본문으로 건너뛰기
색인되지 않은 문서
이 문서는 색인되지 않습니다. 검색 엔진이 이 문서를 색인하지 않으며, 주소를 알고 있는 사용자만 접근할 수 있습니다.
최종 수정: 에

Binlog / Table Stream

요약 Apache Doris Table Stream은 MySQL binlog를 읽는 것처럼 Doris 테이블에서 행 수준 변경 사항(삽입, 업데이트, 삭제)을 읽을 수 있도록 제공될 공개 API입니다. 행 형식 binlog, 파티션별 오프셋을 고정하는 STREAM 객체, 소비 메타데이터 등 기반 구성 요소는 이미 코드베이스에 구현되어 있습니다. 이 기능은 아직 GA 단계가 아니며, 기본 binlog.ttl_seconds는 86,400초(하루)입니다. Doris에서 변경 데이터를 내보내는 일반적인 CDC 용도로는 Flink Doris Connector를 사용하세요. 상태: 출시 예정(미리 보기).

Apache Doris Binlog / Table Stream: Doris 테이블이 다운스트림 소비자에게 제공할 행 수준 변경 피드.

상태: 출시 예정

여기서 설명하는 STREAM 객체, binlog.format = ROW, 소비 메타데이터 뷰는 Doris 소스 트리에 구현되어 있지만, 아직 사용자를 위한 안정적인 API로 출시되지는 않았습니다. GA 이전에 구문과 동작 방식이 변경될 수 있습니다. 현재 프로덕션 CDC 파이프라인에서는 Kafka 및 CDC 통합을 사용해야 합니다.

Apache Doris에서 binlog와 테이블 스트림을 사용하는 이유는 무엇인가요?​

Apache Doris binlog와 테이블 스트림은 다운스트림 소비자에게 행 수준 변경 피드를 제공하므로, Flink 작업, 감사 로그 또는 검색 인덱스가 테이블을 다시 읽지 않고도 모든 삽입, 업데이트, 삭제에 대응할 수 있습니다. Apache Doris는 변경 데이터 수집에 강점이 있습니다. 하지만 변경 데이터를 다시 외부로 내보내기는 더 어렵습니다. 다운스트림 시스템(Flink 작업, 감사 로그, 다른 Doris 클러스터, 검색 인덱스)이 모든 삽입, 업데이트 및 삭제에 대응해야 한다면, 현재 사용할 수 있는 방법은 번거롭습니다.

  • 주기적으로 테이블을 다시 읽고 차이를 비교합니다. 구현은 간단하지만 실행 비용이 높고 실시간으로 처리할 수 없습니다.
  • 데이터 생성 측에서 Kafka와 Doris에 이중으로 기록합니다. 대상이 둘이므로 장애 발생 지점도 둘입니다.

Binlog와 Table Stream은 이 공백을 메웁니다. binlog는 커밋된 모든 변경 사항을 행 수준으로 기록합니다. Table Stream은 이 로그를 가리키는 이름 있는 커서입니다. 소비자는 스트림에 연결하여 마지막 오프셋 이후의 변경 사항을 읽고 처리 완료를 알립니다. MySQL binlog, Snowflake Streams, Postgres 논리 복제 슬롯과 같은 개념을 Doris의 정식 객체로 구현한 것입니다.

Apache Doris binlog와 테이블 스트림이란 무엇인가요?​

Apache Doris binlog는 Doris가 유지하는 테이블별 변경 로그이며, Apache Doris 테이블 스트림은 이 로그를 행 수준 CDC로 제공하는 소비자용 객체입니다. binlog에는 두 가지 형식이 있습니다. STATEMENT_AND_SNAPSHOT은 DDL과 스냅샷을 기록하고, ROW는 범용 CDC 소비자를 위해 커밋된 모든 행 변경분을 기록합니다.

테이블 스트림은 행 형식 binlog 위에 구축된 소비자용 객체입니다. 스트림은 CREATE STREAM <name> ON <base_table>로 생성되며, 자체적인 파티션별 오프셋을 유지합니다. 또한 SQL 인터페이스로 SHOW CREATE STREAM과 소비 진행 상황을 보여 주는 information_schema 뷰를 제공합니다.

주요 용어

  • binlog.enable: 테이블별 속성입니다. true로 설정하면 해당 테이블의 binlog가 활성화됩니다.
  • binlog.format: 테이블별 속성입니다. STATEMENT_AND_SNAPSHOT은 DDL과 스냅샷을 기록하며, ROW는 Table Stream이 소비하는 행 변경분 형식입니다.
  • binlog.ttl_seconds / binlog.max_bytes / binlog.max_history_nums: 보존 설정입니다. 기본 TTL은 하루이며, 바이트 수와 이력 개수 제한은 기본적으로 사실상 무제한입니다.
  • STREAM: 기본 테이블을 감싸고 소비자 하나의 파티션별 오프셋을 추적하는 Doris Catalog 객체입니다.
  • 스트림 소비 유형: default, append_only, min_delta 중 하나입니다. 스트림이 전체 행 변경분, 삽입만 또는 최소 변경 집합 중 무엇을 내보낼지 제어합니다.
  • 스트림 지연: 파티션의 가시 버전에서 스트림에 기록된 오프셋을 뺀 값입니다. LAG 열로 표시됩니다.

Apache Doris binlog와 테이블 스트림은 어떻게 작동하나요?​

Apache Doris binlog는 BE에서 행 수준 변경분을 기록합니다. 테이블 스트림은 이 로그에 파티션별 오프셋을 연결하여, 다운스트림 소비자가 변경 사항을 증분으로 읽고 처리 완료를 알릴 수 있도록 합니다.

  1. binlog를 활성화합니다. ALTER TABLE t SET ("binlog.enable" = "true", "binlog.format" = "ROW"). BE는 binlog.ttl_seconds와 크기 및 이력 개수 제한에 따라 태블릿 데이터와 함께 행 수준 변경분을 보존하기 시작합니다. Table Stream에는 ROW 형식이 필요합니다.
  2. 테이블에 스트림을 생성합니다. CREATE STREAM s ON t PROPERTIES ("type" = "default"). FE는 STREAM 객체를 생성하고, 모든 파티션의 현재 가시 버전을 시작 오프셋으로 저장한 뒤 데이터베이스에 등록합니다. show_initial_rows = true로 설정하면 첫 번째 읽기에서 과거 상태를 반환하도록 동작이 바뀝니다.
  3. 소비합니다. 다운스트림 리더(현재는 외부 CDC 커넥터, 향후에는 네이티브 소비자 엔드포인트)가 스트림에서 데이터를 읽습니다. 각 배치는 파티션별 오프셋을 앞으로 이동시키고 소비 시각을 기록합니다.
  4. 정리합니다. 모든 활성 스트림이 binlog 항목을 지나갔고 해당 항목이 binlog.ttl_seconds보다 오래되면, BE가 가비지 컬렉션으로 이를 제거합니다. 보존 범위를 벗어날 만큼 뒤처진 스트림에는 사유와 함께 IS_STALE = true가 표시됩니다.
  5. 관찰합니다. information_schema.table_streams는 모든 스트림과 해당 기본 테이블을 나열합니다. table_stream_consumption은 파티션별로 UNIT(파티션), CONSUMPTION_STATUS, LAG, LAST_CONSUMPTION_TIME을 보고합니다. 이를 지연 현황 대시보드로 사용할 수 있습니다.

빠른 시작​

-- 1. Enable row-format binlog on the source table
ALTER TABLE orders SET (
  "binlog.enable" = "true",
  "binlog.format" = "ROW",
  "binlog.ttl_seconds" = "86400"
);

-- 2. Create a Table Stream over it (planned syntax, subject to change)
CREATE STREAM orders_cdc ON orders
PROPERTIES ("type" = "default", "show_initial_rows" = "false");

-- 3. Inspect the stream and its lag
SHOW CREATE STREAM orders_cdc;
SELECT * FROM information_schema.table_stream_consumption
WHERE STREAM_NAME = 'orders_cdc';

예상 결과

+---------+------------+-----------+--------------------+-----+----------------------+
| DB_NAME | STREAM_NAME| STREAM_ID | UNIT (partition)   | LAG | LAST_CONSUMPTION_TIME|
+---------+------------+-----------+--------------------+-----+----------------------+
| sales   | orders_cdc | 10042     | p_2026_05          | 0   | 2026-05-09 10:14:33  |
+---------+------------+-----------+--------------------+-----+----------------------+

LAG = 0은 소비자가 파티션의 가시 버전까지 따라잡았다는 뜻입니다. 업스트림에서 쓰기가 커밋되면 LAG가 증가하고, 소비자가 데이터를 읽으면 감소합니다. N/A가 아닌 STALE_REASON 값은 보존 범위가 오프셋을 지나갔으며 스냅샷을 다시 생성해야 한다는 뜻입니다.

Apache Doris binlog와 테이블 스트림은 언제 사용해야 하나요?​

GA 이후에는 다운스트림 시스템이 전체 테이블을 다시 읽지 않고 Doris 테이블의 행 수준 변경 이벤트를 받아야 할 때 Apache Doris binlog와 테이블 스트림을 사용하세요.

적합한 용도(GA 이후)

  • 테이블을 다시 읽지 않고 Doris 측 변경 이벤트로 다운스트림 Flink 또는 Spark 작업을 구동하는 경우.
  • 모든 삽입과 삭제를 반영해야 하는 외부 검색 인덱스, 캐시 또는 감사 로그를 유지하는 경우.
  • 명시적인 소비자 오프셋이 필요한 Doris 간 복제.
  • 파티션의 LAG가 변경될 때 외부 구체화된 뷰의 재계산을 트리거하는 경우.

적합하지 않은 용도(특히 현재)

  • 현재 시점의 프로덕션 CDC 파이프라인. STREAM 객체는 소스 트리에 있지만 GA로 발표되지 않았습니다. 대신 Kafka 및 CDC 통합을 사용하세요.
  • binlog 보존 기간이 짧은 환경에서 장기간 중지되는 소비자. LAG가 binlog.ttl_seconds로 보존되는 범위를 넘어서면 스트림이 오래된 상태가 되어 소비자 데이터를 다시 초기화해야 합니다.
  • 스토리지와 컴퓨팅이 분리된 클러스터. 해당 환경에서 Table Stream을 지원하는 방식은 아직 개발 중입니다.
  • 외부 Catalog 테이블(Hive, Iceberg) 읽기. Table Stream은 내부 OLAP 테이블만 대상으로 합니다.

더 읽어보기​

  • Kafka 및 CDC 통합: 현재 Doris로 변경 데이터를 가져오고 관련 시스템 간에 전달하는 데 사용할 수 있는 공식 지원 방식입니다.
  • 데이터 업데이트 및 삭제: Unique Key Merge-on-Write 테이블이 행 스트림에 담길 삭제와 순서가 뒤바뀐 업데이트를 표현하는 방식입니다.
  • Iceberg: 복제된 테이블의 외부 대상입니다. Doris를 벗어나지 않고 SQL을 통해 CDC 데이터를 Iceberg에 저장할 수 있습니다.
  • Unique Key: 다운스트림 binlog 소비자를 위해 키당 하나의 행으로 상태를 명확하게 표현하는 업스트림 테이블 모델입니다.
Report issue