大数据项目之实时数仓项目_大数据物流数仓项目

为什么做这个项目

随着公司不断业务不断发展，产品需求和内部决策对于数据实时性要求越来越迫切，传

统离线数仓 T+1 模式已经不能满足，所以需要实时数仓的能力来赋能。

项目架构

框架版本选型

1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）。

2）CDH6.3.2：国内使用最多的版本。CDH 和 HDP 合并后推出，CDP7.0。收费标准，10000 美金一个节点每年。（不建议使用）

3）HDP：开源，可以进行二次开发，但是没有 CDH 稳定，国内使用较少。

4）云服务选择

（1）阿里云的 EMR、MaxCompute、DataWorks

（2）腾讯云 EMR、流计算 Oceanus、数据开发治理平台 WeData

（3）华为云 EMR

（4）亚马逊云 EMR

星环国际、金蝶。。。神策、数梦、袋鼠云

*注：着重标出的为公司实际生产中的常用版本。

服务器选型

服务器使用物理机还是云主机？

1）机器成本考虑：

（1）物理机：以 128G 内存，20 核物理 CPU，40 线程，8THDD 和 2TSSD 硬盘，单台报价 4W 出头，惠普品牌。一般物理机寿命 5 年左右。

（2）云主机，以阿里云为例，差不多相同配置，每年 5W。华为云、腾讯云、天翼云。

2）运维成本考虑：

（1）物理机：需要有专业的运维人员（1 万 * 13 个月）、电费（商业用户）、安装空调、场地。

（2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松。

3）企业选择

（1）金融有钱公司选择云产品（上海）。

（2）中小公司、为了融资上市，选择云产品，拉到融资后买物理机。

（3）有长期打算，资金比较足，选择物理机。

集群规模

1）生产集群规模、Flink 集群规模（10 台为例）

项目中方便作业提交，Flink 作为客户端，部署在所有的 Worker 节点

举例：Job 数量在 20 左右，需要 10 台服务器

Clickhouse 单独部署，服务器使用 128G，64C

项目建模

1）数据调研

（1）先和 Java 人员要表，表中最好有字段的描述或者有表和字段的说明文档。（项目经理帮助协调） =》 快速熟悉表中业务。梳理清楚业务线，找到事实表和维度表。

（2）和业务人员聊 =》 验证你猜测的是否正确

（3）和产品经理聊

需求：派生指标、衍生指标

派生指标 = 原子指标（业务过程 + 度量值 + 聚合逻辑） + 统计周期 + 统计粒度 + 业务限定

需求中的业务过程必须和实际的后台业务能对应上。

2）明确数据域

（1）用户域：登录、注册

（2）流量域：启动、页面、动作、故障、曝光

（3）交易域：加购、下单、支付、物流

（4）工具域：领取优惠卷、使用优惠卷下单、使用优惠卷支付

（5）互动域：点赞、评论、收藏

3）构建业务矩阵

用户、商品、活动、时间、地区、优惠卷

（1）用户域：登录、注册

（2）流量域：√

启动、页面、动作、故障、曝光

（3）交易域：加购、下单、支付、物流

（4）工具域：领取优惠卷、使用优惠卷下单、使用优惠卷支付

（5）互动域：点赞、评论、收藏

4）建模 至下而上

（1）ODS 层

①存 Kafka: topic_log\topic_db ,保持数据原貌不做处理

（2）DWD 层 事实表

①事务型事实表

找原子操作

a）选择业务过程

选择感兴趣的业务过程。 产品经理提出的指标中需要的。

b）声明粒度

粒度：一行信息代表什么含义。可以是一次下单、一周下单、一个月下单。

如果是一个月的下单，就没有办法统计一次下单情况。保持最小粒度。

只要你自己不做聚合操作就可以。

c）确定维度

确定感兴趣的维度。

产品经理提出的指标中需要的。

例如：用户、商品、活动、时间、地区、优惠卷

d）确定事实

确定事实表的度量值。 可以累加的值，例如，个数、件数、次数、金额。

e）维度退化

通过 Lookupjoin 将字典表中字段退化到明细表中

（3）DIM 层 维度表

①维度数据存储 Hbase，同时不做维度整合

5）指标体系建设 至上而下

（1）ADS 层

需求、日活、新增、留存、转化率、GMV

（2）DWS 层 聚合层

需求：派生指标、衍生指标

派生指标 = 原子指标（业务过程 + 度量值 + 聚合逻辑） + 统计周期 + 统计粒度 + 业务限定

例如，统计，每天各个省份手机品牌交易总额

交易总额 （下单 + 金额 + sum ） + 每天 + 省份 + 手机品牌

找公共的：业务过程 + 统计周期 + 统计粒度

建宽表

数据量

数据分层数据量

1）ODS 层

（1）用户行为数据（100g => 1 亿条；1g => 100 万条）

曝光（60g or 600 万条）、页面（20g）、动作（10g）、故障 + 启动（10g）

（2）业务数据（1-2g => 100 万-200 万条）

登录（20 万）、注册（100-1000）；

加购（每天增量 20 万、全量 100 万）、下单（10 万）、支付（9 万）、物流（9 万）、取消下单（500）、退款（500）；

领取优惠卷（5 万）、使用优惠卷下单（4 万）、使用优惠卷支付（3 万）；

点赞（1000）、评论（1000）、收藏（1000）；

用户（活跃用户 100 万、新增 1000、总用户 1 千万）、商品 SPU（1-2 万）、商品 SKU（10-20 万）、活动（1000）、时间（忽略）、地区（忽略）

2）DWD 层 + DIM 层

和 ODS 层几乎一致；

3）DWS 层

轻度聚合后，20g-50g。

4）ADS 层

10-50m 之间，可以忽略不计。

实时组件存储数据量

1）Kafka：

ods 层和 dwd 层数据

ods 和 dwd 数据一致，每天约 200G 数据

考虑 kafka 副本 2 个，保存三天，kafka 存储 400G 数据

2）Hbase：

存储 dim 层数据，与离线一致

3）Clickhouse：

存储 dws 层数据，每天约 20~30G 数据

考虑 dws 层数据保存一年，Clickhouse 三个副本

数据约 15~20T

实时 QPS 峰值数据量

QPS 峰值：20000 条/s 或者 2M/s