Doris 提供了哪些常见的数据导入方式？（如 Stream Load、Broker Load、Routine Load、Insert Into）请对比它们的适用数据源、控制粒度与性能特点

Doris 提供了哪些常见的数据导入方式？（如 Stream Load、Broker Load、Routine L...

Apache Doris 提供了非常丰富且灵活的数据导入（Load）机制，以适应各种不同的业务场景（如实时流计算、离线批处理、内部数据转换等）。所有的导入方式在 Doris 内部都由统一的事务管理系统控制，保证了数据的 原子性（Atomicity） 和 一致性（Consistency）。

以下是您提到的四种最常见数据导入方式的详细对比，包括它们的适用数据源、控制粒度与性能特点：

1. Stream Load

Stream Load 是一种同步的导入方式。用户通过 HTTP 协议发送请求，将本地文件或数据流直接推送到 Doris 中。

适用数据源：
- 本地文件（CSV, JSON, Parquet, ORC 等）。
- 流式计算框架（如 Flink, Spark）。
- 自定义程序（通过 Java, Python, Shell 脚本调用 HTTP API）。
控制粒度：
- 微批处理（Micro-batch）级别。
- 支持两阶段提交（2PC），允许用户在应用端（如 Flink 端）精确控制事务，实现 Exactly-Once 语义。
- 可以通过 HTTP Header 灵活指定字段映射、过滤条件、分隔符等。
性能特点：
- 极高的吞吐与低延迟：直接将数据发往 Doris 的 BE（Backend）节点，无需经过中间存储介质。
- 高并发：非常适合高频率、小/中数据量（建议单次请求在 1MB ~ 2GB 之间）的实时写入。
- 注意： 不建议单条数据逐条调用 Stream Load，这会导致 Doris 内部产生过多的小文件（版本）。

2. Broker Load (及 S3 Load / HDFS Load)

Broker Load 是一种异步的导入方式。Doris 通过内部的调度，主动去远端存储拉取海量数据进行并行导入。

适用数据源：
- 分布式文件系统：HDFS。
- 对象存储：AWS S3, 阿里云 OSS, 腾讯云 COS 等。
控制粒度：
- 宏批处理（Large Batch）级别 / 任务级别。
- 用户通过 SQL 提交一个 LOAD 任务，Doris FE 会生成异步任务并返回 Job ID，用户通过 SHOW LOAD 查看进度。
- 支持任务级别的重试、超时设置、最大错误容忍率（max_filter_ratio）。
性能特点：
- 极致的批量吞吐能力：Doris 的多个 BE 节点会并发从远端存储拉取数据、解析、构建索引并写入。
- 适合处理数十 GB 到 TB 级别的单次历史数据初始化或每日离线数据跑批。
- 注意： 在 Doris 较新版本中，直接使用 S3/HDFS TVF（表函数）配合 Insert Into 的方式越来越普及，逐渐取代传统的 Broker Load，但核心逻辑依然是 Doris 主动拉取分布式存储数据。

3. Routine Load

Routine Load 是一种常驻的、异步的流式导入方式。Doris 作为一个 Consumer 直接订阅消息队列中的数据。

适用数据源：
- Apache Kafka（最主要的数据源）。
- 数据格式通常为 JSON 或 CSV。
控制粒度：
- 消息/Partition 级别。
- Doris 内部自动管理 Kafka 的 Offset，保证 Exactly-Once 语义。
- 用户只需提交一次 SQL 作业，Doris 会持续不断地拉取数据，即使集群重启，作业也会自动恢复。
性能特点：
- 自动化与低运维成本：省去了中间件（如 Flink/Logstash）的部署，Doris 直接对接 Kafka。
- 稳定的流式吞吐：BE 节点会根据 Kafka 的 Partition 数量自动分配并发度，性能优异。
- 适合日志收集、业务埋点等持续不断生成的数据流。

4. Insert Into

Insert Into 是符合标准 SQL 语法的导入方式。在 Doris 中，它分为 INSERT INTO ... VALUES 和 INSERT INTO ... SELECT 两种截然不同的场景。

适用数据源：
- VALUES：手工测试输入的少量数据。
- SELECT：Doris 内部表，或者通过 Multi-Catalog 映射的外部表（如 Hive, Iceberg, Hudi, MySQL, Elasticsearch 等）。
控制粒度：
- 表 / 分区 / 行级别。
- 同步执行，SQL 执行成功即代表数据可见。
- 可以在 SELECT 子句中利用 SQL 进行极其复杂的逻辑计算、Join、聚合。
性能特点：
- INSERT INTO ... VALUES：性能极差，强烈禁止在生产环境中高频使用它来单条插入数据，这会导致底层生成海量的数据版本，引发 Compaction 灾难和查询超时。
- INSERT INTO ... SELECT：性能极好。它是 Doris 进行数据清洗（ETL/ELT）、内部数仓分层（ODS -> DWD -> DWS）的最主要手段。结合 Doris 的向量化执行引擎，可以极其快速地处理百亿级别的数据转换。也常用于从外部数据湖（Hive/Iceberg）快速抽取数据到 Doris 内部。

总结与选型对比表

导入方式	工作模式	核心适用数据源	数据量/频率	典型业务场景
Stream Load	同步 PUSH	Flink, 本地文件, 应用程序 API	1MB2GB / 次秒级分钟级延迟	实时数仓，Flink 处理后写入 Doris，实时业务数据同步。
Broker Load	异步 PULL	HDFS, S3, OSS	数十GB~TB级 / 次小时级/天级	离线数仓，海量历史数据初始化，T+1 每日离线跑批。
Routine Load	异步持续拉取	Kafka	持续无界数据流秒级延迟	日志分析，行为埋点收集，无需流计算引擎直连 Kafka。
Insert Into	同步 SQL执行	内部表(ELT), 外部Catalog(Hive/MySQL)	依赖 SELECT 数据量	数仓内部分层流转（dbt整合），外部数据湖快速导入。

最佳实践建议：

如果您的架构中已经有了 Flink，请毫不犹豫地使用 Flink-Doris-Connector（底层基于 Stream Load）。
如果您只有 Kafka，不想写代码也不想部署 Flink，直接用 Routine Load。
如果您需要定时把 Hive/数据湖 的数据灌入 Doris 加速，使用 Multi-Catalog 配合 INSERT INTO ... SELECT。
千万不要在代码里用 for 循环执行 INSERT INTO table VALUES (...)。

播面