数据仓库的构建思路

猫友会希望建立更多高质量垂直细分社群，本次是"大数据学习交流付费群"的第十期分享。

“大数据学习交流付费群”由猫友会联合，斗鱼数据平台总监吴瑞诚，前卷皮BI技术总监柴楹，盛天网络大数据平台负责人王欢发起，希望带动武汉的技术分享氛围， 欢迎大家加入！（ 文末有入群方式 ）

欧阳烈—Today 应用架构师

主要是我过去 4 年工作的一些心得体会， 主要是对数据仓库的每个模块的作用和目标做解析，希望对玩数据的小伙伴们有所帮助，不要再采一些重复的坑。

大数据已经是好几年前的热点，数据仓库则是 30 年前的概念，在几年前随着大数据行业的爆发，作为数据基础环节的数据仓库也随之小火了一把。数据仓库在互联网行业也有越来越重要的地位，现在数据仓库也不仅仅是 30 年前提出时的维度建模，现在的数据仓库是集数据备份、数据清洗、数据建模、指标口径、数据治理、数据规范乃至部分后续数据应用为一体的数据解决方案。

数据仓库是一个外行看起来很高深，入门却发现很简单，但是要做好又很难的工作。。。我举个以前和业务部门 VP 一起聊的看法，以盖房子为例，基础架构便是 BI 的地基，所有的环节都是在基础架构上面运行。

那么，数据仓库的小伙伴做的就是烧砖的工作，负责将来自不同地方的数据源，统一制成规格一样，大小统一的砖，以供后续数据应用使用 ( 非关系型数据怎么统一 ?)

我觉得这个比喻非常的好，将数据仓库工作中 ETL 、数据建模等工作中最重要却又最容易被忽视的的【规范】体现出来了。

我们往往按部就班的按照业务部门的需求去做数据清洗，做数据处理的逻辑等等一系列事情，只有当你意识到数据规范是贯穿整个数据仓库中重要的一环，很多问题才会迎刃而解。

额，解释下我刚刚说的问题哈，包括无尽的取数、无尽的数据逻辑变更、无尽的线上数据 BUG 。。。。不知道能不能引起大家的共鸣哈

下面分享下我们的数据体系结构图

我接下来会对这张图的各个模块进行讲解

一、首先是数据源和 ODS 层

数据仓库需要将尽量多的数据源汇合在一起，数据源越丰富，后续的数据应用也会更实用。所以数据仓库需要经常考虑要接入哪些数据、接入这些数据的代价是什么，能得到的产出有多少。

常见的数据源有业务系统数据 < 一般来自各种不同的关系型数据库 > 、埋点、日志类数据、网络舆情、爬虫数据和文件数据等。

ODS 层的数据会完全和数据源一致，起到的作用是将不同源的数据进行整合，同时会保留完整的历史 ---- 相对于业务系统线上数据可能会定期清理历史数据、不稳定的文件可能会丢失问题， ODS 一定会有最全的数据。。。同时， ODS 也是一份可靠的数据备份，并非简单的抽取。

我们的 ODS 层数据是用的 hdfs 存储，在和业务系统同步数据时也踩过主键数据更新的坑，这里不详细说了哈，有兴趣的下去交流，如果有疑问的我一定会提供力所能及的帮助

二、公共维表层

我们最开始做数仓的时候其实也没有考虑的这么长远。维表就是供给 dw 的数据使用。

但是随着业务的发展， BI 也越来越庞大，后面所有 DW+DM+RPT+ 各种数据应用，光维表就有接近 200 张。

里面绝大多数都是重复的，所以后续做出改良，将所有的维表进行整合，做的过程中就会发现，维表不仅仅是业务系统的映射，只要建模合理，维表是可以直接对外开放的，例如直接作为报表中某个查询维度的枚举值、给某个数据应用提供接口等等。

除了普通的维表外，我们往往还会制作很多的手工维表 ---- 有业务含义，但是往往是某个业务表的某个字段，不是通过 etl 抽取而来，例如商品类型

历史维度表 ---- 需要关注某些维度在具体时间点的表现情况，例如如果业务形态上商品价格会不定期的调整，那么可能需要制定历史商品表，来反应每个时间节点上的商品信息。

此外还会制作大维表 -- 大维表主要用于直接和事实表关联，他会冗余很多维度子集的信息，例如在商品维表中，我们一般会将其类目 ID 、类目名称冗余进去，这样事实表只需要和商品维表 1 张表关联，就能取到足够多的维度信息。

维表的制作一定不要忘记做缺省值，缺省值可以保证后面的事实表与维表关联时均可以使用 join 关联，不需要让数据仓库的使用人员记忆过多的业务逻辑，更重要的是让直接展现给业务方的数据应用展现数据的时候，不会动不动出现 null 值这种尴尬的事情

三、数仓事实表 + 集市层

事实表会经常提到数据建模的概念，因为在业务系统中库表结构的设计是为了满足业务系统的快速、稳定的运行，所以会牺牲统计查询上的便利和效率，在做数据仓库时，需要充分的考虑业务方的统计需求去实现。

除了常见的业务事实表之外，我们还有一些常用的事实表类型

累计快照事实表 ---- 确定事实粒度后，将业务方关心的、在同一事实粒度下的数据尽量的融合在一起 -------- 例如业务方关注订单明细、乃至后续发生了售后、退单等行为，那么我们会将订单和售后单融合，形成 " 订单生命周期 "。

累计快照事实表 ---- 确定事实粒度后，将业务方关心的、在同一事实粒度下的数据尽量的融合在一起 -------- 例如业务方关注订单明细、乃至后续发生了售后、退单等行为，那么我们会将订单和售后单融合，形成 " 订单生命周期 "。

周期性事实表 ---- 业务方关心固定周期的统计数据 -------- 例如商品库存，一般库存是由订销存费计算得出，如果放任后续数据应用去统计，则会导致各个应用的重复计算，且如果每个应用都是即席查询，对集群性能也是很大的考验，所以一般会针对这种需求，做成周期性事实表。

四、 指标口径

指标口径是公司层面的沟通问题，如果没有指标口径的管理，各个业务部门之间的沟通会变的异常困难，同样每天销售额，不同业务部门之间可能理解都存在差异。而数据仓库的研发人员也在频繁的对外解释数据应用中繁杂的指标中疲于奔命。

所以指标口径的管理应在数仓的迭代过程中持续不断的去完善和优化，在业务少且简单的情况下也应当有完备的文档和数据字典以供查阅。在业务量增大或者变得越来越复杂时，维护的指标口径会急剧增多，数据字段和文档往往不能满足口径管理需求，这时就需要对指标口径进行分类。

结合业务元数据和技术元数据以及方便后续扩展血缘关系，指标口径可以分为以下三类 :

基础指标 ---- 最基本的指标，往往是在某张事实表中直接统计而来 < 例如【销售额】，是在订单表中 sum(sale_amount)>

衍生指标 ---- 【基础指标】加上了修饰词，同样是某张事实表统计出来，但是带上了一些过滤条件 < 例如【武汉销售额】，是在订单表中 sum(sale_amount) ，且带上了 where city=' 武汉 '>

复合指标 ---- 多个基础指标或者衍生指标计算而来 < 例如流量中的平均会话时长，则是【会话停留时间】 / 【会话数】 >

按照上述的分类方法后，我们只需要重点维护好基础指标即可，衍生指标和复合指标可以根绝业务方的想象力随意扩展，也不会影响我们指标体系的基本盘面

指标口径就是我们的【业务元数据】，大家可以发现业务元数据 其实和 SQL 有非常紧密的对应关系，所有的指标都是通过 sum/count/count distinct 而来。

在此基础上，可以进一步的对我们集群上所有跑的 SQL 进行解析 < 有个开源项目 antlr 可以帮助做这个事情，如果你用的 hive ， hive 里面自带了解析语法的类 >

就可以将技术元数据和业务元数据进行打通，，，这些可以帮助我们进行数仓建模，可以了解业务方更了解哪些数据等等。

五、数据监控

这个我简单介绍下，数据仓库所有的数据均是通过 ETL 而来，从源数据到最终的数据应用的链路往往会很长，所以我们还需要针对整个 ETL 流程做监控，一般我们对数据的指标波动范围、一致性、和数据业务逻辑进行监控。

监控是挂在每个 ETL 的作业上，根据作业程度的不同，又会分成阻断和继续两种不同的级别。如果作业很重要，数据异常则需要研发人员及时处理，会报错、阻止作业链的执行并打电话通知。

如果作业不是非常重要可以第二天处理的，则设置为继续，后续作业继续执行，发邮件报错但是不会在晚上集群跑批时强行拉研发起来处理

六、数据流程规范

数据仓库是数据的下游，数据是由业务方、用户方使用业务系统产生，最后才能被数据仓库抽取到，整个环节如果有了偏差，则会导致数据处理异常的困难，而业务系统的研发人员往往只会保障功能上的需求，对数据上的需求往往会有所纰漏，所以好的数据仓库，一定会指定好对应的数据规范，下面列举几个实际数仓迭代中我们合业务人员一起推动，给业务研发人员指定的规范。

建表规范：所有的业务表均需要有创建时间和更新时间，且这两个时间是数据库自己更新和写入，不参与任何业务逻辑 ---- 应该规范的公司里一定会有这个研发规范，但是在中小型团队中容易被忽略，导致数仓构建时，遇到不知道怎么抽取数据的问题。

url 规范：在前端的 url 中会带入埋点相关信息且按照规范的格式存储，后续数仓消费到的埋点日志会自动写入数仓，无需数仓人员二次开发 ---- 极大的简化了数仓的研发周期。

七、数据应用

每个公司的数据应用可能都不太一样，这里我列举下因为离数据最近，数仓的小伙伴们经常会负责的数据应用。

报表工具 ---- 固化需求配置成报表，每日展示。

邮件平台 ---- 未固化需求通过 SQL 定时执行生成邮件发送给业务方 -- 配邮件也很麻烦，但是总会比制作报表方便快捷。

olap 平台 ---- 可以选择维度、指标进行即席查询的数据平台，部署简单，本身 olap 需要的数据也是数仓构建的必经之路，一般一个集市层的表直接拖出了就可以放入 olap 系统中。

数据平台 ---- 供有数据处理能力的人员使用，构建数据仓库后，数据一定是易用的，可以让有能力的业务方定制化的查询数据。

好啦，以上就是我今天要分享的内容，希望对大家有所帮助，有疑问的可以在群里直接提问，我会尽我所能的提供帮助

Q&A   互动问题 :

Q :  有很多 ETL ，如何监控他们的执行情况呢，有没有可视化的界面 ?

A  :    我们的调度系统是 zeus ，因为有这个监控的需求，所以让架构的小伙伴进行了二开，可以直接在界面上配置检查的 SQL, 我们的小伙伴二开的工期加上后面还调整了一次，大概是 2 人时 , 就是在作业执行完之后，会去查结果数据是否符合预期 , 就是在作业执行玩之后，会去查结果数据是否符合预期。

Q：数据是事实进 ods 么，业务数据更改是如何更新

A： 我们的数据规范要求业务系统中全部会写 updatetime ，然后晚上集群调度的时候统一批处理 updatetime 大于前一天的数据。

Q： 如果每次只抽 a 和 b 表 1 天的更新数据 , 然后要组合成 c 表 , 处理完成后清除抽取的数据 , 但可能 b 表并没有更新 , 所以在组合时 c 表就会有很多空字段 , 那些字段的数据在源系统中存在 , 有什么解决方法吗 ?

A： 应该缺失了 ODS 层，建议最好增加这个层级，抽取 a 的数据后存入 ods 层的 a 表，抽取 b 后存入 ods 层的 b 表，然后后续再对 a 和 b 做处理，就能避免你说的问题。

Q:   请问使用数据仓库的业务对数据仓库的构建有什么具体的要求么？ 一般在接手设计一个数据仓库时，业务部门都会提出什么样的要求呢？

A:  在构建数仓的时候，其实业务部门肯定已经有数据需求了，第一可以去看看他们在看什么样的数据，有哪些维度、指标，然后带着问题去研究业务库。

Q： 你们的数据是 t +1 ，你们有没有事实数据需求？有没有想过事实流入方案。 olap 是用的什么技术实现？

A： 有实时数据，实时数据我们搞过 3 套方案。第一套是业务数据直接使用关系型数据库，存少量数据，流量数据用 spark 计算，然后在前端统一去展现，第二套是在业务接口里设计埋点，比如调订单接口的时候直接一个 http 请求将订单发送到 kafka ，然后 spark 消费出实时的订单数，第三种是 mysql 特有的，直接将有更新的数据发送到 hdfs ，然后查询的时候查最后一个版本的数据。

Q： 请问 , 有没有一些小经验可以优雅地设计数据分层

A： 数据分层不要太多，你刚刚给我说的阿里的方案我也是刚刚去 Google 查的，然后发现大家的思路是一致的， ods 层负责存储明细数据、保留历史， dw 负责清洗转换，做指标逻辑等， dm 层做数据建模，按主题建宽表，直接对外。

Q： 在数据的抽取过程中会产生的文件 , 相对来说不是很重要 , 但是比较占空间 , 需要保留吗 ?

A： 可以定期清理下就可以了，保留最近 7 天这样，保障近期出了问题可以查 , 也可以设置大小

感谢  猫友会自愿者 陈龙文  的文章整理， :+1:！（排版小猫助手～:sweat_smile:）

添加小猫助手，加入猫友会交流群