Dremio: analyse de données plus simple et plus rapide

Jacques Nadeau est le directeur technique et cofondateur de Dremio.

C'est le moment idéal pour devenir développeur. Au cours de la dernière décennie, les décisions en matière de technologie sont passées de la salle de conférence aux développeurs innovants, qui construisent avec l'open source et prennent des décisions en fonction des mérites du projet sous-jacent plutôt que des relations commerciales fournies par un fournisseur. De nouveaux projets sont apparus qui visent à rendre les développeurs plus productifs, et qui sont plus faciles à gérer et à mettre à l'échelle. Cela est vrai pour pratiquement toutes les couches de la pile technologique. Le résultat est que les développeurs ont aujourd'hui des opportunités presque illimitées pour explorer de nouvelles technologies, de nouvelles architectures et de nouveaux modèles de déploiement.

En regardant en particulier la couche de données, les systèmes NoSQL tels que MongoDB, Elasticsearch et Cassandra ont repoussé les limites en termes d'agilité, d'évolutivité et de performances pour les applications opérationnelles, chacun avec un modèle de données et une approche du schéma différents. En cours de route, de nombreuses équipes de développement sont passées à un modèle de microservices, diffusant les données d'application sur de nombreux systèmes sous-jacents différents.

En termes d'analyse, d'anciennes et de nouvelles sources de données ont trouvé leur chemin dans un mélange d'entrepôts de données traditionnels et de lacs de données, certains sur Hadoop, d'autres sur Amazon S3. Et l'essor de la plate-forme de streaming de données Kafka crée une manière totalement différente de penser le mouvement des données et l'analyse des données en mouvement.

Avec des données dans tant de technologies différentes et de formats sous-jacents, l'analyse des données modernes est difficile. Les outils de BI et d'analyse tels que Tableau, Power BI, R, Python et les modèles d'apprentissage automatique ont été conçus pour un monde dans lequel les données vivent dans une seule base de données relationnelle hautes performances. En outre, les utilisateurs de ces outils - analystes métier, data scientists et modèles de machine learning - veulent pouvoir accéder, explorer et analyser les données par eux-mêmes, sans aucune dépendance à l'informatique.

Présentation de la structure de données Dremio

Les outils de BI, les systèmes de science des données et les modèles d'apprentissage automatique fonctionnent mieux lorsque les données se trouvent dans une seule base de données relationnelle hautes performances. Malheureusement, ce n'est pas là que les données vivent aujourd'hui. En conséquence, le service informatique n'a d'autre choix que de combler cet écart en combinant le développement ETL personnalisé et des produits propriétaires. Dans de nombreuses entreprises, la pile d'analyse comprend les couches suivantes:

  • Mise en scène des données . Les données sont déplacées de diverses bases de données opérationnelles vers une seule zone de transit telle qu'un cluster Hadoop ou un service de stockage cloud (par exemple, Amazon S3).
  • Entrepôt de données . S'il est possible d'exécuter des requêtes SQL directement sur Hadoop et le stockage cloud, ces systèmes ne sont tout simplement pas conçus pour offrir des performances interactives. Par conséquent, un sous-ensemble des données est généralement chargé dans un entrepôt de données relationnelles ou une base de données MPP.
  • Cubes, tables d'agrégation et extraits BI . Afin de fournir des performances interactives sur de grands ensembles de données, les données doivent être pré-agrégées et / ou indexées en créant des cubes dans un système OLAP ou des tables d'agrégation matérialisées dans l'entrepôt de données.

Cette architecture multicouche présente de nombreux défis. Il est complexe, fragile et lent et crée un environnement dans lequel les consommateurs de données dépendent entièrement de l'informatique.

Dremio introduit un nouveau niveau d'analyse de données que nous appelons un data fabric en libre-service. Dremio est un projet open source qui permet aux analystes commerciaux et aux data scientists d'explorer et d'analyser toutes les données à tout moment, quels que soient leur emplacement, leur taille ou leur structure. Dremio combine une architecture évolutive avec une exécution et une accélération en colonnes pour obtenir des performances interactives sur n'importe quel volume de données, tout en permettant aux informaticiens, aux data scientists et aux analystes commerciaux de façonner de manière transparente les données en fonction des besoins de l'entreprise.

Basé sur Apache Arrow, Apache Parquet et Apache Calcite

Dremio utilise un stockage et une exécution en colonnes hautes performances, alimentés par Apache Arrow (colonne en mémoire) et Apache Parquet (colonne sur disque). Dremio utilise également Apache Calcite pour l'analyse SQL et l'optimisation des requêtes, en s'appuyant sur les mêmes bibliothèques que de nombreux autres moteurs SQL, tels qu'Apache Hive.

Apache Arrow est un projet open source qui permet le traitement et l'échange de données en mémoire en colonnes. Arrow a été créé par Dremio et comprend des committers de diverses sociétés, notamment Cloudera, Databricks, Hortonworks, Intel, MapR et Two Sigma.

Dremio est le premier moteur d'exécution construit à partir de zéro sur Apache Arrow. En interne, les données en mémoire sont conservées hors du tas au format Arrow et il y aura bientôt une API qui renvoie les résultats de la requête sous forme de tampons de mémoire Arrow.

Divers autres projets ont également adopté Arrow. Python (Pandas) et R font partie de ces projets, permettant aux data scientists de travailler plus efficacement avec les données. Par exemple, Wes McKinney, créateur de la populaire bibliothèque Pandas, a récemment démontré comment Arrow permet aux utilisateurs de Python de lire des données dans Pandas à plus de 10 Go / s.

Comment Dremio active les données en libre-service

Outre la possibilité de travailler de manière interactive avec leurs ensembles de données, les ingénieurs de données, les analystes commerciaux et les scientifiques des données ont également besoin d'un moyen de gérer les données de manière à ce qu'elles soient adaptées aux besoins d'un projet spécifique. Il s'agit d'un changement fondamental par rapport au modèle centré sur l'informatique, dans lequel les consommateurs de données lancent une demande pour un ensemble de données et attendent que le service informatique réponde à leur demande des semaines ou des mois plus tard. Dremio permet un modèle en libre-service, dans lequel les consommateurs de données utilisent les capacités de curation de données de Dremio pour découvrir, gérer, accélérer et partager des données de manière collaborative sans dépendre de l'informatique.

Toutes ces fonctionnalités sont accessibles via une interface utilisateur Web moderne et intuitive:

  • Découvrez . Dremio comprend un catalogue de données unifié dans lequel les utilisateurs peuvent découvrir et explorer des ensembles de données physiques et virtuels. Le catalogue de données est automatiquement mis à jour lorsque de nouvelles sources de données sont ajoutées et à mesure que les sources de données et les ensembles de données virtuels évoluent. Toutes les métadonnées sont indexées dans un index de recherche haute performance et exposées aux utilisateurs via l'interface Dremio.
  • Curate . Dremio permet aux utilisateurs de gérer les données en créant des ensembles de données virtuels. Diverses transformations pointer-cliquer sont prises en charge et les utilisateurs avancés peuvent utiliser la syntaxe SQL pour définir des transformations plus complexes. Au fur et à mesure que les requêtes s'exécutent dans le système, Dremio apprend les données, ce qui lui permet de recommander diverses transformations telles que des jointures et des conversions de types de données.
  • Dremio est capable d'accélérer les ensembles de données jusqu'à 1000 fois par rapport aux performances du système source. Les utilisateurs peuvent voter pour des ensembles de données qui, selon eux, devraient être plus rapides, et l'heuristique de Dremio prendra en compte ces votes pour déterminer les ensembles de données à accélérer. En option, les administrateurs système peuvent déterminer manuellement les ensembles de données à accélérer.
  • Dremio permet aux utilisateurs de partager des données en toute sécurité avec d'autres utilisateurs et groupes. Dans ce modèle, un groupe d'utilisateurs peut collaborer sur un jeu de données virtuel qui sera utilisé pour un travail analytique particulier. Les utilisateurs peuvent également télécharger leurs propres données, telles que des feuilles de calcul Excel, pour les joindre à d'autres ensembles de données à partir du catalogue d'entreprise. Les créateurs d'ensembles de données virtuels peuvent déterminer quels utilisateurs peuvent interroger ou modifier leurs ensembles de données virtuels. C'est comme Google Docs pour vos données.

Fonctionnement de l'accélération des données Dremio

Dremio utilise des représentations physiques hautement optimisées des données sources appelées Réflexions de données. Le Reflection Store peut vivre sur HDFS, MapR-FS, un stockage cloud tel que S3 ou un stockage en attachement direct (DAS). La taille du magasin de réflexion peut dépasser celle de la mémoire physique. Cette architecture permet à Dremio d'accélérer plus de données à moindre coût, ce qui se traduit par un taux de réussite du cache beaucoup plus élevé par rapport aux architectures traditionnelles à mémoire seule. Les réflexions de données sont automatiquement utilisées par l'optimiseur basé sur les coûts au moment de la requête.

Les réflexions de données sont invisibles pour les utilisateurs finaux. Contrairement aux cubes OLAP, aux tables d'agrégation et aux extraits BI, l'utilisateur ne se connecte pas explicitement à une réflexion de données. Au lieu de cela, les utilisateurs émettent des requêtes sur le modèle logique et l'optimiseur de Dremio accélère automatiquement la requête en tirant parti des réflexions de données adaptées à la requête en fonction de l'analyse des coûts de l'optimiseur.

Lorsque l'optimiseur ne peut pas accélérer la requête, Dremio utilise son moteur d'exécution distribuée haute performance, tirant parti du traitement en mémoire en colonnes (via Apache Arrow) et des push-down avancés dans les sources de données sous-jacentes (lorsqu'il s'agit de sources RDBMS ou NoSQL).

Comment Dremio gère les requêtes SQL

Les applications clientes envoient des requêtes SQL à Dremio via ODBC, JDBC ou REST. Une requête peut impliquer un ou plusieurs ensembles de données, résidant potentiellement dans différentes sources de données. Par exemple, une requête peut être une jointure entre une table Hive, Elasticsearch et plusieurs tables Oracle.

Dremio utilise deux techniques principales pour réduire la quantité de traitement requise pour une requête:

  • Push-downs dans la source de données sous-jacente . L'optimiseur prendra en compte les capacités de la source de données sous-jacente et les coûts relatifs. Il générera ensuite un plan qui exécute les étapes de la requête soit dans la source ou dans l'environnement d'exécution distribuée de Dremio pour obtenir le plan global le plus efficace possible.
  • Accélération via les réflexions de données . L'optimiseur utilisera des réflexions de données pour des parties de la requête lorsque cela produit le plan global le plus efficace. Dans de nombreux cas, l'intégralité de la requête peut être traitée à partir de Data Reflections, car elles peuvent être des ordres de grandeur plus efficaces que le traitement des requêtes dans la source de données sous-jacente.

Requêtes déroulantes

Dremio est capable de pousser le traitement vers le bas dans des sources de données relationnelles et non relationnelles. Les sources de données non relationnelles ne prennent généralement pas en charge SQL et ont des capacités d'exécution limitées. Un système de fichiers, par exemple, ne peut pas appliquer de prédicats ou d'agrégations. MongoDB, en revanche, peut appliquer des prédicats et des agrégations, mais ne prend pas en charge toutes les jointures. L'optimiseur Dremio comprend les capacités de chaque source de données. Lorsqu'il est le plus efficace, Dremio transmettra autant de requêtes que possible à la source sous-jacente et effectuera le reste dans son propre moteur d'exécution distribué.

Déchargement des bases de données opérationnelles

La plupart des bases de données opérationnelles sont conçues pour des charges de travail optimisées en écriture. En outre, ces déploiements doivent répondre à des SLA stricts, car tout temps d'arrêt ou toute dégradation des performances peut avoir un impact significatif sur l'entreprise. En conséquence, les systèmes opérationnels sont souvent isolés du traitement des requêtes analytiques. Dans ces cas, Dremio peut exécuter des requêtes analytiques à l'aide de Data Reflections, qui fournissent le traitement de requête le plus efficace possible tout en minimisant l'impact sur le système opérationnel. Les réflexions de données sont mises à jour périodiquement en fonction de politiques qui peuvent être configurées table par table.

Phases d'exécution des requêtes

La durée de vie d'une requête comprend les phases suivantes:

  1. Le client soumet la requête au coordinateur via ODBC / JDBC / REST
  2. Planification
    1. Le coordinateur analyse la requête dans le modèle relationnel universel de Dremio
    2. Le coordinateur prend en compte les statistiques disponibles sur les sources de données pour développer un plan de requête, ainsi que les capacités fonctionnelles de la source
  3. Le coordinateur réécrit le plan de requête à utiliser
    1. les réflexions de données disponibles, en tenant compte de l'ordre, du partitionnement et de la distribution des réflexions de données et
    2. les capacités disponibles de la source de données
  4. Exécution
  1. Les exécuteurs lisent les données dans les tampons Arrow à partir de sources en parallèle
    1. Les exécuteurs exécutent le plan de requête réécrit.
    2. Un exécuteur testamentaire fusionne les résultats d'un ou plusieurs exécuteurs testamentaires et transmet les résultats finaux au coordinateur
  1. Le client reçoit les résultats du coordinateur

Notez que les données peuvent provenir de Data Reflections ou des sources de données sous-jacentes. Lors de la lecture à partir d'une source de données, l'exécuteur soumet les requêtes natives (par exemple MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) comme déterminé par l'optimiseur dans la phase de planification.

Toutes les opérations de données sont effectuées sur le nœud exécuteur, ce qui permet au système de s'adapter à de nombreux clients simultanés en utilisant seulement quelques nœuds de coordination.

Exemple de requête déroulante

Pour illustrer comment Data Fabric s'intègre dans votre architecture de données, examinons de plus près l'exécution d'une requête SQL sur une source qui ne prend pas en charge SQL.

L'une des sources de données modernes les plus populaires est Elasticsearch. Il y a beaucoup à aimer à propos d'Elasticsearch, mais en termes d'analyse, il ne prend pas en charge SQL (y compris les jointures SQL). Cela signifie que des outils tels que Tableau et Excel ne peuvent pas être utilisés pour analyser les données des applications créées sur ce magasin de données. Il existe un projet de visualisation appelé Kibana qui est populaire pour Elasticsearch, mais Kibana est conçu pour les développeurs. Ce n'est pas vraiment pour les utilisateurs professionnels.

Dremio facilite l'analyse des données dans Elasticsearch avec n'importe quel outil basé sur SQL, y compris Tableau. Prenons par exemple la requête SQL suivante pour les données commerciales de Yelp, qui sont stockées dans JSON:

SELECT état, ville, nom, review_count

DE Elastic.yelp.business

  état NOT IN ('TX', 'UT', 'NM', 'NJ') ET

  review_count> 100

ORDER BY review_count DESC, état, ville

LIMITE 10

Dremio compile la requête dans une expression qu'Elasticsearch peut traiter: