TL;DR
- 场景：企业面临海量数据实时处理需求，需构建统一的实时数据仓库来支撑精细化运营
- 结论：实时数仓通过分层架构（收集层→存储层→引擎层→平台层→应用层）实现数据时效性提升，结合 Flink+ClickHouse+Druid 技术栈可满足业务需求
- 产出：完整的实时数仓架构设计方案、技术选型对比、业务数据库表结构定义
版本矩阵
| 组件 | 版本 | 状态 | 说明 |
|---|---|---|---|
| 数据采集 | Flume / Canal | ✅ 已验证 | 支持 Binlog、IoT、后端服务日志采集 |
| 消息队列 | Kafka | ✅ 已验证 | 实时增量数据存储与分发 |
| 实时计算 | Flink | ✅ 已验证 | 支持复杂事件处理与流式计算 |
| OLAP 引擎 | ClickHouse / Druid | ✅ 已验证 | 高性能实时分析查询 |
| 维度存储 | HBase / Redis | ✅ 已验证 | 维度数据与热点黑名单缓存 |
| 持久化存储 | HDFS | ✅ 已验证 | 状态数据和全量数据存储 |
| 第三方发行版 | CDH / HDP / Fusion Insight | ✅ 已验证 | 企业级 Hadoop 发行版选型 |
项目背景
随着互联网的发展，数据的时效性对企业的精细化运营越来越重要，每天产生的海量数据中，如何能实时的挖掘出有价值的信息，对企业的决策运营策略调整有很大帮助。此外，随着 5G 技术的成熟、广泛应用，对于互联网、物联网数据的时效性要求非常高的企业，需要实时的数据体系来提高自身的行业竞争力。
随着数据时效性在企业运营中的重要性日益凸显，例如：
- 实时推荐
- 精准营销
- 广告投放效果
- 实时物流
数据实时处理能力成为企业提升竞争力的一大因素，最初阶段主要采用来一个需求，编写一个实时任务的方式来处理实时数据，随着需求的增多，计算任务也相对增多，并且不同任务的开发人员不同，导致开发风格差异化，该阶段的实时数据处理缺乏统一的规划，代码风格差异化严重，在维护成本和开发效率上有很大障碍。 为了避免上述的问题，人们参照数据仓库的概念和模型来重新规划和设计实时数据处理，在此基础上产生了实时数据仓库（实时数仓）。
数仓概念
离线数仓架构
实时数仓架构
收集层
- Binlog（业务日志）、IoT（物联网）、后端服务日志（系统日志）
- 经过日志收集团队和 DB 收集团队的处理，数据将会收集到 Kafka 中，这些数据不只是参与实时计算，也会参与离线计算。
存储层
- Kafka：实时增量数据
- HDFS：状态数据存储和全量数据存储（持久层）
- HBase：维度数据存储
引擎层
实时处理框架
平台层
数据、任务和资源三个角度去管理 集群资源
应用层
底层架构的应用场景
流量相关
- 流量数据的产生：不同通道的埋点和不同页面的埋点产生的数据
- 采集：按照业务维度划分不同的业务通道
- 应用：流的方式提供下游业务使用、流量方面的分析
实时效果验证
- CPV（展示广告）又称富媒体广告，按展示付费，即按投放广告网站的被展示次数计费，网站被打开一次计费一次。
- CPC 与 CTR：在现在的广告业 CPC 这个指标很难用来跟效果扯上关系，更多的时候是计费单位了。而 CTR 有的时候还是会作为效果的工具，大多用来衡量两次投放的不同投放策略、优化策略、创意的好坏。
- Reach Rate：广告产生点击动作以后，后面的指标就是到达。点击后到达的比率是一个重要的指标，是否比较高的到达率是广告效果的重要体现。
- Conversation Rate：广告后续的转换比率，从到达到转化的比率是用来评估广告效果的一种指标
需求分析
- 日志数据：启动日志、点击日志、广告日志
- 业务数据：用户下单、提交订单、支付、退款等核心交易数据的分析
- 广告流量的实时统计：生成动态黑名单
- 恶意刷单：一旦发现恶意刷单进行实时警告，基于动态黑名单进行行为过滤，计算每隔 5 分钟统计最近一小时内各广告的点击量，计算每天各省的热门广告，计算每天各广告最近 1 小时内的点击趋势
- 点击来源：从不同的维护分析用户是从哪里来的
- 渠道质量：针对用户进行以下几方面分析，访问时长、是否消费、首次消费的金额、收藏、访问页面数（PV）
- 风险控制：当检测到交易异常时进行实时警告
技术选型
技术选型方案
框架选型：Apache、第三方发行版（CDH、HDP、Fusion Insight）。
Apache 社区版本的优点：
- 完全开源免费
- 社区活跃
- 文档、资料详实
Apache 社区版本的缺点：
- 复杂的版本管理
- 复杂的集群安装
- 复杂的集群运维
- 复杂的生态环境
第三方发型版本（CDH、HDP、Fusion Insight）Hadoop 遵从 Apache 遵从Apache开源协议，用户可以免费的任意使用和修改 Hadoop。 正因如此，市面上很多厂家在 Apache Hadoop 的基础上开发自己的产品，如 Cloudera 的 CDH，Hortonworks 的 HDP，华为的 Fusion Insight等，这些产品的优点是：
- 主要功能和社区一致
- 版本管理清晰，比如 Cloudera、CDH1、CDH2、CDH3、CDH4 等，后面加上补丁版本
- 比 Apache Hadoop 在兼容性、安全性、稳定性上有增强。第三方发行版通常都经过大量的测试验证，有众多部署实例，大量的运用各种生产环境
- 版本更新快，如 CDH 每个季度会有一个 update，每一年会有一个 release
- 基于稳定的版本 Apache Hadoop，并应用了最新 BUG 修复
- 提供了部署、安装、配置工具，大大提供了集群部署的效率，可以在几个小时内部署好集群
运行简单，提供了管理、监控、诊断、配置修改的工具，管理配置方便，定位问题快速、准确、使运行工作简单、有效
-
CDH：最成型的发型版本，拥有最多的部署案例，提供强大的部署、管理和监控工具，国内使用最多的版本，拥有强大的社区支持，当遇到问题时，能够通过社区、论坛等网络资源快速获取解决方法
-
HDP：100% 开源，可以进行二次开发，但没有 CDH 稳定，国内使用相对较少，Fusion Insight：华为基于 Hadoop 2.7版本开发的，坚持分层，解耦，开放的原则，得益于高可靠性，在全国各地政府、运营商、金融系统有较多案例。
软件选型方案
- 数据采集：Flume、Canal
- 数据存储：MySQL、Kafka、HBase、Redis
- 数据计算：Flink
- OLAP：ClickHouse、Druid 框架
逻辑架构
业务数据库表结构
业务数据库：
- 交易订单表（trade_orders）
- 订单产品表（order_product）
- 产品信息表（product_info）
- 产品分类表（product_category）
- 商家店铺表（shops）
- 商家地域组织表（shop_admin_org）
- 支付方式表（payments）
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| 实时任务延迟增加 | Kafka 消息堆积、Flink checkpoint 阻塞 | 检查 Kafka Consumer Lag、Flink TaskManager 内存 | 优化并行度、调整 checkpoint 间隔、扩容 Kafka Partition |
| 数据倾斜导致热点 Partition | Key 分布不均 | 查看 Flink UI Task 各 SubTask 处理的记录数 | 对热点 Key 进行加盐或重新设计分区键 |
| 动态黑名单更新不及时 | 黑名单写入 HBase 延迟 | 检查黑名单表写入时间戳 | 启用 HBase 异步写入或使用 Redis 缓存热点黑名单 |
| 恶意刷单漏检 | 5分钟窗口太短、阈值设置不合理 | 对比人工审计结果与系统检测结果 | 调整窗口长度、动态调整检测阈值 |
| ClickHouse 查询超时 | 数据量过大、缺少分区索引 | 检查 ClickHouse part 数量和查询计划 | 添加物化视图、配置分区裁剪、使用 PreAggregate |
| Canal 数据同步延迟 | MySQL Binlog 格式问题、网络带宽不足 | 检查 Canal server 日志和 MySQL binlog 状态 | 切换 Row 格式 binlog、提升网络带宽、调整 batch size |
| Flink Job 重启后状态丢失 | 状态后端配置错误、checkpoint 存储故障 | 检查 Flink UI checkpoint 页面 | 配置正确的 RocksDB 状态后端、修复 HDFS 可用性问题 |
