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

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

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

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

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

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

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

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

  Примечание.

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

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

  Если вы не можете использовать 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. Выберите Далее: Источник.

Исходный код

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

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

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

     

   Примечание.

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

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

   

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

   

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

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

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

      

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

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

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

Схема

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

Чтобы создать команду LightIngest, нажмите кнопку Next: Start Ingestion(Начать прием).

Необязательно.

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

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

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

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

Примечание.

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

Прием

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. В возвращаемых результатах найдите таблицу, которую выполняете повторное разделение, и отслеживайте столбец 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