← blog

El estado actual del “SQL para Hadoop”

Desde la adopción masiva de Hadoop, muchas herramientas open-source y propietarias han aparecido que tratan de resolver el problema de “hacer consultas sobre Hadoop”. Hadoop comenzó como un simple (aunque poderoso) framework Big Data consistente en (1) una capa de almacenamiento (HDFS, inspirado GFS) y (2) una capa de procesamiento (una implementación de MapReduce). Al cabo de dos años las primeras releases de HBase (inspirado por BigTable) comenzaron a hacer los datos en Hadoop más recuperables.  Después de eso, muchas NoSQL’s comenzaron a trabajar en conectores Hadoop (SOLR-1301 fue uno de los primeros). Aun y así, el problema de “hacer consultas sobre Hadoop” siguió estando no resuelto en dos ejes principales:

  • Flexibilidad: Los motores de consultas fuera de Hadoop tenían características muy variables y lenguajes de consulta muy diferentes. Muchas NoSQL’s estaban limitadas por naturaleza a llave/valor. Elegir una NoSQL siempre implicaría un “tradeoff”, y elegir más de una (concepto “Polyglot Persistence”) hacía las cosas más complicadas aun.
  • Integración: Hacer que los datos de Hadoop fueran accesibles por un motor de consultas era un reto en sí mismo (¿Cómo se integra ésta base de datos con Hadoop? ¿Cómo es el conector? ¿Cómo de maduro es? ¿Y cómo de eficiente es? ¿Puedo actualizar todos los datos desde Hadoop de forma atómica, en una “gran transacción”?).


Después de unos años de fuerte tendencia “NoSQL”, voces del pasado anunciado “SQL” aparecieron como una posible solución a los problemas en la flexibilidad para hacer consultas sobre Hadoop. Es verdad que Sqoop (tan viejo como HADOOP-5815) ya hizo posible conectar Hadoop con bases de datos relacionales, pero eso no resolvía de forma satisfactoria la parte de integración. También es verdad que el “Batch SQL” ya existe desde las primeras releases de Hive (finales de 2008), pero tal tipo de latencias nunca ofrecieron la posibilidad de hacer consultas sobre Hadoop, sino más bien la posibilidad de evitar escribir código MapReduce.

Aunque SQL es un lenguaje con más de 40 años, tiene muchos elementos que lo hacen conveniente como un lenguaje de consultas para Hadoop:

  • Provee la flexibilidad necesaria para calcular agregaciones sin necesidad de pre-calcularlas todas de antemano.
  • Le resulta familiar a mucha gente y a las compañías, con lo que se puede reusar conocimiento.
  • Soporta joins, evitando que el modelo de datos subyacente haya de ser denormalizado totalmente.
  • Hace posible la integración con herramientas de BI y visualización a través de JDBC u ODBC.

La escalada de soluciones “SQL para Hadoop” en los últimos años puede ser también explicada por la madurez que Hadoop ha alcanzado. Como Hadoop está siendo realmente adoptado por más y más compañías, éstas han presionado al mercado para ofrecer SQL por encima de Hadoop. Como ejemplo, cada vez vemos más y más data warehouses mixtos (este paper es una buena referencia de ello).

En este post vamos a revisar el estado actual de los motores “SQL para Hadoop”. Proveeremos una tabla con los casos de uso que cada motor soporta mejor, es decir: (1) Batch SQL (procesos largos que leen y escriben cantidades arbitrarias de datos), (2) Consultas interactivas (consultas ad-hoc en tiempos comparables a las bases de datos MPP, en el orden de segundos o minutos), (3) Consultas de muy baja latencia (lecturas por debajo del segundo, para aplicaciones web y móviles) y (4) SQL operacional (lecturas y escrituras, transacciones ACID, etc). A veces un motor tendrá varios casos de uso disponibles, lo cual no es raro. Vamos a intentar mostrar soluciones no muy conocidas, ya que los informes parecidos actuales se basan sólo en motores muy conocidos. También daremos más peso a las soluciones de código abierto.

Hay muchos detalles que tener en cuenta al evaluar cada una de éstas herramientas, es muy difícil compararlas (aunque MapR hizo un buen trabajo en éste post). Recomendamos analizarlas todas en detalle en las siguientes dimensiones: comunidad, madurez, completitud del SQL soportado, JDBC/ODBC, si son sólo basadas en el uso de memoria o si pueden usar disco, formato de datos que soportan, etc.

  1. Hive: Una herramienta conocida en el ecosistema desde finales de 2008. Está evolucionando hacia un motor de consultas interactivo a través de “Stinger Phase III”. En el Berlin’s Big Data Beers tuvimos la oportunidad de escuchar sobre este proyecto.
  2. LINGUAL: Interfaz SQL de Cascading similar a Hive, pero que soporta ANSI SQL. Si Cascading soporta Tez en el futuro, LINGUAL también lo soportará.
  3. Apache Tajo: Proyecto Apache Top-level desde 2014-03-24, pensado tanto para Batch SQL como para queries interactivas, soporta SQL estándar y se ejecuta sobre su propio DAG tipo Tez.
  4. Impala: El popular motor SQL de Cloudera. En el Berlin’s Big Data Beers tuvimos la oportunidad de escuchar sobre su evolucion, que parece incluir el uso de disco para joins y agregaciones en el futuro.
  5. Apache Drill: Motor de consultas ad-hoc para analítica de datos, orientado a motores y formatos arbitrarios. Totalmente colaborativo y orientado a la comunidad, contrario a Impala.
  6. Shark: Capa SQL de Spark, compatible con Hive.
  7. BigSQL: Motor de consultas interactivas a través de PostgreSQL. Es algo bastante nuevo y aunque pueda parecerlo, no tiene nada que ver con el “Big SQL” de IBM.
  8. Presto: Motor SQL para Hadoop desarrollado en Facebook, con una filosofía y diseño muy similar a Apache Drill.
  9. Hadapt (antes llamado HadoopDB), tecnología propietaria que pone bases de datos relacionales (PostgreSQL) en cada nodo Hadoop, y delega ciertas queries o partes de una query a ellos.
  10. RainStor: Motor MPP SQL propietario, tiene su propio formato de almacenamiento que comprime más que ORC.
  11. Splout SQL: Motor de consultas de muy baja latencia desacoplado de Hadoop, se basa en generar ficheros SQL particionados, que permiten cualquier consulta SQL y creación de índices a voluntad.
  12. Phoenix: SQL sobre HBase a través del uso de “co-processors”, orientado a muy baja latencia, recientemente ha entrado en la Apache incubator.
  13. JethroData: Nuevo motor (no sabemos si propietario u open-source todavía) que indexa cada columna de datos tal como los datos van llegando. No hay prototipo todavía.
  14. Spire: Motor SQL real-time para Hadoop. Desde su primer announcement hemos estado preguntándonos qué pasa con este producto, pero ahora parece que ha quedado abandonado.
  15. Splice: Motor SQL operacional para Hadoop con soporte de casos de uso tanto OLTP como OLAP, con transacciones ACID, etc.
  16. HAWK: Motor propietario con EMC detrás, que reusa años de investigación y desarrollo sobre Greenplum.
Motor Batch Interactivo Muy baja latencia Operacional
Hive A través de Stinger (Tez)
LINGUAL En el futuro, si Cascading migra a Tez
Apache Tajo
Impala Más o menos, al usar HBase por debajo
Apache Drill Más o menos, al usar HBase por debajo
Shark
BigSQL
Presto Más o menos, al usar HBase por debajo
Hadapt
RainStor
Splout SQL Más o menos, limitado a una sóla partición y sin almacenamiento columnar
Phoenix
JethroData
Spire
Splice Sí (ACID)
HAWK Sí (ACID)

¿Ves algún error en la tabla anterior? ¿Crees que falta algo que debería ser mencionado? Si es así, contáctanos.



Comentar