Ce n'est pas pour rien que des collègues plus expérimentés, la tête parsemée de bugs et de ce déjà aux cheveux gris, envisageant le déploiement incroyablement rapide de packs de «conteneurs» en «cubes» sur des dizaines de serveurs dans des «langages à la mode» avec prise en charge intégrée des E / S asynchrones non bloquantes - sourire modestement ... Et ils continuent silencieusement à relire "man ps", à fouiller dans le code source de "nginx" jusqu'à ce qu'ils saignent des yeux et à écrire-écrire-écrire des tests unitaires. Les collègues savent que le plus intéressant sera à venir, lorsque «tout cela» une nuit deviendra un enjeu le soir du Nouvel An. Et seule une compréhension approfondie de la nature d'Unix, une table d'état TCP / IP apprise et des algorithmes de recherche de tri de base les aideront. Redonner vie au système sous les carillons.
Oh oui, j'étais un peu distrait, mais j'espère avoir réussi à transmettre l'état d'anticipation.
Aujourd'hui, je souhaite partager notre expérience de déploiement d'une pile pratique et peu coûteuse pour DataLake, qui résout la plupart des tâches analytiques dans une entreprise pour des divisions structurelles complètement différentes.
Il y a quelque temps, nous avons compris que l'entreprise avait de plus en plus besoin des fruits de l'analyse produit et technique (sans parler de la cerise sur le gâteau sous la forme d'apprentissage automatique) et pour comprendre les tendances et les risques - de plus en plus de besoins doivent être collectés et analysés. plus de métriques.
Analyse technique de base chez Bitrix24
Il y a plusieurs années, parallèlement au lancement du service Bitrix24, nous avons investi activement du temps et des ressources dans la création d'une plate-forme analytique simple et fiable qui nous aiderait à identifier rapidement les problèmes d'infrastructure et à planifier l'étape suivante. Bien entendu, il était souhaitable de prendre les outils prêts à l'emploi et aussi simples et compréhensibles que possible. En conséquence, nagios a été choisi pour la surveillance et munin pour l'analyse et la visualisation. Maintenant, nous avons des milliers de chèques dans les nagios, des centaines de graphiques dans munin et collègues chaque jour et les utilisons avec succès. Les métriques sont claires, les graphiques sont clairs, le système fonctionne de manière fiable depuis plusieurs années et de nouveaux tests et graphiques y sont régulièrement ajoutés: nous mettons un nouveau service en service - nous ajoutons plusieurs tests et graphiques. Bonne chance.
Hand on the pulse - Analyse technique avancée
Le désir de recevoir des informations sur les problèmes «le plus rapidement possible» nous a conduit à des expériences actives avec des outils simples et compréhensibles - pinba et xhprof.
Pinba nous a envoyé des statistiques de paquets UDP sur la vitesse de parties de pages Web en PHP et il était possible de visualiser en ligne dans le stockage MySQL (pinba est livré avec son propre moteur MySQL pour une analyse rapide des événements) une courte liste de problèmes et d'y répondre. Et xhprof en mode automatique permettait de collecter des graphiques d'exécution des pages PHP les plus lentes des clients et d'analyser ce qui pouvait conduire à cela - calmement, verser du thé ou quelque chose de plus fort.
Il y a quelque temps, la boîte à outils a été complétée par un autre moteur assez simple et direct basé sur l'algorithme d'indexation inverse, parfaitement implémenté dans la légendaire bibliothèque Lucene - Elastic / Kibana. L'idée simple de l'écriture multi-thread de documents à un index inverse de Lucene basé sur les événements dans les journaux et une recherche rapide à travers eux en utilisant la division par facettes s'est avérée, en effet, utile.
Malgré le type plutôt technique de visualisations dans Kibana avec des concepts de bas niveau «fluides» comme «seau» et le langage nouvellement inventé de l'algèbre relationnelle pas encore oubliée, l'outil a commencé à bien nous aider dans les tâches suivantes:
- Combien d'erreurs PHP le client Bitrix24 a-t-il eues sur le portail p1 au cours de la dernière heure, et lesquelles? Comprenez, pardonnez et réparez rapidement.
- - 24 , /?
- ( C PHP), ? segfaults?
- PHP? : «out of memory»? .
Voici un exemple concret. Malgré des tests minutieux et à plusieurs niveaux, le client, avec un cas très non standard et des données d'entrée corrompues, a eu une erreur ennuyeuse et inattendue, une sirène a retenti et le processus de sa solution rapide a commencé:
De plus, kibana vous permet d'organiser la notification d'événements spécifiés et en peu de temps est devenu un outil dans l'entreprise font appel à des dizaines d'employés de différents départements - du support technique et du développement à l'assurance qualité.
L'activité de toute division au sein de l'entreprise est devenue pratique à suivre et à mesurer - au lieu d'analyser manuellement les logs sur les serveurs, il suffit de configurer l'analyse des logs et de les envoyer une fois au cluster élastique, pour profiter, par exemple, de contempler dans le tableau de bord kibana le nombre de chatons bicéphale vendus imprimés sur 3-d imprimante pour le dernier mois lunaire.
Business Intelligence de base
Tout le monde sait que l'intelligence d'affaires dans les entreprises commence souvent par une utilisation extrêmement active, oui, oui, Excel. Mais l'essentiel est que cela ne s'arrête pas là. Cloud Google Analytics ajoute de l'huile sur le feu - vous vous habituez rapidement aux bonnes choses.
Dans notre entreprise en développement harmonieux, des «prophètes» d'un travail plus intensif avec des données plus volumineuses ont commencé à apparaître ici et là. Le besoin de rapports plus approfondis et plus multiformes a commencé à apparaître régulièrement, et grâce aux efforts de gars de différents départements, une solution simple et pratique a été organisée il y a quelque temps - un tas de ClickHouse et PowerBI.
Pendant assez longtemps, cette solution flexible a beaucoup aidé, mais progressivement, il a commencé à comprendre que ClickHouse n'est pas du caoutchouc et ne peut pas être ridiculisé comme ça.
Ici, il est important de bien comprendre que ClickHouse, comme Druid, comme Vertica, comme Amazon RedShift (qui est basé sur postgres), sont des moteurs analytiques optimisés pour des analyses assez pratiques (sommes, agrégations, minimum-maximum par colonne et un peu de jointures) ), parce que sont organisés pour stocker efficacement les colonnes dans des tables relationnelles, contrairement à MySQL et aux autres bases de données (orientées lignes) que nous connaissons.
En fait, ClickHouse est juste une "base de données" plus volumineuse de données, avec une insertion de points pas très pratique (comme prévu, tout va bien), mais de belles analyses et un ensemble de fonctions puissantes intéressantes pour travailler avec des données. Oui, vous pouvez même créer un cluster - mais vous comprenez que marteler des clous avec un microscope n'est pas tout à fait correct, et nous avons commencé à chercher d'autres solutions.
La demande de python et d'analystes
De nombreux développeurs dans notre entreprise écrivent du code presque tous les jours pendant 10 à 20 ans en PHP, JavaScript, C #, C / C ++, Java, Go, Rust, Python, Bash. Il y a aussi de nombreux administrateurs système expérimentés qui ont survécu à plus d'un désastre absolument incroyable qui ne rentre pas dans les lois des statistiques (par exemple, lorsque la plupart des disques du raid-10 sont détruits par un fort coup de foudre). Dans de telles conditions, pendant longtemps, ce qu'est un "analyste python" n'a pas été clair. Python est comme PHP, seul le nom est légèrement plus long et les traces de substances psychotropes dans le code source de l'interpréteur sont légèrement plus petites. Cependant, à mesure que de plus en plus de rapports analytiques sont créés, les développeurs expérimentés sont de plus en plus conscients de l'importance d'une spécialisation étroite dans des outils tels que numpy, pandas, matplotlib, seaborn.
Le rôle décisif a probablement été joué par l'évanouissement soudain des employés de la combinaison des mots «régression logistique» et la démonstration d'un reporting efficace sur des données volumineuses en utilisant oui, oui, pyspark.
Apache Spark, son paradigme fonctionnel, son algèbre relationnelle et ses capacités ont tellement impressionné les développeurs habitués à MySQL que la nécessité de renforcer les rangs de bataille avec des analystes expérimentés est devenue claire comme le jour.
Autres tentatives d'Apache Spark / Hadoop pour décoller et ce qui n'a pas fonctionné
Cependant, il est vite devenu clair qu'avec Spark, apparemment, quelque chose ne va pas systématiquement, ou vous devez simplement mieux vous laver les mains. Si la pile Hadoop / MapReduce / Lucene a été faite par des programmeurs assez expérimentés, ce qui est évident si vous regardez le code source Java ou les idées de Doug Cutting dans Lucene avec passion, alors Spark, du coup, est écrit dans un très controversé du point de vue de la praticité et ne développe plus le langage exotique Scala. Et la baisse régulière des calculs sur le cluster Spark en raison d'un travail illogique et peu transparent d'allocation de mémoire pour réduire les opérations (de nombreuses clés arrivent en même temps) - a créé un halo de quelque chose autour de lui qui a de la place pour se développer. De plus, la situation a été aggravée par un grand nombre de ports ouverts étranges, de fichiers temporaires,grandissant dans les endroits les plus incompréhensibles et l'enfer des dépendances aux bocaux - ce qui a causé aux administrateurs système un sentiment bien connu depuis l'enfance: une haine féroce (ou peut-être qu'il était nécessaire de se laver les mains avec du savon et de l'eau).
En conséquence, nous avons «survécu» à plusieurs projets analytiques internes utilisant activement Apache Spark (y compris Spark Streaming, Spark SQL) et l'écosystème Hadoop (entre autres). Malgré le fait qu'au fil du temps, nous avons appris à bien cuisiner et à surveiller «ça» et «ça» a pratiquement cessé de tomber soudainement en raison du changement de nature des données et du déséquilibre du hachage RDD uniforme, le désir de prendre quelque chose de prêt à l'emploi, mis à jour et administré quelque part le nuage est devenu de plus en plus fort. C'est à ce moment-là que nous avons essayé d'utiliser l'assemblage cloud prêt à l'emploi d'Amazon Web Services - EMR et, par la suite, avons essayé de résoudre les problèmes. EMR est un Apache Spark préparé par Amazon avec un logiciel supplémentaire de l'écosystème, similaire aux builds Cloudera / Hortonworks.
Stockage de fichiers en caoutchouc pour l'analyse - un besoin urgent
L'expérience de "cuisiner" Hadoop / Spark avec des brûlures à diverses parties du corps n'a pas été vaine. La nécessité de créer un stockage de fichiers unique, peu coûteux et fiable, résistant aux pannes matérielles et dans lequel il serait possible de stocker des fichiers dans différents formats à partir de différents systèmes et dans lequel il serait possible de faire des sélections efficaces et opportunes pour les rapports à partir de ces données, a commencé à apparaître de plus en plus clairement.
Je voulais également que la mise à jour logicielle de cette plate-forme ne se transforme pas en cauchemar du Nouvel An avec la lecture de traces Java de 20 pages et l'analyse des journaux de cluster détaillés de plusieurs kilomètres à l'aide de Spark History Server et d'une loupe rétroéclairée. Je voulais avoir un outil simple et transparent qui ne nécessitait pas de plonger régulièrement sous le capot, si le développeur arrêtait d'exécuter une requête MapReduce standard lorsque le rédacteur de données a perdu de la mémoire avec un algorithme de partitionnement mal choisi pour les données initiales.
Amazon S3 un candidat DataLake?
L'expérience avec Hadoop / MapReduce a montré que vous avez besoin d'un système de fichiers évolutif et fiable et de travailleurs évolutifs au-dessus, "se rapprochant" des données, afin de ne pas générer de données sur le réseau. Les travailleurs devraient pouvoir lire les données dans différents formats, mais, de préférence, ne pas lire les informations inutiles et afin que les données puissent être stockées à l'avance dans des formats convenant aux travailleurs.
Encore une fois, l'idée principale.Il n'y a pas de désir de «télécharger» des données volumineuses dans un seul moteur d'analyse de cluster, qui, tôt ou tard, se noiera et devra être laide. Je souhaite stocker des fichiers, juste des fichiers, dans un format compréhensible et effectuer des requêtes analytiques efficaces sur eux avec des outils différents mais compréhensibles. Et il y aura de plus en plus de fichiers dans différents formats. Et il vaut mieux séparer non pas le moteur, mais les données initiales. Nous avons besoin d'un DataLake extensible et polyvalent, nous avons décidé ...
Et si nous stockions des fichiers dans le stockage cloud évolutif d'Amazon S3 familier et bien connu sans avoir à faire nos propres côtelettes à partir de Hadoop?
Il est clair que les données sont «en bas», mais d'autres données si vous les retirez et les «conduisez efficacement»?
Écosystème Cluster-Bigdata-Analytics d'Amazon Web Services - en termes très simples
À en juger par notre expérience avec AWS, il y est activement utilisé depuis longtemps sous diverses sauces Apache Hadoop / MapReduce, par exemple dans le service DataPipeline (j'envie mes collègues, ils ont appris à le cuisiner correctement). Ici, nous avons configuré des sauvegardes de différents services à partir de tables DynamoDB:
et elles ont été régulièrement effectuées sur les clusters Hadoop / MapReduce intégrés comme sur des roulettes pendant plusieurs années. Configurez-le et oubliez-le:
vous pouvez également vous engager efficacement dans le catanisme des données en augmentant les ordinateurs portables Jupiter pour les analystes dans le cloud et en utilisant AWS SageMaker pour entraîner et déployer des modèles d'IA au combat. Voici à quoi cela ressemble avec nous:
Et oui, vous pouvez prendre un ordinateur portable dans le cloud pour vous-même ou des analyses et le joindre au cluster Hadoop / Spark, calculer puis tout «clouer»:
Vraiment pratique pour des projets analytiques individuels et pour certains, nous avons utilisé avec succès le service EMR pour des calculs et des analyses à grande échelle. Qu'en est-il d'une solution système pour DataLake, cela fonctionnera-t-il? À ce moment-là, nous étions au bord de l'espoir et du désespoir et avons continué notre recherche.
AWS Glue - Apache Spark parfaitement emballé "sous stéroïdes"
Il s'est avéré qu'AWS avait sa propre version de la pile Hive / Pig / Spark. Le rôle de Hive, i.e. le catalogue des fichiers et leurs types dans DataLake exécute le service «Data catalog», qui ne cache pas sa compatibilité avec le format Apache Hive. Dans ce service, vous devez ajouter des informations sur l'emplacement de vos fichiers et leur format. Les données peuvent être non seulement dans s3, mais aussi dans la base de données, mais ce n'est pas à ce sujet dans cet article. Voici comment le répertoire de données DataLake est organisé ici:
Les fichiers sont enregistrés, super. Si les fichiers ont été mis à jour, nous les lançons manuellement ou selon un calendrier par des robots d'exploration, qui mettront à jour les informations les concernant à partir du lac et les enregistreront. Ensuite, les données du lac peuvent être traitées et les résultats peuvent être déchargés quelque part. Dans le cas le plus simple, nous le téléchargeons également sur s3. Le traitement des données peut être effectué n'importe où, mais il est suggéré de configurer le traitement sur un cluster Apache Spark à l'aide de fonctionnalités avancées via l'API AWS Glue. En fait, vous pouvez prendre le bon vieux code python familier à l'aide de la bibliothèque pyspark et le configurer pour qu'il s'exécute sur N nœuds d'un cluster d'une certaine capacité avec surveillance, sans creuser dans les tripes de Hadoop et faire glisser les conteneurs docker-mocker et éliminer les conflits de dépendance.
Encore une fois, une idée simple.Vous n'avez pas besoin de configurer Apache Spark, il vous suffit d'écrire du code python pour pyspark, de le tester localement sur le bureau, puis de l'exécuter sur un grand cluster dans le cloud, en indiquant où se trouvent les données source et où placer le résultat. Parfois, c'est nécessaire et utile, et
voici comment cela est configuré avec nous: Ainsi, si vous avez besoin de calculer quelque chose sur le cluster Spark sur les données en s3 - écrivez le code en python / pyspark, testez-le et bon voyage dans le cloud.
Et l'orchestration? Et si la tâche tombait et disparaissait? Oui, il est proposé de faire un beau pipeline dans le style d'Apache Pig et nous les avons même essayés, mais avons décidé d'utiliser notre orchestration profondément personnalisée en PHP et JavaScript pour l'instant (je comprends, il y a une dissonance cognitive, mais cela fonctionne pendant des années et sans erreurs).
Le format de fichier Lake est la clé de la performance
Il est très, très important de comprendre deux autres points clés. Pour que les demandes de données provenant de fichiers du lac soient exécutées le plus rapidement possible et que les performances ne se dégradent pas lorsque de nouvelles informations sont ajoutées, vous avez besoin:
- Stockez les colonnes de fichier séparément (afin que vous n'ayez pas besoin de lire toutes les lignes pour comprendre ce qu'il y a dans les colonnes). Pour cela, nous avons pris le format parquet avec compression
- Il est très important de partager les fichiers des papas dans l'esprit: langue, année, mois, jour, semaine. Les moteurs qui comprennent ce type de partitionnement ne regarderont que les bons papas, sans pousser toutes les données à travers eux-mêmes.
En fait, de cette manière, vous disposez de la forme la plus efficace des données initiales pour les moteurs analytiques accrochés au-dessus, qui peuvent entrer sélectivement les papas de partition et lire uniquement les colonnes nécessaires à partir des fichiers. Il n'est pas nécessaire d'aller n'importe où, il se révélera «remplir» les données (le stockage éclatera tout simplement) - il suffit de les mettre de manière raisonnable dans le système de fichiers dans le format correct tout de suite. Bien sûr, il doit être clair ici que stocker un énorme fichier csv dans DataLake, qui doit d'abord être lu par le cluster ligne par ligne, afin d'extraire les colonnes, n'est pas très conseillé. Réfléchissez aux deux points ci-dessus si vous ne savez pas encore pourquoi tout cela est.
AWS Athena - "l'enfer" hors de la tabatière
Et puis, en créant un lac, nous sommes tombés, d'une manière ou d'une autre, sur Amazon Athena. Tout à coup, il s'est avéré qu'en pliant soigneusement nos énormes fichiers journaux par shards-daddies dans le bon format de colonne (parquet), vous pouvez très rapidement faire des sélections extrêmement informatives sur eux et créer des rapports SANS, sans cluster Apache Spark / Glue.
Le moteur de données s3 Athena est basé sur le légendaire Presto , un membre de la famille d'approches de traitement de données MPP (traitement parallèle massif), prenant les données là où elles se trouvent, de s3 et Hadoop à Cassandra et aux fichiers texte. Il vous suffit de demander à Athena d'exécuter la requête SQL, puis tout «fonctionne rapidement et par lui-même». Il est important de noter qu'Athena est "intelligente", ne va qu'aux papas partagés nécessaires et ne lit que les colonnes nécessaires dans la requête.
Les demandes de facturation à Athena sont également intéressantes. Nous payons la quantité de données analysées . Ceux. pas pour le nombre de machines dans le cluster par minute, mais ... pour les données réellement scannées sur 100-500 machines, seulement les données nécessaires pour répondre à la demande.
Et en ne demandant que les colonnes nécessaires à des papas correctement fragmentés, il s'est avéré que le service Athena nous coûte des dizaines de dollars par mois. Eh bien, génial, presque gratuit, par rapport aux analyses sur les clusters!
Soit dit en passant, voici comment nous partageons nos données en s3:
en peu de temps, des divisions complètement différentes de l'entreprise, de la sécurité de l'information à l'analyse, ont commencé à adresser activement des demandes à Athena et rapidement, en quelques secondes, à recevoir des réponses utiles des «grands» des données sur des périodes assez longues: mois, semestre, etc.
Mais nous sommes allés plus loin et avons commencé à aller dans le cloud pour obtenir des réponses via un pilote ODBC : un analyste écrit une requête SQL dans une console familière, qui, sur 100-500 machines, «pour un sou» donne des données en s3 et renvoie une réponse généralement en quelques secondes. Idéalement. Et vite. Je n'arrive toujours pas à y croire.
En conséquence, après avoir pris la décision de stocker les données en s3, dans un format colonne efficace et avec un partage de données raisonnable par les papas ... nous avons obtenu DataLake et un moteur d'analyse rapide et bon marché - gratuitement. Et il est devenu très populaire auprès de l'entreprise parce que comprend SQL et exécute des ordres de grandeur plus rapidement que le démarrage / l'arrêt / la configuration de clusters. "Et si le résultat est le même, pourquoi payer plus?"
La demande à Athéna ressemble à quelque chose comme ça. Si vous le souhaitez, bien sûr, vous pouvez former suffisammentrequête SQL complexe et multi-pages , mais nous nous limiterons à un simple regroupement. Voyons quels codes de réponse le client avait il y a quelques semaines dans les journaux du serveur Web et assurez-vous qu'il n'y a pas d'erreurs:
conclusions
Après avoir parcouru, pour ne pas dire qu'un chemin long mais douloureux, évaluant en permanence de manière adéquate les risques, le niveau de complexité et le coût du support, nous avons trouvé une solution pour DataLake et l'analytique qui ne cesse de nous plaire à la fois avec rapidité et coût de possession.
Il s'est avéré que la construction d'un DataLake efficace, rapide et bon marché pour les besoins de divisions complètement différentes de l'entreprise est totalement à la portée de développeurs même expérimentés qui ne travaillent jamais en tant qu'architectes et ne peuvent pas dessiner des carrés sur des carrés avec des flèches et connaissent 50 termes de l'écosystème Hadoop.
Au début du voyage, ma tête se séparait de l'ensemble des zoos les plus sauvages des logiciels ouverts et fermés et de la compréhension du fardeau de la responsabilité envers les descendants. Commencez simplement à créer votre DataLake à partir d'outils simples: nagios / munin -> élastique / kibana -> Hadoop / Spark / s3 ..., en collectant des commentaires et en comprenant en profondeur la physique des processus en cours. Tout est compliqué et boueux - donnez-le à vos ennemis et concurrents.
Si vous ne voulez pas aller dans le cloud et que vous aimez maintenir, mettre à jour et patcher des projets open source, vous pouvez créer un schéma similaire au nôtre localement, sur des ordinateurs de bureau bon marché avec Hadoop et Presto en plus. L'essentiel est de ne pas s'arrêter et d'aller de l'avant, de compter, de chercher des solutions simples et claires et tout fonctionnera définitivement! Bonne chance à tous et à bientôt!