APACHE KYLIN v4 – BI & Big Data
Les équipes Novagen ont depuis longtemps investi les technologies BI à l’échelle BigData et nous en suivons quotidiennement les évolutions.
Aujourd’hui, nous vous proposons une analyse exhaustive de la version Majeure 4 d’Apache Kylin, sortie cet été, en août 2020.
Petit rappel
Apache Kylin est un moteur open source de traitement analytique en ligne (OLAP) pour l’analyse interactive des données Big Data (des milliards de lignes / des milliers d’utilisateurs simultanés). La plateforme a été conçue pour fournir une interface SQL et une analyse multidimensionnelle (OLAP) sur Hadoop/Spark.
Elle s’intègre facilement aux outils de BI via un pilote ODBC ou JDBC et une API REST. Créé par eBay en 2014, Apache Kylin a obtenu le titre de Top Level Project de l’Apache Software Foundation un an plus tard, en 2015, et a remporté le prix du meilleur outil de données Open Source BIG DATA en 2015 ainsi qu’en 2016.
« Utilisée par des milliers d’entreprises dans le monde entier comme application d’analyse performante sur des volumes de données Big Data, Apache Kylin permet de répondre aux requêtes en quelques millisecondes. Il offre une latence de requête de l’ordre de la seconde pour des ensembles de données qui peuvent s’échelonner jusqu’au pétaoctet« . Voilà pour les arguments officiels.
Fort d’un premier projet conçu, développé et mis en production en 2019 pour l’un de ses clients grands comptes, Novagen a pu éprouver la solution dans toutes ses dimensions et dans le cadre d’un projet remarquable en Volume / Temps de réponse attendus / Nombre d’utilisateurs simultanés.
Quand on veut interroger d’immenses quantités d’information (100Go => 1 To => 10To …), avec des temps de réponse acceptables (quelques secondes au plus, en visant les centaines de ms), il faut souvent mobiliser des infrastructures très importantes. Et ceci parce qu’il faut pour chaque requête traverser des tables et des jointures très consommatrices.
Le problème devient insurmontable quand on ouvre les analyses à des dizaines voire des centaines d’utilisateurs en simultané.
Une solution : pré-calculer les indicateurs demandés. On consacre ainsi une puissance de calcul ponctuelle à préparer les réponses aux requêtes, qui seront servies très rapidement par la suite, au travers de tableaux de bords ou de requêtes ad-hoc.
Le postulat technique de départ d’Apache Kylin est de s’appuyer sur des technologies de stockage ( historiquement HDFS, Hive, HBase ) et de calcul (Map-Reduce puis Spark) pour atteindre des capacités et des performances ultimes.
Novagen a décortiqué la version 4 sortie cet été, nous l’avons soumise à des tests techniques et fonctionnels représentatifs pour vous en donner un verdict détaillé. La V4 répond-elle aux attentes du moment ?
Apache KYLIN : la V4
La version 4 de Apache Kylin s’inscrit pleinement dans cette thématique.
Tout en préservant sa philosophie de modélisation et construction de cubes décisionnels très exigeants, cette version a procédé à des changements d’architectures majeurs :
⇒ Le remplacement de HBase par Apache Parquet comme solution de stockage.
⇒ L’utilisation de Apache Spark :
pour la construction des cubes et, de manière presque contre-intuitive, parce qu’on pense à Apache Spark pour les traitements de masse, pour les requêtes utilisateur.
Les bénéfices promis sont :
Limiter la complexité de maintenance induite par HBase.
Simplifier la conception, toujours en soulageant des spécificités d’HBase
Gains de performances à la construction
Gains de performances aux requêtes
L’espace de stockage nécessaire est moindre (Cf. chiffre annoncé par Kyligence), du fait d’une compression appréciable à toutes les informations
Les temps de désérialisation des informations (exigé par le mode de stockage de HBase) est lui aussi économisé.
NOS TESTS / NOS DÉVELOPPEMENTS
Au delà des promesses des release notes, et bien que nous connaissions la solution Kylin et ses qualités, nous avons effectué un test sans concession, avec en particulier des évaluations poussées sur :
- La simplicité de déploiement et configuration sur une architecture cloud,
- La stabilité de fonctionnalités,
- Les gains de performances annoncés,
- La capacité à tenir la charge avec de nombreux utilisateurs en parallèle.
Nous avons consigné tous ces enseignements dans un rapport complet (que nous vous partageons à contact@novagen.tech ) :
Comment avons-nous procédé ?
- Déploiement sur le cloud AWS. C’est un environnement dans lequel nous avons nos habitudes pour déployer des clusters Hadoop, mais n’importe quel fournisseur pourra convenir s’il a une distribution conforme aux standards.
Nous avons utilisé des clusters modestes de 3 à 5 noeuds. - Pour multiplier les déploiements selon différentes configurations, nous avons scripté l’installation et le lancement de la solution qui est disponible en l’espace de 15 minutes.
- Nous avons généré des données qui permettent des tests représentatifs; c’est à dire : Création de datasets de Millions, Dizaines de millions, Centaines de millions d’enregistrements.
Création de colonnes de type dimension (Date, Timestamp, Référence, identifiant, Catégorie) et de mesures (numériques…) avec des distributions statistiques variées pour tester les cas favorables et les cas défavorables (ultra hautes cardinalités) aux analyses de masse.
Ces données sont placées dans un stockage objet (S3) et on les mobilise pour alimenter des tables HIVE.
Les résultats observés
Construction des cubes
Les constructions sont rapides et exploitent très bien la puissance du serveur. Nous avons voulu observer l’évolution des temps et de l’espace pris en fonction du nombre de lignes du dataset. l’évolution reste contenue mais n’est pas linéaire. A noter que ceci est dépendant de la complexité du cube et de l’infrastructure dédiée. le cas présent était peu favorable: grandes cardinalités des dimensions et cluster à puissance modeste.
| Nombre de lignes | Temps de construction | Taille du cube |
| 3 Millions de lignes | 4 minutes | 2,64GB |
| 15 millions de lignes | 38 minutes | 16 GB |
| 60 millions de lignes | 157 minutes | 98.4 GB |
Les performances des requêtes
De manière générale, elles sont excellentes, mais sont largement dépendantes des bonnes pratiques de modélisation, de requêtage, et de l’infrastructure.
On observe des temps de réponse bien plus importants lorsqu’on sort des cas prévus : la requête aboutit, mais elle s’exécute sur les données sources et non pas sur les données agrégées. C’est un bon point de comparaison sur les temps observés avec un traitement Hive ou Spark classique.
| Requête | Cube de 3M lignes | Cubes de 15M lignes | Cube de 60M lignes |
| Filtrage sur 3 colonnes | <0,1s | 0,16s | 1,27s (Optimisation Spark à faire sur le Query Engine car temps de réponse augmentent de manière non linéaire.) |
| Filtrage sur 4 colonnes | <0,1s | 0,21s | 1,38s |
| Filtrage sur 10 colonnes sur des données non préparées | 26,02s (combinaison de colonnes possibles limitée à 4) | 58,32s | |
| Aggregation group by 4 colonnes | 0,48s | 0,61s | 4,27s |
| Aggrégation+Filtrage 4 colonnes | 0,77s | 0,67s | 5,22s |
La résistance à de fortes charges
Nous avons développé un injecteur capable d’itérer sur un jeu de requêtes en lançant de 20 à 100 exécuteurs en parallèle. Ces sollicitations ‘techniques’ qui correspondent à des centaines voir des milliers d’utilisateurs réels en simultanés nous ont offert des enseignements :
- La solution résiste très bien à de fortes charges et montre une stabilité et une résilience sans faille,
- Les temps de réponses glissent (à infrastructure constante) de 200 ms à 2 secondes. On pourra augmenter les capacités d’infrastructure si l’on doit faire face à de tels volumes d’activités et conserver d’excellents temps de réponse.
Considérations pour un déploiement en production
Pour tirer parti de la nouvelle architecture, certaines précautions doivent être prises :
Kylin arrive avec des files d’attente prédéfinies pour les requêtes : les requêtes heavy (dont on sait qu’elles seront impactantes et les utilisateurs peuvent attendre quelques secondes la réponse), les requêtes lightweight (performantes mais peu gourmandes) et les requêtes vip, pour servir en priorité des requêtes importantes.
On pourra ajouter des nœuds en amont des charges de construction des cubes : on optimise ainsi l’infrastructure nécessaire au bon fonctionnement de Kylin, en laissant la puissance nécessaire aux requêtes utilisateur sans perturber leur qualité de service.
La configuration de départ prévoit 1 Driver et 1 exécuteur. Selon les performances attendues, la typologie des cubes créés et l’infrastructure disponible, on pourra profiter de la parallélisation en montant à 4 ,8… exécuteurs. Nous poursuivons nos tests actuels sur ce point particulier.
En résumé
Toutes les fonctionnalités et spécificités d’Apache Kylin ont été maintenues. Cette version, bien que ‘Alpha’, présente une stabilité très appréciable en plus des améliorations de performances que nous avons pu mesurer.
Cette version 4.0 de Apache Kylin facilitera le déploiement sur des architectures pour lesquelles il y a avait des obstacles : par exemple sur Google Cloud Platform, l’absence de HBase natif complexifiait la mise en œuvre. On pourra surtout l’ajouter plus facilement dans des clusters Hadoop existants pour lesquels l’ajout de Hbase était problématique.
Vous voulez en savoir plus sur la solution ?
Est-elle adaptée à votre contexte Métier, à vos besoins ?
Profitez de notre rapport détaillé sur la V4 de Kylin et n’hésitez pas à nous contacter : contact@novagen.tech / hstefani@novagen.tech, nous sommes à votre disposition pour éclairer vos équipes sur les solutions IT innovantes à privilégier …
