Введение. О чем пойдет речь.

В современном IT ландшафте широко используются форматы представления данных JSON и XML, используемые в качестве своеобразного «общего языка», lingua franca для обмене информацией. (XML, конечно, сильно уступил натиску JSON, но еще кое‑где держится).

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

Какие проблемы будем решать

В случае, когда формат используется в качестве основы для удаленного вызова процедур через API, особой проблемы не возникает, все‑таки при вызове функции логично представлять параметры вызова и ожидаемый ответ.

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

интеграция данных из многих REST API источников или файлов
данные из NoSQL баз данных или хранящиеся в реляционных БД в виде JSON/XML документов
данные из систем обмена сообщениями, например ESB

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

При решении вопроса какая часть информации нам действительно нужна, приходится выбирать между тем, чтобы делать полный маппинг всего содержимого с увеличением трудозатрат и «выковыриваем» нужного подмножества данных с риском пропустить нужное и возвращаться к процессу парсинга/маппинга в будущем. (Конечно, в любом сценарии предпочтительной архитектурой здесь является сохранение архива сырых данные в исходном формате, чтобы было к чему вернуться в случае необходимости).

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

Архитектура решения — 1. Парсинг.

JSON и XML реализуют структуру данных «дерево».

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

Наша T‑таблица — приемник будет содержать все листья исходного дерева в следующих основных полях:

код источника — идентификатор файла или записи таблицы, хранящих исходный документ
полный путь к текущему элементу, например, через слэш
иерархический идентификатор листа дерева внутри документа
имя элемента
значение элемента (текстовое поле)
тип данных элемента
путь к началу массива (размножение однородных элементов)

Технология загрузки в данную структуру зависит от используемого стека, лично мне больше нравится пользоваться средствами СУБД. Практически все основные универсальные базы данных имеют соответствующий инструментарий, ну и популярные языки программирования, еще и с дополнительными библиотеками, «вооружены» в этом смысле неплохо.

Поле пути начала массива напрямую применимо только к JSON данным, так как в JSON есть соответствующий элемент синтаксиса (квадратные скобки). Для XML такого счастья у нас нет, есть только возможность распарсить, если она есть, xsd схему и выявить массивы через значение атрибута maxoccurs=unbounded. Или, если схемы в наличии нет, у нас после загрузки в T‑таблицу есть содержимое множества документов‑деревьев, в которых можно статистически «поймать» момент размножения однородных элементов по количеству потомков для соответствующего уровня.

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

Немного подробнее об иерархическом идентификаторе: вместо использования ссылок типа ParentID, мы построим иерархический идентификатор, пронумеровав вершины исходного документа одного уровня и склеив их в соответствии с путем к конечному элементу. В итоге должен получиться идентификатор вида 0001\0001\0003\0001\0002, точно указывающий на положение элемента в дереве. «Добивание» нулями справа до нужного количества знаков позволяет легко вычислять пути для связи родительской и дочерней подтаблицы через простое вычисление подстроки фиксированной длины (кстати, наш иерархический идентификатор позволяет также пропускать уровни при установлении связи, иногда это может быть полезно). Чисто практически длина идентификатора — это баланс между универсальностью и разумной достаточностью, в приведенном примере мы заложились на максимальное количество потомков конкретного элемента в документе в 9999, если мало, можно сделать больше или отдельно обрабатывать элементы с нестандартной длиной пути.

Подведем предварительный итог: после реализации парсинга исходных документов в T‑таблицу, мы получим универсальный алгоритм, который:

«схлопывает» все разнообразие исходных форматов в единое унифицированное представление, загружаемое единым алгоритмом
позволяет простой группировкой получить структуру всех обработанных документов и образцы значений любого элемента
при необходимости позволяет провести валидацию возможных значений каждого элемента (наличие элемента во всех документах, наличие null или пустых значений, диапазон и корректность значений элементов)
позволяет осуществлять поиск во всем содержимом всех документов, при этом в отличие от поиска по тексту документов и/или использования полнотекстового индексирования исходных документов, мы в итоге не только находим нужный документ, но и его конкретную позицию

При большом количестве исходных документов и/или большом размере документов размер таблицы может стать довольно значительным. Тогда на помощь придут общеизвестные практики оптимизации: индексирование, партицирование, колоночный формат хранения, регулярное обновление статистики, использование MPP‑СУБД (хотя вариант с MPP я бы оставил на закуску, если у вас не используется такая СУБД по умолчанию). Также стоит изначально строить процесс загрузки с расчетом на возможность переключать таблицы‑приемники — если у вас несколько источников данных (например, разные REST API), может быть разумно физически разделить хранение на несколько разных T‑таблиц (фактически, это еще один вид партицирования). Забегая немного вперед, для трансформации данных в целевую табличную структуру может быть разумным использовать отдельную таблицу‑буфер, которая заполняется каждый раз очередной порцией данных под обработку.

Архитектура решения — 2. Трансформация в табличную структуру данных.

При всех плюсах иерархических форматов (пусть даже мы и получили представление в форме T‑таблицы), проводить анализ данных из них напрямую — плохая идея, нужно трансформировать данные в структуру таблиц с правильными кардинальностями связей между ними.

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

Для решения этой задачи создадим отдельную таблицу шаблонов трансформации, содержащую следующие поля:

имя целевой таблицы
полный путь к элементу, который попадёт в целевую таблицу
глубина уровня, на котором начинаются данные таблицы
название поля целевой таблицы

Сама трансформация это, по сути, достаточно простой запрос, связывающий T‑таблицу с таблицей шаблонов по полным путям к элементам с группировкой по коду документа‑источника и подстроке иерархического идентификатора, длина подстроки равна [глубина уровня из таблицы шаблонов]*[количество знаков на уровень]. Значения полей получаем агрегатной функций, MAX или MIN.

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

Заполнение таблицы шаблонов трансформации хорошо алгоритмизируется/автоматизируется на основании данных T‑таблицы, особенно для JSON данных. Именно этот факт позволяет реализовать ранее обещанный практически полностью автоматический пайплайн. Единственной проблемой, для которой сложно предложить готовое универсальное решение, является нейминг целевых таблиц и полей: сохранять в названиях полный путь к элементу или массиву с заменой разделителей пути на подчеркивания — громоздко и легко выйдет за рамки ограничений СУБД, брать в качестве названия только последний элемент в пути — наверняка проявятся дублирующие элементы с тем же именем (типа «code» или «name») в других разделах документа. Можно попробовать брать имя последнего элемента в пути и прикреплять к нему трех‑ или четырехсимвольные «куски» имен нескольких предыдущих уровней в качестве составного суффикса.

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

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

В качестве заключения: возможные трудности внедрения

Если данный архитекутурный подход показался вам разумным и вы считаете, что его внедрение может принести ощутимую пользу вашим проектам, то, из моего опыта, могут быть два основных (в основном организационных) препятствия для успешного внедрения:

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

Вторая возможная проблема (как правило, в корпоративной среде): если вы обладаете достаточном уровнем полномочий, «продавили» решение, стартовали процесс, даже план составили с подзадачами, исполнителями и сроками — каменный цветок может не выйти. У меня был такой опыт, про причины могу только предположить что архитектурное сопровождение внедрения данной технологии должно работать не на уровне «понимаю общую мысль», а как езда на машине или велосипеде — «натренирован интуитивно применять на автомате». В процессе реализации может возникнуть много небольших, но важных моментов, решать которые желательно в рамках общей идеологии подхода.

Архитектура автоматической трансформации данных JSON и XML любой структуры унифицированным способом