El linaje de datos incluye el origen de los datos , lo que les sucede y hacia dónde se mueven con el tiempo. [1] El linaje de datos brinda visibilidad y simplifica el rastreo de errores hasta su causa raíz en un proceso de análisis de datos . [2]
También permite reproducir porciones específicas o entradas del flujo de datos para la depuración paso a paso o la regeneración de la salida perdida. 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 el análisis de dependencia de los datos, la detección y recuperación de errores/compromisos, la auditoría y el análisis de cumplimiento. " El linaje es un tipo simple de por qué procedencia ". [3]
El linaje de datos se puede representar visualmente para descubrir el flujo/movimiento de datos desde su origen hasta su destino a través de varios cambios y saltos en su camino en el entorno empresarial, cómo se transforman los datos en el 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. Una representación simple del linaje de datos se puede mostrar 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 los datos y saltos de flujo de datos intermedios desde el punto de referencia con linaje de datos hacia atrás , lo que lleva 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 registro 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 los 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 de la empresa, 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 el registro 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, de manera 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 los sistemas con los que interactúan los datos antes de llegar a destino. A medida que aumenta la granularidad, sube al nivel de 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 por ese punto de datos específico en el linaje de datos.
La gobernanza de datos desempeña un papel fundamental en la gestión de metadatos para las 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 puede ser completamente diferente. Por lo tanto, el linaje de datos se puede dividir en tres categorías en términos generales según la forma en que se recopilan los metadatos: linaje de datos que involucra paquetes de software para datos estructurados, lenguajes de programación y big data .
La información de 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 empresarial , 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 de linaje de datos permite que las herramientas incorporen todos los enriquecimientos que importan para el caso de uso específico. Para representar sistemas dispares en una vista común, puede ser necesaria la " normalización o estandarización de metadatos".
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 plataformas de este tipo 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 Netflix Prize tardó casi 20 horas en ejecutarse en 50 núcleos, y una tarea de procesamiento de imágenes a gran escala para estimar información geográfica tardó 3 días en completarse utilizando 400 núcleos. [9] "Se espera que el Gran Telescopio de Sondeo Sinóptico genere terabytes de datos cada noche y, con el tiempo, almacene más de 50 petabytes, mientras que en el sector de la bioinformática, las 12 empresas 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.
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, lo que los transforma. Debido al enorme tamaño de los datos, podría haber características desconocidas en ellos, 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 estos canales de análisis y los largos tiempos de ejecución 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 se pueden depurar volviendo a ejecutar todo el análisis 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 volverán más grandes y más agudos a medida que estos sistemas y datos sigan creciendo. Como tal, formas más rentables de analizar la computación escalable intensiva de datos (DISC) son cruciales para su uso continuo y efectivo.
Según un estudio de EMC/IDC: [15]
Trabajar con esta escala de datos se ha vuelto todo un desafío.
Los datos no estructurados suelen hacer referencia a información que no se encuentra en una base de datos tradicional de filas y columnas. Los archivos de datos no estructurados suelen incluir texto y contenido multimedia. Algunos ejemplos son los mensajes de correo electrónico, los documentos de procesamiento de textos, los vídeos, las fotos, los archivos de audio, las presentaciones, las páginas web y muchos otros tipos de documentos empresariales. Cabe señalar que, aunque este tipo de archivos pueden tener una estructura interna, se siguen considerando "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 está creciendo de forma significativa, a menudo muchas veces más rápido que el crecimiento de las bases de datos estructuradas. " Los macrodatos pueden incluir datos estructurados y no estructurados, pero IDC estima que el 90 por ciento de los macrodatos son datos no estructurados". [16]
El desafío fundamental de las fuentes de datos no estructurados es que son difíciles de desempaquetar, comprender y preparar para el uso analítico tanto para los usuarios comerciales no técnicos como para los analistas de datos. Más allá de los problemas de estructura, está el gran volumen de este tipo de datos. Debido a esto, las técnicas actuales de minería de datos a menudo dejan fuera información valiosa y hacen que el análisis de datos no estructurados sea laborioso y costoso. [17]
En el competitivo entorno empresarial actual, las empresas tienen que 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 utilizando una mayor memoria y procesamiento paralelo para procesar grandes volúmenes de datos rápidamente. Otro método es colocar los datos en la memoria pero utilizando un enfoque de computación en cuadrícula , donde se utilizan muchas máquinas para resolver un problema. Ambos enfoques permiten a las organizaciones explorar enormes volúmenes de datos. Incluso con este nivel de hardware y software sofisticados, pocas de las tareas de procesamiento de imágenes a gran escala toman de unos pocos días a algunas 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 empresas más nuevas como Trifacta , Alteryx y otras. [19]
Otro método para rastrear el linaje de datos son los programas de hojas de cálculo como Excel que ofrecen a los usuarios el linaje a nivel de celda, o la capacidad de ver qué celdas dependen de otra, pero se pierde la estructura de la transformación. De manera similar, el software ETL o de mapeo proporciona linaje a nivel de transformación, pero esta vista normalmente no muestra datos y es demasiado granular para distinguir entre transformaciones que son lógicamente independientes (por ejemplo, transformaciones que operan en columnas distintas) o dependientes. [20] Las plataformas de Big Data tienen una estructura muy complicada. Los datos se distribuyen entre varias máquinas. Normalmente, los trabajos se mapean en varias máquinas y los resultados se combinan posteriormente mediante operaciones de reducción. La depuración de una tubería 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 en particular brinde resultados inesperados.
La procedencia o el linaje de los datos se pueden utilizar para facilitar la depuración de la cadena de procesamiento de big data . Esto requiere la recopilación de datos sobre las transformaciones de datos. La siguiente sección explicará la procedencia de los datos con más detalle.
La procedencia de los datos científicos proporciona un registro histórico de los datos y sus orígenes. La procedencia de los datos que se generan mediante transformaciones complejas, como los flujos de trabajo, es de un valor considerable para los científicos. [21] A partir de ella, se puede determinar la calidad de los datos en función de sus datos ancestrales y derivaciones, rastrear las fuentes de errores, permitir la recreación automatizada de derivaciones para actualizar los datos y proporcionar la atribución de las fuentes de datos. La procedencia también es esencial para el ámbito empresarial, donde se puede utilizar para profundizar en la fuente de los datos en un almacén de datos , rastrear la creación de propiedad intelectual y proporcionar un registro de auditoría para fines regulatorios.
Se propone el uso de la procedencia de los datos en 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 flujos de datos. Para ello, es necesario realizar un seguimiento del conjunto de entradas de cada operador, que se utilizaron para derivar cada una de sus salidas. Aunque existen varias formas de procedencia, como la procedencia de copia y la procedencia de cómo, [14] [22] la información que necesitamos es una forma simple de procedencia de por qué, o linaje , como lo definen Cui et al. [23]
PROV es una recomendación del W3C de 2013,
Intuitivamente, para un operador T que produce una salida o, el linaje consta de tripletes de la forma {I, T, o}, donde I es el conjunto de entradas a T utilizadas 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é entradas produjeron la salida o en el operador T?" [3] Una consulta que encuentra las entradas que derivan una salida se denomina consulta de rastreo hacia atrás, mientras que una que encuentra las salidas producidas por una entrada se denomina consulta de rastreo hacia adelante . [26] El rastreo hacia atrás es útil para la depuración, mientras que el rastreo hacia adelante es útil para rastrear la propagación de errores. [26] Las consultas de rastreo también forman la base para reproducir un flujo de datos original. [12] [23] [26] Sin embargo, para usar eficientemente el linaje 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 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 los diferentes casos de uso del linaje pueden dictar el nivel en el que se debe capturar el linaje. El linaje se puede capturar en el nivel del trabajo, utilizando archivos y dando tuplas de linaje de la forma {IF i, M RJob, OF i}, el linaje también se puede capturar en el nivel de cada tarea, utilizando registros y dando, por ejemplo, tuplas de linaje de la 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 en diferentes granularidades de operadores y datos dentro de un flujo de datos. [3]
Para capturar el linaje de extremo a extremo en un sistema DISC, utilizamos el modelo Ibis [27] , 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 de operador implica que el operador contenido (o hijo) realiza una parte de la operación lógica del operador contenedor (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 contenedores (superconjunto).
El concepto de linaje de datos prescriptivos combina el modelo lógico (entidad) de cómo deberían fluir esos datos con el linaje real para esa instancia. [28]
Los términos "linaje de datos" y "procedencia" generalmente describen la secuencia de pasos o procesos por los que ha pasado un conjunto de datos para llegar a su estado actual. Sin embargo, mirar hacia atrás en la auditoría o las correlaciones de registros para determinar el linaje desde un punto de vista forense falla en ciertos casos de gestió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ó con las normas sin el modelo lógico.
Sólo combinando un modelo lógico con eventos forenses atómicos se pueden validar actividades adecuadas:
Muchos informes de cumplimiento certificados requieren la procedencia del flujo de datos, así como los datos del estado final para una instancia específica. En este tipo de situaciones, cualquier desviación de la ruta prescrita debe tenerse en cuenta y, en su caso, remediarse. [29] Esto marca un cambio desde una simple "mirada retrospectiva" a un marco, que es más adecuado para capturar flujos de trabajo de cumplimiento.
La recopilación de linaje diferida generalmente captura solo linaje de grano grueso en tiempo de ejecución. Estos sistemas incurren en gastos generales de captura bajos debido a la pequeña cantidad de linaje que capturan. Sin embargo, para responder a consultas de rastreo de grano fino, deben reproducir el flujo de datos en toda (o una gran parte) de su entrada y recopilar linaje de grano fino durante la reproducción. Este enfoque es adecuado para sistemas forenses, donde un usuario desea depurar una salida incorrecta observada.
Los sistemas de recopilación activa 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 de grano fino, pero no requieren ningún cálculo adicional sobre el flujo de datos después de su ejecución. Los sistemas de recopilación de linaje de grano fino activos incurren en mayores gastos generales de captura que los sistemas de recopilación diferida. Sin embargo, permiten una reproducción y depuración sofisticadas. [3]
Un actor es una entidad que transforma datos; puede ser un vértice Dryad, operadores individuales de mapas y reducciones, un trabajo de MapReduce o una secuencia completa de flujos de datos. 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. De este modo, la instrumentación captura el linaje en un flujo de datos de un actor a la vez, y lo divide en un conjunto de asociaciones para cada actor. El desarrollador del sistema necesita capturar los datos que lee un actor (de otros actores) y los datos que escribe un actor (a otros actores). Por ejemplo, un desarrollador puede tratar el Hadoop Job Tracker como un actor al registrar el conjunto de archivos leídos y escritos por cada trabajo. [30]
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 el 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 y o es el conjunto de salidas dadas producidas por el actor. Las asociaciones son las unidades básicas del linaje de datos. Las asociaciones individuales se agrupan posteriormente para construir el historial completo de transformaciones que se aplicaron a los datos. [3]
Los sistemas de big data se escalan horizontalmente, es decir, aumentan la capacidad añadiendo nuevas entidades de hardware o software al sistema distribuido. El sistema distribuido actúa como una sola entidad en el nivel lógico, aunque comprenda múltiples entidades de hardware y software. El sistema debería seguir manteniendo esta propiedad después del escalamiento 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 escalamiento horizontal se puede realizar utilizando hardware básico.
La característica de escalabilidad horizontal de los sistemas de Big Data debe tenerse en cuenta al crear la arquitectura del almacén de linaje. Esto es esencial porque el propio almacén de linaje también debe poder escalar en paralelo con el sistema de Big Data . La cantidad de asociaciones y la cantidad de almacenamiento necesarias para almacenar el linaje aumentarán con el aumento del tamaño y la 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 y sea imposible de escalar. La solución inmediata a este problema es distribuir el propio almacén de linaje. [3]
El mejor escenario posible 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 en una máquina en particular se almacena en el almacén de linaje local de esa máquina específica. El almacén de linaje generalmente 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 dos problemas. Permite el escalamiento horizontal del almacén de linaje. Si se utilizara un único almacén de linaje centralizado, entonces esta información tendría que ser transportada a través de la red, lo que causaría latencia de red adicional. La latencia de red también se evita mediante el uso de un almacén de linaje distribuido. [30]
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 posteriormente para finalizar 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 en una máquina se almacenan en el almacén de linaje local de esa máquina. 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 puede utilizar el flujo de datos para depurar la canalización de big data . El flujo de datos se reconstruye en 3 etapas.
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 almacén 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 utilizando una serie de uniones 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 unión. Las tablas unidas deben almacenarse en una sola instancia o una máquina para continuar el procesamiento. Existen múltiples esquemas que se utilizan para elegir una máquina donde se calculará una unión. El más fácil es el que tiene una carga mínima de CPU. Las restricciones de espacio también se deben tener en cuenta al elegir la instancia donde se realizará la unió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 en el 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 ascendente de T es aquel que produjo la entrada de T, mientras que un actor descendente es aquel que consume la salida de T. Las relaciones de contención siempre se consideran al crear los vínculos. El gráfico consta de tres tipos de vínculos o aristas.
El vínculo más simple es un vínculo especificado explícitamente entre dos actores. Estos vínculos 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 de MapReduce , cada instancia de mapa conoce la instancia exacta del lector de registros cuya salida consume. [3]
Los desarrolladores pueden asociar 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 origen y un tipo de destino. Por ejemplo, en la arquitectura MapReduce , el tipo de actor map es el origen de reduce, y viceversa. El sistema infiere esto a partir de los arquetipos de flujo de datos y vincula debidamente las instancias de map con las instancias de reduce. Sin embargo, puede haber varios trabajos de MapReduce en el flujo de datos, y vincular todas las instancias de map con todas las instancias de reduce puede crear vínculos falsos. Para evitar esto, dichos vínculos se restringen a las 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 map y reduce solo se vinculan entre sí si pertenecen al mismo trabajo. [3]
En los sistemas distribuidos, a veces hay vínculos 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 leyó de él. Estos vínculos conectan actores que utilizan un conjunto de datos común para la ejecución. El conjunto de datos es la salida del primer actor y la entrada del actor que lo sigue. [3]
El paso final en la reconstrucción del flujo de datos es la ordenació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 tarea o canalización de big data.
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 canalización. El flujo de datos ayuda al científico de datos o al desarrollador a analizar en profundidad a los actores y sus transformaciones. Este paso permite al científico de datos descubrir la parte del algoritmo que está generando el resultado inesperado. Una canalización de big data puede fallar de dos maneras generales. La primera es la presencia de un actor sospechoso en el flujo de datos. La segunda 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 del linaje y del flujo de datos juntos, un científico de datos puede descubrir cómo se convierten las entradas en salidas. Durante el proceso, se pueden detectar actores que se comportan de manera inesperada. Estos actores se pueden eliminar del flujo de datos o se pueden aumentar con 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 los actores del flujo de datos, [31] lo que puede resultar costoso en recursos para flujos de datos largos. Otro enfoque es inspeccionar manualmente los registros de linaje para encontrar anomalías, [13] [32] lo que puede ser tedioso y consumir mucho tiempo en varias etapas de un flujo de datos. Además, estos enfoques solo funcionan cuando el científico de datos puede descubrir salidas incorrectas. Para depurar análisis sin salidas incorrectas conocidas, el científico de datos debe analizar el flujo de datos en busca de comportamiento sospechoso 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 dichos cambios en el comportamiento del actor a lo largo del tiempo y en diferentes instancias de actor. Por lo tanto, la minería de linaje para identificar dichos 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 concuerdan con el resto de resultados. Las entradas que están causando estos resultados incorrectos son 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 son exitosos si el flujo de datos reproducido no produce resultados incorrectos.
Si bien el uso de enfoques de linaje de datos es una forma novedosa de depurar los flujos de datos masivos , 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 operadores de caja negra y muchos otros. Estos desafíos deben considerarse cuidadosamente y es necesario evaluar las compensaciones entre ellos para hacer un diseño realista para la captura de linaje de datos.
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. La cantidad total de operadores que se ejecutan en cualquier momento en un clúster puede variar de cientos a 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 convertirse en un cuello de botella para el análisis DISC.
Los sistemas de captura de linaje también deben ser tolerantes a fallos para evitar volver a ejecutar flujos de datos para capturar el linaje. Al mismo tiempo, también deben adaptarse a los fallos del sistema DISC. Para ello, 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 debe poder gestionar sin problemas varias instancias de sistemas de linaje locales que dejan de funcionar. 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.
Los sistemas de linaje para flujos de datos DISC deben ser capaces de capturar el linaje preciso entre operadores de caja negra para permitir una depuración de grano fino. Los enfoques actuales para esto incluyen Prober, que busca encontrar el conjunto mínimo de entradas que pueden 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, [33] y el corte dinámico, como lo utilizan Zhang et al. [34] para capturar el linaje para operadores NoSQL a través de la reescritura binaria para calcular cortes dinámicos. Aunque producen un linaje altamente preciso, estas técnicas pueden incurrir en gastos de tiempo significativos para la captura o el seguimiento, y puede ser preferible en cambio sacrificar algo de precisión para un mejor rendimiento. Por lo tanto, existe la necesidad de un sistema de recopilación de linaje para flujos de datos DISC que pueda capturar el linaje de operadores arbitrarios con una precisión razonable y sin gastos de tiempo significativos en la captura o el seguimiento.
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 et al. [26] pueden 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. Lipstick, [35] un sistema de linaje para Pig, [36] si bien puede realizar rastreo hacia atrás y hacia adelante, es específico para los operadores Pig y SQL y solo puede realizar rastreo de grano grueso para 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.
La reproducción de solo entradas o partes específicas de un flujo de datos es crucial para una depuración eficiente y para simular escenarios hipotéticos. Ikeda et al. presentan una metodología para la actualización basada en linaje, que reproduce selectivamente las entradas actualizadas para volver a calcular las salidas afectadas. [37] 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 las salidas previamente afectadas por el error para producir salidas sin errores. Llamamos a esto reproducción exclusiva. Otro uso de la reproducción en la depuración implica reproducir entradas incorrectas para una depuración paso a paso (llamada reproducción selectiva). Los enfoques actuales para usar el linaje en los sistemas DISC no abordan estos problemas. Por lo tanto, existe la necesidad de un sistema de linaje que pueda realizar reproducciones tanto exclusivas como selectivas para abordar diferentes necesidades de depuración.
Una de las principales preocupaciones de depuración en los sistemas DISC es la identificación de operadores defectuosos. En flujos de datos largos con varios cientos de operadores o tareas, la inspección manual puede ser tediosa y prohibitiva. Incluso si se utiliza el linaje para limitar 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 económico, que pueda limitar sustancialmente el conjunto de operadores potencialmente defectuosos, con una precisión razonable, para minimizar la cantidad de examen manual necesario.
{{cite web}}: CS1 maint: copia archivada como título ( enlace )