Происхождение данных включает происхождение данных , то, что с ними происходит и куда они перемещаются с течением времени. [1] Происхождение данных обеспечивает наглядность, значительно упрощая возможность отслеживания ошибок до первопричины в процессе анализа данных . [2]
Это также позволяет воспроизводить определенные части или входные данные потока данных для пошаговой отладки или восстановления потерянных выходных данных. Системы баз данных используют такую информацию, называемую происхождением данных , для решения аналогичных задач проверки и отладки. [3] Под происхождением данных понимаются записи о входах, объектах, системах и процессах, которые влияют на интересующие данные, обеспечивая историческую запись данных и их происхождение. Созданные свидетельства поддерживают такие криминалистические операции, как анализ зависимостей данных, обнаружение и восстановление ошибок / компрометации, аудит и анализ соответствия. « Происхождение - это простой тип причины происхождения ». [3]
Происхождение данных может быть представлено визуально, чтобы обнаружить поток / перемещение данных от источника к месту назначения через различные изменения и переходы на его пути в корпоративной среде, как данные трансформируются в процессе, как изменяются представление и параметры, и как данные разделяются или сходятся после каждого перехода. Простое представление Data Lineage может быть показано точками и линиями, где точка представляет собой контейнер данных для точек данных, а линии, соединяющие их, представляют преобразования, которым точка данных претерпевает, между контейнерами данных.
Представление во многом зависит от области управления метаданными и интересующей точки отсчета. Линия данных обеспечивает источники данных и промежуточные переходы потока данных от опорной точки с обратной линией данных , ведет к точкам данных конечного пункта назначения и его промежуточные потоки данных с прямой передачей данных . Эти представления могут быть объединены с непрерывным происхождением для контрольной точки, которая обеспечивает полный контрольный журнал этой интересующей точки данных от источников до ее конечных пунктов назначения. По мере увеличения количества точек данных или скачков сложность такого представления становится непонятной. Таким образом, лучшей особенностью представления происхождения данных будет возможность упростить представление путем временного маскирования нежелательных периферийных точек данных. Инструменты с функцией маскирования обеспечивают масштабируемость представления и улучшают анализ, обеспечивая удобство работы как технических, так и бизнес-пользователей. Линия данных также позволяет компаниям отслеживать источники конкретных бизнес-данных с целью отслеживания ошибок, внесения изменений в процессы и осуществления миграции системы, чтобы сэкономить значительное количество времени и ресурсов, тем самым значительно повысив эффективность бизнес- аналитики . [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]
- 2,8 ЗБ данных были созданы и воспроизведены в 2012 году,
- цифровая вселенная будет удваиваться каждые два года до 2020 года, и
- в 2020 году на каждого человека будет приходиться примерно 5,2 ТБ данных.
Работа с таким масштабом данных стала очень сложной задачей.
Неструктурированные данные
Неструктурированные данные обычно относятся к информации, которая не находится в традиционной базе данных строка-столбец. Файлы с неструктурированными данными часто включают текстовый и мультимедийный контент. Примеры включают сообщения электронной почты, текстовые документы, видео, фотографии, аудиофайлы, презентации, веб-страницы и многие другие виды деловых документов. Обратите внимание, что, хотя файлы такого типа могут иметь внутреннюю структуру, они по-прежнему считаются «неструктурированными», поскольку содержащиеся в них данные не помещаются в базу данных. По оценкам экспертов, от 80 до 90 процентов данных в любой организации неструктурированы. И объем неструктурированных данных на предприятиях растет значительно, часто во много раз быстрее, чем растут структурированные базы данных. « Большие данные могут включать как структурированные, так и неструктурированные данные, но, по оценкам IDC, 90 процентов больших данных - это неструктурированные данные». [16]
Основная проблема неструктурированных источников данных заключается в том, что их трудно распаковать, понять и подготовить к аналитическому использованию как для нетехнических бизнес-пользователей, так и для аналитиков. Помимо вопросов структуры, существует огромный объем данных этого типа. Из-за этого современные методы интеллектуального анализа данных часто упускают ценную информацию и делают анализ неструктурированных данных трудоемким и дорогостоящим. [17]
Длительное время работы
В сегодняшней конкурентной бизнес-среде компании должны быстро находить и анализировать нужные данные. Задача состоит в том, чтобы обработать объемы данных и получить доступ к необходимому уровню детализации на высокой скорости. Проблема только возрастает по мере увеличения степени детализации. Одно из возможных решений - оборудование. Некоторые поставщики используют увеличенную память и параллельную обработку для быстрой обработки больших объемов данных. Другой метод - размещение данных в памяти, но с использованием подхода вычислений сетки , когда для решения проблемы используется множество машин. Оба подхода позволяют организациям исследовать огромные объемы данных. Даже на этом уровне сложного оборудования и программного обеспечения некоторые задачи обработки изображений в большом масштабе занимают от нескольких дней до нескольких недель. [18] Отладка обработки данных чрезвычайно сложна из-за длительного времени выполнения.
Третий подход к расширенным решениям для обнаружения данных сочетает в себе самостоятельную подготовку данных с визуальным обнаружением данных, что позволяет аналитикам одновременно готовить и визуализировать данные в интерактивной среде анализа, предлагаемой новыми компаниями Trifacta , Alteryx и другими. [19]
Другой метод отслеживания происхождения данных - это программы для работы с электронными таблицами, такие как Excel, которые действительно предлагают пользователям происхождение на уровне ячеек или возможность видеть, какие ячейки зависят от других, но при этом теряется структура преобразования. Точно так же ETL или программное обеспечение сопоставления обеспечивают происхождение на уровне преобразования, но это представление обычно не отображает данные и является слишком грубым, чтобы различать преобразования, которые являются логически независимыми (например, преобразования, которые работают с отдельными столбцами) или зависимыми. [20]
Комплексная платформа
Платформы больших данных имеют очень сложную структуру. Данные распределяются между несколькими машинами. Обычно задания отображаются на нескольких машинах, а результаты позже объединяются операциями сокращения. Отладка конвейера больших данных становится очень сложной задачей из-за самой природы системы. Специалисту по данным будет нелегко выяснить, какие данные машины имеют выбросы и неизвестные особенности, из-за которых конкретный алгоритм дает неожиданные результаты.
Предложенное решение
Происхождение или происхождение данных можно использовать для упрощения отладки конвейера больших данных . Это требует сбора данных о преобразованиях данных. В следующем разделе более подробно объясняется происхождение данных.
Источник данных
Источник данных обеспечивает историческую запись данных и их происхождение. Источники данных, которые генерируются сложными преобразованиями, такими как рабочие процессы, имеют большое значение для ученых. [21] Из него можно установить качество данных на основе их предковых данных и производных, отследить источники ошибок, разрешить автоматическое воспроизведение производных для обновления данных и предоставить атрибуцию источников данных. Происхождение также важно для бизнес-домена, где его можно использовать для детализации до источника данных в хранилище данных , отслеживания создания интеллектуальной собственности и обеспечения контрольного следа для нормативных целей.
Использование источника данных предлагается в распределенных системах для отслеживания записей через поток данных, воспроизведения потока данных на подмножестве его исходных входных данных и отладки потоков данных. Для этого необходимо отслеживать набор входных данных для каждого оператора, которые использовались для получения каждого из его выходных данных. Несмотря на то, что существует несколько форм происхождения, таких как происхождение копии и происхождение, [14] [22], необходимая нам информация является простой формой происхождения или происхождения , как это определено Cui et al. [23]
Захват родословной
Интуитивно понятно, что для оператора T, производящего вывод o, происхождение состоит из троек формы {I, T, o}, где I - это набор входных данных для T, используемых для вывода o. Захват происхождения для каждого оператора T в потоке данных позволяет пользователям задавать такие вопросы, как «Какие выходные данные были получены при вводе i для оператора T?» и «Какие входы дали результат o в операторе T?» [3] Запрос, который находит входные данные, являющиеся производными для выходных данных, называется запросом обратной трассировки, в то время как запрос, который находит выходные данные, созданные входными данными, называется запросом прямой трассировки. [24] Обратная трассировка полезна для отладки, а прямая трассировка полезна для отслеживания распространения ошибок. [24] Запросы трассировки также формируют основу для воспроизведения исходного потока данных. [12] [23] [24] Однако, чтобы эффективно использовать происхождение в системе DISC, мы должны иметь возможность фиксировать происхождение на нескольких уровнях (или гранулярностях) операторов и данных, фиксировать точное происхождение для структур обработки DISC и иметь возможность для эффективного отслеживания нескольких этапов потока данных.
Система DISC состоит из нескольких уровней операторов и данных, и различные варианты использования происхождения могут определять уровень, на котором необходимо фиксировать происхождение. Происхождение может быть зафиксировано на уровне задания, используя файлы и задавая кортежи родословной формы {IF i, M RJob, OF i}, родословную также можно зафиксировать на уровне каждой задачи, используя записи и давая, например, кортежи родословной формы {(k rr, v rr), map, (km, vm)}. Первая форма линии передачи называется крупнозернистой линией, а вторая форма называется мелкозернистой линией. Интеграция происхождения с разной степенью детализации позволяет пользователям задавать такие вопросы, как «Какой файл, прочитанный заданием MapReduce, привел к этой конкретной выходной записи?» и может быть полезен при отладке различных операторов и данных в потоке данных. [3]
Чтобы зафиксировать сквозное происхождение в системе DISC, мы используем модель Ibis [25], которая вводит понятие иерархии включения для операторов и данных. В частности, Ibis предлагает, чтобы оператор мог содержаться внутри другого, и такая связь между двумя операторами называется включением оператора . «Включение оператора подразумевает, что содержащийся (или дочерний) оператор выполняет часть логической операции содержащего (или родительского) оператора». [3] Например, задача MapReduce содержится в задании. Аналогичные отношения включения существуют и для данных, называемые вложением данных. Включение данных подразумевает, что содержащиеся данные являются подмножеством содержащихся данных (надмножеством).
Предписательная линия передачи данных
Концепция предписывающего происхождения данных объединяет логическую модель (сущность) того, как эти данные должны течь, с фактическим происхождением для этого экземпляра. [26]
Происхождение и происхождение данных обычно относится к способу или этапам перехода набора данных к текущему состоянию. Происхождение данных, а также ко всем копиям или производным. Однако простое рассмотрение только корреляций аудита или журналов для определения происхождения с точки зрения судебной экспертизы является ошибочным для определенных случаев управления данными. Например, без логической модели невозможно с уверенностью определить, был ли маршрут рабочего процесса данных правильным или соответствующим.
Только путем объединения логической модели с атомарными криминалистическими событиями можно проверить правильность действий:
- Авторизованные копии, присоединения или операции CTAS
- Сопоставление обработки с системами, в которых эти процессы выполняются
- Ad-Hoc по сравнению с установленными последовательностями обработки
Многие сертифицированные отчеты о соответствии требуют происхождения потока данных, а также данных о конечном состоянии для конкретного экземпляра. В таких ситуациях любое отклонение от предписанного пути должно быть учтено и потенциально исправлено. [27] Это знаменует собой сдвиг в мышлении от чисто модели ретроспективного анализа к структуре, которая лучше подходит для отслеживания рабочих процессов соответствия.
Активная и ленивая родословная
Ленивый сбор данных о происхождении обычно захватывает только грубое происхождение во время выполнения. Эти системы несут низкие накладные расходы на захват из-за небольшого количества захваченных линий. Однако, чтобы ответить на запросы точной трассировки, они должны воспроизвести поток данных на всем (или на большей части) входных данных и собрать точную информацию о происхождении во время воспроизведения. Этот подход подходит для криминалистических систем, где пользователь хочет отладить обнаруженный неверный результат.
Активные системы сбора данных фиксируют всю происхождение потока данных во время выполнения. Вид захваченного ими происхождения может быть грубым или мелкозернистым, но они не требуют каких-либо дополнительных вычислений в потоке данных после его выполнения. Активные системы сбора мелкозернистых линий несут более высокие накладные расходы на сбор, чем системы ленивого сбора. Однако они позволяют выполнять сложные операции воспроизведения и отладки. [3]
Актеры
Актер - это объект, который преобразует данные; это может быть вершина Dryad, отдельные операторы map и reduce, задание MapReduce или весь конвейер потока данных. Акторы действуют как черные ящики, а входы и выходы актера используются для фиксации происхождения в форме ассоциаций, где ассоциация представляет собой тройку {i, T, o}, которая связывает вход i с выходом o для актера. Т. Таким образом, инструментарий фиксирует происхождение в потоке данных по одному актору за раз, собирая его в набор ассоциаций для каждого актора. Разработчику системы необходимо фиксировать данные, которые субъект читает (от других субъектов), и данные, которые субъект записывает (другим субъектам). Например, разработчик может рассматривать Hadoop Job Tracker как актера, записывая набор файлов, считываемых и записываемых каждым заданием. [28]
Ассоциации
Ассоциация - это комбинация входов, выходов и самой операции. Операция представлена в виде черного ящика, также известного как актер. Связи описывают преобразования, применяемые к данным. Ассоциации хранятся в таблицах ассоциаций. Каждый уникальный актер представлен собственной таблицей ассоциаций. Сама ассоциация выглядит как {i, T, o}, где i - набор входных данных для актора T, а o - набор выходных данных, выдаваемых актором. Ассоциации являются основными единицами линии передачи данных. Позже отдельные ассоциации объединяются, чтобы построить всю историю преобразований, которые были применены к данным. [3]
Архитектура
Системы больших данных масштабируются по горизонтали, т. Е. Увеличивают емкость за счет добавления нового оборудования или программного обеспечения в распределенную систему. Распределенная система действует как единое целое на логическом уровне, даже если она состоит из нескольких аппаратных и программных объектов. Система должна продолжать поддерживать это свойство после горизонтального масштабирования. Важным преимуществом горизонтальной масштабируемости является то, что она может обеспечить возможность увеличения емкости на лету. Самый большой плюс в том, что горизонтальное масштабирование может быть выполнено с использованием стандартного оборудования.
При создании архитектуры хранилища данных следует учитывать возможность горизонтального масштабирования систем Big Data . Это важно, потому что хранилище родословной само по себе также должно иметь возможность масштабироваться параллельно с системой больших данных . Количество ассоциаций и объем памяти, необходимые для хранения происхождения, будут увеличиваться с увеличением размера и емкости системы. Архитектура систем больших данных делает использование единого хранилища данных нецелесообразным и невозможным для масштабирования. Непосредственным решением этой проблемы является распространение самого хранилища родословных. [3]
В лучшем случае для каждой машины в сети распределенной системы используется локальное хранилище родословных. Это позволяет также масштабировать хранилище родословной по горизонтали. В этой схеме происхождение преобразований данных, применяемых к данным на конкретной машине, хранится в локальном хранилище происхождения этой конкретной машины. Хранилище родословной обычно хранит таблицы ассоциаций. Каждый субъект представлен своей собственной ассоциативной таблицей. Строки сами являются ассоциациями, а столбцы представляют входы и выходы. Эта конструкция решает 2 проблемы. Это позволяет горизонтально масштабировать хранилище родословной. Если использовалось единственное централизованное хранилище родословных, то эту информацию нужно было переносить по сети, что привело бы к дополнительной сетевой задержке. Сетевая задержка также устраняется за счет использования распределенного хранилища данных о происхождении. [28]
Реконструкция потока данных
Информация, хранящаяся в виде ассоциаций, должна быть каким-то образом объединена, чтобы получить поток данных конкретного задания. В распределенной системе задание разбито на несколько задач. Один или несколько экземпляров выполняют определенную задачу. Результаты, полученные на этих отдельных машинах, позже объединяются для завершения работы. Задачи, выполняемые на разных машинах, выполняют несколько преобразований данных на машине. Все преобразования, применяемые к данным на машинах, хранятся в локальном хранилище данных этих машин. Эту информацию необходимо объединить, чтобы получить представление о происхождении всей работы. Происхождение всей работы должно помочь специалисту по данным понять поток данных в работе, и он / она может использовать поток данных для отладки конвейера больших данных . Реконструкция потока данных осуществляется в 3 этапа.
Таблицы ассоциаций
Первым этапом восстановления потока данных является вычисление ассоциативных таблиц. Таблицы ассоциаций существуют для каждого актера в каждом локальном хранилище родословной. Путем объединения этих отдельных таблиц ассоциаций можно вычислить всю таблицу ассоциаций для актера. Обычно это делается с помощью серии соединений на равенство, основанных на самих актерах. В некоторых сценариях таблицы также могут быть объединены с использованием входных данных в качестве ключа. Индексы также можно использовать для повышения эффективности соединения. Объединенные таблицы необходимо сохранить в одном экземпляре или на машине, чтобы продолжить обработку. Существует несколько схем, которые используются для выбора машины, на которой будет вычислено соединение. Самый простой - с минимальной загрузкой процессора. При выборе экземпляра, в котором будет происходить соединение, также следует учитывать ограничения по объему.
График ассоциации
Второй шаг в реконструкции потока данных - это вычисление графа ассоциаций на основе информации о происхождении. График представляет шаги в потоке данных. Акторы действуют как вершины, а ассоциации действуют как ребра. Каждый субъект T связан со своими вышестоящими и нижележащими субъектами в потоке данных. Актер восходящего потока T - это тот, кто произвел вход T, в то время как нижестоящий субъект - тот, который потребляет выход T. При создании ссылок всегда учитываются сдерживающие отношения. Граф состоит из трех типов связей или ребер.
Явно указанные ссылки
Простейшая ссылка - это явно указанная связь между двумя участниками. Эти ссылки явно указаны в коде алгоритма машинного обучения. Когда актор знает о своем точном восходящем или нисходящем актере, он может передать эту информацию в Lineage API. Эта информация позже используется для связи этих субъектов во время запроса трассировки. Например, в архитектуре MapReduce каждый экземпляр карты знает точный экземпляр средства чтения записей, выходные данные которого он использует. [3]
Логически выведенные ссылки
Разработчики могут прикреплять архетипы потока данных к каждому логическому субъекту. Архетип потока данных объясняет, как дочерние типы типа актера размещаются в потоке данных. С помощью этой информации можно сделать вывод о связи между каждым субъектом исходного типа и целевого типа. Например, в архитектуре MapReduce тип актора карты является источником для сокращения, и наоборот. Система делает это на основе архетипов потока данных и должным образом связывает экземпляры карты с экземплярами сокращения. Однако в потоке данных может быть несколько заданий MapReduce , и связывание всех экземпляров карты со всеми экземплярами reduce может создать ложные ссылки. Чтобы предотвратить это, такие ссылки ограничены экземплярами актора, содержащимися в общем экземпляре актора содержащего (или родительского) типа актора. Таким образом, экземпляры map и reduce связаны друг с другом только в том случае, если они принадлежат одному и тому же заданию. [3]
Неявные ссылки через совместное использование набора данных
В распределенных системах иногда встречаются неявные ссылки, которые не указываются при выполнении. Например, существует неявная связь между субъектом, который записал в файл, и другим субъектом, который читает из него. Такие ссылки соединяют акторов, которые используют общий набор данных для выполнения. Набор данных является выходом первого актера и входом следующего за ним актера. [3]
Топологическая сортировка
Заключительным этапом реконструкции потока данных является топологическая сортировка графа ассоциаций. Ориентированный граф, созданный на предыдущем шаге, топологически сортируется, чтобы получить порядок, в котором субъекты изменили данные. Этот порядок наследования субъектов определяет поток данных конвейера больших данных или задачи.
Отслеживание и воспроизведение
Это самый важный шаг в отладке больших данных . Захваченная родословная объединяется и обрабатывается для получения потока данных конвейера. Поток данных помогает специалисту по обработке данных или разработчику глубже изучить действующих лиц и их трансформации. Этот шаг позволяет специалисту по обработке данных выяснить, какая часть алгоритма генерирует неожиданный результат. Большой данные трубопровод может пойти не так в двух широких направлениях. Первый - это наличие подозрительного субъекта в потоке данных. Второй - наличие выбросов в данных.
Первый случай можно отладить, отслеживая поток данных. Используя вместе информацию о происхождении и потоке данных, специалист по данным может выяснить, как входные данные преобразуются в выходные. Во время процесса могут быть пойманы неожиданно ведущие себя субъекты. Либо эти субъекты могут быть удалены из потока данных, либо они могут быть дополнены новыми субъектами для изменения потока данных. Улучшенный поток данных можно воспроизвести, чтобы проверить его достоверность. Отладка ошибочных акторов включает в себя рекурсивное выполнение грубого воспроизведения акторов в потоке данных [29], что может быть дорогостоящим в ресурсах для длинных потоков данных. Другой подход состоит в том, чтобы вручную проверить журналы происхождения на предмет аномалий [13] [30], что может быть утомительным и трудоемким на нескольких этапах потока данных. Более того, эти подходы работают только тогда, когда специалист по данным может обнаружить плохие результаты. Чтобы отлаживать аналитику без известных плохих результатов, специалисту по данным необходимо проанализировать поток данных на предмет подозрительного поведения в целом. Однако часто пользователь может не знать ожидаемого нормального поведения и не может указывать предикаты. В этом разделе описывается методология отладки для ретроспективного анализа происхождения для выявления ошибочных участников в многоступенчатом потоке данных. Мы полагаем, что внезапные изменения в поведении актора, такие как его средняя избирательность, скорость обработки или размер выходных данных, являются характеристикой аномалии. Происхождение может отражать такие изменения в поведении акторов с течением времени и в разных экземплярах акторов. Таким образом, анализ происхождения для выявления таких изменений может быть полезен при отладке неисправных участников в потоке данных.
Вторая проблема, то есть наличие выбросов, также может быть идентифицирована путем пошагового выполнения потока данных и просмотра преобразованных выходных данных. Специалист по обработке данных находит подмножество выходных данных, которые не соответствуют остальным выходным данным. Входные данные, которые вызывают эти плохие результаты, являются выбросами в данных. Эта проблема может быть решена путем удаления набора выбросов из данных и воспроизведения всего потока данных. Ее также можно решить, изменив алгоритм машинного обучения путем добавления, удаления или перемещения субъектов в потоке данных. Изменения в потоке данных успешны, если воспроизводимый поток данных не дает плохих результатов.
Вызовы
Несмотря на то, что использование подходов к передаче данных является новым способом отладки конвейеров больших данных , этот процесс непрост. Проблемы включают в себя масштабируемость хранилища родословных, отказоустойчивость хранилища родословных, точное определение происхождения для операторов «черного ящика» и многие другие. Эти проблемы необходимо тщательно рассмотреть, и необходимо оценить компромиссы между ними, чтобы создать реалистичный дизайн для сбора данных о происхождении.
Масштабируемость
Системы DISC - это в первую очередь системы пакетной обработки, рассчитанные на высокую производительность. Они выполняют несколько заданий на аналитику, с несколькими задачами на задание. Общее количество операторов, выполняемых в любое время в кластере, может варьироваться от сотен до тысяч в зависимости от размера кластера. Захват происхождения для этих систем должен иметь возможность масштабирования как для больших объемов данных, так и для множества операторов, чтобы не стать узким местом для аналитики DISC.
Отказоустойчивость
Системы захвата происхождения также должны быть отказоустойчивыми, чтобы избежать повторного запуска потоков данных для захвата происхождения. В то же время они также должны учитывать сбои в системе DISC. Для этого они должны иметь возможность идентифицировать неудачную задачу DISC и избегать хранения дублирующих копий родословной между частичной линией, созданной неудачной задачей, и дублирующей линией, созданной перезапущенной задачей. Система родословной также должна быть способна корректно обрабатывать несколько экземпляров локальных систем родословной, выходящих из строя. Это может быть достигнуто путем хранения реплик ассоциаций родословных на нескольких машинах. Реплика может действовать как резервная копия в случае потери реальной копии.
Операторы черного ящика
Системы происхождения для потоков данных DISC должны иметь возможность фиксировать точное происхождение между операторами черного ящика, чтобы обеспечить точную отладку. Текущие подходы к этому включают Prober, который стремится найти минимальный набор входных данных, который может дать указанный вывод для оператора черного ящика, путем многократного воспроизведения потока данных для вывода минимального набора [31] и динамического среза, как используется Zhang et al. [32], чтобы зафиксировать происхождение операторов NoSQL посредством двоичной перезаписи для вычисления динамических срезов. Несмотря на получение высокоточной линии происхождения, такие методы могут потребовать значительных затрат времени на захват или отслеживание, и вместо этого может быть предпочтительнее отдать некоторую точность ради лучшей производительности. Таким образом, существует потребность в системе сбора данных о происхождении для потоков данных DISC, которая может фиксировать происхождение от произвольных операторов с разумной точностью и без значительных накладных расходов при захвате или отслеживании.
Эффективное отслеживание
Трассировка важна для отладки, во время которой пользователь может отправить несколько запросов трассировки. Таким образом, важно, чтобы отслеживание выполнялось быстро. Икеда и др. [24] могут выполнять эффективные запросы обратной трассировки для потоков данных MapReduce, но не являются общими для разных систем DISC и не выполняют эффективных прямых запросов. Lipstick, [33] система происхождения для Pig, [34], хотя и может выполнять как обратную, так и прямую трассировку, специфична для операторов Pig и SQL и может выполнять только грубую трассировку для операторов черного ящика. Таким образом, существует потребность в системе происхождения, которая обеспечивает эффективную прямую и обратную трассировку для общих систем DISC и потоков данных с операторами черного ящика.
Изысканный повтор
Воспроизведение только определенных входных данных или частей потока данных имеет решающее значение для эффективной отладки и моделирования сценариев «что, если». Икеда и др. представить методологию обновления на основе происхождения, которая выборочно воспроизводит обновленные входные данные для пересчета затронутых выходных данных. [35] Это полезно во время отладки для повторного вычисления выходных данных, когда неверный вход был исправлен. Однако иногда пользователю может потребоваться удалить неверный ввод и воспроизвести последовательность выходных данных, на которые ранее была нанесена ошибка, для получения безошибочных выходных данных. Мы называем это эксклюзивным воспроизведением. Другое использование воспроизведения при отладке включает воспроизведение неверных входных данных для пошаговой отладки (так называемое выборочное воспроизведение). Текущие подходы к использованию происхождения в системах DISC не решают эти проблемы. Таким образом, существует потребность в системе происхождения, которая может выполнять как эксклюзивные, так и выборочные повторы для удовлетворения различных потребностей отладки.
Обнаружение аномалий
Одной из основных задач отладки в системах DISC является выявление неисправных операторов. В длинных потоках данных с несколькими сотнями операторов или задач ручная проверка может быть утомительной и непосильной. Даже если происхождение используется для сужения подмножества операторов для изучения, происхождение одного вывода все равно может охватывать несколько операторов. Существует потребность в недорогой автоматизированной системе отладки, которая может существенно сузить круг потенциально ошибочных операторов с разумной точностью, чтобы минимизировать количество требуемых ручных проверок.
Смотрите также
- Направленный ациклический граф
Рекомендации
- ^ http://www.techopedia.com/definition/28040/data-lineage
- ^ Хоанг, Натали (2017-03-16). «Линия передачи данных помогает повысить ценность бизнеса | Trifacta» . Trifacta . Проверено 20 сентября 2017 .
- ^ a b c d e f g h i j k Де, Сумьярупа. (2012). Newt: архитектура для воспроизведения и отладки на основе происхождения в системах DISC. Калифорнийский университет в Сан-Диего: b7355202. Источник: https://escholarship.org/uc/item/3170p7zn.
- ^ Дрори, Аманон (18 мая 2020 г.). «Что такое линия передачи данных? | Octopai» . Octopai . Проверено 25 августа 2020 .
- ^ Джеффри Дин и Санджай Гемават. Mapreduce: упрощенная обработка данных на больших кластерах. Commun. ACM, 51 (1): 107–113, январь 2008 г.
- ^ Майкл Айсард, Михай Будиу, Юань Ю, Эндрю Биррелл и Деннис Феттерли. Дриада: распределенные программы с параллельными данными из последовательных строительных блоков. В материалах 2-й Европейской конференции ACM SIGOPS / EuroSys по компьютерным системам 2007, EuroSys '07, страницы 59–72, Нью-Йорк, Нью-Йорк, США, 2007. ACM.
- ^ Apache Hadoop. http://hadoop.apache.org .
- ^ Гжегож Malewicz, Мэттью H Остерн, Aart JC Бик, Джеймс С. Dehnert, Илан Хорн, Naty Лейзер и Гжегож Czajkowski. Pregel: система для обработки крупномасштабных графиков. В материалах международной конференции по управлению данными 2010 г., SIGMOD '10, страницы 135–146, Нью-Йорк, штат Нью-Йорк, США, 2010 г. ACM.
- ^ Шимин Чен и Стивен В. Шлоссер. Map-reduce встречает более широкий спектр приложений. Технический отчет, Intel Research, 2008 г.
- ^ Поток данных в геномике. https://www-304.ibm.com/connections/blogs/ibmhealthcare/entry/data overload in genomics3? lang = de, 2010.
- ^ Yogesh Л. Simmhan, Бет Plale, и Деннис Гэннон. Обзор данных в электронной науке. SIGMOD Rec., 34 (3): 31–36, сентябрь 2005 г.
- ^ Б Ян Фостер, Jens Vockler, Майкл Wilde, и Юн Чжао. Химера: виртуальная система данных для представления, запроса и автоматизации вывода данных. На 14-й Международной конференции по управлению научными и статистическими базами данных, июль 2002 г.
- ^ а б Бенджамин Х. Сигельман, Луис Андр Баррозу, Майк Берроуз, Пэт Стивенсон, Манодж Плакал, Дональд Бивер, Саул Джаспан и Чандан Шанбхаг. Dapper, крупномасштабная инфраструктура трассировки распределенных систем. Технический отчет, Google Inc., 2010 г.
- ^ a b Питер Бунеман , Санджив Кханна и Ван-Чью Тан . Источник данных: некоторые основные вопросы. В материалах 20-й конференции по основам программных технологий и теоретической информатики, FST TCS 2000, страницы 87–93, Лондон, Великобритания, 2000. Springer-Verlag
- ^ http://www.emc.com/about/news/press/2012/20121211-01.htm
- ^ Webopedia http://www.webopedia.com/TERM/U/unstructured_data.html
- ^ Шефер, Пейдж (2016-08-24). «Различия между структурированными и неструктурированными данными» . Trifacta . Проверено 20 сентября 2017 .
- ^ SAS. http://www.sas.com/resources/asset/five-big-data-challenges-article.pdf Архивировано 20 декабря 2014 г. на Wayback Machine
- ^ «5 требований для эффективной самостоятельной подготовки данных» . www.itbusinessedge.com . Проверено 20 сентября 2017 .
- ^ Кандел, Шон (2016-11-04). «Отслеживание происхождения данных в финансовых услугах | Trifacta» . Trifacta . Проверено 20 сентября 2017 .
- ^ Паскье, Томас; Лау, Мэтью К .; Трисович, Ана; Boose, Emery R .; Кутюрье, Бен; Кросас, Мерсе; Эллисон, Аарон М .; Гибсон, Валери; Джонс, Крис Р .; Зельцер, Марго (5 сентября 2017 г.). «Если бы эти данные могли говорить» . Научные данные . 4 : 170114. DOI : 10.1038 / sdata.2017.114 . PMC 5584398 . PMID 28872630 .
- ^ Роберт Икеда и Дженнифер Видом. Происхождение данных: обзор. Технический отчет, Стэнфордский университет, 2009 г.
- ^ а б Я. Цуй и Дж. Видом. Трассировка происхождения для общих преобразований хранилища данных. Журнал VLDB, 12 (1), 2003.
- ^ a b c d Роберт Икеда, Хёнджунг Пак и Дженнифер Видом. Происхождение для обобщенной карты и сокращения рабочих процессов. В Proc. CIDR, январь 2011 г.
- ^ С. Olston и А. Дас Сарма. Ibis: менеджер происхождения для многоуровневых систем. В Proc. CIDR, январь 2011 г.
- ^ http://info.hortonworks.com/rs/549-QAL-086/images/Hadoop-Governance-White-Paper.pdf
- ^ Руководство по соответствию SEC для малых предприятий
- ^ a b Дионисий Логотетис, Сумьярупа Де и Кеннет Йокум. 2013. Масштабируемый сбор данных для отладки аналитики DISC. В материалах 4-го ежегодного симпозиума по облачным вычислениям (SOCC '13). ACM, Нью-Йорк, Нью-Йорк, США, статья 17, 15 страниц.
- ^ Чжоу, Вэньчао; Фэй, Цюн; Нараян, Арджун; Хэберлен, Андреас; Тау Лу, Бун ; Шерр, Мика (декабрь 2011 г.). Безопасное сетевое происхождение . Материалы 23-го симпозиума ACM по принципам операционных систем (SOSP).
- ^ Фонсека, Родриго; Портер, Джордж; Кац, Рэнди Х .; Шенкер, Скотт; Стойка, Ион (2007). X-trace: универсальная среда для отслеживания сети . Материалы НСДИ'07.
- ↑ Аниш Дас Сарма, Альпа Джайн и Филип Боханнон. PROBER: Специальная отладка конвейеров извлечения и интеграции. Технический отчет, Yahoo, апрель 2010 г.
- ^ Минва Чжан, Xiangyu Чжан Сян Чжан, и Сунил Prabhakar. Отслеживание происхождения за пределами реляционных операторов. В Proc. Конференция по очень большим базам данных (VLDB), сентябрь 2007 г.
- ↑ Яэль Амстердам, Сьюзен Б. Дэвидсон, Дэниел Дойч, Това Майло и Юлия Стоянович. Помада на свинью: включение происхождения рабочего процесса в стиле базы данных. В Proc. VLDB, август 2011 г.
- ^ Кристофер Olston, Бенджамин Рид, Utkarsh Шривастава, Рави Кумар, и Эндрю Томкинс. Свиной латынь: не очень иностранный язык для обработки данных. В Proc. ACM SIGMOD, Ванкувер, Канада, июнь 2008 г.
- ^ Роберт Ikeda, Семий Салихогл и Дженнифер Вид. Обновление на основе происхождения в рабочих процессах, ориентированных на данные. В материалах 20-й международной конференции ACM по управлению информацией и знаниями, CIKM '11, страницы 1659–1668, Нью-Йорк, Нью-Йорк, США, 2011. ACM.