3、技术选型与架构设计：OLAP vs OLTP、MPP数据库选型、Lambda与Kappa架构、数据分层设计
这一章，我们聊聊技术选型和架构设计。说白了，就是决定用什么工具、怎么搭架子。
很多团队一上来就选最火的组件，结果发现跟自己的场景根本不匹配。我见过不少这样的案例，最后不得不推倒重来。所以，选型之前，先搞清楚几个核心概念。
3.1 OLAP vs OLTP：你到底是干嘛的？
这两个概念，是数据领域的基石。我习惯用一个比喻来解释：
- OLTP（联机事务处理）：就像超市的收银台。每次交易，就是加几件商品、算个总价、扣个库存。特点是：写多读少、每次操作数据量小、要求高并发、低延迟。典型代表：MySQL、PostgreSQL、Oracle。
- OLAP（联机分析处理）：就像超市的年度经营分析会。你要看过去一年所有门店的销售趋势、哪个品类卖得好、哪个区域利润高。特点是：读多写少、每次查询扫描数据量大、涉及大量聚合和关联。典型代表：ClickHouse、Greenplum、Doris。
核心结论：数据集市是典型的OLAP场景。千万别用OLTP的思维去设计OLAP系统，否则你会被性能问题折磨到崩溃。
我遇到过一个小团队，用MySQL做报表查询。数据量一过千万，一个简单的分组聚合就要跑几十秒。后来换了ClickHouse，同样的查询，毫秒级返回。这就是选型不对的代价。
3.2 MPP数据库选型：Greenplum vs ClickHouse vs Doris
MPP（大规模并行处理）数据库，是数据集市的标配。市面上主流的有三个：Greenplum、ClickHouse、Doris。怎么选？我列个对比表，你一看就明白。
| 维度 | Greenplum | ClickHouse | Doris |
|---|---|---|---|
| 架构 | 基于PostgreSQL，Share-Nothing | 列式存储，MPP架构 | MPP架构，兼容MySQL协议 |
| 擅长场景 | 复杂SQL、多表关联、数据仓库 | 单表聚合、大宽表、实时查询 | 高并发查询、实时分析、明细查询 |
| 写入性能 | 中等，适合批量导入 | 极高，适合实时写入 | 高，支持实时和批量 |
| SQL兼容性 | 非常强，几乎支持所有SQL | 有限，不支持事务和复杂关联 | 较强，兼容MySQL语法 |
| 运维复杂度 | 较高，依赖Hadoop生态 | 中等，独立部署 | 较低，开箱即用 |
| 典型场景 | 企业级EDW、复杂ETL | 用户行为分析、监控、AB测试 | 报表、大屏、自助分析 |
我的选型建议：
- 如果你的团队SQL能力强，需要做复杂的多表关联和ETL，选Greenplum。
- 如果你的场景是海量数据的单表聚合查询，对写入速度要求极高，选ClickHouse。
- 如果你需要高并发的报表查询，希望运维简单，选Doris。
我曾经帮一个电商团队做选型。他们每天有上亿条用户行为日志，需要实时写入，然后做各种维度的聚合分析。我们最终选了ClickHouse。为什么？因为它的写入性能太强了，单机就能扛住每秒几十万条的写入。而且它的聚合查询，在数据量几十亿的情况下，依然能秒级返回。
3.3 Lambda架构 vs Kappa架构：批流一体怎么选？
数据架构的演进，说白了就是批处理和流处理的博弈。
- Lambda架构：批处理层 + 流处理层 + 服务层。批处理保证数据的准确性，流处理保证数据的实时性。两套代码，两套逻辑。
- Kappa架构：只有流处理层。所有数据都走实时流，通过重放历史数据来保证准确性。一套代码，一套逻辑。
我个人的经验是：Lambda架构虽然成熟，但维护成本太高。你想想看，同样的业务逻辑，要在批处理和流处理里各写一遍，还要保证结果一致。一旦出问题，排查起来非常痛苦。
避坑指南：我曾经在一个项目中，因为Lambda架构的批流不一致问题，导致报表数据对不上。排查了整整三天，最后发现是批处理和流处理的窗口函数逻辑有细微差异。从那以后，我倾向于优先考虑Kappa架构。
当然，Kappa架构也不是万能的。它对消息队列的存储能力要求很高，而且不适合需要频繁回溯历史数据的场景。但如果你用的是Kafka + Flink这套组合，Kappa架构会非常顺手。
下面这张图，展示了两种架构的核心差异：
3.4 数据分层设计：ODS/DWD/DWS/ADS
数据分层，是数据集市建设的核心方法论。没有分层，你的数据就是一团乱麻。
我习惯把数据分层比作做饭：
- ODS（操作数据层）：就是菜市场买回来的原材料。没洗、没切、没处理。保持原样，方便溯源。
- DWD（明细数据层）：就是洗好、切好的菜。去掉了脏数据，做了标准化处理。但还没下锅。
- DWS（汇总数据层）：就是半成品。比如把肉切成丝、把菜焯好水。按主题做了轻度汇总。
- ADS（应用数据层）：就是端上桌的成品菜。直接给报表、大屏、应用消费。
核心原则：每一层只做一件事。ODS负责接入，DWD负责清洗，DWS负责汇总，ADS负责输出。职责清晰，才能避免数据混乱。
下面这张图，展示了数据分层的完整流程：
我的实践经验：
- ODS层的数据，一定要保留原始时间戳和来源标识。方便以后排查问题。
- DWD层，我习惯做一次数据质量校验。比如空值率、重复率、异常值。不合格的数据，打回ODS层重新处理。
- DWS层，不要做太细的汇总。粒度太细，会导致数据量爆炸。我一般按天、按小时做轻度聚合。
- ADS层，直接对接业务。字段命名要友好，最好让业务人员也能看懂。
嗯，这一章的内容就到这里。技术选型和架构设计，没有银弹。关键是要理解自己的业务场景，然后选择最合适的方案。别盲目追新，也别固步自封。