Capítulo 28. Adoptar la arquitectura del lago de datos
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Vinoth Chandar
A menudo, los ingenieros de datos construyen canalizaciones de datos para extraer datos de fuentes externas, transformarlos y permitir que otras partes de la organización consulten los conjuntos de datos resultantes. Aunque a corto plazo es más fácil construir todo esto como una canalización de una sola etapa, se necesita una arquitectura de datos más meditada para escalar este modelo a miles de conjuntos de datos que abarcan varios tera/petabytes.
Errores comunes
Entendamos algunos escollos comunes del enfoque de una sola etapa. En primer lugar, limita la escalabilidad, ya que los datos de entrada a una tubería de este tipo se obtienen explorando bases de datos previas -sistemas de gestión de bases de datos relacionales (RDBMS) o almacenes NoSQL-, lo que en última instancia estresaría estos sistemas e incluso provocaría interrupciones. Además, acceder directamente a esos datos permite poca estandarización entre las tuberías (por ejemplo, marca de tiempo estándar, campos clave) y aumenta el riesgo de rotura de datos debido a la falta de esquemas/contratos de datos. Por último, no todos los datos o columnas están disponibles en un único lugar, para poder cruzarlos libremente en busca de perspectivas ...
Get 97 cosas que todo ingeniero de datos debe saber now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.