Por qué debería usar Presto para análisis ad hoc

¡Presto! No es solo un encantamiento para entusiasmar a su audiencia después de un truco de magia, sino también un nombre que se usa cada vez más cuando se habla de cómo generar grandes volúmenes de datos. Si bien hay muchas implementaciones de Presto en la naturaleza, la tecnología, un motor de consultas SQL distribuido que admite todo tipo de fuentes de datos, sigue siendo desconocida para muchos desarrolladores y analistas de datos que podrían beneficiarse de su uso.

En este artículo, hablaré sobre Presto: qué es, de dónde viene, en qué se diferencia de otras soluciones de almacenamiento de datos y por qué debería considerarlo para sus soluciones de big data.

Presto contra Hive

Presto se originó en Facebook en 2012. De código abierto en 2013 y administrado por la Fundación Presto (parte de la Fundación Linux), Presto ha experimentado un aumento constante en popularidad a lo largo de los años. Hoy en día, varias empresas han construido un modelo de negocio en torno a Presto, como Ahana, con ofertas de análisis ad hoc basadas en PrestoDB.

Presto se creó como un medio para proporcionar a los usuarios finales acceso a enormes conjuntos de datos para realizar análisis ad hoc. Antes de Presto, Facebook usaba Hive (también construido por Facebook y luego donado a la Apache Software Foundation) para realizar este tipo de análisis. A medida que crecían los conjuntos de datos de Facebook, se descubrió que Hive no era lo suficientemente interactivo (léase: demasiado lento). Esto se debió en gran parte a que la base de Hive es MapReduce, que, en ese momento, requería que los conjuntos de datos intermedios se conservaran en HDFS. Eso significó una gran cantidad de E / S al disco para los datos que finalmente se desecharon. 

Presto adopta un enfoque diferente para ejecutar esas consultas para ahorrar tiempo. En lugar de mantener los datos intermedios en HDFS, Presto le permite guardar los datos en la memoria y realizar operaciones con los datos allí en lugar de conservar todos los conjuntos de datos intermedios en el disco. Si eso le suena familiar, es posible que haya oído hablar de Apache Spark (o cualquier otra tecnología disponible) que tiene el mismo concepto básico para reemplazar de manera efectiva las tecnologías basadas en MapReduce. Con Presto, mantendré los datos donde residen (en Hadoop o, como veremos, en cualquier lugar) y realizaré las ejecuciones en la memoria en todo nuestro sistema distribuido, barajando los datos entre servidores según sea necesario. Evito tocar cualquier disco, lo que finalmente acelera el tiempo de ejecución de la consulta.

Cómo actúa Presto

A diferencia de un almacén de datos tradicional, Presto se conoce como motor de ejecución de consultas SQL. Los almacenes de datos controlan cómo se escriben los datos, dónde residen y cómo se leen. Una vez que ingresa los datos en su almacén, puede resultar difícil recuperarlos. Presto adopta otro enfoque al desacoplar el almacenamiento de datos del procesamiento, al tiempo que brinda soporte para el mismo lenguaje de consulta ANSI SQL al que está acostumbrado.

En esencia, Presto ejecuta consultas sobre conjuntos de datos proporcionados por complementos, específicamente Conectores. Un conector proporciona un medio para que Presto lea (e incluso escriba) datos en un sistema de datos externo. El conector de Hive es uno de los conectores estándar y utiliza los mismos metadatos que usaría para interactuar con HDFS o Amazon S3. Debido a esta conectividad, Presto es un reemplazo directo para las organizaciones que usan Hive en la actualidad. Puede leer datos de los mismos esquemas y tablas utilizando los mismos formatos de datos: ORC, Avro, Parquet, JSON y más. Además del conector de Hive, encontrará conectores para Cassandra, Elasticsearch, Kafka, MySQL, MongoDB, PostgreSQL y muchos otros. Los conectores se aportan a Presto todo el tiempo, lo que le da a Presto el potencial de poder acceder a los datos en cualquier lugar donde viva.

La ventaja de este modelo de almacenamiento desacoplado es que Presto puede proporcionar una única vista federada de todos sus datos, sin importar dónde residan. Esto aumenta las capacidades de las consultas ad hoc a niveles nunca antes alcanzados, mientras que también proporciona tiempos de consulta interactivos en sus grandes conjuntos de datos (siempre que tenga la infraestructura para respaldarlos, en las instalaciones o en la nube).

Echemos un vistazo a cómo se implementa Presto y cómo se realiza la ejecución de sus consultas. Presto está escrito en Java y, por lo tanto, requiere un JDK o JRE para poder iniciarse. Presto se implementa como dos servicios principales, un solo coordinador y muchos trabajadores . El servicio de Coordinador es efectivamente el cerebro de la operación, recibe solicitudes de consulta de los clientes, analiza la consulta, crea un plan de ejecución y luego programa el trabajo a realizar en muchos servicios de trabajador. Cada trabajador procesa una parte de la consulta general en paralelo, y puede agregar servicios de trabajador a su implementación de Presto para adaptarse a su demanda. Cada fuente de datos se configura como un catálogo y puede consultar tantos catálogos como desee en cada consulta.

Ahana

Se accede a Presto a través de un controlador JDBC y se integra con prácticamente cualquier herramienta que pueda conectarse a bases de datos usando JDBC. La interfaz de línea de comandos de Presto, o CLI, suele ser el punto de partida cuando se comienza a explorar Presto. De cualquier manera, el cliente se conecta al Coordinador para emitir una consulta SQL. Esa consulta es analizada y validada por el Coordinador y se integra en un plan de ejecución de consultas. Este plan detalla cómo los trabajadores de Presto ejecutarán una consulta. El plan de consulta (normalmente) comienza con uno o más escaneos de tablas para extraer datos de sus almacenes de datos externos. Luego hay una serie de operadores para realizar proyecciones, filtros, uniones, agrupaciones, órdenes y todo tipo de operaciones. El plan finaliza con la entrega del conjunto de resultados finales al cliente a través del Coordinador.Estos planes de consultas son vitales para comprender cómo Presto ejecuta sus consultas, además de poder analizar el rendimiento de las consultas y encontrar posibles cuellos de botella.

Ejemplo de consulta de Presto

Echemos un vistazo a una consulta y el plan de consulta correspondiente. Usaré una consulta TPC-H, una herramienta común de evaluación comparativa utilizada para bases de datos SQL. En resumen, TPC-H define un conjunto estándar de tablas y consultas para probar la integridad del lenguaje SQL, así como un medio para comparar varias bases de datos. Los datos están diseñados para casos de uso empresarial, que contienen pedidos de venta de artículos que pueden ser proporcionados por una gran cantidad de suministros. Presto proporciona un conector TPC-H que genera datos sobre la marcha, una herramienta muy útil al revisar Presto.

SELECCIONE

  SUM (l.precio extendido * l.descuento) AS ingresos

DESDE lineitem l

DÓNDE

  l.shipdate> = DATE '1994-01-01'

   Y l. Fecha de envío <FECHA '1994-01-01' + INTERVALO '1' AÑO

   Y l. Descuento ENTRE .06 - 0.01 Y .06 + 0.01

   Y l. Cantidad <24;

Esta es la consulta número seis, conocida como Consulta de cambio de ingresos por pronóstico. Citando la documentación de TPC-H, "esta consulta cuantifica la cantidad de aumento de ingresos que habría resultado de eliminar ciertos descuentos en toda la empresa en un rango de porcentaje dado en un año determinado".

Presto divide una consulta en una o más etapas, también llamadas fragmentos , y cada etapa contiene múltiples operadores . Un operador es una función particular del plan que se ejecuta, ya sea un escaneo, un filtro, una unión o un intercambio. Los intercambios a menudo rompen las etapas. Un intercambio es la parte del plan donde los datos se envían a través de la red a otros trabajadores en el clúster de Presto. Así es como Presto logra proporcionar su escalabilidad y rendimiento, al dividir una consulta en múltiples operaciones más pequeñas que se pueden realizar en paralelo y permitir que los datos se redistribuyan en el clúster para realizar uniones, agrupaciones y ordenamiento de conjuntos de datos. Veamos el plan de consultas distribuidas para esta consulta. Tenga en cuenta que los planes de consulta se leen de abajo hacia arriba.

 Fragmento 0 [SINGLE]

     - Salida [ingresos] => [suma: doble]       

             ingresos: = suma   

         - Agregado (FINAL) => [suma: doble]         

                 suma: = "presto.default.sum" ((sum_4))          

             - LocalExchange [SINGLE] () => [sum_4: double]  

                 - RemoteSource [1] => [sum_4: double]      

 Fragmento 1 

     - Agregado (PARCIAL) => [suma_4: doble]  

             sum_4: = "presto.default.sum" ((expr))  

         - ScanFilterProject [table = TableHandle {connectorId = 'tpch', connectorHandle = "lineitem: sf1.0", layout = "Opcional [lineitem: sf1.0]"}, agrupado = falso, filterPredicate = ((descuento BETWEEN (DOUBLE 0.05 ) Y (DOBLE 0.07)) Y ((cantidad) = (FECHA 1994-01-01)) Y ((fecha de envío) [expr: doble]

                 expr: = (precio extendido) * (descuento)   

                 extendedprice := tpch:extendedprice

                 discount := tpch:discount         

                 shipdate := tpch:shipdate 

                 quantity := tpch:quantity  

This plan has two fragments containing several operators. Fragment 1 contains two operators. The ScanFilterProject scans data, selects the necessary columns (called projecting) needed to satisfy the predicates, and calculates the revenue lost due to the discount for each line item. Then a partial Aggregate operator calculates the partial sum. Fragment 0 contains a LocalExchange operator that receives the partial sums from Fragment 1, and then the final aggregate to calculate the final sum. The sum is then output to the client.

When executing the query, Presto scans data from the external data source in parallel, calculates the partial sum for each split, and then ships the result of that partial sum to a single worker so it can perform the final aggregation. Running this query, I get about $123,141,078.23 in lost revenue due to the discounts.

      revenue       

----------------------

 1.2314107822830005E8

As queries grow more complex, such as joins and group-by operators, the query plans can get very long and complicated. With that said, queries break down into a series of operators that can be executed in parallel against data that is held in memory for the lifetime of the query.

As your data set grows, you can grow your Presto cluster in order to maintain the same expected runtimes. This performance, combined with the flexibility to query virtually any data source, can help empower your business to get more value from your data than ever before — all while keeping the data where it is and avoiding expensive transfers and engineering time to consolidate your data into one place for analysis. Presto!

Ashish Tadose is co-founder and principal software engineer at Ahana. Passionate about distributed systems, Ashish joined Ahana from WalmartLabs, where as principal engineer he built a multicloud data acceleration service powered by Presto while leading and architecting other products related to data discovery, federated query engines, and data governance. Previously, Ashish was a senior data architect at PubMatic where he designed and delivered a large-scale adtech data platform for reporting, analytics, and machine learning. Earlier in his career, he was a data engineer at VeriSign. Ashish is also an Apache committer and contributor to open source projects.

New Tech Forum proporciona un lugar para explorar y discutir la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra selección de las tecnologías que creemos que son importantes y de mayor interés para los lectores. no acepta material de marketing para su publicación y se reserva el derecho de editar todo el contenido contribuido. Envíe todas sus consultas a [email protected]