如何使用Scrum敏捷方法，快速搭建数据集市？

数据仓库自最早1988年被提出来，发展至今也有几十年了。从数仓1.0到数仓4.0，从关系型数据库到大数据仓库。现如今，数据集市和数据湖以及湖仓一体化是业界研发和发展的重要方向。

数仓的建设有一套业界成熟的方法论，但数据集市如何建设各家企业众说纷纭。作为数据产品经理，对数据仓库和数据集市等技术领域也并不会陌生，企业在搭建数据集市过程中，往往会因为流程和项目管理的问题导致数据集市可用度不高以及业务价值较低。

那如何更高效搭建一套面向业务应用场景的数据集市？ 是否可以将产品敏捷方法论快速高效地应用在数据集市的搭建上？

一、基本概念

1. 数据仓库和数据集市

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理层和业务层的经营分析和业务决策制定。数据仓库用于支持决策，面向分析型数据处理，为了进行OLAP，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。

有了数据仓库，为什么还需要数据集市呢？我们看看数据集市是为了解决什么问题。

数据集市可以理解为是一种“小型数据仓库”，它只包含单个主题，且关注范围也非全局。数据集市可以分为两种：

• 一种是独立数据集市，这类数据集市有自己的源数据库和ETL架构；
• 另一种是非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库。

数据集市是一个结构概念，它是企业级数据仓库的一个子集，主要面向部门级业务，并且只面向某个特定的主题。

数据集市是数仓之上更聚焦的业务主题合集，更偏向于应对业务数据快速高效应用的需求，一般用于商业智能系统中探索式和交互式数据分析应用。

2. 产品敏捷方法论

现在绝大部分互联网公司都在使用敏捷开发，最流行也最成熟的敏捷开发框架当属Scrum。这里简单介绍下Scrum的三个重要角色和三个重要概念。

Scrum中的人员分为3个重要角色：产品所有者（Product Owner）, Scrum Master（敏捷教练），开发团队（Dev Team）。

三个重要概念：Sprint，Product Backlog，Sprint Backlog。

1. Sprint：一个冲刺或迭代周期，一般2~4周，是一个可以交付验收的产品需求功能集合；
2. Product Backlog：产品需求集合，是产品规划中所有的需求点；
3. Sprint Backlog：每个Sprint的功能需求点，来自于Product Backlog。

一般的Scrum开发流程如下：

为什么说数据集市项目特别适合使用Scrum方法来迭代：

1. 数据集市需求划分明确。集市的业务域和主题域正好对应Scrum的Story和Sprint。
2. 做出来的集市宽表是否有用，可以在某个业务域内先做一张，快速验证效果。
3. 每个宽表的产出时间周期相对好评估，整体项目风险可控。

针对面向主题域的数据集市，来看看我们的计划和安排：

• PO（Product Owner）：数据产品经理。
• SM（Scrum Master）：数据研发主管。
• Team（Dev Team）：数据架构师，数据研发工程师，数据测试工程师。
• Story：每个Story可以根据业务域来划分，比如我们划分了资金域，用户域，模型域，市场域，营销域，信审域，风控域，财务域，征信域。
• Sprint：每个Sprint可以规划一到两张宽表，比如资金域我们规划了借款宽表，还款宽表，其他类似。

二、Scrum敏捷方法解决了哪些问题

1. 效率问题

以前开发一个主题域的数据集市，需要自顶向下进行建模设计、维度表设计、事实表设计、架构设计、数据表开发、表验证、表测试，完整的瀑布流走下来，几个月过去了，出来了一个大而全的数据集市，交付给分析师和业务。

分析师大呼看不懂，查起来还是很慢，很多表还是需要我来JOIN，业务也大呼为什么取个数据这么久，为什么做个分析要一周？

基于敏捷方法的数据集市建设，提高了整个生产流程的效率，针对具体的业务场景和分析师的需求，小步快跑地先建设一张或几张宽表，先产出给分析师，再不断调整数据字段，大大缩短了生产建设周期。

2. MVP验证问题

通过小步快跑模式，每个Sprint花费两周，建设1~2张宽表，解决一些核心的分析取数场景，然后再交付验证有价值后进行迭代，增加新的字段，不断进行MVP闭环验证。

3. 业务价值问题

直接基于业务分析场景和分析师使用场景来建设，基于怎么用来怎么设计宽表，可以快速验证并产生直接的分析价值和业务价值。相比于传统的自顶向下的瀑布建设流程，不追求大而全的数据集市和数据字段，紧密结合业务场景来进行设计。

三、案例分享

1. 项目介绍

数据集市项目启动前，已有一套数据仓库，初期只做了两层分层，一层ODS，一层DWD。

DWS层表很少几乎可以忽略不计。在业务分析过程中，我们发现很多的分析竟然还是依赖ODS层的表，部分能用到DWD层的表，说明数据仓库分层不明确，违反了数仓和数据集市建设的跨层访问的原则（一般来说分析师不用访问ODS层表）。

为了进一步打破数据孤岛，提升数据使用链上人员的工作效率，进一步快速支持分析和决策，我们打算建立一套基于现有的基础数仓上的数据集市层系列主题宽表。

2. 项目规划

我们采用Scrum敏捷方法来规划每个Sprint的迭代节奏，主题宽表和应用场景规划如下图：

3. 项目实施

项目团队搭建，除了常规的SCRUM核心团队以外，我们还加入了 需求来源团队以及用户团队。

需求来源团队数据产品经理收集需求和痛点的主要受访用户，用户团队是所有数据使用人员。其他的PO，SM和Dev，Test团队是敏捷开发的角色。具体项目团队配置分工如下：

4. 效果评估

Sprint1上线了借款主题域的两张宽表（借款还款和还款宽表），我们并没有迅速进入下一轮迭代，而是基于已上线的表收集使用价值以及评估降本提效的指标，整理如下表：

四、总结

1. 数仓和数据集市建设，市面上有成熟的方法论；
2. 传统的建设流程存在过程冗长，人员庞杂，脱离业务场景，价值评估存在偏差等问题；
3. 敏捷Scrum方法框架可以优化数据集市建设流程，做到降本提效，紧密贴合业务；
4. Scrum本质上是一套项目管理流程和敏捷迭代流程，要集合具体项目具体分析，吸取Scrum精华为我所用。

本文作者 @乘风随行 。

版权声明

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