168大数据
标题: 两篇数仓建模文章 [打印本页]
作者: 168主编 时间: 2019-7-3 14:24
标题: 两篇数仓建模文章
本帖最后由 168主编 于 2019-7-3 14:29 编辑
本文转自下面两个文章:
在转载之前, 先说明我认为比较合理的数仓分层:
有关ODS 层:
ODS层存在的意义已经被大量证明, 加上一个ODS层, 在技术层面可以保障业务系统稳定, 同时ODS也是数据团队和业务团队的一个天然职责分界.
ODS和业务数据库的同步最好是使用现成工具, 比如OGG/canal/sqoop/Debezium. 这些工具抽取效率高, 能适应业务数据表的变更, 甚至能做到实时.
如果业务系统只能通过文件的方式导出数据, 推荐使用avro格式(比定长文件或csv文件更高效并易于处理)
如果业务上对于实时性要求很高, 最好将业务直接架在ODS层上.
ODS层可以和DW是同一类数据库, 也可以是异构数据库.
放在同一类数据库的好处是: DW和ODS交互将非常简单, 会节省很多ETL工作量, 如果是异构数据库的话, DW抽取ODS数据就不那么方便了. 这里可以再深入分析一下, 因为业务数据库是OLTP库, OGG/canal要求同步的目标库也是OLTP, 而DW往往是用OLAP库.
如果我们是使用Oracle来架构小型DW, 通过OGG可以很容易将ODS和DW放在一起, 否则DW和ODS一定是异构. 还有一个思路可以将ODS层也放进OLAP库, 方法是引入Cassandra, 将OGG结果发布到Cassandra上, 然后采用mini batch方式消费到数仓中. 网上更多的是引入 Kafka 而不是 Cassandra, 个人认为使用Cassandra要比Kafka更合适, 因为 数仓涉及的数据, 都是结构化的数据, Cassandra的吞吐能力也很不错, Cassandra 的查询和数据消费比 kafka 方便多了.
有关DWD层:
实时表应该是原始粒度的，即存放各主题域的最细粒度数据。
有关DM层:
一般地DM层内的数据多用于报表, 数据一般是大宽表, 揉合了多个度量值, 在粒度上也已经降维处理.
有关APP层:
DM层多用于报表展现, APP层多是将数据回馈给其他分析系统使用, 比如提供用户画像数据.
文章1: 洋码头数据仓库实践作者介绍
孔永兵, 洋码头高级数据仓库工程师
长期从事数据仓库相关工作，有丰富的数据库开发、设计、性能调优及仓库架构经验，目前负责洋码头数据仓库架构设计及BI事务。
随着洋码头公司业务的快速发展，需要分析和处理的数据更加多元化和复杂化，原有传统关系型数据架构已很难满足公司各业务方面的需求。数据仓库的建立将洋码头业务按不同的主题进行维度建模，实现数据快速读取、及时响应，同时也为产品、运营及数据分析人员提供了更加方便快捷的数据提取平台。本文对洋码头数据仓库从无到有的过程做个大体介绍。 |
本文约2400字，可参阅下面的大纲阅读。
1. 洋码头数据仓库的三个阶段
2. 洋码头数据仓库技术架构
3. 遇到过的问题
3.1 代理键的使用
3.2 迟到维度的处理
3.3 缓慢变化维的处理
4. 参考书籍
1. 洋码头数据仓库的三个阶段
洋码头数据仓库的发展经历了从简单报表阶段、数据集市阶段再到数据仓库阶段的过程。
简单报表阶段, 在此阶段，系统的主要目标是解决一些业务运营人员的日常报表展现，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据，灵活性差，性能低。
数据集市阶段, 在数据仓库建立之前，根据特定部门业务人员的需要，进行指标整理、清洗、转换，进行多维报表的展现，为特定业务提供数据支持及决策。
数据仓库阶段, 按照业务主题进行划分，使用kimball经典的维度建模方法，经过指标清洗、转换，构建成一致性维度及事实表，提供跨部门的，完全一致的业务报表数据。数据仓库建好以后，数据提取效率有了质的提升，与前端报表工具整合更加容易。
2. 洋码头数据仓库技术架构 2.1 架构
图1 - 架构图
如上图所示，洋码头数据仓库由数据源, 数据整合, 数据存储, 数据展现&分析,及ETL调度等几个模块构成。
2.1.1 数据源
洋码头的业务数据来源于SQL Server、MySQL、MongoDB，包含了用户、买手、商品、优惠券、活动、订单、物流等码头核心业务数据。
用户行为数据来源于前端埋点生成的各种访问、点击事件，通过用户行为数据来分析app页面模块的粘性、活跃程度及产出情况。
2.1.2 数据整合
数据整合层将数据源中数据通过ETL框架平台经清洗，整合及转换后存储到数据存储层，在数据抽取转换过程中，根据不同的业务采取不同的调度频度。
2.1.3 数据存储
数据存储层又可分为ODS层、DW层及DataMart层。
ODS层用于存储自源系统抽取过来并经过清洗后的数据，由于该层是准实时的数据，大部分准实时的报表数据都来源于ODS层。
DW层是采用kimball的总线式数据仓库架构，针对各主题进行维度建模后构建的一致性维度及事实表，DW层的粒度是原子的，即存放各主题域的最细粒度数据。洋码头目前分布的几个重要的主题有用户、买手、商品、优惠券、活动、订单、物流。
DataMart层存放经由DW层数据经过一定的加工、汇总聚合而成的宽表，如用户画像、买手经营能力指标、买手DSR指标、商品动销数据、物流监控等。
2.1.4 数据展现
报表展现及数据指标监控，为运营人员提供运营效果展现及运营决策支持，为管理层提供决策依据。数据分析及数据挖掘，为特定主题中主体进行价值分层，如用户价值分层。
2.1.5 ETL调度
在ETL调度中，根据不同的业务需求配置不同调度，如从数据源到ODS的并行抽取调度，及DW中根据各主题域按顺序依赖进行调度。在调度中详细记录每个任务的开始、结束时间，状态，新增记录数，更新记录数，错误日记及遇到错误是及时报警。
图2 - ETL日记
2.2 维度建模
2.2.1 模型选择：星型vs雪花型
在维度建模过程中，根据事实表和维度表的关系，可将常见的模型分为星型模型和雪花型模型。在设计逻辑数据模型的时候，应考虑数据是按照星型模型还是雪花型模型进行组织。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。 也正因为这种冗余，很多统计查询不需要做外部的连接所以一般情况下效率比雪花型要高。
雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。
在洋码头数据仓库建设中，两种模型都有用到，但用的最多的是星型模型，这样不只是查询效率更高，对于不甚了解业务的新员工，相对雪花模型，能够快速、较好地操纵模型。
图3 - 星型模型
图4 - 雪花型模型
2.2.2 逻辑设计
维度模型的逻辑设计是由四个主要决策所驱动的。
1) 选择业务过程
第一步是选择要建模的业务过程，业务过程是维度数据仓库的基石，每个业务过程至少会产生一个事实表。以订单业务为例，确定订单业务后，首先要对订单数据进行初探，了解该业务中有哪些数据产生及产生该数据时是否关联其他业务。
2) 声明粒度
声明粒度也可以理解为声明主键，选择粒度时既要考虑到用什么来满足业务需求，又要考虑基于源系统收集的数据可以得到什么。数据仓库中建议存放最细粒度的数据，以订单业务为例，订单业务将会产生两个事实表，基于订单号粒度及订单号加商品规格粒度。
3) 确定维度
当确定好粒度后，大多主要维度也就很自然的产生了，以订单为例，粒度确定好了，对应的维度：用户、买手、商品、活动、优惠券等都已确定。
4) 确定事实
确定事实也叫确定度量，大多数面向事务的业务过程只有少量的基础事实，如数量和金额，但是却有很多从这些基础事实导出的组合和计算结果，以订单为例，有订单金额、商品数量、商品单价、商品金额、优惠券金额、实付金额等许多度量值。
图5 - 维度建模
3. 遇到过的问题
1) 代理键的使用
是否要使用代理键？这是维度建模过程中经常遇到的问题。
如果数据仓库数据来源于不同的系统，且各系统之间的主体需要合并以达到企业一致性维度时，需要使用代理键。
如果数据仓库维度表涉及到缓慢变化维，需要跟踪到历史数据，需要使用代理键。
如果数据仓库中业务键是字符类型(如Guid)，做关联查询时效率非常低，建议使用代理键。
洋码头数据仓库在维度建模过程中主要针对后两种情况来生成代理键。
2) 迟到维度的处理
数据仓库的重要特点之一就是一致性维度，由于洋码头数据仓库在建设过程中使用了代理建，导致有时候某些维度(如优惠券、商品)可能有比事实记录晚到的情况。此时需要在维度表中建立一条“未知”的维度记录，对于迟到的维度，都将该“未知”维度的代理键做为相关事实表的外键。等迟到的维度到来后，再将建立好的维度的代理键更新到相关的事实表中。
图6 - 迟到维度处理
3) 缓慢变化维的处理
在洋码头数据仓库维度建模过程中，针对需要根据时间追踪历史数据的维度，使用Type2-添加一个新的维度行的方式来处理，如下例，员工金波2015/4/8前居住在广州，之后搬到上海，按照覆盖原值的方式，金波的现居地为上海，按区域统计数据时他所有的销售数据都会归到上海。现将用户维度做成缓慢变化维，在统计金波2015/4/8之前销售的数据时，归属地为广州，以此达到追踪历史的目的，该方法同样可以用在拉链表的设计上。
图7 - 缓慢变化维处理
文章2: 大数据环境数据仓库&维度建模这篇文章是一个ppt, 我截取了主要几个页面.
| 欢迎光临 168大数据 (http://www.bi168.cn/) |
Powered by Discuz! X3.2 |
