Other OLAP Systems to Doris

ClickHouse, Greenplum, and lakehouse tables can be copied to Doris through their corresponding catalogs. Define snapshot, update, and aggregation semantics before selecting a target model; source storage engines do not have automatic, complete Doris equivalents.

Routes and prerequisites

Source	Connection and options reference	Checks before migration
ClickHouse	ClickHouse JDBC Catalog	Drivers, unsigned integers, date-time and complex-type mappings
Greenplum	PostgreSQL JDBC Catalog	Compatible driver, actual metadata, and consistency of distributed exports
Hive	Hive Catalog	Metastore, file storage, authentication, and partitions
Iceberg	Iceberg Catalog	Metadata service, storage permissions, and a consistent snapshot
Hudi	Hudi Catalog	Table type, visible view, underlying files, and query limitations

Every FE/BE must reach the required services, drivers, and storage. Configure a catalog following its reference and use a Doris account allowed to read the external table and create/load the target.

ClickHouse

Use the JDBC Catalog and explicit columns in INSERT INTO ... SELECT. Run DESC first; suggested target designs are not the actual JDBC mappings. For example, the catalog does not promise a direct CHAR mapping for ClickHouse FixedString; test Map/Tuple and other complex-type support for the actual driver and Doris version.

For ReplacingMergeTree, CollapsingMergeTree, and aggregate-state tables, establish the final visible rows, version columns, deletion markers, and merge rules. A Doris Unique Key table does not automatically reproduce all source-engine semantics. Test SQL differences involving NULLs, tied extrema, array expansion, and JSON string extraction.

Greenplum

Follow the batch workflow in PostgreSQL migration, checking the actual Greenplum mappings. Parallel exports and SQL batches must share a consistent source view; concurrency alone does not establish a cross-table snapshot.

Data lake

Use the respective Hive, Iceberg, and Hudi catalogs. Pin the intended Iceberg snapshot during migration. For Hudi, establish which view is read and which table types the deployed version supports. Creating a catalog only makes external data accessible; it does not create a Doris copy.

Basic usage

Assume source_catalog is configured as described above and analytics.migration_demo contains id BIGINT and value DECIMAL(12,2), with a fixed source snapshot. Verify these types with DESC, then run in 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;

Expected result: the empty target receives both selected columns from the source snapshot, and the two validation queries return equal row counts and sums. One replica and one bucket are illustrative; size production tables for resources and reliability. See MySQL or PostgreSQL for a complete fixed-input example.

Other loading methods

If a direct connection is unavailable, export supported files and use S3 Load or Broker Load. Establish file formats, encoding, NULL representation, precision, and time zones before scaling the import.

You can also use the Spark Connector or Flink Connector. Follow each connector's reference for batch/streaming capabilities, compatible versions, and semantics.

Errors and best practices

Validate bounded samples before increasing batch sizes or concurrency. Convert unsupported types explicitly and inspect precision loss rather than skipping columns. Repeating INSERT into a Duplicate Key target appends duplicate rows; establish completed ranges before resuming. Complete the cross-system checks in Migration Overview before cutover and retain source data and a rollback route.