Aprender y utilizar Presto

Capítulo 1. Introducción a Presto

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

En los últimos años, la creciente disponibilidad de diferentes datos producidos por usuarios y máquinas ha planteado nuevos retos a las organizaciones que desean dar sentido a sus datos para tomar mejores decisiones. Convertirse en una organización impulsada por los datos es crucial para encontrar ideas, impulsar el cambio y allanar el camino a nuevas oportunidades. Aunque requiere una gran cantidad de datos, los beneficios merecen la pena.

Esta gran cantidad de datos está disponible en distintos formatos, los proporcionan distintas fuentes de datos y se pueden buscar con distintos lenguajes de consulta. Además, cuando buscan información valiosa, los usuarios necesitan resultados muy rápidamente, por lo que requieren sistemas de motores de consulta de alto rendimiento. Estos retos hicieron que empresas como Facebook (ahora Meta), Airbnb, Uber y Netflix se replantearan cómo gestionan los datos. Han pasado progresivamente del antiguo paradigma basado en almacenes de datos a almacenes de lagos de datos. Mientras que un almacén de datos gestiona datos estructurados e históricos, un lago de datos también puede gestionar y obtener información de datos no estructurados y en tiempo real.

Presto es una posible solución a los retos anteriores. Presto es un motor de consultas SQL distribuido, creado y utilizado por Facebook a escala. Puedes integrar fácilmente Presto en tu lago de datos para crear consultas SQL de ejecución rápida que interactúen con los datos dondequiera que éstos se encuentren físicamente, independientemente de su formato original.

Este capítulo te introducirá en el concepto de lago de datos y en qué se diferencia del almacén de datos. A continuación, aprenderás qué es Presto, por qué se creó y por qué lo utilizan tantas empresas. También aprenderás los casos de uso más populares de Presto, como las consultas ad hoc, los informes y los cuadros de mando. Por último, te familiarizarás con el caso práctico que utilizarás a lo largo de todos los capítulos.

Almacenes y lagos de datos

Existen tres tipos principales de datos: datos estructurados, datos semiestructurados y datos no estructurados.La Tabla 1-1 muestra estos tipos de datos, con una breve descripción, los formatos típicos, los pros y los contras, y algunos ejemplos prácticos.

Tabla 1-1. Tipos de datos

	Datos estructurados	Datos semiestructurados	Datos no estructurados
Descripción	Los datos se organizan en un esquema fijo	Los datos están parcialmente organizados sin un esquema fijo	Los datos no están organizados
Formatos típicos	SQL, CSV	JSON, XML	Audio, vídeo, texto
Pros	Facilidad para obtener información	Más flexible que los datos estructurados	Muy escalable
Contras	La dependencia del esquema limita la escalabilidad	La estructura de metanivel puede contener datos no estructurados	Difícil de buscar
Ejemplos	Base de datos	Textos anotados, como tuits con hashtag	Texto sin formato, fotos digitales

En función de los tipos de datos soportados y de cómo se organicen y procesen, existen distintos sistemas de almacenamiento de datos. Un almacén de datos es un repositorio central que contiene sólo datos estructurados y se utiliza para la elaboración de informes y análisis.La Figura 1-1 muestra la arquitectura general de un almacén de datos. Hay cuatro capas principales:

Datos estructurados

Incluye datos estructurados proporcionados por múltiples fuentes (por ejemplo, sistemas de bases de datos relacionales)

Extraer, transformar y cargar (ETL)

El proceso que convierte los datos en un formato adecuado

Almacén de datos

Contiene datos listos para ser consumidos por las capas finales

Informes, cuadros de mando y minería de datos

Las capas finales que consumen los datos contenidos en el almacén de datos

Figura 1-1. Arquitectura general de un almacén de datos

Con la llegada de la era de los grandes datos, la arquitectura subyacente a los almacenes de datos ha demostrado ser insuficiente para gestionar grandes cantidades de datos. Las grandes empresas, como Facebook, tuvieron los siguientes problemas con el uso de almacenes de datos:

Datos no estructurados

Dado que un almacén de datos gestiona datos estructurados, no puede utilizarse para almacenar datos sin estructurar en bruto, como texto o audio.Debes procesar los datos sin estructurar antes de ingestarlos en un almacén de datos.

Escalabilidad

Un almacén de datos experimenta un aumento no lineal de los costes técnicos asociados a las crecientes cantidades de datos ingestados y al procesamiento analítico.

Datos en tiempo real

Un almacén de datos no es adecuado para datos casi en tiempo real, porque los datos deben estructurarse antes de poder utilizarse.

Un lago de datos aborda estas cuestiones. La Figura 1-2 muestra la arquitectura general de un lago de datos.

Figura 1-2. Arquitectura general de un lago de datos

A diferencia de un almacén de datos, un lago de datos gestiona y proporciona formas de consumir, o procesar, datos estructurados, semiestructurados y no estructurados. La ingesta de datos en bruto permite a un lago de datos ingerir datos tanto históricos como en tiempo real en un sistema de almacenamiento en bruto. Con el tiempo, el concepto de un lago de datos ha evolucionado hasta convertirse en el data lakehouse, un lago de datos aumentado que incluye soporte para transacciones en su parte superior. En la práctica, un data lakehouse modifica los datos existentes en el lago de datos, siguiendo la semántica del almacén de datos. Discutiremos el concepto de lago de datos y lo pondremos en práctica en el Capítulo 5.

Los primeros lagos de datos, llamados on-premise data lakes, se instalaban en los servidores de la empresa. La principal ventaja de este tipo de lago de datos era el control total del sistema por parte de la empresa. Con la llegada de la computación en nube, los lagos de datos se han trasladado a la nube, dejando las cuestiones de gestión, mantenimiento y seguridad a los proveedores de la nube y a sus clientes, que son ambos responsables de la seguridad de sus datos. Esto se denomina lago de datos en la nube, y su popularidad va en aumento. Las principales plataformas que proporcionan lagos de datos en la nube son Amazon Web Services (AWS), Azure y Google Cloud a través de algo llamado almacén de objetos.

Para que los datos sean accesibles a las capas superiores (cuadros de mando, informes y minería de datos), un lago de datos proporciona una capa intermedia, denominada metadatos y gobernanza, que garantiza la coherencia de los datos y los controles de seguridad.

El papel de Presto en un lago de datos

Presto es un motor de consulta SQL distribuido de código abierto que admite fuentes de datos estructuradas y semiestructuradas. Puedes utilizar Presto para consultar tus datos directamente donde se encuentran, como un lago de datos, sin necesidad de trasladarlos a otro sistema. Presto ejecuta consultas de forma concurrente mediante una arquitectura basada en memoria, lo que lo hace muy rápido y escalable.

Dentro de la arquitectura del lago de datos, puedes imaginar que Presto encaja en la capa de gobernanza y metadatos.Presto ejecuta las consultas directamente en memoria. Al evitar la necesidad de escribir y leer del disco entre etapas, en última instancia se acelera el tiempo de ejecución de la consulta.

La máquina coordinadora Presto analiza cualquier consulta escrita en SQL (compatible con el estándar ANSI SQL), crea y programa un plan de consulta en un clúster de máquinas trabajadoras Presto conectadas al lago de datos y, a continuación, devuelve los resultados de la consulta. El plan de consulta puede tener varias etapas de ejecución, dependiendo de la consulta. Por ejemplo, si tu consulta está uniendo muchas tablas grandes, puede necesitar varias etapas de ejecución, agregando las tablas. Puedes pensar en esos resultados intermedios como tu bloc de notas para un problema de cálculo largo.

Orígenes y consideraciones sobre el diseño de Presto

Presto fue implementado por Facebook en 2012 para superar los problemas derivados de Apache Hive, un motor SQL distribuido sobre el marco Hadoop MapReduce conectado a su lago de datos. Apache Hive era uno de los almacenes de datos que Facebook utilizaba en aquel momento. El principal problema de Apache Hive era su lentitud al tratar con grandes cantidades de datos.

Colmena Apache

Apache Hive también fue desarrollado originalmente y convertido en código abierto por Facebook en 2010.En aquel momento, la arquitectura subyacente a Apache Hive era MapReduce, que explotaba conjuntos de datos intermedios que se persistían en el disco. Esto requería frecuentes accesos de E/S al disco para los datos de conjuntos de resultados intermedios y transitorios.

Para superar estos problemas, Facebook desarrolló Presto, un nuevo motor de consulta SQL distribuido diseñado como motor en memoria sin necesidad de persistir conjuntos de resultados intermedios para una sola consulta. Este enfoque dio lugar a un motor de consulta que procesaba la misma consulta más rápido en órdenes de magnitud, con muchas consultas completadas con una latencia inferior a un segundo. Los usuarios finales, como ingenieros, gestores de productos y analistas de datos, descubrieron que podían consultar interactivamente subconjuntos de grandes conjuntos de datos para probar hipótesis y crear visualizaciones.

La Figura 1-3 muestra cómo ejecutan consultas Presto y Hive. Hive utiliza el marco MapReduce para ejecutar consultas. En la práctica, almacena los resultados intermedios en el disco: tanto después de la fase de mapeo como de la de reducción, los resultados intermedios se almacenan en el disco. En cambio, Presto ahorra tiempo ejecutando las consultas en la memoria de las máquinas trabajadoras, incluso realizando allí las operaciones sobre los conjuntos de datos intermedios, en lugar de persistirlos en el disco.

Figura 1-3. Cómo ejecutan consultas Presto y Hive

En 2013, Facebook hizo que el repositorio GitHub de Presto fuera de código abierto bajo la licencia Apache 2.0. Más tarde, Facebook donó el proyecto para que lo alojara la Fundación Linux, que creó una subfundación llamada Fundación Presto.

Presto se desarrolló teniendo en cuenta las siguientes consideraciones de diseño de: alto rendimiento, alta escalabilidad, cumplimiento de la norma SQL del Instituto Nacional Estadounidense de Normalización (ANSI), una federación de fuentes de datos y la capacidad de ejecutarse en la nube.

Alto rendimiento

Presto define varias reglas, entre las que se incluyen optimizaciones bien conocidas, como el pushdown de predicados y límites, la poda de columnas y la descorrelación. En la práctica, Presto puede tomar decisiones inteligentes sobre qué parte del procesamiento de la consulta puede empujarse hacia abajo en las fuentes de datos, dependiendo de las capacidades de la fuente. Por ejemplo, algunas fuentes de datos pueden evaluar predicados, agregaciones, evaluación de funciones, etc. Al acercar estas operaciones a los datos, Presto consigue mejorar significativamente el rendimiento al minimizar la E/S de disco y la transferencia de datos de red. El resto de la consulta, como unir datos de distintas fuentes de datos, será procesado por Presto.

Alta escalabilidad

Gracias a su arquitectura, que verás en , Presto puede funcionar a cualquier escala, aunque no es necesario disponer de una gran infraestructura. También puedes utilizar Presto en entornos pequeños o para crear prototipos antes de abordar un conjunto de datos mayor. Debido a su baja latencia, no hay una sobrecarga importante para ejecutar pequeñas consultas.

Cumplimiento de la norma ANSI SQL

Presto ejecuta consultas SQL, que se adhieren a la norma ANSI SQL. Como la mayoría de los usuarios ya saben escribir consultas SQL, Presto es fácilmente accesible y no requiere aprender un nuevo lenguaje. La conformidad de Presto con SQL permite de inmediato un gran número de casos de uso.

Qué significa el cumplimiento de ANSI SQL

Cumplir la norma ANSI SQL significa que los principales comandos de uso común, como SELECT, UPDATE, DELETE, INSERT, y JOIN, funcionan como cabría esperar.

Federación de Fuentes de Datos

Un motor de consulta feder ado se asigna a varias fuentes de datos, lo que permite un acceso unificado a esos sistemas, ya sea para consultas a una sola fuente de datos a la vez o para consultas federadas con varias fuentes de datos.

Presto es un motor de consulta federado que admite conectores enchufables para acceder a datos de fuentes de datos externas y escribir datos en ellas, independientemente de dónde residan. Hay muchas fuentes de datos disponibles para su integración con Presto.

Motor de consulta federado frente a consulta federada

El concepto de motor de consulta federada es ligeramente distinto del de consulta federada. Una consulta federada es una consulta única que almacena o recupera datos de varias fuentes de datos diferentes, en lugar de una única fuente de datos. Un motor de consulta federada es un motor de consulta diseñado específicamente para ejecutar consultas federadas. Presto es un motor de consultas federadas que admite consultas federadas.

La Figura 1-4 ilustra los pasos básicos de cómo un motor de consultas procesa una consulta federada.¹ Al recibir una consulta, el motor de consultas la analiza(análisis de la consulta) y accede al catálogo de fuentes para seleccionar la fuente o fuentes de datos implicadas en la consulta(selección de la fuente de datos). Como resultado, la selección de fuentes descompone la consulta en subconsultas.

Figura 1-4. Pasos básicos del procesamiento federado de consultas

El siguiente paso consiste en construir un plan lógico(optimización de la consulta), que define cómo se ejecuta la consulta y qué operadores (JOIN, UNION, FILTER, etc.) deben utilizarse. Un ejemplo de plan lógico es un plan basado en un árbol, en el que las hojas del árbol corresponden a las subconsultas que deben ejecutarse, y los nodos internos representan los operadores.

El plan lógico se traduce en un plan físico(ejecución de la consulta), que ejecuta la consulta prácticamente sobre las fuentes de datos seleccionadas. Las salidas de lassubconsultas individuales se reconcilian finalmente para construir el resultado final(reconciliación de la consulta).

Ejecutar en la nube

Puedes ejecutar Presto en un clúster desplegado por tu empresa, o puedes utilizar un servicio en la nube existente.Existen muchas ofertas en la nube para ejecutar Presto, como Amazon Elastic MapReduce (EMR) y Google Dataproc. Otros proveedores, como IBM, ofrecen Presto como parte de una oferta de lago de datos abierto que facilita la configuración y el funcionamiento de varios clústeres de Presto para diferentes casos de uso.

Arquitectura y componentes básicos de Presto

La Figura 1-5 muestra la arquitectura de Presto, que se despliega como dos servicios principales: un único coordinador y muchos trabajadores. El servicio coordinador es, en realidad, el cerebro de la operación: recibe las solicitudes de consulta de los clientes, analiza la consulta, elabora un plan de ejecución y, a continuación, programa el trabajo que deben realizar muchos servicios trabajadores. El coordinador contiene tres componentes principales: el analizador sintáctico, el planificador y el programador.

Cada trabajador procesa una parte de la consulta global en paralelo, y puedes añadir servicios de trabajador a tu implementación de Presto para adaptarlos a tu demanda. Cada fuente de datos se configura como un catálogo, y puedes consultar tantos catálogos como quieras en cada consulta.

Figura 1-5. La arquitectura Presto

Puedes configurar Presto de tres formas distintas:

Con una sola fuente de datos

Los usuarios pueden consultar una única fuente de datos con Presto. En este caso, Presto se convierte en el motor de consulta separado que utiliza los metadatos de un catálogo externo y procesa los datos almacenados en el lago de datos.

Con múltiples fuentes de datos consultadas independientemente

Como motor federado, puedes ver muchas Implementaciones de Presto que están conectadas a múltiples fuentes de datos. Esto permite a los usuarios finales consultar una fuente de datos a la vez, utilizando la misma interfaz sin tener que cambiar entre sistemas o pensar en ellos como sistemas de datos diferentes.

Con múltiples fuentes de datos, correlacionadas y consultadas conjuntamente

Llevando la federación un paso más allá, una consulta puede combinar datos de dos o más fuentes de datos. Las ventajas de hacerlo permiten a los usuarios finales analizar más datos sin necesidad de moverlos o copiarlos en una única fuente de datos.

La Tabla 1-2 resume las ventajas que proporcionan las distintas configuraciones. Las fuentes únicas sólo proporcionan análisis rápidos. Presto configurado con múltiples fuentes de datos, cada una consultada de forma independiente, te proporciona análisis rápidos y federados. Por último, si Presto se configura con varias fuentes de datos, correlacionadas y consultadas conjuntamente, te proporciona una analítica rápida, federada y unificada.

Tabla 1-2. Ventajas de las distintas configuraciones de Presto

Tipo de fuente	Análisis rápidos	Analítica federada	Analítica unificada
Fuente única	X	-	-
Múltiples fuentes consultadas independientemente	X	X	-
Múltiples fuentes consultadas conjuntamente	X	X	X

Alternativas a Presto

La comunidad investigadora ha propuesto muchas alternativas a Presto. La investigación se ha centrado en construir un motor de consulta distribuido, rápido y escalable, capaz de tratar con big data. Dado el constante crecimiento de los big data, soluciones como Presto y sus alternativas se han vuelto muy atractivas para la industria.

Apache Impala

Apache Impala, desarrollado originalmente por Cloudera, es un motor de consulta SQL distribuido para Apache Hadoop. Puedes utilizar Apache Impala para conjuntos de datos de tamaño medio, aunque no admite algunas operaciones SQL, como UPDATE y DELETE. Apache Impala es compatible con Amazon Web Services y MapR.

Colmena Apache

Apache Hive es un software de almacén de datos para gestionar grandes conjuntos de datos consultados mediante la sintaxis SQL. Basado en Apache Hadoop, Hive admite distintos formatos de datos, como archivos de texto con valores separados por comas y tabulaciones (CSV/TSV), Apache Parquet, etc. Puedes ampliar Hive con un conector personalizado para que admita otros formatos de datos. También puedes utilizar Hive con Presto.

Spark SQL

Spark SQL es un módulo creado para que Apache Spark trabaje con datos estructurados. También puedes utilizarlo como motor de consulta SQL distribuido, y puedes integrarlo con el resto de módulos de Spark.

Spark contra Presto

Spark y Presto gestionan las etapas de forma diferente. En Spark, los datos deben procesarse por completo antes de pasar a la siguiente etapa. Presto utiliza un enfoque de procesamiento en cadena y no necesita esperar a que termine una etapa completa.

Trino

Cuando los fundadores del proyecto Presto abandonaron Facebook en 2018, el proyecto original, PrestoDB (descrito en este libro), se bifurcó en un proyecto independiente, llamadoPrestoSQL. En 2021, PrestoSQL pasó a llamarse Trino.

Similar a Presto, Trino pretende ejecutar consultas rápidas y federadas, sin copiar ni mover datos de las fuentes al almacenamiento temporal.

Casos de uso de Presto

Presto se diseñó originalmente para análisis interactivos y consultas ad hoc. Con la evolución de la tecnología y la disponibilidad de datos casi en tiempo real, ha aumentado el número de casos de uso en los que se aplica Presto. En esta sección, verás los casos de uso más populares para Presto.

Informes y cuadros de mando

A diferencia de las versiones estáticas de primera generación, los informes y cuadros de mando interactivos actuales son muy diferentes. Los analistas, los científicos de datos, los gestores de productos, los vendedores y otros usuarios no sólo quieren ver los Indicadores Clave de Rendimiento (KPI), las estadísticas de productos, los datos de telemetría y otros datos, sino que también quieren profundizar en áreas específicas de interés o áreas en las que puede haber oportunidades.

Presto ofrece a los usuarios la posibilidad de consultar datos de distintas fuentes por sí mismos, para que no dependan de los ingenieros de la plataforma de datos. También simplifica enormemente las tareas de los ingenieros de la plataforma de datos, proporcionándoles un único punto final para muchas herramientas de elaboración de informes y cuadros de mando, como Tableau, Graphana, Apache Superset y muchas más.

Consulta ad hoc

Los ingenieros, analistas, científicos de datos y gestores de productos pueden personalizar sus consultas manualmente o utilizando una serie de herramientas de visualización, cuadros de mando e Inteligencia Empresarial (BI). Dependiendo de las herramientas elegidas, pueden ejecutar muchas consultas concurrentes complejas contra un clúster de Presto. Con Presto, pueden iterar rápidamente sobre hipótesis innovadoras con la exploración interactiva de cualquier conjunto de datos, que resida en cualquier lugar.

ETL con SQL

Los analistas pueden agregar terabytes de datos a través de múltiples fuentes de datos y ejecutar eficientes consultas ETL (extraer, transformar y cargar) contra esos datos con Presto. En lugar de los sistemas de procesamiento por lotes heredados, puedes utilizar Presto para ejecutar consultas de alto rendimiento y eficiencia de recursos.

Ejecutar consultas en trabajos ETL por lotes es mucho más caro en términos de volumen de datos y CPU que ejecutar trabajos interactivos. Como los clusters suelen ser mucho más grandes, algunas empresas separan los clusters Presto en dos grupos: uno para ETL y otro para consultas ad hoc. Esto es ventajoso desde el punto de vista operativo, porque los dos clusters utilizan la misma tecnología Presto y requieren las mismas habilidades.

ETL frente a ELT

ETL (extraer, transformar y cargar) difiere de ELT (extraer, cargar y transformar), aunque las operaciones realizadas son las mismas en ambos procesos. La diferencia no es simplemente el orden de las operaciones, porque normalmente se realizan en paralelo. En cambio, la diferencia es dónde se realiza la transformación de los datos. En un sistema ETL, la transformación se realiza en un área de preparación del almacén de datos, mientras que en un sistema ELT, la transformación se realiza directamente en el almacén de datos backend.

Data Lakehouse

Un lago de datos te permite almacenar todos tus datos estructurados y no estructurados tal cual y ejecutar distintos tipos de análisis sobre ellos.Un lago de datos tiene cargas de trabajo SQL y también otras cargas de trabajo no SQL (por ejemplo, aprendizaje automático sobre datos no estructurados). Presto se encarga de las cargas de trabajo SQL. Puedes utilizar Presto para ejecutar consultas SQL directamente en tu lago de datos, sin moverlos ni transformarlos.

Análisis en tiempo real con bases de datos en tiempo real

La analítica en tiempo real suele implicar la combinación de datos que se capturan en tiempo real con datos históricos o archivados. Imagina que un sitio de comercio electrónico utiliza dos almacenes: el primero es, por ejemplo, un bucket de Amazon S3 que almacena tu actividad pasada, y el segundo es un almacén en tiempo real de Apache Pinot que almacena tu actividad en tiempo real, como el contenido de tu carrito.

Además, imagina que la actividad de tu sesión actual se traslada del almacén en tiempo real al archivo histórico a intervalos regulares. En un instante dado, puede que tu actividad de la sesión actual no llegue al S3. Utilizando Presto para fusionar los datos de ambos sistemas, el sitio web podría ofrecerte incentivos en tiempo real para que no abandones tu carrito, o podría determinar si se está produciendo un posible fraude antes y con mayor precisión.

Presentamos nuestro caso práctico

Puedes utilizar Presto en distintos escenarios, como análisis de minería de datos, análisis de inteligencia empresarial de alto rendimiento y monitoreo en tiempo real. Para mostrar las capacidades de Presto, hemos construido un escenario ficticio que utilizaremos a lo largo del libro, siempre que sea posible.

Imagina que una empresa de comercio electrónico ofrece un servicio que vende o distribuye algunos productos en todo el mundo, como libros, ropa y otros artículos. Para representar el servicio, utilizaremos la base de datos Transaction Processing Performance Council Benchmark H (TPC-H), que es totalmente compatible con Presto.

La base de datos TPC-H define ocho tablas, como se ilustra en la Figura 1-6. Las flechas de la figura muestran las relaciones entre las tablas. La base de datos TPC-H define un escenario genérico de comercio electrónico que puedes utilizar con fines de prueba, con una cantidad variable de datos.

Figura 1-6. La base de datos TPC-H

La Figura 1-7 muestra la arquitectura de nuestro caso práctico. Hay dos fuentes de datos principales:

Actividad de los clientes en tiempo real

Define los eventos en tiempo real generados por el cliente, como los productos del carrito

Base de datos de productos

Contiene el catálogo de productos

Figura 1-7. La arquitectura de nuestro caso práctico

Ambas fuentes de datos se ingieren en el lago de datos. Periódicamente, la actividad de los clientes en tiempo real se traslada a un segmento específico del lago de datos, denominado actividad archivada. Presto accede al lago de datos para realizar distintos tipos de consultas. En las capas superiores están los servicios de informes, cuadros de mando y minería de datos.

Conclusión

En este capítulo has aprendido qué es Presto y cuál es su papel en un lago de datos. Presto es un motor de consultas SQL distribuido en paralelo para consultar cualquier formato de datos: estructurados, semiestructurados o no estructurados. Puedes utilizar Presto para ejecutar consultas en el contexto de big data, utilizando ANSI SQL, un lenguaje único estándar y bien conocido. También puedes utilizar Presto en escenarios que requieran un alto rendimiento y una gran escalabilidad, y que se ejecuten en la nube.

Ahora ya conoces los conceptos básicos de Presto, incluida su arquitectura, cómo ejecuta consultas federadas y sus casos de uso. Ahora deberías ser capaz de dar un paso más instalando y ejecutando tu primer escenario con Presto.

En el Capítulo 2, aprenderás a empezar con Presto, centrándote en cómo instalar y configurar Presto utilizando Docker y Kubernetes.

¹ Kemele M. Endris, Maria-Esther Vidal y Damien Graux, "Chapter 5, Federated Query Processing", en Knowledge Graphs and Big Data Processing, ed. Valentina Janev, Hajira Jabeen y Emanuel Sallinger, Springer, 2020. Valentina Janev, Damien Graux, Hajira Jabeen y Emanuel Sallinger (Springer, 2020), https://oreil.ly/p7KFC.