去年跟一个做数仓架构的朋友吃饭，他说了一句话让我印象很深："现在选数仓，跟买车似的——以前只有轿车和 SUV 两种，现在轿车、SUV、MPV、皮卡、新能源、增程、纯电，销售跟你说啥都行，但你买回去停不进车库就尴尬了。"

2026 年的数据仓库市场，确实到了这个阶段。MPP 数仓、湖仓一体、实时数仓各家都在喊"全覆盖"，但你仔细一看，有的在 MPP 上深耕了十年，有的在实时场景下积累了上千案例，有的刚把湖仓架构跑通。选型不看"基因"，很容易买一个"什么都有但什么都不精"的万金油。

这篇文章把数仓选型拆成两层——管道层（数据怎么进来）和引擎层（数据怎么存和算）——逐条路线、逐家产品讲清楚，再给企业选型建议。

一、管道层：数据进不来，引擎再好也是空壳

很多企业花了三个月选数仓引擎，选完才发现数据接不进来——ERP 跑在 Oracle 上，CRM 在 MySQL 里，门店数据在 Excel 里，日志在 Kafka 里，供应商数据走 API。数仓再强，数据源接不通，就是个空壳。

管道层按场景分两派：批量 ETL/ELT 管道（定时抽取、清洗、写入）和实时 CDC 管道（基于日志的增量同步）。大部分企业两条都用得上——核心业务数据走批量，高时效场景走实时。

FineDataLink：低代码一站式集成，管道直通分析和应用

出身：帆软旗下企业级数据集成平台，已服务 1000+ 客户，获 CMMI 5 认证。和 FineBI、FineReport、简道云天然融合。

核心能力：60+ 种数据源对接，ETL+ELT 双核引擎，1 千万行数据同步约 25 秒。实时管道基于 CDC 日志解析实现毫秒级增量同步，自动跟踪源表 DDL 变更。五分钟零代码发布 Restful API，支持血缘追踪和全生命周期管理。质量管控包括脏数据上限管理、失败自动重跑、多渠道异常通知。国产化适配覆盖达梦、OceanBase、GaussDB、人大金仓等国产数据库及星环 ArgoDB、YMatrix 等大数据平台，支持离线私有化部署。

和引擎层的关系：数据同步支持写入 StarRocks、Doris、ClickHouse、GaussDB、Greenplum、Hive、Kafka 等主流引擎。如果企业已在用帆软 BI 或报表工具，到分析应用的数据链路几乎零摩擦。

一句话选型判断：帆软生态用户的首选管道；混合数据源+国产化+低门槛运维的通用方案。

Kettle（Pentaho Data Integration）：开源 ETL 常青树

出身：最早由 Pentaho 开源，国内有大量存量用户和社区积累。

核心能力：图形化拖拽设计 ETL 流程，支持上百种数据库和文件格式，插件生态丰富。纯 Java 实现，跨平台部署方便。

短板：单机架构在大数据量场景下性能瓶颈明显，缺乏原生的实时同步和 CDC 能力，集群和分布式支持需要额外改造。社区版功能有限，企业版需要付费。

一句话选型判断：存量 Kettle 脚本多、不想折腾迁移的团队；对性能要求不极端的传统 ETL 场景。

Apache SeaTunnel：新一代高性能数据集成引擎

出身：Apache 孵化项目，由白鲸开源主导，定位是"下一代数据集成平台"。

核心能力：支持 100+ 种数据源，分布式架构原生支持海量数据同步，支持批流一体。连接器插件化设计，新增数据源只需开发对应连接器。活跃的社区迭代速度很快。

短板：相对年轻，生产环境的大规模验证案例不如 Kettle 和 DataX 丰富。监控和运维工具链仍在完善中。部分连接器的稳定性和成熟度参差不齐。

一句话选型判断：数据量大、对性能有要求、愿意接受较新技术栈的团队；正在从 DataX 或 Kettle 迁移的团队。

DataX：阿里开源轻量同步利器

出身：阿里巴巴开源，曾是国内最广泛使用的离线数据同步工具。

核心能力：插件式架构，支持主流关系型数据库、NoSQL、大数据平台的读写。单机模式部署简单，资源占用低，在中小数据量场景下稳定可靠。

短板：缺乏原生的实时同步能力，没有可视化管理界面（需要搭配 DataX Web 等第三方工具），调度和监控需要额外配置。社区近年来活跃度下降，阿里内部已转向 SeaTunnel。

一句话选型判断：简单离线同步场景够用、团队已有 DataX 经验的存量项目。新项目建议直接评估 SeaTunnel。

Flink CDC：实时管道的事实标准

出身：Apache Flink 生态下的 CDC 组件，由阿里和社区共同推进。

核心能力：基于数据库 Binlog/WAL 日志的实时增量捕获，支持 MySQL、PostgreSQL、Oracle、MongoDB 等主流数据库。端到端毫秒级延迟，原生支持 Flink SQL 进行流式 ETL 加工，全增量一体化同步。

短板：需要搭建和维护 Flink 集群，运维门槛较高。对数据库版本有要求（如 MySQL 5.6+ 需开启 Binlog），部分老旧数据库无法使用。SQL 加工能力对一些复杂 ETL 逻辑支持有限。

一句话选型判断：已经用 Flink 做流计算的团队，或对实时性要求极高（秒级）的场景。运维能力不够的团队建议用 FineDataLink 这类封装了 CDC 的低代码方案。

二、引擎层：三条技术路线，九个代表玩家

管道层搞定了数据怎么进来，接下来才是数据怎么存、怎么算、怎么查。引擎层按技术路线分成三派。

路线一：MPP 数仓——稳，但天花板可见

MPP（大规模并行处理）架构是最老牌的数仓路线。核心思路是把数据分片到多个节点并行计算，架构成熟、SQL 标准兼容好、运维经验丰富。局限在于存算耦合架构弹性伸缩吃力，对半结构化和非结构化数据支持弱。

StarRocks

国产 OLAP 明星，多表关联查询和物化视图加速业界领先。2026 年重点在做存算分离架构升级和湖仓互通——不想被湖仓一体替代，就得自己具备湖仓原生的能力。生态方面和主流 BI 工具对接成熟，已有数仓团队、需要极致查询性能的 OLAP 场景最适合。

Apache Doris

和 StarRocks 师出同门（百度 Palo），路线相似，2026 年主要差异在社区运营和实时能力的提升上。适合对开源方案有偏好、对社区活跃度敏感的团队。

ClickHouse

列存极致性能的代名词，单表扫描速度快，但多表 JOIN 和复杂 ETL 是短板。更适合"宽表查询"场景——把数据预处理成宽表，然后丢给 ClickHouse 做秒级查询。在实时数仓路线上也有竞争力，但更偏"实时数据库"而非完整数仓。

Snowflake

国外 MPP 的标杆，存算分离架构比传统 MPP 灵活得多，按量付费模式降低了中小企业的使用门槛。但在国内部署受限，数据跨境合规问题需要重点评估。

路线二：湖仓一体——灵活，但成熟度参差不齐

湖仓一体（Lakehouse）是过去三年最热的概念：数据湖的灵活存储 + 数仓的事务和性能 = 一套架构搞定所有数据类型。优势是一份数据支持批处理、流处理、ML 等多种计算引擎，存算分离架构弹性伸缩灵活。局限是需要同时搞定存储层、计算层、元数据层、治理层——每一层的技术选型和调优都够一个团队喝一壶的。

阿里云 MaxCompute + Hologres

国内湖仓一体的标杆组合。MaxCompute 负责海量数据的批处理，Hologres 负责实时交互式查询，Flink 负责流处理。整套组合拳在互联网行业是大规模验证过的，但与阿里云生态深度绑定，离开阿里云几乎无法独立运行。已在阿里云上的互联网企业是集成摩擦最小的选择。

华为云 DWS

主打"湖仓一体 + 信创合规"。与华为云 DLI 数据湖深度协同，在政务云场景的湖仓一体落地案例最多。全栈自研架构——从芯片（鲲鹏）到 OS（欧拉）到数仓——信创方面没有短板。但在弹性伸缩和极致查询性能方面跟 StarRocks、ClickHouse 比还有差距。

腾讯云 DLC

数据湖计算走"Serverless + 湖仓原生"路线。优势在于与腾讯云 AI 生态的协同——数据湖上的数据可以直接被机器学习平台调用，不需要再搬数据。有 AI 团队的公司值得关注。但在传统数仓的 SQL 查询场景下不如 MPP 选手来得直接。

Databricks

湖仓一体的全球鼻祖，Delta Lake + Spark + MLflow 的生态体系在国外已经跑通了大量生产案例。Unity Catalog 统一元数据管理能力业内领先。但在国内的部署和服务支持有限，适合有海外业务且技术能力强的企业。

路线三：实时数仓——快，但场景匹配要求高

实时数仓的核心理念是"数据进来就能查"，延迟从小时级降到秒级。优势在实时大屏、实时风控、实时推荐等场景不可替代。局限是场景限制明显——如果业务分析是"看昨天的报表做今天的决策"，实时数仓的额外成本和复杂度完全没必要。

Hologres

阿里云的实时交互式查询引擎，和 Flink 的集成是独门优势。在实时写入 + 实时查询场景下，端到端延迟能做到秒级。独立部署困难，基本走阿里云一体化路线。适合阿里云生态内对实时性有刚需的场景。

RisingWave

云原生流数据库，专为流式数据处理设计。2026 年仍在快速增长期，社区活跃度高。适合对流处理有极致性能要求、团队愿意接受新兴开源方案的场景。

三、企业选型建议

先判断你在哪个阶段

阶段 A：数据源都接不进来，谈不上选引擎。

核心症状：ERP、CRM、WMS 等业务系统各自孤立，数据靠人工导出 Excel 再导入，口径全靠口头对齐。选型重点在管道层。先把管道搭稳，让各个系统的数据能自动、稳定地汇聚到位。

管道层的快速选型：

● 已有帆软 BI/Report/简道云 → FineDataLink，原厂集成，到分析应用的数据链路几乎零摩擦

● 数据源几十个、ETL 靠 Python 脚本硬撑、换了人就没人敢动 → FineDataLink，60+ 数据源适配器 + 低代码拖拽，把"写脚本维护管道"变成"配置管道"，失败自动重跑、异常多渠道通知

● 需要近实时同步但不想上全套 Flink → FineDataLink CDC 管道，基于数据库日志的毫秒级增量同步，自动跟踪 DDL，不引入流处理引擎的额外运维负担

● 国产数据库 + 传统 Oracle + 云上 MySQL 混在一起，信创有要求但不强制全栈国产 → FineDataLink，达梦/GaussDB/OceanBase/人大金仓 都适配，离线私有化部署

● 存量 Kettle 脚本多 → 继续用 Kettle，不折腾迁移

● 数据量大 + 技术栈新 → SeaTunnel，分布式架构原生优势

● 离线同步够用、团队已有经验 → DataX 轻量够用

● 已有 Flink 集群 + 需要秒级实时 → Flink CDC

阶段 B：数据集中了，但查得太慢、算不动。

核心症状：已有数据仓库或数据集市，但随着数据量增长，查询越来越慢，ETL 跑不动。选型重点在引擎层。TB-PB 级别、全是结构化数据和 SQL 查询 → MPP 路线（StarRocks 或 Doris）。日志、文本、时序数据混在一起，还要跑 ML → 湖仓一体路线（MaxCompute+Hologres 或 DWS）。

阶段 C：业务有实时决策需求。

核心症状：实时风控、实时大屏、实时营销触达，数据晚一分钟就损失真金白银。选型在实时数仓层。阿里云生态 → Flink+Hologres；开源偏好 + 自建 → RisingWave。

阶段 D：信创硬性要求。

核心症状：政务、央国企、金融，必须国产化。两条子路线：必须全栈国产化、安全合规是第一位 → 华为云 DWS；需要国产化但不绑定单一生态 → 国产化管道（FineDataLink/SeaTunnel）+ 国产化引擎（StarRocks/Doris），组合方案兼顾适配和架构弹性。

选型矩阵速览

写在最后

2026 年的数仓选型，核心是分清两层——管道层解决"数据怎么进来"，引擎层解决"数据怎么存和算"。

管道层不是只有一家可选。FineDataLink 适合帆软生态和低门槛诉求，SeaTunnel 适合高性能和大数据量，Kettle 适合存量不折腾，Flink CDC 适合实时极致场景。先按自己的生态和团队能力选管道，再按数据量和查询模式选引擎。

数据量几百 TB、团队 5 个人、全是 SQL 查询——上 StarRocks，别折腾湖仓一体。数据源 30 多个、日志和表格混在一起、AI 团队要拿数据做训练——上湖仓一体，MPP 扛不住这个复杂度。交易风控要 500 毫秒出结果——上实时数仓链路，晚一分钟就是真金白银。

别被厂商的"全场景覆盖"话术带偏。每种场景下的最优解可能不是同一家。也别只盯着引擎层——管道层没选好，再好的引擎也是空壳。

本文基于公开资料及实际经验整理，各厂商产品功能与版本状态可能调整，请以官方最新披露为准。