Une nouvelle ère émerge dans le domaine de l’Aide à la décision. La BI a déployé ses lettres de noblesse au cours des 2 dernières décennies mais de nouveaux acteurs poussent et vont révolutionner les usages de la BI traditionnelle.

Apache Kylin est probablement une des solutions Open Source les plus prometteuses pour permettre de marier les promesses du Big Data (des To de données), le Time 0 to Data et les nouveaux besoins d’aide à la Décision auprès de milliers d’utilisateurs.

Nous profitons de la mise en ligne de la dernière version 2.6.0 d’Apache Kylin pour vous en présenter, ci-dessous, les grandes lignes …

Q1 – Qu’est-ce que Kylin ?

Apache Kylin est un moteur d’analyse distribué ou OLAP (OnLine Analytical Processing) Open-source.

Il a été créé par le département R&D de chez Ebay Shanghai en 2013 et il continue d’évoluer depuis.

Il permet de mettre en place des analyses multidimensionnelles sur une stack Hadoop à travers une interface SQL sur des cubes de données pré-calculés.

La solution Apache Kylin est innovante dans le sens où elle permet de préparer des grandes volumétries de données sous forme de cuboïdes multidimensionnels et de les interroger très rapidement (<1s pour des To de données).

Elle permet également à des milliers d’utilisateurs simultanés de se connecter aux reportings et solutions de visualisation interfacées avec les cubes calculés par Kylin.

Ebay / Samsung / J.P.Morgan / Cisco … utilisent Kylin aujourd’hui et tirent profit des performances de requêtage et visualisation offertes par cette plateforme.

Q2 – Comment KYLIN est-il structuré? quels modules existent ? Quelle architecture ? Quels composants ?

Kylin est découpé en 6 composants majeurs :

  • Un serveur WEB qui offre aux concepteurs et administrateurs les fonctionnalités de création et calcul des cubes,
  • Une API REST qui supporte la logique de gestion des cubes via l’interface Web ou au travers de scripts d’automatisation,
  • Un système de métadonnées. Kylin communique avec plusieurs éléments de la stack Hadoop telles que Hbase, Spark, HDFS, Calcite, Hive. La configuration doit être stockée de manière persistante afin de bien contrôler les différents environnements d’exécution.
  • Un moteur de requête pour pouvoir traduire les différentes requêtes SQL en plans d’exécution et interroger le moteur de stockage.
  • Le moteur de stockage : Stockage et Lecture de la donnée. La base utilisée par défaut actuellement est HBase. Apache Parquet a été ajouté récemment et des développements pour utiliser Druid sont en cours.
  • Le moteur d’exécution : Il permet de construire et d’exécuter les différents jobs MapReduce ou Spark depuis les données sources.

Q3 – En quoi la solution apporte t elle des réponses innovantes ? des performances améliorées? Quelle en sont les Promesses ?

Apache Kylin permet d’interroger des volumétries dites « Big Data » (+100To) avec des temps de réponses inférieurs à la seconde, sans limite d’utilisation (des milliers d’utilisateurs peuvent bénéficier des reportings et requêtes SQL de façon simultanée).
Il est intéressant de préciser que la communauté autour d’Apache Kylin est active avec des livraisons de version majeure tous les 2 mois et une réactivité en heures lors de la déclaration de bug.

Les autres solutions OLAP/Big Data du marché n’ont pas encore la même maturité qu’Apache Kylin et aucune ne possède de performances similaires.

Apache Kylin continue d’évoluer. Les axes des travaux en cours visent à :

  • Optimiser encore plus ses performances sur les différents composants qui le constituent, notamment sur la partie stockage : évolution de HBase vers un autre système tel que Druid par exemple,
  • Accentuer la présence de Spark sur certaines étapes en remplacement notamment de MapReduce,
  • Accélérer l’évolution du mode streaming (qui n’est à ce jour que du micro batch) vers une mise à disposition quasi temps réel.

Cette future version du mode streaming d’Apache Kylin est réellement prometteuse.

La version 2.6.0 mise à disposition ce jour – le 14/01/2019 – rends la solution encore plus robuste et performante; elle ajoute également la possibilité très attendue d’utiliser d’autres solutions relationnelles que Hive comme source de données (MySQL, PostgreSQL,…)

Q4 – Quelles difficultés principales ?

Du fait qu’Apache Kylin se repose sur un certain nombre de composants de la stack Hadoop, il est important dans un premier temps de bien comprendre le fonctionnement de ceux-ci et comment ils doivent être configurés pour bien répondre aux besoins exprimés.

La configuration de la solution Apache Kylin demande également d’investir du temps afin de bien comprendre l’ensemble des subtilités de la modélisation d’un cube dans le but d’atteindre les temps de réponses voulus lors de l’interrogation des cubes.

Comme tout projet data, une grande préparation de l’utilisation précise de la donnée doit être faite en amont avec en tête l’utilisation qu’en fera l’analyste par la suite : une modélisation correcte des cubes Kylin permet d’atteindre des performances optimales.

Q5 – De la phase de Tests à la Mise en production : quelles étapes ? points d’attention ?

Plusieurs points sont importants pour la mise en production depuis la phase de test. On pourrait citer en tout premier lieu, la qualité de la donnée, sans laquelle rien n’est possible, mais en soi, on ne commence pas les tests si elle n’est pas au rendez-vous.

Les tests :
Il faut effectuer les tests au plus près de ce qu’est l’architecture cible et la volumétrie de données. Cela permet de s’assurer des dimensionnements de l’architecture et des premiers benchmarks des temps de construction des cubes et des temps de réponses de leur interrogation.

La phase de tests permet aussi de valider les différents modèles de cubes par des mesures précises et benchmarks effectués.

L’architecture proposée :
Il est également essentiel de préparer les systèmes de résilience de l’architecture tels que les différents mécanismes de réplications et de sauvegarde lorsque l’on veut pratiquer l’auto-scaling afin de diminuer les coûts de calculs.

L’architecture proposée pour une montée en production, doit être capable de se remettre d’aplomb d’elle-même en cas, par exemple, de perte de nœuds de calculs.

Q6 – Un exemple de découpage des grandes phases d’un projet (agrégation de ventes France ou Monde, à partir de n tables, avec des données « maîtrisées » …)

Voici ce que peut délivrer un projet en 3 à 4 mois sur Apache Kylin :

  • Analyse du besoin et des données utilisées (cartographie des systèmes sources) – (1 semaine).
  • Remarque : il arrive souvent qu’on parte d’un contexte client qui utilise Essbase, une des solutions phares de l’OLAP depuis 10 ans, mais qui souffre sur les volumes désormais en jeu dans les entreprises.

  • Analyse relationnelle des données et de son utilisation à travers une UX + construction d’un MCD (3-4 semaines). Cette étape est la plus vitale du projet, les erreurs de conception à ce niveau impactent très fortement les temps de développements qui s’ensuivent. < style="color : #5151d0">Préparation de la donnée (2 semaines) : Cette phase peut varier selon la qualité de la donnée initiale et les différentes dimensions que l’on souhaite intégrer dans un cube.
  • Création, dimensionnement et configuration des architectures permettant de supporter les volumétries cibles (3 semaines).
  • Modélisation & Construction des cubes, Benchmark de tests & optimisations (2-3 semaines).
  • Automatisation des incréments et mise en place des systèmes de Run (3 semaines).
  • Mise en production + validation de la stabilité de l’architecture construite (1 mois).

Nous vous en dirons plus très prochainement, avec notamment des exemples de performances obtenues et nos derniers tests et benchmark des montées de version en cours.