Data Lineage — это процесс отслеживания того, как данные передаются и преобразуются в системе, а также того, как данные возникают, преобразуются и перемещаются с течением времени. [1] Data Lineage обеспечивает видимость и упрощает отслеживание ошибок до первопричины в процессе анализа данных . [2]
Он также позволяет воспроизводить определенные части или входы потока данных для пошаговой отладки или восстановления потерянных выходных данных. Системы баз данных используют такую информацию, называемую происхождением данных , для решения аналогичных задач проверки и отладки. [3] Происхождение данных относится к записям входов, сущностей, систем и процессов, которые влияют на интересующие данные, предоставляя историческую запись данных и их происхождения. Сгенерированные доказательства поддерживают криминалистическую деятельность, такую как анализ зависимости данных, обнаружение и восстановление ошибок/компрометаций, аудит и анализ соответствия. « Происхождение — это простой тип происхождения почему ». [3]
Управление данными включает управление метаданными с помощью руководств, стратегий и политик. Качество данных и управление основными данными помогают обогатить происхождение данных большей деловой ценностью. Несмотря на то, что окончательное представление происхождения данных предоставляется в одном интерфейсе, способ сбора метаданных и их отображения в графическом пользовательском интерфейсе (GUI) происхождения данных может быть совершенно разным. Таким образом, происхождение данных можно в целом разделить на три категории в зависимости от способа сбора метаданных: происхождение данных, включающее программные пакеты для структурированных данных, языки программирования и большие данные .
Информация о происхождении данных включает технические метаданные, включающие преобразования данных. Обогащенная информация о происхождении данных может включать результаты проверки качества данных, эталонные значения данных, модели данных , бизнес-словарь , управляющих данными , информацию об управлении программами и корпоративные информационные системы , связанные с точками данных и преобразованиями. Функция маскирования в визуализации происхождении данных позволяет инструментам включать все обогащения, которые имеют значение для конкретного варианта использования. Для представления разнородных систем в одном общем представлении может потребоваться нормализация или стандартизация метаданных .
Представление в целом зависит от области управления метаданными и интересующей опорной точки. Линия данных предоставляет источники данных и промежуточные потоки данных от опорной точки с обратной линией данных , ведущие к точкам данных конечного назначения и его промежуточным потокам данных с прямой линией данных . Эти представления можно объединить с линией сквозного происхождения для опорной точки, которая обеспечивает полный контрольный след этой интересующей точки данных от источников до их конечных пунктов назначения. По мере увеличения точек данных или переходов сложность такого представления становится непостижимой. Таким образом, лучшая функция представления линии данных — это возможность упростить представление путем временного маскирования нежелательных периферийных точек данных. Инструменты, которые имеют функцию маскирования, обеспечивают масштабируемость представления и улучшают анализ с наилучшим пользовательским интерфейсом как для технических, так и для бизнес-пользователей. Линия данных также позволяет компаниям отслеживать источники определенных бизнес-данных в целях отслеживания ошибок, внедрения изменений в процессы и внедрения системных миграций для экономии значительного количества времени и ресурсов. Линия данных может повысить эффективность процессов бизнес-аналитики BI. [4]
Линия данных может быть представлена визуально, чтобы обнаружить поток/движение данных от источника к месту назначения через различные изменения и переходы на своем пути в корпоративной среде: как данные преобразуются по пути, как изменяются представление и параметры, и как данные разделяются или сходятся после каждого перехода. Простое представление линии данных может быть показано с помощью точек и линий, где точка представляет собой контейнер данных для точек данных, а соединяющие их линии представляют собой преобразования, которым точка данных подвергается между контейнерами данных.
Линия данных может быть визуализирована на различных уровнях в зависимости от детализации представления. На очень высоком уровне линия данных предоставляет информацию о том, с какими системами взаимодействуют данные, прежде чем они достигнут пункта назначения. По мере увеличения детализации она переходит на уровень точки данных, где она может предоставить сведения о точке данных и ее историческом поведении, свойствах атрибутов, тенденциях и качестве данных , переданных через эту конкретную точку данных в линии данных.
Область действия линии передачи данных определяет объем метаданных, необходимых для представления ее линии передачи данных. Обычно управление данными и управление данными определяют область действия линии передачи данных на основе своих правил , стратегии управления данными предприятия, воздействия данных, атрибутов отчетности и критических элементов данных организации.
Распределенные системы, такие как Google Map Reduce , [5] Microsoft Dryad, [6] Apache Hadoop [7] (проект с открытым исходным кодом) и Google Pregel [8], предоставляют такие платформы для предприятий и пользователей. Однако даже с этими системами аналитика больших данных может занять несколько часов, дней или недель просто из-за объемов вовлеченных данных. Например, алгоритм прогнозирования рейтингов для конкурса Netflix Prize потребовал почти 20 часов для выполнения на 50 ядрах, а масштабная задача обработки изображений для оценки географической информации заняла 3 дня для выполнения с использованием 400 ядер. [9] «Ожидается, что Большой синоптический обзорный телескоп будет генерировать терабайты данных каждую ночь и в конечном итоге хранить более 50 петабайт, в то время как в секторе биоинформатики 12 крупнейших в мире домов секвенирования генома теперь хранят петабайты данных каждый». [10] Специалисту по данным очень сложно отследить неизвестный или непредвиденный результат.
Аналитика больших данных — это процесс изучения больших наборов данных для выявления скрытых закономерностей, неизвестных корреляций, рыночных тенденций, предпочтений клиентов и другой полезной деловой информации. Они применяют машинное обучение среди других алгоритмов к данным, которые преобразуют данные. Из-за огромного размера данных в данных могут быть неизвестные особенности, возможно, даже выбросы. Специалисту по данным довольно сложно фактически отладить неожиданный результат.
Огромный масштаб и неструктурированная природа данных, сложность этих аналитических конвейеров и длительное время выполнения создают значительные проблемы управляемости и отладки. Даже одну ошибку в этих аналитиках может быть чрезвычайно сложно идентифицировать и устранить. Хотя их можно отладить, повторно запустив всю аналитику через отладчик для пошаговой отладки, это может быть дорого из-за необходимого количества времени и ресурсов. Аудит и проверка данных являются другими серьезными проблемами из-за растущей простоты доступа к соответствующим источникам данных для использования в экспериментах, обмена данными между научными сообществами и использования сторонних данных в коммерческих предприятиях. [11] [12] [13] [14] Эти проблемы будут только увеличиваться и становиться более острыми по мере того, как эти системы и данные продолжают расти. Таким образом, более экономичные способы анализа масштабируемых вычислений с интенсивным использованием данных (DISC) имеют решающее значение для их дальнейшего эффективного использования.
Согласно исследованию EMC/IDC: [15]
Работать с такими масштабами данных стало очень сложно. [ обтекаемые слова ]
Неструктурированные данные обычно относятся к информации, которая не находится в традиционной базе данных строк и столбцов. Неструктурированные файлы данных часто включают текстовый и мультимедийный контент. Примерами являются сообщения электронной почты, документы обработки текста, видео, фотографии, аудиофайлы, презентации, веб-страницы и многие другие виды деловых документов. Обратите внимание, что хотя эти типы файлов могут иметь внутреннюю структуру, они все равно считаются «неструктурированными», поскольку данные, которые они содержат, не умещаются аккуратно в базу данных. Эксперты оценивают, что от 80 до 90 процентов данных в любой организации являются неструктурированными. И объем неструктурированных данных на предприятиях растет значительно, часто во много раз быстрее, чем растут структурированные базы данных. Большие данные могут включать как структурированные, так и неструктурированные данные, но IDC оценивает, что 90 процентов больших данных являются неструктурированными данными. [16]
Основная проблема неструктурированных источников данных заключается в том, что их трудно распаковать, понять и подготовить для аналитического использования как нетехническим бизнес-пользователям, так и аналитикам данных. Помимо проблем структуры, существует огромный объем этого типа данных. Из-за этого современные методы добычи данных часто упускают ценную информацию и делают анализ неструктурированных данных трудоемким и дорогим. [17]
В сегодняшней конкурентной бизнес-среде компании должны быстро находить и анализировать соответствующие данные, которые им нужны. Проблема заключается в том, чтобы просмотреть объемы данных и получить доступ к необходимому уровню детализации, и все это на высокой скорости. Проблема только растет по мере увеличения степени детализации. Одним из возможных решений является аппаратное обеспечение. Некоторые поставщики используют увеличенную память и параллельную обработку для быстрой обработки больших объемов данных. Другой метод заключается в размещении данных в памяти , но с использованием подхода сеточных вычислений , когда для решения проблемы используется множество машин. Оба подхода позволяют организациям исследовать огромные объемы данных. Даже при таком уровне сложного оборудования и программного обеспечения некоторые задачи обработки изображений в больших масштабах занимают от нескольких дней до нескольких недель. [18] Отладка обработки данных чрезвычайно сложна из-за длительного времени выполнения.
Третий подход к передовым решениям по обнаружению данных сочетает самостоятельную подготовку данных с визуальным обнаружением данных, позволяя аналитикам одновременно подготавливать и визуализировать данные бок о бок в интерактивной аналитической среде, предлагаемой новыми компаниями Trifacta , Alteryx и другими. [19]
Другой метод отслеживания происхождения данных — это программы электронных таблиц, такие как Excel, которые предлагают пользователям происхождение на уровне ячеек или возможность видеть, какие ячейки зависят друг от друга, но структура преобразования теряется. Аналогично, ETL или программное обеспечение для картирования предоставляют происхождение на уровне преобразования, однако это представление обычно не отображает данные и слишком грубое, чтобы различать преобразования, которые логически независимы (например, преобразования, которые работают с отдельными столбцами) или зависимые. [20] Платформы больших данных имеют очень сложную структуру. Данные распределены между несколькими машинами. Обычно задания отображаются на нескольких машинах, а результаты позже объединяются с помощью операций сокращения. Отладка конвейера больших данных становится очень сложной из-за самой природы системы. Для специалиста по данным будет непростой задачей выяснить, данные какой машины имеют выбросы и неизвестные особенности, из-за которых конкретный алгоритм дает неожиданные результаты.
Происхождение данных или происхождение данных можно использовать для упрощения отладки конвейера больших данных. Это требует сбора данных о преобразованиях данных. В следующем разделе более подробно объясняется происхождение данных.
Происхождение научных данных обеспечивает историческую запись данных и их происхождения. Происхождение данных, которые генерируются сложными преобразованиями, такими как рабочие процессы, имеет значительную ценность для ученых. [21] С его помощью можно установить качество данных на основе их предковых данных и производных, отследить источники ошибок, разрешить автоматическое повторное воспроизведение производных для обновления данных и предоставить атрибуцию источников данных. Происхождение также имеет важное значение для сферы бизнеса, где его можно использовать для детализации источника данных в хранилище данных , отслеживания создания интеллектуальной собственности и предоставления аудиторского следа для целей регулирования.
Использование происхождения данных предлагается в распределенных системах для отслеживания записей через поток данных, воспроизведения потока данных на подмножестве его исходных входов и отладки потоков данных. Для этого необходимо отслеживать набор входов для каждого оператора, которые использовались для получения каждого из его выходов. Хотя существует несколько форм происхождения, таких как копирование-происхождение и как-происхождение, [14] [22] информация, которая нам нужна, является простой формой почему-происхождения или родословной , как определено Куи и др. [23]
PROV — это рекомендация W3C от 2013 года,
Интуитивно понятно, что для оператора, производящего вывод , происхождение состоит из триплетов вида , где — набор входов, используемых для получения . [3] Запрос, который находит входы, выводящие вывод, называется запросом обратной трассировки , в то время как тот, который находит выходные данные, произведенные вводом, называется запросом прямой трассировки . [26] Обратная трассировка полезна для отладки, в то время как прямая трассировка полезна для отслеживания распространения ошибок. [26] Запросы трассировки также формируют основу для воспроизведения исходного потока данных. [12] [23] [26] Однако для эффективного использования происхождения в системе DISC нам необходимо иметь возможность фиксировать происхождение на нескольких уровнях (или детализации) операторов и данных, фиксировать точное происхождение для конструкций обработки DISC и иметь возможность эффективно отслеживать через несколько этапов потока данных.
Система DISC состоит из нескольких уровней операторов и данных , и различные варианты использования родословной могут диктовать уровень, на котором необходимо захватить родословную. Родословную можно захватить на уровне задания, используя файлы и задавая кортежи родословной вида {IF i, M RJob, OF i }, родословную также можно захватить на уровне каждой задачи, используя записи и задавая, например, кортежи родословной вида {(k rr, v rr ), map, (km, vm )}. Первая форма родословной называется грубозернистой родословной, в то время как вторая форма называется мелкозернистой родословной. Интеграция родословной с различной степенью детализации позволяет пользователям задавать такие вопросы, как «Какой файл, прочитанный заданием MapReduce, создал эту конкретную выходную запись?» и может быть полезна при отладке с различной степенью детализации операторов и данных в потоке данных. [3]
Для захвата сквозной родословной в системе DISC мы используем модель Ibis [27] , которая вводит понятие иерархий включения для операторов и данных. В частности, Ibis предполагает, что оператор может быть включен в другой, и такая связь между двумя операторами называется включением оператора . Включение оператора подразумевает, что включенный (или дочерний) оператор выполняет часть логической операции включенного (или родительского) оператора. [3] Например, задача MapReduce включена в задание. Аналогичные отношения включения существуют и для данных, называемые включением данных. Включение данных подразумевает, что включенные данные являются подмножеством включенных данных (надмножеством).
Системы передачи данных можно разделить на категории «жадные» и «ленивые». [26]
Системы сбора Eager захватывают всю родословную потока данных во время выполнения. Вид родословной, которую они захватывают, может быть грубозернистым или мелкозернистым, но они не требуют никаких дальнейших вычислений над потоком данных после его выполнения.
Ленивый сбор родословной обычно захватывает только грубозернистую родословную во время выполнения. Эти системы несут низкие накладные расходы захвата из-за небольшого количества родословной, которую они захватывают. Однако для ответа на запросы мелкозернистой трассировки они должны воспроизвести поток данных на всех (или большей части) его входных данных и собрать мелкозернистую родословную во время воспроизведения. Этот подход подходит для криминалистических систем, где пользователь хочет отладить наблюдаемый плохой вывод.
Системы сбора точной зернистости родословной требуют больших накладных расходов на захват, чем системы ленивого сбора. Однако они позволяют выполнять сложные повторы и отладку. [3]
Актер — это сущность, которая преобразует данные; это может быть вершина Dryad, отдельные операторы map и reduce, задание MapReduce или целый конвейер потока данных. Актеры действуют как черные ящики, а входы и выходы актера используются для захвата родословной в форме ассоциаций, где ассоциация — это триплет, который связывает вход с выходом для актера . Таким образом, инструментарий захватывает родословную в потоке данных по одному актеру за раз, объединяя его в набор ассоциаций для каждого актера. Разработчику системы необходимо захватывать данные, которые актер считывает (от других актеров), и данные, которые актер записывает (другим актерам). Например, разработчик может рассматривать Hadoop Job Tracker как актера, записывая набор файлов, считываемых и записываемых каждым заданием. [28]
Ассоциация — это комбинация входов, выходов и самой операции. Операция представлена в виде черного ящика, также известного как актор. Ассоциации описывают преобразования, применяемые к данным. Ассоциации хранятся в таблицах ассоциаций. Каждый уникальный актор представлен своей собственной таблицей ассоциаций. Сама ассоциация выглядит как {i, T, o}, где i — это набор входов для актора T, а o — это набор выходов, заданных и произведенных актором. Ассоциации — это основные единицы Data Lineage. Отдельные ассоциации позже объединяются для построения полной истории преобразований, которые применялись к данным. [3]
Системы больших данных увеличивают емкость путем добавления новых аппаратных или программных объектов в распределенную систему. Этот процесс называется горизонтальным масштабированием . Распределенная система действует как единая сущность на логическом уровне, даже если она включает в себя несколько аппаратных и программных объектов. Система должна продолжать поддерживать это свойство после горизонтального масштабирования. Важным преимуществом горизонтальной масштабируемости является то, что она может обеспечить возможность увеличения емкости на лету. Самый большой плюс заключается в том, что горизонтальное масштабирование может быть выполнено с использованием стандартного оборудования.
При создании архитектуры хранилища родословных следует учитывать возможность горизонтального масштабирования систем больших данных. Это важно, поскольку само хранилище родословных также должно иметь возможность масштабироваться параллельно с системой больших данных. Количество ассоциаций и объем хранилища, требуемого для хранения родословных, будут увеличиваться с увеличением размера и емкости системы. Архитектура систем больших данных делает использование одного хранилища родословных нецелесообразным и невозможным для масштабирования. Непосредственным решением этой проблемы является распределение самого хранилища родословных. [3]
Лучшим вариантом является использование локального хранилища родословных для каждой машины в распределенной системной сети. Это позволяет хранилищу родословных также масштабироваться горизонтально. В этой конструкции родословная преобразований данных, применяемых к данным на конкретной машине, хранится в локальном хранилище родословных этой конкретной машины. Хранилище родословных обычно хранит таблицы ассоциаций. Каждый актер представлен своей собственной таблицей ассоциаций. Строки являются самими ассоциациями, а столбцы представляют входы и выходы. Такая конструкция решает две проблемы. Она допускает горизонтальное масштабирование хранилища родословных. Если бы использовалось единое централизованное хранилище родословных, то эта информация должна была бы передаваться по сети, что привело бы к дополнительной сетевой задержке. Сетевая задержка также избегается за счет использования распределенного хранилища родословных. [28]
Информация, хранящаяся в виде ассоциаций, должна быть объединена каким-либо образом, чтобы получить поток данных конкретной работы. В распределенной системе работа разбивается на несколько задач. Один или несколько экземпляров запускают определенную задачу. Результаты, полученные на этих отдельных машинах, позже объединяются вместе, чтобы завершить работу. Задачи, запущенные на разных машинах, выполняют несколько преобразований данных в машине. Все преобразования, примененные к данным на машине, хранятся в локальном хранилище родословных этой машины. Эту информацию необходимо объединить вместе, чтобы получить родословную всей работы. Родословная всей работы должна помочь специалисту по данным понять поток данных работы, и он/она может использовать поток данных для отладки конвейера больших данных . Поток данных реконструируется в 3 этапа.
Первый этап реконструкции потока данных — вычисление таблиц ассоциаций. Таблицы ассоциаций существуют для каждого актера в каждом локальном хранилище родословной. Вся таблица ассоциаций для актера может быть вычислена путем объединения этих отдельных таблиц ассоциаций. Обычно это делается с помощью серии соединений равенства на основе самих актеров. В некоторых сценариях таблицы также могут быть объединены с использованием входных данных в качестве ключа. Индексы также могут использоваться для повышения эффективности объединения. Объединенные таблицы должны храниться на одном экземпляре или машине для дальнейшей обработки. Существует несколько схем, которые используются для выбора машины, на которой будет вычисляться объединение. Самая простая из них — с минимальной загрузкой ЦП. При выборе экземпляра, на котором будет происходить объединение, следует также учитывать ограничения по пространству.
Вторым шагом в реконструкции потока данных является вычисление графа ассоциаций из информации о происхождении. Граф представляет шаги в потоке данных. Актеры действуют как вершины, а ассоциации действуют как ребра. Каждый актер T связан со своими вышестоящими и нижестоящими актерами в потоке данных. Вышестоящий актер T — это тот, который создал входные данные T, в то время как нижестоящий актер — это тот, который потребляет выходные данные T. При создании связей всегда учитываются отношения сдерживания. Граф состоит из трех типов связей или ребер.
Самая простая связь — это явно указанная связь между двумя акторами. Эти связи явно указаны в коде алгоритма машинного обучения. Когда актор знает свой точный актор выше или ниже по течению, он может передать эту информацию в API lineage. Эта информация позже используется для связывания этих акторов во время запроса трассировки. Например, в архитектуре MapReduce каждый экземпляр карты знает точный экземпляр считывателя записей, выходные данные которого он потребляет. [3]
Разработчики могут прикреплять архетипы потока данных к каждому логическому актору. Архетип потока данных объясняет, как дочерние типы типа актора располагаются в потоке данных. С помощью этой информации можно вывести связь между каждым актором исходного типа и целевым типом. Например, в архитектуре MapReduce тип актора map является источником для reduce, и наоборот. Система выводит это из архетипов потока данных и должным образом связывает экземпляры map с экземплярами reduce. Однако в потоке данных может быть несколько заданий MapReduce, и связывание всех экземпляров map со всеми экземплярами reduce может создавать ложные ссылки. Чтобы предотвратить это, такие ссылки ограничиваются экземплярами акторов, содержащимися в общем экземпляре актора содержащего (или родительского) типа актора. Таким образом, экземпляры map и reduce связаны друг с другом только в том случае, если они принадлежат к одному и тому же заданию. [3]
В распределенных системах иногда существуют неявные связи, которые не указываются во время выполнения. Например, неявная связь существует между актором, который записал в файл, и другим актором, который считывает из него. Такие связи соединяют акторов, которые используют общий набор данных для выполнения. Набор данных является выходом первого актора и входом следующего за ним актора. [3]
Последним шагом в реконструкции потока данных является топологическая сортировка графа ассоциаций. Направленный граф, созданный на предыдущем шаге, топологически сортируется для получения порядка, в котором субъекты модифицировали данные. Этот наследуемый порядок субъектов определяет поток данных конвейера больших данных или задачи.
Это самый важный шаг в отладке больших данных . Полученная родословная объединяется и обрабатывается для получения потока данных конвейера. Поток данных помогает специалисту по данным или разработчику глубоко изучить актеров и их преобразования. Этот шаг позволяет специалисту по данным выяснить часть алгоритма, которая генерирует неожиданный вывод. Конвейер больших данных может выйти из строя двумя основными способами. Первый — это присутствие подозрительного актера в потоке данных. Второй — это наличие выбросов в данных.
Первый случай можно отладить, отследив поток данных. Используя информацию о происхождении и потоке данных вместе, специалист по данным может выяснить, как входные данные преобразуются в выходные данные. В ходе процесса можно поймать субъектов, которые ведут себя неожиданно. Эти субъекты могут быть либо удалены из потока данных, либо дополнены новыми субъектами для изменения потока данных. Улучшенный поток данных можно воспроизвести для проверки его валидности. Отладка неисправных субъектов включает рекурсивное выполнение грубого воспроизведения субъектов в потоке данных [29] , что может быть дорогостоящим по ресурсам для длинных потоков данных. Другой подход заключается в ручной проверке журналов происхождений для поиска аномалий [13] [30] , что может быть утомительным и отнимающим много времени на нескольких этапах потока данных. Кроме того, эти подходы работают только тогда, когда специалист по данным может обнаружить плохие выходные данные. Чтобы отладить аналитику без известных плохих выходных данных, специалисту по данным необходимо проанализировать поток данных на предмет подозрительного поведения в целом. Однако часто пользователь может не знать ожидаемого нормального поведения и не может указать предикаты. В этом разделе описывается методология отладки для ретроспективного анализа родословной для выявления неисправных акторов в многоэтапном потоке данных. Мы считаем, что внезапные изменения в поведении актора, такие как его средняя селективность, скорость обработки или размер выходных данных, являются характерными для аномалии. Родословная может отражать такие изменения в поведении актора с течением времени и в разных экземплярах актора. Таким образом, интеллектуальный анализ родословной для выявления таких изменений может быть полезен при отладке неисправных акторов в потоке данных.
Вторая проблема, т. е. наличие выбросов, также может быть выявлена путем пошагового запуска потока данных и просмотра преобразованных выходов. Специалист по данным находит подмножество выходов, которые не соответствуют остальным выходам. Входы, которые вызывают эти плохие выходы, являются выбросами в данных. Эту проблему можно решить, удалив набор выбросов из данных и воспроизведя весь поток данных. Ее также можно решить, изменив алгоритм машинного обучения путем добавления, удаления или перемещения участников в потоке данных. Изменения в потоке данных успешны, если воспроизведенный поток данных не создает плохих выходов.
Несмотря на то, что использование подходов к происхождению данных является новым способом отладки больших конвейеров данных , этот процесс не прост. К проблемам относятся масштабируемость хранилища происхождений, отказоустойчивость хранилища происхождений, точный захват происхождений для операторов черного ящика и многие другие. Эти проблемы необходимо тщательно рассмотреть, а компромиссы между ними необходимо оценить, чтобы создать реалистичный дизайн для захвата происхождений данных.
Системы DISC — это в первую очередь системы пакетной обработки, разработанные для высокой пропускной способности. Они выполняют несколько заданий на аналитику, с несколькими задачами на задание. Общее количество операторов, работающих в кластере в любой момент времени, может варьироваться от сотен до тысяч в зависимости от размера кластера. Захват родословной для этих систем должен иметь возможность масштабирования как для больших объемов данных, так и для многочисленных операторов, чтобы не стать узким местом для аналитики DISC.
Системы захвата родословной также должны быть отказоустойчивыми, чтобы избежать повторного запуска потоков данных для захвата родословной. В то же время они также должны учитывать сбои в системе DISC. Для этого они должны иметь возможность идентифицировать неудавшуюся задачу DISC и избегать сохранения дубликатов копий родословной между частичной родословной, созданной неудавшейся задачей, и дубликатом родословной, созданным перезапущенной задачей. Система родословной также должна иметь возможность изящно обрабатывать несколько экземпляров локальных систем родословных, выходящих из строя. Этого можно достичь путем хранения реплик ассоциаций родословных на нескольких машинах. Реплика может действовать как резервная копия в случае потери реальной копии.
Системы родословной для потоков данных DISC должны иметь возможность захватывать точную родословную между операторами черного ящика, чтобы обеспечить мелкозернистую отладку. Текущие подходы к этому включают Prober, который стремится найти минимальный набор входных данных, который может произвести указанный выход для оператора черного ящика, воспроизводя поток данных несколько раз, чтобы вывести минимальный набор, [31] и динамическое нарезание [32] для захвата родословной для операторов NoSQL посредством двоичной перезаписи для вычисления динамических срезов. Несмотря на создание высокоточной родословной, такие методы могут повлечь за собой значительные накладные расходы времени для захвата или трассировки, и может быть предпочтительнее вместо этого пожертвовать некоторой точностью ради лучшей производительности. Таким образом, существует потребность в системе сбора родословной для потоков данных DISC, которая может захватывать родословную от произвольных операторов с разумной точностью и без значительных накладных расходов на захват или трассировку.
Трассировка необходима для отладки, во время которой пользователь может выдавать несколько запросов трассировки. Таким образом, важно, чтобы трассировка имела быстрое время выполнения. Икеда и др. [26] могут выполнять эффективные запросы обратной трассировки для потоков данных MapReduce, но не являются общими для различных систем DISC и не выполняют эффективные прямые запросы. Lipstick, [33] система родословной для Pig, [34] хотя и может выполнять как обратную, так и прямую трассировку, специфична для операторов Pig и SQL и может выполнять только грубую трассировку для операторов черного ящика. Таким образом, существует потребность в системе родословной, которая обеспечивает эффективную прямую и обратную трассировку для общих систем DISC и потоков данных с операторами черного ящика.
Воспроизведение только определенных входов или частей потока данных имеет решающее значение для эффективной отладки и моделирования сценариев «что если». Икеда и др. представляют методологию обновления на основе родословной, которая выборочно воспроизводит обновленные входы для повторного вычисления затронутых выходов. [35] Это полезно во время отладки для повторного вычисления выходов, когда был исправлен неверный вход. Однако иногда пользователь может захотеть удалить неверный вход и воспроизвести родословную выходов, ранее затронутых ошибкой, для получения безошибочных выходов. Мы называем это исключительным воспроизведением. Другое использование воспроизведения при отладке включает воспроизведение неверных входов для пошаговой отладки (называемой выборочным воспроизведением). Текущие подходы к использованию родословной в системах DISC не решают эти проблемы. Таким образом, существует потребность в системе родословной, которая может выполнять как исключительные, так и выборочные повторы для решения различных задач отладки.
Одной из основных проблем отладки в системах DISC является выявление неисправных операторов. В длинных потоках данных с несколькими сотнями операторов или задач ручная проверка может быть утомительной и непомерной. Даже если для сужения подмножества операторов для проверки используется родословная, родословная одного вывода все равно может охватывать несколько операторов. Существует потребность в недорогой автоматизированной системе отладки, которая может существенно сузить набор потенциально неисправных операторов с разумной точностью, чтобы минимизировать объем требуемой ручной проверки.
