다른 OLAP 시스템에서 Doris로 마이그레이션
ClickHouse, Greenplum 및 레이크하우스 테이블은 각각에 해당하는 Catalog를 통해 Doris로 복사할 수 있습니다. 대상 모델을 선택하기 전에 스냅샷, 업데이트, 집계의 동작 방식을 정의하세요. 소스 스토리지 엔진의 동작을 완전히 재현하는 Doris 구성이 자동으로 제공되지는 않습니다.
마이그레이션 경로 및 사전 요구 사항
| 소스 | 연결 및 옵션 참조 문서 | 마이그레이션 전 확인 사항 |
|---|---|---|
| ClickHouse | ClickHouse JDBC Catalog | 드라이버, 부호 없는 정수, 날짜·시간 및 복합 타입 매핑 |
| Greenplum | PostgreSQL JDBC Catalog | 호환되는 드라이버, 실제 메타데이터, 분산 내보내기의 일관성 |
| Hive | Hive Catalog | Metastore, 파일 스토리지, 인증, 파티션 |
| Iceberg | Iceberg Catalog | 메타데이터 서비스, 스토리지 권한, 일관된 스냅샷 |
| Hudi | Hudi Catalog | 테이블 유형, 조회 가능한 뷰, 기반 파일, 쿼리 제한 사항 |
모든 FE/BE에서 필요한 서비스, 드라이버, 스토리지에 접근할 수 있어야 합니다. 각 Catalog의 참조 문서에 따라 Catalog를 구성하고, 외부 테이블 읽기와 대상 생성 및 데이터 적재 권한이 있는 Doris 계정을 사용하세요.
ClickHouse
JDBC Catalog를 사용하고 INSERT INTO ... SELECT에서 컬럼을 명시하세요. 먼저 DESC를 실행하세요. 권장 대상 설계가 실제 JDBC 매핑과 일치하는 것은 아닙니다. 예를 들어, Catalog는 ClickHouse FixedString을 CHAR에 직접 매핑한다고 보장하지 않습니다. 실제 사용하는 드라이버와 Doris 버전에서 Map/Tuple 및 기타 복합 타입의 지원 여부를 테스트하세요.
ReplacingMergeTree, CollapsingMergeTree 및 집계 상태 테이블의 경우, 최종적으로 조회되는 행, 버전 컬럼, 삭제 마커, 병합 규칙을 명확히 정의하세요. Doris Unique Key 테이블이 소스 엔진의 모든 동작 방식을 자동으로 재현하지는 않습니다. NULL, 최댓값·최솟값의 동률 처리, 배열 확장, JSON 문자열 추출과 관련된 SQL 차이를 테스트하세요.
Greenplum
실제 Greenplum 매핑을 확인하면서 PostgreSQL 마이그레이션의 배치 워크플로를 따르세요. 병렬 내보내기와 SQL 배치는 일관된 소스 뷰를 공유해야 합니다. 동시 실행만으로는 여러 테이블에 걸친 스냅샷이 보장되지 않습니다.
데이터 레이크
Hive, Iceberg, Hudi에 해당하는 Catalog를 사용하세요. 마이그레이션 중에는 사용할 Iceberg 스냅샷을 고정하세요. Hudi의 경우 어떤 뷰를 읽는지, 배포된 버전이 어떤 테이블 유형을 지원하는지 확인하세요. Catalog를 생성하면 외부 데이터에 접근할 수 있게 될 뿐, Doris에 복사본이 생성되지는 않습니다.
기본 사용법
source_catalog가 앞에서 설명한 대로 구성되어 있고, analytics.migration_demo에 id BIGINT와 value DECIMAL(12,2)가 있으며 소스 스냅샷이 고정되어 있다고 가정합니다. DESC로 이 타입들을 확인한 다음 Doris에서 다음을 실행하세요.
CREATE DATABASE IF NOT EXISTS migration_target;
CREATE TABLE migration_target.olap_demo (
id BIGINT,
`value` DECIMAL(12,2)
)
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES ('replication_num' = '1');
INSERT INTO migration_target.olap_demo (id, `value`)
SELECT id, `value` FROM source_catalog.analytics.migration_demo;
SELECT COUNT(*), SUM(`value`) FROM source_catalog.analytics.migration_demo;
SELECT COUNT(*), SUM(`value`) FROM migration_target.olap_demo;
예상 결과: 비어 있는 대상 테이블에 소스 스냅샷에서 선택한 두 컬럼의 데이터가 적재되고, 두 검증 쿼리에서 행 수와 합계가 동일하게 반환됩니다. 복제본 하나와 버킷 하나는 예시입니다. 운영 테이블의 규모는 리소스와 안정성을 고려해 결정하세요. 입력 데이터가 고정된 전체 예제는 MySQL 또는 PostgreSQL을 참조하세요.
기타 데이터 적재 방법
직접 연결할 수 없다면 지원되는 형식의 파일로 내보낸 뒤 S3 Load 또는 Broker Load를 사용하세요. 데이터 적재 규모를 늘리기 전에 파일 형식, 인코딩, NULL 표현 방식, 정밀도, 시간대를 정하세요.
Spark Connector 또는 Flink Connector를 사용할 수도 있습니다. 각 Connector의 참조 문서에 따라 배치/스트리밍 기능, 호환 버전, 동작 방식을 확인하세요.
오류 및 모범 사례
배치 크기나 동시 실행 수를 늘리기 전에 범위를 한정한 샘플로 검증하세요. 지원되지 않는 타입은 명시적으로 변환하고, 컬럼을 건너뛰는 대신 정밀도 손실을 점검하세요. Duplicate Key 대상 테이블에 INSERT를 반복 실행하면 중복 행이 추가됩니다. 다시 시작하기 전에 완료된 범위를 확인하세요. 전환 전에 마이그레이션 개요의 시스템 간 검증을 완료하고, 소스 데이터와 롤백 경로를 유지하세요.