En los últimos años, he tenido muchas conversaciones con amigos y colegas frustrados por lo inescrutablemente complejo que es el ecosistema de infraestructura de datos. Aunque no es tan malo como el mundo del front-end, las cosas están cambiando lo suficientemente rápido como para crear una sopa de palabras de moda.

Como principiante, es muy difícil decidir qué herramientas son adecuadas para usted. La Fundación Apache enumera 38 proyectos en la sección» Big Data», y estas herramientas tienen toneladas de superposición en los problemas que dicen abordar. Por ejemplo, Flink, Samza, Storm y Spark Streaming son «motores de procesamiento de flujo distribuido», Apex y Beam «unifican el procesamiento de flujo y por lotes».

En esta publicación, espero proporcionar algo de ayuda para navegar por las opciones a medida que se dispone a crear infraestructura de datos. Estos son, aproximadamente, los pasos que seguiría hoy, basados en mis experiencias de la última década y en conversaciones con colegas que trabajan en este espacio.

Al comienzo de su proyecto, probablemente se está iniciando con nada más que un objetivo de «obtener información de mis datos» en la mano. Asignar esto a un conjunto específico de tecnologías es extremadamente desalentador. Probablemente no tenga una gran idea de qué herramientas son populares, qué significa «transmisión» o «lote», o si incluso necesita infraestructura de datos.

En esta publicación, espero proporcionar algunas pautas para ayudarlo a despegar rápidamente y extraer valor de sus datos. Creo firmemente en mantener las cosas simples el mayor tiempo posible, introduciendo complejidad solo cuando es necesario para la escalabilidad. Este post sigue ese arco a través de tres etapas. En muchos sentidos, sigue los pasos de la creación de infraestructura de datos que he seguido en los últimos años.

tenga en cuenta que no hay una manera correcta de arquitecto de infraestructura de datos. Para los expertos que leen esto, es posible que haya preferido alternativas a las soluciones sugeridas aquí. Eso es fantástico, y destaca la diversidad de herramientas increíbles que tenemos en estos días. Hemos recorrido un largo camino desde que Hadoop MapReduce era todo lo que teníamos.

Así que aquí está la cosa: probablemente no tengas «big data» todavía. Casi 4 años después, el artículo de Chris Stucchio de 2013 No uses Hadoop sigue en pie. Si tiene menos de 5 TB de datos, comience con poco. Esto le ahorrará dolores de cabeza operativos con sistemas de mantenimiento que aún no necesita. Pero bueno, si te encantan los simulacros de incendio 3am de fallas en el trabajo, no dudes en omitir esta sección

De lo contrario, mantente alejado de todas las tecnologías de palabras de moda al principio y céntrate en dos cosas: (1) hacer que tus datos sean consultables en SQL y (2) elegir una herramienta de BI. Estos serán la columna vertebral de «Hola, Mundo» para toda su futura infraestructura de datos.

Todo en SQL

Esto es realmente importante, porque desbloquea datos para toda la organización. Con raras excepciones para la gente de marketing más intrépida, nunca convencerá a sus colegas no técnicos para que aprendan Kibana, grep algunos registros o usen la oscura sintaxis de su almacén de datos NoSQL.

Proporcionar acceso SQL permite a toda la empresa convertirse en analistas de autoservicio, lo que saca a su equipo de ingeniería, que ya está sobrecargado, del camino crítico. También convierte a todos en un equipo de control de calidad gratuito para sus datos. El «hey, estos números se ven un poco raros is» es invaluable para encontrar errores en sus datos e incluso en su producto.

Si su almacén de datos principal es una base de datos relacional como PostgreSQL o MySQL, esto es realmente simple. Puede configurar una réplica de lectura, aprovisionar acceso y listo.

Con una base de datos NoSQL como ElasticSearch, MongoDB o DynamoDB, necesitará hacer más trabajo para convertir sus datos y colocarlos en una base de datos SQL. Si es nuevo en el mundo de los datos, lo llamamos canalización ETL. Evite construir esto usted mismo si es posible, ya que cablear una solución lista para usar será mucho menos costoso con volúmenes de datos pequeños. Dependiendo de su infraestructura existente, puede haber un segmento como proveedor de ETL en la nube que pueda aprovechar.

Si encuentra que necesita crear sus propias canalizaciones de datos, manténgalas extremadamente simples al principio. Escriba un script para volcar actualizaciones periódicamente desde su base de datos y escríbalas en algún lugar consultable con SQL.

La historia de ETLing de datos de fuentes de terceros es similar a la de las bases de datos NoSQL. Utilice un proveedor de ETL como servicio o escriba un script sencillo y deposite sus datos en una base de datos consultable por SQL.

Configure una máquina para ejecutar su(s) script (s) ETL como cron diario, y estará listo para las carreras.

Herramienta de BI

Una buena herramienta de BI es una parte importante de la comprensión de sus datos. Algunas herramientas excelentes a tener en cuenta son Chartio, Análisis de modos y Datos de Periscopio; cualquiera de estas herramientas debería funcionar muy bien para que sus análisis despeguen. En la mayoría de los casos, puede apuntar estas herramientas directamente a su base de datos SQL con una configuración rápida y sumergirse directamente en la creación de paneles.

Uniendo todo esto, aquí está el «Hola, Mundo» de la infraestructura de datos:

Etapa 1: La canalización de datos pequeños» Hola, Mundo «

Etapa 2: Llamémosla datos «medios»

En este punto, tiene más de unos pocos terabytes flotando, y su ETL de script cron+no se mantiene al día. Tal vez haya proliferado los almacenes de datos y tenga una mezcla heterogénea de backends SQL y NoSQL. También es posible que ahora tenga un puñado de terceros de los que está recopilando datos. Por último, es posible que esté comenzando a tener varias etapas en sus canalizaciones ETL con algunas dependencias entre pasos.

Gestión del flujo de trabajo & Automatización

Su primer paso en esta fase debe ser configurar el flujo de aire para administrar sus tuberías ETL. Airflow le permitirá programar trabajos a intervalos regulares y expresar dependencias temporales y lógicas entre trabajos. También es un excelente lugar en su infraestructura para agregar reintentos de trabajos, monitorizando & alertando de errores de tarea. Es una broma corriente que cada inicio por encima de un cierto tamaño escriba su propio gestor de flujo de trabajo / programador de tareas. Entre otros, Spotify escribió Luigi y Pinterest escribió Pinball. Sin embargo, estos tienen menos impulso en la comunidad y carecen de algunas características con respecto al Flujo de aire.

Construcción de tuberías ETL

A medida que su negocio crezca, sus requisitos de tuberías ETL cambiarán significativamente. Tendrá que comenzar a construir una infraestructura más escalable porque un solo script ya no lo cortará. También es probable que sus objetivos se expandan de simplemente habilitar el acceso SQL a abarcar el soporte de otros trabajos posteriores que procesan los mismos datos.

eventualmente, las canalizaciones simples no escalarán

Para abordar estos requisitos cambiantes, querrá convertir sus scripts ETL para que se ejecuten como un trabajo distribuido en un clúster. El número de soluciones posibles aquí es absolutamente abrumador. Recomiendo encarecidamente comenzar con Apache Spark. Spark tiene una comunidad enorme y muy activa, se adapta bien y es bastante fácil de poner en marcha rápidamente. En AWS, puede ejecutar Spark con EMR; para GCP, con Cloud Dataproc. Si está ingiriendo datos de una base de datos relacional, Apache Sqoop es prácticamente el estándar.

En este punto, su infraestructura ETL comenzará a parecerse a etapas segmentadas de trabajos que implementan los tres verbos ETL: extraer datos de fuentes, transformar esos datos a formatos estandarizados en almacenamiento persistente y cargarlos en un almacén de datos consultable por SQL.

Almacén de datos

En esta etapa, obtener todos sus datos en SQL seguirá siendo una prioridad, pero este es el momento en que querrá comenzar a construir un almacén de datos «real».

Para aquellos que están empezando, recomiendo usar BigQuery. BigQuery es fácil de configurar (solo puede cargar registros como JSON), admite tipos de datos anidados/complejos y está completamente administrado/sin servidor, por lo que no tiene más infraestructura que mantener. Al igual que con muchas de las recomendaciones aquí, hay alternativas a BigQuery disponibles: en AWS, Redshift y en las instalaciones, Presto. Tengo una fuerte preferencia por BigQuery sobre Redshift debido a su diseño sin servidor, simplicidad de configuración de seguridad/auditoría adecuada y soporte para tipos complejos. Vale la pena considerar el presto si tiene un requisito difícil para el prem.

Al pensar en configurar su almacén de datos, un patrón conveniente es adoptar un modelo de 2 etapas, donde los datos sin procesar se depositan directamente en un conjunto de tablas, y un segundo puesto de trabajo procesa estos datos en tablas «más limpias».

Trate estas mesas más limpias como una oportunidad para crear una visión curada de su negocio. Para cada una de las entidades clave de su negocio, debe crear y seleccionar una tabla con todas las métricas/KPI y dimensiones que utiliza con frecuencia para analizar esa entidad. Por ejemplo, una tabla de «usuarios» puede contener métricas como el tiempo de registro, el número de compras y dimensiones como la ubicación geográfica o el canal de adquisición.

al final de todo esto, la infraestructura debe ser algo como esto:

Etapa 2: el «medio» canalización de los datos

🚀 Etapa 3: Crecer a lo grande

Con los cimientos correctos, un mayor crecimiento no tiene por qué ser doloroso. A menudo, puede arreglárselas simplemente lanzando hardware al problema de manejar mayores volúmenes de datos.

Los problemas más difíciles en este período a menudo no son solo la escala bruta, sino la ampliación de los requisitos. Por ejemplo, tal vez necesite admitir pruebas A/B, entrenar modelos de aprendizaje automático o canalizar datos transformados en un clúster de ElasticSearch.

Algunas cosas que puede considerar en esta fase:

  • Casi en Tiempo real: Es probable que no necesite una cola distribuida o una infraestructura casi en tiempo real hasta mucho más tarde de lo que podría pensar. Viene con mucha complejidad adicional para manejar todos los modos de falla posibles, lo cual no vale la pena al principio. Una vez que el cálculo del ROI tenga sentido, pruebe Kafka o Cloud Pub/Sub.Escalabilidad
  • : Con un solo clúster de Spark monolítico, es casi seguro que tendrá problemas con la contención de recursos. Cuando lo hace, vale la pena explorar los clústeres Spark con alcance de trabajo completamente elásticos.
  • Seguridad & Auditoría: En algún momento, es posible que desee aplicar controles de acceso más detallados a los datos de su almacén de datos. Si utiliza BigQuery, puede aprovisionar el acceso a conjuntos de datos a grupos de Google y administrar ese acceso mediante programación mediante el Administrador de implementación. BigQuery también proporciona registros de auditoría para comprender las consultas de los usuarios. Otras herramientas como Apache Knox y Apache Sentry están disponibles para soluciones de seguridad locales.
  • Pruebas A/B: Para crear pruebas A/B internas y apoyar la experimentación, desafortunadamente no hay muchas soluciones listas para usar. Crear una canalización de trabajos de Spark que llenen tablas en su almacén de datos es probablemente su mejor apuesta.
  • Aprendizaje automático: Para la extracción de funciones, puede crear canalizaciones de datos adicionales en Spark. Para los modelos en sí, debe comenzar de nuevo con poco. Sus características procesadas son lo suficientemente pequeñas como para caber en una máquina, por lo que puede entrenar modelos utilizando scikit-learn o TensorFlow. Cuando una máquina ya no es suficiente, puede usar Spark MLlib o distributed TensorFlow.

El futuro

Es emocionante ver cuánto ha mejorado el ecosistema de infraestructura de datos en la última década. Hemos recorrido un largo camino desde el cuidado de los clústeres de Hadoop y la gimnasia hasta coaccionar nuestra lógica de procesamiento de datos en mapas y reducciones en Java incómodo. En aquel entonces, construir una infraestructura de datos era como intentar construir un rascacielos con un martillo de juguete.

Hoy en día, tenemos una increíble diversidad de herramientas. Spark ha dominado claramente como el reemplazo de todos los oficios de Hadoop MapReduce; lo mismo está empezando a suceder con TensorFlow como plataforma de aprendizaje automático. Con muy pocas excepciones, no es necesario crear infraestructura o herramientas desde cero en la empresa en estos días, y probablemente no necesite administrar servidores físicos. El rascacielos ya está ahí, solo tienes que elegir los colores de pintura.

el futuro sin servidor: será totalmente así

De cara al futuro, espero que la infraestructura y las herramientas de datos continúen avanzando hacia plataformas completamente sin servidor: DataBricks acaba de anunciar una oferta de este tipo para Spark. La infraestructura sin servidor permite una separación elegante de preocupaciones: los proveedores de la nube pueden preocuparse por el hardware, devops y herramientas, lo que permite a los ingenieros centrarse en los problemas que son únicos (y están alineados con) sus negocios. El futuro es uno sin fallas de hardware, problemas con los cuidadores de zoológico o problemas con la contención de recursos de YARN, y eso es realmente genial.

Editar: agregar enlaces a algunas publicaciones anteriores que escribí sobre la infraestructura de datos de Thumbtack:

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

lg