数据产品经理如何推进数据仓库的落地

如果放在十年前，数据仓库的搭建毫无疑问完完全全是开发工程师的活，随着业务的发展与细分，对产品经理提出了更高的要求，特别是数据产品经理岗位的出现，产品经理懂技术已经是大势所趋。

今天我们就来聊聊搭建数据仓库都有哪些工作流程，以及数据产品经理在各个流程中扮演的角色。

01 数据仓库的重要性

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

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

想象一下，有一天你需要分析一下某个地区哪种商品卖的最好，这时候是不是要通过层层审批，审批完成后开发在各个系统中通过接口导出数据，估计这时候已经过去了几天时间，所以这个效率是非常低下的；而有了数据仓库，我们就可以自助取数、分析。

数据仓库起到的作用就是：汇总数据、整合数据、加工数据并最终输出能力。

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能够快速满足需求，适合敏捷开发，同时导致的问题是后期维度难度较大；在互联网行业中需求往往是快速变化的，因此Inmon好不容易花大力气实现的需求往往实现后已经意义不大了；相反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等，做到了解每个组件是做什么的，有什么特点，最好是能简单使用。

本文作者 @不语

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！