Очистка и проверка данных с помощью пакетной или потоковой обработки

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

Принудительное применение схемы в Azure Databricks

Delta Lake предоставляет семантику для принудительного применения проверок схемы и ограничений на запись, что обеспечивает гарантии качества данных для таблиц в лейкхаусе.

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

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

Ограничения таблицы

Ограничения могут принимать форму информационных первичных ключей и ограничений внешнего ключа или принудительных ограничений. См. ADD CONSTRAINT пункт.

Ограничения таблиц в Azure Databricks применяются или информационные.

Принудительные ограничения включают NOT NULL и CHECK ограничения.

Информационные ограничения включают первичный ключ и ограничения внешнего ключа.

Смотрите Ограничения в Azure Databricks.

Обработка значений NULL или отсутствующих значений

NOT NULL ограничение может быть применено к таблицам Delta. Она может быть включена только в существующей таблице, если существующие записи в столбце не имеют значения NULL, и запрещает вставлять новые записи со значениями NULL в таблицу.

Принудительное применение шаблонов

Регулярные выражения (regex) можно использовать для принудительного применения ожидаемых шаблонов в поле данных. Это особенно полезно при работе с текстовыми данными, которые должны соответствовать определенным форматам или шаблонам.

Чтобы применить шаблон с помощью регулярных выражений в SQL, можно использовать функции REGEXP или RLIKE. Эти функции позволяют сопоставить поле данных с указанным шаблоном регулярных выражений.

Ниже приведен пример использования ограничения с regex для принудительного применения шаблонов CHECK в SQL:

CREATE TABLE table_name (
  column_name STRING CHECK (column_name REGEXP '^[A-Za-z0-9]+$')
);

Принуждение к соблюдению значений

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

Чтобы применить ограничение диапазона значений, можно использовать CHECK ограничение в SQL. Ограничение CHECK позволяет определить условие, которое должно быть true для каждой строки в таблице.

Ниже приведен пример использования CHECK ограничения для принудительного применения диапазона значений в столбце:

CREATE TABLE table_name (
  column_name INT CHECK (column_name >= 0 AND column_name <= 100)
);

Определите и настройте ожидания с помощью декларативных конвейеров Lakeflow Spark.

Декларативные конвейеры Lakeflow Spark позволяют задавать ожидания при объявлении материализованных представлений или потоковых таблиц. Вы можете настроить ожидания для предупреждения вас о нарушениях, удаления записей, нарушающих требования, или завершения рабочих нагрузок на основе нарушений. См. Управление качеством данных с ожиданиями для потоков обработки.

Мониторинг данных

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

Приведение типов данных

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

Дополнительные сведения о поведении приведения типов см. в следующих статьях:

• функцияcast
• Правила типа данных SQL
• Соответствие ANSI в Databricks Runtime

Настраиваемая бизнес-логика

Фильтры и WHERE предложения можно использовать для определения пользовательской логики, которая изолирует плохие записи и предотвращает их распространение в нижестоящие таблицы. CASE WHEN ... OTHERWISE предложения позволяют определить условную логику для корректного применения бизнес-логики к записям, которые нарушают ожидания предсказуемыми способами.

DECLARE current_time = now()

INSERT INTO silver_table
  SELECT * FROM bronze_table
  WHERE event_timestamp <= current_time AND quantity >= 0;

INSERT INTO quarantine_table
  SELECT * FROM bronze_table
  WHERE event_timestamp > current_time OR quantity < 0;

Примечание.

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

Например, у вас может быть входящая система, которая не способна кодировать значения NULL, и значение заполнителя -1 используется для представления отсутствующих данных. Вместо написания пользовательской логики для всех зависимых запросов в Azure Databricks, чтобы игнорировать записи, содержащие -1, можно использовать оператор case when, чтобы динамически заменять эти записи в виде преобразования.

INSERT INTO silver_table
  SELECT
    * EXCEPT weight,
    CASE
      WHEN weight = -1 THEN NULL
      ELSE weight
    END AS weight
  FROM bronze_table;