Прием исторических данных в Azure Data Explorer

Распространенный сценарий при подключении к azure Data Explorer — прием исторических данных, которые иногда называют обратным заполнением. Этот процесс включает прием данных из существующей системы хранения в таблицу, которая представляет собой коллекцию экстентов.

Мы рекомендуем принимать исторические данные с помощью свойства creationTime ingestion , чтобы задать время создания экстентов в качестве времени создания данных. Использование времени создания в качестве критерия секционирования приема может стареть данные в соответствии с политиками кэша и хранения , а также сделать фильтры времени более эффективными.

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

• Все данные помещаются в кэш и остаются там в течение 30 дней, используя больше кэша, чем ожидалось.
• Старые данные не удаляются один день за раз; поэтому данные хранятся в кластере дольше, чем необходимо, и по истечении двух лет все удаляются одновременно.
• Данные, ранее сгруппированные по дате в исходной системе, теперь могут быть объединяемыми в той же степени, что приводит к неэффективным запросам.

Из этой статьи вы узнаете, как секционировать исторические данные:

• creationTime Использование свойства приема во время приема (рекомендуется)

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

  Примечание

  По умолчанию экстенты секционируются по времени создания (приема), и в большинстве случаев нет необходимости задавать политику секционирования данных.

• Использование политики секционирования после приема

  Если вы не можете использовать creationTime свойство приема, например при приеме данных с помощью соединителя Azure Cosmos DB , где вы не можете управлять временем создания, или если не удается реструктурировать структуру папок, вы можете повторно разделить таблицу после приема, чтобы добиться того же эффекта с помощью политики секционирования. Однако этот метод может потребовать некоторых проб и ошибок для оптимизации свойств политики и менее эффективен, чем использование creationTime свойства приема. Мы рекомендуем использовать этот метод только в том случае, creationTime если использовать свойство приема невозможно.

Предварительные требования

• Учетная запись Майкрософт или удостоверение пользователя Microsoft Entra. Подписка Azure не обязательна.
• Кластер и база данных Azure Data Explorer. Создайте кластер и базу данных.
• Учетная запись хранения.
• Для рекомендуемого метода использования creationTime свойства приема во время приема установите LightIngest.

Прием исторических данных

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

Во время приема (рекомендуется)

LightIngest может быть полезным для загрузки исторических данных из существующей системы хранения в Azure Data Explorer. Хотя вы можете создать собственную команду с помощью списка аргументов командной строки, в этой статье показано, как автоматически создать эту команду с помощью мастера приема. Помимо создания команды, вы можете использовать этот процесс для создания новой таблицы и создания сопоставления схемы. Это средство выводит сопоставление схемы из набора данных.

Назначение

1. В пользовательском веб-интерфейсе Azure Data Explorer в меню слева выберите Запрос.

2. Щелкните правой кнопкой мыши базу данных, в которой нужно принять данные, и выберите LightIngest.

   

   Откроется окно Прием данных с выбранной вкладкой Назначение . Поля кластера и базы данных заполняются автоматически.

3. Выберите целевую таблицу. Если вы хотите принять данные в новую таблицу, выберите Создать таблицу и введите имя таблицы.

   Примечание

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

   

4. Выберите Далее: Источник.

Source

1. В разделе Выбор источника выберите Добавить URL-адрес или Выбрать контейнер.

   • При добавлении URL-адреса в разделе Связь с источником укажите ключ учетной записи или URL-адрес SAS для контейнера. URL-адрес SAS можно создать вручную или автоматически.

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

     

   Примечание

   Максимальный размер принимаемого файла составляет 6 ГБ. Для приема мы советуем файлы размером от 100 МБ до 1 ГБ.

2. Выберите Дополнительные параметры , чтобы определить дополнительные параметры для процесса приема с помощью LightIngest.

   

3. В области Расширенная конфигурация определите параметры LightIngest в соответствии со следующей таблицей.

   

   Свойство	Описание
   Шаблон времени создания	Укажите значение, чтобы переопределить свойство времени приема для созданного экстента собственным шаблоном, например определять дату по структуре папок в контейнере. См. также шаблон времени создания.
   Шаблон имен больших двоичных объектов	Укажите шаблон, который будет использоваться для отбора файлов для приема. Приниматься будут все файлы в указанном контейнере, имена которых соответствуют шаблону имен больших двоичных объектов. Поддерживает подстановочные знаки. Рекомендуется заключать в двойные кавычки.
   Тег	Определите тег, который будет присваиваться принятым данным. Значением тега может быть любая строка.
   Ограничение на количество файлов	Укажите количество файлов для приема. Будут приниматься первые n файлов, соответствующих шаблону имен больших двоичных объектов, вплоть до указанного количества.
   Не дожидаться завершения приема	Если установлен этот параметр, BLOB-объект помещаются в очередь на прием без отслеживания процесса приема. Если он не установлен, LightIngest постоянно опрашивает состояние приема, пока процесс не будет завершен.
   Показывать только выбранные элементы	Файлы в контейнере будут отображаться, но не будут приниматься.

4. Нажмите кнопку Готово , чтобы вернуться на вкладку Источник .

   1. При необходимости выберите Фильтры файлов , чтобы отфильтровать данные для приема только файлов по определенному пути к папке или с определенным расширением файла.

      

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

   2. При необходимости в разделе Файл определения схемы можно указать используемый файл.

5. Выберите Далее: Схема, чтобы просмотреть и изменить конфигурацию столбца таблицы.

схема

Вкладка схемы предоставляет предварительный просмотр данных.

Чтобы создать команду LightIngest, выберите Далее: начать прием.

При необходимости

• Измените автоматически выводимый формат данных , выбрав нужный формат в раскрывающемся меню.
• Измените автоматически выводимое имя сопоставления. Вы можете использовать буквенно-цифровые символы и символы подчеркивания. Пробелы, специальные символы и дефисы не поддерживаются.
• При использовании существующей таблицы вы можете Сохранить текущую схему таблицы, если она соответствует выбранному формату.
• Выберите Средство просмотра команд , чтобы просмотреть и скопировать автоматические команды, созданные на основе входных данных.
• Изменение столбцов. В разделе Частичный предварительный просмотр данных выберите раскрывающееся меню столбца, чтобы изменить различные аспекты таблицы.

Изменения, которые вы можете внести в таблицу, зависят от следующих параметров:

• Тип таблицы — новая или существующая.
• Тип сопоставления — новое или существующее.

Тип таблицы	Тип сопоставления	Доступные корректировки
Новая таблица	Новое сопоставление	"Изменить тип данных", "Переименовать столбец", "Создать столбец", "Удалить столбец", "Обновить столбец", "Сортировать по возрастанию", "Сортировать по убыванию"
Существующая таблица	Новое сопоставление	"Создать столбец" (который можно переименовать и обновить либо выполнить изменение данных для него), "Обновить столбец", "Сортировать по возрастанию", "Сортировать по убыванию"
	Существующее сопоставление	"Сортировать по возрастанию", "Сортировать по убыванию"

Примечание

При добавлении нового столбца или обновлении существующего можно изменить преобразования сопоставления. Дополнительные сведения см. в разделе Преобразования сопоставлений.

Прием

1. После того как команды table, mapping и LightIngest будут отмечены зелеными проверка знаками, щелкните значок копирования в правом верхнем углу окна Команды Создано, чтобы скопировать созданную команду LightIngest.

   

   Примечание

   При необходимости можно скачать средство LightIngest, выбрав Скачать LightIngest.

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

После приема

Шаг 1. Подготовка к повторному секционирование

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

   .alter-merge table MyTable policy retention softdelete = 3650d recoverability = enabled
   

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

   .alter table MyTable policy caching hot = 3650d
   

   Важно!

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

Шаг 2. Инициализация повторного секционирования

1. Создайте политику секционирования, которая секционирует данные по столбцу с именем Timestamp. В следующем примере вы задали политику секционирования для таблицы MyTable на секционирование по столбцу с именем Timestamp.

   .alter table MyTable policy partitioning
   ```
   {
     "EffectiveDateTime" : "1970-01-01T00:00:00",
     "PartitionKeys": [
       {
         "ColumnName": "Timestamp",
         "Kind": "UniformRange",
         "Properties": {
           "Reference": "1970-01-01T00:00:00",
           "RangeSize": "1.00:00:00",
           "OverrideCreationTime": true
         }
       }
     ]
   }
   ```
   

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

   • Чтобы активировать повторное секционирование, свойству EffectiveDateTime необходимо задать дату, более раннюю, чем начало приема.
   • Параметр RangeSize имеет значение один день, чтобы данные были разбиты на сегменты по одному дню. Однако это значение следует задать в соответствии с данными. Например, если у вас меньше нескольких ГБ данных в день, рассмотрите возможность установки большего значения.
   • Для параметра OverrideCreationTime необходимо задать значение true , чтобы после повторного секционирования данных в контейнеры дня экстенты помечались этим днем как время создания.

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

   .alter table MyTable policy merge
   ```
   {
     "Lookback": {
       "Kind": "HotCache"
     }
   }
   ```
   

3. Отслеживайте ход повторного секционирования с помощью команды .show database extents partitioning statistics . В возвращенных результатах найдите таблицу, которую вы повторно секционировали, и отслеживайте столбец PartitionedRowPercentage . Если значение столбца PartitionedRowPercentage равно 100, повторное секционирование завершается.

Шаг 3. Очистка после повторного секционирования

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

1. Удалите политику секционирования.

   .delete table MyTable policy partitioning
   

2. Удалите политику слияния.

   .delete table MyTable policy merge
   

3. Удалите или задайте политику кэширования.

   // Remove the caching policy
   .delete table MyTable policy caching
   // OR set the caching policy to your desired value
   .alter table MyTable policy caching hot = 90d
   

4. Удалите или задайте политику хранения.

   // Remove the retention policy
   .delete table MyTable policy retention
   // OR set the retention policy to your desired value
   .alter-merge table MyTable policy retention softdelete = 30d recoverability = enabled
   

См. также

• Запрос данных в Azure Data Explorer