当前位置：首页 > 网文库 > 正文

网易杭研PMO数仓建设是如何从0到0.1的

时间：2021-01-11　　来源：网易杭研项目管理廖永洲

需求，以及未来业务数据接入的可能性，PMO数仓将整体架构分为3层，分别是：

odl层（数据传输层），dwl层（数据仓库层），dml层（数据集市层）。这三层，即代表了数据在数仓中流动的所有环节。

odl层：数据传输层，即从各个数据源（如EP、JIRA）抽取原始数据，生成odl数据表，并存入数仓平台的过程。这个过程生成的表，称为odl表。

dwl层：数据仓库层，从数仓平台调用odl表或其他dwl表进行数据操作，并生成新的dwl表的过程。这个过程产生的表称为dwl表，或过程表，一般情况下，过程表不会用于数据报表制作。

dml层：数据集市层，从猛犸odl或者dwl层调用数据表，经过操作，成为可供有数用户使用的数据表，称为dml数据表。有数上pmo公共文件夹的数据模型，都是基于dml层的数据表。dml数据表正常情况下不会进行大的变动。

其关系可以用以下图示表示：

利用这样的分层结构，我们可以比较清晰地区分出，ETL过程中，各个表的定位和用途等。下面我们利用树结构的表设计这样一个例子，说明一下ETL的必要性。

树结构的表设计

我们先不管树结构是什么。众所周知（现在讲这个成语有种莫名的喜感），任何产品的数据库设计的出发点，都是产品功能的实现，以及产品运行成本和性能。因此，大部分产品自身的数据库，并不具备直接的业务逻辑。

在举例之前，我们先说说数仓初建时遇到的一个问题，是单据之间的关联关系。

首先单据又是什么。读者应该很多人使用过jira这个工具。其实，jira上的bug单子，story单子，task单子，我们都称之为单据。每一个单据之间都可能存在关系，比如story下挂task。JIRA各单据的关系，被存储在不同的数据表，相互之间的关系一般由中间表维护，对于业务在管理上的度量需求并不友好。各类工具对于单据功能本身的数据库设计，一般是这样的，我们以JIRA为例：

JIRA数据库中，subtask和story之间的关系，其关联类型为“jira_subtask_link”。也就是说，subtask和story，其关系，靠“jira_subtask_link”这个字段维护。其表结构如下：

这表示，1号单据，是2号单据，通过拆分子任务的方式生成的。此时，若story有个父级是epic，则story与epic关系的表结构如下：

可见，subtask与epic没有直接关系，两者的关系并不会出现在一条记录里，story作为一个中间者，间接关联了这三层关系。

这样，就会给数据统计带来了不便。

举一个场景，A想知道某epic下的人力投入。根据产品设计，人力投入是记录在subtask上的，epic和subtask没有直接关联关系，我完全不知道某epic下有多少subtask。那么制作报表就无从下手。

类似的，如果单据的层级增加，关联关系种类增多，再加上各种越级关联，数据分析的困难度就会更高。

我们可以看看，下面是JIRA的部分关联关系，任意3种关联关系 + 任意5种单据类型，其场景已经非常复杂。（红色表示目前不被PMO认可的关联关系）

如何解决上面提到的场景呢？当时的想法是，将任意单据的所有层级关系，放在一条记录里。PMO标准中，层级最多为5个，至下而上分别是：subtask，task，story，feature，epic。

即，一个subtask，其父节点task，以及往上的story，feature和epic，都体现在一条记录中。如果没有完整的5个层级，没有的层级该列则显示null。

于是经过了一番处理（具体细节非常复杂，不在此赘述）后，我们形成了一张表，这张表仅有6个字段，即subtask，task，story，feature，epic，以及这些单据所在的jira项目。表结构如下：

在这种情况下，整一条链路的5个层级，都存在一条记录里。那么解决以上场景的问题则非常简单，我们只需找到具体的epic_id，就可以找到其下所有的subtask_id了，简单做个汇总，所有的工作投入就可以得到。

上面问题类型和关联关系的复杂场景，被理顺为：

单据，作为JIRA工具的核心，单据之间的关系自然是其核心骨干。于是，我们把这张表的层级关系，比作树的主干。回到刚刚的场景，我想要获取subtask上的人力数据。在得到这样一个层级关系之后，我们需要得到这些层级的维度和事实。如，subproduct是一个维度，original estimate是一个事实。我们可以理解为，无论维度还是事实，都是该层级关系的属性。subtask上有很多属性，包括其名称，负责人，原预估时间等。我们把这些属性，比作叶子。

于是，主干+叶子，就形成了一棵树。我们称之为树结构模型

分享到:

免责声明：

1、PMO评论发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。

2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！

上一篇：
从抗疫医院建设谈中国式项目组合管理“集成术”
下一篇：
立白集团PMO专员林靖钰参加“白云泵业杯”三人篮球赛

延伸阅读：

本站推荐

独家PMO、项目经理和敏捷教练学习材料，欢迎阅读！

第十二届中国PMO大会会刊资料，主题：拥抱变革展现PMO力量；第十一届PMO大会（线上会议）会刊资料，主题：解码战略赋能项目 PMO笃行致远；第十届P...
第十二届中国PMO大会在京成功召开

由PMO评论主办，以“拥抱变革展现PMO力量”为主题的第十二届中国PMO大会在京成功召开。全国项目管理标准化技术委员会俞彪秘书长、《项目管理技术》杂志...
2022第十一届PMO大会（线上会议）成功召开

PMO大会是PMO评论主办的全国PMO专业人士年度盛会，是业内了解PMO前沿理论与资讯，分享PMO最佳实践经验，彰显PMO价值的高端会议交流平台。至今，PMO大会已...
2022第三届中国项目经理大会成功召开

由PMO评论主办，以“鏖战项目使命必达”为主题的2022第三届中国项目经理大会于11月26-27日、12月3日以三天线上会议形式成功召开，大会特邀29位来自华为...
2022首届中国敏捷大会成功召开

12月17-18日，由PMO评论主办，以“拥抱变化拥抱敏捷”为主题的2022首届中国敏捷大会以线上会议形式成功召开，大会特邀来自腾讯、京东、美的、海尔、OPP...
2021第十届PMO大会线上会议成功举办

由PMO评论主办，以“探索中奋进领航PMO新时代”为主题的第十届PMO大会于2021年8月28-29日、9月4-5日以线上会议形式成功举办。来自华为、亚马逊、京东、...
第二届中国项目经理线上会议成功召开

11月27日，由PMO评论主办的第二届中国项目经理线上会议顺利召开。本次会议主题为：“执项目牛耳悟管理精髓”，来自腾讯、京东、阿里云、大族激光、用友...
从联想的战略升级解剖PMO的价值︱PMO案例分享

PMO：Project Management Office，项目管理办公室。一般企业的PMO有两种大的存在形态：1）公司的主营业务本身就是以项目开展的，公司需要成立PMO管理业...

more >> 活动圈

more >> 公开课

more >> 书刊柜

《娓娓道来：高效项目管理100法》

本书从项目管理的十大知识领域出发，对每个知识领域所涉及的核心知识点进行剖析。无论是计划管理的“边界条件”、风险管理的...
《PMO论文集（2016）》介绍

和人力资源部、行政办公室等职能部门相比，PMO（项目管理办公室）无疑是很年轻的，国外最早出现这一部门是在20世纪90年代，而...
《成功的项目始于卓越的管理》

《成功的项目始于卓越的管理》重点介绍了很多浪潮在推动组织级项目管理过程中使用的一些卓有成效的方法、工具、模板，如项目...

网易杭研PMO数仓建设是如何从0到0.1的

免责声明：

延伸阅读：

本站推荐

活动圈

公开课

书刊柜

《娓娓道来：高效项目管理100法》

《PMO论文集（2016）》介绍

《成功的项目始于卓越的管理》

PMO评论网微信公众号

PMO大会微信公众号