本文深入探讨了数据中台建设的具体路径和实施计划，详细阐述了从现状梳理到项目成果的全过程，引导读者了解如何高效构建企业级数据中台，希望对你在数据管理和战略规划方面有所启发。
本篇主要写建设数据中台的建设路径，具体的项目实施计划，以及实施过程中的注意点。
整个过程包含：
一、现状梳理，明确当前主要问题
二、勾勒自下而上的解决方案
三、制定项目计划
四、项目人员规划
五、项目成果
每一块业务都有对应的ETL开发团队为其提供数据支持，每个团队按自己的思路建设一套数据体系。
指标定义阶段：字段命名不规范、口径不统一、算法不一致。
指标规划阶段：数据部门疲于对业务支持、缺乏全局规划，产品化能力不足。
指标开发阶段：烟囱式数据开发，数据重复，不可信。
指标维护阶段：复杂关系引用导致指标下线牵扯面大。
从此可看出，公司业务线较为单一的情况下，不需要盲目上中台服务；数据中台往往建立在解决一定交叉性数据问题的基础上。
统一数据源：统一ODS数据基础层，并有一个团队负责和管控，其他团队无权复制数据基础层中的数据。
进行数据的统一规划：面向业务提供服务前，由数据团队负责从业务中抽象源于业务而又不同于业务的数据域，再主导统一建设数据中间层。
建设oneservice服务体系：将openAPI升级为缓解业务变化对数据模型冲击的方法论、数据产品，提供统一公用服务的同事，兼容面向个性化应用的服务。
梳理清楚现状之后，明确问题所在，明确解决方案，接下来需要做具体的实施。
在不影响业务发展的同时，在业务上推进数据价值化，降本提效为基础目标，创造业务价值。
OneData：公共层建设核心方法论，知道构建与管理数据。
OneService：7x24h无间断、无差异服务
OneEntity：连接孤岛数据，实现数据连接后萃取各类标签进行用户画像。
其中OneEntity体系包含如下：
1）OneEntity统一实体：全域关系打通设想ID-mapping
2）GProfile全域标签：四维标签体系探索，包含自然属性、社会属性、兴趣偏好、行业消费偏好…
3）GRelation全域关系：设想以全域Entity关系打通为基础的等关系图谱
4）GBehavior全域行为：以全域Entity关系聚拢形成全域行为中心
第一阶段：完成全局架构
1. 全面接管ODS数据基础层
全面接管ODS数据基础层，是一件十分吃力不讨好的事情，事项十分繁琐。但接管了ODS数据基础层，则是从数据源头上做了一层把关控制，防止重复建设数据体系的现象。
建设离线数ODS数据基础层和实时ODS数据基础层。
2. 升级OneData体系
将OneData体系升级到OneDataII，比较关键的是制定关于数据规范定义、数据模型设计、ETL开发规范3大环节的方法大纲。
3. 完成业务数据架构
从源头控制住所有数据，并且也确定了未来如何建设和管理数据的方法论，那接下来如何设计具有前瞻性、可持续性、可扩展性的直接面向业务层的服务呢？
需要对业务数据进行盘点、分析和认知。但是，如果对所有业务都同时进行盘点，不仅耗时长且难以深入，不具备可行性。
于是，可以按照“二八原则”，先对关键业务及其关键数据进行第一批盘点，并从业务视角和技术视角同时进行盘点。
例如，对淘系数据的4100多张报表中的2万多个指标盘点，经过多轮筛选，最终保留6600多个指标，即可保障当时的业务需求，其中1.4万个指标，一部分直接下线，一部分在后续数据公共层建成并切换下线。
第二阶段：抓关键业务的数据建设
在构建好ODS层之后，需要进一步丰富和完善DWD、DWS、ADS数据应用层。总共包含4个方向。
1. 离线数据公共层建设（ODS、DWD、DWS）
最开始建设淘系数据基础层治理项目，接盘ODS层之后，进行深度数据治理。，降低存储和计算资源的消耗，提升数据监控管理力度。
2. 离线数据应用层建设（ADS、报表）
一是面向应用服务的数据宽表的建设：基于数据公共层，向各个业务部门提供方便、快捷的数据服务。
二是给领导们提供关键数据：建设面向COO领导层的重点关注的经营指标。
三是建设各业务线、行业的数据。
3. 数据存储的专项治理
4. 实时数据公共层建设
第三阶段：全面铺开，逐步推进各个项目的数据建设
（下一篇文章中进行展开）
第四步：明确处理好关键矛盾
第五步：紧盯业务并超越业务满意度
一个月内完成第一阶段的全局架构工作，并快速启动第二阶段。第二阶段第一期切入关键应用，并在2个月内完成数据公共层初始化；第二阶段二期在迁移存量应用的同时支持新需求。
把服务双十一和双十二作为阶段性业务目标，让业务人员看到实际效果，技术人员感受到技术进步，数据公共层建设的推进就会由难到易，由慢到快。
第六步：业务和技术，两手都要抓，两手都要硬
数据技术是数据公共层建设的内核力量，包含数据模型、存储治理、数据质量、安全权限、平台运维、研发工具等。
第七步：以产品化思维推进项目
将数据公共层建设视为一个需要长期运营的产品。
第八步：关注预警和加强风险管理
提前进行风险规划，制定保障措施，如：
风险描述：数据规范定义和数据模型设计体系化，需要专业人才和工具保障。
保障措施：
1）制定规则及工作流，完善onedata体系数据规范定义，同时以工具化保障onedata体系工作流
2）数据产品经理和数据模型师培养，输出多名具有建模思想和建模能力、同时熟悉业务的人员
3）公共层可以稳定支持业务后，定期安排数据模型师和ETL研发人员深入业务以更新对源系统和业务的认知
若是需要最终完美的完成项目计划，缺乏其他业务部门或技术部门的配合是万万不可的，因为在实际的项目进程中，需要一个实体团队来负责数据公共层建设，以及协同若干个业务线的技术团队作为虚线加入项目组。
在最初建设时，数据团队只有50个人，而要实现如此庞大的计划，需要更多人员的支持。在建设前期由兼职的18罗汉进行现状梳理，并完成全局架构。
随着项目的兴起，领导团队对项目愈加看重，因而得到了更多人员资源上的支持。
降本：数据计算成本和存储成本降低，以及因重复建设而造成的人力成本的降低等。
2015年，批量数据计算总时长减少约50%，解约计算成本近亿元；批量数据下线，解约存储空间上百PB，节约存储成本上亿元。
提效：让各业务部门得到了统一、标准的数据服务，并且响应速度很快，提升了使用数据的效率。
业务上，数据价值化。
如上是阿里数据中台第一阶段、第二阶段的建设过程，接下来一篇会继续解析第三阶段：全面铺开的数据中台建设过程。
专栏作家
草帽小子，公众号：一个数据人的自留地，人人都是产品经理专栏作家。《大数据实践之路：数据中台+数据分析+产品应用》书籍作者，专注用户画像领域。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。