Não é à toa que colegas mais experientes, com suas cabeças repletas de bugs e disso já grisalhos, contemplam a implantação incrivelmente rápida de pacotes de "containers" em "cubos" em dezenas de servidores em "linguagens da moda" com suporte embutido para E / S não bloqueadoras assíncronas - sorria modestamente ... E eles silenciosamente continuam a reler "man ps", mergulhar no código-fonte de "nginx" até sangrar de seus olhos e testes de unidade de escrita-escrita-escrita. Os colegas sabem que o mais interessante virá, quando “tudo isso” uma noite se tornar aposta na passagem de ano. E apenas uma compreensão profunda da natureza do Unix, uma tabela de estados TCP / IP aprendida e algoritmos básicos de busca de classificação irão ajudá-los. Para trazer o sistema de volta à vida sob os sinos.
Ah, sim, estava um pouco distraído, mas espero ter conseguido transmitir o estado de expectativa.
Hoje, quero compartilhar nossa experiência de implantação de uma pilha conveniente e barata para DataLake, que resolve a maioria das tarefas analíticas em uma empresa para divisões estruturais completamente diferentes.
Há algum tempo, entendemos que a empresa precisa cada vez mais dos frutos da análise técnica e do produto (sem falar da cereja do bolo na forma de aprendizado de máquina) e de entender tendências e riscos - cada vez mais precisa ser coletado e analisado. mais métricas.
Análise técnica básica em Bitrix24
Vários anos atrás, simultaneamente com o lançamento do serviço Bitrix24, investimos ativamente tempo e recursos na criação de uma plataforma analítica simples e confiável que nos ajudaria a ver rapidamente os problemas de infraestrutura e planejar a próxima etapa. Claro, era desejável pegar as ferramentas prontas e o mais simples e compreensíveis possível. Como resultado, nagios foi escolhido para monitoramento e munin para análises e visualização. Agora temos milhares de verificações no nagios, centenas de gráficos no munin e colegas todos os dias e os usamos com sucesso. As métricas são claras, os gráficos são claros, o sistema tem funcionado de forma confiável por vários anos e novos testes e gráficos são regularmente adicionados a ele: colocamos um novo serviço em operação - adicionamos vários testes e gráficos. Boa sorte.
Mão no pulso - análises técnicas avançadas
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 em pacotes UDP estatísticas sobre a velocidade de partes de páginas web em PHP e foi possível 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 respondê-los. E o xhprof no modo automático permitiu coletar gráficos de execução das páginas PHP mais lentas dos clientes e analisar o que poderia levar a isso - calmamente, servindo chá ou algo mais forte.
Algum tempo atrás, o kit de ferramentas foi complementado com outro mecanismo bastante simples e direto baseado no algoritmo de indexação reversa, perfeitamente implementado na lendária biblioteca Lucene - Elastic / Kibana. A ideia simples de gravação multiencadeada de documentos no índice inverso Lucene com base em eventos nos logs e pesquisa rápida através deles usando divisão facetada acabou sendo muito útil.
Apesar do tipo bastante técnico de visualizações em Kibana, com conceitos de baixo nível "fluindo" como "balde" e a linguagem recém-inventada de álgebra relacional ainda não 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 conserte rapidamente.
- - 24 , /?
- ( C PHP), ? segfaults?
- PHP? : «out of memory»? .
Aqui está um exemplo concreto. Apesar do teste completo e multinível, o cliente, com um caso muito fora do padrão e dados de entrada corrompidos, teve um erro irritante e inesperado, uma sirene soou e o processo de sua rápida correção começou:
Além disso, o kibana permite que você organize notificações de eventos especificados e em pouco tempo se torna uma ferramenta na empresa usa dezenas de funcionários de diferentes departamentos - de suporte técnico e desenvolvimento ao controle de qualidade.
A atividade de qualquer divisão dentro da empresa tornou-se conveniente rastrear e medir - ao invés da análise manual dos logs nos servidores, basta configurar a análise dos logs e enviá-los uma vez ao cluster elástico, para desfrutar, por exemplo, contemplando no painel kibana a quantidade de gatinhos bicabeçados vendidos impressos em 3-d impressora durante o último mês lunar.
Business Intelligence Básico
Todo mundo sabe que a inteligência de negócios nas empresas geralmente começa com o uso extremamente ativo, sim, sim, Excel. Mas, o principal é que não acaba aí. O Cloud Google Analytics adiciona lenha à fogueira - você se acostuma rapidamente com coisas boas.
Em nossa empresa em desenvolvimento harmonioso, “profetas” de um trabalho mais intensivo com dados maiores começaram a aparecer aqui e ali. A necessidade de relatórios mais profundos e multifacetados começou a aparecer regularmente e, graças aos esforços de caras de diferentes departamentos, uma solução simples e prática foi organizada há algum tempo - uma combinação de ClickHouse e PowerBI.
Por muito tempo, essa solução flexível ajudou muito, mas aos poucos foi começando a compreender que o ClickHouse não é borracha e não pode ser ridicularizado dessa forma.
Aqui é importante entender bem que ClickHouse, como Druid, como Vertica, como Amazon RedShift (que é baseado em postgres), são mecanismos analíticos otimizados para análises bastante convenientes (somas, agregações, mínimo-máximo por coluna e um pouco de junções ), Porque são organizados para armazenar colunas de maneira eficiente em tabelas relacionais, ao contrário do MySQL e de outros bancos de dados (orientados a linhas) que conhecemos.
Na verdade, ClickHouse é apenas um "banco de dados" de dados mais amplo, com inserção de pontos não muito conveniente (como pretendido, está tudo bem), mas análises interessantes e um conjunto de funções poderosas interessantes para trabalhar com dados. Sim, você pode até criar um cluster - mas você entende que martelar pregos com um microscópio não é totalmente correto, e começamos a procurar outras soluções.
A demanda por python e analistas
Muitos desenvolvedores em nossa empresa escrevem código quase todos os dias por 10-20 anos em PHP, JavaScript, C #, C / C ++, Java, Go, Rust, Python, Bash. Existem também muitos administradores de sistema experientes que sobreviveram a mais de um desastre absolutamente incrível que não se encaixa nas leis das estatísticas (por exemplo, quando a maioria dos discos no raid-10 são destruídos por um forte raio). Nessas condições, por muito tempo não ficou claro o que é um "analista python". Python é como PHP, apenas o nome é um pouco mais longo e os traços das substâncias que alteram a mente são ligeiramente menores no código-fonte do interpretador. No entanto, à medida que mais e mais relatórios analíticos estão sendo criados, desenvolvedores experientes estão cada vez mais cientes da importância da especialização restrita em ferramentas como numpy, pandas, matplotlib e seaborn.
O papel decisivo provavelmente foi desempenhado pelo desmaio repentino dos funcionários com a combinação das palavras "regressão logística" e a demonstração de relatórios eficazes sobre grandes dados usando sim, sim, pyspark.
O Apache Spark, seu paradigma funcional, álgebra relacional e recursos impressionaram tanto os desenvolvedores acostumados com o MySQL que a necessidade de fortalecer as fileiras de batalha com analistas experientes ficou clara como o dia.
Outras tentativas do Apache Spark / Hadoop de decolar e o que deu errado
No entanto, logo ficou claro que com o Spark, aparentemente, algo não está certo sistematicamente, ou você só precisa lavar melhor as mãos. Se a pilha Hadoop / MapReduce / Lucene foi feita por programadores bastante experientes, o que é óbvio se você olhar o código-fonte em Java ou as ideias de Doug Cutting em Lucene com paixão, então Spark, de repente, é escrito de uma forma muito controversa do ponto de vista da praticidade e agora não está desenvolvendo a linguagem exótica Scala. E a queda regular nos cálculos no cluster Spark devido ao trabalho ilógico e não muito transparente de alocação de memória para operações de redução (muitas chaves chegam de uma vez) - criou um halo de algo ao redor dele 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 jar-dependências - o que causava aos administradores de sistema um e conhecido sentimento desde a infância: ódio feroz (ou talvez fosse necessário lavar as mãos com água e 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 outros e assim por diante). Apesar do fato de que com o tempo aprendemos a cozinhar e monitorar bem "isso" e "isso" praticamente parou de cair repentinamente devido à mudança na natureza dos dados e ao desequilíbrio do hashing RDD uniforme, o desejo de levar algo pronto, atualizado e administrado em algum lugar em a nuvem ficou cada vez mais forte. Foi nessa época que tentamos usar um assembly já pronto e baseado em nuvem do Amazon Web Services - EMR e, posteriormente, tentamos resolver os problemas já existentes nele. EMR é um Apache Spark preparado pela Amazon com software adicional do ecossistema, semelhante às compilações Cloudera / Hortonworks.
Armazenamento de arquivos de borracha para análises - uma necessidade urgente
A experiência de "cozinhar" Hadoop / Spark com queimaduras em várias partes do corpo não foi em vão. A necessidade de criar um armazenamento de arquivos único, barato e confiável que seja resistente a falhas de hardware e no qual seja possível armazenar arquivos em diferentes formatos de sistemas diferentes e no qual seja possível fazer seleções eficientes e oportunas para relatórios a partir desses dados começou a emergir cada vez mais claramente.
Eu também queria que a atualização de software desta plataforma não se transformasse em um pesadelo de Ano Novo com a leitura de rastreamentos Java de 20 páginas e análise de logs de cluster detalhados de quilômetros de extensão usando o Spark History Server e uma lupa iluminada. Eu queria ter uma ferramenta simples e transparente que não exigisse mergulho regular sob o capô, se o desenvolvedor parasse de executar a solicitação MapReduce padrão quando o trabalhador de redução de dados perdesse a memória com um algoritmo de particionamento mal escolhido para os dados iniciais.
Amazon S3 é um candidato a DataLake?
A experiência com Hadoop / MapReduce ensinou que você precisa de um sistema de arquivos escalonável e confiável e trabalhadores escalonáveis acima dele, "chegando" mais perto dos dados, para não direcionar os dados pela rede. Os trabalhadores devem ser capazes de ler dados em diferentes formatos, mas, preferencialmente, não ler informações desnecessárias e para que os dados possam ser armazenados com antecedência em formatos convenientes para os trabalhadores.
Mais uma vez, a ideia principal.Não há desejo de "fazer upload" de big data em um único mecanismo analítico de cluster, que mais cedo ou mais tarde se afogará e terá de ser um fragmento feio. Eu gostaria de armazenar arquivos, apenas arquivos, em um formato compreensível e realizar consultas analíticas eficazes sobre eles com ferramentas diferentes, mas compreensíveis. E haverá cada vez mais arquivos em diferentes formatos. E é melhor fragmentar não o mecanismo, mas os dados iniciais. Precisamos de um DataLake expansível e versátil, decidimos ...
E se armazenarmos arquivos no conhecido e conhecido armazenamento em nuvem escalonável do Amazon S3 sem ter que fazer nossos próprios recursos do Hadoop?
É claro que os dados são "inferiores", mas outros dados se você retirá-los e "conduzi-los com eficácia"?
Ecossistema de cluster-bigdata-analytic da Amazon Web Services - em palavras muito simples
A julgar por nossa experiência com AWS, ele foi usado ativamente por um longo tempo sob vários molhos Apache Hadoop / MapReduce, por exemplo, no serviço DataPipeline (tenho inveja de meus colegas, eles aprenderam a cozinhá-lo corretamente). Aqui, configuramos backups de diferentes serviços de tabelas do DynamoDB:
E eles têm sido executados regularmente nos clusters integrados do Hadoop / MapReduce como um relógio por vários anos. Configure e esqueça:
você também pode se envolver efetivamente no datasatanism levantando laptops Jupiter para analistas na nuvem e usando o AWS SageMaker para treinar e implantar modelos de IA na batalha. É assim que se parece conosco:
E sim, você pode pegar um laptop na nuvem para você ou análises e anexá-lo ao cluster Hadoop / Spark, calcular e, em seguida, "pregar" tudo:
Muito 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, vai funcionar? Naquele momento estávamos à beira da esperança e do desespero e continuamos nossa busca.
AWS Glue - Apache Spark perfeitamente 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 executa o serviço “Catálogo de dados”, que não esconde sua compatibilidade com o formato Apache Hive. Neste serviço, você precisa adicionar informações 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 não é isso nesse post. Veja como o diretório de dados DataLake é organizado aqui:
Os arquivos estão registrados, ótimo. Se os arquivos foram atualizados, nós lançamos manualmente ou de acordo com uma programação por crawlers, que irão atualizar as informações sobre eles do lago e salvá-los. Além disso, os dados do lago podem ser processados e os resultados podem ser descarregados em algum lugar. No caso mais simples, também fazemos upload para s3. O processamento de dados pode ser feito em qualquer lugar, mas sugere-se configurar o processamento em um cluster Apache Spark usando recursos avançados por meio da API AWS Glue. Na verdade, você pode pegar o bom e velho código Python usando a biblioteca pyspark e configurá-lo para ser executado em N nós de um cluster de alguma capacidade com monitoramento, sem cavar nos miúdos do Hadoop e arrastar contêineres docker-mocker e eliminar conflitos de dependência.
Mais uma vez, uma ideia simples.Você não precisa configurar o Apache Spark, você só precisa escrever o código python para pyspark, testá-lo localmente no desktop e depois executá-lo em um grande cluster na nuvem, indicando onde estão os dados de origem e onde colocar o resultado. Às vezes é necessário e útil, e é assim que é configurado conosco:
Assim, se você precisa calcular algo no cluster Spark sobre os dados em s3 - escreva o código em python / pyspark, teste-o e faça uma boa viagem para a nuvem.
E a orquestração? E se a tarefa caísse e desaparecesse? Sim, é proposto fazer um belo pipeline no estilo do Apache Pig e até experimentamos, mas decidimos usar nossa orquestração profundamente customizada em PHP e JavaScript por enquanto (eu entendo, há uma dissonância cognitiva, mas funciona há anos e sem erros).
O formato de arquivo Lake é a chave para o desempenho
É muito importante compreender mais dois pontos-chave. Para que as solicitações de dados de arquivos no lago sejam executadas o mais rápido possível e o desempenho não seja degradado quando novas informações são adicionadas, você precisa:
- Armazene as colunas do arquivo 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 arquivos por papais no espírito: idioma, ano, mês, dia, semana. Os motores que entendem esse tipo de fragmentação olharão apenas para os daddies certos, sem passar todos os dados por eles mesmos.
Na verdade, dessa forma, você organiza da forma mais eficiente os dados iniciais para os mecanismos analíticos que estão suspensos no topo, que podem entrar seletivamente em shard daddies e ler apenas as colunas necessárias dos arquivos. Não há necessidade de ir a lugar nenhum, ele acabará por "preencher" os dados (o armazenamento simplesmente explodirá) - basta colocá-lo de maneira sensata no sistema de arquivos no formato correto imediatamente. Claro, deve ficar claro aqui que não é muito aconselhável armazenar um arquivo csv enorme no DataLake, que deve primeiro ser lido pelo cluster linha por linha para extrair as colunas. Pense nos dois pontos acima novamente, se ainda não estiver claro o porquê de tudo isso.
AWS Athena - "inferno" fora da caixa de rapé
E então, enquanto criamos o lago, nós, de alguma forma de passagem, tropeçamos na Amazon Athena. De repente, descobriu-se que dobrando ordenadamente nossos enormes arquivos de log por shards-daddies no formato colunar correto (parquet), você pode fazer seleções extremamente informativas sobre eles e criar relatórios SEM, sem o cluster Apache Spark / Glue.
O motor de dados s3 Athena é baseado no lendário Presto , um membro da família MPP (processamento paralelo massivo) de abordagens de processamento de dados, levando os dados onde eles estão, de s3 e Hadoop a Cassandra e arquivos de texto simples. Você só precisa pedir a Athena para executar a consulta SQL, e então tudo "funciona rapidamente e por si só". É importante notar que Athena é "inteligente", vai apenas para os sharded daddies necessários e lê apenas as colunas necessárias na solicitação.
As solicitações de faturamento para o Athena também são interessantes. Pagamos pela quantidade de dados digitalizados . Essa. 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 atender à solicitação.
E, solicitando apenas as colunas necessárias de papais devidamente fragmentados, descobrimos que o serviço de Atenas nos custa dezenas de dólares por mês. Bem, ótimo, quase gratuito, em comparação com análises em clusters!
A propósito, é assim que 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 à Athena e rapidamente, em segundos, receber respostas úteis do “grande” dados por períodos bastante longos: meses, meio ano, etc.
Mas fomos além e começamos a ir para a nuvem para obter respostas por meio de um driver ODBC : um analista escreve uma consulta SQL em um console familiar, que, em 100-500 máquinas, "por um centavo" dados lentos em s3 e retorna uma resposta geralmente em alguns segundos. Convenientemente. E rápido. Ainda não consigo acreditar.
Como resultado, tendo tomado a decisão de armazenar dados em s3, em um formato colunar eficiente e com fragmentação de dados razoável por daddies ... nós temos o DataLake e um mecanismo analítico rápido e barato - de graça. E ele se tornou muito popular com a empresa porque entende SQL e executa ordens de magnitude mais rápido do que iniciar / parar / configurar clusters. "E se o resultado for o mesmo, por que pagar mais?"
O pedido de Atena se parece com isso. Se desejar, é claro, você pode formar o suficienteconsulta SQL complexa e de várias páginas , mas nos limitaremos a agrupamentos simples. Vamos ver quais códigos de resposta o cliente tinha algumas semanas atrás nos logs do servidor web e ter certeza de que não há erros:
conclusões
Tendo percorrido, para não dizer que seja um caminho longo, mas doloroso, avaliando constantemente de forma adequada os riscos e o nível de complexidade e custo de suporte, encontramos uma solução para DataLake e análise que nunca para de nos agradar com velocidade e custo de propriedade.
Descobriu-se que mesmo desenvolvedores experientes que nunca trabalharam como arquitetos e não podem desenhar quadrados em quadrados com setas e que conhecem 50 termos do ecossistema Hadoop são capazes de construir um DataLake eficiente, rápido e barato para as necessidades de divisões completamente diferentes da empresa.
No início da jornada, minha cabeça estava se partindo do conjunto dos mais selvagens zoológicos 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 complicado e turvo - dê-o aos seus inimigos e concorrentes.
Se você não deseja ir para a nuvem e gosta de manter, atualizar e corrigir projetos de código aberto, pode construir um esquema semelhante ao nosso localmente, em máquinas de escritório de baixo custo com Hadoop e Presto no topo. O principal é não parar e seguir em frente, contar, buscar soluções simples e claras e tudo dará certo! Boa sorte a todos e até breve!