다음을 통해 공유


Unity 카탈로그 테이블에서 데이터베이스 인스턴스로 데이터 동기화

중요합니다

이 기능은 다음 지역의 공개 미리 보기에 있습니다. westuswestus2eastuseastus2centralussouthcentralusnortheuropewesteuropeaustraliaeastbrazilsouthcanadacentralcentralindiasoutheastasiauksouth

이 페이지에서는 동기화된 테이블을 만들고 관리하는 방법을 설명합니다. 동기화된 테이블은 Unity 카탈로그 테이블에서 Lakebase 데이터베이스 인스턴스로 데이터를 자동으로 동기화하는 Unity 카탈로그 읽기 전용 Postgres 테이블입니다. Unity 카탈로그 테이블을 Postgres에 동기화하면 대기 시간이 짧은 읽기 쿼리가 가능하며 다른 Postgres 테이블과의 쿼리 시간 조인을 지원합니다.

동기화는 Lakeflow Spark 선언적 파이프라인에서 처리됩니다. 관리되는 파이프라인은 원본 테이블의 변경 내용으로 Postgres 테이블을 지속적으로 업데이트합니다. 만든 후에는 Postgres 도구를 사용하여 동기화된 테이블을 직접 쿼리할 수 있습니다.

동기화된 테이블의 주요 특징은 다음과 같습니다.

  • 원본을 사용하여 데이터 무결성을 유지하기 위해 Postgres에서 읽기 전용
  • 관리되는 Lakeflow Spark 선언적 파이프라인을 사용하여 자동으로 동기화됨
  • 표준 PostgreSQL 인터페이스를 통해 쿼리 가능
  • 거버넌스 및 수명 주기 관리를 위해 Unity 카탈로그를 통해 관리

시작하기 전 주의 사항:

  • 모든 카탈로그에 Unity 카탈로그 테이블이 있습니다.
  • CAN USE 데이터베이스 인스턴스에 대한 권한이 있습니다.

동기화된 테이블 만들기

사용자 인터페이스 (UI)

Unity 카탈로그 테이블을 Postgres에 동기화하려면 다음을 수행합니다.

  1. 작업 영역 사이드바에서 카탈로그 를 클릭합니다.

  2. 동기화된 테이블을 만들 Unity 카탈로그 테이블을 찾아 선택합니다.

  3. 동기화된 테이블>를 클릭합니다.

  4. 카탈로그, 스키마를 선택하고 새 동기화된 테이블의 테이블 이름을 입력합니다.

    • 일부 추가 구성을 사용하여 표준 카탈로그에서 동기화된 테이블을 만들 수도 있습니다. 표준 카탈로그, 스키마를 선택하고 새로 만든 동기화된 테이블의 테이블 이름을 입력합니다.
  5. 데이터베이스 인스턴스를 선택하고 동기화된 테이블을 만들 Postgres 데이터베이스의 이름을 입력합니다. Postgres 데이터베이스 필드는 기본적으로 현재 선택된 대상 카탈로그로 설정됩니다. 이 이름 아래에 Postgres 데이터베이스가 없는 경우 Azure Databricks는 새 데이터베이스를 만듭니다.

  6. 기본 키를 선택합니다. 기본 키는 읽기, 업데이트 및 삭제에 대한 행에 효율적으로 액세스할 수 있도록 하기 때문에 필요합니다 .

    중요합니다

    기본 키의 열은 동기화된 테이블에서 null을 허용하지 않습니다. 따라서 기본 키 열에 null이 있는 행은 동기화에서 제외됩니다.

  7. 원본 테이블에서 두 행의 기본 키가 동일한 경우 중복 제거를 구성하려면 Timeseries 키를 선택합니다. Timeseries 키를 지정하면 동기화된 테이블에는 각 기본 키에 대한 최신 timeseries 키 값이 있는 행만 포함됩니다.

  8. 스냅샷, 트리거됨연속에서 동기화 모드를 선택합니다. 각 동기화 모드에 대한 자세한 내용은 설명된 동기화 모드를 참조하세요.

  9. 새 파이프라인 또는 기존 파이프라인에서 이 동기화된 테이블을 만들 것인지 선택합니다.

    • 새 파이프라인을 만들고 관리되는 카탈로그를 사용하는 경우 준비 테이블의 스토리지 위치를 선택합니다. 표준 카탈로그를 사용하는 경우 스테이징 테이블은 카탈로그에 자동으로 저장됩니다.
    • 기존 파이프라인을 사용하는 경우 새 동기화 모드가 파이프라인 모드와 일치하는지 확인합니다.
  10. (선택 사항) 서버리스 예산 정책을 선택합니다. 서버리스 예산 정책을 만들려면 서버리스 예산 정책을 사용하는 특성 사용을 참조하세요. 이를 통해 특정 사용 정책에 대한 청구 사용량을 특성화할 수 있습니다.

    • 동기화된 테이블의 경우 청구 가능한 개체는 기본 Lakeflow Spark 선언적 파이프라인입니다. 예산 정책을 수정하려면 기본 파이프라인 개체를 수정합니다. 서버리스 파이프라인 구성을 참조하세요.
  11. 동기화된 테이블 상태가Online이면 데이터베이스 인스턴스에 로그인하고 새로 만든 테이블을 쿼리합니다. SQL 편집기, 외부 도구 또는 Notebook을 사용하여 테이블을 쿼리합니다.

Python SDK

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.database import SyncedDatabaseTable, SyncedTableSpec, NewPipelineSpec, SyncedTableSchedulingPolicy

# Initialize the Workspace client
w = WorkspaceClient()

# Create a synced table in a database catalog
synced_table = w.database.create_synced_database_table(
    SyncedDatabaseTable(
        name="database_catalog.schema.synced_table",  # Full three-part name
        spec=SyncedTableSpec(
            source_table_full_name="source_catalog.source_schema.source_table",
            primary_key_columns=["id"],  # Primary key columns
            scheduling_policy=SyncedTableSchedulingPolicy.TRIGGERED,  # SNAPSHOT, TRIGGERED, or CONTINUOUS
            # Optional: timeseries_key="timestamp"  # For deduplication
            new_pipeline_spec=NewPipelineSpec(
                storage_catalog="storage_catalog",
                storage_schema="storage_schema"
            )
        ),
    )
)
print(f"Created synced table: {synced_table.name}")

# Create a synced table in a standard UC catalog
synced_table = w.database.create_synced_database_table(
    SyncedDatabaseTable(
        name="standard_catalog.schema.synced_table",  # Full three-part name
        database_instance_name="my-database-instance",  # Required for standard catalogs
        logical_database_name="postgres_database",  # Required for standard catalogs
        spec=SyncedTableSpec(
            source_table_full_name="source_catalog.source_schema.source_table",
            primary_key_columns=["id"],
            scheduling_policy=SyncedTableSchedulingPolicy.CONTINUOUS,
            create_database_objects_if_missing=True,  # Create database/schema if needed
            new_pipeline_spec=NewPipelineSpec(
                storage_catalog="storage_catalog",
                storage_schema="storage_schema"
            )
        ),
    )
)
print(f"Created synced table: {synced_table.name}")

# Check the status of a synced table
synced_table_name = "database_catalog.schema.synced_table"
status = w.database.get_synced_database_table(name=synced_table_name)
print(f"Synced table status: {status.data_synchronization_status.detailed_state}")
print(f"Status message: {status.data_synchronization_status.message}")

CLI

# Create a synced table in a database catalog
databricks database create-synced-database-table  \
  --json '{
    "spec": {
      "name": "database_catalog.schema.synced_table",
      "source_table_full_name": "source_catalog.source_schema.source_table",
      "primary_key_columns": ["id"],
      "scheduling_policy": "TRIGGERED"
    },
    "new_pipeline_spec": {
      "storage_catalog": "storage_catalog",
      "storage_schema": "storage_schema"
    }
  }'

# Create a synced table in a standard UC catalog
# new_pipeline_spec, storage_catalog, and storage_schema are optional
databricks database create-synced-database-table \
  --database-instance-name "my-database-instance" \
  --logical-database-name "databricks_postgres" \
  --json '{
    "name": "standard_catalog.schema.synced_table",
    "spec": {
      "source_table_full_name": "source_catalog.source_schema.source_table",
      "primary_key_columns": ["id"],
      "scheduling_policy": "CONTINUOUS",
      "create_database_objects_if_missing": true
    }
  }'

# Check the status of a synced table
databricks database get-synced-database-table "database_catalog.schema.synced_table"

curl

데이터베이스 카탈로그에서 동기화된 테이블을 만듭니다.

export CATALOG_NAME=<Database catalog>
export SRC_TBL="source_catalog.source_schema.source_table"
export DEST_TBL="$CATALOG_NAME.some_schema.synced_table"
export PKS='["id"]'
export ST_CATALOG = "storage_catalog"
export ST_SCHEMA = "storage_schema"

curl -X POST https://$WORKSPACE/api/2.0/database/synced_tables \
-H "Content-Type: text/json" \
-H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
--data-binary @- << EOF
{
  "name": "$DEST_TBL",
  "spec": {
    "source_table_full_name": "$SRC_TBL",
    "primary_key_columns": $PKS,
    "scheduling_policy": "TRIGGERED",
  },
  "new_pipeline_spec": {
    "storage_catalog": "$ST_CATALOG",
    "storage_schema": "$ST_SCHEMA",
  }
}
EOF

표준 Unity 카탈로그 카탈로그에서 동기화된 테이블을 만듭니다.

export CATALOG_NAME=<Standard catalog>
export DATABASE_INSTANCE=<database instance>
export POSTGRES_DATABASE=$CATALOG_NAME
export SRC_TBL="source_catalog.source_schema.source_table"
export DEST_TBL="$CATALOG_NAME.some_schema.sync_table"
export PKS='["id"]'
export ST_CATALOG = "storage_catalog"
export ST_SCHEMA = "storage_schema"

curl -X POST https://$WORKSPACE/api/2.0/database/synced_tables \
-H "Content-Type: text/json" \
-H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
--data-binary @- << EOF
{
  "name": "$DEST_TBL",
  "database_instance_name": "$DATABASE_INSTANCE",
  "logical_database_name": "$POSTGRES_DATABASE",
  "spec": {
    "source_table_full_name": "$SRC_TBL",
    "primary_key_columns": $PKS,
    "scheduling_policy": "TRIGGERED",
  },
  "new_pipeline_spec": {
    "storage_catalog": "$ST_CATALOG",
    "storage_schema": "$ST_SCHEMA",
  }
}
EOF

동기화된 테이블의 상태를 확인합니다.

export SYNCEDTABLE='pg_db.silver.sbtest1_online'

curl --request GET \
  "https://e2-dogfood.staging.cloud.databricks.com/api/2.0/database/synced_tables/$SYNCEDTABLE" \
  --header "Authorization: Bearer dapi..."

동기화 모드 설명

데이터를 원본에서 Postgres의 동기화된 테이블로 동기화하는 방법을 결정하는 다음 동기화 모드 중 하나를 사용하여 동기화된 테이블을 만들 수 있습니다.

동기화 모드 Description Performance
스냅샷 파이프라인은 한 번 실행하여 원본 테이블의 스냅샷을 만들고 동기화된 테이블에 복사합니다. 후속 파이프라인 실행은 전체 원본 데이터를 대상에 복사하고, 데이터의 일관성을 보장하기 위해 원자적으로 대체합니다. 파이프라인은 API를 통해 또는 일정에 따라 수동으로 트리거할 수 있습니다. 이 모드는 처음부터 데이터를 다시 만들기 때문에 트리거 또는 연속 동기화 모드보다 10배 더 효율적입니다. 원본 테이블의% 10개 이상을 수정하는 경우 이 모드를 사용하는 것이 좋습니다.
자극받음 파이프라인은 한 번 실행하여 원본 테이블의 스냅샷을 만들고 동기화된 테이블에 복사합니다. 스냅샷 동기화 모드와 달리 동기화된 테이블을 새로 고치면 마지막 파이프라인 실행 이후 변경 내용만 검색되어 동기화된 테이블에 적용됩니다. 증분 새로 고침은 API를 통해 또는 일정에 따라 수동으로 트리거할 수 있습니다. 이 모드는 요청 시 실행되고 마지막 실행 이후 변경 내용만 적용되므로 지연과 비용 간에 적절한 절충안입니다. 지연을 최소화하려면 원본 테이블을 업데이트한 직후 이 파이프라인을 실행합니다. 5분마다 이 작업을 더 자주 실행하는 경우 매번 파이프라인을 시작하고 중지하는 비용 때문에 연속 모드보다 비용이 더 많이 들 수 있습니다.
지속적 파이프라인은 한 번 실행하여 원본 테이블의 스냅샷을 만들고 동기화된 테이블에 복사한 다음 파이프라인이 지속적으로 실행됩니다. 원본 테이블에 대한 후속 변경 내용은 동기화된 테이블에 실시간으로 증분 방식으로 적용됩니다. 수동 새로 고침이 필요하지 않습니다. 이 모드는 지속적으로 실행되므로 지연 시간이 가장 낮지만 비용이 더 높습니다.

비고

트리거 또는 연속 동기화 모드를 지원하려면 원본 테이블에 변경 데이터 피드가 활성화되어 있어야 합니다. 보기와 같은 특정 원본은 변경 데이터 피드를 지원하지 않으므로 스냅샷 모드에서만 동기화할 수 있습니다.

지원되는 작업

Databricks는 실수로 덮어쓰거나 데이터 불일치를 방지하기 위해 동기화된 테이블에 대해 Postgres에서 다음 작업만 수행하는 것이 좋습니다.

  • 읽기 전용 쿼리
  • 인덱스 만들기
  • 테이블 삭제(Unity 카탈로그에서 동기화된 테이블을 제거한 후 공간을 확보하려면)

다른 방법으로 이 테이블을 수정할 수 있지만 동기화 파이프라인을 방해합니다.

동기화된 테이블 삭제

동기화된 테이블을 삭제하려면 Unity 카탈로그에서 삭제한 다음 데이터베이스 인스턴스에 테이블을 삭제해야 합니다. Unity 카탈로그에서 동기화된 테이블을 삭제하면 테이블 등록이 취소되고 데이터 새로 고침이 중지됩니다. 그러나 테이블은 기본 Postgres 데이터베이스에 남아 있습니다. 데이터베이스 인스턴스의 공간을 확보하려면 인스턴스에 연결하고 명령을 사용합니다 DROP TABLE .

사용자 인터페이스 (UI)

  1. 작업 영역 사이드바에서 카탈로그 를 클릭합니다.
  2. 삭제할 동기화된 테이블을 찾아 선택합니다.
  3. Kebab 메뉴 아이콘을 클릭합니다. > 삭제합니다.
  4. SQL 편집기 psql 또는 노트북을 사용하여 인스턴스에 연결합니다.
  5. PostgreSQL을 사용하여 테이블을 삭제합니다.
    DROP TABLE synced_table_database.synced_table_schema.synced_table
    

Python SDK

from databricks.sdk import WorkspaceClient

# Initialize the Workspace client
w = WorkspaceClient()

# Delete a synced table from UC
synced_table_name = "catalog.schema.synced_table"
w.database.delete_synced_database_table(name=synced_table_name)
print(f"Deleted synced table from UC: {synced_table_name}")

# To free up space in your database instance, you need to connect to the
# instance and drop the table using PostgreSQL:
#
# DROP TABLE synced_table_database.synced_table_schema.synced_table;

CLI

# Delete a synced table from UC
databricks database delete-synced-database-table "catalog.schema.synced_table"

# To free up space in your database instance, you need to connect to the
# instance and drop the table using PostgreSQL:
#
# DROP TABLE synced_table_database.synced_table_schema.synced_table;

curl

# Delete a synced table from UC
curl -X DELETE --header "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  https://$WORKSPACE/api/2.0/database/synced_tables/$SYNCED_TABLE_NAME

# To free up space in your database instance, you need to connect to the
# instance and drop the table using PostgreSQL:
#
# DROP TABLE synced_table_database.synced_table_schema.synced_table;

소유권 및 권한

새 Postgres 데이터베이스, 스키마 또는 테이블을 만드는 경우 Postgres 소유권은 다음과 같이 설정됩니다.

  • Azure Databricks 로그인이 Postgres에 역할로 존재하는 경우 데이터베이스, 스키마 또는 테이블을 만드는 사용자에게 소유권이 할당됩니다. Postgres에서 Azure Databricks ID 역할을 추가하려면 Postgres 역할 관리를 참조하세요.
  • 그렇지 않으면 소유권은 Postgres(일반적으로 )에서 부모 개체의 소유자에게 databricks_superuser할당됩니다.

동기화된 테이블 액세스 관리

동기화된 테이블이 생성된 후 Postgres에서 동기화된 테이블을 가져올 수 있습니다 databricks_superuserREAD. 이 databricks_superuser는 모든 테이블에서 읽을 수 있는 권한인 pg_read_all_data을 갖고 있습니다. 또한 pg_write_all_data 이 역할이 모든 테이블에 쓸 수 있는 권한이 있습니다. 즉, databricks_superuser Postgres에서 동기화된 테이블에 쓸 수도 있습니다. Lakebase는 대상 테이블을 긴급하게 변경해야 하는 경우 이 쓰기 동작을 지원합니다. 그러나 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의 대상 동기화 테이블에 매핑하는 방법을 정의합니다.

원본 열 형식 Postgres 열 형식
BIGINT BIGINT
바이너리 BYTEA
부울 BOOLEAN
날짜 DATE
DECIMAL(p,s) 숫자
배정밀도
뜨다 real
INT 정수
INTERVAL 간격한정자(intervalQualifier)
SMALLINT 스몰인트 (SMALLINT)
문자열 텍스트
타임 스탬프 시간대를 포함한 타임스탬프
TIMESTAMP_NTZ 표준 시간대가 없는 타임스탬프
TINYINT 스몰인트 (SMALLINT)
GEOGRAPHY(srid) 지원되지 않음
GEOMETRY(srid) 지원되지 않음
ARRAY < elementType > JSONB
MAP < keyType,valueType > JSONB
STRUCT < [fieldName : fieldType [NOT NULL][COMMENT str][, ...]] > JSONB
변체 JSONB
객체 지원되지 않음

비고

  • ARRAY, MAP 및 STRUCT 형식에 대한 매핑은 2025년 5월에 변경되었습니다. 이전에 만든 테이블을 동기화하여 해당 형식을 JSON에 계속 매핑합니다.
  • TIMESTAMP에 대한 매핑은 2025년 8월에 변경되었습니다. 이전에 만든 동기화 테이블은 표준 시간대가 없는 TIMESTAMP에 계속 매핑됩니다.

잘못된 문자 처리

null 바이트(0x00)와 같은 특정 문자는 델타 테이블의 STRING, ARRAY, MAP, STRUCT 열에서는 허용되지만, Postgres TEXT 또는 JSONB 열에서는 지원되지 않습니다. 따라서 이러한 데이터를 델타에서 Postgres로 동기화하면 오류가 있는 삽입 오류가 발생할 수 있습니다.

org.postgresql.util.PSQLException: ERROR: invalid byte sequence for encoding "UTF8": 0x00

org.postgresql.util.PSQLException: ERROR: unsupported Unicode escape sequence DETAIL: \u0000 cannot be converted to text.
  • 첫 번째 오류는 최상위 문자열 열에 null 바이트가 표시되어 Postgres에 직접 매핑되는 경우에 발생합니다 TEXT.
  • 두 번째 오류는 Azure Databricks가 직렬화하는 복합 형식(STRUCTARRAY또는MAP)에 중첩된 문자열에 null 바이트가 나타날 때 발생합니다JSONB. serialization 중에 모든 문자열은 Postgres TEXT에 캐스팅되며, \u0000는 허용되지 않습니다.

해결 방법:

다음 방법 중 하나로 이 문제를 해결할 수 있습니다.

  • 문자열 필드 정리

    Postgres로 동기화하기 전에 지원되지 않는 문자를 복합 형식 내의 문자를 포함하여 모든 문자열 필드에서 제거하거나 대체합니다.

    최상위 STRING 열에서 null 바이트를 제거하려면 다음 함수를 REPLACE 사용합니다.

    SELECT REPLACE(column_name, CAST(CHAR(0) AS STRING), '') AS cleaned_column FROM your_table;
    
  • 이진수로 변환(열 STRING 에만 해당)

    원시 바이트 콘텐츠를 보존해야 하는 경우 영향을 받는 STRING 열을 .로 변환합니다 BINARY.

제한 사항 및 고려 사항

지원되는 원본 테이블

동기화된 테이블의 동기화 모드에 따라 다양한 유형의 원본 테이블이 지원됩니다.

  • 스냅샷 모드의 경우 원본 테이블이 지원 SELECT *되어야 합니다. 예를 들어 델타 테이블, Iceberg 테이블, 뷰, 구체화된 뷰 및 기타 유사한 형식이 있습니다.

  • 트리거 또는 연속 동기화 모드의 경우 원본 테이블에 변경 데이터 피드 사용하도록 설정되어 있어야 합니다.

명명 및 식별자 제한 사항

  • 허용되는 문자: 동기화된 테이블의 Postgres 데이터베이스, 스키마 및 테이블 이름은 영숫자 문자와 밑줄([A-Za-z0-9_]+)만 포함할 수 있습니다. 하이픈(-) 및 기타 특수 문자는 지원되지 않습니다.
  • 열 및 테이블 식별자: 원본 Unity 카탈로그 테이블의 열 또는 테이블 이름에 대문자나 특수 문자를 사용하지 마세요. 유지되는 경우 Postgres에서 참조할 때 이러한 식별자를 인용해야 합니다.

성능 및 동기화

  • 동기화 속도: 데이터를 동기화된 테이블로 동기화하는 것은 추가 처리로 인해 네이티브 PostgreSQL 클라이언트를 사용하여 데이터베이스 인스턴스에 직접 데이터를 쓰는 것보다 느릴 수 있습니다. 연속 동기화 모드는 Unity 카탈로그 관리 테이블에서 동기화된 테이블로 최소 15초 간격으로 데이터를 새로 고칩니다.
  • 연결 사용량: 각 테이블 동기화는 인스턴스의 연결 제한에 따라 계산되는 데이터베이스 인스턴스에 대해 최대 16개의 연결을 사용할 수 있습니다.
  • API idempotency: 동기화된 테이블 API는 idempotent이며, 적시에 작업을 보장하기 위해 오류가 발생하는 경우 다시 시도해야 할 수 있습니다.
  • 스키마 변경 내용: 동기화된 테이블 또는 Triggered 모드의 Continuous 경우 Unity 카탈로그 테이블의 추가 스키마 변경(예: 새 열 추가)만 동기화된 테이블에 반영됩니다.
  • 중복 키: 원본 테이블에 두 행의 기본 키가 동일한 경우 Timeseries 키를 사용하여 중복 제거를 구성하지 않으면 동기화 파이프라인이 실패합니다. 그러나 Timeseries 키를 사용하면 성능 저하가 발생합니다.
  • 업데이트 속도: 동기화 파이프라인은 CU(용량 단위)당 초당 약 1,200개의 행에서 연속 쓰기를 지원하고 CU당 초당 최대 15,000개의 행으로 대량 쓰기를 지원합니다.

용량 및 제한

  • 테이블 제한:
    • 원본 테이블당 동기화된 테이블 20개로 제한됩니다.
    • 각 테이블 동기화는 최대 16개의 데이터베이스 연결을 사용할 수 있습니다.
  • 크기 제한 및 전체 새로 고침:
    • 동기화된 테이블을 완전히 새로 고치면 새 테이블이 동기화될 때까지 Postgres의 이전 버전이 삭제되지 않습니다. 논리적 데이터베이스 크기 제한에 두 버전 모두 갱신하는 동안 일시적으로 포함됩니다.
    • 동기화된 개별 테이블에는 제한이 없지만 인스턴스의 모든 테이블에 대한 총 논리 데이터 크기 제한은 2TB입니다. 그러나 전체 테이블 재현 대신 새로 고침이 필요한 경우 Databricks는 1TB를 초과하지 않는 것이 좋습니다.
    • Unity 카탈로그 테이블의 압축되지 않은 행 형식 크기가 데이터베이스 인스턴스 크기 제한(2TB)을 초과하면 동기화가 실패합니다. 인스턴스에 더 쓰기 전에 Postgres에서 동기화된 테이블을 삭제해야 합니다.

카탈로그 통합

  • 카탈로그 중복: 또한 별도의 데이터베이스 카탈로그로 등록된 Postgres 데이터베이스를 대상으로 하는 표준 카탈로그에 동기화된 테이블을 만들면 동기화된 테이블이 표준 카탈로그와 데이터베이스 카탈로그 모두에서 Unity 카탈로그에 표시됩니다.