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.

Les grands principes d’Apache Kylin :

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 :

1

Limiter la complexité de maintenance induite par HBase.

Hbase est une solution NoSQL dont les domaines d’applications ne correspondent pas parfaitement avec l’exécution de requêtes analytiques. Son positionnement au coeur du moteur de Kylin pouvait parfois se traduire par des instabilités du cluster, des phénomènes de hotspotting (sur sollicitation de certains noeuds) et demander une charge de monitoring pénalisante.
2

Simplifier la conception, toujours en soulageant des spécificités d’HBase

Le stockage véritable ‘colonne’ de Parquet, par opposition au stockage ‘Clé d’accès + colonnes’ de HBase, simplifie très significativement la mise au point des cubes. Notamment dans les cas complexes où il fallait trouver la meilleure stratégie de génération des clés ‘rowkeys’.
3

Gains de performances à la construction

Le stockage des données calculées est constitué de multiples fichiers parquet qui sont la combinaison des dimensions d’analyse et des calculs recherchés. Apache Spark s’exprime de manière très performante dans ce domaine. Les gains de construction observés sont de l’ordre de 50%. Ce qui est très appréciable dans des plages batch souvent contraintes.
4

Gains de performances aux requêtes

Les temps de requêtes sont bien plus homogènes (nous évitons que les requêtes de ‘fin de rowkey’ ne prennent des temps de calculs inconsidérés)

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 :

1. Comprendre comment fonctionnent les queues Yarn pour les configurer et les dimensionner correctement. La performance des requêtes et des constructions de cubes y sont sensibles.

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.

2. Redimensionner dynamiquement le cluster

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.

3. Ajuster le nombre d’exécuteurs spark dédiés à la partie Query

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 …