本篇主要写建设数据中台的建设路径,具体的项目实施计划,以及实施过程中的注意点。
整个过程包含:
二、勾勒自下而上的解决方案
三、制定项目计划
四、项目人员规划
五、项目成果
每一块业务都有对应的ETL开发团队为其提供数据支持,每个团队按自己的思路建设一套数据体系。
指标定义阶段:字段命名不规范、口径不统一、算法不一致。
指标规划阶段:数据部门疲于对业务支持、缺乏全局规划,产品化能力不足。
指标维护阶段:复杂关系引用导致指标下线牵扯面大。
从此可看出,公司业务线较为单一的情况下,不需要盲目上中台服务;数据中台往往建立在解决一定交叉性数据问题的基础上。
二、勾勒自下而上的解决方案
统一数据源:统一ODS数据基础层,并有一个团队负责和管控,其他团队无权复制数据基础层中的数据。
进行数据的统一规划:面向业务提供服务前,由数据团队负责从业务中抽象源于业务而又不同于业务的数据域,再主导统一建设数据中间层。
建设oneseRvice服务体系:将openaPI升级为缓解业务变化对数据模型冲击的方法论、数据产品,提供统一公用服务的同事,兼容面向个性化应用的服务。
三、继而制定项目计划
梳理清楚现状之后,明确问题所在,明确解决方案,接下来需要做具体的实施。
在不影响业务发展的同时,在业务上推进数据价值化,降本提效为基础目标,创造业务价值。
第二步:确定指导性的方法论
OneEntity:连接孤岛数据,实现数据连接后萃取各类标签进行用户画像。
1)OneEntity统一实体:全域关系打通设想ID-mapping
2)GPRofile全域标签:四维标签体系探索,包含自然属性、社会属性、兴趣偏好、行业消费偏好…
3)GRelation全域关系:设想以全域Entity关系打通为基础的等关系图谱
4)GBehavioR全域行为:以全域Entity关系聚拢形成全域行为中心
第三步:确定三步走的项目执行计划
第一阶段:完成全局架构
全面接管ODS数据基础层,是一件十分吃力不讨好的事情,事项十分繁琐。但接管了ODS数据基础层,则是从数据源头上做了一层把关控制,防止重复建设数据体系的现象。
将OneData体系升级到OneDatAII,比较关键的是制定关于数据规范定义、数据模型设计、ETL开发规范3大环节的方法大纲。
3. 完成业务数据架构
从源头控制住所有数据,并且也确定了未来如何建设和管理数据的方法论,那接下来如何设计具有前瞻性、可持续性、可扩展性的直接面向业务层的服务呢?
需要对业务数据进行盘点、分析和认知。但是,如果对所有业务都同时进行盘点,不仅耗时长且难以深入,不具备可行性。
于是,可以按照“二八原则”,先对关键业务及其关键数据进行第一批盘点,并从业务视角和技术视角同时进行盘点。
例如,对淘系数据的4100多张报表中的2万多个指标盘点,经过多轮筛选,最终保留6600多个指标,即可保障当时的业务需求,其中1.4万个指标,一部分直接下线,一部分在后续数据公共层建成并切换下线。
第二阶段:抓关键业务的数据建设
在构建好ODS层之后,需要进一步丰富和完善DWD、DWS、aDS数据应用层。总共包含4个方向。
1. 离线数据公共层建设(ODS、DWD、DWS)
最开始建设淘系数据基础层治理项目,接盘ODS层之后,进行深度数据治理。,降低存储和计算资源的消耗,提升数据监控管理力度。
一是面向应用服务的数据宽表的建设:基于数据公共层,向各个业务部门提供方便、快捷的数据服务。
二是给领导们提供关键数据:建设面向cOO领导层的重点关注的经营指标。
三是建设各业务线、行业的数据。
4. 实时数据公共层建设
第三阶段:全面铺开,逐步推进各个项目的数据建设