Поделиться через

Общие сведения о хранилище для семантических моделей Direct Lake

  • Статья

В этой статье приведены основные понятия Direct Lake Storage. В нем описываются таблицы Delta и файлы Parquet. В нем также описывается, как оптимизировать разностные таблицы для семантических моделей Direct Lake и как их можно поддерживать, чтобы обеспечить надежную, быструю производительность запросов.

Разностные таблицы

Разностные таблицы существуют в OneLake. Они упорядочивают данные на основе файлов в строки и столбцы и доступны вычислительным модулям Microsoft Fabric, таким как записные книжки, Kusto и lakehouse и хранилище. Вы можете запрашивать разностные таблицы с помощью выражений анализа данных (DAX), многомерных выражений (МНОГОмерных выражений), T-SQL (Transact-SQL), Spark SQL и даже Python.

Примечание.

Delta (или Delta Lake) — это формат хранилища с открытым кодом. Это означает, что Структура также может запрашивать разностные таблицы, созданные другими инструментами и поставщиками.

Разностные таблицы хранят данные в файлах Parquet, которые обычно хранятся в лейкхаусе, который используется для загрузки данных семантической моделью Direct Lake. Однако файлы Parquet также могут храниться внешне. На внешние файлы Parquet можно ссылаться с помощью ярлыка OneLake, указывающего на определенное расположение хранилища, например Azure Data Lake Storage (ADLS) 2-го поколения, учетных записей хранения Amazon S3 или Dataverse. В почти всех случаях вычислительные подсистемы обращаются к файлам Parquet, запрашивая таблицы Delta. Однако обычно семантические модели Direct Lake загружают данные столбцов непосредственно из оптимизированных файлов Parquet в OneLake с помощью процесса, известного как транскодирование.

Управление версиями данных

Разностные таблицы состоят из одного или нескольких файлов Parquet. Эти файлы сопровождаются набором файлов ссылок на основе JSON, которые отслеживают порядок и характер каждого файла Parquet, связанного с таблицей Delta.

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

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

ProductID StockOnHand
A 1
Б 2
C 3

Данные таблицы Delta хранятся в одном файле Parquet, который содержит все данные, и есть один файл ссылки, содержащий метаданные о том, когда данные были вставлены (добавлены).

  • Файл Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Файл ссылки 1:
    • Содержит метку времени при Parquet file 1 создании и записывает, что данные были добавлены.

Операции вставки

Рассмотрим, что происходит при выполнении операции вставки: новая строка для продукта C с запасом по 4 значению вставки вставляется. Эти операции приводят к созданию нового файла Parquet и файла ссылки, поэтому теперь есть два файла Parquet и два файла ссылок.

  • Файл Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Файл Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Файл ссылки 1:
    • Содержит метку времени при Parquet file 1 создании и записывает, что данные были добавлены.
  • Файл ссылки 2:
    • Содержит метку времени при Parquet file 2 создании и записывает, что данные были добавлены.

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

ProductID StockOnHand
A 1
Б 2
C 3
D 4

Каждая последующая операция вставки создает новые файлы Parquet и файлы ссылок. Это означает, что количество файлов Parquet и файлов ссылок увеличивается при каждой операции вставки.

Операции обновления

Теперь рассмотрим, что происходит при выполнении операции обновления: строка для продукта D имеет свои запасы по стоимости, измененной на 10. Эти операции приводят к созданию нового файла Parquet и файла ссылок, поэтому теперь есть три файла Parquet и три файла ссылок.

  • Файл Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Файл Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Файл Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Файл ссылки 1:
    • Содержит метку времени при Parquet file 1 создании и записывает, что данные были добавлены.
  • Файл ссылки 2:
    • Содержит метку времени при Parquet file 2 создании и записывает, что данные были добавлены.
  • Файл ссылки 3:
    • Содержит метку времени при Parquet file 3 создании и записывает обновленные данные.

На этом этапе запрос таблицы Delta возвращает следующий результат.

ProductID StockOnHand
A 1
Б 2
C 10
D 4

Данные для продукта C теперь существуют в нескольких файлах Parquet. Однако запросы к таблице Delta объединяют файлы ссылок, чтобы определить, какие данные следует использовать для предоставления правильного результата.

Операции удаления

Теперь рассмотрим, что происходит при выполнении операции удаления: строка для продукта B удаляется. Эта операция приводит к новому файлу Parquet и файлу ссылки, поэтому теперь есть четыре файла Parquet и четыре файла ссылок.

  • Файл Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Файл Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Файл Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Файл Parquet 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • Файл ссылки 1:
    • Содержит метку времени при Parquet file 1 создании и записывает, что данные были добавлены.
  • Файл ссылки 2:
    • Содержит метку времени при Parquet file 2 создании и записывает, что данные были добавлены.
  • Файл ссылки 3:
    • Содержит метку времени при Parquet file 3 создании и записывает обновленные данные.
  • Файл ссылки 4:
    • Содержит метку времени при Parquet file 4 создании и записывает данные, которые были удалены.

Обратите внимание, что Parquet file 4 больше не содержит данные для продукта B, но содержит данные для всех остальных строк в таблице.

На этом этапе запрос таблицы Delta возвращает следующий результат.

ProductID StockOnHand
A 1
C 10
D 4

Примечание.

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

Внимание

В зависимости от того, как вы определяете таблицы Delta и частоту операций изменения данных, это может привести к множеству файлов Parquet. Имейте в виду, что каждая лицензия емкости Fabric имеет защищенную границу. Если количество файлов Parquet для таблицы Delta превышает ограничение номера SKU, запросы возвращаются в DirectQuery, что может привести к снижению производительности запросов.

Сведения об управлении количеством файлов Parquet см. в разделе "Обслуживание таблиц Delta" далее в этой статье.

Переход по времени в Delta

Ссылки на файлы позволяют запрашивать данные по истечении более ранней точки во времени. Эта возможность называется разностным путешествием по времени. Более ранний момент времени может быть меткой времени или версией.

Рассмотрим следующие примеры запросов.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Совет

Вы также можете запросить таблицу с помощью @ сокращенного синтаксиса, чтобы указать метку времени или версию в составе имени таблицы. Метка времени должна быть указана в формате yyyyMMddHHmmssSSS. Вы можете указать версию после @, добавив к версии v.

Ниже приведены предыдущие примеры запросов, перезаписываемые с помощью краткого синтаксиса.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Внимание

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

Обрамление

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

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

Внимание

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

Дополнительные сведения об обрамления см . в обзоре Direct Lake.

Секционирование таблиц в хранилище данных SQL

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

Рассмотрим таблицу Delta, которая содержит миллиард строк данных о продажах в течение двухлетнего периода. Хотя можно хранить все данные в одном наборе файлов Parquet, для этого тома данных это не оптимально для операций чтения и записи. Вместо этого производительность можно улучшить, распространяя миллиарды строк данных в нескольких рядах файлов Parquet.

Ключ секции должен быть определен при настройке секционирования таблиц. Ключ секции определяет, какие строки будут храниться в каких рядах. Для таблиц Delta ключ секции можно определить на основе отдельных значений указанного столбца (или столбцов), таких как столбец месяца или года таблицы дат. В этом случае два года данных будут распределены между 24 секциями (2 года x 12 месяцев).

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

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

Однако запросы, которые не фильтруют ключ секции, могут не всегда выполняться лучше. Это может быть так, когда таблица Delta хранит все данные в одном большом наборе файлов Parquet и есть фрагментация файлов или групп строк. Хотя можно параллелизировать извлечение данных из нескольких файлов Parquet на нескольких узлах кластера, многие небольшие файлы Parquet могут негативно повлиять на производительность операций ввода-вывода файлов и, следовательно, на производительность запросов. По этой причине рекомендуется избежать секционирования разностных таблиц в большинстве случаев, если операции записи или извлечения, преобразования и загрузки (ETL) не будут пользоваться им.

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

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

Внимание

Если основная цель таблицы Delta — служить источником данных для семантических моделей (и во-вторых, другими рабочими нагрузками запросов), обычно лучше избегать секционирования в предпочтениях оптимизации нагрузки столбцов в память.

Для семантических моделей Direct Lake или конечной точки аналитики SQL оптимальным способом оптимизации секций таблиц Delta является автоматическое управление файлами Parquet для каждой версии таблицы Delta. Выход из управления в Fabric должен привести к высокой производительности запросов путем параллелизации, однако это может не обязательно обеспечить лучшую производительность записи.

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

Предупреждение

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

Файлы Parquet

Базовое хранилище для таблицы Delta — это один или несколько файлов Parquet. Формат файла Parquet обычно используется для приложений для записи однократно, многочитанных приложений. Новые файлы Parquet создаются каждый раз, когда данные в таблице Delta изменяются, независимо от того, выполняется ли операция вставки, обновления или удаления.

Примечание.

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

Пример файла Parquet

Внутренний формат файла Parquet отличается от других распространенных форматов хранения данных, таких как CSV, TSV, XMLA и JSON. Эти форматы упорядочивают данные по строкам, а Parquet упорядочивает данные по столбцам. Кроме того, формат файла Parquet отличается от этих форматов, так как он упорядочивает строки данных в одну или несколько групп строк.

Внутренняя структура данных семантической модели Power BI основана на столбцах, что означает, что файлы Parquet используют много общего с Power BI. Это сходство означает, что семантическая модель Direct Lake может эффективно загружать данные из файлов Parquet непосредственно в память. На самом деле очень большие объемы данных могут загружаться в секундах. Сравните эту возможность с обновлением семантической модели импорта, которая должна извлекать блоки или исходные данные, а затем обрабатывать, кодировать, хранить и загружать их в память. Операция обновления семантической модели импорта также может использовать значительные объемы вычислительных ресурсов (память и ЦП) и занять значительное время. Однако при использовании разностных таблиц большая часть усилий по подготовке данных, подходящих для прямой загрузки в семантической модели, происходит при создании файла Parquet.

Как файлы Parquet хранят данные

Рассмотрим следующий пример набора данных.

Дата ProductID StockOnHand
2024-09-16 а 10
2024-09-16 Б 11
2024-09-17 а 13
…

При хранении в формате файла Parquet этот набор данных может выглядеть следующим образом.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

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

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Если для семантической модели Direct Lake требуются данные для вычисления суммы столбца StockOnHand , сгруппированного ProductIDпо, требуется только словарь и данные, связанные с двумя столбцами. В больших файлах, содержащих много столбцов, можно пропустить значительные части файла Parquet, чтобы ускорить процесс чтения.

Примечание.

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

V-Order

Fabric поддерживает дополнительную оптимизацию с именем V-Order. V-Order — это оптимизация времени записи в формате файла Parquet. После применения V-Order он приводит к меньшему и более быстрому чтению файла. Эта оптимизация особенно актуальна для семантической модели Direct Lake, так как она подготавливает данные для быстрой загрузки в память, поэтому это делает меньше требований к ресурсам емкости. Это также приводит к повышению производительности запросов, так как требуется сканировать меньше памяти.

Разностные таблицы, созданные и загруженные элементами Fabric, такими как конвейеры данных, потоки данных и записные книжки, автоматически применяют V-Order. Однако файлы Parquet, отправленные в Lakehouse Fabric или на которые ссылается ярлык, могут не применять эту оптимизацию. Хотя неоптимизированные файлы Parquet по-прежнему могут быть прочитаны, производительность чтения, скорее всего, не будет так быстро, как эквивалентный файл Parquet, примененный v-Order.

Примечание.

Файлы Parquet с примененными V-Order по-прежнему соответствуют формату файлов Parquet с открытым исходным кодом. Поэтому их можно читать с помощью средств, отличных от Fabric.

Дополнительные сведения см. в разделе "Оптимизация таблицы Delta Lake" и "V-Order".

Оптимизация разностной таблицы

В этом разделе описываются различные разделы по оптимизации таблиц Delta для семантических моделей.

Объем данных

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

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

Кроме того, убедитесь, что V-Order применяется, так как он приводит к меньшему и более быстрому чтению файла.

Тип данных столбца

Старайтесь уменьшить кратность (число уникальных значений) в каждом столбце каждой таблицы Delta. Это связано с тем, что все столбцы сжимаются и хранятся с помощью хэш-кодировки. Для хэш-кодирования требуется оптимизация V-Order, чтобы назначить числовый идентификатор каждому уникальному значению, содержаму в столбце. Это числовые идентификаторы, которые хранятся, требуя хэш-поиска во время хранения и запроса.

Если вы используете приблизительные числовые типы данных (например , float и real), рассмотрите возможность округления значений и более низкой точности.

Ненужные столбцы

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

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

Так как семантические модели Direct Lake не поддерживают вычисляемые столбцы, следует материализовать такие столбцы в таблицах Delta. Обратите внимание, что этот подход к проектированию является анти-шаблоном для семантических моделей импорта и DirectQuery. Например, если у вас есть FirstName и LastName столбцы, и вам нужен FullName столбец, материализуйте значения этого столбца при вставке строк в таблицу Delta.

Рассмотрим, что некоторые семантические сводные данные модели могут зависеть от нескольких столбцов. Например, чтобы вычислить продажи, мера в модели суммирует продукт из двух столбцов: Quantity и Price. Если ни один из этих столбцов не используется независимо, было бы эффективнее материализовать вычисление продаж в виде одного столбца, чем хранить значения компонентов в отдельных столбцах.

Размер группы строк

Во внутреннем режиме файл Parquet упорядочивает строки данных в несколько групп строк в каждом файле. Например, файл Parquet, содержащий 30 000 строк, может объединить их в три группы строк, каждая из которых содержит 10 000 строк.

Количество строк в группе строк влияет на то, как быстро Direct Lake может считывать данные. Более высокое количество групп строк с меньшим количеством строк, скорее всего, негативно влияет на загрузку данных столбцов в семантику модели из-за чрезмерного ввода-вывода.

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

Внимание

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

Обслуживание таблиц Delta

С течением времени при выполнении операций записи версии таблицы Delta накапливаются. В конечном итоге вы можете достичь точки, когда негативное влияние на производительность чтения становится заметным. Хуже, если количество файлов Parquet на таблицу или группы строк на таблицу или строки на таблицу превышает сторожевые ограничения для емкости, запросы будут возвращаться к DirectQuery, что может привести к снижению производительности запросов. Поэтому важно регулярно поддерживать разностные таблицы.

OPTIMIZE

Вы можете использовать OPTIMIZE для оптимизации таблицы Delta для объединения небольших файлов в более крупные. Вы также можете задать WHERE предложение для целевого назначения только отфильтрованного подмножества строк, которые соответствуют заданному предикату секции. Поддерживаются только фильтры, включающие ключи секций. Команда OPTIMIZE также может применить V-Order для сжатия и перезаписи файлов Parquet.

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

Команда VACUUM

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

Внимание

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

REORG TABLE

С помощью REORG TABLE можно реорганизовать таблицу Delta, перезаписав файлы для очистки обратимо удаленных данных, например при удалении столбца с помощью ALTER TABLE DROP COLUMN.

Автоматизация обслуживания таблиц

Для автоматизации операций обслуживания таблиц можно использовать API Lakehouse. Дополнительные сведения см. в статье "Управление Lakehouse с помощью REST API Microsoft Fabric".

Совет

Вы также можете использовать функцию обслуживания таблиц Lakehouse на портале Fabric, чтобы упростить управление таблицами Delta.

Связанный контент