Vivemos em uma época incrível em que você pode conectar de forma rápida e fácil várias ferramentas de código aberto prontas, configurá-las com sua “consciência desligada” de acordo com o conselho do stackoverflow, sem se aprofundar nas “múltiplas letras” e lançar colocá-los em operação comercial. E quando você precisa atualizar/expandir ou alguém acidentalmente reinicia algumas máquinas - você percebe que algum tipo de pesadelo obsessivo começou na realidade, tudo de repente se tornou mais complicado e irreconhecível, não há como voltar atrás, o futuro é vago e mais seguro, em vez de programar, criar abelhas e fazer queijo.
Não é à toa que colegas mais experientes, com a cabeça repleta de bugs e portanto já cinzentas, contemplam a implantação incrivelmente rápida de pacotes de “contêineres” em “cubos” em dezenas de servidores em “linguagens da moda” com suporte integrado para E/S assíncrona sem bloqueio, sorria modestamente. E eles silenciosamente continuam a reler “man ps”, a mergulhar no código-fonte “nginx” até que seus olhos sangrem e a escrever, escrever, escrever testes de unidade. Os colegas sabem que o mais interessante virá quando “tudo isso” um dia for apostado à noite na véspera de Ano Novo. E eles só serão ajudados por uma compreensão profunda da natureza do Unix, da tabela de estados TCP/IP memorizada e de algoritmos básicos de classificação e pesquisa. Para trazer o sistema de volta à vida quando os sinos soarem.
Ah, sim, me distraí um pouco, mas espero ter conseguido transmitir o estado de expectativa.
Hoje quero compartilhar nossa experiência na implantação de uma pilha conveniente e barata para DataLake, que resolve a maioria das tarefas analíticas da empresa para divisões estruturais completamente diferentes.
Há algum tempo, chegamos à conclusão de que as empresas precisam cada vez mais dos frutos da análise técnica e de produtos (sem falar da cereja do bolo na forma de aprendizado de máquina) e para entender tendências e riscos - precisamos coletar e analisar cada vez mais métricas.
Análise técnica básica no Bitrix24
Há vários anos, simultaneamente ao lançamento do serviço Bitrix24, investimos ativamente tempo e recursos na criação de uma plataforma analítica simples e confiável que ajudaria a identificar rapidamente problemas na infraestrutura e planejar o próximo passo. Claro, era aconselhável levar ferramentas prontas, tão simples e compreensíveis quanto possível. Como resultado, o nagios foi escolhido para monitoramento e o munin para análise e visualização. Agora temos milhares de cheques no nagios, centenas de gráficos no munin, e nossos colegas os utilizam com sucesso todos os dias. As métricas são claras, os gráficos são claros, o sistema funciona de forma confiável há vários anos e regularmente novos testes e gráficos são adicionados a ele: quando colocamos um novo serviço em operação, adicionamos vários testes e gráficos. Boa sorte.
Finger on the Pulse - Análise Técnica Avançada
O desejo de receber informações sobre os problemas “o mais rápido possível” nos levou a experimentos ativos com ferramentas simples e compreensíveis - pinba e xhprof.
Pinba nos enviou estatísticas em pacotes UDP sobre a velocidade de operação de partes de páginas da web em PHP, e pudemos ver online no armazenamento MySQL (Pinba vem com seu próprio mecanismo MySQL para análise rápida de eventos) uma pequena lista de problemas e responder a eles. E o xhprof nos permitiu coletar automaticamente gráficos de execução das páginas PHP mais lentas dos clientes e analisar o que poderia levar a isso - com calma, servindo chá ou algo mais forte.
Há algum tempo, o kit de ferramentas foi reabastecido com outro mecanismo bastante simples e compreensível baseado no algoritmo de indexação reversa, perfeitamente implementado na lendária biblioteca Lucene - Elastic/Kibana. A simples ideia de gravação multithread de documentos em um índice Lucene inverso com base em eventos nos logs e uma busca rápida por eles usando divisão de facetas acabou sendo realmente útil.
Apesar da aparência bastante técnica das visualizações no Kibana com conceitos de baixo nível como “balde” “fluindo para cima” e a linguagem reinventada da álgebra relacional ainda não completamente esquecida, a ferramenta começou a nos ajudar bem nas seguintes tarefas:
- Quantos erros de PHP o cliente Bitrix24 teve no portal p1 na última hora e quais? Entenda, perdoe e corrija rapidamente.
- Quantas videochamadas foram realizadas em portais da Alemanha nas últimas 24 horas, com que qualidade e houve alguma dificuldade com o canal/rede?
- Quão bem funciona a funcionalidade do sistema (nossa extensão C para PHP), compilada a partir do código-fonte na última atualização de serviço e distribuída aos clientes? Existem falhas de segurança?
- Os dados do cliente cabem na memória PHP? Há algum erro sobre exceder a memória alocada para processos: “sem memória”? Encontre e neutralize.
Aqui está um exemplo concreto. Apesar dos testes completos e multiníveis, o cliente, com um caso muito fora do padrão e dados de entrada danificados, recebeu um erro irritante e inesperado, uma sirene soou e o processo de correção rápida começou:
Além disso, o kibana permite organizar notificações para eventos específicos e em pouco tempo a ferramenta na empresa passou a ser utilizada por dezenas de funcionários de diferentes departamentos - desde suporte técnico e desenvolvimento até QA.
A atividade de qualquer departamento da empresa tornou-se conveniente para rastrear e medir - em vez de analisar manualmente os logs nos servidores, basta configurar os logs de análise uma vez e enviá-los para o cluster elástico para desfrutar, por exemplo, contemplando no kibana painel de controle o número de gatinhos de duas cabeças vendidos impressos em impressora 3-D no último mês lunar.
Análise Básica de Negócios
Todo mundo sabe que a análise de negócios nas empresas geralmente começa com o uso extremamente ativo, sim, do Excel. Mas o principal é que não termina aí. O Google Analytics baseado em nuvem também coloca lenha na fogueira - você rapidamente começa a se acostumar com as coisas boas.
Em nossa empresa em desenvolvimento harmonioso, aqui e ali começaram a aparecer “profetas” de trabalho mais intensivo com dados maiores. A necessidade de relatórios mais aprofundados e multifacetados começou a aparecer regularmente, e através do esforço de pessoal de diferentes departamentos, há algum tempo foi organizada uma solução simples e prática - uma combinação de ClickHouse e PowerBI.
Por muito tempo essa solução flexível ajudou muito, mas aos poucos começou a chegar o entendimento de que ClickHouse não é borracha e não pode ser ridicularizado assim.
Aqui é importante entender bem que ClickHouse, como Druid, como Vertica, como Amazon RedShift (que é baseado em postgres), são motores analíticos otimizados para análises bastante convenientes (somas, agregações, mínimo-máximo por coluna e algumas junções possíveis ), porque organizado para armazenamento eficiente de colunas de tabelas relacionais, ao contrário do MySQL e de outros bancos de dados (orientados a linhas) que conhecemos.
Em essência, ClickHouse é apenas um “banco de dados” mais espaçoso, com inserção ponto a ponto não muito conveniente (é assim que se pretende, está tudo bem), mas análises agradáveis e um conjunto de funções poderosas e interessantes para trabalhar com dados. Sim, você pode até criar um cluster - mas você entende que martelar pregos com microscópio não é totalmente correto e começamos a buscar outras soluções.
Demanda por python e analistas
Nossa empresa tem muitos desenvolvedores que escrevem código quase todos os dias durante 10 a 20 anos em PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Existem também muitos administradores de sistema experientes que passaram por mais de um desastre absolutamente incrível que não se enquadra nas leis das estatísticas (por exemplo, quando a maioria dos discos em um raid-10 são destruídos por um forte raio). Nessas circunstâncias, durante muito tempo não ficou claro o que era um “analista python”. Python é como PHP, só que o nome é um pouco mais longo e há um pouco menos de vestígios de substâncias que alteram a mente no código-fonte do interpretador. No entanto, à medida que mais e mais relatórios analíticos foram criados, os desenvolvedores experientes começaram a compreender cada vez mais a importância da especialização restrita em ferramentas como numpy, pandas, matplotlib, seaborn.
O papel decisivo, muito provavelmente, foi desempenhado pelo súbito desmaio dos funcionários com a combinação das palavras “regressão logística” e a demonstração de relatórios eficazes sobre grandes volumes de dados usando, sim, sim, pyspark.
Apache Spark, seu paradigma funcional no qual a álgebra relacional se encaixa perfeitamente e seus recursos causaram uma impressão tão grande nos desenvolvedores acostumados com o MySQL que a necessidade de fortalecer as fileiras com analistas experientes tornou-se clara como o dia.
Outras tentativas de decolagem do Apache Spark/Hadoop e o que não saiu de acordo com o script
No entanto, logo ficou claro que algo não estava sistemicamente certo com o Spark ou que era simplesmente necessário lavar melhor as mãos. Se a pilha Hadoop/MapReduce/Lucene foi feita por programadores bastante experientes, o que é óbvio se você olhar atentamente para o código-fonte em Java ou as ideias de Doug Cutting em Lucene, então o Spark, de repente, é escrito na linguagem exótica Scala, que é muito controverso do ponto de vista prático e atualmente não está em desenvolvimento. E a queda regular nos cálculos no cluster Spark devido ao trabalho ilógico e pouco transparente com alocação de memória para operações de redução (muitas chaves chegam ao mesmo tempo) criou um halo em torno dele de algo que tem espaço para crescer. Além disso, a situação foi agravada por um grande número de portas abertas estranhas, arquivos temporários crescendo nos lugares mais incompreensíveis e um inferno de dependências de jars - o que fez com que os administradores de sistema tivessem um sentimento que era bem conhecido desde a infância: ódio feroz (ou talvez precisavam lavar as mãos com sabão).
Como resultado, “sobrevivemos” a vários projetos analíticos internos que usam ativamente o Apache Spark (incluindo Spark Streaming, Spark SQL) e o ecossistema Hadoop (e assim por diante). Apesar do fato de que com o tempo aprendemos a preparar e monitorar “isso” muito bem, e “isso” praticamente parou de travar repentinamente devido a mudanças na natureza dos dados e ao desequilíbrio do hashing RDD uniforme, o desejo de pegar algo já pronto , atualizado e administrado em algum lugar da nuvem ficou cada vez mais forte. Foi nessa época que tentamos usar a montagem em nuvem pronta da Amazon Web Services - e, posteriormente, tentou resolver problemas utilizando-o. EMR é Apache Spark preparado pela Amazon com software adicional do ecossistema, bem como compilações Cloudera/Hortonworks.
O armazenamento de arquivos de borracha para análises é uma necessidade urgente
A experiência de “cozinhar” o Hadoop/Spark com queimaduras em diversas partes do corpo não foi em vão. A necessidade de criar um armazenamento de arquivos único, barato e confiável, que fosse resistente a falhas de hardware e no qual fosse possível armazenar arquivos em diferentes formatos de diferentes sistemas e fazer amostras eficientes e com economia de tempo para relatórios a partir desses dados tornou-se cada vez mais claro.
Eu também queria que a atualização do software desta plataforma não se transformasse em um pesadelo de Ano Novo com a leitura de rastreamentos Java de 20 páginas e a análise de registros detalhados do cluster com quilômetros de extensão usando o Spark History Server e uma lupa retroiluminada. Eu queria ter uma ferramenta simples e transparente que não exigisse mergulhos regulares nos bastidores se a solicitação MapReduce padrão do desenvolvedor parasse de ser executada quando o trabalhador de redução de dados ficasse sem memória devido a um algoritmo de particionamento de dados de origem não muito bem escolhido.
O Amazon S3 é candidato ao DataLake?
A experiência com Hadoop/MapReduce nos ensinou que precisamos de um sistema de arquivos escalonável e confiável e de trabalhadores escalonáveis sobre ele, “chegando” mais perto dos dados para não direcioná-los pela rede. Os trabalhadores devem ser capazes de ler dados em diferentes formatos, mas de preferência não ler informações desnecessárias e ser capazes de armazenar dados antecipadamente em formatos convenientes para os trabalhadores.
Mais uma vez, a ideia básica. Não há desejo de “despejar” big data em um único mecanismo analítico de cluster, que mais cedo ou mais tarde irá engasgar e você terá que fragmentá-lo feio. Quero armazenar arquivos, apenas arquivos, em um formato compreensível e realizar consultas analíticas eficazes sobre eles usando ferramentas diferentes, mas compreensíveis. E haverá cada vez mais arquivos em diferentes formatos. E é melhor fragmentar não o mecanismo, mas os dados de origem. Precisamos de um DataLake extensível e universal, decidimos...
E se você armazenar arquivos no conhecido e conhecido armazenamento em nuvem escalável Amazon S3, sem ter que preparar seus próprios recursos do Hadoop?
É claro que os dados pessoais são “baixos”, mas e os outros dados se os levarmos para fora e “dirigí-los de forma eficaz”?
Ecossistema de análise de bigdata de cluster da Amazon Web Services - em palavras muito simples
A julgar pela nossa experiência com AWS, o Apache Hadoop/MapReduce tem sido usado ativamente há muito tempo sob vários molhos, por exemplo, no serviço DataPipeline (invejo meus colegas, eles aprenderam como prepará-lo corretamente). Aqui configuramos backups de diferentes serviços de tabelas do DynamoDB:
E eles têm sido executados regularmente em clusters Hadoop/MapReduce incorporados como um relógio há vários anos. “Configure e esqueça”:
Você também pode se envolver efetivamente no satanismo de dados configurando laptops Jupiter na nuvem para analistas e usando o serviço AWS SageMaker para treinar e implantar modelos de IA em batalha. Aqui está o que parece para nós:
E sim, você pode pegar um laptop para você ou para um analista na nuvem e conectá-lo a um cluster Hadoop/Spark, fazer os cálculos e então definir tudo:
Realmente conveniente para projetos analíticos individuais e, para alguns, usamos com sucesso o serviço EMR para cálculos e análises em grande escala. Que tal uma solução de sistema para DataLake, funcionará? Neste momento estávamos à beira da esperança e do desespero e continuamos a busca.
AWS Glue - Apache Spark bem embalado com esteróides
Descobriu-se que a AWS tem sua própria versão da pilha “Hive/Pig/Spark”. O papel do Hive, ou seja, O catálogo de arquivos e seus tipos no DataLake é realizado pelo serviço “Catálogo de dados”, que não esconde sua compatibilidade com o formato Apache Hive. Você precisa adicionar informações a este serviço sobre onde seus arquivos estão localizados e em que formato eles estão. Os dados podem estar não só no s3, mas também no banco de dados, mas isso não é assunto deste post. Veja como nosso diretório de dados DataLake está organizado:
Os arquivos estão registrados, ótimo. Se os arquivos foram atualizados, lançamos rastreadores manualmente ou de forma programada, que atualizarão as informações sobre eles do lago e os salvarão. Em seguida, os dados do lago podem ser processados e os resultados carregados em algum lugar. No caso mais simples, também carregamos para s3. O processamento de dados pode ser feito em qualquer lugar, mas sugere-se que você configure o processamento em um cluster Apache Spark usando recursos avançados por meio da API do AWS Glue. Na verdade, você pode pegar o bom e velho e familiar código python usando a biblioteca pyspark e configurar sua execução em N nós de um cluster de alguma capacidade com monitoramento, sem se aprofundar no Hadoop e arrastar contêineres docker-moker e eliminar conflitos de dependência .
Mais uma vez, uma ideia simples. Não há necessidade de configurar o Apache Spark, você só precisa escrever código python para pyspark, testá-lo localmente em seu desktop e depois executá-lo em um grande cluster na nuvem, especificando onde estão os dados de origem e onde colocar o resultado. Às vezes, isso é necessário e útil, e veja como configuramos:
Assim, se você precisar calcular algo em um cluster Spark usando dados em s3, escrevemos código em python/pyspark, testamos e boa sorte para a nuvem.
E a orquestração? E se a tarefa caísse e desaparecesse? Sim, é proposto fazer um lindo pipeline no estilo Apache Pig e até tentamos, mas por enquanto decidimos usar nossa orquestração profundamente customizada em PHP e JavaScript (eu entendo, há dissonância cognitiva, mas funciona, por anos e sem erros).
O formato dos arquivos armazenados no lago é a chave para o desempenho
É muito, muito importante entender mais dois pontos-chave. Para que as consultas nos dados do arquivo no lago sejam executadas o mais rápido possível e o desempenho não seja prejudicado quando novas informações forem adicionadas, você precisa:
- Armazene colunas de arquivos separadamente (para que você não precise ler todas as linhas para entender o que há nas colunas). Para isso pegamos o formato parquet com compressão
- É muito importante fragmentar os arquivos em pastas como: idioma, ano, mês, dia, semana. Os mecanismos que entendem esse tipo de fragmentação examinarão apenas as pastas necessárias, sem examinar todos os dados seguidos.
Essencialmente, desta forma, você organiza os dados de origem da forma mais eficiente para os mecanismos analíticos pendurados no topo, que mesmo em pastas fragmentadas podem inserir e ler seletivamente apenas as colunas necessárias dos arquivos. Você não precisa “preencher” os dados em nenhum lugar (o armazenamento simplesmente estourará) - basta colocá-los imediatamente no sistema de arquivos no formato correto. Claro, deve ficar claro aqui que não é muito aconselhável armazenar um enorme arquivo csv no DataLake, que primeiro deve ser lido linha por linha pelo cluster para extrair as colunas. Pense novamente nos dois pontos acima se ainda não estiver claro por que tudo isso está acontecendo.
AWS Athena – a caixa pronta para uso
E então, ao criar um lago, de alguma forma acidentalmente encontramos o Amazon Athena. De repente, descobriu-se que, ao organizar cuidadosamente nossos enormes arquivos de log em fragmentos de pastas no formato de coluna correto (parquet), você pode rapidamente fazer seleções extremamente informativas a partir deles e criar relatórios SEM, sem um cluster Apache Spark/Glue.
O mecanismo Athena alimentado por dados no s3 é baseado no lendário - um representante da família de abordagens MPP (processamento paralelo massivo) para processamento de dados, levando os dados onde eles estão, de s3 e Hadoop a Cassandra e arquivos de texto comuns. Você só precisa pedir ao Athena para executar uma consulta SQL e então tudo “funcionará de forma rápida e automática”. É importante ressaltar que o Athena é “inteligente”, ele vai apenas até as pastas fragmentadas necessárias e lê apenas as colunas necessárias na solicitação.
O preço das solicitações para Athena também é interessante. Nós pagamos por . Aqueles. não para o número de máquinas no cluster por minuto, mas... para os dados realmente verificados em 100-500 máquinas, apenas os dados necessários para concluir a solicitação.
E ao solicitar apenas as colunas necessárias de pastas fragmentadas corretamente, descobrimos que o serviço Athena nos custa dezenas de dólares por mês. Bem, ótimo, quase grátis, em comparação com análises em clusters!
A propósito, veja como fragmentamos nossos dados no s3:
Como resultado, em pouco tempo, departamentos completamente diferentes da empresa, desde segurança da informação até análise, começaram a fazer solicitações ativamente ao Athena e rapidamente, em segundos, a receber respostas úteis de “big” data por períodos bastante longos: meses, meio ano, etc.
Mas fomos além e começamos a buscar respostas na nuvem : um analista escreve uma consulta SQL em um console familiar, que em 100-500 máquinas “por centavos” envia dados para s3 e geralmente retorna uma resposta em alguns segundos. Confortável. E rápido. Eu ainda não consigo acreditar.
Como resultado, tendo decidido armazenar dados em s3, em um formato colunar eficiente e com fragmentação razoável de dados em pastas... recebemos o DataLake e um mecanismo analítico rápido e barato - de graça. E ele se tornou muito popular na empresa, porque... entende SQL e trabalha muito mais rápido do que iniciar/parar/configurar clusters. “E se o resultado for o mesmo, por que pagar mais?”
Um pedido para Atenas é mais ou menos assim. Se desejar, é claro, você pode formar o suficiente , mas nos limitaremos a agrupamentos simples. Vamos ver quais códigos de resposta o cliente tinha há algumas semanas nos logs do servidor web e ter certeza de que não há erros:
Descobertas
Tendo percorrido um caminho, para não dizer longo, mas doloroso, avaliando constantemente e adequadamente os riscos e o nível de complexidade e custo de suporte, encontramos uma solução para DataLake e análises que nunca deixa de nos agradar tanto com velocidade quanto com custo de propriedade.
Descobriu-se que construir um DataLake eficaz, rápido e barato para operar para as necessidades de departamentos completamente diferentes da empresa está completamente dentro das capacidades até mesmo de desenvolvedores experientes que nunca trabalharam como arquitetos e não sabem como desenhar quadrados em quadrados com setas e conheça 50 termos do ecossistema Hadoop.
No início da jornada, minha cabeça estava dividida entre os muitos zoológicos selvagens de software aberto e fechado e a compreensão do peso da responsabilidade para com os descendentes. Basta começar a construir seu DataLake a partir de ferramentas simples: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., coletando feedback e entendendo profundamente a física dos processos que estão ocorrendo. Tudo complexo e obscuro - entregue aos inimigos e concorrentes.
Se você não quer ir para a nuvem e gosta de oferecer suporte, atualizar e corrigir projetos de código aberto, você pode construir um esquema semelhante ao nosso localmente, em máquinas de escritório baratas com Hadoop e Presto no topo. O principal é não parar e seguir em frente, contar, buscar soluções simples e claras, e com certeza tudo dará certo! Boa sorte a todos e nos vemos novamente!
Fonte: habr.com