В этой статье описывается, как команда Enterprise Data Lake (EDL) в PayPal создала Rule Execution Framework (REF) для реализации возможностей на уровне предприятия: создание централизованной системы конфигурации общих правил на уровне предприятия для определения, управления, контроля и развертывания. правила и наборы правил структуры качества данных.
Почему нам нужна команда Rule Execution Framework
Команды, занимающиеся преобразованием данных в PayPal, должны соответствовать определенным критериям качества данных:
- Гарантия того, что 100 % данных, которые передаются в зависимые системы ниже по течению, сертифицированы, обеспечивая при этом полную прозрачность любых исключений.
- Обеспечьте нулевую потерю данных
- Заблаговременно выявляйте проблемы с качеством и быстро устраняйте их, чтобы снизить риски и расходы, в том числе сократить количество критических предупреждений.
- Улучшить качество и точность данных
- Обеспечьте безопасность данных
Ключевым элементом выполнения этих требований является возможность определения и выполнения правил качества данных. Правило содержит формулу или выражение для выполнения операции, например проверки или преобразования. Для правил качества данных данные проверяются на соответствие правилу. В случае сбоя сведения о сбое сохраняются в таблицах исключений.
Команда REF была сформирована для создания этой структуры выполнения правил.
Первоначальное требование к REF состояло в том, чтобы предоставить возможности для управления и выполнения различных типов правил для команд, обращающихся с данными, поступающими в Enterprise Data Lake (EDL). Мы расширили возможности для поддержки любых корпоративных групп, которым необходимо управлять, контролировать и развертывать правила структуры качества данных.
Задачи
Команда REF столкнулась с некоторыми специфическими проблемами в существующем ландшафте данных:
- Логика проверки была встроена в код приложения ETL (извлечение, преобразование, загрузка).
- Аутентификация и подключение к различным типам источников данных, необходимых для соблюдения наших стандартов безопасности.
- У доступных инструментов была крутая кривая обучения
- Немногие инструменты отвечали требованию полностью встроенного выполнения правил в процессе клиентского приложения.
- Нам нужна была возможность повторить неудачные правила
- Процесс проверки данных, которые перемещаются между хранилищами данных, был ручным и часто постфактум.
Логика проверки
До разработки REF команды встраивали логику проверки в свой код и инструменты ETL. Например, если они использовали инструмент ETL, логика проверки была встроена в него. Если они использовали приложение Java, оно было встроено в их приложение Java. Одна из проблем заключается в том, что для внедрения нового технологического стека требуется эксперт, который может переписать код проверки и экспортировать его в новый инструмент. Обновление кода проверки для одного и того же инструмента требует экспертных знаний, поскольку код проверки и код преобразования взаимосвязаны в приложении ETL.
Решение от REF состояло в том, чтобы отделить логику проверки от любого конкретного инструмента или процесса. REF извлекает и фиксирует метаданные (таблицы, файлы, полученные сообщения, потоковые данные и т. д.) из источников данных. Абстракция на уровне метаданных позволяет платформе поддерживать несколько источников данных (базы данных, файлы и т. д.), используя один и тот же код для выполнения правил. Платформа предоставляет средство чтения для каждого типа данных. Как только платформа идентифицирует объект, она считывает данные и преобразует их в Spark DataFrame, который может быть обработан обработчиком правил.
На следующем рисунке показан общий обзор модели метаданных:
Кривая обучения
Команда просмотрела множество движков правил. Некоторые из них предлагали правила на естественном языке, тогда как другие предлагали выполнение на основе конфигурации. Тем не менее, большинство из них имеют крутую кривую обучения, что затрудняет управление сложными правилами. Поэтому мы решили использовать предопределенные шаблоны правил с настраиваемыми атрибутами для простых правил. В основном это вопрос настройки имени таблицы и столбца с критериями проверки для простых правил. Например, чтобы выполнить проверку длины, пользователю необходимо настроить имя таблицы, имя столбца и ожидаемую длину.
Для написания сложных правил мы решили использовать SQL, потому что почти все, кто работает с данными, от инженеров до бизнес-аналитиков и специалистов по данным, знают SQL и могут писать правила на основе SQL.
Команда REF создала приложение, которое может выполнять правила качества данных (DQ) в пакетном режиме для любых данных в состоянии покоя, например, в таблице или файле. Пользователям необходимо настроить и опубликовать правила, а также запланировать пакетное выполнение, но код приложения поддерживается командой REF. Настройка пакетного выполнения — это однократная операция для каждой среды, например, для запуска в определенном локальном кластере или облаке.
Приложение REF также обеспечивает поддержку выполнения в виде наборов правил, которые позволяют пользователю группировать и выполнять набор связанных правил. Например, вы можете написать правила для каждого столбца в таблице и создать набор правил для выполнения всех правил для этой таблицы.
Запуск встроенного кода
До сих пор мы говорили о проверках данных в состоянии покоя. У команды REF также было требование проверять потоковые данные в процессе ETL. Немногие инструменты могут удовлетворить эту потребность, но команда REF решила внедрить язык правил Drools (DRL) для проверки потоковых данных. REF предлагает библиотеку проверки, которая использует Drools под капотом. Его можно вызвать, выполнив вызов функции, что позволяет клиентам выполнять правила в приложении.
Сертификация данных
Еще одной проблемой, которую решила группа REF, была сертификация данных, перемещаемых из одного хранилища данных в другое. Мы создали инструмент Различия данных,дляавтоматизации процесса, который широко используется для проверки миграции между хранилищами данных. Например, он может сравнить устаревшее локальное хранилище данных с эквивалентным хранилищем в облаке.
Сама операция требует больших ресурсов в обеих системах, поэтому она выполняется только для сертификации новых сборок. Он сравнивает данные между хранилищами данных и проверяет, все ли записи из устаревшей системы находятся в новой системе. Он также помечает любые различия между системами, такие как повторяющиеся записи, несовпадающие столбцы и т. д. Data Diff выполняет сравнение и публикует результат, чтобы пользователь мог сравнить различия между данными в старом хранилище и в новом.
Архитектура
Наша среда выполнения правил (REF) предоставляет возможность настраивать правила и выполнять их. В качестве возможности уровня платформы от EDL REF предлагает платформу, инфраструктуру, API и пользовательский интерфейс. Это многопользовательская и общая служба, которую может использовать любой клиент или приложение. В настоящее время он поддерживает качество данных, преобразование данных, профилирование данных, обнаружение аномалий и правила согласования правила и достаточно прост, чтобы его могли использовать как технические, так и нетехнические пользователи.
На следующем рисунке показана архитектура REF:
Функционально REF включает в себя:
- Интерактивный прикладной уровень для добавления правил и управления ими
- Основной механизм правил, созданный на основе фреймворков и библиотек с открытым исходным кодом.
- Уровень отчетности с детализацией бизнес-вариантов, операционных и технологических вариантов использования.
