【dwd022】数据产品经理如何促进数据仓库的着陆

编辑指南：产品经理这个职位有数据产品经理、B端产品经理等多个领域，每个领域的重点和工作内容都不一样。数据产品经理不仅要具备现有PM必须具备的产品设计能力、项目管理能力等技术，还必须具备数据技术。本文作者分享了数据产品经理如何推进数据仓库的落地。让我们一起看看。

如果十年前，数据仓库的建设无疑完全是开发工程师的工作。随着业务的发展和细分，对产品经理提出了更高的要求，尤其是数据产品经理职位的出现，产品经理知道技术已经是大势所趋。

今天，我们将讨论数据仓库构建中的哪些工作流和数据产品经理在每个流程中扮演的角色。

01数据仓库的重要性

1. 为什么要搭建数据仓库

这个问题翻译数据仓库能给我们带来什么价值。

想象一下，有一天，你要分析哪个地区哪种商品卖得最好。此时，请考虑是否需要通过分层获得批准，批准完成后，每个系统是否需要通过界面导出数据。因为估计过了几天，所以这个效率很低。(大卫亚设，Northern Exposure，)通过数据仓库，我们可以自己进行收集和分析。

数据仓库执行数据汇总、数据集成、数据处理和最终输出功能。

2. 数据产品为什么要懂数据仓库

数据仓库最终需要发挥能力，赋能需要业务结合，开发工程师往往对特定的业务不感兴趣，所以如果完全交给开发工程师开发的数据仓库，可能无法很好地支持业务。这需要数据产品经理参与数据仓库开发，要参与，必须了解数据仓库。

02构建数据仓库

数据仓库的基本体系结构如下图所示。

1. 数仓需求分析

数据产品经理在收到数据要求后，需要分析这个要求能否实现，如何实现，需要什么资源。避免为满足特定需求而开发，制定需求的整合计划，以便提供更丰富的数据以满足不时的需求。

梳理

2. 数据源梳理

数据源也是数据产品的工作，需要整理整个公司有哪些数据源，需要在数据源持有者的支持下了解数据源的格式和含义。

典型的数据源包括ERP系统、CRM系统、支付系统等内部系统数据、产品商店的行为数据和一些外部文档数据。

在

3. 数据同步汇总

数据持有人的支持下，将每个数据源同步到数据仓库的ODS层。这一层与源数据是同构的。也就是说，在ODS层中完整地存储数据源中的数据，以跟踪后续数据问题。该层的数据粒度最详细，该层的数据保留时间最长。

4. 数仓建模

数据仓库的设计模式为自上而下、自下而上，两种模式的方法体系分别为Inmon模式和Kimball模式。

1)Inmon模式

Inmon是自上而下的设计模式。也就是说，首先构建数据仓库，然后从数据仓库派生数据市场。

数据仓库中的数据源往往是异构的，其他数据源必须响应不同规则的数据清洗，在放置到数据仓库层之前通过ETL处理数据，必要时将数据输出到数据集市层。

Inmon以数据源为导向，数据源经常更改，因此实体建模比维建模更适合Inmon。

2)Kimball模式

Kimball是自下而上的设计模式。也就是说，首先构建数据集市，然后聚合到数据仓库，最后聚合到数据源。

Kimball方案中的数据源经常是几个现有表，数据源相对稳定，但表和表之间的关系尚未清理。Kimball方案获得数据后，根据目标对不同的表要求进行分区，然后通过ETL移动到数据仓库层。Kimball使用维建模。

比较两种模式可以发现，Inmon是企划型，Kimball是享乐型，Inmon提前制定计划，开发难度大，周期长，但一旦开发出来，维护起来就比较容易。

Kimball强调先满足要求，再制定计划，因此Kimball能够快速满足需求，适合敏捷开发，这带来了事后层面的困难更大的问题。(威廉莎士比亚，Northern Exposure(美国电视剧)，成功)在互联网行业，需求经常发生急剧变化，因此Inmon勉强努力达成的需求往往在实现后没有太大意义。(莎士比亚、温斯顿、网络名言)(William Shinston、Internet名言)相反，Kimball没有考虑数据仓库体系结构的复杂设计，看似不标准化，但实用地成为了互联网公司建模的主流模式。

5. ETL

ETL的工作将经历整个数据仓库构建过程。

ETL是数据提取、转换和加载的缩写。指从关系数据库中提取数据，根据规则转换和合并其他数据源中的数据，最后将其加载到数据仓库中。

在这个系列中

的操作中将会对元数据的数据格式，拼写错误，多余字段以及缺失值等进行处理，将分散、零乱、标准不统一的数据整合到一起，使数据达到允许加载到数据仓库的标准。

6. 数据仓库分层

存储在ODS层的数据显然是不能直接使用的，要经过层层处理；如果一步到位计算出各类指标将来业务变化的时候又要重头开始开发一遍，因此数据仓库分层是很有必要的。

数据仓库分层主要有以下几点好处：

• 支持复用：数据在每一层进行特定的处理，保留了大量的中间层数据，将来业务变更的时候可以从已有的中间层数据重新计算而不需要重头再来，大大地减少了重复开发；
• 便于管理使用：通过分层可以看到数据在整个仓库中的流转，方便掌握数据的生命周期，每一层负责特定的职责，便于使用者理解使用。

数据仓库分层通常分为以下三层：DWD、DWM、DWS。每一层的功能如下：

1） 数据明细层：DWD（Data Warehouse Detail）

DWD层直接与ODS层接触，ODS层的数据经过ETL后流向该层，一般保持和ODS层一样的数据粒度。

DWD层的主要工作有以下几点：

① 数据质量保证

ODS层的异常值、缺失值等等数据问题在这一层中解决，视具体情况进行数据矫正或者补充默认值或者直接丢弃。

② 维度退化

在本层同时也要开始为后续的数据使用做准备，之前维度建模的事实表和维度表后续使用的话需要进行大量的事实表维度表关联，显然效率是非常低下的；在DWD层将一些维度退化至事实表中以减少关联，即提前关联好各维度以便后续使用。

③ 数据聚集

ODS层的数据来源各种各样，有些数据属于同一个主题的但是来源不同，因此存在于不同表之中，需要将不同来源但是属于相同主题的数据汇总到同一张表之中。

2）数据中间层：DWM（Data WareHouse Middle）

DWM层的作用是进行数据聚合，即计算出一些公共指标，生成一系列中间表，方便后续使用方直接取数，本层的数据聚合保留较细的维度；这一层视具体业务而定，如果业务比较简单可以不需要这一层。

3）数据服务层：DWS（Data WareHouse Servce）

DWS层即我们熟知的数据集市或者大宽表。本层将DWM层的指标数据按主题进行汇总，生成一些字段较多的大宽表，即将各个指标都放在一张表中，方便使用方直接从表里面取数不需要进行任何计算。

由于将各种指标都合并到一张表中，DWS层的表不会太多，一张表包含了较多的业务内容，多指标的整合也注定了DWS层的数据表里面的维度不会太多，仅保留各指标共有的常用的一些维度。

DWM层到DWS层的流动示意图如下：

7. 数据共享层

拥有了DWD、DWM、DWS三层数据后，是不是就可以满足所有需求了呢？显然是不可能的，有以下需求三层架构就满足不了：

① 通常情况下，大部分的数据需求可以从DWS层直接取数，但是总会存在一些需求是DWS层支持不了的，这时候就需要将DWS层数据或者是从DWM、DWD数据进行计算以满足需求；

② 数据的使用我们讲究实时性，三层数据通常存储在一些比较廉价的存储介质上，如使用hive进行存储，这显然是不能满足我们的分析查询实时需求的，需要将有实时需求的数据加载到这一层中支持实时查询获取。

总而言之，数据共享层的作用就是支持三层架构满足不了的需求以及提高数据库性能，对外提供统一服务。

8. 数据实时需求

三层架构是无法支持实时计算需求的，因此需要有一个数据实时同步实时计算的架构，一般做法是数据源通过kafka实时同步至计算引擎，再由spark streaming或者flink等计算引擎计算出结果，储存在高效查询数据库中，如hbase。

03 数据产品能力与职责

1. 职责

通过以上流程，我们可以知道数据产品在构建数据仓库中的主要工作有：

① 数据需求对接与分析评估。

② 数据源梳理，争取到兄弟部门的配合，统一规划数据的来源去向。

③ 数据建模，根据现有业务对数据进行建模，用指标与维度描述出业务流程，这一块工作需要熟悉业务，所以非产品莫属，最终输出的事实表与维度表不一定是具体落地的物理表，只需将需要的事实与维度交给开发即可，具体怎么落实体表由开发决定。

④ 确定数据处理逻辑，ODS层的数据同步到DWD层需要进行ETL，对一些异常值或者缺失值需要怎么处理，需要数据产品经理与业务方进行协商再将处理逻辑同步给开发。

⑤ 数据库三层架构处理逻辑，哪些指标需要在DWM层处理哪些指标需要在DWS层处理以及每一层需要保留哪些维度，这些是开发不能确定的，需要数据产品根据业务方的使用需求进行统一规划，最终目标是提高数据仓库的易用性、丰富度以及扩展性。

⑥ 整个处理流程以及以后的数据使用，需要数据产品保证数据质量，数据质量除了准确性还需要保证实时性，不能几天前的数据今天才进入到数据仓库中。

2. 能力

从数据产品的职责来看，我们不难看出构建数据仓库对于产品经理最大的难点就是需要懂大数据技术以及数仓架构规划。

需要懂得构建数仓架构，知道数据怎么在数仓中流通，以及了解每个地方可能使用到的技术；常见的数据组件有Hive、Impala、Hbase、Hadoop、Spark、Flink、Redis、ES、Kafka、Sqoop等，做到了解每个组件是做什么的，有什么特点，最好是能简单使用。

本文由 @不语 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议