数仓项目架构_数仓都是用python吗

1、系统数据流程设计

为什么这里面需要kafka？

1. 我们的业务有实时的业务，Spark可以和Flume做整合的
2. 削峰平谷，处理一些高并发的场景
3. 解耦，适合这种多场景对数据的多次使用
1
2
3

埋点的数据是如何被采集的？

采集的都是用户的行为，写一些代码（js，sdk），往后台发送，实时发送，每隔一段时间发送一个数据包（加密、压缩、转码，一次性发送多条）
1

2、项目技术如何选型？

技术选型主要考虑因素：数据量大小、业务需求、行业内经验、技术成熟度、开发维护成本、总成本预算

1. 数据采集传输：Flume，Kafka、Sqoop、Logstash、DataX
2. 数据存储：MySQL，HDFS，HBase，Redis，MongoDB
3. 数据计算：Hive，Tez，Spark，Flink，Storm
4. 数据查询：Presto，Druid，Impala，Kylin
5. 数据可视化：Echarts，Superset，QuickBI，DataV
6. 任务调度：Azkaban，Oozie
7. 集群监控：Zabbix
8. 元数据管理：Atlas
9. 数据质量监控：Griffin

3、框架版本如何选型？

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

CDH6.3.2：国内使用最多的版本，但CM不开源，但其实对中、小公司使用来说没有影响（建议使用）1万美金一个节点

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

Apache框架版本

CDH框架版本：5.12.1

注意事项：框架选型尽量不要选择最新的框架，选择最新框架半年前左右的稳定版

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

1. 机器成本考虑

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

   云主机：以阿里云为例，差不多相同配置，每年5W

2. 运维成本考虑

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

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

3. 企业选择

   • 金融有钱公司和阿里没有直接冲突的公司选择阿里云（上海）
   • 中小公司、为了融资上市，选择阿里云，拉到融资后买物理机
   • 有长期打算，资金比较足，选择物理机

5、如何确认集群规模？

1. 用户行为数据

   1、每天日活跃用户100万，每人一天平均100条：100万*100条=10000万条
   
   2、每条日志1K左右，每天1亿条：100000000 / 1024 / 1024 = 约100G
   
   3、数仓ODS层采用LZO存储：100g压缩为10g左右
   
   4、数仓DWD层采用LZO+parquet存储：10g左右
   
   5、数仓DWS层轻度聚合存储（为了快速运算，不压缩）：50g左右
   
   6、数仓ADS层数据量很小：忽略不计
   
   7、保存3副本：70g*3=210g
   
   8、半年内不扩容服务器来算：210g*180天=约37T
   
   9、预留20%~30%Buf=37T/0.7=53T
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   17

2. kafka中数据

   1、每天约100G数据*副本（2）=200g
   
   2、保存3天*200g=600g
   
   3、预留30%buf=600g/0.7=857g=约1T
   1
   2
   3
   4
   5

3. Flume中默认缓存的数据比较小：暂时忽略不计

4. 业务数据

   1、每天活跃用户100万，每天下单的用户10万，每人每天产生的业务数据10条，每条日志1k左右：10万*10条*1k=1g左右
   
   2、数仓四层存储：1g*3=3g
   
   3、保存3副本：3g*3=9g
   
   4、半年内不扩容服务器来算：9g*180天=约1.6T
   
   5、预留20%~30%Buf=1.6T/0.7=2T
   1
   2
   3
   4
   5
   6
   7
   8
   9

5. 集群总规模

   53T + 1T + 2T = 56T
   1

6. 算到这

   约8T * 7台服务器
   1

测试集群服务器规划

生产环境中，一个可以参考的集群配置，生产集群

1. 服务尽量平均，内存、CPU消耗大的不要太聚集
2. 高可用的配置要分开
3. 互相有频繁通信的要分开