Всем привет! В данном цикле статей мы поделимся своими результатами исследования по составлению профиля объектов данных, которые хранятся в RDBMS Oracle с помощью DataHub и интеграции с инструментом Great Expectations. В первой части мы поговорим про проблемы, которые возникли в ходе интеграции, а также поделимся найденными решениями для их устранения.

Глоссарий

• Профиль данных (профилирование) – исследование данных для выяснения статистических характеристик данных. Профилирование выполняют перед разработкой процедур ETL;

• Метаданные – описание структуры данных.  Какие типы объектов хранятся в базе данных, описание зависимостей между объектами и т.д.;

• DQ (DataQuality) – контроль качества данных.

Введение

Началось все с pre-sale проекта, в котором проводилось исследование возможных инструментов профилирования объектов данных из БД Oracle. Среди исследуемых инструментов числились DataHub и Great Expectations. В ходе их изучения мы решили написать данную статью, чтобы поделиться полученным опытом работы.

Мы пройдем следующий путь:

1. Подключим DataHub к БД Oracle и проведем профилирование данных;

2. Подключим GreatExpectations к БД Oracle для проведения DQ проверок;

3. Результаты проверок отправим из Great Expectations в DataHub.

Планируется получить в одном интерфейсе DataHub профиль объектов данных, которые хранятся в БД Oracle, и результаты DQ проверок, которые были определены в GreatExpectations.Мы рассмотрим подключение DataHub к базе данных Oracle и профилирование объектов данных.

1.1 Используемые инструменты

DataHub был выбран по той причине, что он является достаточно гибким и универсальным инструментом для профилирования данных. Внутри него есть коннекторы для большинства возможных источников данных, что и обуславливает универсальность. Также он собирает большое количество метрик, которые могут заинтересовать исследователей, и хранит их в историческом разрезе. Ознакомиться с интерфейсом DataHub и его возможностями можно на демо-стенде разработчиков. В дополнение к этому, DataHub является Open Source проектом. Если необходимо, возможно разработать свой инструмент на базе DataHub, добавив необходимые особенности.

DataHub имеет также одну полезную особенность: он может выступать в качестве приемника результатов DQ проверок, проведенных Great Expectations. Таким образом, мы можем в одном интерфейсе получить и профиль данных, и результаты DQ проверок.

1.2 Установка DataHub

Установку DataHub проводили на локальной машине под управлением Ubuntu 22.04. Это можно сделать, выполнив простые команды в bash:

python3 -m pip install --upgrade pip wheel setuptools
python3 -m pip install --upgrade acryl-datahub

Дополнительную информацию можно получить в официальной документации. На рабочей машине также необходим Docker и Docker Compose: Datahub имеет микросервисную архитектуру, каждый элемент которой работает в отдельном контейнере.

Запустить DataHub можно командой:

datahub docker quickstart

В случае успешного запуска мы увидим в конце похожее сообщение:

Проверить работу можно в любом браузере, пройдя по адресу: http://localhost:9002.

Работающий DataHub состоит из нескольких контейнеров. Можно выделить контейнеры, которые представляют собой отдельные сервисы, необходимые для работы DataHub:

schema-registry и broker – работающий инстанс kafka;

• zookeeper;

• elasticsearch;

• mysql;

Отдельные части самого DataHub:

• datahub-frontend-react – работа и отображение UI;

• datahub-gms – бэкэнд DataHub;

• datahub-datahub-actions-1 – бэкэнд функции action. Эта функция нами не использовалась по ненадобности, подробнее можно почитать в документации.

Также контейнеры, которые необходимы только для запуска. Во время работы они остановлены:

• kafka-setup;

• elasticsearch-setup;

• mysql-setup;

• datahub-upgrade.

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

Мы использовали быструю установку с помощью Python-библиотеки. Существует также возможность сборки DataHub как Java-проект с помощью Gradle. Исходный выложен на Github, а подробная инструкция по установке приведена в документации. Такой способ установки рекомендуется для разработки инструмента на основе открытого кода DataHub. В данной статье такой вариант использования DataHub не рассматривается.

1.3 Профилирование данных

В качестве исследуемой БД мы взяли стандартную тестовую схему HR от Oracle.

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

Ниже приведен рецепт, который был написан для профилирования всех объектов (таблиц и представлений) схемы HR. Подробно про каждый пункт можно прочитать в документации:

pipeline_name: "pipeline_name"
source:
    type: oracle
    config:
        host_port: "localhost:1521"
        username: HR
        password: HR
        service_name: XEPDB1
        schema_pattern:
            allow:
                - HR
        profiling:
            enabled: true
        stateful_ingestion:
            enabled: true
        profile_pattern:
            allow:
            - "HR.*.*"
        table_pattern:
            deny:
                - 'HR.G[EX]_*'
sink:
    type: "datahub-rest"
    config:
        server: "http://localhost:8080"

Запуск профилирования из командной строки выполняется с помощью следующей команды:

datahub ingest -c /path/to/recipe/recipe_name.yaml

Результат извлечения метаданных можно посмотреть в UI:

1.4 Возникшие проблемы

На скриншоте видим, что для численных полей DataHub не собрал метрики, которые он должен собирать (min, max, mean, median). Однако он собрал статистику по NULL’ам и уникальным значениям – эти метрики являются универсальными для всех типов полей. Также он собрал статистику по всей таблице – количество столбцов, записей. Также определил первичные, вторичные ключи и типы полей.

К сожалению, проблема со сбором метрик для полей численных типов на стороне DataHub. На данный момент он собирает числовые метрики только для полей типа float. Возможно, на момент публикации этой статьи проблема была решена. Она обсуждалась с разработчиками в их официальном канале в Slack’е (здесь), а также был инициализирован github issue для решения этой проблемы (здесь).

Кроме того, во время извлечения метаданных у нас возник ряд ошибок. Как мы их решали:

1. Не хватает модуля acryl-datahub[oracle]. Установить его можно командой в консоли.

pip install acryl-datahub[oracle]

Если вы запускаете из UI, то тут datahub достаточно умен, чтобы самостоятельно установить необходимые пакеты.

2. Внутренняя ошибка библиотеки cx_Oracle:

DatabaseError: (cx_Oracle.DatabaseError) DPI-1047: Cannot locate a 64-bit Oracle Client library: "libclntsh.so: cannot open shared object file: No such file or directory.

Тут уже сложнее. Для подключения к СУБД Oracle DataHub использует Python библиотеку cx_Oracle, которой необходим установленный клиент СУБД Oracle. Изначально он не поставляется на Ubuntu, но, тем не менее, установить возможно. Подробно установка приведена на сайте;

3. Для получения метаданных из Oracle DataHub потребует права на таблицы DBA_USERS и DBA_TABLES. Разработчики решили, что для адекватного сбора метаданных таблиц USER_TABLES и ALL_TABLES недостаточно. Использование более привилегированных таблиц жестко забито в исходном коде библиотеки. С этим остается только смириться и выдать права на эти таблицы юзеру, под которым DataHub заходит в БД.

После этого извлечение было выполнено успешно.

1.5 Выводы к 1-й части

Итак, мы успешно подключились из DataHub к БД Oracle. Инструмент показал себя с хорошей стороны: он достаточно гибок, имеет возможность подключения к различным источникам. Также он позволяет задать несколько объектов профилирования: для этого достаточно указать шаблоны regex и определить, по каким объектам и в каких схемах нужно делать профиль данных. Еще радует, что он не нагружает систему: все расчеты перекладываются на сервер, на котором установлен источник данных, сам же он только принимает результат. Благодаря этому была показана высокая скорость профилирования данных: таблицу с 50 колонками и 10 млн записями он обработал за 11.5 минут – то около 870 тысяч записей в минуту.

Однако, была обнаружена проблема в сборе метрик для числовых типов во время профилирования конкретно БД Oracle. Об этой проблеме были уведомлены разработчики инструмента, в будущем это должно быть исправлено. При профилировании БД PostgreSQL такой проблемы обнаружено не было.