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

如何使用Scrum敏捷方法，快速搭建数 据集市？数据仓库自最早1988年被提出来，开展至今也有几十年了。从数仓1.0到数仓 4.0 ,从关系型数据库到大数据仓库。现如今，数据集市和数据湖以及湖仓一体 化是业界研发和开展的重要方向。数仓的建设有一套业界成熟的方法论，但数据集市如何建设各家企业众说纷纭。 作为数据产品经理,对数据仓库和数据集市等技术领域也并不会陌生，企业在搭 建数据集市过程中 往往会因为流程和工程管理的问题导致数据集市可用度不高 以及业务价值较低。那如何更高效搭建一套面向业务应用场景的数据集市？是否可以将产品敏捷方 法论快速高效地应用在数据集市的搭建上？1 .数据仓库和数据集市数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合， 用于支持管理层和业务层的经营分析和业务决策制定。数据仓库用于支持决策， 面向分析型数据处理，为了进行OLAP ,把分布在各个散落独立的数据库孤岛整 合在了一个数据结构里面，称之为数据仓库。有了数据仓库，为什么还需要数据集市呢？我们看看数据集市是为了解决什么问 题。数据集市可以理解为是一种小型数据仓库，它只包含单个主题，且关注范围 也非全局。数据集市可以分为两种： 一种是独立数据集市,这类数据集市有自己的源数据库和ETL架构;另一种是非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓 库。数据集市是一个结构概念，它是企业级数据仓库的一个子集，主要面向部门级业 务，并且只面向某个特定的主题。数据集市是数仓之上更聚焦的业务主题合集，更偏向于应对业务数据快速高效应 用的需求，一般用于商业智能系统中探索式和交互式数据分析应用。2 .产品敏捷方法论现在绝大局部互联网公司都在使用敏捷开发，最流行也最成熟的敏捷开发框架当 属Scrum。这里简单介绍下Scrum的三个重要角色和三个重要概念。Scrum中的人员分为3个重要角色：产品所有者(Product Owner), Scrum Master (敏捷教练)，开发团队(Dev Team )。三个重要概念:Sprint, Product Backlog , Sprint Backlogo1. Sprint : 一个冲刺或迭代周期，一般24周，是一个可以交付验收的产品需求功能集合;2. Product Backlog :产品需求集合，是产品规划中所有的需求点；3. Sprint Backlog :每个 Sprint 的功能需求点，来自于 Product Backlog。一般的Scrum开发流程如下：为什么说数据集市工程特别适合使用Scrum方法来迭代:1 .数据集市需求划清楚确。集市的业务域和主题域正好对应Scrum的Story和Sprint.2 .做出来的集市宽表是否有用，可以在某个业务域内先做一张，快速验证效果。3 .每个宽表的产出时间周期相对好评估，整体工程风险可控。针对面向主题域的数据集市，来看看我们的计划和安排： P0 ( Product Owner):数据产品经理。 SM ( Scrum Master):数据研发主管。 Team ( Dev Team ):数据架构师，数据研发工程师，数据测试工程师。 Story :每个Story可以根据业务域来划分，比方我们划分了资金域，用户域,模 型域，市场域，营销域，信审域，风控域，财务域，征信域。 Sprint :每个Sprint可以规划一到两张宽表，比方资金域我们规划了借款宽表，还 款宽表，其他类似。二,Scrum敏捷方法解决了哪些问题.效率问题以前开发一个主题域的数据集市，需要自顶向下进行建模设计、维度表设计、事 实表设计、架构设计、数据表开发、表验证、表测试，完整的瀑布流走下来，几 个月过去了，出来了一个大而全的数据集市，交付给分析师和业务。分析师大呼看不懂，查起来还是很慢，很多表还是需要我来JOIN ,业务也大呼 为什么取个数据这么久，为什么做个分析要一周？基于敏捷方法的数据集市建设，提高了整个生产流程的效率,针对具体的业务场 景和分析师的需求，小步快跑地先建设一张或几张宽表，先产出给分析师，再不 断调整数据字段，大大缩短了生产建设周期。1 . MVP验证问题 通过小步快跑模式,每个Sprint花费两周，建设12张宽表，解决一些核心的 分析取数场景，然后再交付验证有价值后进行迭代，增加新的字段，不断进行 MVP闭环验证。2 .业务价值问题直接基于业务分析场景和分析师使用场景来建设，基于怎么用来怎么设计宽表， 可以快速验证并产生直接的分析价值和业务价值。相比于传统的自顶向下的瀑布 建设流程，不追求大而全的数据集市和数据字段，紧密结合业务场景来进行设计。三,案例提供.工程介绍数据集市工程启动前，已有一套数据仓库，初期只做了两层分层，一层ODS ,一层 DWD。DWS层表很少几乎可以忽略不计。在业务分析过程中，我们发现很多的分析竟然还是依赖ODS层的表，局部能用到DWD层的表，说明数据仓库分层不明确, 违反了数仓和数据集市建设的跨层访问的原那么（一般来说分析师不用访问ODS为了进一步打破数据孤岛，提升数据使用链上人员的工作效率，进一步快速支持 分析和决策，我们打算建立一套基于现有的基础数仓上的数据集市层系列主题宽 表。1 .工程规划我们采用Scrum敏捷方法来规划每个Sprint的迭代节奏，主题宽表和应用场景规划如下列图：借款主题主题政策主题 信由主超 财务主卷 征信主题用户主题 次用声表市场主题 UBT 5MS Umt应用腐其分f，孟E菅甫，晒表日菖分析应用场后* RK-盯樊工尸方史也飞应月均基/网声直手，IUV.工程实施工程团队搭建,除了常规的SCRUM核心团队以外，我们还加入了需求来源团 队以及用户团队。需求来源团队数据产品经理收集需求和痛点的主要受访用户，用户团队是所有数 据使用人员。其他的P0 , SM和Dev , Test团队是敏捷开发的角色。具体工程团队配置分工如下：- FgVg数仓工程团队.效果评估Sprintl上线了借款主题域的两张宽表（借款还款和还款宽表）,我们并没有迅 速进入下一轮迭代，而是基于已上线的表收集使用价值以及评估降本提效的指 标，整理如下表：Case 1借款主题表CategoryindicatorsBefore! After数据表比照字段数量2468表效后6 +2| 1报，月报15-30min3-5min应用场导艮裳，月报没再切片，查词集时每月切片,支持历史数1B回避KPI.月报,日常统计分析月报指标跪完成1小时月报10分钟分析团队（分析，报表，取数）多人加工，敌寮孤岛， 取数慢统一加工，菇到至化.取配代7丁 m幽。1 .数仓和数据集市建设，市面上有成熟的方法论；2 .传统的建设流程存在过程冗长，人员庞杂，脱离业务场景，价值评估存在偏差等问题；3 .敏捷Scrum方法框架可以优化数据集市建设流程，做到降本提效,紧密贴合业务;4 . Scrum本质上是一套工程管理流程和敏捷迭代流程,要集合具体工程具体分析，吸取Scrum精华为我所用。