Arquitetura de data mesh com AWS Lake Formation e AWS Glue

Por Nivas Shankar, Arquiteto de Soluções Principal de Data na AWS,
Ian Meyers, Gerente Principal de Produto na AWS,
Zach Mitchell, Arquiteto de Soluções Senior de BigData na AWS e
Roy Hasson, Gerente Principal de Produto na AWS

Organizações de todos os tamanhos reconheceram que os dados são um dos principais facilitadores para aumentar e sustentar a inovação e gerar valor para seus clientes e unidades de negócios. Elas estão modernizando avidamente as plataformas de dados tradicionais com tecnologias nativas da nuvem que são altamente escaláveis, ricas em recursos e econômicas. À medida que você procura tomar decisões de negócios guiadas por dados, você pode ser ágil e produtivo ao adotar uma mentalidade que fornece produtos de dados a partir de equipes especializadas, ao invés de por meio de uma plataforma de gerenciamento de dados centralizada que fornece análises generalizadas.

Neste post, será descrita uma abordagem para implementar uma arquitetura de data mesh usando serviços nativos da AWS, incluindo o AWS Lake Formation e o AWS Glue. Essa abordagem permite que as linhas de negócios (LOBs) e as unidades organizacionais operem de forma autônoma, possuindo seus produtos de dados de ponta a ponta, ao mesmo tempo em que fornece descoberta de dados centralizada, governança e auditoria para a organização em geral, para garantir a privacidade e a conformidade dos dados.

Benefícios de um modelo de data mesh

Um modelo centralizado destina-se a simplificar a equipe e o treinamento através da centralização de dados e conhecimento técnico em um único local, reduzir o débito técnico gerenciando uma única plataforma de dados e reduzir os custos operacionais. Os grupos de plataformas de dados, muitas vezes parte da TI central, são divididos em equipes com base nas funções técnicas da plataforma que eles suportam. Por exemplo, uma equipe pode ser proprietária das tecnologias de ingestão usadas para coletar dados de várias fontes de dados gerenciadas por outras equipes e LOBs. Uma equipe diferente pode possuir pipelines de dados, escrever e depurar, extrair, transformar e carregar código (ETL) e orquestrar execuções de trabalho, ao mesmo tempo em que valida e corrige problemas de qualidade de dados e garante que o processamento de dados atenda aos SLAs de negócios. No entanto, o gerenciamento de dados por meio de uma plataforma de dados central pode criar desafios de dimensionamento, propriedade e responsabilidade, porque as equipes centrais podem não entender as necessidades específicas de um domínio de dados, seja devido a tipos e armazenamento de dados, segurança, requisitos de catálogo de dados ou tecnologias específicas necessárias para o processamento de dados.

Muitas vezes você pode reduzir esses desafios, dando propriedade e autonomia à equipe proprietária dos dados e permitindo que eles criem produtos de dados, em vez de apenas poder usar uma plataforma de dados central comum. Por exemplo, as equipes de produtos são responsáveis por garantir que o estoque seja atualizado regularmente com novos produtos e alterações nos produtos existentes. Eles são os especialistas em domínio dos conjuntos de dados de inventário de produtos. Se ocorrer uma discrepância, eles são o único grupo que sabe como corrigi-la. Portanto, eles são mais capazes de implementar e operar uma solução técnica para ingerir, processar e produzir o conjunto de dados de inventário do produto. Eles são donos de tudo o que leva ao consumo dos dados: escolhem a pilha de tecnologia, operam na mentalidade dos dados como um produto, aplicam segurança e auditoria e fornecem um mecanismo para expor os dados à organização de uma maneira fácil de consumir. Isso reduz o atrito geral para o fluxo de informações na organização, onde o produtor é responsável pelos conjuntos de dados que produz e é responsável perante o consumidor com base nos SLAs anunciados.

Esse paradigma de dados como produto é semelhante ao modelo operacional de construção de serviços da Amazon. As equipes de serviço criam seus serviços, expõem APIs com SLAs anunciados, operam seus serviços e possuem a experiência completa do cliente. Isso é diferente do mundo em que alguém constrói o software e uma equipe diferente faz a operação. O modelo de propriedade ponta a ponta nos permitiu implementar mais rapidamente, com melhor eficiência e escalar rapidamente para atender aos casos de uso dos clientes. Não estamos limitados por equipes centralizadas e sua capacidade de escalar para atender às demandas dos negócios. Cada serviço que construímos fica sobre os ombros de outros serviços que fornecem os blocos de construção. A analogia no mundo dos dados seria os produtores de dados possuírem a implementação e o serviço de produtos de dados de ponta a ponta, usando as tecnologias que eles selecionaram com base em suas necessidades exclusivas. Na AWS, falamos sobre o modelo de organização orientado por dados há anos, que consiste em produtores e consumidores de dados. Esse modelo é semelhante aos usados por alguns de nossos clientes e foi descrito de forma eloquente recentemente por Zhamak Dehghani, da Thoughtworks, que cunhou o termo data mesh em 2019.

Visão geral da solução

Nesta postagem, será demonstrado como a arquitetura da Lake House é ideal para ajudar as equipes a construir domínios de dados e como você pode usar a abordagem de data mesh para reunir domínios para permitir o compartilhamento de dados e a federação entre unidades de negócios. Essa abordagem pode permitir uma melhor autonomia e um ritmo mais rápido de inovação, ao mesmo tempo em que se baseia em uma arquitetura e tecnologia comprovadas e bem compreendidas, além de garantir altos padrões de segurança e governança de dados.

A seguir estão os pontos-chave ao considerar um design de data mesh:

Data mesh é um padrão para definir como as organizações podem se organizar em torno de domínios de dados com foco no fornecimento de dados como um produto. No entanto, pode não ser o padrão certo para todos os clientes.
A abordagem da Lake House e a arquitetura de data lake fornecem orientação técnica e soluções para a criação de uma plataforma de dados moderna na AWS.
A abordagem Lake House com um data lake fundacional serve como um projeto repetível para a implementação de domínios de dados e produtos de forma escalável.
A maneira pela qual você utiliza os serviços de analytics da AWS em um padrão de data mesh pode mudar com o tempo, mas ainda permanece consistente com as recomendações tecnológicas e as melhores práticas para cada serviço.

A seguir estão os objetivos de design de data mesh:

Dados como produto — Cada domínio organizacional possui seus dados de ponta a ponta. Eles são responsáveis por criar, operar, servir e resolver quaisquer problemas decorrentes do uso de seus dados. A precisão e a responsabilidade dos dados são do proprietário dos dados dentro do domínio.
Governança de dados federada — a governança de dados garante que os dados sejam seguros, precisos e não sejam usados indevidamente. A implementação técnica da governança de dados como coleta de linhagem, validação da qualidade dos dados, criptografia de dados em repouso e em trânsito e aplicação de controles de acesso apropriados, pode ser gerenciada por cada um dos domínios de dados. No entanto, a descoberta central de dados, a emissão de relatórios e a auditoria são necessários para simplificar a localização dos dados pelos usuários e para que os auditores verifiquem a conformidade.
Acesso comum — os dados devem ser facilmente consumidos por pessoas do assunto, como analistas de dados e cientistas de dados, bem como serviços de analytics e aprendizado de máquina (ML) como o Amazon Athena, Amazon Redshift e Amazon SageMaker. Para fazer isso, os domínios de dados devem expor um conjunto de interfaces que tornam os dados consumíveis, ao mesmo tempo em que impõem controles de acesso e rastreamento de auditoria apropriados.

A seguir estão as considerações sobre a experiência do usuário:

As equipes de dados são donas do ciclo de vida das informações, desde o aplicativo que cria os dados originais até os sistemas de análise que extraem e criam relatórios e previsões de negócios. Por meio desse ciclo de vida, elas são donas do modelo de dados e determinam quais conjuntos de dados são adequados para publicação aos consumidores.
Os produtores de domínio de dados expõem conjuntos de dados para o resto da organização, registrando-os em um catálogo central. Eles podem escolher o que compartilhar, por quanto tempo e como os consumidores podem interagir com ele. Eles também são responsáveis por manter os dados e garantir que eles sejam precisos e atualizados.
Consumidores de domínio de dados ou usuários individuais devem ter acesso aos dados por meio de uma interface compatível, como uma API de dados, que pode garantir desempenho consistente, rastreamento e controles de acesso.
Todos os ativos de dados são facilmente detectáveis a partir de um único catálogo de dados central. O catálogo de dados contém os conjuntos de dados registrados por produtores de domínio de dados, incluindo metadados de suporte como linhagem, métricas de qualidade de dados, informações de propriedade e contexto de negócio.
Todas as ações realizadas com dados, padrões de uso, transformação de dados e classificações de dados devem ser acessíveis por meio de um único local central. Proprietários de dados, administradores e auditores devem poder inspecionar a postura de conformidade de dados de uma empresa em um único local.

Vamos começar com um design de alto nível que se baseia no padrão de data mesh. No diagrama a seguir, há separação de consumidores, produtores e governança central para destacar os principais aspectos discutidos anteriormente. No entanto, um domínio de dados pode representar um consumidor de dados, um produtor de dados ou ambos.

O objetivo desse projeto é criar uma base para a construção de plataformas de dados em escala, apoiando os objetivos de produtores e consumidores de dados com governança forte e consistente. A abordagem da AWS para projetar um data mesh identifica um conjunto de princípios e serviços gerais de design para facilitar as melhores práticas para a criação de plataformas de dados escaláveis, compartilhamento de dados onipresente e permitir self-service analytics na AWS.

Expandindo o diagrama anterior, fornecemos detalhes adicionais para mostrar como os serviços nativos da AWS dão suporte a produtores, consumidores e governança. Cada domínio de dados, seja produtor, consumidor ou ambos, é responsável por sua própria stack de tecnologia. No entanto, o uso de serviços nativos de analytics da AWS com a arquitetura Lake House oferece um blueprint repetível que sua organização pode usar à medida que você escala seu projeto de data mesh. Ter uma base técnica consistente garante que os serviços sejam bem integrados, os principais recursos sejam suportados, a escala e o desempenho sejam incorporados e os custos permaneçam baixos.

Domínio de dados: produtor e consumidor

Um design de data mesh se organiza em torno de domínios de dados. Cada domínio de dados possui e opera vários produtos de dados com sua própria stack de dados e tecnologia, que é independente de outros. Os domínios de dados podem ser puramente produtores, como um domínio financeiro que produz apenas dados de vendas e receita para domínios para consumidores, ou um domínio de consumidor, como um serviço de recomendação de produtos que consome dados de outros domínios para criar as recomendações de produtos exibidas em um site de comércio eletrônico. Além do compartilhamento, um catálogo de dados centralizado pode fornecer aos usuários a capacidade de encontrar mais rapidamente conjuntos de dados disponíveis e permitir que os proprietários de dados atribuam permissões de acesso e auditem o uso em unidades de negócios.

Um domínio de produtor reside em uma conta da AWS e usa buckets do Amazon Simple Storage Service (Amazon S3) para armazenar dados brutos e transformados. Ele mantém sua própria stack de ETL usando o AWS Glue para processar e preparar os dados antes de ser catalogado em um Lake Formation Data Catalog em sua própria conta. Da mesma forma, o domínio do consumidor inclui seu próprio conjunto de ferramentas para realizar análises e ML em uma conta separada da AWS. A conta central de governança de dados é usada para compartilhar conjuntos de dados com segurança entre produtores e consumidores. É importante observar que o compartilhamento é feito apenas por meio da vinculação de metadados. Os dados não são copiados para a conta central e a propriedade permanece com o produtor. O catálogo central facilita para qualquer usuário encontrar dados e solicitar acesso ao proprietário dos dados em um único local. Eles podem então usar sua ferramenta de escolha dentro de seu próprio ambiente para realizar análises e ML nos dados.

O diagrama a seguir ilustra o fluxo de trabalho de ponta a ponta.

O fluxo de trabalho do produtor para o consumidor inclui as seguintes etapas:

Os locais de origem de dados hospedados pelo produtor são criados no AWS Glue Data Catalog do produtor e registrados no Lake Formation.
Quando um conjunto de dados é apresentado como um produto, os produtores criam entidades do Lake Formation Data Catalog (banco de dados, tabela, colunas, atributos) dentro da conta de governança central. Isso facilita a localização e a descoberta de catálogos entre os consumidores. No entanto, isso não concede nenhum direito de permissão para catálogos ou dados para todas as contas ou consumidores, e todas as concessões são autorizadas pelo produtor.
O Catálogo de Dados do Lake Formation central compartilha os recursos do Catálogo de Dados de volta à conta do produtor com as permissões necessárias por meio de links de recursos do Lake Formation para bancos de dados e tabelas de metadados.
As permissões do Lake Formation são concedidas na conta central para personas de função de produtor (como a função de engenheiro de dados) para gerenciar alterações de esquema e realizar transformações de dados (alterar, excluir, atualizar) no Catálogo de Dados central.
Os produtores aceitam o compartilhamento de recursos da conta de governança central para que possam fazer alterações no esquema posteriormente.
As alterações de dados feitas na conta do produtor são propagadas automaticamente para a cópia de governança central do catálogo.
Com base em uma solicitação de acesso do consumidor e na necessidade de tornar os dados visíveis no AWS Glue Data Catalog do consumidor, o proprietário da conta central concede permissões do Lake Formation a uma conta de consumidor com base no compartilhamento direto da entidade ou com base em controles de acesso baseados em tags, que podem ser usados para administrar o acesso via controles como classificação de dados, centro de custos ou ambiente.
O Lake Formation na conta do consumidor pode definir permissões de acesso nesses conjuntos de dados para os usuários locais consumirem. Os usuários na conta do consumidor, como analistas de dados e cientistas de dados, podem consultar dados usando a ferramenta escolhida, como Athena e Amazon Redshift.

Crie produtos de dados

Os produtores de domínio de dados ingerem dados em seus respectivos buckets do S3 por meio de um conjunto de pipelines que gerenciam, possuem e operam. Os produtores são responsáveis por todo o ciclo de vida dos dados sob seu controle e por mover dados de dados brutos capturados de aplicativos para um formato adequado para consumo por terceiros. O AWS Glue é um serviço de preparação e integração de dados sem servidor que oferece todos os componentes necessários para desenvolver, automatizar e gerenciar pipelines de dados em escala e de forma econômica. Ele fornece uma interface simples de usar que as organizações podem usar para integrar rapidamente domínios de dados.

Governança de dados centralizada

A conta central de governança de dados armazena um catálogo de dados de todos os dados corporativos entre contas e fornece recursos que permitem aos os produtores registrar e criar entradas de catálogo com o AWS Glue de todos os buckets do S3. Não existem dados (exceto logs) nesta conta. O Lake Formation define centralmente políticas de segurança, governança e auditoria em um só lugar, aplica essas políticas para os consumidores em aplicativos de análise e apenas fornece autorização e acesso por token de sessão para fontes de dados para a função que está solicitando acesso. O Lake Formation também fornece controle de acesso uniforme para compartilhamento de dados em toda a empresa por meio de compartilhamentos de recursos com governança e auditoria centralizadas.

Acesso comum

Cada consumidor obtém acesso a recursos compartilhados da conta de governança central na forma de links de recursos. Eles estão disponíveis no Lake Formation local do consumidor e no AWS Glue Data Catalog, permitindo acesso ao banco de dados e à tabela que pode ser gerenciado pelos administradores do consumidor. Depois que o acesso é concedido, os consumidores podem acessar a conta e realizar ações diferentes com os seguintes serviços:

O Athena atua como consumidor e executa consultas sobre dados registrados usando o Lake Formation. O Lake Formation verifica se o principal de função do grupo de trabalho AWS Identity and Access Management (IAM) tem as permissões de Lake Formation apropriadas para o banco de dados, além da tabela e o local do Amazon S3 apropriado para a consulta. Se o principal tiver acesso, o Lake Formation enviará credenciais temporárias para o Athena e a consulta será executada. A autenticação é concedida por meio de funções ou usuários do IAM ou identidades federadas da web usando SAML ou OIDC. Para obter mais informações, consulte Como o Athena acessa os dados registrados com o Lake Formation.
O Amazon SageMaker Data Wrangler permite selecionar rapidamente dados de várias fontes de dados, como Amazon S3, Athena, Amazon Redshift, Lake Formation e Amazon SageMaker Feature Store. Você também pode escrever consultas para fontes de dados e importar dados diretamente para o SageMaker a partir de vários formatos de arquivo como arquivos CSV, arquivos Parquet e tabelas de banco de dados. A autenticação é concedida por meio de IAM roles na conta do consumidor. Para obter mais informações, consulte Preparar dados de ML com o Amazon SageMaker Data Wrangler.
O Amazon Redshift Spectrum permite registrar esquemas externos do Lake Formation e fornece uma hierarquia de permissões para controlar o acesso a bancos de dados e tabelas do Amazon Redshift em um catálogo de dados. Se a entidade do consumidor tiver acesso, o Lake Formation enviará credenciais temporárias para tabelas do Redshift Spectrum e a consulta será executada. A autenticação é concedida por meio de roles ou usuários do IAM ou identidades federadas da web usando SAML ou OIDC. Para obter mais informações, consulte Usando o Redshift Spectrum com o AWS Lake Formation.
O Amazon QuickSight via Athena se integra às permissões do Lake Formation. Se você estiver consultando dados com o Athena, você pode usar o Lake Formation para simplificar a segurança e a conexão com seus dados do QuickSight. O Lake Formation adiciona ao modelo de permissões do IAM fornecendo seu próprio modelo de permissões que é aplicado aos serviços de Analytics e ML da AWS. A autenticação é concedida por meio de IAM roles mapeadas às permissões de usuário do QuickSight. Para obter mais informações, consulte Autorizar conexões por meio do AWS Lake Formation.
Os notebooks do Amazon EMR Studio e do EMR permitem executar SparkSQL em tabelas do Lake Formation apoiadas por uma autoridade SAML. A partir do Amazon EMR31.0, você pode executar um cluster que se integra ao Lake Formation. A autenticação é concedida por meio de roles ou usuários do IAM ou identidades federadas da web usando SAML ou OIDC. Para obter mais informações, consulte Integrar o Amazon EMR ao AWS Lake Formation.

Com esse design, você pode conectar múltiplos Lake Houses a uma conta de governança centralizada que armazena todos os metadados de cada ambiente. O poder dessa abordagem é que ela integra todos os metadados e os armazena em um esquema de meta-modelo que pode ser facilmente acessado por meio dos serviços da AWS para vários consumidores. Você pode estender essa arquitetura para registrar novos catálogos de data lake e compartilhar recursos entre contas de consumidores. O diagrama a seguir ilustra uma arquitetura de data mesh entre contas.

Conclusão

Uma abordagem de data mesh fornece um método pelo qual as organizações podem compartilhar dados entre unidades de negócios. Cada domínio é responsável pela ingestão, processamento e disponibilização de seus dados. Eles são proprietários de dados e especialistas em domínio, e são responsáveis pela qualidade e precisão dos dados. Isso é semelhante ao modo como os microsserviços transformam um conjunto de recursos técnicos em um produto que pode ser consumido por outros microsserviços. A implementação de um data mesh na AWS é simplificada usando serviços gerenciados e sem servidor como AWS Glue, Lake Formation, Athena e Redshift Spectrum, para fornecer uma solução bem compreendida, de desempenho, escalável e econômica para integrar, preparar e fornecer dados.

Um cliente que usou esse padrão de data mesh é JPMorgan Chase. Para obter mais informações, consulte Como o JPMorgan Chase construiu uma arquitetura de data mesh para gerar valor significativo para aprimorar sua plataforma de dados corporativos.

O AWS Lake Formation oferece a capacidade de implementar a governança de dados dentro de cada domínio de dados e entre domínios para garantir que os dados sejam facilmente detectáveis e seguros. A linhagem é rastreada e o acesso pode ser auditado. Uma arquitetura de Lake House fornece uma base ideal para suportar um data mesh e fornece um padrão de design para aumentar a entrega de domínios de produtores dentro de uma organização. Cada domínio tem autonomia para escolher sua própria pilha de tecnologia, mas é governado por um modelo de segurança federado que pode ser administrado centralmente, fornecendo as melhores práticas de segurança e conformidade, ao mesmo tempo em que permite alta agilidade dentro do domínio.

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre o tradutor

Daniel Bento é Sr. Analytics Solutions Architect na AWS.

Sobre os revisores

Ivan Vargas é Sr. Solutions Architect na AWS.

Fabricio Quiles é Sr. Analytics Solutions Architect na AWS.

Explore mais conteúdos sobre Analytics na página de Sessions On Demand.

Acesse >

O blog da AWS