Databricks Liquid Clustering: 성능 최적화와 운영 가이드

Lakehouse 환경에서 테이블을 어떻게 최적화하느냐는 쿼리 성능과 운영 효율성에 직결되는 중요한 요소입니다. 지금까지는 파티셔닝(Partitioning)이나 ZORDER 인덱싱을 통해 데이터 레이아웃을 최적화하는 방식이 주로 사용되었습니다. 하지만 이 방식들은 파티션 키 설계 부담이 크거나, 데이터가 갱신될 때마다 다시 정렬 작업을 해야 하는 등의 한계가 있었습니다.

 

Databricks가 새롭게 선보인 Liquid Clustering은 이러한 문제를 해결하기 위해 등장한 차세대 데이터 최적화 기능입니다. Liquid Clustering은 기존 데이터를 다시 쓰지 않고도 클러스터링 키를 유연하게 변경할 수 있으며, Streaming Table과 Materialized View까지 지원하여 운영의 복잡성을 크게 줄여줍니다. 또한 자동화 기능을 통해 데이터와 쿼리 패턴에 따라 Databricks가 스스로 최적의 클러스터링 키를 선택하기 때문에 관리 부담 없이 안정적인 성능을 보장할 수 있습니다.

 

이번 글에서는 Databricks Liquid Clustering의 개념, 사용 방법, 자동화 기능, 그리고 제약사항까지 전반적으로 살펴보며, 실제 환경에서 어떻게 활용할 수 있는지 가이드를 제공합니다.

 

---

테이블에 Liquid Clustering을 사용하기

Liquid Clustering은 기존의 테이블 파티셔닝이나 ZORDER를 대체하여 데이터 레이아웃 설계를 단순화하고 쿼리 성능을 최적화할 수 있는 기능입니다. 가장 큰 장점은 기존 데이터를 다시 쓰지 않고도 클러스터링 키를 재정의할 수 있다는 점입니다. 덕분에 시간이 지나면서 분석 요구가 변하더라도 유연하게 데이터 레이아웃을 발전시킬 수 있습니다. Liquid Clustering은 Streaming Table과 Materialized View 모두에 적용할 수 있습니다.

 

---

Liquid Clustering은 언제 사용하면 좋을까?

Databricks는 새로운 테이블을 만들 때는 기본적으로 Liquid Clustering을 적용할 것을 권장합니다. 여기에는 Streaming Table과 Materialized View가 모두 포함됩니다. 특히 다음과 같은 상황에서 Liquid Clustering의 장점이 더욱 두드러집니다.

• 고유값이 많은 컬럼(예: 고객 ID, 세션 ID)으로 자주 필터링하는 경우
• 데이터 분포가 불균형하여 특정 값에 데이터가 몰리는 경우
• 데이터가 빠르게 증가하여 주기적인 유지보수와 튜닝이 필요한 경우
• 여러 작업이 동시에 쓰기를 수행하는 테이블
• 시간이 지나면서 접근 패턴이 변하는 테이블
• 일반적인 파티션 키로는 파티션이 너무 많거나, 너무 적은 경우

---

Liquid Clustering 활성화하기

Liquid Clustering은 기존 테이블에 적용하거나, 새로 테이블을 만들 때 바로 적용할 수 있습니다. 다만 주의해야 할 점은 파티셔닝(Partitioning)이나 ZORDER와는 함께 사용할 수 없으며, 테이블 내 데이터 레이아웃과 최적화 작업은 반드시 Azure Databricks에서 관리해야 한다는 점입니다.

 

Liquid Clustering을 활성화한 이후에는 평소와 마찬가지로 OPTIMIZE 작업을 실행하여 데이터를 점진적으로 클러스터링할 수 있습니다. 

SQL 예제

Liquid Clustering은 CLUSTER BY 구문을 통해 활성화할 수 있습니다.

-- 빈 Delta 테이블 생성 시
CREATE TABLE table1(col0 INT, col1 string) CLUSTER BY (col0);

-- CTAS(Create Table As Select) 구문 사용 시
CREATE EXTERNAL TABLE table2 CLUSTER BY (col0)  -- CLUSTER BY는 테이블 이름 뒤에 지정
LOCATION 'table_location'
AS SELECT * FROM table1;

-- 기존 테이블 설정을 복사할 때
CREATE TABLE table3 LIKE table1;

 

위 예시처럼 테이블 생성 시점에서 클러스터링 키를 지정할 수 있으며, 기존 테이블에도 추가할 수 있습니다.

 

Apache Iceberg 사용 시 주의사항

Managed Iceberg 테이블에서 Liquid Clustering을 활성화하려면 Deletion Vector(삭제 벡터)와 Row ID 기능을 반드시 비활성화해야 합니다. 이 설정을 하지 않으면 Liquid Clustering을 적용할 수 없습니다.

 

---

DBR 16.0+에서 Structured Streaming으로 Liquid Clustering 테이블 생성

Databricks Runtime 16.0 이상에서는 Structured Streaming 쓰기를 사용해 Liquid Clustering이 활성화된 테이블을 직접 생성할 수 있습니다. 즉, 스트리밍 파이프라인을 구성하면서 처음부터 클러스터링 키를 지정해, 이후 유입되는 데이터가 원하는 레이아웃으로 점진적으로 클러스터링되도록 설정할 수 있습니다.

 

아래 예시는 col0, col1 컬럼을 클러스터링 키로 지정해 테이블을 생성하는 SQL 구문입니다.

CREATE TABLE table1 (
  col0 STRING,
  col1 DATE,
  col2 BIGINT
)
CLUSTER BY (col0, col1);

참고: Liquid Clustering은 파티셔닝이나 ZORDER와 함께 사용할 수 없으며, 데이터 레이아웃/최적화 작업은 Databricks에서 관리됩니다. 테이블 생성 후에는 OPTIMIZE 작업을 통해 데이터를 점진적으로 클러스터링 하면 됩니다.

 

Structured Streaming에서 Liquid Clustering 적용하기

Databricks Runtime 16.0 이상에서는 Structured Streaming write 시에도 Liquid Clustering을 바로 적용할 수 있습니다. 즉, 스트리밍으로 유입되는 데이터를 테이블에 적재하면서 동시에 특정 컬럼을 기준으로 클러스터링을 지정할 수 있습니다.

 

Python 예제

(spark.readStream.table("source_table")
  .writeStream
  .clusterBy("column_name")  # 클러스터링 기준 컬럼 지정
  .option("checkpointLocation", checkpointPath)  # 체크포인트 경로 설정
  .toTable("target_table"))  # 타깃 테이블에 적재

 

Scala 예제

spark.readStream.table("source_table")
  .writeStream
  .clusterBy("column_name")               // 클러스터링 기준 컬럼 지정
  .option("checkpointLocation", checkpointPath) // 체크포인트 경로 설정
  .toTable("target_table")                // 타깃 테이블에 적재

 

Liquid Clustering 키 제거하기

테이블에 지정된 클러스터링 키를 제거하려면 ALTER TABLE ... CLUSTER BY NONE 구문을 사용하면 됩니다.
이렇게 하면 테이블은 더 이상 새로운 데이터에 대해 클러스터링을 적용하지 않으며, 기존 데이터는 그대로 유지됩니다.

 

SQL 예제

ALTER TABLE table_name CLUSTER BY NONE;

 

---

자동 Liquid Clustering

Databricks Runtime 15.4 LTS 이상에서는 Unity Catalog에서 관리하는 Delta 테이블에 대해 자동 Liquid Clustering을 활성화할 수 있습니다. 이 기능을 사용하면 Azure Databricks가 클러스터링 키를 자동으로 선택해 쿼리 성능을 최적화합니다. 자동 Liquid Clustering은 CLUSTER BY AUTO 구문으로 활성화할 수 있으며, Predictive Optimization 기능이 테이블에 켜져 있어야 합니다.

 

동작 방식

1. Databricks는 테이블의 과거 쿼리 워크로드를 분석해 가장 적합한 클러스터링 키 후보를 찾습니다.
2. 데이터 스키핑 효과에 따른 예상 비용 절감이 클러스터링 비용보다 크다고 판단되면 새로운 키를 적용합니다.
3. 시간이 지나면서 쿼리 패턴이 바뀌거나 데이터 분포가 달라지면, 자동으로 새로운 키를 선택해 성능을 최적화합니다.

클러스터링 키가 자동으로 선택되지 않는 경우

다음과 같은 상황에서는 자동 Liquid Clustering이 키를 지정하지 않을 수 있습니다.

• 테이블 크기가 너무 작아 클러스터링 이점이 없는 경우
• 이미 좋은 클러스터링 스킴을 가진 경우
  • 예: 이전에 알맞은 키를 적용했거나, 데이터가 시간순으로 삽입되고 타임스탬프 기준으로 쿼리하는 경우
• 해당 테이블에 쿼리 빈도가 낮은 경우
• DBR 15.4 LTS 이상을 사용하지 않는 경우

장점

자동 Liquid Clustering은 모든 Unity Catalog 관리 테이블에 적용 가능합니다. 데이터와 쿼리 특성과 상관없이 데이터 사용 패턴 기반으로 지능적인 데이터 레이아웃 최적화를 수행하며, 내부 휴리스틱이 자동으로 “클러스터링을 적용하는 것이 비용 효율적인지”를 판단합니다.

 

자동 Liquid Clustering 활성화 여부 확인하기

테이블에 자동 Liquid Clustering이 적용되어 있는지 확인하려면 DESCRIBE TABLE 또는 SHOW TBLPROPERTIES 명령어를 사용할 수 있습니다.

자동 클러스터링이 켜져 있다면:

• clusterByAuto 속성이 true로 표시됩니다.
• clusteringColumns 속성에는 현재 자동 또는 수동으로 선택된 클러스터링 컬럼이 나타납니다.

예시

DESCRIBE TABLE table_name;
SHOW TBLPROPERTIES table_name;

출력 결과에서 clusterByAuto = true 라고 되어 있으면 자동 Liquid Clustering이 활성화된 것입니다.

 

제약사항

• 자동 Liquid Clustering은 Apache Iceberg 테이블에서는 지원되지 않습니다.
• 따라서 Iceberg 테이블에서는 수동으로만 클러스터링 키를 지정해야 합니다.

 

기본 기능 활성화 동작 무시하기 (선택 사항)

Liquid Clustering을 활성화할 때, Delta 테이블의 특정 기능들이 기본적으로 활성화되며 그에 따라 Reader/Writer 프로토콜 버전이 업그레이드될 수 있습니다. 하지만 경우에 따라 이러한 기본 동작을 무시(override)할 수 있습니다. 즉, 특정 기능을 비활성화하여 프로토콜 업그레이드를 방지할 수 있습니다. 이 작업은 반드시 이미 존재하는 테이블에서 수행해야 합니다.

 

1. 특정 기능 비활성화하기

ALTER TABLE ... SET TBLPROPERTIES 구문을 사용하면 됩니다.
예를 들어, Deletion Vector 기능을 비활성화하려면 다음과 같이 실행합니다.

ALTER TABLE table_name 
SET TBLPROPERTIES ('delta.enableDeletionVectors' = false);

2. Liquid Clustering 활성화

그 다음, 클러스터링 키를 지정하여 Liquid Clustering을 활성화할 수 있습니다.

ALTER TABLE table_name
CLUSTER BY (clustering_columns);

 

참고 사항

Databricks 문서에서는 Liquid Clustering을 적용할 때 오버라이드할 수 있는 Delta 기능들과, 이 설정이 Databricks Runtime 버전과 어떤 호환성 영향을 주는지에 대한 정보도 함께 제공하고 있습니다.

👉 즉, 필요에 따라 특정 기능을 끄고 Liquid Clustering을 적용해 운영 환경의 호환성을 유지할 수 있다는 점이 핵심입니다.

---

클러스터링 키 선택하기

Databricks에서는 지원되는 테이블에 대해서는 자동 Liquid Clustering을 권장합니다. 만약 수동으로 클러스터링 키를 지정해야 한다면, 쿼리에서 가장 자주 필터링에 사용되는 컬럼을 기준으로 선택하는 것이 좋습니다. 클러스터링 키는 순서와 상관없이 지정할 수 있으며, 서로 강하게 상관관계가 있는 두 컬럼은 하나만 지정해도 충분합니다.

 

클러스터링 키 개수 권장사항

• 클러스터링 키는 최대 4개까지 지정 가능합니다.
• 소규모 테이블(10TB 미만)에서는 키를 많이 지정할수록(예: 4개) 단일 컬럼 필터링 성능이 떨어질 수 있으므로, 2개 정도로 제한하는 것이 좋습니다.
• 대규모 테이블에서는 키를 더 많이 지정하더라도 단일 컬럼 필터링 성능 저하는 사실상 무시할 수 있습니다.

클러스터링 키로 지정 가능한 컬럼 조건

• 클러스터링 키는 통계가 수집된 컬럼이어야 합니다.
• 기본적으로 Delta 테이블의 앞 32개 컬럼에 대해 통계가 수집됩니다.

지원되는 데이터 타입

Liquid Clustering에서 클러스터링 키로 지정할 수 있는 데이터 타입은 다음과 같습니다:

• Date
• Timestamp
• TimestampNTZ (Databricks Runtime 14.3 LTS 이상 필요)
• String
• Integer, Long, Short
• Float, Double, Decimal
• Byte

👉 따라서, 새로운 테이블을 설계하거나 기존 테이블을 변환할 때는 쿼리에서 자주 쓰이는 컬럼, 상관관계, 테이블 크기를 고려하여 클러스터링 키를 선택하는 것이 성능 최적화의 핵심입니다.

 

기존 최적화 기법에서 Liquid Clustering으로 전환할 때의 권장사항

기존에 사용하던 데이터 최적화 방식에 따라 클러스터링 키를 어떻게 지정할지에 대한 가이드라인이 있습니다.

기존 최적화 기법	권장되는 클러스터링 키
Hive 스타일 파티셔닝	파티션 컬럼을 그대로 클러스터링 키로 사용
Z-order 인덱싱	ZORDER BY에 사용한 컬럼들을 클러스터링 키로 사용
Hive 파티셔닝 + Z-order	파티션 컬럼과 ZORDER BY 컬럼을 모두 클러스터링 키로 사용
카디널리티(값 종류 수)를 줄이기 위해 생성한 컬럼 (예: 타임스탬프 대신 날짜 컬럼)	생성된 컬럼 대신 원본 컬럼을 클러스터링 키로 사용. 즉, 인위적으로 컬럼을 줄이지 않고 원래 컬럼을 그대로 지정

 

클러스터링 컬럼 개수에 따른 크기 임계값

Unity Catalog 관리 테이블과 일반 Delta 테이블의 경우, 클러스터링 컬럼 개수에 따라 최소 데이터 크기 임계값이 다릅니다. 이 크기를 초과해야 Liquid Clustering이 효과적으로 동작합니다.

클러스터링 컬럼 수	Unity Catalog 관리 테이블 임계값	일반 Delta 테이블 임계값
1	64 MB	256 MB
2	256 MB	1 GB
3	512 MB	2 GB
4	1 GB	4 GB

OPTIMIZE 실행 권장

모든 작업이 자동으로 Liquid Clustering을 적용하는 것은 아니기 때문에, Databricks에서는 주기적으로 OPTIMIZE를 실행하여 데이터를 효율적으로 클러스터링할 것을 권장합니다.

---

스트리밍 워크로드와 클러스터링

Structured Streaming 워크로드에서도 Liquid Clustering을 지원합니다.

• Spark 설정에서 spark.databricks.delta.liquid.eagerClustering.streaming.enabled = true 로 지정하면 스트리밍 쓰기 시에도 클러스터링이 적용됩니다.
• 단, 최근 5번의 스트리밍 업데이트 중 하나 이상이 위의 테이블에서 정의된 임계값을 초과해야 클러스터링이 실제로 트리거됩니다.

---

클러스터링 트리거하기

Predictive Optimization을 사용하는 경우, Databricks가 자동으로 OPTIMIZE 명령을 실행해 테이블을 클러스터링합니다. 
이 기능을 사용하는 경우에는 스케줄링된 OPTIMIZE 작업을 따로 설정할 필요가 없습니다.

 

수동으로 OPTIMIZE 실행하기

클러스터링을 직접 트리거하려면 Databricks Runtime 13.3 LTS 이상이 필요합니다.
테이블에 대해 아래와 같이 OPTIMIZE 명령을 실행하면 됩니다.

OPTIMIZE table_name;

 

---

Liquid Clustering의 특징

• Liquid Clustering은 증분 방식(incremental)으로 동작합니다.
• 즉, 전체 데이터를 다시 쓰는 것이 아니라 필요한 데이터만 선택적으로 다시 작성합니다.
• 이미 클러스터링 키가 잘 맞는 데이터 파일은 건드리지 않기 때문에, 일반적으로 실행 속도가 빠릅니다.

OPTIMIZE 스케줄링 권장사항

• Predictive Optimization을 사용하지 않는 경우, 주기적으로 OPTIMIZE 작업을 예약하는 것이 좋습니다.
• 업데이트나 Insert가 빈번한 테이블이라면 1~2시간 간격으로 OPTIMIZE 작업을 실행하는 것이 권장됩니다.
• 증분 방식 덕분에 대부분의 경우 OPTIMIZE 작업은 빠르게 완료됩니다.

---

모든 레코드에 대해 강제 리클러스터링하기

Databricks Runtime 16.0 이상에서는 테이블 전체 데이터를 강제로 리클러스터링하려면 아래 구문을 사용할 수 있습니다.

OPTIMIZE table_name FULL;

 

언제 OPTIMIZE FULL을 실행해야 할까?

• 처음으로 Liquid Clustering을 활성화할 때
• 클러스터링 키를 변경한 직후

이 두 경우에는 반드시 OPTIMIZE FULL을 실행해야 합니다. 그래야 현재 지정된 클러스터링 키에 맞춰 테이블 전체 레이아웃이 정리됩니다.

 

OPTIMIZE FULL의 동작 방식

• 만약 이전에 이미 OPTIMIZE FULL을 실행했고, 클러스터링 키 변경이 없다면 → OPTIMIZE FULL은 일반 OPTIMIZE와 동일하게 동작합니다.
• 이 경우에는 증분 방식이 적용되어, 아직 컴팩션(compaction)이 되지 않은 파일만 다시 쓰게 됩니다.
• 따라서 불필요하게 모든 파일을 재작성하지 않아 비용이 절감됩니다.

권장사항

항상 클러스터링 키 변경 시점에는 OPTIMIZE FULL을 실행해 데이터 레이아웃이 현재 클러스터링 키를 정확히 반영하도록 하는 것이 중요합니다.

 

---

클러스터링된 테이블에서 데이터 읽기

클러스터링이 적용된 Delta 테이블은 Deletion Vector(삭제 벡터)를 읽을 수 있는 Delta Lake 클라이언트라면 정상적으로 조회할 수 있습니다. 만약 Apache Iceberg를 사용하는 경우에는 Iceberg REST Catalog API를 통해 클러스터링된 테이블의 데이터를 읽을 수 있습니다.

 

SQL 예제

SELECT * 
FROM table_name 
WHERE cluster_key_column_name = "some_value";

 

위 예시처럼, 클러스터링 키를 조건절(WHERE)에 활용하면 데이터 스키핑 효과가 극대화되어 쿼리 성능이 향상됩니다.

 

---

클러스터링 키 변경하기

Liquid Clustering의 장점 중 하나는 운영 중에도 클러스터링 키를 언제든지 변경할 수 있다는 것입니다. 아래 예시처럼 ALTER TABLE 명령어를 실행하면 됩니다.

ALTER TABLE table_name CLUSTER BY (new_column1, new_column2);

 

 

• 클러스터링 키를 변경하면, 이후의 OPTIMIZE 작업과 새로운 쓰기 작업부터 새로운 클러스터링 방식을 사용합니다.
• 단, 기존 데이터는 다시 쓰이지 않습니다.

---

클러스터링 해제하기

클러스터링을 완전히 해제하려면 CLUSTER BY NONE 구문을 사용합니다.

ALTER TABLE table_name CLUSTER BY NONE;

 

 

• CLUSTER BY NONE으로 설정하면 기존에 이미 클러스터링된 데이터는 그대로 유지됩니다.
• 다만, 이후 실행되는 OPTIMIZE 작업은 더 이상 클러스터링 키를 사용하지 않게 됩니다.

 

👉 정리하자면,

• ALTER TABLE ... CLUSTER BY (...) → 새로운 클러스터링 키 지정 (기존 데이터는 그대로)
• ALTER TABLE ... CLUSTER BY NONE → 클러스터링 해제 (향후 OPTIMIZE에서 클러스터링 사용 안 함)

이처럼 Liquid Clustering은 테이블 운영 중에도 데이터 전체를 다시 쓰지 않고 유연하게 키를 변경하거나 해제할 수 있는 점이 큰 강점입니다.

 

---

외부 엔진에서 Liquid Clustering 사용하기

Databricks에서는 관리형 Iceberg 테이블에 대해 외부 Iceberg 엔진을 통해서도 Liquid Clustering을 활성화할 수 있습니다. 이 경우 테이블 생성 시 파티션 컬럼을 지정하면 Unity Catalog가 해당 컬럼을 클러스터링 키로 해석합니다.

 

1. Liquid Clustering 활성화하기

아래 예시는 OSS Spark에서 Iceberg 테이블을 생성하면서 c1 컬럼을 파티션으로 지정한 경우입니다. Unity Catalog는 이를 클러스터링 키로 사용합니다.

CREATE OR REPLACE TABLE main.schema.icebergTable
PARTITIONED BY c1;

 

 

2. Liquid Clustering 비활성화하기

클러스터링을 끄고 싶다면, 지정된 파티션 필드를 삭제하면 됩니다.

ALTER TABLE main.schema.icebergTable DROP PARTITION FIELD c2;

 

3. 클러스터링 키 변경하기 (Partition Evolution)

Iceberg의 Partition Evolution 기능을 활용하면 새로운 파티션 컬럼을 추가하여 클러스터링 키를 변경할 수 있습니다.

ALTER TABLE main.schema.icebergTable ADD PARTITION FIELD c2;

 

4. Bucket Transform 사용 시

만약 파티션을 bucket 변환으로 지정하면, Unity Catalog는 변환식을 버리고 해당 컬럼 자체를 클러스터링 키로 사용합니다.

CREATE OR REPLACE TABLE main.schema.icebergTable
PARTITIONED BY (bucket(c1, 10));

 

👉 요약하면, 외부 Iceberg 엔진을 통해 관리형 Iceberg 테이블을 생성하거나 수정할 때, 파티션 컬럼은 자동으로 Liquid Clustering 키로 해석되며, 필요에 따라 추가/삭제/변경이 가능합니다.

 

---

테이블의 클러스터링 확인하기

Liquid Clustering이 적용된 테이블이 어떤 컬럼을 기준으로 클러스터링 되어 있는지 확인하려면 DESCRIBE 명령어를 사용하면 됩니다.

 

SQL 예제

-- 테이블의 기본 정보 확인
DESCRIBE TABLE table_name;

-- 테이블 상세 정보 확인 (클러스터링 키 포함)
DESCRIBE DETAIL table_name;

 

 

• DESCRIBE TABLE : 테이블의 메타데이터와 구조를 보여줍니다.
• DESCRIBE DETAIL : 현재 설정된 클러스터링 키(clusteringColumns) 를 포함해 더 자세한 정보를 확인할 수 있습니다.

---

Liquid Clustering 테이블의 호환성

Liquid Clustering이 적용된 테이블은 사용하는 Databricks Runtime(DBR) 버전에 따라 호환성 차이가 있습니다.

 

v2 체크포인트 기본 적용

• DBR 14.1 이상에서 Liquid Clustering으로 생성된 테이블은 기본적으로 v2 체크포인트를 사용합니다.
• v2 체크포인트가 적용된 테이블은 DBR 13.3 LTS 이상에서 읽기 및 쓰기가 가능합니다.

구버전 호환성 (다운그레이드)

• 만약 DBR 12.2 LTS 이상에서 Liquid Clustering 테이블을 읽어야 하는 경우,
  • v2 체크포인트를 비활성화하고
  • 테이블 프로토콜을 다운그레이드해야 합니다.
• 관련 방법은 Drop a Delta Lake table feature and downgrade table protocol 문서를 참고하면 됩니다.

---

Liquid Clustering의 제약사항

Liquid Clustering은 강력한 기능을 제공하지만, Databricks Runtime 버전 및 스토리지 포맷에 따라 몇 가지 제한이 존재합니다.

 

1. DBR 15.1 이하

• 클러스터링을 쓰기 시점에 적용할 때, 소스 쿼리에 필터, 조인, 집계 연산이 포함되어 있으면 지원되지 않습니다.

2. DBR 15.4 LTS 이하

• Structured Streaming을 사용해 Liquid Clustering이 활성화된 새로운 테이블 생성은 불가능합니다.
• 다만, 이미 Liquid Clustering이 적용된 테이블에 스트리밍 데이터를 추가로 쓰는 것은 가능합니다.

3. 관리형 Iceberg 테이블

• Row-level concurrency(행 단위 동시성 제어)를 지원하지 않습니다.
• 이는 Iceberg 테이블이 Deletion Vector와 Row Tracking 기능을 지원하지 않기 때문입니다.