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

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

  • Статья

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

Дельта-таблицы

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

Заметка

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

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

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

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

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

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

ProductID Остаток на складе
A 1
B 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
    • ОстатокНаСкладе: 4
  • Файл ссылки 1:
    • Содержит метку времени создания Parquet file 1 и фиксирует, что данные были добавлены.
  • Файл ссылки 2:
    • Содержит метку времени при создании Parquet file 2 и фиксирует, что данные были добавлены.

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

ProductID StockOnHand
A 1
B 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
    • ЗапасНаСкладе: 4
  • Файл Parquet 3:
    • ProductID: C
    • Остаток на складе: 10
  • Файл ссылки 1:
    • Содержит метку времени момента создания Parquet file 1 и фиксирует добавление данных.
  • Файл ссылки 2:
    • Содержит метку времени, когда было создано Parquet file 2, и информацию о том, что данные были добавлены.
  • Файл ссылки 3:
    • Содержит метку времени, в момент создания Parquet file 3, и фиксирует, что данные были обновлены.

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

ProductID StockOnHand
A 1
B 2
C 10
D 4

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

Удаление операций

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

  • Паркетный файл 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Файл Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Файл Parquet 3:
    • ProductID: C
    • Запасы на складе: 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 Товары в Наличии
A 1
C 10
D 4

Заметка

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

Важный

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

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

Временное перемещение Дельта

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

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

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

Совет (if "Tip" refers to advice) / Чаевые (if "Tip" refers to gratuity)

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

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

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

Важный

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

Обрамление

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

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

Важный

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

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

Секционирование таблиц

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

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

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

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

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

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

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

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

Важный

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

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

Если необходимо оптимизировать операции записи, рассмотрите возможность использования разделов для оптимизации операций записи в таблицы Delta на основе ключа раздела. Однако помните, что при чрезмерном секционировании таблицы 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 непосредственно в память. На самом деле очень большие объемы данных могут загружаться в секундах. Сравните эту возможность с обновлением семантической модели импорта, которая должна извлекать блоки или исходные данные, а затем обрабатывать, кодировать, хранить и загружать их в память. Операция обновления семантической модели импорта также может использовать значительные объемы вычислительных ресурсов (память и ЦП) и занять значительное время. Однако в случае использования таблиц Delta, большая часть усилий по подготовке данных, подходящих для прямой загрузки в семантическую модель, происходит на этапе генерации файла Parquet.

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

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

Дата ProductID StockOnHand
16.09.2024 A 10
16.09.2024 B 11
17.09.2024 А 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, так как она подготавливает данные для быстрой загрузки в память, поэтому это делает меньше требований к ресурсам емкости. Это также приводит к повышению производительности запросов, так как требуется сканировать меньше памяти.

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

Заметка

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

Для получения дополнительной информации смотрите раздел об оптимизации таблицы Delta Lake и раздело V-Order.

Оптимизация Дельта-таблицы

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

Объём данных

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

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

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

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

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

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

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

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

ОПТИМИЗИРОВАТЬ

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

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

ВАКУУМ

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

Важный

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

ТАБЛИЦА REORG

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

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

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

Совет

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

Связанное содержимое