Предоставление данных Lakehouse с синхронизированными таблицами

Синхронизированные таблицы позволяют обслуживать данные озерохранилища с помощью Lakebase Postgres. Таблицы каталога Unity синхронизируются с Postgres, чтобы приложения могли запрашивать данные lakehouse непосредственно с низкой задержкой. Этот процесс обычно называется обратным ETL. Lakehouse оптимизирован для аналитики и обогащения, а Lakebase предназначен для операционных рабочих нагрузок, требующих быстрого поиска запросов и согласованности транзакций.

Схема архитектуры, показывающая поток данных из Lakehouse в Lakebase в приложения

Что такое синхронизированные таблицы?

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

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

Синхронизированные таблицы поддерживают следующие типы источников каталога Unity:

Управляемые и внешние таблицы Delta
Управляемые и внешние таблицы Iceberg
Представления и материализованные представления

Принцип работы

Синхронизированные таблицы Databricks создают управляемую копию данных каталога Unity в Lakebase. При создании синхронизированной таблицы вы получите следующее:

Синхронизированная таблица в каталоге Unity, ссылающаяся на конвейер синхронизации
Таблица Postgres в Lakebase (доступная только для чтения, запрашиваемая приложениями)

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

Например, можно синхронизировать золотые таблицы, встроенные функции или выходные данные машинного обучения в analytics.gold.user_profiles новую синхронизированную таблицу analytics.gold.user_profiles_synced. В Postgres имя схемы каталога Unity становится именем схемы Postgres, поэтому это выглядит следующим образом gold.user_profiles_synced:

SELECT * FROM gold.user_profiles_synced WHERE user_id = 12345;

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

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

Хотя можно изменить синхронизированную таблицу непосредственно в Postgres, Azure Databricks строго рекомендует выполнять только запросы на чтение для защиты целостности данных с помощью источника. Поддерживаемые операции с синхронизированными таблицами см. в разделе "Операции, разрешенные для синхронизированных таблиц в Postgres".

Конвейеры синхронизации используют управляемые конвейеры Lakeflow для непрерывного обновления синхронизированной таблицы каталога Unity и таблицы Postgres с изменениями из исходной таблицы. Каждая синхронизация может использовать до 16 подключений к базе данных Lakebase.

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

Ускоренная начальная синхронизация

LTAP Direct Writes — это бета-версия архитектуры LTAP , которая сокращает время начальных загрузок и полного обновления. Данные загружаются непосредственно в уровень хранения, лежащий в основе вашей ветки Lakebase, вместо того чтобы направлять операцию массовой записи через активную вычислительную конечную точку. В результате крупные загрузки выполняются быстрее и не создают нагрузку запросами на конечную точку во время выполнения.

Возможность прямой записи LTAP ускоряет начальную нагрузку для каждого режима синхронизации. Каждая синхронизированная таблица начинается с загрузки полной копии исходного кода, и эта первая загрузка использует LTAP Direct Writes, независимо от того, выбираете ли вы Snapshot, Triggered или Continuous режим. Он также ускоряет полное обновление, включая повторяющиеся полные загрузки, которые запускаются в режиме Snapshot при каждой последующей синхронизации.

Замечание

LTAP Direct Writes не ограничивается режимом Snapshot . Каждый режим синхронизации получает ускоренную начальную нагрузку. Для режима Snapshot также выполняется ускоренное полное обновление при каждой последующей синхронизации, а в режимах Triggered и Continuous последующие обновления применяются инкрементально через Change Data Feed, а не в виде пакетных загрузок.

LTAP Direct Writes находится в бета-версии и требует проекта Lakebase с Postgres 17. Для использования администратор рабочего пространства включает предпросмотр LTAP Direct Writes на странице предпросмотра в настройках рабочего пространства.

На Azure LTAP Direct Writes доступен во всех регионах, кроме Восточной части США, Восточной части США 2, Западной Европы и Западной части США 2.

Режимы синхронизации

Выберите правильный режим синхронизации в зависимости от потребностей приложения:

Режим	Описание	Когда использовать	Производительность
Моментальный снимок	Однократная копия всех данных	Источник изменяет >10% строк за цикл	10x более эффективно при изменении >10% исходных данных
Запущено	Запланированные обновления, которые выполняются по требованию или через интервалы	Исходные строки изменяются по известному графику. Вставки, обновления и удаления распространяются каждый раз при обновлении.	Хороший баланс затрат и задержки. Дорого, если запускать с интервалами в <5 минут
Непрерывный	Потоковая передача в режиме реального времени с задержкой в секундах	Изменения должны отображаться в Lakebase практически в режиме реального времени	Низкая задержка, самая высокая стоимость. Минимальные 15-секундные интервалы

Требование источника зависит от режима синхронизации:

Snapshot копирует все данные при каждой синхронизации, поэтому источнику достаточно поддерживать SELECT *.
Triggered и Continuous применяют изменения на уровне строки постепенно, поэтому источник должен предоставлять поток данных изменений. Включите ленту данных об изменениях при записи в источнике или используйте автоматическую ленту данных об изменениях. Если триггерный или непрерывный источник не имеет потока данных изменений, интерфейс показывает предупреждение с точной ALTER TABLE командой для запуска.

Автоматическая лента данных об изменениях (общедоступная предварительная версия) вычисляет изменения на уровне строк во время чтения вместо того, чтобы требовать наличия ленты данных об изменениях в источнике на этапе записи. Это позволяет синхронизировать больше типов источников, включая таблицы Apache Iceberg и материализованные представления, в режиме Triggered или Continuous. Для типов исходных кодов, которые поддерживает Автоматический поток данных изменений, см. документацию Автоматического потока данных изменений .

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

Включите предварительную версию. Администратор рабочего пространства включает автоматический предпросмотр ленты изменений данных на странице предпросмотра в настройках рабочего пространства.
Установите канал конвейера на предварительный просмотр. Когда вы создаёте синхронизированную таблицу, установите канал конвейера на PREVIEW. Эта опция в настоящее время доступна только через API:
```
{
  "spec": {
    "new_pipeline_spec": {
      "pipeline_channel": "PREVIEW"
    }
  }
}
```

Примеры вариантов использования

Синхронизированные таблицы можно использовать для таких вариантов использования, как:

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

Создание синхронизированной таблицы

Необходимые условия

Тебе нужно:

Рабочая область Databricks с активированной функцией Lakebase.
Проект Lakebase (см. раздел "Создание проекта").
Таблица каталога Unity для синхронизации.
Разрешения на создание синхронизированных таблиц. Вам потребуется USE_SCHEMA и CREATE_TABLE для любой используемой схемы.

Для триггерных или непрерывных режимов источник должен предоставлять поток данных об изменениях. Либо включите подачу данных об изменениях при записи для подходящей исходной таблицы Delta, либо используйте Автоматическую подачу данных об изменениях для таких источников, как таблицы Apache Iceberg и материализованные представления. Автоматический поток данных изменений находится в публичном предварительном просмотре и требует дополнительной настройки, описанной в режимах синхронизации.

Чтобы включить поток изменений данных при записи для исходной таблицы Delta, запустите:

ALTER TABLE your_catalog.your_schema.your_table
SET TBLPROPERTIES (delta.enableChangeDataFeed = true)

Сведения о планировании емкости и совместимости типов данных см. в разделе "Типы данных" и "Планирование емкости".

Пользовательский интерфейс

Перейдите в каталог на боковой панели рабочей области и выберите таблицу каталога Unity, которую вы хотите синхронизировать.
Щелкните "Создать>синхронизированную таблицу " в представлении сведений о таблице.
В диалоговом окне создания синхронизированной таблицы :

Списки каталогов и схем включают только схемы каталога Unity, в которых текущий пользователь имеет USE_SCHEMAи CREATE_TABLE привилегии. Если вы не видите схему, которую вы ожидаете, подтвердите разрешения с помощью администратора каталога.
1. Имя таблицы: введите имя синхронизированной таблицы (она создается в том же каталоге и схеме, что и исходная таблица). При этом создается синхронизированная таблица каталога Unity и таблица Postgres, которые можно запрашивать.
2. Тип базы данных: выберите Lakebase Serverless (автомасштабирование).
3. Режим синхронизации: выберите моментальный снимок, триггер или непрерывный в зависимости от ваших потребностей (см. режимы синхронизации выше).
4. Настройте выбор проекта, ветви и базы данных.
5. Проверьте правильность первичного ключа (обычно автоматическое обнаружение).
  
  Это важно
  
  Столбцы в первичном ключе не могут принимать значение NULL в синхронизированной таблице. Строки со значениями NULL в столбцах первичного ключа исключаются из синхронизации.
6. (Необязательно) Если две строки в исходной таблице могут иметь один и тот же первичный ключ, выберите ключ временных рядов, чтобы настроить дедупликацию. При указании ключа таймерии синхронизированная таблица содержит только строку с последним значением ключа таймерии для каждого первичного ключа. Режим сбоя без ключа таймерии см. в разделе "Повторяющиеся ключи".
Если вы выбрали триггерный или непрерывный режим и еще не включили канал изменений данных, вы увидите предупреждение с точной командой для запуска. Вопросы о совместимости типов данных см. в разделе "Типы данных" и "Совместимость".

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

интерфейс командной строки (CLI)

databricks postgres create-synced-table my-catalog.sales.orders \
  --json '{
    "spec": {
      "source_table_full_name": "main.sales.orders",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["order_id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true
    }
  }'

Позиционный SYNCED_TABLE_ID аргумент использует формат catalog.schema.table. В Postgres таблица {table} создается в схеме {schema}, в базе данных, которую вы задаете с помощью postgres_database (здесь, mydb). Команда ожидает завершения операции по умолчанию. Все доступные параметры см. в разделе databricks postgres create-synced-table.

пакет SDK Python

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.postgres import (
    SyncedTable,
    SyncedTableSyncedTableSpec,
    SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy,
)

w = WorkspaceClient()

synced_table = w.postgres.create_synced_table(
    synced_table=SyncedTable(spec=SyncedTableSyncedTableSpec(
        source_table_full_name="main.sales.orders",
        branch="projects/my-project/branches/production",
        primary_key_columns=["order_id"],
        scheduling_policy=SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy.SNAPSHOT,
        postgres_database="mydb",
        create_database_objects_if_missing=True,
    )),
    synced_table_id="my-catalog.sales.orders",
).wait()

print(f"Synced table created: {synced_table.name}")

Объект synced_table_id использует формат catalog.schema.table и становится именем синхронизированной таблицы в Unity Catalog. В Postgres таблица {table} создается в схеме {schema}, в базе данных, которую вы задаете с помощью postgres_database (здесь, mydb).

пакет SDK для Java

import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.service.postgres.*;
import java.util.List;

WorkspaceClient w = new WorkspaceClient();

SyncedTable syncedTable = w.postgres().createSyncedTable(
    new CreateSyncedTableRequest()
        .setSyncedTableId("my-catalog.sales.orders")
        .setSyncedTable(new SyncedTable()
            .setSpec(new SyncedTableSyncedTableSpec()
                .setSourceTableFullName("main.sales.orders")
                .setBranch("projects/my-project/branches/production")
                .setPrimaryKeyColumns(List.of("order_id"))
                .setSchedulingPolicy(SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy.SNAPSHOT)
                .setPostgresDatabase("mydb")
                .setCreateDatabaseObjectsIfMissing(true))))
    .waitForCompletion();

System.out.println("Synced table created: " + syncedTable.getName());

завиток

curl -X POST "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables?synced_table_id=my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "source_table_full_name": "main.sales.orders",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["order_id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true
    }
  }'

Это возвращает длительную операцию. Проверяйте возвращаемое name поле до done: true. См. долговременные операции. Сведения о настройке проверки подлинности см. в разделе "Проверка подлинности".

Планирование или активация последующих синхронизаций

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

Задача конвейера синхронизации таблиц базы данных

Задача конвейера синхронизации таблиц базы данных в заданиях Lakeflow выполняет конвейер синхронизированной таблицы в качестве шага рабочего процесса. Настройте задание с помощью триггера обновления таблицы или расписания.

Триггер обновлений исходной таблицы

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

На боковой панели щелкните "Рабочие процессы".
Нажмите кнопку "Создать задание " или откройте существующее задание.
На вкладке "Задачи " нажмите кнопку +Добавить другой тип задачи.
В разделе "Прием и преобразование" выберите конвейер синхронизации таблиц базы данных.
В поле конвейера выберите конвейер, связанный с синхронизированной таблицей.
В разделе "Расписания и триггеры" нажмите кнопку "Добавить триггер".
Выберите "Обновление таблицы " в качестве типа триггера.
В разделе "Таблицы" выберите исходную таблицу каталога Unity для мониторинга.
Нажмите кнопку Сохранить.

Триггер, действующий по расписанию

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

Выполните действия 1–5 выше, чтобы добавить задачу конвейера синхронизации таблиц базы данных в задание.
В разделе "Расписания и триггеры" нажмите кнопку "Добавить триггер".
Выберите "Запланированный " в качестве типа триггера.
Задайте расписание и часовой пояс cron, а затем нажмите кнопку "Сохранить".

Проверка состояния синхронизации

Чтобы проверить текущее состояние и время последней синхронизации синхронизированной таблицы:

Пользовательский интерфейс

В каталоге перейдите к синхронизированной таблице и перейдите на вкладку "Обзор ". В нем отображается текущее состояние синхронизации, состояние конвейера и метка времени последней синхронизации.

пакет SDK Python

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

table = w.postgres.get_synced_table("synced_tables/my-catalog.sales.orders")
print(f"State: {table.status.detailed_state}")
print(f"Last sync: {table.status.last_sync_time}")
print(f"Message: {table.status.message}")

пакет SDK для Java

import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.service.postgres.SyncedTable;

WorkspaceClient w = new WorkspaceClient();

SyncedTable table = w.postgres().getSyncedTable("synced_tables/my-catalog.sales.orders");
System.out.println("State: " + table.getStatus().getDetailedState());
System.out.println("Last sync: " + table.getStatus().getLastSyncTime());
System.out.println("Message: " + table.getStatus().getMessage());

завиток

curl "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables/my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Типы данных и совместимость

Типы данных каталога Unity сопоставляются с типами Postgres при создании синхронизированных таблиц. Сложные типы (ARRAY, MAP, STRUCT) хранятся в формате JSONB в Postgres.

Тип исходного столбца	Тип столбца Postgres
БИГИНТ	БИГИНТ
BINARY	BYTEA
BOOLEAN	BOOLEAN
DATE	DATE
DECIMAL(p,s)	ЧИСЛОВОЙ
ДВОЙНОЙ	ДВОЙНАЯ ТОЧНОСТЬ
FLOAT	РЕАЛЬНЫЙ
INT	ЦЕЛОЕ ЧИСЛО
INTERVAL	INTERVAL
СМОЛЛИНТ	СМОЛЛИНТ
СТРУНА	ТЕКСТ
TIMESTAMP	Метка времени с часовым поясом
TIMESTAMP_NTZ	МЕТКА ВРЕМЕНИ БЕЗ ЧАСОВОГО ПОЯСА
TINYINT	СМОЛЛИНТ
ARRAY<типЭлемента	JSONB
MAP<тип_ключа,тип_значения>	JSONB
Имя поля STRUCT<:fieldType[, ...]>	JSONB

Замечание

Типы GEOGRAPHY, GEOMETRY, VARIANT и OBJECT не поддерживаются.

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

При создании синхронизированной таблицы можно переопределить стандартное сопоставление типов из Delta в Postgres для конкретных столбцов с помощью type_overrides.

Замечание

Типы vector и halfvec требуют векторного расширения в базе назначения. Создание синхронизированной таблицы не устанавливает расширения, поэтому установите одно перед созданием синхронизированной таблицы. Используйте lakebase_vector, который добавляет ANN-векторный поиск через поиск Lakebase и устанавливает pgvector как зависимость:

CREATE EXTENSION IF NOT EXISTS lakebase_vector CASCADE;

Чтобы использовать типы vector и halfvec без Lakebase Search, установите pgvector отдельно с помощью CREATE EXTENSION IF NOT EXISTS vector;. Тип varchar не требует удлинения.

Тип исходного столбца	Постгрес тип	Size	Определение (`pg_type`)	Пример варианта использования
`ARRAY<FLOAT>`, `ARRAY<DOUBLE>`	`vector(n)`	Измерение внедрения	`PG_SPECIFIC_TYPE_VECTOR`	Храните эмбеддинги как `vector`, а не как `JSONB`, готовые для поиска по сходству с lakebase_vector
`ARRAY<FLOAT>`, `ARRAY<DOUBLE>`	`halfvec(n)`	Измерение внедрения	`PG_SPECIFIC_TYPE_HALFVEC`	Эмбеддинги с половинной точностью занимают примерно вдвое меньше места, чем `vector`
`STRING`	`varchar(n)`	Максимальная длина	`PG_SPECIFIC_TYPE_VARCHAR`	Сопоставить с `varchar` с ограничением длины вместо `TEXT`, используемого по умолчанию

Замечание

size требуется для каждого типа в этой таблице. Допустимые диапазоны:

vector и halfvec: от 1 до 16 000 — количество вложенных измерений.
varchar: от 1 до 10 485 760, максимальная длина символа.

Пользовательские отображения типов можно настраивать через API, CLI и SDK Databricks при создании синхронизированной таблицы.

Для исходной таблицы main.docs.chunks(id BIGINT, title STRING, embedding ARRAY<FLOAT>) в Postgres выполняется следующее сопоставление: title в varchar(256) и embedding в vector(1024).

databricks postgres create-synced-table main.docs.chunks_pg \
  --json '{
    "spec": {
      "source_table_full_name": "main.docs.chunks",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true,
      "type_overrides": [
        { "column_name": "title", "pg_type": "PG_SPECIFIC_TYPE_VARCHAR", "size": 256 },
        { "column_name": "embedding", "pg_type": "PG_SPECIFIC_TYPE_VECTOR", "size": 1024 }
      ]
    }
  }'

Без переопределения title было бы TEXT, а embedding было бы JSONB.

Обработка недопустимых символов

Некоторые символы, такие как нулевые байты (0x00), разрешены в столбцах каталога Unity STRING, ARRAY, MAP или STRUCT, но не поддерживаются в столбцах Postgres TEXT или JSONB. Это может привести к сбоям синхронизации с такими ошибками:

ERROR: invalid byte sequence for encoding "UTF8": 0x00
ERROR: unsupported Unicode escape sequence DETAIL: \u0000 cannot be converted to text

Первая ошибка возникает, когда байт null отображается в строковом столбце верхнего уровня, который сопоставляется непосредственно с Postgres TEXT.
Вторая ошибка возникает, когда байт null отображается в строке, вложенной внутри сложного типа (STRUCTилиARRAYMAP), который сериализуется как JSONB. Во время сериализации все строки привязываются к Postgres TEXT, где \u0000 запрещено.

Решения:

Очистка строковых полей: удалите неподдерживаемые символы перед синхронизацией. Для нулевых байтов (NULL) в столбцах STRING:
```
SELECT REPLACE(column_name, CAST(CHAR(0) AS STRING), '') AS cleaned_column FROM your_table
```
Преобразование в BINARY: для столбцов STRING, в которых необходимо сохранить необработанные байты, преобразуйте в тип BINARY.

Планирование емкости

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

Использование соединений: Каждая синхронизированная таблица использует до 16 подключений к вашей базе данных Lakebase, которые засчитываются в лимит соединения проекта.
Квота на объём: Общий объём логических данных во всех синхронизированным таблицах засчитывается в квоту хранилища базы данных ветки. Обратитесь в службу поддержки Databricks, если вам нужна более большая квота. У отдельных таблиц нет квоты, но Databricks рекомендует не превышать 1 ТБ для таблиц, требующих обновлений.
Размер полного обновления: при активации полного обновления старая версия в Postgres не удаляется до завершения новой синхронизации. Обе версии временно засчитываются в квоту на размер логической базы данных во время обновления.
Таблиц на источник: для одной исходной таблицы можно синхронизировать до 20 таблиц.
Требования к именованию: имена баз данных, схем и таблиц могут содержать только буквенно-цифровые символы и символы подчеркивания ([A-Za-z0-9_]+).
Руководство по идентификатору источника. Избегайте использования прописных букв или специальных символов в именах столбцов или таблиц в исходной таблице каталога Unity. Если вы их оставите, то при обращении к ним в Postgres необходимо заключать эти идентификаторы в кавычки.
Эволюция схемы. Для триггерных и непрерывных режимов поддерживаются только изменения аддитивной схемы (например, добавление столбцов).
Изменение определения таблицы: Обновление определения синхронизированной таблицы не поддерживается ни одним интерфейсом (UI, SDK, CLI, REST API, Terraform или DAB). Чтобы изменить первичный ключ или ключ временных рядов, либо внести неаддитивное изменение схемы, удалите синхронизированную таблицу и создайте новую.
Повторяющиеся ключи: если две строки имеют один и тот же первичный ключ в исходной таблице, конвейер синхронизации завершается ошибкой, если не настроить дедупликацию с помощью ключа таймерии.
Идемпотентность API: API синхронизированных таблиц являются идемпотентными, поэтому повторите попытку при временных ошибках, чтобы обеспечить своевременные операции.
Скорость обновления: Для Lakebase конвейер синхронизации поддерживает непрерывные и триггерные записи примерно 150 строк в секунду на единицу емкости (CU), а запись Snapshot — до 2000 строк в секунду на CU.

Операции, разрешенные для синхронизированных таблиц в Postgres

Azure Databricks рекомендует выполнять только следующие операции в Postgres для синхронизированных таблиц, чтобы предотвратить случайные перезаписи или несоответствия данных:

Запросы только для чтения
Создание индексов
Удаление таблицы (чтобы освободить место после удаления синхронизированной таблицы из каталога Unity)

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

Владение и разрешения

Синхронизированная таблица принадлежит внутренней databricks_writer_<dbid> роли, а не пользователю, создавшему ее, так как конвейер синхронизации управляет им (см. роли Postgres). Команды только владельца, такие как настройка безопасности на уровне строк, не могут выполняться непосредственно в синхронизированной таблице.

Замечание

Это исключение из общего правила Postgres, согласно которому объекты, которые вы создаёте сами, принадлежат вашей учётной записи Azure Databricks, если соответствующий логин существует в Postgres как роль. Конвейер создает синхронизированные таблицы от вашего имени.

Доступ для пользователя, создающего синхронизированную таблицу

При создании синхронизированной таблицы вашей учетной записи Azure Databricks автоматически предоставляется доступ для работы с ней. Никаких databricks_superuser действий не требуется. Вашей учетной записи предоставлены следующие привилегии для синхронизированной таблицы:

Объект	Privileges	Purpose
Синхронизированная таблица	`SELECT`, `DELETE`, `TRUNCATE`	Чтение или очистка таблицы
Schema	`USAGE`, `CREATE`	Использование схемы и создание таких объектов, как индексы

Вам не предоставляются INSERT или UPDATE. Конвейер управляет данными таблицы, поэтому любые прямые изменения будут перезаписаны при следующем обновлении. DELETE и TRUNCATE только очищают таблицу. Следующее обновление заново заполняет таблицу данными из источника.

Этот доступ является производным от разрешений каталога Unity в синхронизированной таблице и управляется в каталоге Unity. Чтобы изменить его, обновите разрешения каталога Unity пользователя. Вы не можете REVOKE это напрямую из учётной записи Azure Databricks в Postgres.

Замечание

Этот доступ привязан к учётной записи, которая создала синхронизированную таблицу. Изменение учётной записи в параметре конвейера Run as не приводит к его переназначению. Чтобы использовать другой идентификатор владельца, заново создайте синхронизированную таблицу с этим идентификатором.

Управление доступом к синхронизированной таблице

После создания синхронизированной таблицы databricks_superuser может читать синхронизированную таблицу из Postgres. Этот databricks_superuserpg_read_all_dataпараметр позволяет считывать эту роль из всех таблиц. Он также имеет привилегию pg_write_all_data , которая позволяет этой роли записывать все таблицы. Это означает, что databricks_superuser можно также записывать в синхронизированную таблицу в Postgres. Lakebase поддерживает это поведение записи в случае, если необходимо внести срочные изменения в целевую таблицу. Однако Azure Databricks рекомендует вносить исправления в исходную таблицу.

Кроме того, databricks_superuser эти привилегии можно предоставить другим пользователям:
```
GRANT USAGE ON SCHEMA synced_table_schema TO user;
```
```
GRANT SELECT ON synced_table_name TO user;
```

databricks_superuser может отозвать эти привилегии:

REVOKE USAGE ON SCHEMA synced_table_schema FROM user;

REVOKE {SELECT | INSERT | UPDATE | DELETE} ON synced_table_name FROM user;

Управление синхронизированными операциями таблицы

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

CREATE INDEX
ALTER INDEX
DROP INDEX
DROP TABLE

Все остальные операции DDL запрещены для синхронизированных таблиц.

Чтобы предоставить этим привилегиям дополнительным пользователям, databricks_superuser сначала необходимо создать расширение в databricks_auth:

CREATE EXTENSION IF NOT EXISTS databricks_auth;

databricks_superuser Затем пользователь может добавить пользователя для управления синхронизированной таблицей:

SELECT databricks_synced_table_add_manager('"synced_table_schema"."synced_table"'::regclass, '[user]');

databricks_superuser может удалить пользователя из управления синхронизированной таблицей.

SELECT databricks_synced_table_remove_manager('[table]', '[user]');

databricks_superuser может просматривать всех руководителей:

SELECT * FROM databricks_synced_table_managers;

Удаление синхронизированной таблицы

При удалении синхронизированной таблицы из каталога Unity также удаляется соответствующая таблица Postgres.

Пользовательский интерфейс

В каталоге найдите синхронизированную таблицу, щелкните значок меню Kebab. Меню и нажмите кнопку "Удалить".

пакет SDK Python

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

w.postgres.delete_synced_table("synced_tables/my-catalog.sales.orders").wait()

пакет SDK для Java

import com.databricks.sdk.WorkspaceClient;

WorkspaceClient w = new WorkspaceClient();

w.postgres().deleteSyncedTable("synced_tables/my-catalog.sales.orders").waitForCompletion();

завиток

curl -X DELETE "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables/my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Узнать больше

задачи	Описание
Создание проекта	Настройка проекта Lakebase
Подключение к базе данных	Сведения о параметрах подключения для Lakebase
Регистрация базы данных в каталоге Unity	Сделать данные Lakebase видимыми в каталоге Unity для унифицированного управления и кросс-исходных запросов
Интеграция каталога Unity	Общие сведения об управлении и разрешениях

Интеграция с каталогом

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

Другие варианты

Сведения о решениях Partner Connect по обратному ETL для синхронизации данных с системами, отличными от Databricks, см. таких, как Census или Hightouch.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-09-02

Предоставление данных Lakehouse с синхронизированными таблицами

Что такое синхронизированные таблицы?

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

Принцип работы

Ускоренная начальная синхронизация

Режимы синхронизации

Примеры вариантов использования

Создание синхронизированной таблицы

Необходимые условия

Пользовательский интерфейс

интерфейс командной строки (CLI)

пакет SDK Python

пакет SDK для Java

завиток

Планирование или активация последующих синхронизаций

Задача конвейера синхронизации таблиц базы данных

Триггер обновлений исходной таблицы

Триггер, действующий по расписанию

Проверка состояния синхронизации

Пользовательский интерфейс

пакет SDK Python

пакет SDK для Java

завиток

Типы данных и совместимость

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

Обработка недопустимых символов

Планирование емкости

Операции, разрешенные для синхронизированных таблиц в Postgres

Владение и разрешения

Доступ для пользователя, создающего синхронизированную таблицу

Управление доступом к синхронизированной таблице

Управление синхронизированными операциями таблицы

Удаление синхронизированной таблицы

Пользовательский интерфейс

пакет SDK Python

пакет SDK для Java

завиток

Узнать больше

Интеграция с каталогом

Другие варианты

Обратная связь

Дополнительные ресурсы