Los datos por sí solos no son suficientes: la evolución de las arquitecturas de datos

Datos, datos, datos: durante mucho tiempo ha sido una palabra de moda en la industria, ya sea big data, streaming de datos, análisis de datos, ciencia de datos, incluso inteligencia artificial y aprendizaje automático, pero los datos por sí solos no son suficientes: se necesita un sistema completo de herramientas y tecnología. para extraer valor de los datos.

Ha surgido una industria multimillonaria en torno a herramientas y tecnologías de datos. Y con tanta emoción e innovación en el espacio: ¿cómo encajan exactamente todas estas herramientas?

Este podcast, una conversación al estilo de pasillo entre Ali Ghodsi, CEO y fundador de Databricks, y el socio general de a16z Martin Casado, explora la evolución de las arquitecturas de datos, incluido un breve historial, hacia dónde se dirigen y un caso de uso sorprendente para la streaming de datos , así como la opinión de Ali sobre cómo diseñaría los picos y las palas que manejan los datos de un extremo a otro en la actualidad.

Una breve historia de las arquitecturas de datos

Comenzó en los 80. Los líderes empresariales volaban a ciegas, sin saber cómo iba el negocio, esperando que las finanzas cerraran los libros. Este paradigma de almacenamiento de datos surgió cuando dijeron: “Mire, tenemos todos estos datos en estos sistemas de datos operativos. ¿Por qué no obtenemos todos esos datos, los sacamos de todos estos sistemas, los transformamos en un lugar central, llamémoslo un data warehousing, y luego podemos obtener inteligencia empresarial sobre esos datos? “

Y fue solo una transformación importante porque ahora podría tener paneles de control. Podía saber cómo se vendía su producto por región, por SKU, por geografía. Eso ha creado un mercado de al menos $ 20 mil millones que ha existido durante bastantes décadas.

Pero hace unos 10 años, esta tecnología comenzó a enfrentar algunos desafíos. Comenzaron a aparecer uno, más y más tipos de datos, como video y audio, y no hay forma de que pueda almacenar nada de eso en almacenes de datos.

En segundo lugar, eran cajas grandes locales que había que comprar. Y unieron el almacenamiento y la computación, por lo que resultó muy costoso escalarlos hacia arriba y hacia abajo.

Y tercero, la gente quería hacer más y más aprendizaje automático e IA en estos data sets. Vieron que podemos hacer preguntas sobre el futuro. “¿Cuáles de mis clientes van a abandonar? ¿Cuáles de mis productos se van a vender? ¿Qué campañas debo ofrecer a quién? “

El Data Lake surgió hace unos 10 años. Y la idea era: “Aquí hay un almacenamiento realmente barato, volca todos tus datos aquí y podrás obtener toda esa información. Y resulta que, simplemente volcando todos sus datos en una ubicación central, es difícil encontrarle sentido a los datos que están ahí. Como resultado, lo que la gente está haciendo ahora es tomar subconjuntos de esos datos y moverlos a almacenes de datos clásicos en la nube.

Entonces, terminamos con un desorden arquitectónico que es inferior al que teníamos en los años 80, donde tenemos datos en dos lugares, en el Data Lake y en el data warehousing donde la obsolescencia y la actualidad no son grandes.

En los últimos dos o tres años, hubo algunos avances tecnológicos realmente interesantes que están permitiendo un nuevo tipo de patrón de diseño. Nos referimos a ella como lakehouse. Y la idea es: ¿y si pudiera hacer BI directamente en su Data Lake? ¿Y si pudiera hacer sus informes directamente en su Data Lake y pudiera hacer su ciencia de datos y su aprendizaje automático directamente en el Data Lake?

En los últimos 2–3 años, hubo algunos avances tecnológicos realmente interesantes que están permitiendo un nuevo tipo de patrón de diseño: la lakehouse. Y la idea: ¿y si pudiera hacer BI directamente en su Data Lake? -Ali Ghodsi

Analítica y IA / ML: ¿uno o dos mercados?

Martin: Me encantaría desglosar algunas cosas que nos han llevado hasta aquí. Es muy evidente que existe un gran mercado de data warehouse en torno a BI y análisis, tipificado por personas que utilizan SQL en datos estructurados.

Parece que el caso de uso de ML e IA es un poco diferente al caso de uso de análisis. El caso de uso de análisis es normalmente seres humanos que miran paneles y toman decisiones, mientras que en el caso de uso de ML / AI, estás creando estos modelos y esos modelos se ponen en producción y son parte del producto. Están evaluando precios, detectando fraudes, asegurando, etc.

El mercado analítico es un comportamiento de compra existente y un cliente existente. ML / AI es un mercado emergente. Entonces, la pregunta central es: ¿estamos realmente viendo la aparición de múltiples mercados o es este un solo mercado?

Ali: Hay grandes similitudes y grandes diferencias. Empecemos por las similitudes. Se necesitan aproximadamente los mismos datos para ambos. No hay duda de que, cuando se trata de inteligencia artificial y aprendizaje automático, gran parte del secreto para obtener resultados o predicciones realmente excelentes proviene de aumentar sus datos con los metadatos adicionales que tiene.

En cierto sentido, tenemos los mismos datos y usted está haciendo preguntas analíticas. La única diferencia es que uno mira hacia atrás, el otro mira hacia el futuro. Pero aparte de eso, desea hacer el mismo tipo de cosas con los datos. Quieres prepararlo. Quieres tenerlo para que puedas encontrarle sentido. Si tiene problemas estructurales con sus datos, eso también causa problemas para el aprendizaje automático.

Las diferencias hoy en día son que es una línea de negocio que normalmente se dedica a la ciencia de datos e inteligencia artificial o investigación y desarrollo intensos. Mientras que el almacenamiento de datos y BI a menudo se encuentran en TI. Los usuarios del data warehousing y las herramientas de BI son analistas de datos y analistas comerciales. En el caso del aprendizaje automático, tenemos científicos de datos e ingenieros de aprendizaje automático. Entonces, las personas son diferentes y se sientan en un lugar diferente en la organización. Esas personas tienen diferentes antecedentes y tienen diferentes requisitos para los productos que utilizan en la actualidad.

El mercado de la analítica es un cliente existente. ML / AI es un mercado emergente. Entonces, la pregunta central es: ¿estamos realmente viendo la aparición de múltiples mercados o es este un solo mercado?

¿Pero no podemos simplemente usar SQL?

Martin: Si habla con algunas personas que provienen del lado del analista tradicional, dirán: “La inteligencia artificial y el aprendizaje automático son geniales, pero si realmente miras lo que están haciendo, solo están haciendo regresiones simples. ¿Por qué no usamos el modelo tradicional de data warehouse con SQL, y luego ampliamos SQL para hacer regresiones básicas y cubriremos el 99% de los casos de uso?

Ali: Sí, es interesante que preguntes porque de hecho lo intentamos en UC Berkeley. Hubo un proyecto de investigación que analizó: ¿Hay alguna manera de tomar un modelo relacional existente y aumentarlo con el aprendizaje automático?

Y después de cinco años, se dieron cuenta de que en realidad es realmente difícil incorporar el aprendizaje automático y la ciencia de datos a estos sistemas. La razón es un poco técnica, solo tiene que ver con el hecho de que estos son algoritmos iterativos y recursivos que continúan mejorando la medida estadística hasta que alcanza un cierto umbral y luego se detienen. Eso es difícil de implementar además del data warehouse.

Si miras los artículos que se publicaron a partir de ese proyecto, la conclusión fue que realmente tenemos que hackearlo duro, y no va a ser bonito. Si está pensando en el modelo relacional de Codd con SQL encima, no es suficiente para hacer cosas como el aprendizaje profundo y demás.

Martin: ¿Es cierta la misma afirmación acerca de pasar de algo diseñado para IA y ML y luego hacer que sea compatible con un modelo relacional de analista tradicional?

Ali: Curiosamente, creo que la respuesta es no, porque ahora existe una API de ciencia de datos generalizada que ha surgido como la lengua franca para los científicos de datos: data frames.

Básicamente, un data frames es una forma en la que puede tomar sus datos y convertirlos en tablas y comenzar a realizar consultas sobre ellos. Eso suena mucho a SQL, pero no lo es, porque en realidad está construido con soporte de lenguaje de programación para que pueda hacerlo en lenguajes de programación, como Python o R, que le permiten hacer ciencia de datos.

Entonces, ahora sus datos están en tablas, y resulta que ahora también puede construir SQL sobre marcos de datos. Puede conseguir un matrimonio entre el mundo de la ciencia de datos y el aprendizaje automático y el mundo de BI y análisis de datos, utilizando marcos de datos.

Martin: Entiendo lo que dice sobre el data warehousing, pero hay mucho más que los datos almacenados en el data warehousing. Todavía tienes todo este mundo de datos, SQL y ETL. ¿Hay una disonancia ahí o se quedan dos mundos? ¿Lo que pasa?

Ali: Todas las empresas con las que hablamos, tienen la mayoría de sus datos en el Data Lake en la actualidad, y un subconjunto de ellos va al data warehousing.

Hay un ETL de dos pasos que hacen. El primer paso de ETL es ingresar al Data Lake, y luego hay un segundo paso de ETL que usan para moverlo al almacén. Por lo tanto, las organizaciones están pagando un precio elevado por esta redundancia arquitectónica.

Pero la pregunta es: ¿realmente necesita dos copias? ¿Y realmente tienes que mantener esas dos copias y mantenerlas sincronizadas? ¿Va a tener un mundo en el que tenga todos sus datos en el Data Lake y luego haga su aprendizaje automático y ciencia de datos en él, y luego subconjuntos de ellos se trasladen nuevamente a un data warehousing, donde los limpia y coloca en esa forma estructurada para que pueda hacer SQL y BI, o ¿podemos hacerlo todo en un solo lugar?

Martin: De hecho, hagamos esa pregunta específica. Porque a pesar de que AI-ML es un mercado grande con mucho valor, existe un montón de flujo de trabajo existente en torno a BI.

Tiene todos los paneles y herramientas que se basan en SQL para almacenes de datos, pero también tiene personas que quieren interactuar con los datos muy rápidamente y usarán algo como ClickHouse o Druid para hacerlo en OLAP. OLAP significa procesamiento analítico en línea y es efectivamente una interfaz rápida que admite consultas rápidas. Luego tiene un procesamiento por lotes más tradicional, que normalmente la gente ha pensado en Spark. Lo que está diciendo es que puede combinar todas estas cosas en el mismo Data Lake, incluidas las cargas de consultas OLAP.

Ali: Sí, de hecho creo que puedes llegar hasta allí. Los datalakes son una fuente amplia. Almacenamiento grande, grande y barato, pero una especie de pantanos de datos.

Resulta que hay algunos avances tecnológicos recientes que le muestran cómo básicamente puede convertirlos en un sistema de almacenamiento relacional estructurado. La forma en que lo hace es construir transaccionalidad en estos datalakes.

Una vez que tenga eso, ahora puede comenzar a agregar cosas, como esquemas, encima de ellos. Una vez que agregue esquemas encima de ellos, puede agregar métricas de calidad. Y una vez que tenga eso, puede comenzar a razonar sobre sus datos como datos estructurados en tablas en lugar de datos que son solo archivos.

Martin: Pongo la estructura en la parte superior de una tienda de blobs, pero aún necesitas una consulta más tarde, ¿verdad? Al construir un motor de consultas que sea súper rápido que pueda responder a consultas analíticas, hay empresas enteras que lo hacen.

Ali: Sí, resulta que necesitas dos API. Uno es la API del data frames. Eso permitirá toda la ciencia de datos y el aprendizaje automático. Luego, puede construir una capa SQL encima de ella, y no hay nada que realmente se interponga en el camino para hacer que esto sea tan eficiente como los motores MPP más rápidos y de última generación que existen. Puede aplicar los mismos trucos ahora porque en realidad está tratando con datos estructurados.

El caso de uso real de streaming

Martin: Parece que, especialmente en los datos, siempre existe una especie de tendencia del día que entusiasma a todos, pero nunca están realmente seguros de si el mercado es real o no. La gente ha estado diciendo esto mucho para los casos de uso en tiempo real y de streaming.

Está muy claro que la gente quiere procesar datos en diferentes momentos y velocidades. Batch, sabemos, es un mercado muy grande, donde tienes un montón de datos, quieres hacer un montón de procesamiento, y luego se almacena en otro lugar y haces algunas consultas.

Cada vez más personas hablan de análisis de streaming, donde a medida que ingresa una streaming, usted realiza las consultas antes de que llegue al disco.

Me siento en lanzamientos básicamente como un trabajo de tiempo completo, y muchas de las cosas que motivan el caso de uso de streaming parecen un poco artificiales.

Ali: Existe la latencia y la velocidad y qué tan rápido puedes obtener estas cosas. Ese es un lado de la ecuación, y eso es en lo que todos se enfocan.

A menudo, cuando le preguntamos al líder empresarial, “Oye, ¿qué tipo de latencia estaría bien para ti?” Dirán: “Queremos que sea superrápido, como cada 5 minutos, cada 10 minutos”. Y puede lograrlo con sistemas batch.

Luego, cuando investigue, “¿no le gustaría que fuera aún más rápido?” Resulta que los sistemas de streaming, el eslabón más débil, dictará la latencia. Habrá algún proceso ascendente que no tiene nada que ver con el sistema que está implementando. Y si ese enlace ascendente, si ese único lugar donde está cargando los datos o algo así, si llega cada media hora, entonces no importa qué tan rápido sea el resto.

Creo que la latencia real, esta obsesión con “Lo necesitamos en menos de 5 milisegundos”. Para la mayoría de los casos de uso, no tiene eso.

Hay otro lado de la ecuación, en el que la gente no se enfoca porque es más difícil de entender o explicar, pero podría ser el mayor beneficio de estos sistemas de streaming, es decir, se encarga de todas las operaciones de datos por usted.

Si no tiene un sistema de streaming en tiempo real, debe lidiar con cosas como, está bien, entonces los datos llegan todos los días. Voy a aceptarlo aquí. Lo voy a agregar allí. Bueno, ¿cómo me reconcilio? ¿Qué pasa si algunos de esos datos se retrasan? Necesito unir dos mesas, pero esa mesa no está aquí. Entonces, tal vez esperaré un poco y volveré a ejecutarlo. Y luego, tal vez una vez a la semana, vuelvo a ejecutar todo desde cero solo para asegurarme de que todo sea consistente.

En cierto sentido, todo el ETL que la gente está haciendo hoy y todo el procesamiento de datos que están haciendo hoy podría simplificarse si realmente lo convierte en un caso de streaming, porque los motores de streaming se encargan de la operacionalización por usted. Ya no tiene que preocuparse: “¿Llegaron tarde estos datos? ¿Todavía lo estamos esperando? ¿Es la cosa consistente? Ellos se encargarán de todo eso.

Martin: ¿Crees que, en última instancia, una gran parte de esto se convierte en procesamiento de streaming?

Ali: Lo que estoy diciendo, de manera provocativa, es que, en cierto sentido, todos los datos batch que existen son un caso de uso potencial para streaming.

Creo que los sistemas de procesamiento de streaming han sido demasiado complicados de usar, pero en realidad se encargan de muchas operaciones de datos que la gente está haciendo manualmente en la actualidad.

Arquitectura end-to-end

Martin: Me encantaría hablar sobre cómo crees que es un data stack moderno. Hablamos con un mucha gente, y parece que se está formando una pila de mejores prácticas, pero muy, muy poca gente sabe cómo se ve.

Digamos que te contratan, Ali. Tiene un nuevo trabajo, vicepresidente de datos, y tenía que construir una infraestructura de datos que realiza tanto análisis como AI-ML, ¿qué categoría de productos, no productos específicos, sino categorías de productos, usaría end-to-end?

Ali: Si me contratan para una gran empresa, pasaré los próximos cinco años luchando en batallas políticas sobre quién es dueño de qué parte de la pila y de qué tecnología debería deshacerme. Hay muchos organigramas y problemas humanos y de procesos, pero digamos que entro allí y dicen que él puede salirse con la suya.

Martin: Tiene todo el jugo, eso es correcto.

Ali: Obviamente, intentar hacer algo local no tiene ningún sentido en este momento. Y cuando esté creando esa arquitectura nativa de la nube, no intente replicar lo que tenía en el pasado en las instalaciones. No lo consideres como grandes grupos que los usuarios compartirán.

Un gran cambio que ocurre en la nube en el que los proveedores locales no piensan a menudo es que las redes en la nube son invisibles. Dos máquinas pueden comunicarse a toda velocidad y también pueden comunicarse con el sistema de almacenamiento, con el Data Lake, a toda velocidad. Este no era el caso en las instalaciones, y cosas como Hadoop y demás, tenían que optimizar dónde colocaba los datos y el cálculo tenía que estar cerca de los datos.

Entonces, lo mueves a la nube. Normalmente, tiene datos que fluyen desde algunos de sus sistemas. Dependiendo del tipo de negocio en el que se encuentre, tiene dispositivos de TI o tiene algo de sus aplicaciones web. A veces va a sistemas de cola de streaming, como Kafka. Y desde allí, aterriza en el Data Lake.

Martin: En el Data Lake. Entonces, dice que los datos van directamente a su Data Lake.

Ali: Ese es el primer lugar de aterrizaje. Si no lo hace, en realidad retrocederá una década o dos en la evolución. Porque si no lo coloca en el Data Lake, debe decidir inmediatamente qué esquema va a tener. Y eso es difícil de obtener derechos desde el principio. La buena noticia con los datalakes es que no tiene que decidir el esquema. Solo tírelo allí.

Paso número dos, necesita construir una capa transaccional estructural encima, para que realmente pueda darle sentido. Hay tres o cuatro de esas tecnologías que aparecieron aproximadamente al mismo tiempo, y todas te permiten tomar tu Data Lake y convertirlo en un lake.

Paso número tres. Necesita algún tipo de entorno de ciencia de datos interactivo en el que pueda comenzar a trabajar de forma interactiva con sus datos y obtener información de ellos.

Normalmente, las personas tienen soluciones basadas en Notebooks, donde pueden iterar con Notebooks. Usan cosas como Spark bajo el capó, y están procesando sus datos de forma interactiva y obteniendo información de ellos.

Y eso es realmente importante porque gran parte de la ciencia de datos en las organizaciones termina por no ser aprendizaje automático avanzado. Al final, está bien, entonces tenemos estos datos provenientes de nuestros productos o de nuestros dispositivos o lo que sea. Tenemos que masajearlo, obtenerlo en buena forma y necesitamos obtener algunas ideas básicas de él.

Si desea ingresar al juego predictivo, necesita una plataforma de aprendizaje automático. Ahora están surgiendo estas plataformas de aprendizaje automático, muchas de ellas propietarias, dentro de las empresas. Puedes leer sobre ellos, pero no puedes conseguir uno.

Martin: ¿ Y esto es para ML operativo?

Ali: En realidad, esto va desde entrenar el modelo de ML, así que en realidad lo incluye, crear un modelo que pueda hacer las predicciones, rastrear los resultados, asegurarse de que pueda hacerlos reproducibles y razonar sobre ellos hasta llevarlo a producción, que es el la parte mas dificil. Pasarlo a producción donde realmente puede servirlo dentro de los productos. Ese es el trabajo del aprendizaje automático.

Martin: ¿ Y las personas que utilizan la plataforma de aprendizaje automático en su mundo son los científicos de datos, los ingenieros de datos o ambos?

Ali: Son organizaciones diferentes, hoy, desafortunadamente. La parte de servicio, la parte de producción, a veces es propiedad de TI, y los científicos de datos que se encuentran en la línea de negocio crean los modelos.

Y hay fricción en esas organizaciones, porque TI opera en una longitud de onda diferente a la de los científicos de datos, pero la plataforma de aprendizaje automático debe abarcar ambos. Si no es así, no obtendrá todo el valor del trabajo de aprendizaje automático que está realizando.

Martin: ¿Puede hablarnos un poco sobre dónde encajan el pipeline de datos y las herramientas DAG en todo esto?

Ali: Ese sería el primer paso de esto. Hablé de entrenar de inmediato. Pero la parte más difícil es tomar esos datos que ahora están en el Data Lake y construir los pipelines que los caracterizan y ponerlos en la forma y forma correctas para que pueda comenzar a hacer aprendizaje automático en ellos. Entonces, ese es el paso número uno. Luego, después de eso, comienzas a entrenar los modelos.

Para organizar eso automáticamente y hacer que ese flujo de trabajo simplemente suceda, necesita un software que lo haga, por lo que definitivamente esa es la primera milla en la plataforma ML.

Martin: Y si quiero tomar mi panel de BI tradicional y adjuntarlo a este, ¿dónde se adjunta?

Ali: Esa es la última milla. BI en sí mismo suele utilizar algo como JDBC / ODBC. Para hacerlo realmente rápido y ágil y trabajar sobre los datos, necesita alguna capacidad que lo haga posible.

En el pasado, su única opción era colocarlo en un data warehousing y luego adjuntarle su herramienta de BI. Afirmo que con el patrón del lakehouse que estamos viendo, y con algunos de esos avances tecnológicos que mencioné, podría conectar su herramienta de BI directamente ahora en ese Data Lake.

Martin: ¿ A dónde? ¿A la capa transaccional que se construye sobre ella?

Ali: Sí, si tienes algo como Delta Lake o si tienes algo como Iceberg o Hive ACID, puedes conectarlo directamente.

Martin: Si no tuviera ninguna tecnología heredada, parece que hacer un Data Lake tiene mucho sentido. ¿Existe una ruta de migración simple para esto?

Ali: Creo que es más difícil en Occidente. En Asia, es más fácil porque no hay mucho legado. Es más difícil en Occidente porque las empresas tienen 40 años de tecnología en la que compraron, instalaron y configuraron datos de aplicaciones. Necesitan hacer que eso funcione con lo que estamos hablando.

Mientras que si lo está construyendo desde cero, en realidad puede hacerlo bien más fácilmente.

Martin: ¿Realmente está viendo un mayor uso de datalakes para empresas que no están cargadas por el legado?

Ali: Las empresas que realmente están teniendo éxito con estas cosas … toman un Uber. Están haciendo predicciones y las predicciones son una ventaja competitiva. Presiona un botón y, en un segundo, le indica cuál es el precio del viaje. Básicamente simuló el viaje. Sabe lo que le dirá ese medidor después de una hora de viaje con las condiciones del tráfico y todo. Le ofrece exactamente el precio correcto: no se puede sobrevalorar ni subestimar. Hace coincidir la oferta y la demanda de conductores con los precios de aumento. Incluso puede poner a las personas en el mismo automóvil para reducir el costo.

Todos estos son casos de uso de aprendizaje automático, y esas pilas, todas son empresas que tienen 10 años. Ellos no existieron. No tienen muchos datawarehouse heredados ni sistemas heredados. Lo construyeron a medida para este caso de uso, y es una gran ventaja competitiva.

De aquí

Martin: ¿Es esta la pila duradera que dura la próxima década, o está convergiendo en algo que se ve un poco diferente de lo que se puede articular desde aquí?

Ali: No puedo predecir el futuro, pero te diré algunos ingredientes que tienen sentido a largo plazo.

Si soy una empresa y estoy sentado allí como CIO o alguien que está eligiendo la estrategia de datos, me aseguraría de que todo lo que esté construyendo sea multinube. Hay mucha innovación entre los diferentes proveedores de la nube. Tienen bolsillos profundos y hay una especie de carrera armamentista allí, así que asegúrese de tener algo que sea de múltiples nubes.

Lo segundo que haría es, en la medida de lo posible, tratar de basarlo en estándares abiertos y tecnología de código abierto si es posible. Eso le brinda la mayor flexibilidad de que, si el espacio cambia nuevamente, puede mover cosas. De lo contrario, se encontrará atrapado en una pila de tecnología de la misma manera en que estaba atrapado en tecnologías de los años 80, 90 y 2000.

Almacenar todos sus datos, volcarlos primero en formato sin procesar en un Data Lake, es algo que permanecerá porque se están recopilando muchos datos. No tienes tiempo para averiguar los esquemas perfectos exactos para él y qué vamos a hacer con él. Entonces, o lo tiramos en algún lado o lo tiramos, y nadie quiere ser ese empleado que tiró los datos, especialmente cuando es tan barato almacenarlos.

Y la tercera cosa que haría es asegurarme de que la pila que está construyendo, la forma en que la está diseñando, tenga aprendizaje automático y ciencia de datos como un ciudadano de primera clase. Las plataformas de aprendizaje automático no existían hace 15 años, por lo que probablemente eso cambiará bastante. Creo que la forma exacta de la plataforma de aprendizaje automático no creo que se vea exactamente como es hoy.

Pero muchos de los ingredientes son correctos.

Referencia:

Traducción: https://a16z.com/2020/10/22/data-alone-is-not-enough-the-evolution-of-data-architectures/