УПРОЩЕННОЕ ПОСТРОЕНИЕ КОЛОНОЧНОЙ ЛИНИИ ДАННЫХ ДЛЯ ПЛАТФОРМ ВИЗУАЛЬНОЙ РАЗРАБОТКИ НА БАЗЕ APACHE SPARK

​SIMPLIFIED COLUMN-LEVEL DATA LINEAGE  INFERENCE FOR APACHE SPARK-BASED LOW-CODE PLATFORMS

Volkov Denis Dmitrievich

PhD student, National University of Science and Technology MISIS,

Russia, Moscow

Razumovskii Dmitrii Andreevich

PhD student, National University of Science and Technology MISIS,

Russia, Moscow

Stuchilin Vladimir Valerievich

Candidate of Sciences, Deputy Head of the Department of Information Systems, associate professor, National University of Science and Technology MISIS,

Russia, Moscow

АННОТАЦИЯ

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

ABSTRACT

The article addresses the problem of developing a lightweight algorithm for inference column-level data lineage for low-code platforms based on Apache Spark. A simplified algorithm is made for determining dependencies between columns using the optimized query execution plan and data schemas. An experimental evaluation on typical low-code pipeline scenarios demonstrated high precision and recall for linear and join scenarios and acceptable quality for scenarios with aggregation.

Ключевые слова: Apache Spark; платформы визуальной разработки; колоночная линия данных; оптимизированный план выполнения запросов; большие данные.

Keywords: Apache Spark; low-code platforms; column-level data lineage; optimized query execution plan; big data.

Развитие платформ обработки больших данных привело к широкому распространению платформ визуальной разработки, ориентированных на быструю разработку аналитических процессов [1]. В таких платформах бизнес-пользователь и аналитик оперируют визуальными блоками и декларативными конструкциями, а техническая сложность распределенных вычислений скрывается внутри инфраструктуры. В качестве вычислительного ядра для подобных систем часто применяется Apache Spark, который предоставляет масштабируемую обработку данных в памяти, развитый SQL и DataFrame API, интеграцию с инфраструктурой хранения и оркестрации [2].

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

Сбор зависимостей между наборами данных несет ключевую роль в задаче повышения прозрачности вычислений в системах обработки больших данных. В контексте рассматриваемых платформ на базе Apache Spark особый интерес представляет легковесный метод с детализацией до уровня колонок. В дальнейшем под линией данных понимается трассировка зависимостей между наборами данных и их колонками по цепочке преобразований (data lineage).

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

На рис. 1 показан типовой пример процесса для подготовки отчетной витрины.

Рисунок 1. Типовой процесс в системе визуальной разработки

Итоговые процессы как правило включают этапы: подготовка исходных таблиц, последовательные трансформации, объединение данных из нескольких источников, вычисление показателей и формирование итоговых витрин [3].

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

В предлагаемом подходе связи между данными определяются на основе оптимизированного плана выполнения Apache Spark, формирующегося оптимизатором Catalyst и на основе метаданных каталога платформы и встроенного каталога Spark. Набор операторов, используемый в типовых сценариях ограничен проекциями, соединениями источников, агрегированием и фильтрацией [4]. Каждый класс операторов является отображением множества входных колонок в множество выходных колонок. На основе указанных классов в таблице 1 выполняется обход плана и формируется граф зависимостей.

Таблица 1.

Правила формирования колоночной линии данных для основных операторов оптимизированного плана

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

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

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

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

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

Пошаговый алгоритм построения линии данных

1. Загрузка оптимизированного плана выполнения и схем входных и выходных таблиц.
2. Выделение из плана узлов типов Project, Filter, Join и Aggregate и упорядочивание этих узлов по направлению потока данных от источников к витринам.
3. Инициализация пустого графа  и добавление в множество V вершин для всех полей входных таблиц и итоговых витрин.
4. Для каждого узла n в упорядоченном списке:
5. Определение множеств  и  на основе схем данных и информации об атрибутах узла.
6. Для узлов Project и Aggregate разбор выражений вывода и вычисление множеств  для каждого .
7. Применение локального правила :
8. Для Filter: для каждого  при необходимости добавление вершины  в  и ребра  в ;
9. Для Project: для каждого  добавление ребер  для всех ;
10. Для Join: сопоставление выходных атрибутов вершинам левого и правого входов;
11. Для Aggregate: добавление ребер для ключей группировки и агрегированных колонок в соответствии с множествами  для .
5. Завершение обхода узлов плана и фиксация итогового графа .

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

Для оценки качества алгоритма сформирован набор сценариев, отражающих распространенные шаблоны процессов с последовательностью шагов, фиксированным набором операторов и заданными схемами входных и выходных таблиц. Входные данные представлены транзакционными таблицами, справочниками клиентов и агрегированными витринами; во всех сценариях использовались таблицы с 10–20 колонками и выражения, включающие не более 3–4 входных колонок. Обобщенная характеристика сценариев приведена в таблице 2.

Таблица 2.

Описание экспериментальных сценариев

Сценарий С1 моделирует типичный однотабличный процесс подготовки витрины, С2 отражает процесс интеграции транзакций со справочником клиентов через объединение по ключам и формирование результирующей витрины с комбинированной схемой, сценарий С3 ориентирован на агрегированную отчетную витрину.

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

Полученные значения точности P и полноты R для рассмотренных сценариев приведены в таблице 3.

Таблица 3.

Результаты оценки качества по экспериментальным сценариям

Результаты, представленные в таблице 3, показывают, что для линейного сценария С1 алгоритм обеспечивает максимально возможные значения точности и полноты. В сценарии С2, включающем объединения двух источников, значения метрик незначительно снижаются за счет появления отдельных избыточных зависимостей при последующей проекции, однако все ключевые связи между источниками и витриной сохраняются. В сценарии С3 использование агрегированных выражений приводит к дальнейшему снижению точности и полноты, что связано с консервативной стратегией формирования зависимостей для сложных агрегатов. При этом получаемый граф остается достаточным для решения практических задач анализа влияния изменений и аудита вычислительных цепочек в типичных процессах.

Список литературы:

1. Jangam S.K. Scalability and Performance Limitations of Low-Code and No-Code Platforms for Large-Scale Enterprise Applications and Solutions / S.K. Jangam // International Journal of Emerging Trends in Computer Science and Information Technology. – 2024. – Vol.5. № 37.
2. Tang S. A Survey on Spark Ecosystem: Big Data Processing Infrastructure, Machine Learning, and Applications / S. Tang, B. He, C. Yu et al. // IEEE Transactions on Knowledge and Data Engineering. – 2022. – Vol. 34. № 1. – P. 71-91.
3. Martinez E. Benefits and limitations of using low-code development to support digitalization in the construction industry / E. Martinez, L. Pfister // Automation in Construction. - 2023. – Vol. 152.
4. Paduroiu A. Membrane - Safe and Performant Data Access Controls in Apache Spark in the Presence of Imperative Code / A. Paduroiu, S. Wi, Y. Yan // Proc. VLDB Endow. — 2024. – Vol. 17. № 13.