📚 课程目录第4章技术选型与工具链

4. 技术选型与工具链：OLAP引擎、ETL工具、调度系统

技术选型这事儿，说白了就是「没有银弹」。我在不同公司做过三套数据集市，每次选型都不一样。业务规模、团队能力、甚至老板的偏好，都会影响最终决策。这一章我把自己的选型思路和踩坑经验摊开来讲，希望能帮你少走弯路。

核心原则：选型不是选「最好的」，而是选「最适合当前阶段」的。别为了炫技引入团队hold不住的技术栈。

4.1 OLAP引擎三巨头：ClickHouse、Doris、StarRocks

OLAP引擎是数据集市的「发动机」。数据查得快不快，就看它了。目前国内最主流的三款，我挨个说说。

4.1.1 ClickHouse：单表查询之王

ClickHouse的列式存储和向量化执行引擎，让它在单表聚合查询上几乎无敌。我曾在一次实时报表项目中，用ClickHouse把原本跑30秒的SQL优化到了200毫秒——嗯，当时业务方都以为我开了挂。

适合场景：

大宽表、单表聚合查询
日志分析、用户行为轨迹
对实时写入要求不高的场景

注意：ClickHouse的Join性能是硬伤。我遇到过几次多表关联查询，直接导致内存溢出。如果你业务中大量使用Join，建议慎重考虑。

4.1.2 Apache Doris：MPP架构的均衡派

Doris（现在叫StarRocks的前身）走的是MPP路线，天然支持多表Join。它的查询优化器做得不错，能自动选择最优执行计划。我个人习惯把Doris用在需要复杂关联分析的场景，比如财务对账、多维度交叉分析。

核心优势：

支持标准MySQL协议，迁移成本低
物化视图自动刷新，省心
高并发点查询表现稳定

4.1.3 StarRocks：Doris的进化版

StarRocks是从Doris fork出来的，但发展速度很快。它引入了CBO（基于成本的优化器）和更激进的向量化技术。我在做实时大屏项目时对比过，StarRocks在复杂查询上的响应速度比Doris快15%-20%。

对比维度	ClickHouse	Doris	StarRocks
单表查询	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
多表Join	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
实时写入	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
运维复杂度	⭐⭐	⭐⭐⭐	⭐⭐⭐
社区活跃度	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐

我的建议：如果团队刚起步，优先选StarRocks。它兼容Doris生态，性能更好，而且文档中文支持完善。ClickHouse适合作为「查询加速器」配合其他引擎使用。

4.2 ETL工具链：DataX、Kettle、Flink CDC

ETL是数据集市的「搬运工」。数据从源端到目标端，中间要经过抽取、清洗、转换。我见过太多团队在ETL环节翻车——不是数据对不上，就是跑着跑着挂了。

4.2.1 DataX：离线批量同步的瑞士军刀

DataX是阿里巴巴开源的离线同步工具。它的插件化设计支持几乎所有主流数据源。我在做历史数据迁移时，用DataX一天搬了10TB数据，稳得很。

使用场景：

全量数据迁移
定时批量同步（T+1）
异构数据源之间的数据交换

{
  "job": {
    "content": [
      {
        "reader": {
          "name": "mysqlreader",
          "parameter": {
            "connection": [{"jdbcUrl": ["jdbc:mysql://source:3306/db"], "table": ["orders"]}],
            "column": ["id", "order_no", "amount", "create_time"]
          }
        },
        "writer": {
          "name": "clickhousewriter",
          "parameter": {
            "connection": [{"jdbcUrl": "jdbc:clickhouse://target:8123/dw", "table": "fact_orders"}],
            "column": ["id", "order_no", "amount", "create_time"]
          }
        }
      }
    ],
    "setting": {
      "speed": {"channel": 8}
    }
  }
}

经验之谈：DataX的channel数不是越大越好。我试过开到32个channel，结果把源库打挂了。建议从4开始，逐步往上加，观察源库负载。

4.2.2 Kettle：可视化ETL的老牌选手

Kettle（现在叫Pentaho Data Integration）是图形化ETL工具。它的拖拽式设计对业务人员友好。不过说实话，我在生产环境很少用Kettle——性能一般，而且大数据量下容易OOM。

适合场景：

快速原型开发
数据质量校验
小数据量的复杂转换

避坑：Kettle的「内存模式」默认会把所有数据加载到内存。我曾经有个同事没注意这个配置，跑一个5000万行的转换，直接把服务器搞挂了。记得改成「行集模式」。

4.2.3 Flink CDC：实时同步的王者

Flink CDC基于数据库的binlog实现实时数据捕获。它支持Exactly-Once语义，保证数据不丢不重。我在做实时数仓时，用Flink CDC把MySQL的变更实时同步到StarRocks，延迟控制在秒级。

核心优势：

支持全量+增量一体化同步
断点续传，重启不丢数据
与Flink生态无缝集成

// Flink CDC 实时同步示例
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.enableCheckpointing(5000);

DataStreamSource<String> source = env.addSource(
    MySqlSource.<String>builder()
        .hostname("localhost")
        .port(3306)
        .databaseList("order_db")
        .tableList("order_db.orders")
        .username("cdc_user")
        .password("cdc_pass")
        .deserializer(new JsonDebeziumDeserializationSchema())
        .build()
);

source.addSink(StarRocksSink.sink(
    StarRocksSinkOptions.builder()
        .withProperty("jdbc-url", "jdbc:mysql://starrocks:9030")
        .withProperty("load-url", "starrocks:8030")
        .withProperty("database-name", "dw")
        .withProperty("table-name", "fact_orders")
        .build()
));

env.execute("CDC Sync Job");

4.3 调度系统：Airflow vs DolphinScheduler

调度系统是数据集市的「指挥官」。什么时候跑ETL、任务失败了怎么重试、上下游依赖怎么管理，都靠它。

4.3.1 Apache Airflow：生态最丰富的调度器

Airflow用DAG（有向无环图）定义任务依赖，Python原生编写。它的社区非常活跃，几乎你能想到的插件都有。不过，Airflow的部署和维护有点重——需要Celery、Redis、PostgreSQL一堆组件。

优点：

Python生态，扩展性强
丰富的Operator库
调度策略灵活（定时、依赖、传感器）

我的习惯：Airflow适合团队中有Python基础的人。如果团队全是Java工程师，建议别硬上Airflow，否则运维成本会让你崩溃。

4.3.2 Apache DolphinScheduler：国产易用的调度系统

DolphinScheduler是国产开源调度系统，界面友好，支持拖拽式DAG编辑。它的分布式架构天然支持高可用，而且部署简单——一个jar包就能跑起来。

核心特性：

可视化DAG编辑，零代码
支持Shell、SQL、Spark、Flink等多种任务类型
内置告警和失败重试机制
多租户支持，权限管理完善

对比维度	Airflow	DolphinScheduler
部署复杂度	高（需要多个组件）	低（单jar包启动）
任务定义方式	Python代码	可视化拖拽
高可用	依赖外部组件	内置Master-Slave
中文支持	一般	原生中文
社区活跃度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐

选型建议：如果团队规模小、追求快速上线，选DolphinScheduler。如果团队有Python功底、需要深度定制，选Airflow。我个人在中小团队更倾向DolphinScheduler——省心。

4.4 工具链整合：一个完整的选型方案

说了这么多，给一个我实际用过的组合方案，供你参考：

OLAP引擎：StarRocks（主）+ ClickHouse（加速层，用于大宽表查询）
离线ETL：DataX（批量同步）+ DolphinScheduler（调度）
实时ETL：Flink CDC（实时同步）+ StarRocks（实时写入）
数据质量：Kettle（用于数据校验和补录）

这套方案我在两家公司验证过，支撑了日均千万级的数据处理量。当然，具体到你自己的场景，还是要做POC验证。毕竟，别人的经验只能参考，自己的坑才记得牢。