ao longo dos últimos anos, eu tive muitas conversas com amigos e colegas frustrados com o quão inescrutavelmente complexo é o ecossistema da infra-estrutura de dados. Apesar de não ser tão mau como o mundo do front-end, as coisas estão a mudar rápido o suficiente para criar uma sopa de palavras-chave.

como iniciante, é super desafiador decidir quais as ferramentas certas para você. A Fundação Apache lista 38 projetos na seção “Big Data”, e essas ferramentas têm toneladas de sobreposição sobre os problemas que eles afirmam resolver. Por exemplo, Flink, Samza, Storm e Spark Streaming são “distributed stream processing engines”, Apex e Beam “unify stream and batch processing”.

neste post, eu espero fornecer alguma ajuda navegando as opções como você partiu para construir infra-estrutura de dados. Estes são aproximadamente os passos que eu seguiria hoje, com base em minhas experiências na última década e em conversas com colegas que trabalham neste espaço.

No início de seu projeto, você provavelmente está com nada mais do que um objetivo de “obter insights a partir de meus dados” na mão. Mapear isso para um conjunto específico de tecnologias é extremamente assustador. Você provavelmente não tem um grande senso para quais ferramentas são populares, O Que “fluxo” ou “lote” significa, ou se você mesmo precisa de infra-estrutura de dados em tudo.

neste post, eu espero fornecer alguma orientação para ajudá-lo a sair do terreno rapidamente e extrair o valor de seus dados. Acredito firmemente em manter as coisas simples durante o maior tempo possível, introduzindo complexidade apenas quando é necessária para a escalabilidade. Este post segue esse arco em três etapas. Em muitos aspectos, ele retraça os passos da construção de infra-estrutura de dados que eu segui ao longo dos últimos anos.

Observe que não há uma forma correta de arquiteto de infra-estrutura de dados. Para os especialistas que lêem isso, você pode ter preferido alternativas às soluções sugeridas aqui. Isso é fantástico, e destaca a diversidade de ferramentas incríveis que temos hoje em dia. Percorremos um longo caminho de quando Hadoop MapReduce era tudo o que tínhamos.

então aqui está a coisa: você provavelmente não tem “grandes dados” ainda. Quase 4 anos depois, o artigo de Chris Stuchio 2013 Don’T use Hadoop ainda está no ponto. Se você tem menos de 5TB de dados, Iniciar pequeno. Isto vai poupar-lhe dores de cabeça operacionais com sistemas de manutenção que ainda não precisa. Mas hey, se você gosta de exercícios de fogo 3am de falhas de trabalho, Sinta-se à vontade para pular esta seção…

caso contrário, fique longe de todas as tecnologias buzzword no início, e se concentrar em duas coisas: (1) Fazer seus dados queryable em SQL, e (2) escolher uma ferramenta BI. Estes serão a espinha dorsal “Olá, mundo” para toda a sua infra-estrutura de dados futuros.

tudo em SQL

isto é realmente importante, porque desbloqueia dados para toda a organização. Com raras exceções para as pessoas de marketing mais intrépidas, você nunca vai convencer seus colegas não-técnicos a aprender Kibana, grep alguns logs, ou para usar a sintaxe Obscura de seu datastore NoSQL.

fornecer acesso SQL permite que toda a empresa se torne analistas de auto-serviço, tirando sua equipe de engenharia já esticada do caminho crítico. Ele também transforma todos em uma equipe de perguntas e Respostas grátis para seus dados. O “EI, esses números parecem meio estranhos …” é inestimável para encontrar bugs em seus dados e até mesmo em seu produto.Se o seu datastore primário é uma base de dados relacional como PostgreSQL ou MySQL, isto é muito simples. Você pode apenas configurar uma réplica de leitura, acesso de provisão, e você está pronto.

com uma base de dados NoSQL como ElasticSearch, MongoDB, ou DynamoDB, você precisará fazer mais trabalho para converter seus dados e colocá-los em uma base de dados SQL. Se você é novo no mundo dos dados, chamamos isso de um oleoduto ETL. Evite construir isso você mesmo, se possível, como a fiação de uma solução off-the-shelf será muito menos caro com pequenos volumes de dados. Dependendo de sua infra-estrutura existente, pode haver um provedor de ETL em nuvem como segmento que você pode alavancar.

se você achar que você precisa construir seus próprios oleodutos de dados, mantenha-os extremamente simples no início. Escreva um script para enviar periodicamente atualizações da sua base de dados e escreva-as em algum lugar queryable com SQL.

a história para dados de fontes de terceiros é semelhante à das bases de dados NoSQL. Use um provedor ETL-as-a-service ou escreva um script simples e apenas deposite seus dados em uma base de dados SQL-queryable.

Configure uma máquina para executar o(s) SEU (s) Script (s) ETL como um cron diário, e você está fora para as corridas.

ferramenta BI

uma boa ferramenta BI é uma parte importante da compreensão dos seus dados. Algumas grandes ferramentas a considerar são Chartio, Mode Analytics, e dados Periscópicos — qualquer um destes deve funcionar muito bem para tirar suas analíticas do chão. Na maioria dos casos, você pode apontar essas ferramentas diretamente em seu banco de dados SQL com uma configuração rápida e mergulhar diretamente na criação de painéis.Aqui está o “Olá, Mundo” da infra-estrutura de dados.:

Fase 1: “Olá, Mundo” pequeno pipeline de dados

Fase 2: Vamos chamá-lo de “médio” de dados

neste ponto, você tem mais do que alguns terabytes flutuando, e o cron+script de ETL não é bastante para se manter actualizado. Talvez tenhas proliferado datastores e uma mistura heterogénea de infra-estruturas SQL e NoSQL. Você também pode agora ter um punhado de terceiros de quem você está coletando dados. Finalmente, você pode estar começando a ter vários estágios em seus oleodutos ETL com algumas dependências entre os passos.

gestão do fluxo de trabalho & Automação

o seu primeiro passo nesta fase deve ser a criação de fluxo de ar para gerir os seus oleodutos ETL. O fluxo de ar lhe permitirá agendar trabalhos em intervalos regulares e expressar dependências temporais e lógicas entre trabalhos. É também um grande lugar em sua infra-estrutura para adicionar tentativas de trabalho, monitorando & alertando para falhas de Tarefas. É uma piada em execução que cada startup acima de um determinado tamanho escreve o seu próprio gestor de fluxo de trabalho / programador de trabalho. Entre outros, Spotify escreveu Luigi, e Pinterest escreveu Pinball. No entanto, estes têm menos dinamismo na comunidade e carecem de algumas características no que diz respeito ao fluxo de ar.

construção de condutas ETL

à medida que a sua empresa cresce, os seus requisitos de condutas ETL irão mudar significativamente. Você vai precisar começar a construir uma infra-estrutura mais escalável, porque um único script não vai cortá-lo mais. Seus objetivos também são susceptíveis de se expandir a partir de simplesmente permitir o acesso SQL para abranger o apoio a outros empregos a jusante que processam os mesmos dados.

eventualmente, a simples condutas não escala

Para abordar essas necessidades de mudanças, você vai querer converter seu ETL scripts para executar como um trabalho distribuído em um cluster. O número de soluções possíveis é absolutamente esmagador. Recomendo vivamente que comece com o Apache Spark. Spark tem uma comunidade enorme, muito ativa, balança bem, e é bastante fácil de se levantar e correr rapidamente. Na AWS, você pode executar Spark usando EMR; para GCP, usando Dataproc em nuvem. Se estiver a ingerir dados de uma base de dados relacional, o Apache Sqoop é basicamente o padrão.

neste ponto, a sua infra-estrutura ETL vai começar a parecer estágios pipelinados de trabalhos que implementam os três verbos ETL: extrair dados de fontes, transformar esses dados em formatos padronizados de armazenamento persistente, e carregá-lo em um datastore SQL-queryable.

Data Warehouse

nesta fase, obter todos os seus dados em SQL continuará a ser uma prioridade, mas este é o momento em que você vai querer começar a construir um “real” data warehouse.

para aqueles que estão apenas começando, eu recomendaria usar BigQuery. BigQuery é fácil de configurar (você pode apenas carregar registros como JSON), suporta tipos de dados aninhados/complexos, e é totalmente gerenciado/sem servidor para que você não tenha mais infra-estrutura para manter. Como acontece com muitas das recomendações aqui, alternativas ao BigQuery estão disponíveis: on AWS, Redshift, e on-prem, Presto. Eu tenho uma forte preferência por BigQuery sobre Redshift devido ao seu design sem Server, simplicidade de configurar a segurança/auditoria adequada, e suporte para tipos complexos. Presto vale a pena considerar se você tem uma exigência difícil para on-prem.Ao pensar em criar o seu armazém de dados, um padrão conveniente é adotar um modelo de 2 estágios, onde os dados não processados são desembarcados diretamente em um conjunto de tabelas, e um segundo trabalho pós-processa esses dados em tabelas “mais limpas”.

trate estas tabelas mais limpas como uma oportunidade para criar uma visão curada para o seu negócio. Para cada uma das entidades chave do seu negócio, deve criar e gerir uma tabela com todas as métricas/KPIs e dimensões que utiliza frequentemente para analisar essa entidade. Por exemplo, uma tabela de” usuários ” pode conter métricas como tempo de inscrição, número de compras e dimensões como localização geográfica ou canal de aquisição.

No final de tudo isso, sua infra-estrutura deve ser algo como isto:

Fase 2: o “médio” data pipeline

🚀 Fase 3: Indo grande

com as fundações certas, um maior crescimento não precisa ser doloroso. Você pode muitas vezes fazer isso simplesmente jogando hardware para o problema de lidar com o aumento dos volumes de dados.

os problemas mais desafiadores neste período são muitas vezes não apenas a escala bruta, mas necessidades em expansão. Por exemplo, talvez você precise apoiar testes A/B, modelos de aprendizagem de máquinas de trem, ou pipe transformou dados em um cluster ElasticSearch.

algumas coisas que poderá querer considerar nesta fase:

  • quase em tempo real: Você provavelmente não vai precisar de uma fila distribuída ou infra-estrutura em tempo quase real até muito mais tarde do que você poderia pensar. Ele vem com um monte de complexidade adicional para lidar com todos os modos de falha possíveis, o que não vale a pena no início. Uma vez que o cálculo ROI faz sentido, tente Kafka ou nuvem Pub/Sub.
  • escalabilidade: com um único aglomerado monolítico de faísca, você quase certamente vai se deparar com problemas com a contenção de recursos. Quando o fizer, vale a pena explorar aglomerados de faíscas totalmente elásticos.
  • Segurança & Auditoria: Em algum momento você pode querer impor mais controles de acesso granular para os seus dados de armazenamento de dados. Se você usar BigQuery, você pode fornecer acesso de conjunto de dados para grupos do Google, e gerenciar programaticamente esse acesso usando o Gerenciador de implantação. BigQuery também fornece logs de auditoria para entender as consultas do Usuário. Outras ferramentas como Apache Knox e Apache Sentinel estão disponíveis para soluções de segurança on-prem.
  • A/B Testing: para construir em casa A/B testing e apoiar a experimentação, infelizmente não existem muitas soluções fora da prateleira. Construir um oleoduto de Trabalhos de faísca que povoam tabelas em seu armazém de dados é provavelmente a sua melhor aposta.
  • aprendizagem de máquinas: para a extração de recursos, você pode construir pipelines de dados adicionais em faísca. Para os próprios modelos, você deve começar de novo pequeno. Suas características processadas são provavelmente pequenas o suficiente para caber em uma máquina, então você pode treinar modelos usando scikit-learn ou TensorFlow. Quando uma máquina já não é suficiente, você pode usar faísca MLlib ou TensorFlow distribuído.

o futuro

é emocionante ver o quanto o ecossistema da infra-estrutura de dados melhorou na última década. Nós percorremos um longo caminho desde babysitting Hadoop clusters e ginástica para coagir nossa lógica de processamento de dados em mapas e reduz em Java constrangedor. Naquela época, construir uma infra-estrutura de dados era como tentar construir um arranha-céus usando um martelo de brinquedo.

hoje, temos uma incrível diversidade de ferramentas. A Spark dominou claramente a substituição do jack-of-all-trades por Hadoop MapReduce.; o mesmo está começando a acontecer com o TensorFlow como uma plataforma de aprendizagem de máquina. Com poucas exceções, você não precisa construir infra-estrutura ou ferramentas a partir do zero em casa hoje em dia, e você provavelmente não precisa gerenciar servidores físicos. O arranha-céus já está lá, basta escolher as cores da tinta.

o serverless futuro ele vai ser totalmente assim

Olhando para o futuro, eu espero que a infra-estrutura de dados e as ferramentas para continuar se movendo em direção totalmente sem servidor plataformas — DataBricks acaba de anunciar a tal oferta por Centelha. A infra-estrutura Serverless permite uma elegante separação de preocupações: os provedores de nuvem podem se preocupar com o hardware, devops e ferramentas, permitindo que os engenheiros se concentrem nos problemas que são únicos (e alinhados com) seus negócios. O futuro é um sem falhas de hardware, freakeeper freakouts, ou problemas com a contenção de recursos de fios, e isso é muito legal.

Edite: adicionando links para algumas publicações anteriores que escrevi sobre a infra-estrutura de dados do Thumbtack:

Deixe uma resposta

O seu endereço de email não será publicado.

lg