Construyendo el data stack perfecto (Parte 1): Conceptos previos y elección de plataformas
Lo prometido es deuda y empiezo esta serie de artículos sobre cómo construir lo que bajo mi punto de vista es un data stack perfecto o por lo menos realmente útil. Mi intención no es otra que la de compartir mi experiencia durante estos últimos años, en la que he estado trabajando en la construcción de un gran data stack en Isdin y también he ayudado a compañeros de empresas más pequeñas a construir sus pequeños data stacks. Hablaré de lo que a mi me parece correcto, pero también de cosas que hice mal en su día o que por lo menos ahora haría de otra forma. Lo haré desde un punto de vista funcional tocando algunos aspectos técnicos fundamentales, pero no entraremos en código, ya que no es la finalidad de estos artículos.
Si no tienes un perfil técnico, no te asustes y sigue leyendo, ya que estos artículos te permitirán entender qué compone un data stack y como empezar a montarlo. Te servirán para hablar con proveedores que te empiecen a ayudar con la parte técnica.
Antes de empezar con el artículo en sí, quisiera comentar que si estás trabajando en una empresa con bastantes fuentes de datos distintas (ecommerce, Analytics, inversión en facebook, inversión en google, FTP's, API's de terceros...) :
Construir un data stack que te ayude a almacenar todos los datos en un mismo lugar (Data warehouse), de una forma estructurada, es lo mejor que puedes hacer y el esfuerzo vale realmente la pena
Me gustaría empezar con mi particular definición de data stack, para que todos partamos desde el mismo lugar. Cuando hablo de data stack me refiero a las aplicaciones que hacen posible la carga, almacenaje y explotación de los datos. Por tanto:
- Sistemas de carga: Son los que permiten traerse los datos desde cualquier fuente de datos (herramientas de analitics, marketing, web....) y volcarlos en una base de datos (data warehouse). A veces, se usan sistemas intermedios (Data Lakes) para guardar la información en crudo para después procesarla. Hablaré de ello más adelante.
- Almacenado de datos (Data Lakes y Data Warehouse): Son las bases de datos a la que van a parar los datos que nos traen los sistemas de carga. Son conocidos como Data Lakes y Data Warehouse (explicaré las diferencias entre ellos). Los Data Warehouse son el destino final de los datos y suelen ser sistemas con una estructura pensada para que sea sencillo unir y analizar datos de las diferentes fuentes (Ejemplo: Google Big Query o Amazon Redshift). Suelen ser bases de datos llamadas analíticas, cuya característica más destacable es que pueden leer miles de datos de forma muy rápida. No están pensadas para ser usadas en aplicaciones webs y cosas por el estilo, para esto ya existen las bases de datos transaccionales. Insisto, los data warehouse están hechos para analizar información. A modo de ejemplo, aquí podéis ver las opciones de bases de datos del ecosistema de Google, donde se ven diferenciadas las bases de datos transaccionales de las analíticas (que son las que usamos como data warehouse).
- Explotación de los datos: Hay múltiples maneras de explotar los datos. Una de las más habituales es conectar nuestro Data Warehouse a una herramienta de visualización/BI tipo Tableau, Power BI, Looker, Data Studio (gratuita)... Con sistemas de Machine Learning también se pueden crear, entrenar y publicar modelos predictivos o de clasificación. Por ejemplo, crear un sistema de alertas que detecte cuando un producto se ha vendido más o menos de lo esperado, crear un forecast de ventas etc. Otra forma de explotación es lanzar consultas (querys) directamente contra el data warehouse... Esta parte es fundamental, ya que de nada sirve tener un super sistema montado si los datos no son entendibles para el resto del equipo (que no suele tener conocimientos técnicos). Por tanto, esto va de explicar historias con los datos y hacerlos útiles y entendibles para todos.
Hasta aquí la breve definición de los elementos que componen un Data Warehouse. Ahora sí que sí, voy a comentar qué cosas considero fundamentales antes de ponerse a construir el data lake.
Selección de la plataforma. ¿En Cloud o On Premise?
La primera pregunta que nos debemos hacer es si queremos un sistema en cloud o por el contrario un sistema en servidores propios almacenado por nuestro equipo de sistemas. Si tu empresa tiene ya servidores propios y equipos de sistemas con conocimientos avanzados, puedes plantearte la opción de montarlo en servidores propios. Por lo general no soy partidario de este método por varios motivos:
- Escalabilidad
- Seguridad
- Disponibilidad
- Coste
Puedes conseguir un sistema construido en servidores propios que sea seguro y con alta disponibilidad...incluso con bastante escalabilidad...pero dificilmente igualarás el nivel que ofrecen plataformas como Google Cloud, Amazon AWS, Azure, Snowflake... En el pasado, algunas empresas se decantaban más por sistemas propios porque les daba miedo exponer sus datos en bases de datos de terceros y porque además el uso de los sistemas en cloud no estaba tan extendido como ahora, que muchísimas empresas usan ya sistemas en cloud.
Si te decantas por montarlo en la nube, tienes a tu alcance diversas plataformas. Las más usadas son posiblemente las 4 que he mencionado arriba y ofrecen sistemas con características similares (por lo menos para usuarios normales que no busquen algo muy concreto). Estás herramientas ofrecen decenas de módulos/aplicaciones con diverso alcance para realizar todo tipo de tareas relacionadas con los datos. Desde la carga hasta la explotación vía Machine Learning y la visualización. Os dejo esta cheatsheet de las herramientas que existen en GCP, divididas por su finalidad:
Recomendado por LinkedIn
Yo he usado dos de estas plataformas, AWS y GCP, aunque muchísimo más la segunda.
Hay varios motivos por los que he usado mucho más el entorno Google (GCP):
- Me parece una interfaz mucho más amigable/usable
- Suelo trabajar con herramientas de tracking y marketing que pertenecen a Google y la integración es mucho mejor dentro de un ecosistema Google. Ej: Google Analytics , Campaign Manager etc
- Por lo general, me gusta mucho más la documentación de Google que la de AWS.
- Conozco mucho mejor GCP y se me hace más fácil realizar ciertas tareas.
Dicho esto, es importante saber que podrías usar una de estas herramientas simplemente como Data Warehouse y usar herramientas de otra compañia como sistema de carga o como visualización. Es algo bastante común de los que hablaré a continuación para finalizar este artículo.
Eligiendo el sistema de carga de datos
Más allá de la solución de data warehouse que elijas (que comentaremos en próximos artículos) la selección del sistema de carga de datos es la parte más compleja y de lo que dependerá el éxito del proyecto. Hay múltiples formas y herramientas para cargar los datos a un data warehouse / data lake (unas requieren de programación y otras no), pero cada una tiene sus PROS y sus CONTRAS. Por ello hay varios factores importantes de cara a decantarse por uno u otro:
- Data Enginers in house o subcontratados: Si dispones o puedes disponer de un equipo de data enginers es importante de cara a tomar la decisión. Tened en cuenta que este tipo de proyectos pueden empezarse con una agencia especialidad en datos para la creación, pero suelen ser empresas caras para el mantenimiento del proyecto (no os bajará de 60/70 la hora), por tanto lo ideal si te decantas por un sistemas hecho a medida es crear un equipo de varias personas (según el número de procesos) para el mantenimiento del mismo
- Presupuesto disponible
- Número y tipo de fuentes de datos de las que quieres extraer data: El número de fuentes de datos a las que te quieras conectar es un factor importante en algunos sistemas que te comentaré a posteriori. También lo es el tipo de herramientas de las que quieras extraer datos. Si son aplicaciones comunes (Google Ads, Facebook, Salesforce, Oracle...) lo podrás hacer con prácticamente cualquier tipo de herramienta. Si son cosas muy específicas posiblemente tengas que ir a programación propia.
Voy a comentar varios escenarios para que puedan ayudarte a tomar la decisión:
- Si no tienes un equipo muy técnico ni quieres tenerlo y además no esperas leer de muchas fuentes, lo ideal es que te decantes por soluciones que hacen la carga de datos de forma automática sin que tengas que programar tu la conexión ni hacer el control de datos. Estas soluciones son bastante caras si tienes muchas fuentes de datos, ya que suelen cobrar por fuente de datos o por datos descargados. Algunos ejemplos son Dataddo, Stitch, Fivetran... Dataddo por ejemplo tiene un coste de unos 30€ por fuente al mes, aunque supongo que es posible obtener algún tipo de descuento al tener varias fuentes conectadas. Lo bueno de estas soluciones es que son 100% mantenidas, es decir, se actualizan a las nuevas versiones. Además se suelen conectar con las fuentes más comunes del mercado (ejemplo: Google Analytics, Google Ads, Facebook Ads, TikTok Ads...) y puedes enviar la data a las herramientas de data warehousing más comunes (Big query, Redshift, Snowflake...). Yo he usado Dataddo para pequeños data warehouse en los que simplemente hacía falta leer de 4 o 5 fuentes y el resultado es realmente bueno, aunque algo caro.
- Si tienes o esperas crear un equipo de Data Enginers para crear o mantener tu arquitectura de datos y además esperas leer de muchas fuentes de datos, mi recomendación es que vayas para alguna solución programada por tu equipo/agencia. Todas las plataformas que te he nombrado tienen una o varias aplicaciones del estilo incorporadas. Por ejemplo GCP tiene Composer (apache airflow) o dataflow para algunos casos concretos, AWS tiene Amazon Data Pipeline o AWS glue, Azure tiene Azure Data Factory... Estas soluciones tiene un coste que depende de varios factores, pero no del número de fuentes que conectes, ya que puedes conectarte con tantas como quieras (con el handicap de que se tienen que programar y mantener). Por dar un aproximado pueden tener un coste que vaya desde los 300 hasta los 700 euros al mes para un entorno productivo.
Estos dos escenarios serían los más claros, pero si te encuentras en algo intermedio te tocará decidir pensando en el futuro. Es importante tener clara la decisión, ya que una futura migración a otra herramienta puede ser realmente costosa.
Uno de los errores habituales y que yo cometí es empezar un proyecto de este calibre, con todo hecho a medida sin tener un equipo técnico con la escalabilidad necesaria para asegurar el futuro. Lo ideal es que te puedas anticipar al futuro y cuando veas que te estás quedando sin recursos, contratar a un nuevo data engineer. Si no lo haces, no podrás mantener la plataforma como sería deseable. Irás metiendo parches que te dejarán deuda técnica y te tocará refactorizar procesos en el futuro...algo que no suele ser nada sencillo.
Por todo ello, este punto es fundamental de cara a asegurar el éxito del proyecto. Es importante pararte a pensar en los cimientos antes de empezar, ya que todo tiene implicaciones futuras...pero si lo montas con cabeza, será una de las mejores decisiones que hayas tomado.
¡Y hasta aquí esta primera parte! Si has llegado hasta aquí, espero que te haya gustado y te haya servido de algo.
En la segunda parte te hablaré de las diferentes metodología de carga y transformación de datos (EL, ETL, ELT) y de la selección y organización del data warehouse.
Un abrazo
Business development | Project management | Software development manager (EVIDEN/ATOS)
2 añosGracias por compartir, muy bien explicado!, gracias!
Chief Digital Officer en Cash Converters España
2 añosGran contenido, gracias por compartir David Garcia Estaun
🚀 Data Architect & Team Lead | | Transformando Datos en Conocimiento Valioso | Gestionando equipos de datos | Certificado en #PowerBI, #DataEngineering y #FabricEngineering
2 añosMuy interesante David Garcia Estaun , gracias por compartir!!
Senior Experienced Consultant en Deloitte Digital
2 añosMuchas gracias David! Muy top!