Um único lakehouse onde data engineering, análise e machine learning usam as mesmas tabelas, devidamente geridas.
Com a confiança de organizações de referência
Numa implementação de Databricks, criamos um lakehouse: tabelas Delta no seu ambiente cloud, Unity Catalog para gerir permissões e lineage, Lakeflow para carregamento e orquestração e MLflow para modelos. Como parceira Databricks, a Data Science Lab faz isto para organizações com muitas fontes de dados, grandes volumes de dados ou a ambição de colocar machine learning em produção.
Muitos ambientes Databricks começam com um único data scientist e alguns notebooks. Com o tempo, há jobs a correr em clusters criados manualmente, as tabelas continuam no antigo Hive metastore e ninguém sabe qual é o notebook que alimenta a tabela de clientes de que depende o relatório de marketing. Se esse colega sair, leva o conhecimento consigo.
Os custos também aumentam. Os clusters interativos continuam ativos fora do horário de trabalho e, sem tags, não é possível saber que equipa foi responsável por cada parcela do consumo. As tags só se aplicam ao consumo a partir do momento em que são adicionadas; se forem adicionadas mais tarde, perde-se o histórico.
A plataforma cumpre a sua função. O que falta é uma estrutura definida de catálogos, um responsável por cada tabela e um percurso do desenvolvimento até à produção. É aí que começa o nosso trabalho no âmbito da fundação de dados.
O Delta Lake acrescenta um registo de transações aos ficheiros Parquet. Isto permite transações ACID, validação do esquema durante a escrita e uma nova versão da tabela a cada alteração. O protocolo é aberto, pelo que outras ferramentas também podem ler as tabelas.
Tabelas, volumes, funções e modelos ficam num único catálogo, com nomes em três partes no formato catalog.schema.object. As permissões são atribuídas a grupos, e a linhagem de dados ao nível da coluna mostra que fonte alimenta cada dashboard ou modelo.
Os dados brutos permanecem inalterados na camada bronze; a camada prata valida-os e elimina duplicados; a camada ouro fornece tabelas para relatórios e modelos. A Databricks desaconselha a escrita diretamente da ingestão para a camada prata: uma alteração do esquema pode interromper a pipeline.
O Lakeflow Connect carrega dados de forma incremental a partir de fontes como SQL Server, Salesforce ou SharePoint. As pipelines declarativas usam expectations para monitorizar a qualidade de cada registo, e o Lakeflow Jobs agenda as tarefas e comunica os erros.
Registamos experiências, versões de modelos e aprovações no MLflow, com os modelos no Unity Catalog. O Model Serving disponibiliza um modelo como REST-API, para que as suas aplicações o possam chamar em vez de ficar apenas num notebook.
Os SQL warehouses dão aos analistas e a ferramentas como Power BI ou Tableau acesso às mesmas tabelas da camada ouro. A Databricks recomenda serverless warehouses onde estejam disponíveis, porque iniciam rapidamente e reduzem a capacidade quando deixa de ser necessária.
Fale com um dos nossos data engineers sobre os seus catálogos, custos ou a migração para o Unity Catalog.
Em conjunto com o seu departamento de TI, definimos o ambiente cloud, a região, a rede e as identidades e escolhemos classic ou serverless compute como ponto de partida.
Organizamos o Unity Catalog por ambiente e domínio, atribuímos um responsável a cada catálogo e gerimos as permissões através dos grupos do seu fornecedor de identidades.
Carregamos os dados das primeiras fontes de forma incremental com o Lakeflow Connect ou código próprio e guardamos os dados em bruto para que os possa voltar a processar mais tarde.
Para uma questão concreta, criamos tabelas validadas e agregadas, com regras de qualidade na pipeline. Os utilizadores conferem os resultados com números que conhecem.
As políticas de compute limitam os tipos e tamanhos dos clusters, o encerramento automático desliga os clusters esquecidos, e as tags e os alertas de orçamento tornam visível o consumo de cada equipa na tabela de sistema de faturação.
Definimos os jobs e as pipelines em Declarative Automation Bundles no Git, para que cada release seja reproduzível. Depois, a sua equipa assume a gestão ou gerimos nós a plataforma.
A plataforma de dados é, para nós, o ponto central onde os dados se reúnem. Permite-nos disponibilizar dados a toda a empresa para obter insights de negócio, garantindo ao mesmo tempo que existe apenas uma versão da verdade.
O Databricks funciona em Azure, AWS e Google Cloud, e a escolha depende normalmente da cloud que já utiliza. Com classic compute, os clusters funcionam na sua própria conta cloud; com serverless compute, o Databricks faz a gestão, na mesma região que a sua workspace. Tenha atenção às regiões: o Unity Catalog tem uma metastore por região e a lineage não atravessa fronteiras regionais.
O Databricks é adequado quando existem muitas fontes e grandes volumes de dados, para equipas que trabalham com Python e Spark e para modelos em produção com controlo de versões e monitorização. Se procura sobretudo uma plataforma única centrada no Power BI, com pouca gestão de infraestrutura, conheça a nossa abordagem à implementação do Microsoft Fabric. Também é possível combinar as duas plataformas: o Fabric pode espelhar o catálogo do Azure Databricks, permitindo ao Power BI ler as tabelas gold sem as copiar.
Para a GVB, criámos no Databricks um workflow de MLOps com templates reutilizáveis, para que um modelo de segmentação do comportamento de viagem funcione em produção e possa ser mantido. Para a Fokker Services Group, reunimos fontes de dados dispersas numa plataforma Databricks em Azure, para uma ferramenta de planeamento que prevê quando é necessária manutenção.
Qualquer organização pode iniciar um projeto-piloto de IA. O desafio está no passo seguinte: integrar a IA na organização. É aí que a Data Science Lab faz a diferença.
Saiba mais sobre nós
10+
8,7
200+
Um lakehouse funcional com um primeiro caso de uso: fontes carregadas de forma incremental, tabelas bronze, prata e ouro em Delta Lake, permissões e lineage em Unity Catalog e jobs monitorizados. Configuramos também políticas de compute, tags e alertas de orçamento, além de um processo de publicação através de Git. A sua equipa pode continuar a desenvolver a partir daí sem ter de refazer a fundação de dados.
A base é a mesma nas três: Delta Lake, Unity Catalog, Lakeflow e MLflow. A diferença está na integração com as suas identidades, rede e armazenamento. Por isso, escolha a cloud onde já estão os seus dados e processos de gestão. Escolha também a região de forma consciente: um metastore de Unity Catalog está associado a uma única região. Verifique ainda se serverless compute está disponível nessa região.
Com regras integradas na plataforma desde o início. As políticas de compute limitam os clusters que cada pessoa pode iniciar, o encerramento automático pára os clusters inativos e, para SQL, escolhemos warehouses serverless sempre que possível. As tags por equipa tornam o consumo visível na tabela de sistema de faturação. Os orçamentos geram alertas, mas não são limites rígidos: é preciso que alguém lhes dê seguimento.
Fazemos a migração passo a passo. A Databricks recomenda começar por federar o antigo metastore do Hive como foreign catalog e, depois, converter as tabelas no local, sem mover os dados. Entretanto, os jobs existentes continuam a funcionar. Em seguida, migramos as queries e os jobs e desativamos o antigo metastore, para que ninguém contorne as novas permissões.
Registamos experiências e versões dos modelos no MLflow e registamos os modelos no Unity Catalog, para que lineage e permissões também se apliquem aos modelos. O Model Serving disponibiliza um modelo como uma API REST para as suas aplicações, enquanto os jobs tratam do novo treino. Depois da entrada em produção, monitorizamos a qualidade, porque o desempenho de um modelo pode degradar-se quando os dados mudam.
Somos parceiros Databricks e concebemos plataformas de acordo com as boas práticas da Databricks. Para o Koninklijk Concertgebouworkest, construímos uma plataforma de dados com Databricks, Azure, Delta Lake, Unity Catalog e dbt que liga informação de vários sistemas. Para a Vivara, desenvolvemos uma plataforma de dados que carrega diariamente dados de fontes como SAP, Magento e SharePoint no Azure Databricks.
Se tem poucas fontes, volumes modestos e usa sobretudo o Power BI para relatórios, uma plataforma Spark é muitas vezes mais do que precisa. Nesses casos, uma base de dados bem modelada para o Power BI costuma ser suficiente, ou o Microsoft Fabric se forem acrescentadas fontes e equipas. Para organizações mais pequenas, saiba mais sobre dados e IA para PME. E, sem alguém que mantenha o código Python e Spark, o Databricks pode tornar-se mais um peso do que uma ajuda.
E-mail info@datasciencelab.nl
Telefone +31 (0)20 3636 724
Diga-nos o que está atualmente em funcionamento e onde estão os entraves. Analisamos consigo os catálogos, os custos e o primeiro caso de uso que faz a diferença.
Mensagem enviada
Obrigado pela sua mensagem. Entraremos em contacto consigo o mais rapidamente possível.
