Blogs

Início / Blogs / Discutindo armazenamento de dados para o setor de serviços financeiros com Vincent Rainardi

Tabela de conteúdo
O Automatizado, Nenhum código Pilha de dados

Saiba como Astera O Data Stack pode simplificar e agilizar o gerenciamento de dados da sua empresa.

Discutindo armazenamento de dados para a indústria de serviços financeiros com Vincent Rainardi

26 de fevereiro de 2024

Com o lançamento de Astera Construtor de DW ao virar da esquina, estivemos conversando com alguns dos principais líderes de pensamento do setor para obter sua opinião sobre o setor como ele está, como está evoluindo e onde eles veem a automação do data warehouse se encaixando no cenário mais amplo.

Para nossa segunda entrevista nesta série, nos sentamos com Vincent Rainardi, um veterano de longa data no espaço de armazenamento de dados. Ele trabalhou em projetos para clientes como Barclays, Lloyds Bank, Toyota e Avery Dennison. Vincent também escreveu extensivamente sobre armazenamento de dados e BI, escrevendo um livro Construindo um Data Warehouse: com exemplos no SQL Server e um popular blog sobre o tema.

Nesta discussão, mergulhamos profundamente nas diversas experiências e percepções de Vincent sobre armazenamento de dados, com um foco específico no setor de serviços financeiros, onde ele acumulou experiência substancial ao longo dos anos.

Você poderia me contar um pouco sobre seu envolvimento com o armazenamento de dados? Quando você começou a trabalhar nesses projetos e quais funções você desempenhou no processo de desenvolvimento ao longo dos anos?

Comecei a trabalhar com data warehouse em 1996, construindo um data warehouse e BI para um fabricante de automóveis. Naquela época, o DW & BI era denominado DSS e EIS / MIS (Sistema de Apoio à Decisão e Sistema de Informação Executivo / Gerencial). Então, deixei o DW / BI por alguns anos, mas me envolvi neste espaço novamente em 2005, quando li o livro de Ralph Kimball sobre armazenamento de dados (O Data Warehouse Toolkit) e ficou muito apaixonado por ele. Depois disso, escrevi muitos artigos sobre o assunto para vários sites e meu blog. Em 2007, publiquei um livro cobrindo muitos de meus insights sobre armazenamento de dados.

Desde 2005, tenho trabalhado em vários projetos de armazenamento de dados, desenvolvendo armazéns de dados para bancos, gestores de ativos, seguradoras, fabricantes, prestadores de cuidados de saúde, varejistas e empresas de comércio eletrônico. Durante as implementações, minhas responsabilidades principais são como arquiteto de data warehouse, ou seja, projetar a arquitetura de fluxo de dados, os modelos de dados e as plataformas físicas, incluindo SQL Server, Oracle, Teradata, Hadoop, Azure.

Também desempenhei várias outras funções, incluindo analista de negócios (requisitos de negócios, especificações funcionais), designer de BI (definindo painéis e visualizações), desenvolvedor de BI (trabalhando com plataformas como QlikView, Spotfire, Tableau, SSRS, SSAS , ProClarity, Business Objects, Strategy Companion), desenvolvedor de ETL (SSIS, Informatica, utilitários Teradata, SQL), testador e gerente de projeto.

Você falou um pouco antes sobre as diferenças entre data warehouse e BI - como você acha que esses dois conceitos se complementam e onde eles diferem em princípio?

Na prática, eles são usados ​​alternadamente, mas, na verdade, são diferentes. BI é o front end (painéis, relatórios, visualizações) e o data warehouse é o backend (banco de dados, armazenamento, ETL, arquivos). No entanto, eles se complementam e, na prática, são usados ​​juntos. Hoje, o back-end não precisa ser um data warehouse; pode ser um data lake. E o front end não precisa ser BI; pode ser aprendizado de máquina.

Você tem uma vasta experiência em serviços financeiros. O que você diria que são os casos de uso mais comuns que você vê em organizações em setores como seguros ou banco de investimento?

Os casos de uso em seguros envolvem muitas análises complexas. Então, normalmente, as organizações procuram responder a perguntas sobre os tipos de prêmio bruto de nível superior ganho, prêmios emitidos, cobertura de risco, custo de risco, ajustes de sinistros, cronogramas de sinistros, pipelines de vendas, lucratividade do cliente, subscrição, taxas atuariais, riscos de resseguro, e fluxo de caixa.

No banco de investimento, essas análises cobrirão riscos de mercado, exposição de posição, atividades de negociação, relatórios regulatórios, pesquisa de mercado, liquidez, garantia, pipelines de negócios, contas de clientes, anti-lavagem de dinheiro, contrapartes, detecção de fraude, gestão de portfólio e testes de estresse de capital .

Observamos um aumento significativo no volume e na variedade de dados que circulam pelas empresas na última década. Como você vê o chamado data warehouse tradicional evoluindo para lidar com esses requisitos?

Portanto, o data warehouse tradicional evoluiu para incorporar data lake e tecnologias de big data. Os dados não estruturados são armazenados em data lakes, incluindo documentos, imagens, vídeo, IoT e feeds de mídia social, enquanto os dados estruturados (dados armazenados em formato tabular) são armazenados no data warehouse. Os data lakes são normalmente construídos no sistema de arquivos Hadoop em comparação com o data warehouse, que geralmente é construído em bancos de dados relacionais. Os armazéns de dados modernos também incorporam NoSQL, como bancos de dados de gráficos e documentos, pois alguns dados são mais adequados para esses tipos de formatos. Isso cobre a parte da variedade.

No que diz respeito ao volume, nos primeiros anos do armazenamento de dados, os bancos de dados MPP como Teradata, Oracle Exadata e Microsoft PDW eram uma forma popular de lidar com grandes volumes de dados, mantendo os dados relacionais. Mas hoje em dia, as tecnologias de big data são muito mais amplamente utilizadas.

Qual é a sua opinião sobre o data lake? Ele tem um lugar no sistema de BI moderno? Complementa o data warehouse ou é uma alternativa viável?

Sim. Os armazéns de dados modernos usam lagos de dados como uma área de teste que permite aos usuários e tecnologias de ML de front-end acessar dados brutos. Contanto que você não esteja procurando integrar dados, o data lake é uma alternativa viável. Esse tipo de caso de uso é frequentemente visto em projetos onde os dados são isolados (separados de outras funções) e o tempo de desenvolvimento é mínimo, caso em que os data lakes são muito eficazes. Bons exemplos para isso seriam um projeto de detecção de fraude baseado em aprendizado de máquina em um banco ou um projeto onde um requisito de relatório regulatório específico precisa ser atendido dentro de três meses. Quando esses siloes são removidos posteriormente (ou seja, quando outras funções corporativas precisam acessar o resultado da previsão), a saída do modelo pode ser armazenada no data warehouse para usuários downstream.

No entanto, na maioria dos cenários corporativos, você precisará integrar os dados. Por exemplo, uma seguradora ou gerente de ativos precisará criar um visão unificada a partir de dados sobre títulos, emissores, apólices e clientes para desenvolver uma imagem precisa de sua empresa.

Você disse no passado que entender o negócio pode ser a parte mais crítica do desenvolvimento do data warehouse. Como você faria para garantir que os requisitos de negócios sejam fielmente traduzidos na arquitetura de dados?

Sim, a compreensão do negócio é muito importante. Não é possível projetar um bom modelo de dados sem um bom entendimento do negócio. Imagine se você fosse encarregado de projetar um data warehouse ESG (ambiental, social, de governança), mas não tinha ideia do que era ESG. Ou um data mart de subscrição, mas você nunca trabalhou com seguros. Você não pode saber como as tabelas de fatos e dimensões deveriam se parecer. Um bom arquiteto de dados deve estar interessado nos detalhes do negócio. Digamos que você esteja projetando um mercado de atribuição de desempenho para um gerente de investimentos. É essencial que você aprenda sobre a diferença entre retornos aritméticos e geométricos, curvas de rendimento e fatores de interação. Infelizmente, alguns arquitetos de dados não estão interessados ​​nesses detalhes comerciais essenciais. Eles estão mais interessados ​​nas partes técnicas.

A melhor maneira de garantir que os requisitos de negócios sejam bem incorporados ao modelo de dados é executando vários cenários de negócios, testando se cada cenário pode ser satisfeito consultando o modelo de dados usando uma consulta SQL simples. Se para isso você precisa de uma consulta complexa, o modelo de dados não está bem desenhado. Isso geralmente é a queda de um data lake; eles não satisfazem cenários de negócios complicados. E este é o ponto crucial de tudo: escrever bem esses cenários; você precisa ter um bom entendimento do negócio.

Em uma postagem anterior no blog, você escreveu sobre quantas organizações de serviços financeiros ainda estão usando o Excel para gerar relatórios e análises. Você vê essa prática mudando com ferramentas de visualização mais sofisticadas se tornando comum ou continuaremos vendo esse processo no futuro próximo?

As empresas de serviços financeiros continuarão a usar o Excel para análises e relatórios também. Esta é a natureza humana porque os funcionários neste domínio tendem a ter fortes habilidades em Excel. Eu experimentei essa preferência em primeira mão em vários bancos e empresas de investimento. Até mesmo organizações que usam plataformas como Tableau, Qlik ou Power BI pediram um recurso de “exportação para Excel” para análises posteriores.

Embora os relatórios e painéis padrão produzidos pelas ferramentas de visualização sejam importantes (eles contêm dados formalizados em um formato de fácil digestão), os usuários precisam realizar suas próprias análises em muitos casos. Para isso, eles pedem os dados brutos por trás desses painéis em uma ferramenta com a qual estão muito mais familiarizados - o Excel. Com os dados brutos em mãos, eles podem agrupar os dados de forma diferente, aplicar determinados filtros, etc., tudo de acordo com suas necessidades.

Lembre-se de que esses são analistas financeiros, conhecedores de números e pessoas inteligentes - analisar dados e processar números é o que eles fazem. Consumir relatórios estáticos nunca irá satisfazer todas as suas necessidades, e é por isso que geralmente não é uma boa ideia tentar atender a todas as necessidades possíveis na ferramenta de BI.

Nos últimos anos, houve um grande impulso para começar a mover armazéns de dados para a nuvem em plataformas como Google BigQuery ou Amazon Redshift. Qual é a sua opinião sobre as vantagens da implantação da nuvem? Você ainda recomendaria manter bancos de dados locais em alguns casos?

As principais vantagens são a terceirização de recursos humanos e a flexibilidade dos recursos computacionais. Com um data warehouse na nuvem, você não precisa pagar muitas pessoas internamente para manter os processos de servidores, armazenamento, rede, segurança, backup e recuperação de desastres. Se você precisar de um novo servidor de banco de dados, não precisará esperar três semanas para comprar, configurar, instalar, anexar armazenamento, etc. Em vez disso, você obtém maior capacidade de servidor sob demanda e paga por hora.

Esta proposta de valor não é apenas interessante para pequenas empresas, mas também para grandes corporações que muitas vezes se perguntam: "em que negócio devo me concentrar?" Quer você seja um varejista, uma empresa de telecomunicações ou financeira, a resposta certamente não é "o negócio de servidores" nem "o negócio de infraestrutura de TI". Então você terceiriza. Com a infraestrutura em nuvem, você pode aumentar e diminuir a capacidade de computação e a memória como e quando você precisar. Você desliga os servidores de teste e desenvolvimento quando eles não estão em uso à noite e paga por hora.

Quando se trata de servidores de data warehouse poderosos, o custo é proibitivo para configurá-lo internamente (no local). As habilidades exigidas dos funcionários também são proibitivas, pois há muitas habilidades diferentes de especialistas exigidas, de SAN a segurança, de Docker a Yarn. Portanto, eu recomendaria uma implantação baseada em nuvem em vez de um data warehouse local. Esse é o argumento para usar o Google BigQuery, Amazon Redshift e Azure Dedicated SQL Pool (anteriormente SQL DW, PDW, APS).

No entanto, suponha que não seja um projeto novo e você precise aprimorar um data warehouse existente no local com muitos sistemas locais conectados a ele. Nesse caso, o custo para migrar todos esses sistemas / aplicativos para a nuvem é enorme. Digamos, para fins de argumentação, que custaria US $ 2 milhões adicionais e três anos para concluir esse tipo de projeto. Não faz sentido para os negócios gastar aqueles US $ 2 milhões sem recursos de negócios adicionais. Mantenha-o no local, faça o aprimoramento no local e, enquanto isso, construa lentamente seu novo sistema na nuvem. Atualmente, cerca de 25% dos orçamentos de TI vão para a manutenção de sistemas e infraestrutura existentes. Este é o pool do qual você deve utilizar para conduzir uma migração lenta para a nuvem.

Eu já vi você tocar no grande debate ETL vs. ELT antes. Quando se trata de carregar dados no data warehouse, há uma abordagem que você prefere? Ou precisa ser decidido caso a caso?

Precisa ser decidido caso a caso. Depende da infraestrutura. Depende do data lake. Depende da ferramenta de ingestão de dados. E isso depende da plataforma de data warehouse. Em última análise, não importa se você está usando ETL, ELT ou ELTLT; você pode fazer a ingestão de dados de várias maneiras diferentes. Você pode encená-lo uma, duas ou nenhuma. Transforme-o uma, duas ou nenhuma. Você só precisa escolher a abordagem mais adequada para cada pipeline e cada situação.

Seja ETL ou ELT, o “must-have” na ingestão de dados é o teste automatizado. Nimrod Avissar explica bem SUA PARTICIPAÇÃO FAZ A DIFERENÇA. Essa é a abordagem que prefiro em ETL / ELT: abordagem de teste automatizado.

No que diz respeito ao próprio processo de desenvolvimento do data warehouse, você acha que o Agile ou o Waterfall são mais capazes de atender aos requisitos de BI em constante mudança?

Não se trata de ágil ou cascata (ágil, claro, quem quer dar um grande pedaço de uma só vez?). O processo de desenvolvimento do data warehouse trata das operações de desenvolvimento. Esta disciplina de engenharia está madura agora. Você precisa ter um pipeline de lançamento, um quadro de sprint, backlog, controle de origem, controle de alterações, registro de erros e gerenciamento de incidentes. Uma equipe de desenvolvimento de data warehouse precisa ter automação DevOps, ou seja, o processo de liberação deve ser automatizado, desde o controle de origem, puxar a solicitação para o ramo de liberação, implantar em um teste, executar testes automatizados e implantação na produção

CI / CD costumava ser associado ao desenvolvimento de aplicativos, não ao desenvolvimento de data warehouse. Mas agora, é um must-have. Se você administrar uma equipe de desenvolvimento de data warehouse sem ele, incorrerá em muitos custos adicionais todos os meses. Ou pior, sacrificando a qualidade de construção do data warehouse.

Em seu blog, você escreveu sobre alguns elementos-chave que determinam a eficácia de seu data warehouse, incluindo disponibilidade de dados, segurança de dados, qualidade de dados e, claro, desempenho de consulta / carga. Qual você diria que é o fator mais importante?

O elemento mais importante que determina a eficácia de um data warehouse é se ele trata ou não de problemas de negócios e casos de uso. No final do dia, você pode usar seu DW para criar relatórios de clientes, painéis de gerenciamento, relatórios regulatórios ou análises gerais de negócios. Ainda assim, se não resolver o problema do seu negócio, simplesmente não será eficaz. Nesse caso, a falha geralmente pode ser atribuída a uma de três coisas:

  1. Falta de dados específicos, por exemplo, dados sobre um produto ou cliente importante,
  2. Problemas de qualidade de dados, por exemplo, dados incorretos,
  3. Dificuldade em consultar dados, por exemplo, os dados estão no warehouse, mas não aparecem nos relatórios.

Eu diria que dados incorretos são particularmente prejudiciais para os negócios, especialmente quando eles tomam medidas com base nesses dados. Por exemplo, se você usou os dados de desempenho do warehouse para criar uma ficha técnica e errou o desempenho do fundo, é um risco para a reputação e também para o financeiro. Isso não só pode resultar em uma penalidade substancial por parte das autoridades financeiras, mas seus clientes podem se dirigir para a saída com base nos números enganosos que você citou, causando fluxos de saída maciços e um futuro de negócios global sombrio.

Em comparação, se uma consulta de uma hora fosse executada durante todo o dia, isso não seria nada, quase nenhum prejuízo financeiro. O mesmo com não ter dados específicos (disponibilidade de dados), que não é um risco tão grande em comparação com dados incorretos sendo publicados / enviados para as autoridades ou clientes. Por outro lado, se os dados de seus clientes forem roubados, isso também pode prejudicar a confiança do cliente, causando o êxodo de clientes, o que pode deixá-lo sem negócios no futuro previsível.

Eu diria que a qualidade e a segurança dos dados são os dois principais problemas contra os quais você precisa se proteger.

Você também discutiu algumas das etapas críticas na construção de um data warehouse, ou seja, modelagem de dados, criação de processos para carregamento e entrega de dados e, em seguida, arquitetar esses processos para garantir a máxima eficiência. Qual você diria que é a parte mais desafiadora do desenvolvimento do data warehouse?

A parte mais difícil do desenvolvimento do data warehouse não é a modelagem de dados, o carregamento de dados ou a eficiência do processo, mas determinar o que arquitetura é o mais adequado.

Se você escolheu construir um data lake, embora o que você realmente precisa é de um data warehouse dimensional (por causa de sua natureza integrada), você estava indo na direção errada desde o início. Se você decidiu usar uma tecnologia de ingestão específica que nenhum de seus funcionários tinha habilidade para operar, você fez um investimento significativo que aumentou seu risco e criou atrasos evitáveis ​​na implementação. Se você decidiu comprar um data warehouse pré-projetado, mas o modelo de dados não combinava com você, era como construir um arranha-céu em uma base fraca.

 O que não vemos nos bastidores é o que geralmente torna o warehouse um sucesso, ou seja, a escolha da arquitetura, as operações de desenvolvimento e o qualidade de dados cheques.

Onde você vê a automação de data warehouse encaixada aqui? Como isso pode ajudar a reduzir o esforço e o tempo gasto em algumas dessas tarefas? Onde você vê o grande valor no que diz respeito a uma ferramenta desenvolvida para esse fim?

O valor da automação do data warehouse é o carregamento automático. Por exemplo, muitas empresas de gestão de ativos usam sistemas de gestão de investimentos de prateleira amplamente usados ​​para gerenciar seus portfólios. Um data warehouse dimensional que pode carregar dados automaticamente deles tem muito valor. Muitas grandes empresas de manufatura usam SAP como seu sistema operacional central. Um data warehouse que pode carregar dados automaticamente do SAP é valioso porque você não precisa desenvolver os pipelines para carregar os dados, o que leva muito tempo. Em todos os casos, você deve ser capaz de alterar o modelo dimensional conforme achar adequado.

A próxima melhor coisa é tentar automatizar a ingestão de dados. Integrar várias fontes de dados em uma dimensão é complexo (por exemplo, dimensão do cliente, dimensão da empresa, dimensão da segurança) e automatizar é ainda mais difícil. Poderíamos estar lidando com arquivos verticais ou arquivos incrementais, arquivos CSV ou Excel. Precisamos ser capazes de dinamizar, agregar e aglutinar esses dados.

Além disso, não devemos presumir que a fonte de dados seja um arquivo pronto para ser processado; ele pode precisar ser descriptografado, descompactado, renomeado ou baixado primeiro. O núcleo da integração de dados de várias fontes envolve um processo chamado “correspondência de dados”, e pode ser uma correspondência em cascata em vários critérios. O segundo processo principal é chamado de “enriquecimento de dados”, por exemplo, se o título não tiver uma classificação S&P, um país de risco ou setor GICS, então o enriquecemos de uma fonte externa, como Bloomberg ou FactSet.

O valor central de um data warehouse é a dimensão integrada que é criada a partir de muitas fontes. Uma ferramenta de automação de data warehouse precisa ser capaz de construir essa dimensão, não uma dimensão de país ou moeda, mas uma dimensão de cliente ou segurança composta de várias tabelas de origem.

Quais recursos e funcionalidades você acha que são absolutamente essenciais para uma ferramenta de automação de data warehouse eficaz?

As funcionalidades absolutamente essenciais para uma ferramenta de automação de data warehouse eficaz são:

  1. Deve se manter atualizado com ERP, CRM ou IMS (por exemplo, SAP, Salesforce ou ThinkFolio) conforme eles mudam de versão
  2. Deve ter a capacidade de integrar várias fontes para criar dimensões complexas, ou seja, a dimensão do cliente
  3. Ele deve ter a capacidade de pré-processar arquivos de dados, por exemplo, para recuperar ou fazer download de arquivos para processamento.
  4. Deve permitir testes automatizados e implantação

Finalmente, para onde você vê o data warehouse se dirigindo no futuro? Que avanços significativos (se houver) você prevê neste espaço?

Algumas pessoas pensam que podem substituir dois anos de desenvolvimento de data warehouse por um desenvolvimento de data lake de três meses. Isso é enganoso porque os dados do cliente ou do produto que estão sendo carregados na última arquitetura não estão integrados, portanto, não podem ser consultados. E eles podem se esquecer de incluir verificações de qualidade de dados ou prontidão operacional (por exemplo, ferramentas de monitoramento) no sistema, o que, de outra forma, consumiria 30% de todo o esforço. Concedido, alguns projetos não precisam de integração e, neste caso, um data lake pode ser usado, mas você ainda precisa construir verificações de qualidade de dados e prontidão operacional.

O que vejo no futuro é a automação de testes e a automação de verificações de qualidade de dados. Não é muito difícil construir uma ferramenta que observe todos os arquivos recebidos e execute verificações em colunas especificadas, comparando-os com os dados dos últimos dias. Outra coisa que poderia ser construída é uma ferramenta de BI compatível com CI / CD, por exemplo, baseada em XML, para que possa ser implantada do controle de origem até a produção automaticamente porque é baseada em texto.

E, finalmente, até agora, não há uma única ferramenta de governança de dados no mercado que possa fazer a varredura de bancos de dados, ETL e ferramentas de BI e criar automaticamente linhagem de dados dos arquivos de origem ao relatório. Pode não ser possível construir essa ferramenta para cada banco de dados, ETL e ferramenta de BI que existe, mas é possível fazer as principais. A chave para a governança de dados é a automação.

Astera DW Builder - uma resposta ágil para seus desafios de desenvolvimento de data warehouse

Astera O DW Builder é uma plataforma unificada que permite implantar e consumir rapidamente modelos de dados enriquecidos com metadados, orientados pelos requisitos do usuário final.

O produto traz uma variedade de funcionalidades prontas para uso que você pode aproveitar para construir um data warehouse ágil que realmente atenda às necessidades de sua empresa. Desde a implementação de regras de negócios e convenções de nomenclatura no nível lógico até a criação de pipelines de dados complexos que podem recuperar dados automaticamente de seus sistemas de origem escolhidos, transformá-los de acordo com seus requisitos de qualidade de dados e carregá-los em uma nuvem ou banco de dados local de sua escolha , tudo isso é possível por meio de nossa solução sem código.

Agora, estamos dando a você a chance de ter uma primeira visão exclusiva da velocidade e intuitividade do ADWB em um evento de lançamento de ponta a ponta que promete mudar a maneira como você pensa sobre armazenamento de dados. Veja o evento de lançamento exclusivo aqui.

Você pode gostar
Esquema estrela vs. Esquema do floco de neve: 4 diferenças principais
Como carregar dados do AWS S3 para Snowflake
BigQuery x Redshift: qual você deve escolher?
Considerando Astera Para suas necessidades de gerenciamento de dados?

Estabeleça conectividade sem código com seus aplicativos corporativos, bancos de dados e aplicativos em nuvem para integrar todos os seus dados.

Vamos nos conectar agora!
vamos conectar