高顿CFA1. 为什么把实时数仓项目落在腾讯云：架构选型与云资源规划
1.1 实时数仓到底解决什么问题
先说项目背景。当时业务方提了一个很现实的需求：数据大屏上的指标不能再看T+1的离线报表，老板打开大屏就想看到当前这一分钟的成交金额、订单量、活跃用户数，运营同学要实时看各渠道的转化漏斗。如果继续用离线数仓跑Hive SQL，数据延迟至少半小时以上，根本没法用。于是实时数仓这个项目就提上了日程。
实时数仓和离线数仓最大的区别在于数据处理延迟。离线数仓按天、按小时调度，适合批量加工历史数据；实时数仓要处理的是流式数据，数据从产生到最终可查询，延迟要求通常控制在秒级到分钟级。这个项目最终的目标是：业务库数据变更后，最迟5分钟内同步到分析库，核心指标延迟控制在30秒以内。
当时考虑过自建机房、混部其它云厂商，最终选了腾讯云，原因比较实际：团队对腾讯云的VPC、CVM、CDB这些产品比较熟，后续要打通企业微信告警也方便；CVM按量计费和竞价实例在测试阶段能省不少钱；另外腾讯云容器镜像服务（CCR）配合TKE，后续扩缩容会轻松很多。对于中小团队来说，云上部署实时数仓的性价比明显高于自建机房。
1.2 云上组件选型：自建还是托管
这是项目初期争论最多的地方。实时数仓的核心链路无非四块：数据接入、消息缓冲、实时计算、OLAP分析。
- 数据接入：业务库是MySQL，需要在腾讯云数据库CDB上开启binlog，用Canal订阅增量变更。
- 消息缓冲：选了Kafka，版本2.8。自建在CVM上，没用CKafka托管，原因有两个：一是托管版按分区数和流量计费，测试阶段数据量不大时候价格不划算；二是团队需要自己管理Kafka的Topic分区策略，为后面的实时链路调优留出空间。
- 实时计算：Flink 1.13，自建集群。当时也考虑过腾讯云流计算Oceanus，但团队对Flink SQL已经有一定积累，直接在CVM上部署更灵活，改代码、看日志、调参数都不受平台限制。
- OLAP分析：选型时对比了ClickHouse、Doris、StarRocks。最终选了ClickHouse，因为查询性能好、部署简单，而且团队里有人之前用过，踩坑成本低。Doris在实时更新模型上更好，但当时版本升级快，社区资料少，怕踩坑没人能问。
整个架构串起来就是：MySQL binlog -> Canal -> Kafka -> Flink SQL -> ClickHouse，Redis作为维表缓存和结果缓存。这套链路在业界已经很成熟，每个组件都有大量实践案例，踩坑时比较容易找到解决方案。
1.3 服务器与网络规划
资源规划上，测试环境用了3台CVM，配置4核8G，系统盘50G SSD，数据盘200G高性能云硬盘。生产环境起步是5台8核16G，后面按负载再扩容。这里有一个教训：Kafka和ClickHouse对磁盘IO要求很高，千万别图便宜用普通云硬盘，最好上SSD。刚开始测试环境用普通云硬盘，Kafka在高写入下磁盘IO直接打满，延迟飙到几十秒，后来换了SSD才稳定。
网络规划上，所有组件部署在同一个VPC内，通过内网IP互通，不暴露公网端口。安全组只开放必要的端口给应用服务器，比如Kafka的9092只允许Flink节点访问，ClickHouse的8123和9000只允许报表服务和数据开发机访问。测试环境为了方便，一度把端口全放开，结果被扫描端口撞库，Redis被种了挖矿木马，这是血的教训。后面全部收紧了安全组策略，Redis也关了公网访问。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实时数仓的分层设计与数据流向：从业务库到分析报表
2.1 四层模型怎么落到实时链路里
如果没有离线数仓经验，可能不太理解为什么实时数仓也要分层。直接用Kafka原始数据算指标，看起来很直接，但业务复杂了根本维护不了。比如今天要算成交金额，明天要加一个退款率指标，如果每次都从原始binlog开始算，逻辑会越堆越乱，出了问题也不好排查。
所以项目里参考了离线数仓的分层思想，把实时链路分成四层：
- ODS层：Kafka中原始binlog和日志数据，不加工，只存储，对应Kafka Topic。
- DWD层：清洗、过滤、维度补充后的明细数据，如订单明细、用户行为明细，也存Kafka。
- DWS层：按业务维度聚合后的结果数据，如每分钟订单金额、各渠道活跃数，存Kafka或直接落ClickHouse。
- ADS层：面向业务应用的数据，按指标需求做轻度加工，ClickHouse里的物化视图和结果表。
这样的好处是：每一层职责清晰，DWD层负责把“脏数据”挡掉，DWS层负责口径统一，ADS层只做最后的结果输出。业务方如果发现指标不对，可以按链路一层一层排查，而不是在一大坨SQL里找逻辑。
2.2 数同步链路：Canal + Kafka
Canal是阿里开源的一个组件，模拟MySQL的从库协议，把自己伪装成binlog的订阅者，从而拿到增量变更数据。部署上，Canal需要单独分配一台机器，或者和Kafka共用，因为它要维持和MySQL的binlog连接，还要把数据推送到Kafka，资源占用不能忽视。
Canal推送的数据格式是JSON，里面包含库名、表名、事件类型（INSERT、UPDATE、DELETE），以及变更前后的数据。这里有个细节：数据量大的表，binlog日志一天能涨到好几G，要确认腾讯云CDB的binlog保留时间，项目里设置的是7天，防止Canal挂了恢复时binlog已经被清理，导致数据丢失。
Kafka的Topic命名我习惯用三层结构