Share via

Распространенные сценарии использования политик обновления таблиц

  • Статья

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

В этой статье вы узнаете о следующих распространенных сценариях:

Обогащение данных архитектуры Medallion

Политики обновления таблиц обеспечивают эффективный способ применения быстрых преобразований и совместимы с архитектурой medallion lakehouse в Fabric.

В архитектуре medallion при получении необработанных данных в целевую таблицу (бронзовый слой) можно использовать политику обновления для применения начальных преобразований и сохранения обогащенных выходных данных в таблице уровня серебра. Этот процесс может быть каскадным, когда данные из таблицы уровня "серебряный" могут активировать другую политику обновления для дальнейшего уточнения данных и гидратации таблицы золотого слоя.

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

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

Маршрутизация данных

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

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

Для обработки этого сценария используются три политики обновления. Политика обновления Get_Telemetry фильтрует сообщение телеметрии устройства, обогащает данные и сохраняет их в Device_Telemetry таблице. Аналогичным образом политика обновления Get_Alarms сохраняет данные в Device_Alarms таблице. Наконец, политика обновления Log_Error отправляет неизвестные сообщения в таблицу Error_Log , позволяя операторам обнаруживать сообщения неправильного формата или непредвиденное изменение схемы.

На следующей схеме показан пример с тремя политиками обновления.

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

Оптимизация моделей данных

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

Для выполнения запросов к таблицам в схеме star часто требуется объединение таблиц. Однако соединения таблиц могут привести к проблемам с производительностью, особенно при запросе больших объемов данных. Чтобы повысить производительность запросов, можно преобразовать модель в плоскую структуру, сохранив денормализованные данные во время приема.

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

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

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

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

См. также