В настоящее время концепции происхождения данных и грамотности в отношении данных становятся все более и более популярными, однако все еще остается ряд давних вопросов, которые остаются без ответа. Допустим, у вас есть хранилище данных с тысячами объектов данных, включая таблицы, представления и хранимые процедуры. Как понять взаимосвязь между этими объектами данных, включая хранимые процедуры? А как узнать их связь с внешними процессами, API, сервисами, дашбордами и т.д.?

Для большинства администраторов хранилищ данных это правильный вопрос. Со временем хранилище данных становится все более и более сложным. Продолжает расти не только количество объектов данных и взаимосвязей, но и количество устаревших и дублированных/подобных объектов данных.

Здесь я хотел бы поделиться решением для управления связью хранилища данных с базой данных графа.

Прежде чем мы начнем, давайте проясним пару понятий, чтобы понять, почему родословная данных не поможет.

Происхождение данных — не ответ

Согласно Таленду:

Происхождение данных — это карта путешествия данных, которая включает в себя его происхождение, каждую остановку на пути и объяснение того, как и почему данные перемещались с течением времени. Происхождение данных может быть документировано визуально от источника до конечного пункта назначения, отмечая остановки, отклонения или изменения на этом пути. Этот процесс упрощает отслеживание операционных аспектов, таких как повседневное использование и устранение ошибок.

Становится очевидным, что управление линией передачи данных больше заинтересовано в отслеживании динамических отношений данных о том, как данные были преобразованы с одного этапа на другой. Если мы называем путешествие данных вертикальными отношениями, нам также интересно знать горизонтальные отношения данных, например. общая картина статических отношений. Мы хотим понять, как различные объекты данных взаимодействуют друг с другом и их сходства или различия.

База данных графов

По сравнению с традиционной реляционной базой данных, хранилищем ключей-значений или базой данных документов графовая база данных менее известна. Тем не менее, это невероятно полезно, так как я настоятельно рекомендую каждому инженеру данных иметь графическую базу данных в своем наборе инструментов.

Помимо других технических функций, графовая база данных управляет контентом в виде узлов и ссылок. Способ хранения и анализа данных очень похож на естественный человеческий разум. Многие базы данных графов также поставляются с простым способом запроса и представления графического интерфейса, что упрощает его использование для нетехнических заинтересованных сторон. И последнее, но не менее важное: довольно много баз данных также имеют встроенную поддержку машинного обучения, благодаря чему глубоко спрятанный секрет становится легким делом. Посмотрим, как это работает.

Фон

Недавно я работал над проектом миграции хранилища данных, чтобы перенести локальное хранилище Sybase на Bigquery. Все задания ETL были запланированы рабочими процессами и рабочими процессами Informatica, а в хранилище данных находится 1100 таблиц, 200 представлений и 700 хранимых процедур. Для своего проекта я выбрал Neo4j, так как это одна из самых популярных графовых баз данных. Он имеет достаточную мощность для покрытия этого небольшого набора данных, а его язык запросов под названием Cypher удобен для пользователя.

Входные данные представляют собой электронную таблицу Excel со всеми характеристиками таблиц, представлений, хранимых процедур и их взаимосвязей с рабочим процессом/рабочими процессами Informatica. Используя Pandas и множество регулярных выражений, я извлек все имена сущностей и их отношения в файлы CSV. Затем я импортировал очищенные данные в Neo4j. Результат такой, как показано:

У нас есть пять типов данных: процедура, таблица, представление, рабочий процесс и рабочийлет. Импортировано 2119 узлов данных. Также имеется 3710 взаимосвязей данных, которые были извлечены из файлов SQL и импортированы в Neo4j.

Теперь давайте найдем одну процедуру:

Верхнее окно — это запрос Cypher, а справа — список всех свойств, связанных с хранимой процедурой. Мы видим, что довольно много функций SQL записаны как свойства. Также имеется статистика длины запроса спецификации хранимой процедуры и признак того, была ли хранимая процедура полностью протестирована.

Если мы расширим подключения к процедуре хранения, результаты будут такими, как показано:

Теперь мы обнаружили, что процедура была вызвана одним Informatica Worklet. Он создает, загружает и выбирает одну промежуточную таблицу, а затем использует промежуточную таблицу для обновления целевой таблицы.

При дальнейшем расширении сети целевой таблицы мы увидим следующее:

Над целевой таблицей также работают три другие процедуры. Одна из них также вызывается тем же Informatica Worklet, однако две другие процедуры не контролируются никаким Informatica Worklet. Очевидно, возникает вопрос: почему они не контролируются Informatica? Может они уже не нужны, может надо разработать для них рабочий процесс?

Я надеюсь, вы видите, что без проверки определения SQL мы можем четко знать, как работают хранимые процедуры, их сложность и даже определить проблему, которую нелегко обнаружить без помощи инструмента.

Выявление закономерностей

Чтобы упростить миграцию хранилища данных, мы хотим определить общие шаблоны для автоматизации преобразования объектов данных. Мы заметили, что довольно много таблиц имеют либо процедуру загрузки, либо процедуру пакетного обновления. Давайте посмотрим, сколько таблиц содержат этот шаблон:

Таких таблиц 458, содержащих только хранимые процедуры load/batchupdate. Теперь давайте проверим оставшиеся таблицы:

Мы обнаружили, что таблиц, на которые ссылались несколько процедур, было мало. Интересно, что мы обнаружили, что некоторые из процедур сформировали изолированные клики, в то время как другие процедуры начали формировать большое сообщество. Основываясь на этом понимании, мы можем убедиться, что перенесли группу таблиц и процедур в один и тот же пакет, чтобы мы могли предоставлять интегрированную функцию из каждого пакета.

Машинное обучение

Мой проект миграции хранилища данных не нуждается в машинном обучении. Но просто для демонстрации давайте посмотрим, как запустить PageRank для узлов на основе связей. Имейте в виду, что PageRank — это алгоритм, изобретенный Google для своей поисковой системы в Интернете.

Шаг 1, сгенерируйте проекцию памяти графа, указав отношения, которые мы хотим включить:

call gds.graph.project('graph_3',
    ['Procedure', 'Table', 'View'],
    ['update', 'select','load','insert','delete']
)
yield graphName AS graph, nodeProjection, nodeCount AS nodes, relationshipProjection, relationshipCount AS rels

Шаг 2: сгенерируйте оценку PageRank для узла:

CALL gds.pageRank.stream('graph_3')
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).name AS name, score
ORDER BY score DESC, name ASC

Вот и все!

Мы можем использовать базу данных графиков многими творческими способами. Например, анализировать сходство процедур выявления дублирующегося кода, связывать узлы данных с каталогом данных и т. д.