数仓架构和数仓分层
大数据知识点全面盘点笔记（一）
九、数仓
数仓解决方案和架构分层
云上数据仓库解决方案：
构建与优化数据仓库·业务调研--阿里云教程
构建与优化数据仓库·架构与模型设计--阿里云教程
离线数仓架构 VS 实时数仓架构
MaxCompute离线数据仓库、流式计算
MaxCompute离线数据仓库：
ODS -> DWD -> DWS -> ADS
ODS -> DWD -> DWS、DWT
-> ADS
数据管道|数据质量|监控
报表/分析/应用存储Hologress
离线归档OSS
交互式分析Hologres是实时交互式分析产品，兼容PostgreSQL协议，与大数据生态无缝连接，支持高并发和低延时地查询分析万亿级数据，帮助用户轻松的使用现有BI工具分析业务数据。
流式计算：
流数据收集 -> 流数据处理 -> 下游存储系统
数据导入：
数据集成/DataX DTS LogService DataHub/Kafka
业务数据源：
业务系统 Web系统 APP 外部系统 人工整理
实时数仓：基于Kafka+HBase、基于Kudu+Impala（Spark OR Flink）
ODS层（DataHub/Kafka） -> DWD层（数据清洗） -> DWS层（多流join）-> ADS层（结果存储和获取DataHub/Kafka）
数仓输入系统和输出系统
数据来源：用户行为的埋点数据、业务系统后台的业务数据、外部数据； 输出系统：报表系统、（用户画像、推荐系统）。
框架版本选型
Apache 运维麻烦，组件间兼容性需要自己调研，须有专业的运维人员 CDH6.3.2 使用最多的版本，但CM不开源，且6.3.2+以上版本需要访问权限才可以下载 HDP2.7 开源，可以进行二次开发，但是没有CDH稳定，使用较少 CDH与HDP已经合并并开始收费，推出了新版本CDP 7.0+（先给钱后试用）。
建议搭建Apache开源组件，开源不受限
Apache框架版本参考：
Hadoop 2.7.2 VS 3.1.3
Zookeeper 3.4.10 VS 3.5.7
MySQL 5.6.24 VS 5.7.16
Hive 1.2.1 VS 3.1.2
Flume 1.7.0 VS 1.9.0
Kafka 0.11.0.2 VS _2.11-2.4.1
Kafka Eagle 1.3.7 VS 1.4.5
Azkaban 2.5.0 VS 3.84.4
Spark 2.1.1 VS 2.4.5
HBase 1.3.1 VS 2.0.5
Phoenix 4.14.1 VS 5.0.0
Redis 3.2.5 VS 3.2.5（有点旧了）
Canal 1.1.2 VS 1.1.2
ES+Kibana 6.3.1 VS 6.3.1
CDH6.3.2组件版本：
服务器选型
物理机 VS 云主机
考虑 机器成本
（一般线程数是核数的2倍） 单台物理机（惠普4W+）：128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，一般物理机寿命5年左右（运维有对接相应厂商或者电商平台渠道、第三方代理）
云主机：以阿里云为主
CPU（Intel）个数即CPU芯片个数；CPU的核心数是指物理上，也就是硬件上存在着几个核心，双核就是包括2个相对独立的CPU核心单元组，四核就包含4个相对独立的CPU核心单元组。线程数是一种逻辑的概念，简单地说，就是模拟出的CPU核心数。一个核心最少对应一个线程，但通过
超线程技术
，一个核心可以对应两个线程，也就是说它可以同时运行两个线程。
考虑 运维成本
物理机：需要专业的运维人员、电费、安装空调等；
云主机：阿里云完成，运维变得方便轻松企业选择
金融有钱直接选择阿里云；
中小公司前期选择阿里云，后期买物理机；
有长期打算，资金比较足，选择物理机，或者行业有专门的监管要求，比如必须自建机房等
集群规模
估算方法，注意自身行业真实数据场景：
比如，100万日活（100万的日交易量或者百万级的日交易笔数），
每人1天产生100条数据，1KB；
100万 * 100条 = 1亿条数据；
1亿条 * 1K = 100G数据；
ODS层 100G数据 => 压缩到 10G左右（5~6G）；
DWD层 100G数据 => 列式存储 10G左右；
粗粒度 DWS + DWT => 50G左右；
ADS层 数据量忽略不计。
=> 70G * 180天 * 3个副本 0.7 = 53T
180天：半年不扩容，或者1年365天
/ 0.7：30%的磁盘余量
Kafka数据存储
100G * 副本2 * 保留3天 0.7 = 1T左右
Flume数据 忽略不计
业务数据：
100万日活 * 10个订单 10条 1k => 1G左右
ODS DWD DWS DWT 3G
=> 2T左右数据量
集群总大小：53T + 1T + 2T = 56T
1台服务器8T硬盘
7 * 8T = 56T => 半年存储需要7台服务器
或者 7 * 16T 存储翻倍
1年14台，10台左右（实际小公司可能只有3台物理机，然后使用虚拟机搭建集群）
20核40线程 * 7 = 280个线程
（基本框架+200个实际参与运算的线程）
内存128G * 7 = 896G
（计算任务内存700G+基本框架需要的内存）
128M数据处理需要 => 1G内存
87G数据 => 700G内存
集群组件分布：
NN、NN（客户端：Hive MySQL主备 Spark Flink）；
RM、RM；NN和RM分别在不同的两个节点上
分布依据：
消耗内存的组件分开部署在不同的节点上 Kafka、ZK、消费Kafka的Flume等传输数据比较紧密的放在一起 客户端尽量放在一到两台服务器上，方便外部访问
预算多少，多长时间不扩容，多久要上线（项目周期），离线还是实时，统计哪些指标，目前服务器状况，数据源状况，长期打算，工作范围和边界
人员配置
研发部/技术部/数据部，大数据组。
大数据开发工程师->架构师（技术中台负责人）->部门经理->CTO。
十、数仓分层
数据在关系数据库，约有30张表，建模方案如何设计？
最基本的：不同环境的数据库连接；
表ER图、数据字典（表结构字段、表关系）
业务系统详细设计说明书
建模第一步，建模工具：PowerDesigner EZDML SQLYog
ODS层
保持数据原貌，不做任何修改，可以起到备份作用 创建分区表 => 防止后续的全表扫描 采用LZO压缩 => 减少磁盘空间
DWD层
ETL工具
hql、spark sql、mr、Python、kettle清洗掉多少数据才算合理
10000条数据里面1条，万分之一，超过万分之一，需要找到数据源进行应用优化清洗规则
解析数据、核心字段不能为空、超期数据过滤掉、过滤掉重复数据采用压缩 采用列式存储 加快查询速度 创建分区表 脱敏 维度退化（维度建模中，星型模型（事实表周围只有一级维度）） 维度建模
选择业务过程
数据表30~50张=>所有业务过程，可以全部纳入建模范围；
数据表1000+=>根据需求选择（业务模块） 声明粒度
一行信息代表什么，比如一次下单，一次支付 粒度就是一次；
1天的下单笔数 粒度就是1天
周、月、季度
只要不把原始层数据进行聚合操作就可以了。
采用最小粒度。
确定维度（维度退化）
时间、地点（省份+地区）、用户、商户、渠道、产品、行业；
商品（商品表、spu表、品类表、三级分类、二级分类、一级分类）
确定事实
确定事实的度量值（个数、件数、次数、金额）；
订单表、订单详情、支付表、加购表、收藏、评价、退款、优惠券领用
选择业务过程->声明粒度->确定维度（维度退化）->确定事实
DWS层
宽表 1天；
有哪些表：有多少维度就创建多少宽表；比如，商户号，交易笔数，交易金额，手续费
每张表里的字段：站在维度的角度去看事实，主要关注事实表的度量值；减少重复的join操作
DWT层
粒度更粗；从业务开始到结束的累积过程；
有哪些表：有多少维度就创建多少宽表；比如，商户号，交易笔数，交易金额，手续费
每张表里的字段：站在维度的角度去看事实，主要关注业务开始时间、结束时间、度量值的累积值、度量值一段时间累积度量值【商户主题宽表：首次交易时间、最近一次交易时间、累积交易次数、累积交易金额、最近30天交易次数、最近30天交易金额】
ADS层
能够非常熟悉实际生产工作中统计的哪些指标，日活、新增、留存、转化率。
分析用户活跃
在启动日志中统计不同设备id出现次数分析用户新增
用户活跃表left join用户新增表，用户新增表中mid为空的即为用户新增分析用户1天留存
留存用户=前一天新增join今天活跃
用户留存率=留存用户/前一天新增分析沉默用户
比如：登录时间为7天前，且只出现过一次
按照设备id对日活表分组，登录次数为1，且是在一周前登录...... 最近连续3周活跃用户
通常是周一对前3周的数据做统计，该数据一周计算一次最近7天内连续3天活跃用户数
drop table if exists ads_continuity_uv_count;
create external table ads_continuity_uv_count(
`dt` string COMMENT '统计日期',
`wk_dt` string COMMENT '最近7天日期',
`continuity_count` bigint
) COMMENT '连续活跃设备数'
row format delimited fields terminated by '\t'
location '/warehouse/gmall/ads/ads_continuity_uv_count';
insert into table ads_continuity_uv_count
select
'2019-02-12',
concat(date_add('2019-02-12',-6),'_','2019-02-12'),
count(*)
from
(
select mid_id
from
(
select mid_id
from
(
select
mid_id,
date_sub(dt,rank) date_dif
from
(
select
mid_id,
dt,
rank() over(partition by mid_id order by dt) rank
from dws_uv_detail_day
where dt>=date_add('2019-02-12',-6) and dt<='2019-02-12'
)t1
)t2
group by mid_id,date_dif
having count(*)>=3
)t3
group by mid_id
)t4;
运费分摊
流转等指标
留存用户、留存率，周留存、月留存、促销活动
转化率（首页->加购->下单->支付），看10个下单1个...
GMV，每天10万订单（快100万交易笔数了）
哪个商品的复购率高，大概是多少，日常商品较高，中高端较低
日活100万？、月活2-3倍，300万（去重）？、总用户是多少1000万~3000万之间？
十一、电商业务
SKU VS SPU
SKU，一台银色、128G内存的、支持联通网络的iPhoneX
SPU，iPhoneX
tm_id，品牌id苹果，包括iPhone、二级、MAC等
订单表 VS 订单详情表
订单表的订单状态会发生变化，订单详情表不会，因为没有订单状态。
订单表记录：user_id、订单id、订单编号、订单的总金额、order_status、支付方式等；
订单详情表记录：user_id， 商品sku_id，具体的商品信息
埋点行为数据基本格式（基本字段）
页面数据（静止信息、停留时间）、事件数据（点击、动作）、曝光数据、启动数据和错误数据；json
电商业务过程
用户表、优惠券表、优惠券领用表、订单表、编码字典表、商品评论表、加购表、商品收藏表、支付流水表、订单状态表、活动表、活动订单表、省份表、订单详情表、SKU商品表、商品三级分类表、商品二级分类表、商品一级分类表、SPU商品表、品牌表、参与活动商品表、地区表、退单表、优惠规则表
维度表和事实表
维度表
：一般是对事实的描述信息。例如：用户、商品、日期、地区等
事实表
：每行数据代表一个业务事件（下单、支付、退款、评价）。事实
表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。
每一个事实表的行包括：具有可累加性的数值型的度量值、与维度表相关联的字段（外键）。
事务型事实表
以每个事务或事件为单位，例如一个销售订单记录、一笔支付记录、一条财务收支流水等。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
周期型快照事实表
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
累积型快照事实表
用于跟踪业务事实的变化。比如从下单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单生命周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
订单id 用户id 下单时间 打包时间 发货时间 签收时间 订单金额
同步策略
全量
：数据量比较小的表/编码字典表等；保持不变、无需同步
：特殊的字典表，省份、地区，变化的时候调整一次即可，比如杭州重新划区；新增
：数据量比较大和不变化的表（只增不更新）；新增和变化
：数据量比较大、且会发生数据变更
实体表，维度表，每日全量或每月全量
事务型事实表：每日增量
sqoop：query select...from
where create_time>=${today-1} or update_time>=${today-1}
关系型数据库范式理论
1NF：属性不可分割
2NF：不能存在部分函数依赖
3NF：不能存在传递函数依赖
MySQL关系模型：主要应用于OLTP系统场景中，也会有相应的冗余和反范式设计；
Hive维度模型：维度模型主要用于OLAP系统中，Hive将相关各种表整理成事实表和维度表两种，所有维度表围绕着事实表进行解释。
数据模型
维度建模：雪花模型、星型模型和星座模型
星型模型：一级维度表；
雪花模型：多级维度；
星座模型：（星型模型+多个事实表）
提高查询效率
拉链表
拉链表处理的业务场景：主要是处理缓慢变化维的业务场景。（用户表、订单表）
a 订单id 状态 生效开始日期 生效结束日期
b 订单id 状态
a left join b 注意变更生效结束日期
即席查询数据库
Druid：是一个实时处理时序数据的OLAP数据库，因为它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。 Kylin：核心是Cube，Cube是一种预计算技术，基本思路是预先对数据做多维索引，查询时只扫描索引而不访问原始数据从而提速。 Presto：没有使用MapReduce，大部分场景下比Hive快一个数量级，其中的关键是所有的处理都在内存中完成。 Impala：基于内存运算，速度快，支持的数据源没有Presto多。
如果是CDH，使用Impala；如果是Apache开源组件，使用Presto。
Spark SQL：基于Spark平台上的一个OLAP框架，基本思路是增加机器来并行计算，从而提高查询速度，一般都是晚上执行的任务。 ES：最大的特点是使用了倒排索引解决索引问题，ES在数据获取和聚集用的资源比Druid要高，用户画像（标签数据）。 框架选型：从超大数据的查询效率，Druid>Kylin>Presto>Spark SQL；从支持的数据源种类来看：Presto>Spark SQL>Kylin>Druid
数据仓库每天跑多少张表，大概什么时候运行，运行多久
主要是业务数据；凌晨00:30分；运行大约40分钟（8小时之内）；大数据实时处理部分控制在5分钟之内（分钟级别、秒级别）。
ods层多少张表，dwd、dws层多少张表，ads层多少张表（报表数量、BI）；
dwd
dws 5（设备 会员 商品 优惠券 地区）
ads 30
切量，数据量增加多少
集群资源都留有预留。动态增加服务器。
并发峰值、大概时间点
Kafka xx M/s；x 万/s
Hive数仓文件存储格式
textFile
ORC
Parquet
，一般会使用ORC或者Parquet，都是列式存储，且压缩比非常高，查询速度快，占用磁盘空间少
哪张表最费时间，有没有优化
xx宽表，数据量过大，数据倾斜的相关优化手段（mr hive spark）；比如使用null来标识业务含义
权限管理
Ranger【推荐】或Sentry（kerberos）；没有做到表级别和字段级别权限...VPN方式，数据服务前置内部权限管理
数仓当中数据多久删除一次
可以永久不删，看数据增长情况和后续资源补充情况（这里的删除是永久备份后，再删除）
十二、测试相关、发布流程
测试服务器
完整的CDH集群、Apache开源集群
测试环境资源
生产环境的一半
测试数据
Java程序、Python脚本生成的数据（更灵活），生产环境数据比较敏感，不允许同步到测试环境
如何保证写的SQL正确性
造一些特定的测试数据进行测试；
离线和实时数据结果进行比较，倾向取离线；
业务数据，在关系数据库算出来，与ADS层计算的结果进行比较。
测试之后如何上线发布
走上线流程，提交开发完成的jar包、脚本等，运维发布
注意分担风险
项目实际工作流程
确定指标的业务口径，邮件/需求文档
需求来源：管理层、客户、内部各部门等需求评审
产品经理主导设计原型，数据开发、后端开发、前端开发一同参与大数据开发
通过数据同步工具将数据同步到ODS层，然后一层一层的通过SQL计算到DWD、DWS层，最后形成可为应用直接服务的数据填充到ADS层。后端开发
业务数据接口前端开发
前端埋点、可视化展示联调 测试
边界值、等价类等、测试用例：输入和预期输出；开发一周，测试两周上线
运维
实现一个需求的开发周期
刚开始第一个需求7天左右，业务熟悉之后可以一天一个需求；对业务熟悉、开会讨论需求、权限申请、测试
迭代次数、版本升级
瀑布式开发（V字型开发、周期特别长）；敏捷开发（小步快跑）
看具体业务和数据需求、新产品或者优化需求、预研新技术如Flink Hudi
框架版本，x.y.z 大版本号、核心features变动、BUG修复小改动
项目开发中每天做什么事
新需求 占比60% 故障分析：数据反馈问题排查 占比20% 新技术预研 实时数仓、数据湖、数据质量、元数据管理 占比10% 临时任务 占比10% 会议培训等等
实时任务，怎么分配内存和CPU
128M数据对应1G内存；
1个Kafka分区对应一个CPU
实时任务数据量
算平均值；业务数据：多少张表
十三、技术和项目中遇到的问题
可视化报表工具
Echarts、Kibana、Tableau、Superset、QuickBI、DataV
集群监控工具
Zabbix+Grafana
项目中遇到的问题
Shell中Flume停止脚本
Hadoop宕机、Hadoop解决数据倾斜的方法
集群资源分配
小文件问题
Hadoop优化
Flume挂掉
Flume优化
Kafka挂掉
Kafka丢失：ACK 0 1追求效率、允许丢失 -1
Kafka数据重复
Kafka消息数据积压
Kafka优化
Kafka单条日志传输大小
自定义UDF、UDTF
Hive优化
Hive解决数据倾斜方法
7天内连续3次活跃
Sqoop控制、一致性、数据倾斜
Azkaban任务挂了怎么办
Azkaban故障报警
Spark数据倾斜
Spark优化
SparkStreaming精确一次性消费
十四、数仓热点-元数据-数据质量-权限
元数据管理
依赖关系：表级别和字段级别
用处：作业执行失败，评估它的影响范围。一般表比较多的时候是非常有用的。
Atlas 0.84 VS 2.1.x，一般是Hive元数据，还包括很多组件。组件元数据->Kafka->元数据存储在HBase里面->使用Index Store（Solr）提供快速检索查询。
Apache Atlas导入Hive元数据及Atlas常用配置
ODS -> DWD 如何找到依赖关系，解析SQL的开源工具；
insert overwrite table dwd_table
select age, name
from ods_table
数据质量监控
Griffin
为什么要做数据质量监控？ 数据不一致数据不完整数据不合规数据不可控建设方法（质量监管平台）
1.质量需求（发现数据问题、收集需求、检核规则的需求）->2.提炼规则（梳理指标、确定指标、检核指标）->3.规则库（检核对象、检核调度、配置规则、检核范围、检核标准）->4.执行检核（调度执行、检核代码->配置调度->执行调度）->5.问题数据（问题展示、问题分类、质量分析、严重程度）->6.分析报告（评估等级、趋势分析、影响范围、解决方案）->7.知识库（知识积累、知识应用、体系标准、专家经验）->8.落实处理（落实方案、跟踪管理、发现问题、标准化）监控指标 单表数据量监控
：一张表的记录数在一个已知的范围内，或者上下浮动不会超过某个阈值。
SQL结果、报警触发条件设置、同比增加（100 * (本周-上周)/上周）、环比增加（100 * (今天-昨天)/昨天）、达到报警触发条件则监控告警出来。
日活、周活、月活、留存（日周月）、转化率（日周月）、GMV（日周月）、复购率 高低偏差如30%单表空值检测
：某个字段为空的记录数在一个范围内，或者占总量的百分比在某个阈值范围内。
目标字段、SQL结果（is null）、单词检测并报警单表重复值检测
：一个或多个字段是否满足某些规则。
目标字段（正常统计条数count(*)
）、去重统计条数（count(*) group by
）、两次统计结果减一减，看是否在上下线阈值之内、单词检测并报警单表值域检测
：一个或多个字段没有重复记录。跨表数据量对比
：针对同步流程，监控两张表的数据量是否一致
Griffin不是特别成熟，也不太好用，组件支持版本兼容性问题。
Python数据校验通用脚本实现，把校验结果存储下来，形成报告可视化
权限管理Ranger
谁可以访问、谁不可以访问
RangerAdmin、REST APIS、WEB-UI、Solr、DB（MySQL）、Plugins
数据治理
包括：数据质量管理、元数据管理、权限管理
数据规划->指定标准->整理数据（数据质量管理、元数据管理、权限管理）->搭建平台->推广贯标->运维体系
数据中台
前台：包括各种和用户直接交互的页面，Web页面、手机APP、服务端各种实时响应用户请求的业务逻辑
后台：面向运营人员的（配置）管理系统，后台为前台提供了一些简单的配置
传统项目的痛点：重复造轮子
中台：统一、封装、通用、复用
阿里：大中台，小前台
华为：平台炮火支撑精兵战略
业务中台
：核心业务（与人打交道，最难实现）技术中台
：中间件（最容易实现）数据中台
：数据建模 日志分析 用户画像算法中台
：语音识别、图像识别、搜索算法
中台使用场景
从0到1，没有必要；从1到N，适合搭建中台；从N到N+1，搭建中台势在必行
数据湖
1.0数仓、2.0数据中台、3.0数据湖
DataLake数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。
数据湖是一个概念，Hadoop是用于实现这个概念的技术之一。
数据仓库：主要处理历史的、结构化的数据，而且这些数据必须与数据仓库事先定义的模型吻合；数仓分析的指标一般都是产品经理提前定义的好的，按需分析数。
数据湖：能处理所有类型的数据，如结构化数据、半结构化数据、非结构化数据，数据的类型依赖于数据源系统的原始数据格式。非结构化数据（语音、图片、视频等）；根据海量的数据，挖掘出规律，反应给运营部门。拥有非常强的计算能力用于处理数据。主要用于数据挖掘。
Apache Hudi
“数据”库
https://hudi.apache.org/
Hudi适用于Spark-2.4.3 +和Spark 3.x版本
Apache Iceberg
https://iceberg.apache.org/
Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to Trino and Spark that use a high-performance format that works just like a SQL table.
Delta Lake
https://delta.io/
Delta Lake is an open-source project that enables building a Lakehouse architecture on top of existing storage systems such as S3, ADLS, GCS, and HDFS.
埋点
代理埋点、可视化埋点、全埋点
收费：xx数据 相关demo
count sum top 100*x/y
猜你喜欢
点一下，代码无 Bug
