El lago de datos en la nube

Capítulo 4. Lagos de datos escalables

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

Si cambias tu forma de mirar las cosas, las cosas que miras cambian.

Wayne Dyer

Después de leer los tres primeros capítulos, deberías tener todo lo que necesitas para poner en marcha tu arquitectura de lago de datos en la nube, con un perfil de costes razonable para tu organización. Teóricamente, también tienes el primer conjunto de casos de uso y escenarios funcionando con éxito en producción. Tu lago de datos tiene tanto éxito que la demanda de más escenarios es ahora mayor, y estás ocupado atendiendo las necesidades de tus nuevos clientes. Tu negocio está en auge, y tu patrimonio de datos crece rápidamente. Como se dice en los negocios, pasar de cero a uno es un reto diferente que pasar de uno a cien o de cien a mil. Para asegurarte de que tu diseño también es escalable y sigue rindiendo a medida que crecen tus datos y los casos de uso, es importante conocer los diversos factores que afectan a la escala y el rendimiento de tu lago de datos. En contra de la opinión popular, la escala y el rendimiento no siempre están reñidos con los costes, sino que van muy de la mano. En este capítulo, examinaremos más detenidamente estas consideraciones, así como las estrategias para optimizar tu lago de datos para la escala, sin dejar de optimizar los costes. Una vez más, utilizaremos Klodars Corporation, una organización ficticia, para ilustrar nuestras estrategias. Nos basaremos en estos fundamentos para centrarnos en el rendimiento en el Capítulo 5.

Un vistazo a la escalabilidad

Escala y rendimiento son términos que probablemente hayas visto esparcidos generosamente en lanzamientos de productos y materiales de marketing. ¿Qué significan realmente y por qué son importantes? Para entenderlo mejor, veamos primero la definición de escalabilidad. En el Capítulo 5, profundizaremos en los aspectos relacionados con el rendimiento.

¿Qué es la escalabilidad?

La mejor definición de escalabilidad que he encontrado es la del blog de Werner Vogels. Vogels fue el Director Técnico de Amazon, que alberga uno de los mayores sistemas de hiperescala del planeta. Según su blog, la definición de escalabilidad es la siguiente:

Se dice que un servicio es escalable si cuando aumentamos los recursos de un sistema, se produce un aumento del rendimiento de forma proporcional a los recursos añadidos. Se dice que un servicio siempre activo es escalable si al añadir recursos para facilitar la redundancia no se produce una pérdida de rendimiento.

Este concepto de escala es muy importante porque, a medida que crecen tus necesidades y tu uso, es importante tener una arquitectura que pueda garantizar la misma experiencia a tus clientes sin degradación del rendimiento. Para ilustrarlo mejor, aplicaremos los principios de escala a algo con lo que todos podemos identificarnos: hacer bocadillos.

La balanza en nuestro día a día

Veamos un ejemplo de escalabilidad en acción. Supongamos que tardas un total de cinco minutos en preparar un bocadillo de mantequilla de cacahuete y mermelada para el almuerzo, que consta de los siguientes pasos, como se muestra en la Figura 4-1:

1. Tuesta dos trozos de pan.

2. Unta un lado con mantequilla de cacahuete.

3. Unta la otra cara con gelatina.

4. Monta el bocadillo.

5. Embolsa el bocadillo.

Figura 4-1. Pasos para preparar un bocadillo de mantequilla de cacahuete y mermelada

Bastante sencillo y nada complicado, ¿verdad? Supongamos que quieres hacer 100 bocadillos de mantequilla de cacahuete y mermelada. El siguiente paso obvio es invitar a más gente a que te ayude. Ahora bien, si un bocadillo tarda cinco minutos en hacerse, y tienes un equipo de cinco miembros para hacer los 100 bocadillos, es natural pensar que se tardaría un total de 100 minutos en hacer estos 100 bocadillos, suponiendo una distribución equitativa del trabajo y que cada persona hace 20 bocadillos.

Nota

En este ejemplo concreto, el rendimiento se mide por el resultado en términos de unidad de trabajo realizada (un bocadillo) y el tiempo empleado para ese resultado (tiempo medio para hacer un bocadillo). La escalabilidad es entender cuánto se conserva este tiempo medio a medida que aumenta la unidad de trabajo realizada.

Sin embargo, la realidad podría ser muy distinta en función de cómo decidas ponerlo en práctica con cinco personas. Veamos dos enfoques:

Enfoque de ejecución de extremo a extremo

En este enfoque, cada persona sigue los pasos para hacer un solo bocadillo, y luego procede a hacer el siguiente bocadillo, hasta completar cinco bocadillos. Esto se ilustra en la Figura 4-2.

Figura 4-2. Ejecución de extremo a extremo

Enfoque de línea de montaje

En este enfoque, tienes una división del trabajo en la que distribuyes los pasos a distintas personas: la primera persona tuesta el pan, la segunda aplica la mantequilla de cacahuete, la tercera la mermelada, y así sucesivamente, como se muestra en la Figura 4-3.

Figura 4-3. Línea de montaje

Como probablemente ya habrás adivinado, el enfoque de la cadena de montaje es más eficiente que el enfoque de la ejecución de extremo a extremo. Pero, ¿qué es exactamente lo que lo hace más eficiente? Para entenderlo, primero tenemos que comprender los conceptos fundamentales de lo que afecta al escalado:

Recursos

Los materiales disponibles para hacer el bocadillo -en este caso, el pan, la mantequilla de cacahuete y la mermelada- son los recursos más obvios. La tostadora y los cuchillos son otros recursos necesarios para hacer el bocadillo.

Tarea

El conjunto de pasos que se siguen para producir el resultado: en este caso, los cinco pasos necesarios para hacer el bocadillo.

Trabajadores

Los componentes que realizan el trabajo real: en este caso, las personas que ejecutan la tarea de hacer el bocadillo.

Salida

El resultado del trabajo que indica que el trabajo está terminado: en este caso, el bocadillo.

Los trabajadores utilizan los recursos para ejecutar la tarea que produce el resultado. La eficacia con la que se unen afecta al rendimiento y la escalabilidad del proceso. La Tabla 4-1 muestra cómo el enfoque de línea de montaje es más eficaz que el enfoque de ejecución de extremo a extremo.

Tabla 4-1. Comparación de los enfoques

Área	Enfoque de ejecución de extremo a extremo	Enfoque de línea de montaje
Contención por los recursos	Todos los trabajadores acaban compitiendo por el mismo conjunto de recursos (tostadora, tarro de mantequilla de cacahuete, etc.).	La contención es mínima, ya que los distintos trabajadores necesitan recursos diferentes.
Flexibilidad en la asignación de trabajadores a hilos	Baja: dado que los trabajadores realizan todas las tareas, la asignación es uniforme para todas las tareas.	Alto: si algunas tareas necesitan más trabajadores que otras, es posible un cambio rápido.
Impacto de añadir/eliminar recursos	El impacto de añadir recursos puede no suponer una gran diferencia dependiendo del cuello de botella que haya en el sistema. Sin embargo, añadir los recursos adecuados aceleraría la ejecución. Por ejemplo, si tienes cinco tostadoras en lugar de una, los trabajadores podrán tostar el pan más rápidamente.	La flexibilidad de la asignación de recursos permite aumentar el rendimiento cuando se dispone de más recursos.

Además, ten en cuenta que en el enfoque de ejecución de extremo a extremo, algunos bocadillos tardarán menos tiempo en terminarse que otros. Por ejemplo, cuando cinco personas estén alcanzando la tostadora y una de ellas lo consiga, ese bocadillo en concreto estará terminado antes que los demás, que tendrán que esperar a que la tostadora esté lista. Así que si midieras el rendimiento, verías que el tiempo para hacer un bocadillo en el percentil 50 podría ser aceptable, pero el tiempo empleado en los percentiles 75 y 99 podría ser mucho mayor.

Sería justo concluir que el enfoque de la cadena de montaje es más escalable que el enfoque de la ejecución de extremo a extremo en la elaboración del bocadillo. Aunque las ventajas de esta escalabilidad no son evidentes en tu día normal, como cuando puedes envasar tres o cuatro bocadillos, la diferencia es realmente visible cuando el trabajo a realizar aumenta drásticamente, hasta hacer 3.000 ó 4.000 bocadillos, por ejemplo.

Escalabilidad en las arquitecturas de lagos de datos

En las arquitecturas de lago de datos, como vimos en en los capítulos anteriores, los recursos están a nuestra disposición desde la nube: los recursos informáticos, de almacenamiento y de red. Además, hay dos factores clave que poseemos y controlamos para aprovechar mejor los recursos de que disponemos: el trabajo de procesamiento, que es el código que escribimos, y los propios datos, en cuanto a cómo conseguimos almacenarlos y organizarlos para su procesamiento. Esto se ilustra en la Figura 4-4.

Figura 4-4. Recursos del lago de datos

Los recursos clave de que disponemos en una arquitectura de lago de datos en la nube son los siguientes:

Recurso informático

Los recursos informáticos de que dispones desde la nube son principalmente núcleos de CPU y memoria para tus necesidades de procesamiento de datos. Además, hay software que se ejecuta en estos núcleos, principalmente el software que instalas en el caso de IaaS y el software disponible para ti en términos de PaaS y SaaS que está diseñado para manipular y optimizar la utilización de los recursos de CPU y memoria. Comprender cómo funciona esto es fundamental para construir tu solución escalable. Los proveedores de servicios en la nube ofrecen capacidades como el autoescalado, en el que a medida que aumentan las necesidades de computación de tu solución, tus servicios en la nube pueden añadir automáticamente más computación sin que tengas que gestionar los recursos. Además, hay componentes sin servidor, como BigQuery de Google, que abstraen completamente del usuario los aspectos de recursos de computación y almacenamiento, permitiéndole centrarse únicamente en sus escenarios empresariales principales. Los componentes sin servidor tienden a costar más en comparación con la IaaS ajustable, pero ofrecen optimizaciones y ajustes integrados que te permiten centrarte en tus escenarios principales.

Recursos de red

Piensa en tu recurso de red como un cable metafórico que puede enviar datos de un lado a otro. Esto se implementa en el hardware de red o, en otros casos, es una red definida por software.

Recursos de almacenamiento

Sistemas de almacenamiento de lago de datos en la nube proporcionan un sistema de almacenamiento distribuido elástico que te da espacio para almacenar datos (en discos, almacenamiento flash y unidades de cinta, según el nivel de datos con el que operes), junto con potencia informática para realizar transacciones de almacenamiento y potencia de red para transferir datos por cable a otros recursos dentro y fuera de tu proveedor de la nube.

Éstas son las piezas clave que controlas:

• El código que escribas

• La forma en que se almacenan y organizan tus datos, que influye en gran medida en la eficacia con que se utilizan los recursos.

• Cómo de escalable y eficaz es tu solución

En la siguiente sección, profundizaremos en cómo funciona el procesamiento de big data en una arquitectura de lago de datos y en los factores que afectan a la escalabilidad y el rendimiento de tu solución de lago de datos.

Comprender y aprender los factores que ayudan a escalar el sistema es importante por dos razones fundamentales:

• Los patrones de tráfico en el lago de datos tienden a ser muy variables y en ráfagas en la mayoría de los casos, por lo que la ampliación y la reducción son capacidades clave que deben tenerse en cuenta en la arquitectura de tu lago de datos.

• Comprender los cuellos de botella te da una idea de qué recursos hay que aumentar o reducir; de lo contrario, corres el riesgo de añadir los recursos equivocados sin mover la aguja de la escalabilidad de la solución.

¿Por qué tengo que preocuparme por la escalabilidad? Mi solución funciona bien hoy.

Hablando de crecimiento 10×, a menudo veo que los clientes subestiman el valor y las oportunidades que una arquitectura de lago de datos ayuda a desbloquear, y optimizan su tiempo y sus esfuerzos para los máximos a corto plazo. Si estás pensando en la línea de estas afirmaciones - "Sólo necesito trasladar mi almacén de datos ahora; no veo que ningún otro dato sea importante todavía", o "Mi primera prioridad es llevar a la nube lo que sea que estemos haciendo; déjame preocuparme del resto más tarde", o "Tengo un plazo de un año para trasladar mis datos a la nube; no puedo permitirme pensar en nada más que en mis cargas de trabajo actuales"-, permíteme asegurarte algunas cosas:

• Como con cualquier esfuerzo de desarrollo de software, pensar en escenarios futuros te ayuda a evitar la deuda técnica de tener que volver a diseñar completamente tus soluciones cuando se habilitan nuevos escenarios.

• Preparar tu diseño para el futuro no es tan difícil como crees. Se trata más de diligencia que de esfuerzo, lo que te preparará para el éxito.

• Según un estudio publicado por el Foro Económico Mundial, se espera que la transformación digital añada 100 billones de dólares a la economía mundial para 2025, y las interacciones impulsadas por plataformas impulsarán al menos dos tercios de este crecimiento de 100 billones de dólares. Es sólo cuestión de tiempo que se desbloqueen estos escenarios.

Sistemas internos de procesamiento de lagos de datos

Como se ve en la Figura 4-4, las operaciones clave que intervienen en el procesamiento de big data son las siguientes:

Ingerir

Obtención de datos brutos de diversas fuentes en un lago de almacenamiento de datos

Prepara

Preparar los datos brutos para generar datos enriquecidos, aplicando un esquema bajo demanda, eliminando o corrigiendo los datos erróneos y optimizando los formatos de los datos.

Conserva

Generar datos curados con densidad de alto valor mediante la agregación, el filtrado y otros procesamientos de datos enriquecidos.

Consume

Consumir tus datos a través de cuadros de mando, consultas o exploraciones relacionadas con la ciencia de datos, por nombrar algunos, y utilizar estos conocimientos para modificar el comportamiento de tu aplicación, lo que también entra dentro del consumo.

En este capítulo, nos centraremos en el caso de uso más común del gran lago de datos, que es el procesamiento por lotes. En el procesamiento por lotes, los datos se ingieren en el lago de datos de forma programada y periódica mediante copias de datos. Estos datos en bruto se preparan y enriquecen, y luego se tratan con motores de procesamiento ELT/ETL. Apache Spark y Apache Hadoop son los motores de procesamiento más utilizados para las fases de preparación y depuración. Estos trabajos de Spark se ejecutan de forma programada una vez finalizada la ingesta o la copia de datos.

Hay otros casos de uso, como los motores de procesamiento en tiempo real de , en los que los datos se ingieren continuamente en el lago de datos y se preparan y curan posteriormente. Aunque los principios de escala que discutiremos en el procesamiento por lotes también se aplican en gran medida a los conductos de procesamiento en tiempo real, existen restricciones adicionales en el diseño, dada la naturaleza continua del procesamiento. En este libro no profundizaremos en los sistemas que no son de procesamiento por lotes, ya que los casos de uso más comunes son pertinentes al procesamiento por lotes. En este capítulo, tampoco profundizaremos en los casos de uso de consumo para consultas de BI y ciencia de datos. Hay muchos recursos disponibles sobre patrones de consulta y ciencia de datos.

Veremos los dos aspectos específicos del procesamiento de big data que son exclusivos de la arquitectura del lago de datos en la nube:

Copia de datos

Esto implica mover datos tal cual de un sistema a otro, por ejemplo, ingiriendo datos en el lago de datos desde fuentes externas y copiando datos de un sistema de almacenamiento a otro dentro del servicio en la nube, como cargar datos de un lago de datos en un almacén de datos. Ésta es la forma más común de ingestión utilizada en los sistemas de procesamiento de big data.

Procesamiento ETL/ELT

Esto implica un conjunto de datos de entrada y de salida, donde los datos de entrada se leen y se transforman mediante filtrado, agregación y otras operaciones para generar los conjuntos de datos de salida. La generación de datos en los conjuntos de datos enriquecidos y curados entra en esta categoría. Hadoop y Spark son los motores de procesamiento más populares, con Spark a la cabeza en este ámbito al admitir operaciones por lotes, en tiempo real y en flujo con la misma arquitectura. Estos son los tipos más comunes de etapas de preparación y curación de datos del procesamiento de big data.

Copia de datos internos

Hay muchas formas de realizar operaciones de copia de datos. Los proveedores de la nube y los ISV ofrecen PaaS que copian datos de un sistema a otro de forma optimizada. También puedes aprovechar herramientas y kits de desarrollo de software (SDK) para copiar datos, como utilizar el portal del proveedor de la nube para cargar o descargar datos. En esta sección, examinaremos los aspectos internos de un trabajo de copia en el que los datos se leen de un origen y se copian como tales en el destino. Ten en cuenta que, en la vida real, también puedes ampliar este sencillo escenario de copia de datos a temas más avanzados, como la copia de un conjunto de datos que cambia constantemente, así como la limpieza periódica de conjuntos de datos para cumplir requisitos normativos como el GDPR. Para comprender la escalabilidad, nos centraremos en el proceso de copia simple.

Componentes de una solución de copia de datos

Los componentes muy simplificados que intervienen en la copia de datos se presentan en la Figura 4-5.

Figura 4-5. Funcionamiento interno de la copia de datos

La herramienta de copia de datos tiene dos componentes principales de forma simplificada:

Orquestador de copia de datos

Comprende el trabajo que hay que hacer (por ejemplo, cuántos archivos hay que copiar del origen) y aprovecha los recursos informáticos disponibles para distribuir el trabajo de copia entre distintos trabajadores. El orquestador también conserva el estado del propio trabajo de copia, es decir, sabe qué datos se han copiado y cuáles aún no.

Copiadores de datos

Unidades de cómputo que aceptan el trabajo del orquestador y realizan las operaciones de copia del origen al destino.

Hay una configuración que especifica el número de trabajadores de copia de datos que puedes proporcionar al trabajo de copia. Se trata de un mando que puedes marcar hacia arriba o hacia abajo para configurar el número de trabajadores que necesitas, ya sea directamente estableciendo el número máximo de trabajadores o especificando un valor proxy que el orquestador de copia de datos haya definido como valor configurable.

Comprender la utilización de recursos de un trabajo de copia de datos

Los cuellos de botella que afectan a la escalabilidad y al rendimiento de tu copia de datos son los siguientes:

El número y tamaño de los archivos/objetos que hay que copiar

La granularidad del trabajo de copia de datos es a nivel de archivo/objeto en tu sistema de almacenamiento. Un archivo grande podría dividirse en trozos para hacer una copia paralela, pero no puedes combinar varios archivos en un trabajo de copia única. Si tienes muchos archivos pequeños que copiar, puedes esperar que esto lleve mucho tiempo, porque la operación de listado para el operador podría llevar más tiempo, y los archivos pequeños harían que en una unidad de trabajo de copia única, la cantidad de datos transferidos fuera baja, no utilizando al máximo tu recurso de ancho de banda disponible.

Capacidad de cálculo de tu herramienta de copia de datos

Si configuras tu herramienta de copia de datos para que disponga de suficientes recursos de cálculo, podrás lanzar más trabajadores, realizando efectivamente muchas operaciones de copia simultáneas. Por el contrario, no disponer de suficientes recursos informáticos hace que el número de trabajadores disponibles se convierta en un cuello de botella en tu sistema.

Capacidad de red disponible para la copia

La cantidad de capacidad de red de que dispongas controla la tubería que se utiliza para la transferencia de datos, especialmente para copiar datos a través del límite de la nube. Asegúrate de que tienes una red aprovisionada de gran ancho de banda. Ten en cuenta que cuando copias o realizas transacciones entre servicios en la nube del mismo proveedor, no necesitas aprovisionar o aprovechar tu red; los servicios en la nube tienen su propia red para hacerlo.

Copia de datos entre regiones

Cuando realizas copias de datos entre regiones, éstas tienen que recorrer una distancia mayor por la red, lo que hace que la copia de datos sea mucho más lenta e incluso, en algunos casos, que se agote el tiempo de espera, provocando el fallo de los trabajos.

Internos de procesamiento ELT/ETL

Si necesitas un repaso sobre cómo funcionan los motores de análisis de grandes datos, te recomiendo que vuelvas a leer " Motores de análisis de grandes datos", concretamente la sección sobre Spark en "Apache Spark".

Los procesos ELT/ETL trabajan principalmente sobre datos no estructurados, estructurados o semiestructurados, aplican un esquema bajo demanda y transforman estos datos mediante filtrado, agregaciones y otros procesamientos para generar datos estructurados en un formato tabular. Apache Hadoop y Apache Spark son los motores de procesamiento más comunes que entran en esta categoría. En esta sección profundizaremos en los aspectos internos de Apache Spark, pero los conceptos se aplican en gran medida a Apache Hadoop con sutiles matices. Apache Hadoop, aunque puede ejecutarse en la nube, se diseñó para ejecutarse in situ en HDFS. Apache Spark está mucho más cerca de la arquitectura en la nube. Apache Spark es también en gran medida el motor de procesamiento de facto debido a su consistencia a través de lotes, streaming y canalizaciones de datos interactivos, por lo que nos centraremos en Spark en esta sección.

Ejecutarías un trabajo de Apache Spark en un clúster que puedes crear de las siguientes formas:

• Aprovisiona recursos informáticos IaaS e instala la distribución de Apache Spark, ya sea del código abierto Apache Spark o de un ISV como Cloudera.

• Provision PaaS, donde puedes conseguir un clúster que viene con Spark ya instalado y listo para que lo utilices de proveedores como Databricks o de proveedores de servicios en la nube como Amazon EMR o Azure Synapse Analytics.

Apache Spark aprovecha una arquitectura informática distribuida, en la que hay un controlador/coordinador central, también llamado conductor, que orquesta la ejecución, y múltiples ejecutores, o unidades de trabajo, que realizan una tarea específica que contribuye a la aplicación. Haciendo una analogía con la construcción de una casa, puedes pensar en el controlador de Apache Spark como el contratista general y en los ejecutores como trabajadores cualificados, como fontaneros y electricistas. A continuación repasaremos algunos conceptos clave que son fundamentales para Apache Spark.

Componentes de una aplicación Apache Spark

Los desarrolladores de datos escriben código Spark y envían ese código a un clúster Spark, luego obtienen los resultados de vuelta cuando termina la ejecución. Detrás de la pantalla, el código del usuario se ejecuta como una aplicación Spark y se divide en los siguientes componentes:

Conductor

El controlador es el coordinador central del proceso Spark y es el único componente que entiende el código de usuario. El controlador tiene dos componentes principales: definir el desglose de los trabajos, tareas y ejecutores necesarios para ejecutar el programa y coordinar la asignación de éstos en las distintas partes disponibles del clúster Spark. El gestor del clúster ayuda al controlador a encontrar los recursos.

Ejecutores

Los ejecutores son los componentes que realmente realizan el cálculo. El controlador comunica el código, así como el conjunto de datos sobre el que debe trabajar el ejecutor.

Trabajos, etapas y tareas

Una aplicación Apache Spark se traduce internamente en un plan de ejecución dentro de tu clúster Spark. Este plan de ejecución se representa como un grafo acíclico dirigido (DAG) con un conjunto de nodos que representan trabajos, que a su vez constan de etapas que podrían tener dependencias entre sí. A continuación, estas etapas se descomponen en tareas, que son las unidades reales de ejecución, donde se realiza el trabajo. Esto se muestra en la Figura 4-6. La cantidad de ejecutores asignados a una tarea depende de la cantidad de datos que haya que procesar.

Figura 4-6. Funcionamiento interno de la tarea Spark

Comprender la utilización de recursos de un trabajo Spark

Como puedes ver, hay dos factores que contribuyen a la utilización de recursos de un código Spark:

El código

La complejidad de las operaciones que hay que realizar

Los datos

El volumen y la organización de los datos que hay que procesar

Estos cuellos de botella afectan a la escalabilidad de tu copia de datos:

Factor de forma y memoria del clúster

La cantidad de computación y memoria que proporcionas a tu trabajo Spark afecta en gran medida al rendimiento del trabajo. Cuando tienes una aplicación de cálculo intensivo con muchas transformaciones de datos, aumentar el número de núcleos de cálculo proporcionaría más ejecutores para realizar las tareas, lo que se traduciría en una mejora general del trabajo. Del mismo modo, cuando tengas una transformación compleja, si dispones de más memoria, los conjuntos de datos temporales (RDDs) podrían persistir en memoria, minimizando los tiempos de recuperación desde soluciones de almacenamiento persistente más lentas, como el almacén de objetos. Los proveedores de Apache Spark también habilitan cachés que ayudan a almacenar en memoria conjuntos de datos de uso frecuente.

El número y tamaño de los ficheros/objetos que hay que operar

La granularidad de la ejecución del trabajo es a nivel de archivo/objeto en tu sistema de almacenamiento. De forma similar al trabajo de copia de datos, si tienes que leer muchos archivos pequeños para realizar tu trabajo Apache Spark, puedes esperar que esto lleve mucho tiempo porque la operación de listado en el controlador llevaría más tiempo, y la sobrecarga de leer un archivo (es decir, hacer comprobaciones de acceso y otros metadatos) sólo tiene un pequeño retorno en términos de datos reales leídos o escritos. Por otro lado, si aumentas el número de ejecutores de Spark, puedes paralelizar las escrituras mucho más rápido y completar el trabajo antes. Se trata de un conflicto saludable porque, mientras que las escrituras son más caras y pueden optimizarse escribiendo muchos archivos pequeños, las lecturas posteriores resultan caras. Para minimizar este impacto posterior, Apache Spark proporciona utilidades de compactación que pueden utilizarse para combinar estos archivos pequeños en un archivo grande una vez finalizado el trabajo.

Organización de los datos

El procesamiento en Apache Spark implica esencialmente muchas operaciones de filtrado o recuperación selectiva de datos para lecturas. Organizar tus datos de una forma que permita una recuperación más rápida de los datos en cuestión podría suponer una gran diferencia en el rendimiento de tu trabajo. Los formatos de datos columnares como Parquet ofrecen una gran ventaja en este sentido; lo veremos en detalle en la siguiente sección. Además, particionar eficazmente tus datos de modo que los archivos/objetos con contenido similar se organicen juntos ayuda inmensamente a optimizar el acceso rápido, requiriendo menos recursos informáticos y, por tanto, mejorando la escalabilidad de tu solución.

Capacidad de la red y límites regionales

Como en el escenario de copia de datos, la capacidad de la red y los límites entre regiones afectan mucho a su rendimiento y escalabilidad.

Nota sobre otras consultas interactivas

Apache Spark es una tecnología de código abierto que aborda en gran medida las interacciones por lotes, interactivas y en tiempo real con el lago de datos. Los almacenes de datos en la nube ofrecen otras tecnologías de consulta interactiva que están optimizadas para determinados formatos de datos. Estos formatos son propietarios, y tanto los sistemas informáticos como los de almacenamiento están optimizados para los formatos. No vamos a profundizar en ellos en este libro. Sin embargo, conceptualmente siguen el modelo interno de Spark a un alto nivel.

Consideraciones para soluciones de lago de datos escalables

Permíteme empezar con un gran descargo de responsabilidad: en no hay ningún proceso de 12 pasos que puedas seguir al pie de la letra para que tu lago de datos sea eficaz, fiable o escalable. Sin embargo, hay varios factores que contribuyen a la escalabilidad y el rendimiento de tu solución en los que puedes confiar para tener una implementación sólida de tu lago de datos. Piensa en estos factores como perillas que puedes ajustar para comprender qué es exactamente lo que impulsa tu rendimiento óptimo.

Si tienes datos históricos de años anteriores o de tu implementación local análoga, podrías utilizarlos como aproximación a tus características de escala máxima. Sin embargo, no te preocupes si eso no está disponible: podrías ejecutar una PoC a escala, que esencialmente es una copia de tu carga de trabajo en un entorno simulado para ayudarte a comprender los diversos factores que afectan a tu rendimiento, de modo que puedas ver cómo aumentan a medida que aumenta la carga de tu sistema. Toma tu trabajo más complejo o tu mayor conjunto de datos para ejecutar tu PoC en el lago de datos, y duplica esa complejidad o el tamaño de los datos, o ambos, para analizar el impacto en tus recursos.

En esta sección, repasaremos algunos de los factores clave que afectan a la escala y el rendimiento de tu sistema.

Elige la oferta de nube adecuada

Como hemos visto en las secciones anteriores de este capítulo, tienes muchas opciones de ofertas en la nube cuando se trata de tus soluciones de big data. Puedes decidir componer tu solución de big data con IaaS, PaaS o SaaS, ya sea todo en un proveedor de nube, en varios proveedores de nube (solución multicloud), o con una mezcla de entornos en las instalaciones y en la nube (solución de nube híbrida), y en una región o en varias. Veamos el impacto de algunas de estas opciones en el rendimiento y la escalabilidad generales de tu solución.

Soluciones híbridas y multicloud

La mayoría de las organizaciones actuales aprovechan un enfoque multicloud, en el que han invertido en arquitecturas que abarcan dos o más proveedores de nubes. La mayoría de las organizaciones también tienen arquitecturas de nube híbrida, en las que han invertido en nubes privadas y en sistemas locales, así como en proveedores de nubes públicas.

Son muchas las motivaciones que impulsan una arquitectura multicloud o de nube híbrida:

• Migrar una plataforma local a la nube por fases

• Aprovechar la nube para los nuevos escenarios y devolver los conocimientos a la plataforma heredada en las instalaciones por razones de compatibilidad con versiones anteriores.

• Minimizar la dependencia de un único proveedor de la nube, lo que equivale a no poner todos los huevos en la misma cesta.

• Fusiones y adquisiciones en las que diferentes partes de la organización tienen su infraestructura en diferentes nubes

• Requisitos específicos, como la privacidad de los datos o el cumplimiento normativo, que exigen que parte de los activos de datos permanezcan en las instalaciones y no en la nube.

• Arquitectura de malla de datos, en la que los equipos o unidades de negocio de la organización tienen la flexibilidad de elegir los proveedores de la nube

Una arquitectura multicloud también tiene sus ventajas:

• Flexibilidad de elección para las unidades de negocio

• Menor coste: algunosservicios podrían ser más baratos en un servicio en la nube que en otros

Sin embargo, en lo que se refiere al rendimiento y la escala, así como al coste de la solución, hay algunas trampas en las que puedes caer cuando tienes una arquitectura multicloud o de nube híbrida:

• El coste operativo de gestionar varias nubes podría ser un gasto general o un coste oculto que podrías haber pasado por alto. Podrías aprovechar varias aplicaciones de software de gestión de nubes, lo que podría aumentar tus costes.

• Mover datos fuera de la nube no es óptimo en términos de rendimiento y además es caro. Si tienes un escenario en el que estás moviendo datos de un lado a otro a través de diferentes soluciones en la nube, verías que eso afecta al rendimiento general y, por tanto, se vería afectada la escalabilidad de la solución.

• Aunque los conceptos fundamentales son similares en todos los servicios ofrecidos por los distintos proveedores de la nube, también se requiere un profundo conocimiento de los matices y las buenas prácticas de implantación. La falta de estos conjuntos de habilidades podría hacer que no tuvieras una solución óptima en todos tus entornos.

• Cuando tengas escenarios en los que necesites conexiones directas, seguras y de baja latencia a la nube, tendrás que aprovisionar funciones especializadas como ExpressRoute de Azure o AWS Direct Connect. Tendrías que aprovisionar varias soluciones para mover los datos de tus sistemas locales, con lo que aumentarías tanto los costes como las transferencias de datos.

Si necesitas una solución híbrida o multicloud, presta atención a las transferencias de datos, e idealmente asegúrate de que las transferencias de datos a través de estos entornos múltiples son mínimas y están cuidadosamente pensadas.

Soluciones IaaS frente a PaaS frente a SaaS

Tu solución de big data puede estar compuesta de una mezcla de soluciones IaaS, PaaS y SaaS. He aquí las diferencias entre las opciones para un escenario de ejecución de un cuaderno Spark para tus científicos de datos:

Solución IaaS

En esta solución, primero aprovisionarías recursos de máquinas virtuales (VM) del proveedor de la nube, luego instalarías la distribución del software -ya sea de la Fundación Apache de código abierto o de un ISV como Cloudera- y habilitarías el acceso al portátil para tus científicos de datos. Tienes el control integral de la solución; sin embargo, también necesitas los conocimientos necesarios para optimizar el rendimiento y la escala. Las empresas suelen seguir este enfoque cuando tienen ingenieros que pueden ajustar el software de código abierto a sus necesidades construyendo sobre ellos y cuando tienen su versión personalizada de las herramientas de código abierto, como Apache Hadoop o Apache Spark.

Solución PaaS

En esta solución, aprovisionarías clústeres del proveedor de la nube que te ofrezca el entorno de software adecuado (junto con la gestión de las actualizaciones). Puedes especificar los recursos que necesitas en términos de CPU, memoria y almacenamiento sin tener que entender la mecánica profunda de cómo funcionan los motores de procesamiento de big data. La mayoría de las organizaciones siguen este enfoque.

Solución SaaS

En esta solución, te suscribirías a un SaaS, como un almacén de datos y un servicio de bloc de notas, los conectarías y empezarías a utilizarlos de inmediato. Aunque esto funciona muy bien como solución para empezar, la escalabilidad y el rendimiento tienen el techo de la escalabilidad de la propia solución SaaS. Las soluciones SaaS son cada vez mejores, así que tienes que entender cuánto necesitas escalar y verificarlo con el proveedor de SaaS, y confirmarlo también con una PoC.

Utiliza el resumen de la Tabla 4-2 para elegir la mejor opción.

Tabla 4-2. Comparación de las soluciones IaaS, PaaS y SaaS

Tipo de servicio	Cómo empezar	Flexibilidad para personalizar la solución	Control de los recursos
IaaS	Esfuerzo elevado: necesidad de gestionar el software, las actualizaciones, etc.	Gran flexibilidad: eres el propietario de la pila de software	Alto control: tienes control sobre los detalles del servicio a nivel de infraestructura
PaaS	Esfuerzo elevado: inferior al IaaS	Flexibilidad media: tanto como el proveedor de servicios PaaS exponga los controles	Control medio: más alto que las soluciones IaaS; más bajo que las soluciones SaaS
SaaS	Poco esfuerzo: puedes empezar con tu problema empresarial casi de inmediato	Poca flexibilidad: la facilidad de uso se debe a una flexibilidad limitada; aprovecha los modelos de extensibilidad para construir sobre el SaaS	Poco control: las soluciones SaaS suelen ser multiusuario (recursos compartidos por distintos clientes), y los detalles a nivel de recursos no están expuestos al cliente

Ofertas en la nube para Klodars Corporation

Klodars Corporation planeó implantar su solución como una solución híbrida, con su componente heredado ejecutándose en las instalaciones y sus componentes de análisis de datos ejecutándose en la nube. Eligió PaaS para su clúster de big data y el almacenamiento del lago de datos, ejecutando Apache Spark, y aprovechó una solución SaaS para su almacén de datos y el componente de cuadros de mando. Klodars comprendió el impacto de los recursos de red entre su solución local y su proveedor en la nube en el rendimiento de su solución, y planificó la capacidad adecuada con el proveedor en la nube. También ejecutó una PoC de la carga de trabajo de procesamiento de datos de uno de sus escenarios de uso intensivo de datos y cálculo -recomendación de productos y proyecciones de ventas- y se aseguró de que había elegido un clúster de big data con el conjunto adecuado de recursos.

Klodars también segmentó sus clusters -uno para escenarios de ventas, otro para escenarios de marketing y otro para escenarios de productos- para garantizar que un pico de carga de trabajo en uno de ellos no afectara al rendimiento de los demás. Para promover el intercambio de datos y conocimientos, los científicos de datos tenían acceso a todos los datos de producto, ventas y marketing para sus análisis exploratorios. Sin embargo, Klodars también proporcionó clústeres separados para los científicos de datos y estableció un límite para los recursos, de modo que hubiera barandillas contra trabajos espurios que pudieran acaparar recursos. Puedes ver un resumen de esta implementación en la Figura 4-7.

Figura 4-7. Implementación del lago de datos en Klodars Corporation

Planificar los picos de capacidad

Independientemente del tipo de solución que elijas, la planificación de la capacidad y la comprensión de la vía para adquirir más capacidad cuando tengas una demanda adicional son fundamentales para la solución del lago de datos en la nube. La planificación de la capacidad se refiere a la capacidad de predecir tu demanda a lo largo del tiempo, asegurarte de que estás equipado con los recursos adecuados para satisfacer esa demanda y tomar las decisiones empresariales correctas si no es así.

El primer paso es prever la demanda. Esto se puede conseguir de las siguientes maneras:

• Comprende las necesidades de tu empresa y los SLA que debes ofrecer a tus clientes. Por ejemplo, si el último lote de tus datos llega a las 10 de la noche, y tu promesa a tus clientes es que verán un cuadro de mandos actualizado a las 8 de la mañana, entonces tienes una ventana de 10 horas para hacer tu procesamiento, quizá 8 horas si quieres dejar un margen.

• Comprende la utilización de tus recursos en la nube. La mayoría de los proveedores de la nube ofrecen soluciones de monitoreo y observabilidad que puedes aprovechar para comprender cuántos recursos estás utilizando. Por ejemplo, si tienes un clúster con 4 CPU virtuales (vCPU) y 1 GB de memoria, y observas que tu carga de trabajo utiliza el 80% de la CPU y el 20% de la memoria en total, entonces sabrás que podrías pasar a un SKU o tipo de clúster diferente que tenga más CPU y menos memoria, o podrías aprovechar la memoria para almacenar en caché algunos resultados con optimizaciones, de modo que puedas reducir la carga de la CPU.

• Planifica los picos de demanda y de utilización. La gran ventaja de pasarse a la nube es la elasticidad que ésta ofrece. Al mismo tiempo, siempre es mejor tener un plan sobre cómo escalarás exactamente tus recursos en los picos de demanda. Por ejemplo, tus cargas de trabajo actuales están soportadas por un clúster que tiene cuatro vCPU y 1 GB de memoria. Cuando preveas un aumento repentino de la carga, bien porque sea la temporada de cierre de presupuestos si gestionas servicios financieros, bien porque te estés preparando para la demanda navideña si perteneces al sector minorista, ¿cuál sería tu plan? ¿Aumentarías los recursos de tus clusters existentes, o tus trabajos están lo suficientemente segmentados como para añadir clusters adicionales bajo demanda? Si necesitas traer más datos durante este tiempo desde tus sistemas locales, ¿has planificado también la explosión adecuada en la capacidad de red?

  Puedes utilizar una de las dos estrategias de escalado : escalado horizontal o escalado vertical.El escalado horizontal, también denominado escalado vertical, consiste en escalar una unidad de escala (por ejemplo, VM o clúster) y añadir más de esas unidades de escala. Tu aplicación también tendría que ser consciente de esta unidad de escala. El escalado vertical, también denominado escalado ascendente, implica mantener la unidad de escala tal cual y añadir más recursos (por ejemplo, CPU o memoria) bajo demanda. Cualquiera de las dos estrategias funciona bien, siempre que seas consciente del impacto en tus necesidades empresariales, tus ANS y tu implementación técnica.

En la Tabla 4-3, verás el conjunto de factores a tener en cuenta en relación con el monitoreo y la evaluación para la planificación de la capacidad. Fíjate también en los modelos de reserva disponibles, que permiten que las cargas de trabajo críticas de producción se ejecuten sin interferir con otras cargas de trabajo.

Tabla 4-3. Factores a considerar para la planificación de la capacidad

Componente	Factores a tener en cuenta
Computación IaaS	vCPU (núcleos), memoria, SKU (tipo de VM), caché disponible, tamaño del disco (GB/TB) y transacciones (TPS)
Computación PaaS	Tamaño del clúster, vCPU (núcleo) cuando estén disponibles, y unidades facturables publicadas por el proveedor de PaaS
Almacenamiento	Tamaño de los datos (TB/PB), transacciones (TPS) y nivel de almacenamiento (flash, discos, unidades de cinta en orden de alto a bajo rendimiento), según el rendimiento
Almacén de datos	SKUs: vigila la informática, el almacenamiento y las transacciones
Red	Entrada y salida, nivel (estándar/premium) y pasarelas con redes privadas

Para hacer la mejor estimación de las necesidades de capacidad, te recomiendo que ejecutes una PoC a escala que represente la carga de trabajo que estás ejecutando. Para la PoC, debes tener en cuenta la distribución del conjunto de datos que mejor represente tu carga de trabajo de producción. Si estás ejecutando una implementación local, un buen método es ejecutar una carga de trabajo existente en la nube. Si aprovechas las capacidades de autoescalado de tu clúster o las ofertas sin servidor de tu proveedor de la nube, muchas de estas funciones se gestionan automáticamente por ti.

Formatos de datos y perfil del puesto

El formato de datos que elijas desempeña un papel fundamental en el rendimiento y la escalabilidad de tu lago de datos. A menudo se ignora porque en los sistemas de almacenamiento de datos estructurados (bases de datos o almacenes de datos), este supuesto se daba por sentado. Los datos se almacenaban en un formato óptimo para los patrones de transacción del servicio de base de datos/almacén de datos. Sin embargo, dada la miríada de aplicaciones de procesamiento de datos que se ejecutan sobre el almacenamiento del lago de datos, y la premisa de que los mismos datos podrían utilizarse en los múltiples motores, la responsabilidad recae en los arquitectos de big data y los desarrolladores de elegir el formato adecuado para sus escenarios. Sin embargo, lo mejor de esto es que, una vez que encuentres el formato óptimo, comprobarás que tu solución ofrece un alto rendimiento y escala, junto con un menor coste de tu solución total. Dado el auge del lago de datos y la ubicuidad de tecnologías como Apache Spark para la computación por lotes, en flujo e interactiva, Apache Parquet, y los formatos basados en Parquet como Delta Lake y Apache Iceberg, están siendo adoptados ampliamente como formatos óptimos para la solución del lago de datos. Profundizaremos en ello en el Capítulo 6.

Otro aspecto que influye en tus necesidades de escalabilidad es la construcción de tu trabajo de procesamiento de big data. Normalmente, el trabajo puede dividirse en varias etapas de ingestión y procesamiento. Sin embargo, no todas las etapas son iguales. Como ejemplo, digamos que tu trabajo comprende las siguientes etapas:

1. Lee un conjunto de datos que tiene 150 millones de registros.

2. Filtra eso hasta los registros de interés, que son 50 millones de registros.

3. Aplica transformaciones a los 50 millones de registros para generar un conjunto de datos de salida.

En este escenario, si tu conjunto de datos de entrada comprende múltiples archivos pequeños, eso serviría como el polo largo de tu trabajo total. Introduciendo una nueva etapa en tu trabajo de compactación de los múltiples archivos pequeños en un pequeño número de archivos más grandes, puedes hacer que tu solución sea más escalable.

Resumen

En esta sección, profundizamos en las características de escalabilidad de la arquitectura de lago de datos en la nube y en lo estrechamente vinculada que está la escalabilidad al rendimiento. Comparamos una arquitectura de big data con un modelo desagregado de cálculo y almacenamiento con una arquitectura colocada y estrechamente acoplada, y examinamos las ramificaciones de esta desagregación en la escala. También examinamos las diversas consideraciones de la arquitectura de lago de datos en la nube que afectan a la escala: elegir las ofertas de nube adecuadas, planificar la capacidad y ajustar los formatos y la organización de los datos para que coincidan con los patrones de consulta. Estas son consideraciones que debes comprender para ajustar eficazmente la implementación de tu lago de datos para escalar 10×. En el Capítulo 5, nos basaremos en estos conceptos fundamentales de la escala para optimizar el rendimiento.