No en vano colegas más experimentados, con la cabeza llena de bichos y de este ya canoso, contemplando el despliegue increíblemente rápido de paquetes de "contenedores" en "cubos" en decenas de servidores en "lenguajes de moda" con soporte incorporado para E / S asincrónicas sin bloqueo - sonrisa modesta ... Y silenciosamente continúan releyendo "man ps", profundizando en el código fuente de "nginx" hasta sangrar de sus ojos y pruebas unitarias de escritura-escritura-escritura. Los colegas saben que lo más interesante estará por delante, cuando "todo esto" una noche se convierta en juego en la víspera de Año Nuevo. Y solo una comprensión profunda de la naturaleza de Unix, una tabla de estado TCP / IP aprendida y algoritmos básicos de búsqueda de clasificación les ayudarán. Para devolver la vida al sistema bajo las campanas.
Oh, sí, estaba un poco distraído, pero espero haber logrado transmitir el estado de anticipación.
Hoy quiero compartir nuestra experiencia de implementar una pila conveniente y económica para DataLake, que resuelve la mayoría de las tareas analíticas en una empresa para divisiones estructurales completamente diferentes.
Hace algún tiempo, llegamos a comprender que la empresa necesita cada vez más los frutos de la analítica técnica y de productos (sin mencionar la guinda del pastel en forma de aprendizaje automático) y comprender las tendencias y los riesgos: es necesario recopilar y analizar más y más. más métricas.
Análisis técnico básico en Bitrix24
Hace varios años, simultáneamente con el lanzamiento del servicio Bitrix24, invertimos activamente tiempo y recursos para crear una plataforma analítica simple y confiable que nos ayudaría a ver rápidamente los problemas de infraestructura y planificar el siguiente paso. Por supuesto, era deseable tener las herramientas listas para usar y lo más simples y comprensibles posible. Como resultado, se eligió nagios para monitorear y munin para análisis y visualización. Ahora tenemos miles de comprobaciones en nagios, cientos de gráficos en munin y colegas todos los días y los usamos con éxito. Las métricas son claras, los gráficos son claros, el sistema ha estado funcionando de manera confiable durante varios años y regularmente se le agregan nuevas pruebas y gráficos: ponemos en funcionamiento un nuevo servicio, agregamos varias pruebas y gráficos. Buena suerte.
Hand on the pulse - análisis técnico avanzado
El deseo de recibir información sobre los problemas "lo más rápido posible" nos llevó a realizar experimentos activos con herramientas simples y comprensibles: pinba y xhprof.
Pinba nos envió en paquetes UDP estadísticas sobre la velocidad de partes de las páginas web en PHP y fue posible ver en línea en el almacenamiento MySQL (pinba viene con su propio motor MySQL para análisis rápidos de eventos) una breve lista de problemas y responder a ellos. Y xhprof en modo automático permitió recopilar gráficos de ejecución de las páginas PHP más lentas de los clientes y analizar qué podría conducir a esto: con calma, sirviendo té o algo más fuerte.
Hace algún tiempo, el kit de herramientas se complementó con otro motor bastante simple y directo basado en el algoritmo de indexación inversa, perfectamente implementado en la legendaria biblioteca de Lucene: Elastic / Kibana. La simple idea de escribir documentos con múltiples subprocesos en el índice inverso de Lucene basado en eventos en los registros y buscar rápidamente a través de ellos usando la división por facetas resultó ser realmente útil.
A pesar del tipo bastante técnico de visualizaciones en Kibana con conceptos de bajo nivel "fluidos" como "cubo" y el lenguaje recién inventado del álgebra relacional aún no olvidado, la herramienta comenzó a ayudarnos bien en las siguientes tareas:
- ¿Cuántos errores de PHP tuvo el cliente Bitrix24 en el portal p1 en la última hora y cuáles? Comprenda, perdone y arregle rápidamente.
- - 24 , /?
- ( C PHP), ? segfaults?
- PHP? : «out of memory»? .
He aquí un ejemplo concreto. A pesar de las pruebas exhaustivas y multinivel, el cliente, con un caso muy poco estándar y datos de entrada corruptos, tuvo un error molesto e inesperado, sonó una sirena y comenzó el proceso de su solución rápida:
Además, kibana le permite organizar la notificación de eventos específicos y en poco tiempo se convirtió en una herramienta en la empresa utilice decenas de empleados de diferentes departamentos, desde el soporte técnico y el desarrollo hasta el control de calidad.
Se ha vuelto conveniente monitorear y medir la actividad de cualquier división dentro de la empresa - en lugar de analizar manualmente los registros en los servidores, basta con configurar el análisis de los registros y enviarlos al clúster elástico una vez, para disfrutar, por ejemplo, contemplando en el tablero de kibana el número de gatitos de dos cabezas vendidos impresos en 3D impresora para el último mes lunar.
Inteligencia empresarial básica
Todo el mundo sabe que la inteligencia empresarial en las empresas a menudo comienza con un uso extremadamente activo, sí, sí, Excel. Pero, lo principal es que no acaba ahí. Cloud Google Analytics le da más leña al fuego: te acostumbras rápidamente a las cosas buenas.
En nuestra empresa que se desarrollaba armoniosamente, empezaron a aparecer aquí y allá “profetas” de trabajo más intensivo con datos más grandes. La necesidad de informes más profundos y multifacéticos comenzó a aparecer con regularidad, y gracias a los esfuerzos de personas de diferentes departamentos, hace algún tiempo se organizó una solución simple y práctica: una combinación de ClickHouse y PowerBI.
Durante bastante tiempo, esta solución flexible ayudó mucho, pero gradualmente comenzó a comprender que ClickHouse no es de goma y no se puede burlar de él de esa manera.
Es importante entender bien aquí que ClickHouse, como Druid, como Vertica, como Amazon RedShift (que se basa en postgres), son motores analíticos optimizados para análisis bastante convenientes (sumas, agregaciones, mínimo-máximo para una columna y un poco de uniones ), porque están organizados para almacenar columnas de manera eficiente en tablas relacionales, a diferencia de MySQL y otras bases de datos (orientadas a filas) que conocemos.
De hecho, ClickHouse es simplemente una "base de datos" de datos más amplia, con una inserción de puntos no muy conveniente (como se pretendía, todo está bien), pero con buenos análisis y un conjunto de funciones potentes e interesantes para trabajar con datos. Sí, incluso puede crear un grupo, pero comprende que martillar clavos con un microscopio no es del todo correcto, y comenzamos a buscar otras soluciones.
La demanda de Python y analistas.
Hay muchos desarrolladores en nuestra empresa que escriben código casi todos los días durante 10 a 20 años en PHP, JavaScript, C #, C / C ++, Java, Go, Rust, Python, Bash. También hay muchos administradores de sistemas experimentados que han sobrevivido a más de un desastre absolutamente increíble que no se ajusta a las leyes de las estadísticas (por ejemplo, cuando la mayoría de los discos en raid-10 son destruidos por un fuerte rayo). En tales condiciones, durante mucho tiempo no estuvo claro qué es un "analista de Python". Python es como PHP, solo que el nombre es un poco más largo y los rastros de las sustancias que alteran la mente son un poco más pequeños en el código fuente del intérprete. Sin embargo, a medida que se crean más y más informes analíticos, los desarrolladores experimentados se han vuelto cada vez más conscientes de la importancia de una especialización limitada en herramientas como numpy, pandas, matplotlib, seaborn.
Lo más probable es que el papel decisivo lo haya jugado el repentino desmayo de los empleados por la combinación de las palabras "regresión logística" y la demostración de informes efectivos sobre grandes datos utilizando sí, sí, pyspark.
Apache Spark, su paradigma funcional, álgebra relacional y sus capacidades han dejado tal impresión en los desarrolladores acostumbrados a MySQL que la necesidad de fortalecer las filas de batalla con analistas experimentados se hizo evidente como el día.
Más intentos de Apache Spark / Hadoop de despegar y qué salió mal
Sin embargo, pronto quedó claro que con Spark, aparentemente, algo sistémicamente no está del todo bien, o simplemente necesita lavarse mejor las manos. Si la pila de Hadoop / MapReduce / Lucene fue hecha por programadores bastante experimentados, lo cual es obvio si miras el código fuente en Java o las ideas de Doug Cutting en Lucene con pasión, entonces Spark, de repente, está escrito de una manera muy controvertida desde el punto de vista práctico y ahora no está desarrollando un lenguaje Scala exótico. Y la caída regular en los cálculos en el clúster Spark debido al trabajo ilógico y poco transparente con la asignación de memoria para operaciones de reducción (muchas claves llegan a la vez), creó un halo de algo a su alrededor que tiene espacio para crecer. Además, la situación se vio agravada por una gran cantidad de puertos abiertos extraños, archivos temporales,creciendo en los lugares más incomprensibles y el infierno de las jar-dependencias, lo que provocó en los administradores del sistema un sentimiento muy conocido desde la infancia: un odio feroz (o tal vez era necesario lavarse las manos con agua y jabón).
Como resultado, “sobrevivimos” a varios proyectos analíticos internos utilizando activamente Apache Spark (incluidos Spark Streaming, Spark SQL) y el ecosistema Hadoop (y otros y otros). A pesar de que con el tiempo aprendimos a cocinar y monitorear bien "eso" y "eso" prácticamente dejó de caer repentinamente debido al cambio en la naturaleza de los datos y al desequilibrio del hash uniforme del RDD, el deseo de llevar algo ya hecho, actualizado y administrado en algún lugar de la nube se hizo cada vez más fuerte. Fue en este momento que intentamos utilizar el ensamblaje basado en la nube listo para usar de Amazon Web Services - EMR y, posteriormente, intentamos resolver problemas en él. EMR es un Apache Spark preparado por Amazon con software adicional del ecosistema, similar a las compilaciones de Cloudera / Hortonworks.
Almacenamiento de archivos de caucho para análisis: una necesidad urgente
La experiencia de "cocinar" Hadoop / Spark con quemaduras en varias partes del cuerpo no fue en vano. La necesidad de crear un almacenamiento de archivos único, económico y confiable que fuera resistente a fallas de hardware y en el que fuera posible almacenar archivos en diferentes formatos de diferentes sistemas y en el que fuera posible realizar selecciones eficientes y oportunas para los informes a partir de estos datos comenzó a surgir cada vez con más claridad.
También quería que la actualización de software de esta plataforma no se convirtiera en una pesadilla de Año Nuevo con la lectura de trazos de Java de 20 páginas y el análisis de registros de clúster detallados de un kilómetro de longitud utilizando Spark History Server y una lupa retroiluminada. Quería tener una herramienta simple y transparente que no requiera una inmersión regular bajo el capó, si el desarrollador deja de ejecutar una solicitud MapReduce estándar cuando el trabajador de reducción de datos se queda sin memoria con un algoritmo de partición mal elegido para los datos iniciales.
¿Amazon S3 es un candidato para DataLake?
La experiencia con Hadoop / MapReduce enseñó que necesita un sistema de archivos escalable y confiable y trabajadores escalables por encima de él, "acercándose" a los datos, para no conducir datos a través de la red. Los trabajadores deberían poder leer datos en diferentes formatos, pero, preferiblemente, no leer información innecesaria y de modo que los datos puedan almacenarse por adelantado en formatos convenientes para los trabajadores.
Una vez más, la idea principal.No hay ningún deseo de "cargar" big data en un motor analítico de clúster único, que tarde o temprano se ahogará y tendrá que ser un fragmento feo. Me gustaría almacenar archivos, solo archivos, en un formato comprensible y realizar consultas analíticas efectivas sobre ellos con herramientas diferentes pero comprensibles. Y cada vez habrá más archivos en diferentes formatos. Y es mejor fragmentar no el motor, sino los datos iniciales. Necesitamos un DataLake expandible y versátil, decidimos ...
¿Qué pasa si almacenamos archivos en el conocido y conocido almacenamiento escalable en la nube de Amazon S3 sin tener que hacer nuestras propias decisiones desde Hadoop?
Está claro que los datos están "al final", pero ¿otros datos si los sacas y los "manejas de manera efectiva"?
Cluster-bigdata-analytic ecosistema de Amazon Web Services - en palabras muy simples
A juzgar por nuestra experiencia con AWS, se ha utilizado activamente allí durante mucho tiempo bajo varias salsas Apache Hadoop / MapReduce, por ejemplo, en el servicio DataPipeline (envidio a mis colegas, aprendieron a cocinarlo correctamente). Aquí hemos configurado copias de seguridad de diferentes servicios de las tablas de DynamoDB:
y se han realizado regularmente en los clústeres integrados de Hadoop / MapReduce como un reloj durante varios años.
Configúrelo y olvídelo: también puede participar de manera efectiva en el satanismo de datos al elevar las computadoras portátiles Jupiter para los analistas en la nube y usar AWS SageMaker para entrenar e implementar modelos de IA en la batalla. Así es como se ve con nosotros:
Y sí, puede elegir una computadora portátil en la nube para usted o para análisis y conectarla al clúster de Hadoop / Spark, calcular y luego "clavar" todo:
Realmente conveniente para proyectos analíticos individuales y para algunos hemos utilizado con éxito el servicio EMR para cálculos y análisis a gran escala. ¿Qué pasa con una solución de sistema para DataLake, funcionará? En ese momento estábamos al borde de la esperanza y la desesperación y continuamos nuestra búsqueda.
AWS Glue: Apache Spark cuidadosamente empaquetado "con esteroides"
Resultó que AWS tiene su propia versión de la pila Hive / Pig / Spark. El papel de Hive, es decir el catálogo de archivos y sus tipos en DataLake ejecuta el servicio “Catálogo de datos”, que no oculta su compatibilidad con el formato Apache Hive. En este servicio, debe agregar información sobre dónde se encuentran sus archivos y en qué formato están. Los datos pueden estar no solo en s3, sino también en la base de datos, pero no se trata de eso en esta publicación. Así es como se organiza el directorio de datos de DataLake aquí:
Los archivos están registrados, genial. Si los archivos se han actualizado, los iniciamos manualmente o en un horario por rastreadores, quienes actualizarán la información sobre ellos desde el lago y los guardarán. Además, los datos del lago se pueden procesar y los resultados se pueden descargar en algún lugar. En el caso más simple, también lo subimos a s3. El procesamiento de datos se puede realizar en cualquier lugar, pero se sugiere configurar el procesamiento en un clúster de Apache Spark utilizando capacidades avanzadas a través de la API de AWS Glue. De hecho, puede tomar el viejo y familiar código de Python usando la biblioteca pyspark y configurarlo para que se ejecute en N nodos de un clúster de cierta capacidad con monitoreo, sin excavar en las entrañas de Hadoop y arrastrar contenedores docker-mocker y eliminar conflictos de dependencia.
Una vez más, una idea sencilla.No necesita configurar Apache Spark, solo necesita escribir código Python para pyspark, probarlo localmente en el escritorio y luego ejecutarlo en un clúster grande en la nube, indicando dónde están los datos de origen y dónde poner el resultado. A veces es necesario y útil, y así es como se configura aquí:
Así, si necesitas calcular algo en el clúster Spark sobre los datos en s3, escribimos el código en python / pyspark, lo probamos y tenemos un buen viaje a la nube.
¿Qué pasa con la orquestación? ¿Y si la tarea cayera y desapareciera? Sí, se propone hacer un hermoso pipeline al estilo de Apache Pig e incluso los probamos, pero decidimos usar nuestra orquestación profundamente personalizada en PHP y JavaScript por ahora (entiendo, hay una disonancia cognitiva, pero funciona durante años y sin errores).
El formato de archivo Lake es clave para el rendimiento
Es muy, muy importante comprender dos puntos clave más. Para que las solicitudes de datos de archivos en el lago se ejecuten lo más rápido posible y el rendimiento no se degrade cuando se agrega nueva información, necesita:
- Almacene las columnas del archivo por separado (de modo que no necesite leer todas las líneas para comprender qué hay en las columnas). Para ello, tomamos el formato de parquet con compresión.
- Es muy importante fragmentar los archivos de los papás en el espíritu: idioma, año, mes, día, semana. Los motores que entienden este tipo de fragmentación solo mirarán a los padres adecuados, sin pasar todos los datos por sí mismos.
De hecho, de esta manera, presenta de la forma más eficiente los datos iniciales para los motores analíticos que se cuelgan en la parte superior, que pueden ingresar selectivamente los fragmentos principales y leer solo las columnas necesarias de los archivos. No hay necesidad de ir a ningún lado, resultará que "llenará" los datos (el almacenamiento simplemente explotará), simplemente colóquelo con sensatez en el sistema de archivos en el formato correcto inmediatamente. Por supuesto, debe quedar claro aquí que almacenar un archivo csv enorme en DataLake, que primero debe ser leído por el clúster línea por línea, para extraer las columnas, no es muy recomendable. Piense en los dos puntos anteriores nuevamente si aún no está claro por qué todo esto es así.
AWS Athena - "infierno" fuera de la caja de rapé
Y luego, mientras creábamos el lago, de alguna manera, de pasada, nos topamos con Amazon Athena. De repente, resultó que al plegar cuidadosamente nuestros enormes archivos de registro por shards-daddies en el formato de columna correcto (parquet), puede hacer selecciones extremadamente informativas sobre ellos y generar informes SIN, sin el clúster Apache Spark / Glue.
El motor de datos Athena s3 se basa en el legendario Presto , un miembro de la familia de enfoques de procesamiento de datos MPP (procesamiento paralelo masivo), que lleva los datos donde se encuentran, desde s3 y Hadoop hasta Cassandra y archivos de texto sin formato. Solo necesita pedirle a Athena que ejecute la consulta SQL, y luego todo "funcionará rápidamente y por sí solo". Es importante tener en cuenta que Athena es "inteligente", va solo a los papás fragmentados necesarios y lee solo las columnas necesarias en la solicitud.
Las solicitudes a Atenea también se cobran de manera interesante. Pagamos por la cantidad de datos escaneados . Aquellos. no por la cantidad de máquinas en el clúster por minuto, sino ... por los datos realmente escaneados en 100-500 máquinas, solo los datos necesarios para cumplir con la solicitud.
Y al solicitar solo las columnas necesarias de los papás debidamente fragmentados, resultó que el servicio de Athena nos cuesta decenas de dólares al mes. Bueno, genial, casi gratis, en comparación con el análisis en clústeres.
Por cierto, así es como compartimos nuestros datos en s3:
como resultado, en poco tiempo, departamentos completamente diferentes de la empresa, desde seguridad de la información hasta análisis, comenzaron a realizar solicitudes activamente a Athena y rápidamente, en segundos, recibieron respuestas útiles de los "grandes". datos por períodos bastante largos: meses, medio año, etc.
Pero fuimos más allá y comenzamos a ir a la nube en busca de respuestas a través de un controlador ODBC : un analista escribe una consulta SQL en una consola familiar, que, en 100-500 máquinas, "por un centavo" arroja datos en s3 y devuelve una respuesta generalmente en unos pocos segundos. Convenientemente. Y rápido. Todavía no puedo creerlo.
Como resultado, después de haber tomado la decisión de almacenar datos en s3, en un formato de columnas eficiente y con una fragmentación de datos razonable por parte de los padres ... obtuvimos DataLake y un motor analítico rápido y barato, gratis. Y se hizo muy popular entre la empresa porque comprende SQL y ejecuta órdenes de magnitud más rápido que iniciar / detener / configurar clústeres. "Y si el resultado es el mismo, ¿por qué pagar más?"
La solicitud a Athena se parece a esto. Si lo desea, por supuesto, puede formar suficientesconsulta SQL compleja y de varias páginas , pero nos limitaremos a la agrupación simple. Veamos qué códigos de respuesta tenía el cliente hace unas semanas en los logs del servidor web y asegurémonos de que no haya errores:
conclusiones
Habiendo recorrido, por no decir eso, un camino largo pero doloroso, evaluando constantemente de manera adecuada los riesgos y el nivel de complejidad y costo de soporte, hemos encontrado una solución para DataLake y análisis que nunca deja de complacernos tanto con la velocidad como con el costo de propiedad.
Resultó que incluso los desarrolladores experimentados que nunca trabajan como arquitectos y no pueden dibujar cuadrados en cuadrados con flechas y que conocen 50 términos del ecosistema Hadoop pueden construir un DataLake eficiente, rápido y barato para las necesidades de divisiones completamente diferentes de la empresa.
Al comienzo del viaje, mi cabeza se estaba separando del conjunto de los zoológicos más salvajes de software abierto y cerrado y la comprensión de la carga de responsabilidad hacia los descendientes. Simplemente comience a construir su DataLake a partir de herramientas simples: nagios / munin -> elastic / kibana -> Hadoop / Spark / s3 ..., recolectando comentarios y entendiendo profundamente la física de los procesos que tienen lugar. Todo lo complicado y lodoso: dáselo a tus enemigos y competidores.
Si no desea ir a la nube y le gusta mantener, actualizar y parchear proyectos de código abierto, puede crear un esquema similar al nuestro localmente, en máquinas de oficina de bajo costo con Hadoop y Presto encima. Lo principal es no detenerse y seguir adelante, contar, buscar soluciones simples y claras y ¡definitivamente todo saldrá bien! ¡Buena suerte a todos y hasta pronto!