Vivimos nunha época incrible na que podes conectar rápida e facilmente varias ferramentas de código aberto preparadas, configuralas coa túa "conciencia desactivada" segundo o consello de stackoverflow, sen afondar nas "múltiples letras" e lanzar en explotación comercial. E cando necesitas actualizar/expandir ou alguén reinicia accidentalmente un par de máquinas, dás conta de que comezou algún tipo de mal soño obsesivo, todo se complicou drasticamente sen recoñecelo, non hai volta atrás, o futuro é vago e máis seguro. en lugar de programar, criar abellas e facer queixo.
Non por nada os compañeiros máis experimentados, coa cabeza chea de bichos e polo tanto xa grises, contemplan o despregamento incriblemente rápido de paquetes de “contedores” en “cubos” en decenas de servidores en “idiomas de moda” con soporte integrado para E/S asíncrona non bloqueadora, sorría modestamente. E seguen en silencio relendo "man ps", afondando no código fonte "nginx" ata que lles sangran os ollos e escriben, escriben, escriben probas unitarias. Os compañeiros saben que o máis interesante chegará cando un día "todo isto" se aposte pola noite na véspera de Ano Novo. E só se lles axudará cunha comprensión profunda da natureza de Unix, a táboa de estado TCP/IP memorizada e os algoritmos básicos de busca de clasificación. Para devolver a vida ao sistema mentres tocan as badaladas.
Ah, si, distraínme un pouco, pero espero que conseguín transmitir o estado de expectación.
Hoxe quero compartir a nosa experiencia na implantación dunha pila conveniente e barata para DataLake, que resolve a maioría das tarefas analíticas na empresa para divisións estruturais completamente diferentes.
Hai tempo, chegamos á comprensión de que as empresas necesitan cada vez máis os froitos da analítica de produtos e técnicas (por non falar da guinda do pastel en forma de aprendizaxe automática) e para comprender as tendencias e os riscos: necesitamos recoller e analizar cada vez máis métricas.
Analítica técnica básica en Bitrix24
Hai varios anos, ao mesmo tempo co lanzamento do servizo Bitrix24, investimos activamente tempo e recursos na creación dunha plataforma analítica sinxela e fiable que axudase a ver rapidamente os problemas na infraestrutura e a planificar o seguinte paso. Por suposto, era recomendable levar ferramentas xa preparadas que fosen o máis sinxelas e comprensibles posible. Como resultado, escolleuse nagios para o seguimento e munin para a análise e visualización. Agora temos miles de cheques en nagios, centos de gráficos en munin e os nosos colegas utilízanos con éxito todos os días. As métricas son claras, os gráficos son claros, o sistema leva varios anos funcionando de forma fiable e con regularidade engádenselle novas probas e gráficos: cando poñemos en funcionamento un novo servizo, engadimos varias probas e gráficos. Moita sorte.
Finger on the Pulse - Análise técnica avanzada
O desexo de recibir información sobre os problemas "o máis rápido posible" levounos a realizar experimentos activos con ferramentas sinxelas e comprensibles: pinba e xhprof.
Pinba enviounos estatísticas en paquetes UDP sobre a velocidade de funcionamento de partes das páxinas web en PHP, e puidemos ver en liña no almacenamento MySQL (Pinba ven co seu propio motor MySQL para unha rápida análise de eventos) unha pequena lista de problemas e responder a eles. E xhprof permitiunos recoller automaticamente gráficos da execución das páxinas PHP máis lentas dos clientes e analizar o que podería levar a isto: con calma, botando té ou algo máis forte.
Hai tempo, o conxunto de ferramentas foi reabastecido con outro motor bastante sinxelo e comprensible baseado no algoritmo de indexación inversa, perfectamente implementado na lendaria biblioteca de Lucene: Elastic/Kibana. A simple idea de gravar documentos multiproceso nun índice Lucene inverso baseado nos eventos dos rexistros e unha busca rápida a través deles mediante a división de facetas resultou ser realmente útil.
A pesar da aparencia bastante técnica das visualizacións en Kibana con conceptos de baixo nivel como "cubo" "fluíndo cara arriba" e a linguaxe reinventada da álxebra relacional aínda non completamente esquecida, a ferramenta comezou a axudarnos ben nas seguintes tarefas:
- Cantos erros PHP tivo o cliente Bitrix24 no portal p1 na última hora e cales? Comprender, perdoar e corrixir rapidamente.
- Cantas videochamadas se realizaron en portais de Alemaña nas últimas 24 horas, con que calidade e houbo dificultades coa canle/rede?
- Que ben funciona a funcionalidade do sistema (a nosa extensión C para PHP), compilada a partir da fonte na última actualización do servizo e lanzada aos clientes? Hai fallos secundarios?
- Os datos do cliente caben na memoria PHP? Hai algún erro ao exceder a memoria asignada aos procesos: "falta de memoria"? Buscar e neutralizar.
Aquí tes un exemplo concreto. A pesar das probas exhaustivas e de varios niveis, o cliente, cun caso moi non estándar e datos de entrada danados, recibiu un erro molesto e inesperado, soou unha serea e comezou o proceso de arranxalo rapidamente:
Ademais, kibana permítelle organizar notificacións para eventos específicos e, en pouco tempo, a ferramenta na empresa comezou a ser utilizada por decenas de empregados de diferentes departamentos, desde soporte técnico e desenvolvemento ata QA.
A actividade de calquera departamento dentro da empresa fíxose conveniente para rastrexar e medir: en lugar de analizar manualmente os rexistros nos servidores, só tes que configurar os rexistros de análise unha vez e envialos ao clúster elástico para gozar, por exemplo, contemplando na kibana. panel de control o número de gatiños de dúas cabezas vendidos impresos nunha impresora 3D durante o último mes lunar.
Análise empresarial básica
Todo o mundo sabe que a analítica empresarial nas empresas adoita comezar cun uso moi activo de, si, Excel. Pero o principal é que non remata aí. Google Analytics baseado na nube tamén engade combustible ao lume: comezas a acostumarte rapidamente ás cousas boas.
Na nosa empresa en desenvolvemento harmonioso, comezaron a aparecer aquí e alí "profetas" de traballo máis intenso con datos máis grandes. A necesidade de informes máis profundos e multifacéticos comezou a aparecer regularmente e, grazas aos esforzos de rapaces de diferentes departamentos, hai un tempo organizouse unha solución sinxela e práctica: unha combinación de ClickHouse e PowerBI.
Durante bastante tempo, esta solución flexible axudou moito, pero aos poucos comezou a comprenderse que ClickHouse non é de goma e non se pode burlar así.
Aquí é importante entender ben que ClickHouse, como Druid, como Vertica, como Amazon RedShift (que está baseado en postgres), son motores analíticos optimizados para realizar análises bastante convenientes (sumas, agregacións, mínimo-máximo por columna e algunhas combinacións posibles). ), porque organizado para o almacenamento eficiente de columnas de táboas relacionais, a diferenza de MySQL e outras bases de datos (orientadas a filas) coñecidas por nós.
En esencia, ClickHouse é só unha "base de datos" máis ampla, cunha inserción punto por punto non moi cómoda (así se pretende, todo está ben), pero unha análise agradable e un conxunto de funcións poderosas interesantes para traballar con datos. Si, incluso podes crear un racimo, pero entendes que bater cravos cun microscopio non é do todo correcto e comezamos a buscar outras solucións.
Demanda de python e analistas
A nosa empresa ten moitos desenvolvedores que escriben código case todos os días durante 10-20 anos en PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Tamén hai moitos administradores de sistemas experimentados que experimentaron máis dun desastre absolutamente incrible que non encaixa nas leis das estatísticas (por exemplo, cando a maioría dos discos dun raid-10 son destruídos por un forte raio). En tales circunstancias, durante moito tempo non estaba claro o que era un "analista python". Python é como PHP, só o nome é un pouco máis longo e hai un pouco menos de rastros de substancias que alteran a mente no código fonte do intérprete. Non obstante, a medida que se creaban máis e máis informes analíticos, os desenvolvedores experimentados comezaron a comprender cada vez máis a importancia da especialización estreita en ferramentas como numpy, pandas, matplotlib, seaborn.
O papel decisivo, moi probablemente, tivo o desmaio repentino dos empregados pola combinación das palabras "regresión loxística" e a demostración de informes eficaces sobre grandes datos utilizando, si, si, pyspark.
Apache Spark, o seu paradigma funcional no que encaixa á perfección a álxebra relacional e as súas capacidades causaron tal impresión nos desenvolvedores afeitos a MySQL que a necesidade de reforzar as filas con analistas experimentados quedou patente como o día.
Outros intentos de Apache Spark/Hadoop para despegar e o que non foi do todo segundo o guión
Non obstante, pronto quedou claro que algo sistemáticamente non estaba ben con Spark, ou simplemente era necesario lavar mellor as mans. Se a pila de Hadoop/MapReduce/Lucene foi feita por programadores bastante experimentados, o que é obvio se observas atentamente o código fonte en Java ou as ideas de Doug Cutting en Lucene, entón Spark, de súpeto, está escrito na linguaxe exótica Scala, que é moi polémico dende o punto de vista práctico e actualmente non se está a desenvolver. E a caída regular dos cálculos no clúster Spark debido a un traballo ilóxico e pouco transparente coa asignación de memoria para operacións de redución (chegan moitas claves á vez) creou un halo ao seu redor de algo que ten espazo para crecer. Ademais, a situación viuse agravada por unha gran cantidade de estraños portos abertos, ficheiros temporais que medran nos lugares máis incomprensibles e un inferno de dependencias de jar - que fixo que os administradores do sistema tivesen un sentimento que era moi coñecido desde a infancia: o odio feroz (ou quizais necesitaban lavarse as mans con xabón).
Como resultado, "sobrevivimos" a varios proxectos analíticos internos que usan activamente Apache Spark (incluíndo Spark Streaming, Spark SQL) e o ecosistema Hadoop (e así por diante). A pesar de que co paso do tempo aprendemos a preparalo e supervisalo bastante ben, e "el" practicamente deixou de caer de súpeto debido aos cambios na natureza dos datos e ao desequilibrio do hash RDD uniforme, o desexo de tomar algo xa preparado. , actualizado e administrado nalgún lugar da nube fíxose cada vez máis forte. Foi neste momento cando tentamos utilizar o conxunto de nube prefabricado de Amazon Web Services. e, posteriormente, intentou resolver problemas utilizándoo. EMR é Apache Spark preparado por Amazon con software adicional do ecosistema, ao igual que as compilacións de Cloudera/Hortonworks.
O almacenamento de ficheiros de goma para a análise é unha necesidade urxente
A experiencia de "cociñar" Hadoop/Spark con queimaduras en varias partes do corpo non foi en balde. A necesidade de crear un almacenamento de ficheiros único, económico e fiable, que fose resistente aos fallos de hardware e no que fose posible almacenar ficheiros en diferentes formatos de distintos sistemas e facer mostras eficientes e eficientes en tempo para os informes a partir destes datos. claro.
Tamén quería que a actualización do software desta plataforma non se convertera nun pesadelo de ano novo coa lectura de trazos Java de 20 páxinas e a análise de rexistros detallados de quilómetros de lonxitude do clúster usando Spark History Server e unha lupa retroiluminada. Quería ter unha ferramenta sinxela e transparente que non requirise mergullo regularmente baixo o capó se a solicitude estándar MapReduce do programador deixaba de executarse cando o traballador de redución de datos quedou sen memoria debido a un algoritmo de partición de datos fonte non moi ben escollido.
Amazon S3 é un candidato para DataLake?
A experiencia con Hadoop/MapReduce ensinounos que necesitamos un sistema de ficheiros escalable e fiable e ademais traballadores escalables, que "acheguen" aos datos para non dirixir os datos pola rede. Os traballadores deberían poder ler datos en diferentes formatos, pero preferiblemente non ler información innecesaria e poder almacenar datos con antelación en formatos convenientes para os traballadores.
Unha vez máis, a idea básica. Non hai ningún desexo de "verter" grandes datos nun único motor analítico de clúster, que tarde ou cedo se atragantará e terás que esnaquizalo feo. Quero almacenar ficheiros, só ficheiros, nun formato comprensible e realizar consultas analíticas eficaces sobre eles utilizando ferramentas diferentes pero comprensibles. E haberá cada vez máis ficheiros en diferentes formatos. E é mellor fragmentar non o motor, senón os datos de orixe. Necesitamos un DataLake extensible e universal, decidimos...
E se almacenas ficheiros no coñecido e coñecido almacenamento en nube escalable Amazon S3, sen ter que preparar as túas propias chuletas de Hadoop?
Está claro que os datos persoais son "baixos", pero que pasa con outros datos se os sacamos por aí e os "diriximos con eficacia"?
Ecosistema de análise de clusters-bigdata de Amazon Web Services, en palabras moi sinxelas
A xulgar pola nosa experiencia con AWS, Apache Hadoop/MapReduce utilizouse activamente alí durante moito tempo baixo varias salsas, por exemplo no servizo DataPipeline (envexo aos meus compañeiros, aprenderon a preparalo correctamente). Aquí configuramos copias de seguridade de diferentes servizos das táboas de DynamoDB:
E levan xa varios anos funcionando regularmente en clústeres integrados de Hadoop/MapReduce como un reloxo. "Configúrao e esquéceo":
Tamén podes participar de forma eficaz no satanismo de datos configurando portátiles Xúpiter na nube para analistas e usando o servizo AWS SageMaker para adestrar e implementar modelos de IA na batalla. Aquí tes o que nos parece:
E si, podes coller un portátil para ti ou para un analista na nube e anexalo a un clúster de Hadoop/Spark, facer os cálculos e despois aclarar todo:
Realmente cómodo para proxectos analíticos individuais e para algúns utilizamos con éxito o servizo EMR para cálculos e análises a gran escala. E unha solución de sistema para DataLake, funcionará? Neste momento estabamos ao bordo da esperanza e da desesperación e continuamos a procura.
AWS Glue: Apache Spark ben empaquetado con esteroides
Resultou que AWS ten a súa propia versión da pila "Hive/Pig/Spark". O papel de Hive, é dicir. O catálogo de ficheiros e os seus tipos en DataLake realízao o servizo "Catálogo de datos", que non oculta a súa compatibilidade co formato Apache Hive. Debes engadir información a este servizo sobre onde están os teus ficheiros e en que formato están. Os datos poden estar non só en s3, senón tamén na base de datos, pero ese non é o tema desta publicación. Así é como está organizado o noso directorio de datos DataLake:
Os ficheiros están rexistrados, xenial. Se os ficheiros foron actualizados, lanzamos rastrexadores de xeito manual ou programado, que actualizará a información sobre eles desde o lago e gardalos. Despois pódense procesar os datos do lago e cargar os resultados nalgún lugar. No caso máis sinxelo, tamén subimos a s3. O procesamento de datos pódese facer en calquera lugar, pero suxírese que configure o procesamento nun clúster de Apache Spark utilizando capacidades avanzadas a través da API de AWS Glue. De feito, podes levar o bo vello e familiar código Python usando a biblioteca pyspark e configurar a súa execución en N nodos dun clúster de certa capacidade con monitorización, sen cavar nas entrañas de Hadoop e arrastrar contedores docker-moker e eliminar conflitos de dependencia. .
Unha vez máis, unha idea sinxela. Non é necesario configurar Apache Spark, só tes que escribir código python para pyspark, probalo localmente no teu escritorio e executalo nun clúster grande na nube, especificando onde están os datos de orixe e onde colocar o resultado. Ás veces isto é necesario e útil, e así o configuramos:
Así, se necesitas calcular algo nun clúster de Spark usando datos en s3, escribimos código en python/pyspark, probámolo e moita sorte na nube.
E a orquestración? E se a tarefa caese e desaparecese? Si, proponse facer un bonito pipeline ao estilo Apache Pig e ata os probamos, pero de momento decidimos usar a nosa orquestración profundamente personalizada en PHP e JavaScript (entendo, hai disonancia cognitiva, pero funciona, para anos e sen erros).
O formato dos ficheiros almacenados no lago é a clave do rendemento
É moi, moi importante entender dous puntos clave máis. Para que as consultas sobre os datos do ficheiro no lago se executen o máis rápido posible e o rendemento non se degrade cando se engade nova información, cómpre:
- Almacena columnas de ficheiros por separado (para que non teñas que ler todas as liñas para comprender o que hai nas columnas). Para iso tomamos o formato parqué con compresión
- É moi importante dividir os ficheiros en cartafoles como: idioma, ano, mes, día, semana. Os motores que entendan este tipo de fragmentación só mirarán os cartafoles necesarios, sen examinar todos os datos seguidos.
Esencialmente, deste xeito, dispón os datos de orixe na forma máis eficiente para os motores analíticos colgados na parte superior, que mesmo nos cartafoles fragmentados poden introducir e ler de forma selectiva só as columnas necesarias dos ficheiros. Non é necesario "encher" os datos en ningún lugar (o almacenamento simplemente explotará) - simplemente colócao inmediatamente no sistema de ficheiros no formato correcto. Por suposto, aquí debe quedar claro que almacenar un ficheiro csv enorme en DataLake, que primeiro debe ler o clúster liña por liña para extraer as columnas, non é moi recomendable. Volve pensar nos dous puntos anteriores se aínda non está claro por que está a suceder todo isto.
AWS Athena - o Jack-in-the-box
E entón, mentres creabamos un lago, dalgunha maneira atopámonos accidentalmente con Amazon Athena. De súpeto resultou que, organizando coidadosamente os nosos enormes ficheiros de rexistro en fragmentos de cartafoles no formato de columna correcto (parquet), podes facer moi rapidamente seleccións moi informativas a partir deles e crear informes SEN, sen un clúster Apache Spark/Glue.
O motor Athena alimentado por datos en s3 está baseado no lendario - un representante da familia de enfoques do procesamento de datos MPP (procesamento paralelo masivo), tomando os datos onde se atopan, desde s3 e Hadoop ata Cassandra e ficheiros de texto ordinarios. Só ten que pedirlle a Athena que execute unha consulta SQL e, a continuación, todo "funciona de forma rápida e automática". É importante ter en conta que Athena é "intelixente", só vai aos cartafoles fragmentados necesarios e le só as columnas necesarias na solicitude.
O prezo das solicitudes a Athena tamén é interesante. Nós pagamos . Eses. non para o número de máquinas do clúster por minuto, senón... para os datos realmente dixitalizados en máquinas 100-500, só os datos necesarios para completar a solicitude.
E ao solicitar só as columnas necesarias das carpetas correctamente fragmentadas, resultou que o servizo Athena cústanos decenas de dólares ao mes. Ben, xenial, case gratuíto, en comparación coas análises dos clústeres.
Por certo, así é como repartimos os nosos datos en s3:
Como resultado, en pouco tempo, departamentos completamente diferentes da empresa, desde a seguridade da información ata a analítica, comezaron a realizar solicitudes activamente a Athena e, rapidamente, en segundos, recibiron respostas útiles de datos "grandes" durante períodos bastante longos: meses, seis meses, etc. P.
Pero fomos máis aló e comezamos a ir á nube para buscar respostas : un analista escribe unha consulta SQL nunha consola familiar, que en máquinas 100-500 "por centavos" envía datos a s3 e devolve unha resposta normalmente en poucos segundos. Cómodo. E rápido. Aínda non o podo crer.
Como resultado, tendo decidido almacenar os datos en s3, nun formato de columnas eficiente e cunha partición razoable de datos en cartafoles... recibimos DataLake e un motor analítico rápido e barato, de balde. E fíxose moi popular na empresa, porque... comprende SQL e funciona con ordes de magnitude máis rápido que a través do inicio/detención/configuración de clústeres. "E se o resultado é o mesmo, por que pagar máis?"
Unha petición a Atenea parece algo así. Se o desexa, por suposto, pode formar o suficiente , pero limitarémonos a unha simple agrupación. Vexamos que códigos de resposta tiña o cliente hai unhas semanas nos rexistros do servidor web e asegúrese de que non hai erros:
Descubrimentos
Despois de percorrer, por non dicir un camiño longo, pero doloroso, avaliando constantemente de forma adecuada os riscos e o nivel de complexidade e o custo do soporte, atopamos unha solución para DataLake e analítica que non deixa de agradarnos tanto coa velocidade como o custo de propiedade.
Descubriuse que construír un DataLake eficaz, rápido e barato para operar para as necesidades de departamentos completamente diferentes da empresa está completamente dentro das capacidades de desenvolvedores experimentados que nunca traballaron como arquitectos e non saben como debuxar cadrados en cadrados. frechas e coñece 50 termos do ecosistema Hadoop.
Ao comezo da viaxe, a miña cabeza estaba separando os moitos zoolóxicos salvaxes de software aberto e pechado e a comprensión da carga da responsabilidade cos descendentes. Só tes que comezar a construír o teu DataLake a partir de ferramentas sinxelas: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., recollendo comentarios e comprendendo profundamente a física dos procesos que teñen lugar. Todo complexo e turbio: dálle a inimigos e competidores.
Se non queres ir á nube e queres apoiar, actualizar e parchear proxectos de código aberto, podes crear un esquema similar ao noso localmente, en máquinas de oficina económicas con Hadoop e Presto enriba. O principal é non parar e avanzar, contar, buscar solucións sinxelas e claras, ¡e definitivamente todo funcionará! Moita sorte a todos e vémonos de novo!
Fonte: www.habr.com