Узнайте, как интегрировать перехватчики lakeFS для проверки данных о коммитах.
Один из наиболее частых вопросов, который мы получаем от существующих и потенциальных пользователей lakeFS: Может ли он работать с« Delta Tables ?»
Понятно, почему мы слышим этот вопрос, учитывая быстрое внедрение и расширенные возможности Delta, в том числе:
- Операции ACID на уровне таблицы
- Мутации данных, включая удаления и обновления «на месте»
- Расширенные возможности секционирования и индексации (с z-порядком)
Несмотря на то, что вышеуказанные функции являются мощными, комбинация дельта-таблиц в репозитории lakeFS еще более эффективна. Вместе с Delta Lake и lakeFS вы можете обеспечить дополнительные гарантии безопасности данных, упростив при этом операции.
Например:
- Операции ACID могут охватывать несколько таблиц Delta.
- Перехватчики CI / CD могут использоваться для проверки качества данных и даже обеспечения ссылочной целостности
- Таблицы могут быть клонированы без копирования, без дублирования данных.
LakeFS и Delta в действии
Чтобы доказать это, мы продемонстрируем, как гарантировать качество данных в дельта-таблице, используя ветви и перехватчики lakeFS в рабочем процессе для добавления новых данных.
Мы начнем с создания двух таблиц Delta, представляющих ссуды и платежи по ссудам на основе данных, хранящихся в репозитории lakeFS. Для этого мы будем использовать записную книжку Databricks, настроенную на использование lakeFS в качестве основного хранилища:
После выполнения вышеуказанных команд мы увидим следующие файлы метаданных Delta, добавленные в репозиторий. В lakeFS мы можем зафиксировать их в активной ветке, как показано ниже.
Большой! Теперь давайте создадим вторую записную книжку, содержащую набор правил проверки между двумя таблицами ссуд, которые будут служить ловушкой для проверки качества данных перед слиянием.
Как вы можете видеть выше, мы создали две проверки достоверности данных в виде SQL-запросов:
- Проверка целостности внешнего ключа credit_payments и первичных ключей ссуд
- Проверьте, чтобы платеж не превышал общую сумму кредита
Поскольку ветвление и слияние в lakeFS - это операции с метаданными с нулевым копированием, мы можем использовать отдельную ветвь от основной для загрузки новых файлов. Таким образом, новые данные добавляются изолированно и могут быть протестированы с помощью перехвата LakeFS для запуска проверки перед их объединением обратно в основную.
Первый шаг - создать ветку lakeFS, которую мы будем называть dev-reports. Мы можем создать его с помощью API, CLI или пользовательского интерфейса lakeFS:
В предлагаемой схеме ветвления у нас будет основная ветка и ветка dev-reports. Большинству потребителей следует читать из основной ветки, чтобы читать данные, которые гарантированно будут протестированы и проверены.
Потребитель, который нормально читает «грязные» данные, чтобы увидеть самые последние, может сделать это из ветки dev-reports:
Автоматизация развертывания данных с помощью перехватчиков lakeFS
Чтобы предоставить эту гарантию, мы настроим созданные нами тесты на автоматический запуск, прежде чем предоставлять новые данные потребителям.
Для этого давайте сначала создадим задание Databricks, которое выполняет созданный ранее блокнот проверки:
Мы можем определить lakeFS webhook, загрузив конфигурацию (показанную ниже) с префиксом _lakefs_actions / в основную ветку. Это автоматически выполнит это задание как хук перед слиянием на main:
Давайте сохраним этот файл и развернем следующий веб-перехватчик Flask для выполнения задания Databricks:
Для многоразовых веб-перехватчиков, которые вы могли бы просто развернуть и использовать, ознакомьтесь с примерами в репозитории lakeFS-hooks!
Теперь давайте добавим «плохую» запись и вставим ее в нашу таблицу credit_payments - эта запись относится к несуществующей ссуде.
Давайте попробуем зафиксировать и объединить это изменение с нашей основной веткой:
Ура! Перехватчик pre-merge для main завершился неудачно, и потребители этой ветви никогда не увидят эту запись в наборе данных.
Заключение
При использовании lakeFS вместе с Delta мы можем безопасно вносить изменения в данные и схему, обеспечивая надежные гарантии в отношении данных, содержащихся внутри.
В этой архитектуре каждая технология отвечает за то, что она была разработана: Delta Lake для масштабируемых, удобных для транзакций таблиц и lakeFS для управления жизненным циклом данных.
Хотите узнать больше?
Чтобы узнать больше об lakeFS и его преимуществах в архитектурах озера данных, загляните в Репозиторий Github lakeFS и скажите Привет в группе Slack!
Первоначально опубликовано Озом Кацем в блоге lakeFS.
