Flink Connector 실전

Connector가 왜 중요한가?

Flink는 "계산 엔진"일 뿐이고,

실제 업무에서는 **데이터를 어디서 가져오고(Kafka, Filesystem), 어디에 저장하느냐(ClickHouse, Iceberg, JDBC)**가 파이프라인의 본질을 결정함.

즉,

Flink = 파이프의 중앙 처리부
Connector = 파이프의 입구와 출구

Connector 이해가 바로 파이프라인 설계 능력임.

Connector 전반 개념 정리

Connector는 크게 두 가지로 나뉨:

Source Connector

Kafka, Pulsar, Kinesis
FileSystem(Parquet, CSV), Iceberg
JDBC(읽기)

Sink Connector

ClickHouse, JDBC, Kafka, Iceberg
FileSystem(Parquet/CSV)

중요한 건 Flink Table API/SQL에서는

DDL로 선언만 하면 바로 테이블처럼 다룰 수 있다는 점.

예)

CREATE TABLE orders (...) WITH ('connector' = 'kafka');

이 한 줄로 "Kafka → Flink → SQL로 처리"가 됨.

Kafka Connector

(가장 많이 쓰는 정석 Source/Sink)

Kafka는 Flink에서 사실상 표준 Source임.

Kafka Source 특징

파티션 단위 병렬 처리 → Flink parallelism 자동 확장
event-time 기반 처리에 적합 (timestamp & watermark)
exactly-once 보장 가능 (source offset + state 체크포인트)

Kafka Sink 특징

모니터링 스트림, DLQ(dead-letter), alert pipeline 등에 자주 사용
트랜잭션 기반 exactly-once 지원
key, partition, timestamp 메타데이터도 커스텀 가능

예제 DDL

CREATE TABLE orders (
  order_id STRING,
  user_id STRING,
  ts TIMESTAMP(3),
  WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'orders',
  'properties.bootstrap.servers' = 'kafka:9092',
  'format' = 'json'
);

Kafka는 Flink의 "입구"로 가장 적합한 구조임.

ClickHouse Connector

(실시간 대시보드/OLAP 지표용)

ClickHouse는 Flink Sink로 가장 자주 쓰이며 목적은 단 하나:

"빠르게 조회 가능한 실시간 집계 테이블 만들기"

ClickHouse가 잘하는 것:

대용량 집계, 그룹바이 속도
실시간 대시보드/서비스 통계

ClickHouse Sink 패턴

보통 **집계된 형태(윈도우 결과)**를 넣음
row-level 데이터를 넣는 구조는 거의 없음
INSERT BATCH size, retry 정책이 중요

예제 DDL

CREATE TABLE ch_sales (
  window_start TIMESTAMP(3),
  window_end TIMESTAMP(3),
  category STRING,
  total_amount DOUBLE
) WITH (
  'connector' = 'jdbc',
  'url' = 'jdbc:clickhouse://ch-host:8123/default',
  'table-name' = 'realtime_sales'
);

요약: 대표님이 만드는 5분/10분 매출 집계, 유저 행동 통계 같은 건 ClickHouse가 최적임.

Iceberg Connector

(Data Lake / Analytics / 장기 보관 / 스냅샷 관리)

Iceberg는 "디스크 위의 거대한 테이블"을 관리하는 포맷.

데이터 레이크의 사실상 표준이 되어가는 중.

Iceberg가 필요한 이유:

장기 보관 (수개월~수년)
스키마 진화 지원
대량 데이터 효율적 분할(파티션)
Time-Travel(특정 시점 스냅샷 조회)
Flink/Spark/Trino 등 여러 엔진에서 동시에 조회 가능

Flink + Iceberg 조합은 아래 목적에 최적화됨:

row-level 원본 로그 저장
Fact 테이블 적재
batch/stream 통합 ETL
ML feature store용 원본 데이터

예제 DDL

CREATE TABLE iceberg_orders (
  order_id STRING,
  user_id STRING,
  amount DOUBLE,
  ts TIMESTAMP(3),
  WATERMARK FOR ts AS ts - INTERVAL '10' SECOND
) WITH (
  'connector' = 'iceberg',
  'catalog-name' = 'prod_catalog',
  'catalog-type' = 'hive',
  'warehouse' = 's3://warehouse/'
);

요약: 실시간 ClickHouse는 "지금 보는 지표", Iceberg는 "나중에 분석할 원본 저장소".

JDBC Connector

(레거시 DB/차원 테이블 lookup/단순 적재)

Flink의 JDBC Connector는 안정성은 좋지만 대량 쓰기에는 부적합임.

대량 쓰기 환경에서는 ClickHouse·Iceberg·Kafka가 더 적합함.

JDBC는 아래 상황에 딱 맞음:

Dim table 조회
적은 row에 incremental load
운영 DB에 소규모 로그 삽입
Lookup join으로 enrichment

예제 DDL

CREATE TABLE dim_user (
  user_id STRING,
  grade STRING
) WITH (
  'connector' = 'jdbc',
  'url' = 'jdbc:mysql://mysql:3306/db',
  'table-name' = 'user_dim',
  'username' = 'root',
  'password' = 'root'
);

주의사항:

병렬 Insert는 DB 부하 커짐
Primary Key 기반 upsert만 제대로 활용
트랜잭션 비용 큼 → 운영 DB는 과부하 위험 있으니 대부분은 "reference lookup"용으로만 사용함.

실전: 왜 하나의 Kafka 주문 이벤트를 여러 목적지로 나누는가?

아래는 실제 회사들이 가장 많이 쓰는 패턴.

ClickHouse: "지금 바로 보는 지표"

1분/5분/10분 집계
대시보드
내부 운영툴

Iceberg: "나중에 또 분석할 raw 데이터"

row-level 주문 로그
batch 분석
ML 학습 데이터
Data Lake 저장

모니터링 Kafka: "실시간 이상탐지/알림/다른 팀 소비"

고액 주문 alert
결제 실패 이벤트
위험 패턴 감지

이걸 Flink에서 어떻게 구현?

StatementSet으로 한 번에 처리함.

StatementSet stmt = tableEnv.createStatementSet();
 
stmt.addInsertSql("INSERT INTO ch_sales SELECT ...");
stmt.addInsertSql("INSERT INTO iceberg_orders SELECT ...");
stmt.addInsertSql("INSERT INTO monitor_topic SELECT ...");
 
stmt.execute();

하나의 ordering event가 이렇게 분기되는 것:

Kafka orders
     ├─ 집계 → ClickHouse
     ├─ 원본 row → Iceberg
     └─ 고액/이상 이벤트 → monitoring Kafka

이게 바로 "하나의 소스 → 여러 목적지" 패턴임.

어떤 Connector를 언제 선택하면 좋은가?

간단히 정리하면 아래 기준이면 대부분 해결됨.

실시간 집계/지표 → ClickHouse

장기 보관 / 원본 저장 / BI·ML 분석 → Iceberg

실시간 알림 / 이상탐지 / 확장성 높은 이벤트 브로커 / 외부 팀에서 사용해야하는 데이터 → Kafka

운영 DB에 소규모 참조 / Dim table lookup → JDBC

정리

Flink는 외부 시스템을 Table로 선언해 스트림/배치를 일관된 방식으로 처리
Kafka는 사실상 표준 Source이고, ClickHouse는 실시간 집계 Sink, Iceberg는 장기 보관용 Data Lake Sink, JDBC는 소규모 Lookup/적재에 사용함.
실무에서는 하나의 Kafka 이벤트를 여러 목적지로 보내기 위해 StatementSet을 활용해 ClickHouse·Iceberg·모니터링 Kafka로 동시에 전송하는 구조가 일반적

Flink Connector 실전

Flink Connector 실전

Connector가 왜 중요한가?

Connector 전반 개념 정리

Source Connector

Sink Connector

Kafka Connector

Kafka Source 특징

Kafka Sink 특징

ClickHouse Connector

Iceberg Connector

JDBC Connector

실전: 왜 하나의 Kafka 주문 이벤트를 여러 목적지로 나누는가?

ClickHouse: "지금 바로 보는 지표"

Iceberg: "나중에 또 분석할 raw 데이터"

모니터링 Kafka: "실시간 이상탐지/알림/다른 팀 소비"

이걸 Flink에서 어떻게 구현?

어떤 Connector를 언제 선택하면 좋은가?

정리

공식 문서 출처

댓글