离线数仓构建方法指导论(二)
9、数据仓库分层思想详解
（1）数仓定义
数据仓库之父 Bill Inmon对数据仓库做了定义——面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
Data warehouse（可简写为DW或者DWH）数据仓库，是在数据库已经大量存在的情况下，它是一整套包括了etl、调度、建模在内的完整的理论体系。
数据仓库的方案建设的目的，是为前端查询和分析作为基础，主要应用于OLAP（on-line Analytical Processing，联机分析处理），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
数据仓库并不是数据的最终目的地，而是为数据最终的目的地做好准备，这些准备包含：清洗、转义、分类、重组、合并、拆分、统计等
（2）数仓分层
数据分层是数据仓库设计中一个十分重要的环节，良好的分层设计能够让整个数据体系更容易被理解和使用。
分层是以解决当前业务快速的数据支撑为目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。
（3）为什么分层（分层优点）
• 清晰数据结构：让每个数据层都有自己的作用和职责，在使用和维护的时候能够更方便和理解
• 复杂问题简化：将一个复杂的任务拆解成多个步骤来分步骤完成，每个层只解决特定的问题
• 统一数据口径：通过数据分层，提供统一的数据出口，统一输出口径
• 减少重复开发：规范数据分层，开发通用的中间层，可以极大地减少重复计算的工作
• 数据血缘追踪：提供给业务人员或下游系统的数据服务时都是目标数据，目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时，清晰的血缘关系可以快速定位问题所在。而且，血缘管理也是元数据管理重要的一部分。
• 屏蔽原始数据的(影响)：业务或系统发生变化时，不必改一次业务就需要重新接入数据。提高数据稳定性和连续性。
• 屏蔽源头业务系统的复杂性：源头系统可能极为繁杂，而且表命名、字段命名 、字段含义等可能五花八门，通过 DW 层来规范和屏蔽所有这些复杂性，保证下游数据用户使用数据的便捷和规范。如果源头系统业务发生变更，相关的变更由 DW 层来处理，对下游用户透明，无须改动下游用户的代码和逻辑。
• 数据仓库的可维护性：分层的设计使得某一层的问题只在该层得到解决，无须更改下一层的代码和逻辑。大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！
（4）如何搭建一个好的数仓
稳定：数据产出稳定且有保障。
可信：数据干净、数据质量高。
丰富：数据涵盖的业务足够广泛。
透明：数据构成体系足够透明。
（5）数仓设计的3个维度：
功能架构：结构层次清晰。
数据架构：数据质量有保障。
技术架构：易扩展、易用。
（6）常见分层
ODS->DWD->DWM->DWS->ADS
10、数据仓库 ODS层设计与实现
（1）ODS：贴源数据层。数据源（源系统）中的数据，经过是ETL过程之后进入该层。
（2）功能：
• ODS是后面数据仓库层的准备区
• 为DWD层提供原始数据
• 减少对业务系统的影响
（3）数据来源方式 为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可。这层的数据是后续数据仓库加工数据的来源。来源方式如下：
• 业务库：sqoop定时抽取数据；实时方面考虑使用canal监听mysql的binlog日志，实时接入即可；
• 埋点日志：日志一般是以文件的形式保存，可以选择使用flume来定时同步；可以使用spark streaming或者Flink、Kafka来实时接入；
• 消息队列：来自ActiveMQ、Kafka的数据等。
11、数据仓库 DWD层设计与实现
该层是业务层和数据仓库的隔离层，保持和ODS层一样的数据颗粒度；主要是对ODS数据层做一些数据的清洗和规范化的操作，比如去除空数据、脏数据、离群值等。
为了提高数据明细层的易用性，该层通常会才采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联。
12、数据仓库 DWM层设计与实现
该层是在DWD层的数据基础上，对数据做一些轻微的聚合操作，生成一些列的中间结果表，提升公共指标的复用性，减少重复加工的工作。
简单来说，对通用的核心维度进行聚合操作，算出相应的统计指标
13、数据仓库 DWS层设计与实现
该层是基于DWM上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP分析，数据分发等。 一般来说，该层的数据表会相对较少；一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
14、数据仓库 ADS层设计与实现
数据应用层：Application Data Service，ADS； 该层主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、Redis、PostgreSql等系统中供线上系统使用；也可能存放在hive或者Druid中，供数据分析和数据挖掘使用，比如常用的数据报表就是存在这里的。
15、数据仓库DIM层设计与实现
维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联，相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。维度表主要是包含两个部分：
• 高基数维度数据：一般是用户资料表、商品资料表类似的资料表，数据量可能是千万级或者上亿级别；
• 低基数维度数据：一般是配置表，比如枚举字段对应的中文含义，或者日期维表等；数据量可能就是个位数或者几千几万。
常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。
16、数据库与数据仓库的区别
数据库：数据库是面向交易的处理系统（业务系统），它是针对具体业务在数据库联机的日常操作，通常对记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理，也被称为联机事务处理 OLTP（OnLine Transaction Processing）。
数据仓库：:数据仓库一般针对某些主题的历史数据进行分析，支持管理决策，又被称为联机分析处理 OLAP（OnLine Analytical Processing）。
| 数据库 | 数据仓库 | |
|---|---|---|
| 面向 | 事务 | 分析 |
| 数据类型 | 细节、业务 | 综合、清洗过的数据 |
| 数据特点 | 当前的、最新的 | 历史的、跨时间维护 |
| 目的 | 日常操作 | 长期信息需求、决策支持 |
| 设计模型 | 基于ER模型、面向应用 | 星型模型/雪花模型、面向主题析 |
| 操作 | 读写 | 大多读 |
| 数据规模 | GB到TB | >=TB |
17、数仓数据来源及采集
来源：业务系统等
采集：业务表、日志表、埋点数据
（1）业务表
业务表从业务系统中采集，一般采用结构化的存储方式，即有行有列的表；数仓在采集业务表数据时，直接从业务表中获取即可，相对比较简单干净。按数仓分层结构来看，业务表、埋点、日志 都是比 ODS 层还底层的明细数据，经过处理后才会生成 ODS 层表单。
业务表设计的核心目的，是为产品系统上某个业务环节服务，比如在订单环节，就需要将信息记录到订单表中。因此通常来讲，业务表不应为数仓的需求增加复杂逻辑（这会影响业务）。
因此，相比于埋点、日志，业务表结构清晰，数据准确性最高（如果数据不准，业务系统首先受到影响）。
（2）埋点
埋点一般需要单独在业务系统嵌入代码，调用数仓数据采集接口，当用户触发埋点行为时，自动将信息上报到数据仓库。采集到的数据多为 json 格式，由数仓处理成结构化数据。
埋点设计的核心目的，是为数据采集服务的。如果说其他两种数据采集方式叫做“有啥用啥”，那么埋点则是为了实现“用啥采啥”。但是，埋点最终还是为业务数据分析和数据应用服务的，因此在埋点采集时，同样也应当遵循业务优先的原则——即埋点采集不应过度影响业务系统的使用效率，不应对业务系统造成负面影响。这就需要我们把握好尺度。
例如，可接受案例和不可接受案例
可接受： 在投放页上打点采集用户行为数据，一定会影响投放页的加载效率（加载代码变多了 & 占用了部分带宽发送埋点信息），那么此时根据经验或经过测试，对页面加载时长的影响极小，例如 1%-2%，从1s变成了1.02s。这个埋点方案就可以接受。
不可接受： 检测用户关闭投放页的行为。此时存在一个顺序问题，因为用户点击关闭按钮时，页面会关掉，在关掉之前可以发送一个埋点。但因为埋点会丢失，所以一般埋点可以设计补发机制；在这个关闭页面的case中，我们如果设计成通过补发机制确保埋点上报成功后再退出页面，这就是不可接受的（用户不能点击关闭后等2s再退出，而且仅仅是因为要采集一下关闭页面的事件，，这就有点买椟还珠的意味了）
尽管埋点在采集数据上拥有其他方法不可比拟的优势，但它也确实存在着设计方案复杂、容易丢失数据、存储和应用成本较高等问题。
（3）日志
日志类似于系统的日记（其实叫流水账更贴切一点），日志会存储到专门的日志表中。数仓可以通过日志表获取日志数据，并处理成结构化数据。日志的服务对象一般是产品、研发、运维等角色，主要用于排查系统问题或记录系统中某些信息的变更状态，如下：
排查系统问题：例如，检测服务器资源使用情况；
排查代码bug、记录系统中某些信息的变更状态：例如，当 某日业务系统中，A销售的项目组由x变更为y，此时业务表中一般只记录变更结果，变更时间信息，可以存储在日志中（当然，变更时间信息如果在业务系统中有重要应用，也可以专门做一张业务表）
相比其他两种采集方式，日志添加方便，但数据准确性不高，处理也比较麻烦。只能作为数据采集的一种补充方式。
18、数据仓库每层命令设计规范
命名规范
具体情况还是应在项目组内制定统一的数仓分层、脚本、任务调度等命名规范。
| 数仓分层 | 命名规范（参考） |
|---|---|
| ODS | ODS_应用系统名(或缩写)数据库类型(数据库名称可省略)_数据表名_增全量后缀;例如：ods_erp_mysql_oder_info_di |
| DWD | DWD_主题域缩写_表名主体_增全量后缀;例如：dwd_member_order_info_di |
| DWS | DWS_主题域缩写_表名主体_增全量后缀;例如：dws_member_order_info_di |
| ADS | ADS_主题域缩写_表名主体_增全量后缀;例如：ads_analysis_sale_offline_ds |
| DIM | DIM_表名主体_增全量后缀;例如：dim_goods_dd |
19、大数据企业离线数仓架构分析
20、数据仓库架构技术选型实战
参考：
[大数据数仓项目总结（一）需求、技术选型、框架版本、服务器、集群规模_数据项目评优数仓技术介绍-CSDN博客]
项目框架及选型
A 技术选型
1）技术选型主要考虑因素：
业务需求
数据量大小
行业内经验、技术成熟度
开发维护成本
总成本预算
2）可选择技术：
数据采集传输: Flume，Kafka，Sqoop，Logstash， DataX
数据存储: MySql，HDFS，HBase, Redis，MongoDB
数据计算: Hive，Spark，Flink，Tez， Storm
数据查询: Presto，Kylin，Impala，Druid
数据可视化: Echarts、 Superset、QuickBI、DataV
任务调度: Azkaban、 Oozie .
集群监控:Zabbix
元数据管理: Atlas
B 项目架构与数据流程
1）系统数据处理流程
2）数据仓库的输入数据源和输出系统分别是：
输入系统：埋点产生的用户行为数据、业务系统产生的业务数据等
输出系统：报表系统、用户画像系统、推荐系统
D 服务器选型
服务器选择物理机还是云主机?
1)物理机成本：
硬件成本： 服务器配置及对应单价和寿命等方面考虑
运维成本：需要有专业的运维人员
其他费用：电费、场地、空调等——配套成本
2)云主机成本
硬件成本：以阿里云为例，差不多相同配置，每年5W。
运维成本：很多运维工作都由阿里云完成，运维相对较轻松
3)企业如何选择：
主要考虑企业数据规模、发展预期、资金实力、业务属性等
资金充裕且和阿里没有直接冲突的公司———选择云主机
中小公司（短期）为了融资上市———先选择云主机，后买物理机
有长期打算，资金比较足的公司———选择物理机
E 集群资源规划设计
如何确定集群规模？
首先要考虑自己单台服务器的性能，
其次要考虑的是每日的数据规模：每日活跃用户、用户平均每日数据量
副本策略：一般2~3个副本
扩容周期：半年不扩容
预留空间：一般20%~30%
考虑数仓分层
假设每台服务器配置：128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘：
简单版：
一天日活用户：100万
一人一天数据：100条
一条日志大小：1 K左右
一天数据：1 亿条
半年数据：100G * 180天 ≈ 18T
副本数据：18T*3=54T
预留20%-30%大小：54T/0.7=77T
结论：8T*10台服务器
考虑数仓分层、压缩、副本策略等其他各项：
1)每天用户行为数据规模：以每天日活跃用户100万，每人一天平均100条日志数据，每条日志大小1K，则： 100万∗100条∗1K/1024/1024=约100G/天
2）Hive数仓分层：
ods与dwd层：采用LZO压缩+列式存储，每天100G数据压缩存储后两层共计：10G∗2=20G
dws层聚合不压缩：50G
再加上HDFS分布式存储的3个副本，共计：70G∗3=210G
3)半年内不扩容服务器来算：210G∗180天=约37T
4)预留20%~30%Buf：37T/0.7=53T
5)kafka中：每天100G数据，两个副本，预留7天，预留30%空间：100G∗2∗7/0.7=2T
6)flume忽略不计
7)业务数据：
按照每天下单10万，每人每天10条，每条1K：10万101K/10^6=1G 算上3层数仓存储、3个副本、180天扩容周期、30%预留：1G∗3层数仓∗3副本∗180天/0.7=约2T
8）日志数据存储周期30天： 100G∗30=3T
9）共计 53+2+2+3=60T
结论：大致需要8T*8台服务器
F 测试集群规划
需要考虑的问题：
1、测试服务器多少台;
2、测试环境什么样;
3、测试数据哪里来;
4、如保证写的SQL正确:
5、测试之后如何上线
测试集群规划：
尽量将耗内存的服务分开安装
客户端服务放到一起
Flume与Kafka安装对应起来
21、数据仓库架构设计
1）Lambda架构 Lambda 架构总共由三层系统组成的：批处理层（Batch Layer），速度处理层（Speed Layer），以及用于响应查询的服务层（Serving Layer）。
更详细的架构图：
批处理层: 使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。
速度层: 通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
总结： 批处理层保证数据的完整性和准确性，速度层保证数据的时效性，但是缺点是需要维护两套逻辑代码，维护较复杂，有没有可能在批处理中实现实时计算，或者在实时处理中实现批处理计算呢？于是就有了下面的kappa架构。
2）kappa架构
与 Lambda 架构不同的是，Kappa 架构去掉了批处理层这一体系结构，而只保留了速度层。你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。
kafka可以通过设置来决定数据的保留时长，七天、一个月、或者永久保留，且kafka是通过offset来决定从哪里读取数据，因此当我们的业务逻辑改变时，需要重新读取所有历史数据时，只需要把offset设置为0即可。
如果你所面对的业务逻辑是设计一种稳健的机器学习模型来预测即将发生的事情，那么你应该优先考虑使用 Lambda 架构，因为它拥有批处理层和速度层来确保更少的错误。
如果你所面对的业务逻辑是希望实时性比较高，而且客户端又是根据运行时发生的实时事件来做出回应的，那么你就应该优先考虑使用 Kappa 架构。
