De strijd tussen de SQL-on-Hadoop engines is begonnen

Dit jaar was het glashelder op de Strata Conference in San Jose in Californië: De strijd tussen de SQL-on-Hadoop engines is losgebarsten. Veel bestaande en nieuwe leveranciers toonden daar trots hun implementatie op de beursvloer en daarnaast waren veel sessies aan dit onderwerp gewijd.

Zo populair als NoSQL vorig jaar was, zo populair is SQL-on-Hadoop op dit moment. Enkele van de vele implementaties zijn: Apache Hive, CitusDB, Cloudera Impala, ConcurrencyLingual, Hadapt, InfiniDB, JethroData, MammothDB, MapR Drill, MemSQL, PivotalHawQ, ProgressDataDirect, ScleraDB, Simba en SpliceMachine.

Naast deze implementaties moeten eigenlijk ook alle datavirtualisatie-producten genoemd worden. Deze producten zijn ontworpen om allerlei soorten gegevensbronnen (waaronder Hadoop) te benaderen en om gegevens vanuit verschillende gegevensbronnen te integreren. Voorbeelden zijn Cirro, Cisco/Composite, Denodo, Informatica IDS, RedHat JBoss Data Virtualization en Stonebond.

Natuurlijk zijn er enkele SQL database servers die polyglot persistence ondersteunen. Dit betekent dat zij hun gegevens in hun eigen SQL database of in Hadoop kunnen opslaan. Voorbeelden zijn EMC/Greenplum UAP, Microsoft Polybase, Actian Paraccell en Teradata Aster database (SQL-H).

De meeste van deze implementaties worden momenteel beperkt tot het bevragen van gegevens die zijn opgeslagen in Hadoop, maar sommige, zoals SpliceMachine, ondersteunen transacties op Hadoop. De meeste maken geen gebruik van indexen, alhowel JethroData dat weer wel doet.

Deze aandacht voor SQL-on-Hadoop is natuurlijk begrijpelijk. Door middels een SQL interface alle big data die in HDFS is opgeslagen beschikbaar te maken, kunnen talloze tools voor rapportage en analyse tools deze gegevens benaderen. Het maakt big data geschikt voor de massa. Het is dan niet alleen meer voor de “happy few” die goed Java kunnen programmeren.

Bent u geïnteresseerd in SQL-on-Hadoop, dan moet u tenminste twee technische aspecten bestuderen. Ten eerste, hoe efficiënt zijn deze engines bij het uitvoeren van joins? Vooral het koppelen van meerdere grote tabellen is een grote technologische uitdaging. Ten tweede, het is relatief eenvoudig één query snel uit te voeren, maar hoe goed zijn deze engines in staat hun workload te beheren als meerdere queries met verschillende kenmerken tegelijkertijd uitgevoerd moeten worden? Met andere woorden, hoe goed beheren deze engines de query workload? Kan een query zo veel resources gebruiken dat alle andere queries staan te wachten? Laat u dus niet teveel beïnvloeden door single-user benchmarks.

Het is niet moeilijk te voorspellen dat er nog veel meer van deze SQL-on-Hadoop implementaties uitgebracht zullen gaan worden. Dat de bestaande producten zullen verbeteren en sneller zullen worden, is ook wel duidelijk. De kernvraag is welke van deze implementaties de strijd zullen overleven. Het is voor de hand liggend dat ze niet allemaal een groot commercieel succes zullen worden, maar voor klanten is het wel belangrijk dat een gekozen product na een aantal jaar nog steeds bestaat. Dit is vandaag de dag moeilijk te voorspellen omdat de markt snel verandert. Laten we maar gaan bekijken hoe deze grote groep producten er volgend jaar op Strata bij staat.