El linaje de los datos incluye el origen de los datos , lo que les sucede y hacia dónde se mueven a lo largo del tiempo. [1] El linaje de datos brinda visibilidad al mismo tiempo que simplifica enormemente la capacidad de rastrear errores hasta la causa raíz en un proceso de análisis de datos . [2]
También permite reproducir porciones o entradas específicas del flujo de datos para depurar o regenerar la salida perdida por pasos . Los sistemas de bases de datos utilizan dicha información, denominada procedencia de los datos , para abordar desafíos similares de validación y depuración. [3] La procedencia de los datos se refiere a los registros de las entradas, entidades, sistemas y procesos que influyen en los datos de interés, proporcionando un registro histórico de los datos y sus orígenes. La evidencia generada respalda actividades forenses como análisis de dependencia de datos, detección y recuperación de errores / compromiso, auditoría y análisis de cumplimiento. "El linaje es un tipo simple de por qué la procedencia ". [3]
El linaje de datos se puede representar visualmente para descubrir el flujo / movimiento de datos desde su origen a destino a través de varios cambios y saltos en su camino en el entorno empresarial, cómo se transforman los datos a lo largo del camino, cómo cambian la representación y los parámetros, y cómo los datos se dividen o convergen después de cada salto. Se puede mostrar una representación simple del linaje de datos con puntos y líneas, donde el punto representa un contenedor de datos para puntos de datos y las líneas que los conectan representan las transformaciones que experimenta el punto de datos, entre los contenedores de datos.
La representación depende en gran medida del alcance de la gestión de metadatos y del punto de referencia de interés. El linaje de datos proporciona fuentes de datos y saltos de flujo de datos intermedios desde el punto de referencia con linaje de datos hacia atrás , conduce a los puntos de datos del destino final y sus flujos de datos intermedios con linaje de datos hacia adelante . Estas vistas se pueden combinar con el linaje de extremo a extremo para un punto de referencia que proporciona un seguimiento de auditoría completo de ese punto de datos de interés desde las fuentes hasta sus destinos finales. A medida que aumentan los puntos de datos o los saltos, la complejidad de dicha representación se vuelve incomprensible. Por lo tanto, la mejor característica de la vista de linaje de datos sería poder simplificar la vista enmascarando temporalmente los puntos de datos periféricos no deseados. Las herramientas que tienen la función de enmascaramiento permiten la escalabilidad de la vista y mejoran el análisis con la mejor experiencia de usuario tanto para usuarios técnicos como comerciales. El linaje de datos también permite a las empresas rastrear fuentes de datos comerciales específicos con el fin de rastrear errores, implementar cambios en los procesos e implementar migraciones de sistemas para ahorrar cantidades significativas de tiempo y recursos, mejorando así enormemente la eficiencia de BI . [4]
El alcance del linaje de datos determina el volumen de metadatos necesarios para representar su linaje de datos. Por lo general, la gobernanza y la gestión de datos determinan el alcance del linaje de datos en función de sus regulaciones , la estrategia de gestión de datos empresariales, el impacto de los datos, los atributos de los informes y los elementos de datos críticos de la organización.
El linaje de datos proporciona la pista de auditoría de los puntos de datos en el nivel granular más alto, pero la presentación del linaje se puede realizar en varios niveles de zoom para simplificar la vasta información, similar a los mapas web analíticos. El linaje de datos se puede visualizar en varios niveles según la granularidad de la vista. En un nivel muy alto, el linaje de datos proporciona qué sistemas interactúan los datos antes de llegar a su destino. A medida que aumenta la granularidad, sube al nivel del punto de datos donde puede proporcionar los detalles del punto de datos y su comportamiento histórico, propiedades de atributos y tendencias y calidad de los datos que pasan a través de ese punto de datos específico en el linaje de datos.
La gobernanza de datos juega un papel clave en la gestión de metadatos para directrices, estrategias, políticas e implementación. La calidad de los datos y la gestión de datos maestros ayudan a enriquecer el linaje de datos con más valor comercial. Aunque la representación final del linaje de datos se proporciona en una interfaz, la forma en que se recopilan los metadatos y se exponen a la interfaz gráfica de usuario del linaje de datos podría ser completamente diferente. Por lo tanto, el linaje de datos se puede dividir en tres categorías según la forma en que se recolectan los metadatos: linaje de datos que involucra paquetes de software para datos estructurados, lenguajes de programación y big data .
La información del linaje de datos incluye metadatos técnicos que involucran transformaciones de datos. La información de linaje de datos enriquecida puede incluir resultados de pruebas de calidad de datos, valores de datos de referencia, modelos de datos , vocabulario comercial , administradores de datos , información de gestión de programas y sistemas de información empresarial vinculados a los puntos de datos y las transformaciones. La función de enmascaramiento en la visualización del linaje de datos permite que las herramientas incorporen todos los enriquecimientos importantes para el caso de uso específico. Para representar sistemas dispares en una vista común, puede ser necesaria la "normalización de metadatos" o la estandarización.
Razón fundamental
Los sistemas distribuidos como Google Map Reduce , [5] Microsoft Dryad, [6] Apache Hadoop [7] (un proyecto de código abierto) y Google Pregel [8] proporcionan tales plataformas para empresas y usuarios. Sin embargo, incluso con estos sistemas, el análisis de big data puede tardar varias horas, días o semanas en ejecutarse, simplemente debido a los volúmenes de datos involucrados. Por ejemplo, un algoritmo de predicción de calificaciones para el desafío del Premio Netflix tardó casi 20 horas en ejecutarse en 50 núcleos, y una tarea de procesamiento de imágenes a gran escala para estimar la información geográfica tardó 3 días en completarse utilizando 400 núcleos. [9] "Se espera que el Large Synoptic Survey Telescope genere terabytes de datos cada noche y eventualmente almacene más de 50 petabytes, mientras que en el sector bioinformático, las 12 casas de secuenciación del genoma más grandes del mundo ahora almacenan petabytes de datos cada una". [10] Es muy difícil para un científico de datos rastrear un resultado desconocido o imprevisto.
Depuración de big data
El análisis de big data es el proceso de examinar grandes conjuntos de datos para descubrir patrones ocultos, correlaciones desconocidas, tendencias del mercado, preferencias de los clientes y otra información comercial útil. Aplican algoritmos de aprendizaje automático, etc.a los datos que transforman los datos. Debido al enorme tamaño de los datos, podría haber características desconocidas en los datos, posiblemente incluso valores atípicos. Es bastante difícil para un científico de datos depurar un resultado inesperado.
La escala masiva y la naturaleza no estructurada de los datos, la complejidad de estas canalizaciones de análisis y los tiempos de ejecución prolongados plantean importantes desafíos de gestión y depuración. Incluso un solo error en estos análisis puede ser extremadamente difícil de identificar y eliminar. Si bien uno puede depurarlos volviendo a ejecutar el análisis completo a través de un depurador para una depuración paso a paso, esto puede resultar costoso debido a la cantidad de tiempo y recursos necesarios. La auditoría y la validación de datos son otros problemas importantes debido a la creciente facilidad de acceso a fuentes de datos relevantes para su uso en experimentos, el intercambio de datos entre comunidades científicas y el uso de datos de terceros en empresas comerciales. [11] [12] [13] [14] Estos problemas solo se agravarán y agudizarán a medida que estos sistemas y datos sigan creciendo. Como tal, las formas más rentables de analizar la computación escalable con uso intensivo de datos (DISC) son cruciales para su uso efectivo continuo.
Desafíos en la depuración de big data
Escala masiva
Según un estudio de EMC / IDC: [15]
- 2.8ZB de datos fueron creados y replicados en 2012,
- el universo digital se duplicará cada dos años entre ahora y 2020, y
- habrá aproximadamente 5,2 TB de datos para cada persona en 2020.
Trabajar con esta escala de datos se ha convertido en un gran desafío.
Datos no estructurados
Los datos no estructurados generalmente se refieren a información que no reside en una base de datos tradicional de filas y columnas. Los archivos de datos no estructurados suelen incluir texto y contenido multimedia. Los ejemplos incluyen mensajes de correo electrónico, documentos de procesamiento de texto, videos, fotos, archivos de audio, presentaciones, páginas web y muchos otros tipos de documentos comerciales. Tenga en cuenta que si bien este tipo de archivos pueden tener una estructura interna, todavía se consideran "no estructurados" porque los datos que contienen no encajan perfectamente en una base de datos. Los expertos estiman que entre el 80 y el 90 por ciento de los datos de cualquier organización no están estructurados. Y la cantidad de datos no estructurados en las empresas crece significativamente, muchas veces más rápido de lo que crecen las bases de datos estructuradas. " Los macrodatos pueden incluir tanto datos estructurados como no estructurados, pero IDC estima que el 90 por ciento de los grandes datos son datos no estructurados". [dieciséis]
El desafío fundamental de las fuentes de datos no estructuradas es que son difíciles de desempaquetar, comprender y preparar para los usuarios comerciales no técnicos y los analistas de datos para su uso analítico. Más allá de las cuestiones de estructura, está el gran volumen de este tipo de datos. Debido a esto, las técnicas de minería de datos actuales a menudo dejan fuera información valiosa y hacen que el análisis de datos no estructurados sea laborioso y costoso. [17]
Larga duración
En el competitivo entorno empresarial actual, las empresas deben encontrar y analizar rápidamente los datos relevantes que necesitan. El desafío es revisar los volúmenes de datos y acceder al nivel de detalle necesario, todo a alta velocidad. El desafío solo crece a medida que aumenta el grado de granularidad. Una posible solución es el hardware. Algunos proveedores están usando mayor memoria y procesamiento paralelo para procesar grandes volúmenes de datos rápidamente. Otro método es poner datos en la memoria pero usando un enfoque de computación en cuadrícula , donde se usan muchas máquinas para resolver un problema. Ambos enfoques permiten a las organizaciones explorar grandes volúmenes de datos. Incluso con este nivel de hardware y software sofisticado, pocas de las tareas de procesamiento de imágenes a gran escala llevan de unos días a unas pocas semanas. [18] La depuración del procesamiento de datos es extremadamente difícil debido a los largos tiempos de ejecución.
Un tercer enfoque de soluciones avanzadas de descubrimiento de datos combina la preparación de datos de autoservicio con el descubrimiento visual de datos, lo que permite a los analistas preparar y visualizar datos simultáneamente en un entorno de análisis interactivo ofrecido por las nuevas empresas Trifacta , Alteryx y otras. [19]
Otro método para rastrear el linaje de los datos son los programas de hojas de cálculo como Excel que ofrecen a los usuarios un linaje a nivel de celda, o la capacidad de ver qué celdas dependen de otra, pero la estructura de la transformación se pierde. De manera similar, ETL o software de mapeo proporcionan linaje a nivel de transformación, sin embargo, esta vista generalmente no muestra datos y es demasiado detallada para distinguir entre transformaciones que son lógicamente independientes (por ejemplo, transformaciones que operan en columnas distintas) o dependientes. [20]
Plataforma compleja
Las plataformas de Big Data tienen una estructura muy complicada. Los datos se distribuyen entre varias máquinas. Normalmente, los trabajos se asignan a varias máquinas y los resultados se combinan posteriormente mediante operaciones de reducción. La depuración de una canalización de big data se vuelve muy desafiante debido a la naturaleza misma del sistema. No será una tarea fácil para el científico de datos averiguar qué datos de la máquina tienen valores atípicos y características desconocidas que hacen que un algoritmo particular dé resultados inesperados.
Solución propuesta
La procedencia o el linaje de los datos se pueden utilizar para facilitar la depuración de la canalización de big data . Esto requiere la recopilación de datos sobre transformaciones de datos. La siguiente sección explicará la procedencia de los datos con más detalle.
Procedencia de datos
La procedencia de los datos proporciona un registro histórico de los datos y sus orígenes. La procedencia de los datos generados por transformaciones complejas, como los flujos de trabajo, tiene un valor considerable para los científicos. [21] A partir de él, se puede determinar la calidad de los datos basados en sus datos ancestrales y derivaciones, rastrear las fuentes de errores, permitir la recreación automatizada de derivaciones para actualizar los datos y proporcionar atribución de fuentes de datos. La procedencia también es esencial para el dominio empresarial, donde se puede utilizar para profundizar en la fuente de datos en un almacén de datos , rastrear la creación de propiedad intelectual y proporcionar una pista de auditoría con fines regulatorios.
El uso de la procedencia de los datos se propone en los sistemas distribuidos para rastrear registros a través de un flujo de datos, reproducir el flujo de datos en un subconjunto de sus entradas originales y depurar los flujos de datos. Para hacerlo, es necesario realizar un seguimiento del conjunto de entradas para cada operador, que se utilizaron para derivar cada una de sus salidas. Aunque hay varias formas de procedencia, como copia-procedencia y cómo-procedencia, [14] [22] la información que necesitamos es una forma simple de por qué-procedencia, o linaje , según lo definido por Cui et al. [23]
Captura de linaje
Intuitivamente, para un operador T que produce la salida o, el linaje consiste en tripletes de la forma {I, T, o}, donde I es el conjunto de entradas de T que se utilizan para derivar o. La captura del linaje para cada operador T en un flujo de datos permite a los usuarios hacer preguntas como "¿Qué salidas fueron producidas por una entrada i en el operador T?" y "¿Qué insumos produjeron salida o en el operador T?" [3] Una consulta que encuentra las entradas que derivan de una salida se llama consulta de rastreo hacia atrás, mientras que una que encuentra las salidas producidas por una entrada se llama consulta de rastreo hacia adelante. [24] El rastreo hacia atrás es útil para depurar, mientras que el rastreo hacia adelante es útil para rastrear la propagación de errores. [24] Las consultas de seguimiento también forman la base para reproducir un flujo de datos original. [12] [23] [24] Sin embargo, para usar el linaje de manera eficiente en un sistema DISC, necesitamos poder capturar el linaje en múltiples niveles (o granularidades) de operadores y datos, capturar el linaje preciso para las construcciones de procesamiento DISC y poder para rastrear a través de múltiples etapas de flujo de datos de manera eficiente.
El sistema DISC consta de varios niveles de operadores y datos, y diferentes casos de uso de linaje pueden dictar el nivel en el que se debe capturar el linaje. El linaje se puede capturar al nivel del trabajo, usando archivos y dando tuplas de linaje de la forma {IF i, M RJob, OF i}, el linaje también se puede capturar al nivel de cada tarea, usando registros y dando, por ejemplo, tuplas de linaje de forma {(k rr, v rr), map, (km, vm)}. La primera forma de linaje se llama linaje de grano grueso, mientras que la segunda forma se llama linaje de grano fino. La integración del linaje en diferentes granularidades permite a los usuarios hacer preguntas como "¿Qué archivo leído por un trabajo de MapReduce produjo este registro de salida en particular?" y puede ser útil para depurar diferentes granularidades de datos y operadores dentro de un flujo de datos. [3]
Para capturar el linaje de un extremo a otro en un sistema DISC, usamos el modelo Ibis, [25] que introduce la noción de jerarquías de contención para operadores y datos. Específicamente, Ibis propone que un operador puede estar contenido dentro de otro y tal relación entre dos operadores se llama contención de operador . "La contención del operador implica que el operador contenido (o hijo) realiza una parte de la operación lógica del operador que contiene (o padre)". [3] Por ejemplo, una tarea de MapReduce está contenida en un trabajo. También existen relaciones de contención similares para los datos, llamadas contención de datos. La contención de datos implica que los datos contenidos son un subconjunto de los datos que los contienen (superconjunto).
Linaje de datos prescriptivos
El concepto de linaje de datos prescriptivos combina el modelo lógico (entidad) de cómo deben fluir esos datos con el linaje real para esa instancia. [26]
El linaje y la procedencia de los datos generalmente se refieren a la forma o los pasos en que un conjunto de datos llegó a su estado actual Linaje de datos, así como todas las copias o derivados. Sin embargo, simplemente mirar hacia atrás solo en las correlaciones de auditoría o registro para determinar el linaje desde un punto de vista forense es defectuoso para ciertos casos de administración de datos. Por ejemplo, es imposible determinar con certeza si la ruta que tomó un flujo de trabajo de datos fue correcta o cumplió sin el modelo lógico.
Solo combinando un modelo lógico con eventos forenses atómicos se pueden validar las actividades adecuadas:
- Copias autorizadas, uniones u operaciones CTAS
- Mapeo del procesamiento a los sistemas en los que se ejecutan esos procesos
- Secuencias de procesamiento ad-hoc versus establecidas
Muchos informes de cumplimiento certificados requieren la procedencia del flujo de datos, así como los datos del estado final para una instancia específica. Con este tipo de situaciones, cualquier desviación de la ruta prescrita debe tenerse en cuenta y potencialmente remediarse. [27] Esto marca un cambio en el pensamiento de un modelo puramente retrospectivo a un marco más adecuado para capturar los flujos de trabajo de cumplimiento.
Linaje activo versus perezoso
La colección de linaje perezoso generalmente captura solo el linaje de grano grueso en tiempo de ejecución. Estos sistemas incurren en bajos costos de captura debido a la pequeña cantidad de linaje que capturan. Sin embargo, para responder consultas de seguimiento de grano fino, deben reproducir el flujo de datos en toda (o una gran parte) de su entrada y recopilar el linaje de grano fino durante la reproducción. Este enfoque es adecuado para sistemas forenses, donde un usuario desea depurar un resultado incorrecto observado.
Los sistemas de recopilación activos capturan todo el linaje del flujo de datos en tiempo de ejecución. El tipo de linaje que capturan puede ser de grano grueso o fino, pero no requieren más cálculos sobre el flujo de datos después de su ejecución. Los sistemas activos de recolección de linaje de grano fino incurren en gastos generales de captura más altos que los sistemas de recolección perezosos. Sin embargo, permiten una repetición y una depuración sofisticadas. [3]
Actores
Un actor es una entidad que transforma datos; puede ser un vértice de Dryad, un mapa individual y operadores de reducción, un trabajo de MapReduce o un flujo de datos completo. Los actores actúan como cajas negras y las entradas y salidas de un actor se aprovechan para capturar el linaje en forma de asociaciones, donde una asociación es un triplete {i, T, o} que relaciona una entrada i con una salida o para un actor T. Por lo tanto, la instrumentación captura el linaje en un flujo de datos de un actor a la vez, uniéndolo en un conjunto de asociaciones para cada actor. El desarrollador del sistema necesita capturar los datos que un actor lee (de otros actores) y los datos que un actor escribe (a otros actores). Por ejemplo, un desarrollador puede tratar a Hadoop Job Tracker como un actor al registrar el conjunto de archivos leídos y escritos por cada trabajo. [28]
Asociaciones
La asociación es una combinación de las entradas, las salidas y la operación en sí. La operación se representa en términos de una caja negra también conocida como actor. Las asociaciones describen las transformaciones que se aplican a los datos. Las asociaciones se almacenan en las tablas de asociación. Cada actor único está representado por su propia tabla de asociación. Una asociación en sí misma se ve como {i, T, o} donde i es el conjunto de entradas al actor T yo es el conjunto de salidas dadas por el actor. Las asociaciones son las unidades básicas de Data Lineage. Posteriormente, las asociaciones individuales se agrupan para construir el historial completo de transformaciones que se aplicaron a los datos. [3]
Arquitectura
Los sistemas de big data se escalan horizontalmente, es decir, aumentan la capacidad agregando nuevas entidades de hardware o software al sistema distribuido. El sistema distribuido actúa como una sola entidad en el nivel lógico aunque comprende múltiples entidades de hardware y software. El sistema debe continuar manteniendo esta propiedad después del escalado horizontal. Una ventaja importante de la escalabilidad horizontal es que puede proporcionar la capacidad de aumentar la capacidad sobre la marcha. El mayor punto a favor es que el escalado horizontal se puede realizar utilizando hardware básico.
La característica de escalamiento horizontal de los sistemas de Big Data debe tenerse en cuenta al crear la arquitectura de la tienda de linaje. Esto es esencial porque el almacén de linaje en sí también debería poder escalar en paralelo con el sistema de Big Data . El número de asociaciones y la cantidad de almacenamiento necesario para almacenar el linaje aumentará con el aumento de tamaño y capacidad del sistema. La arquitectura de los sistemas de Big Data hace que el uso de un único almacén de linaje no sea apropiado e imposible de escalar. La solución inmediata a este problema es distribuir la propia tienda de linaje. [3]
El mejor escenario es utilizar un almacén de linaje local para cada máquina en la red del sistema distribuido. Esto permite que el almacén de linaje también se escale horizontalmente. En este diseño, el linaje de las transformaciones de datos aplicadas a los datos de una máquina en particular se almacena en el almacén de linaje local de esa máquina específica. La tienda de linaje normalmente almacena tablas de asociación. Cada actor está representado por su propia tabla de asociación. Las filas son las asociaciones en sí mismas y las columnas representan entradas y salidas. Este diseño resuelve 2 problemas. Permite el escalado horizontal del almacén de linajes. Si se usaba un único almacén de linaje centralizado, entonces esta información tenía que transportarse a través de la red, lo que causaría una latencia de red adicional. La latencia de la red también se evita mediante el uso de un almacén de linaje distribuido. [28]
Reconstrucción del flujo de datos
La información almacenada en términos de asociaciones debe combinarse de alguna manera para obtener el flujo de datos de un trabajo en particular. En un sistema distribuido, un trabajo se divide en varias tareas. Una o más instancias ejecutan una tarea en particular. Los resultados producidos en estas máquinas individuales se combinan más tarde para terminar el trabajo. Las tareas que se ejecutan en diferentes máquinas realizan múltiples transformaciones en los datos de la máquina. Todas las transformaciones aplicadas a los datos de una máquina se almacenan en el almacén de linaje local de esas máquinas. Esta información debe combinarse para obtener el linaje de todo el trabajo. El linaje de todo el trabajo debería ayudar al científico de datos a comprender el flujo de datos del trabajo y él / ella puede usar el flujo de datos para depurar la canalización de big data . El flujo de datos se reconstruye en 3 etapas.
Tablas de asociación
La primera etapa de la reconstrucción del flujo de datos es el cálculo de las tablas de asociación. Las tablas de asociación existen para cada actor en cada tienda de linaje local. La tabla de asociación completa para un actor se puede calcular combinando estas tablas de asociación individuales. Esto generalmente se hace usando una serie de combinaciones de igualdad basadas en los propios actores. En algunos escenarios, las tablas también se pueden unir utilizando entradas como clave. Los índices también se pueden utilizar para mejorar la eficiencia de una combinación. Las tablas unidas deben almacenarse en una sola instancia o en una máquina para continuar con el procesamiento. Hay varios esquemas que se utilizan para elegir una máquina en la que se calcularía una combinación. El más fácil es el que tiene una carga mínima de CPU. Las limitaciones de espacio también deben tenerse en cuenta al elegir la instancia en la que se realizaría la unión.
Gráfico de asociación
El segundo paso en la reconstrucción del flujo de datos es calcular un gráfico de asociación a partir de la información de linaje. El gráfico representa los pasos del flujo de datos. Los actores actúan como vértices y las asociaciones actúan como aristas. Cada actor T está vinculado a sus actores ascendentes y descendentes en el flujo de datos. Un actor aguas arriba de T es uno que produce la entrada de T, mientras que un actor aguas abajo es uno que consume la salida de T. Las relaciones de contención siempre se consideran al crear los enlaces. El gráfico consta de tres tipos de enlaces o bordes.
Enlaces especificados explícitamente
El vínculo más simple es un vínculo especificado explícitamente entre dos actores. Estos enlaces se especifican explícitamente en el código de un algoritmo de aprendizaje automático. Cuando un actor conoce su actor ascendente o descendente exacto, puede comunicar esta información a la API de linaje. Esta información se utiliza posteriormente para vincular a estos actores durante la consulta de seguimiento. Por ejemplo, en la arquitectura MapReduce , cada instancia de mapa conoce la instancia exacta del lector de registros cuya salida consume. [3]
Enlaces inferidos lógicamente
Los desarrolladores pueden adjuntar arquetipos de flujo de datos a cada actor lógico. Un arquetipo de flujo de datos explica cómo los tipos secundarios de un tipo de actor se organizan en un flujo de datos. Con la ayuda de esta información, se puede inferir un vínculo entre cada actor de un tipo de fuente y un tipo de destino. Por ejemplo, en la arquitectura MapReduce , el tipo de actor de mapa es la fuente para reducir y viceversa. El sistema infiere esto de los arquetipos de flujo de datos y vincula debidamente las instancias del mapa con las instancias reducidas. Sin embargo, puede haber varios trabajos de MapReduce en el flujo de datos y vincular todas las instancias de mapa con todas las instancias de reducción puede crear enlaces falsos. Para evitar esto, dichos enlaces están restringidos a instancias de actor contenidas dentro de una instancia de actor común de un tipo de actor contenedor (o padre). Por lo tanto, las instancias de mapa y reducción solo están vinculadas entre sí si pertenecen al mismo trabajo. [3]
Vínculos implícitos mediante el intercambio de conjuntos de datos
En los sistemas distribuidos, a veces hay enlaces implícitos, que no se especifican durante la ejecución. Por ejemplo, existe un vínculo implícito entre un actor que escribió en un archivo y otro actor que lo leyó. Dichos enlaces conectan a los actores que utilizan un conjunto de datos común para la ejecución. El conjunto de datos es la salida del primer actor y es la entrada del actor que lo sigue. [3]
Clasificación topológica
El paso final en la reconstrucción del flujo de datos es la clasificación topológica del gráfico de asociación. El gráfico dirigido creado en el paso anterior se ordena topológicamente para obtener el orden en el que los actores han modificado los datos. Este orden heredado de los actores define el flujo de datos de la tubería o tarea de big data.
Seguimiento y reproducción
Este es el paso más crucial en la depuración de Big Data . El linaje capturado se combina y procesa para obtener el flujo de datos de la tubería. El flujo de datos ayuda al científico de datos o al desarrollador a observar en profundidad a los actores y sus transformaciones. Este paso permite al científico de datos descubrir la parte del algoritmo que genera la salida inesperada. Una canalización de big data puede salir mal de dos formas generales. El primero es la presencia de un actor sospechoso en el flujo de datos. El segundo es la existencia de valores atípicos en los datos.
El primer caso se puede depurar rastreando el flujo de datos. Al usar la información de linaje y flujo de datos juntos, un científico de datos puede descubrir cómo las entradas se convierten en salidas. Durante el proceso, los actores que se comportan de manera inesperada pueden ser atrapados. O estos actores pueden eliminarse del flujo de datos o pueden ser aumentados por nuevos actores para cambiar el flujo de datos. El flujo de datos mejorado se puede reproducir para probar su validez. La depuración de actores defectuosos incluye la realización recursiva de una reproducción de grano grueso en actores en el flujo de datos, [29] que puede ser costoso en recursos para flujos de datos largos. Otro enfoque es inspeccionar manualmente los registros de linaje para encontrar anomalías, [13] [30] que pueden ser tediosas y consumir mucho tiempo en varias etapas de un flujo de datos. Además, estos enfoques funcionan solo cuando el científico de datos puede descubrir resultados incorrectos. Para depurar análisis sin resultados erróneos conocidos, el científico de datos debe analizar el flujo de datos en busca de comportamientos sospechosos en general. Sin embargo, a menudo, un usuario puede no conocer el comportamiento normal esperado y no puede especificar predicados. Esta sección describe una metodología de depuración para analizar retrospectivamente el linaje para identificar actores defectuosos en un flujo de datos de múltiples etapas. Creemos que los cambios repentinos en el comportamiento de un actor, como su selectividad promedio, tasa de procesamiento o tamaño de salida, son característicos de una anomalía. El linaje puede reflejar tales cambios en el comportamiento de los actores a lo largo del tiempo y en diferentes instancias de actores. Por lo tanto, el linaje de minería para identificar tales cambios puede ser útil para depurar actores defectuosos en un flujo de datos.
El segundo problema, es decir, la existencia de valores atípicos, también se puede identificar ejecutando el flujo de datos paso a paso y observando los resultados transformados. El científico de datos encuentra un subconjunto de resultados que no están de acuerdo con el resto de resultados. Las entradas que están causando estos malos resultados son los valores atípicos en los datos. Este problema se puede resolver eliminando el conjunto de valores atípicos de los datos y reproduciendo todo el flujo de datos. También se puede resolver modificando el algoritmo de aprendizaje automático agregando, eliminando o moviendo actores en el flujo de datos. Los cambios en el flujo de datos tienen éxito si el flujo de datos reproducido no produce resultados incorrectos.
Desafíos
Aunque el uso de enfoques de linaje de datos es una forma novedosa de depurar las canalizaciones de big data , el proceso no es simple. Los desafíos incluyen la escalabilidad del almacén de linaje, la tolerancia a fallas del almacén de linaje, la captura precisa del linaje para los operadores de caja negra y muchos otros. Estos desafíos deben considerarse cuidadosamente y las compensaciones entre ellos deben evaluarse para hacer un diseño realista para la captura del linaje de datos.
Escalabilidad
Los sistemas DISC son principalmente sistemas de procesamiento por lotes diseñados para un alto rendimiento. Ejecutan varios trabajos por análisis, con varias tareas por trabajo. El número total de operadores que se ejecutan en cualquier momento en un clúster puede variar entre cientos y miles, según el tamaño del clúster. La captura de linaje para estos sistemas debe poder escalar tanto a grandes volúmenes de datos como a numerosos operadores para evitar ser un cuello de botella para el análisis DISC.
Tolerancia a fallos
Los sistemas de captura de linaje también deben ser tolerantes a fallas para evitar volver a ejecutar los flujos de datos para capturar el linaje. Al mismo tiempo, también deben adaptarse a las fallas en el sistema DISC. Para hacerlo, deben poder identificar una tarea DISC fallida y evitar almacenar copias duplicadas del linaje entre el linaje parcial generado por la tarea fallida y el linaje duplicado producido por la tarea reiniciada. Un sistema de linaje también debería poder manejar con gracia múltiples instancias de sistemas de linaje local que se caen. Esto se puede lograr almacenando réplicas de asociaciones de linaje en varias máquinas. La réplica puede actuar como una copia de seguridad en caso de que se pierda la copia real.
Operadores de caja negra
Los sistemas de linaje para los flujos de datos DISC deben poder capturar el linaje preciso entre los operadores de caja negra para permitir una depuración detallada. Los enfoques actuales para esto incluyen Prober, que busca encontrar el conjunto mínimo de entradas que puede producir una salida específica para un operador de caja negra al reproducir el flujo de datos varias veces para deducir el conjunto mínimo, [31] y el corte dinámico, como utilizado por Zhang et al. [32] para capturar el linaje de los operadores NoSQL a través de la reescritura binaria para calcular porciones dinámicas. Aunque producen un linaje de alta precisión, estas técnicas pueden generar una sobrecarga de tiempo significativa para la captura o el rastreo, y puede ser preferible cambiar algo de precisión por un mejor rendimiento. Por lo tanto, existe la necesidad de un sistema de recopilación de linajes para flujos de datos DISC que pueda capturar el linaje de operadores arbitrarios con una precisión razonable y sin gastos generales significativos en la captura o el rastreo.
Rastreo eficiente
El rastreo es esencial para la depuración, durante la cual, un usuario puede emitir múltiples consultas de rastreo. Por lo tanto, es importante que el rastreo tenga tiempos de respuesta rápidos. Ikeda y col. [24] puede realizar consultas de rastreo hacia atrás eficientes para flujos de datos de MapReduce, pero no son genéricas para diferentes sistemas DISC y no realizan consultas hacia adelante eficientes. El lápiz labial, [33] un sistema de linaje para Pig, [34] aunque puede realizar un rastreo tanto hacia atrás como hacia adelante, es específico para los operadores de Pig y SQL y solo puede realizar un rastreo de grano grueso para los operadores de caja negra. Por lo tanto, existe la necesidad de un sistema de linaje que permita un rastreo hacia adelante y hacia atrás eficiente para sistemas DISC genéricos y flujos de datos con operadores de caja negra.
Reproducción sofisticada
Reproducir solo entradas específicas o partes de un flujo de datos es crucial para una depuración eficiente y la simulación de escenarios hipotéticos. Ikeda y col. presentar una metodología para la actualización basada en el linaje, que reproduce de forma selectiva las entradas actualizadas para volver a calcular las salidas afectadas. [35] Esto es útil durante la depuración para volver a calcular las salidas cuando se ha corregido una entrada incorrecta. Sin embargo, a veces un usuario puede querer eliminar la entrada incorrecta y reproducir el linaje de salidas previamente afectadas por el error para producir salidas libres de errores. A esto lo llamamos repetición exclusiva. Otro uso de la reproducción en la depuración implica la reproducción de entradas incorrectas para la depuración paso a paso (llamada reproducción selectiva). Los enfoques actuales para usar el linaje en los sistemas DISC no abordan estos. Por lo tanto, existe la necesidad de un sistema de linaje que pueda realizar repeticiones tanto exclusivas como selectivas para abordar diferentes necesidades de depuración.
Detección de anomalías
Una de las principales preocupaciones de depuración en los sistemas DISC es la identificación de operadores defectuosos. En largos flujos de datos con varios cientos de operadores o tareas, la inspección manual puede resultar tediosa y prohibitiva. Incluso si el linaje se utiliza para reducir el subconjunto de operadores a examinar, el linaje de una única salida puede abarcar varios operadores. Existe la necesidad de un sistema de depuración automatizado de bajo costo, que pueda reducir sustancialmente el conjunto de operadores potencialmente defectuosos, con una precisión razonable, para minimizar la cantidad de examen manual requerido.
Ver también
- Gráfico Acíclico Dirigido
Referencias
- ^ "¿Qué es el linaje de datos? - Definición de Techopedia" .
- ^ Hoang, Natalie (16 de marzo de 2017). "El linaje de datos ayuda a impulsar el valor comercial | Trifacta" . Trifacta . Consultado el 20 de septiembre de 2017 .
- ^ a b c d e f g h i j k De, Soumyarupa. (2012). Newt: una arquitectura para la reproducción y depuración basada en el linaje en sistemas DISC. UC San Diego: b7355202. Obtenido de: https://escholarship.org/uc/item/3170p7zn
- ^ Drori, Amanon (18 de mayo de 2020). "¿Qué es el linaje de datos? | Octopai" . Octopai . Consultado el 25 de agosto de 2020 .
- ^ Jeffrey Dean y Sanjay Ghemawat. Mapreduce: procesamiento de datos simplificado en grandes clústeres. Comun. ACM, 51 (1): 107-113, enero de 2008.
- ^ Michael Isard, Mihai Budiu, Yuan Yu, Andrew Birrell y Dennis Fetterly. Dryad: programas paralelos de datos distribuidos a partir de bloques de construcción secuenciales. En Actas de la 2ª Conferencia europea sobre sistemas informáticos SIGOPS / EuroSys de ACM 2007, EuroSys '07, páginas 59–72, Nueva York, NY, EE.UU., 2007. ACM.
- ^ Apache Hadoop. http://hadoop.apache.org .
- ^ Grzegorz Malewicz, Matthew H. Austern, Aart JC Bik, James C. Dehnert, Ilan Horn, Naty Leiser y Grzegorz Czajkowski. Pregel: un sistema para el procesamiento de gráficos a gran escala. En Actas de la conferencia internacional de 2010 sobre gestión de datos, SIGMOD '10, páginas 135–146, Nueva York, NY, EE. UU., 2010. ACM.
- ^ Shimin Chen y Steven W. Schlosser. Map-reduce se adapta a una variedad más amplia de aplicaciones. Informe técnico, Intel Research, 2008.
- ^ El diluvio de datos en genómica. https://www-304.ibm.com/connections/blogs/ibmhealthcare/entry/data overload in genomics3? lang = de, 2010.
- ^ Yogesh L. Simmhan, Beth Plale y Dennis Gannon. Una encuesta sobre la procedencia de datos en e-ciencia. SIGMOD Rec., 34 (3): 31–36, septiembre de 2005.
- ^ a b Ian Foster, Jens Vockler, Michael Wilde y Yong Zhao. Quimera: un sistema de datos virtual para representar, consultar y automatizar la derivación de datos. En la 14a Conferencia Internacional sobre Gestión de Bases de Datos Científicas y Estadísticas, julio de 2002.
- ^ a b Benjamin H. Sigelman, Luiz Andr Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan y Chandan Shanbhag. Dapper, una infraestructura de rastreo de sistemas distribuidos a gran escala. Informe técnico, Google Inc, 2010.
- ↑ a b Peter Buneman , Sanjeev Khanna y Wang-Chiew Tan . Procedencia de los datos: algunas cuestiones básicas. En Actas de la 20ª Conferencia sobre los fundamentos de la tecnología del software y la informática teórica, FST TCS 2000, páginas 87–93, Londres, Reino Unido, Reino Unido, 2000. Springer-Verlag
- ^ "El nuevo estudio del universo digital revela una brecha de Big Data que se analiza menos de 1 de los datos mundiales. Se protege menos de 20" .
- ^ Webopedia http://www.webopedia.com/TERM/U/unstructured_data.html
- ^ Schaefer, Paige (24 de agosto de 2016). "Diferencias entre datos estructurados y no estructurados" . Trifacta . Consultado el 20 de septiembre de 2017 .
- ^ SAS. http://www.sas.com/resources/asset/five-big-data-challenges-article.pdf Archivado el 20 de diciembre de 2014 en Wayback Machine.
- ^ "5 requisitos para una preparación de datos de autoservicio eficaz" . www.itbusinessedge.com . 18 de febrero de 2016 . Consultado el 20 de septiembre de 2017 .
- ^ Kandel, Sean (4 de noviembre de 2016). "Seguimiento del linaje de datos en servicios financieros | Trifacta" . Trifacta . Consultado el 20 de septiembre de 2017 .
- ^ Pasquier, Thomas; Lau, Matthew K .; Trisovic, Ana; Boose, Emery R .; El modisto, Ben; Crosas, Mercè; Ellison, Aaron M .; Gibson, Valerie; Jones, Chris R .; Seltzer, Margo (5 de septiembre de 2017). "Si estos datos pudieran hablar" . Datos científicos . 4 : 170114. doi : 10.1038 / sdata.2017.114 . PMC 5584398 . PMID 28872630 .
- ^ Robert Ikeda y Jennifer Widom. Linaje de datos: una encuesta. Informe técnico, Universidad de Stanford, 2009.
- ^ a b Y. Cui y J. Widom. Seguimiento de linaje para transformaciones generales de almacenamiento de datos. Revista VLDB, 12 (1), 2003.
- ^ a b c d Robert Ikeda, Hyunjung Park y Jennifer Widom. Procedencia para mapa generalizado y reducción de flujos de trabajo. En Proc. del CIDR, enero de 2011.
- ^ C. Olston y A. Das Sarma. Ibis: un gestor de procedencia para sistemas multicapa. En Proc. del CIDR, enero de 2011.
- ^ http://info.hortonworks.com/rs/549-QAL-086/images/Hadoop-Governance-White-Paper.pdf
- ^ Guía de cumplimiento de la SEC para pequeñas entidades
- ^ a b Dionysios Logothetis, Soumyarupa De y Kenneth Yocum. 2013. Captura de linaje escalable para depurar análisis DISC. En Actas del 4º Simposio anual sobre Computación en la Nube (SOCC '13). ACM, Nueva York, NY, EE. UU., Artículo 17, 15 páginas.
- ^ Zhou, Wenchao; Fei, Qiong; Narayan, Arjun; Haeberlen, Andreas; Thau Loo, Boon ; Sherr, Micah (diciembre de 2011). Procedencia de red segura . Actas del 23º Simposio de ACM sobre principios de sistemas operativos (SOSP).
- ^ Fonseca, Rodrigo; Porter, George; Katz, Randy H .; Shenker, Scott; Stoica, Ion (2007). X-trace: un marco de seguimiento de red generalizado . Actas de NSDI'07.
- ^ Anish Das Sarma, Alpa Jain y Philip Bohannon. PROBER: Depuración Ad-Hoc de Pipelines de Extracción e Integración. Informe técnico, Yahoo, abril de 2010.
- ^ Mingwu Zhang, Xiangyu Zhang, Xiang Zhang y Sunil Prabhakar. Rastreando el linaje más allá de los operadores relacionales. En Proc. Conferencia sobre bases de datos muy grandes (VLDB), septiembre de 2007.
- ^ Yael Amsterdamer, Susan B. Davidson, Daniel Deutch, Tova Milo y Julia Stoyanovich. Poner lápiz labial en un cerdo: habilitar la procedencia del flujo de trabajo al estilo de una base de datos. En Proc. de VLDB, agosto de 2011.
- ^ Christopher Olston, Benjamin Reed, Utkarsh Srivastava, Ravi Kumar y Andrew Tomkins. Pig latin: una lengua no tan extranjera para el procesamiento de datos. En Proc. de ACM SIGMOD, Vancouver, Canadá, junio de 2008.
- ^ Robert Ikeda, Semih Salihoglu y Jennifer Widom. Actualización basada en procedencia en flujos de trabajo orientados a datos. En Actas de la 20ª conferencia internacional de ACM sobre gestión de la información y el conocimiento, CIKM '11, páginas 1659–1668, Nueva York, NY, EE. UU., 2011. ACM.