Presto : le moteur de traitement qui réconcilie Big Data et temps réel
Presto est un outil conçu pour interroger de grandes quantités de données à l'aide de requêtes SQL distribuées. Il a été écrit en Java par les développeurs de Facebook pour les besoins internes du réseau social. Utilisant initialement Hadoop (HDFS et MapReduce) et Hive, Facebook a vu ses volumes de données à traiter augmenter inexorablement. La plateforme Hadoop utilisée alors ne répondait plus à l'accélération des cycles de production du réseau social. C'est ainsi que Presto est né en 2012, avec comme objectif de permettre aux salariés d'accéder via des requêtes SQL aux données stockées sur HDFS. Presto peut traiter des données allant du téraoctet aux centaines de pétaoctets, avec une vitesse qui le rend compatible avec les productivités quotidiennes du réseau social.
En 2013, Presto a été mis à la disposition par Facebook des contributeurs open source, sous licence Apache v2. Depuis, il a fait son chemin dans les entreprises les plus consommatrices de données. Presto a été conçu comme une alternative aux outils qui interrogent HDFS et utilisant MapReduce tels que Hive ou Pig, mais il n'est pas limité à HDFS. Son usage a été étendu pour fonctionner sur différents types de sources de données, y compris les bases de données relationnelles conventionnelles (comme MySQL,) et d'autres sources de données telles Cassandra, et même Kafka.
Un moteur soutenu par des acteurs majeurs
Un des avantages de Presto est de s'insérer dans les architectures hétérogènes complexes, telles qu'on les trouve dans les entreprises. C'est l'une des raisons de son succès auprès d'entreprise comme Dropbox, Netflix et Airbnb. Cette technologie bénéficie également de l'apport de contributeurs de marque : outre Facebook, son créateur, Teradata, Netflix et Airbnb figurent parmi les plus actifs.
Côté prestataires de service, Teradata a été l'un des premiers à annoncer un service commercial de support de Presto. "Nous avons toujours été orientés vers des solutions analytiques", explique Charles-Yves Baudet, porte-parole de Teradata. "Nous nous sommes intéressés à Presto pour pouvoir fournir une solution analytique complète à nos clients." Teradata a ainsi développé des pilotes ODBC et JDBC pour Presto. Ces derniers ont pour objectif de rendre le moteur de requêtes open source plus adapté à une utilisation en entreprise, avec, à la clé, de nombreuses applications de business intelligence et de traitement analytique. "Ils fournissent la connectivité et le protocole nécessaires au transfert de la requête et de son résultat entre l'application et la base de données", précise-t-on chez Teradata.
Un moteur de requête agnostique, mais avec les performances d'une base relationnelle
Le but de Teradat était d'étendre l'usage de Presto aux grands comptes en le sortant du ghetto du web analytics. "Le moteur SQL de Presto permet de l'intégrer dans l'existant et de traiter les données de manière interactive", explique Thibault Storai, expert technique architecture Big Data chez Teradata. "Il permet d'avoir l'interactivité d'une base relationnelle, d'aller chercher des données sur tous types de bases de données, le tout au sein du même environnement."
Les développeurs de Presto avaient comme consigne de concevoir un outil de requêtes SQL qui offre les avantages des moteurs SQL du marché ainsi que des performances compatibles avec un usage quotidien, et ce, quelle que soit la taille de l'entrepôt de données. Il s'agissait de s'approcher le plus possible d'un traitement en temps réel, le seul compatible avec la productivité quotidienne de Facebook. Le pari aurait été relevé avec succès, car, selon ses créateurs, Presto est dix fois plus rapide que le framework Hive/MapReduce. Une performance qui découle d'une architecture distribuée (voir diagramme ci-dessous) et d'un mode de fonctionnement qui privilégie l'exécution des différentes étapes directement en mémoire, alors que le couple Hive/MapReduce utilise l'écriture sur disque pour stocker les résultats intermédiaires, ce qui ralentit le processus. Concrètement, Hive traduit chaque requête en de multiples tâches MapReduce et les exécute séquentiellement. Chaque tâche lit les données à partir des serveurs de stockage et écrit les résultats intermédiaires sur le support de stockage.
Presto a toutefois ses limites
Presto a été conçu pour fonctionner sur des clusters dont l'architecture repose sur un coordinateur et des workers (nœuds d'exécution). En pratique, les requêtes sont prises en main par le coordinateurs, dont le parser analyse et coordonne l'exécution de la requête. Celui-ci transfère ensuite les tâches au scheduler (plannificateur) qui coordonne les tunnels d'exécution, distribue le travail aux différents nœuds, de préférence les plus proches des données, et surveille les progrès. Le tout s'exécute en mémoire, avec une consommation réduite des ressources et des entrées/sorties, responsables d'overheads donc de latences.
Durant le processus, les pipelines s'exécutent simultanément et transmettent les données résultantes, d'où une chaîne de traitement en continu. C'est un avantage indéniable mais qui a ses limites selon Thibault Storai. "Le souci avec Presto c'est qu'il exécute de multiples requêtes sur des volumes limités", explique l'expert. "Le traitement se faisant in-memory, il est soumis aux contraintes mémoires. Il est limité à la mémoire dédiée à Presto sur chaque nœuds et n'a pas pour l'instant la possibilité d'utiliser le stockage disque. Le but de Presto n'est pas de remplacer Hive, qui reste très approprié pour tout ce qui est batch computing." Dans certains cas, les deux technologies peuvent donc se révéler complémentaires.