数据中台是什么？数据中台如何建设？

这篇文章主要从产品经理和项目管理角度，和大家分享下数据中台在实际生产中如何运作。

1 数据中台应该有什么

1.1 数据应用

互联网大厂的数据中台一般会有如下几个数据应用：推荐引擎、埋点系统、画像系统、AB测试系统、业务大屏&报表系统等等。

各行各业的企业规划有所不同，对于各数据中台应用的需求也有轻重缓急，不过业务大屏&报表分析系统常常是各企业启动数据中台的第一站。

业务大屏&报表系统相信大家接触较多，可以认为是监测核心业务状态的可视化工具，主要提供3个功能：

监控：集成数据信息，监控商业进程。领导们监控大趋势，业务部门监控各细化指标，发布业务预警。

分析：各业务团队可通过拖拉拽的方式进行可视化分析，进行业务复盘，深挖数据细节，分析原因，直击问题点。

协同：实时同步各部门的协作目标，促进交流与协作，共同解决业务问题。

其他数据应用咱们不再展开了。在这些数据应用之上，有的直接服务管理层、用户和商户，即to C领域。

同时可以赋能各类业务中台，诸如投放中台、运营中台、客服中台、内容中台等，通过业务中台创造价值。

1.2 数据平台

如果说上述的数据应用是数据中台给业务的赋能，那么数据开发平台、数据资产管理平台、元数据管理平台、数据安全合规平台等等，则是数据仓库基础架构给数据中台的赋能。

这些平台不直接产生价值，但是如果没有在数据中台启动初期同步建设，在业务规模扩大后，必然带来不可忽视的安全隐患，同时也会大大拉低研发效能。

如果受限于资源，无法及时启动上述的数据平台，数据产品经理也可以尽早制定相应规范，并定期回顾，从而减少后期的修复成本。

说一句丑话，由于后期成本与前期工作量不在一处，两者之间有一定的矛盾之处，此时如果有一个懂技术、懂数据、懂管理的leader或者强力的项目管理同事来统筹，往往可以事半功倍。

1.3 组织架构

组织架构与数据应用有时是一一对应的，有时不是，大公司职能细化，团队数量更多，常常需要多个团队支持一个数据需求；

小一些的中台可能只有数据分析、平台开发、数据仓库、用户画像这几个团队；再小一些的数据中台朋友们往往身兼数职了。

1.4 技术架构

各类大数据组件必不可少。但是一定要注意，适合业务的才是最好的，切不可贪多，构成的组件越多，运维起来越艰苦，所需的人力成本必然直线上升。

当然也不必过分求快。公司数据看板结合业务可以提供秒级更新，不一定非要像大电商平台那样做到毫秒级别的数据。

比方说实时计算能力对于一些企业来说并不是必须的，往往只有一个短数据支线用于业务大屏，这往往没必要做一套flink，通过spark也可以实现秒级更新。

2 数据中台日常在做什么

2.1 数据中台主要内容

本质上在做两类事情，分别是业务数据支持和中台建设统筹。

1）业务数据支持

业务的数据需求紧急且重要。这个场景大家可能都不陌生，业务同事火急火燎来到我们工位，介绍了需求的紧急程度和重要程度，然后留下一句“大领导希望X天看到XXX数据的分析结果，辛苦了”。

2）中台建设统筹

数据中台建设初期，往往由于BI与各业务部门的目标协同不足，被迫投入过多人力支持业务数据需求。

而事实上两者应该是相辅相成的，平台能力建设是为了业务部门可以更加自助地使用数据资产，业务数据需求支持可以为中台积累业务认知，更好地洞察业务需求。

关于两者的关系，有一个例子可以很好地进行说明。

以我们熟悉的报表为例

在没有中台的时候，或者中台能力尚不强大时，数据开发/数据分析的同事需要与业务部门对接，必然经过多回合的“确认口径-出报表验证-修改口径-定期批跑-导出-分析”，沟通成本高，节奏拖沓，往往拿到准确的报表已经是几天之后了，而且后续的每一次调整都需要与数据开发同事沟通确认。

2.2 数据中台建设示例

平台能力建设可以归纳出常见的业务分析场景，将报表需求抽象化、模块化，赋能业务部门在平台上自行选择统计口径、渠道范围、时间区间、统计频率、汇总粒度等条件，分钟级自动生成报表。这样的中台建设显著增加了代码和服务的复用，降低了沟通成本，提升了各部门的工作效率。

平台能力建设是一个宽泛的概念，应该视业务的需求而定，准确来说将出现次数越多、消耗中台人力越多的场景，约需要尽早建设为数据中台的能力。包括报表、合规、AB测试、埋点、推荐等等。

我们再以报表和合规监管为例：

1）报表能力建设

各业务部门需要定期、不定期统计总结日活用户、客单价及各指标变化等数据指标，与画像提包情况相似。在平台建设完成之后，使用者可以自助选择口径，定期回顾发送邮件，基于图表模块生成可视化图表，或进行异常情况监控。

2）数据安全合规能力建设

各监管机构对于用户隐私数据日益重视，需要进行各类加密处理，维护与监管机构的高效沟通。

打个比方，监管机构首次提出整改要求或者要求检查部分数据时，各公司可能需要一两周的时间来“处理加工”数据（处理加工在这里是中性词，指从海量杂乱的数据中找出监管部门所需要的，并进行分类、归纳）。后续监管机构再次拜访时，对接部门可以更早拿到数据进行查验，可以更加从容地应对，比友商更及时提交相关资料。

归纳起来，数据中台日常工作便是通过需求实现+能力沉淀，最终打造一个4S的数据中台。

3 数据中台流程与运营实践

这一部分主要介绍数据中台项目管理的重点工作内容。对于项目管理缺位的团队，则需要或者leader或者产品经理来承担。数据中台是开发比重较大的部门，但对于少而精的项目管理能起到提效减负作用是不容忽视的。

笔者所在BAT中某业务线的数据中台经过多年优化后，大致固化了较为可靠高效的流程，抽象出来供大家参考。

3.1 需求预沟通

业务部门向数据中台中熟识的同事进行预先沟通，与业务部门接触的可能是数据中台的各个岗位的同事，因此也需要培养数据开发、数据后台工程同事预沟通的习惯。预沟通的首要目标是让业务部门的需求进入既定流程，通过数据中台提供的指引完成提单。

预沟通的次要目标是在成本不高的情况下，帮助业务部门明确需求，如果需求跨越团队较多，预沟通时难以明确，可在需求评审时讨论。

实践中我们会遇到业务部门的需求比较模糊的情况，可能是刚接手的同事只有业务领导的一两句话指示尚不清楚具体情况；可能是发现了一个问题想优化，但没有明确的目标，不清楚要改成什么样；可能是业务部门想要一份数据，但不清楚有没有这样的数据，或不清楚数据存放在哪里。

3.2 提需求单

为了更好地记录、回溯，必须要求业务部门进行提单。需求单里应该包含的内容，视不同的公司的数据中台所承接的职能不同而有所不同，较核心的内容包括需求背景、所需的能力支持、相关数据的口径定义、期望完成时间、验收标准，可能业务部门提单时无法全部写清楚，需要与数据中台各团队在评审会上确认，可以后续对需求单进行补充调整。

Q：如果业务同事太忙了，不愿意写需求单，只写一句话需求单，怎么办？
A：需求单必须由业务部门发起，业务部门最了解需求背景、验收标准，业务部门所不太了解的部分（比如数据源、口径、时效等）可以由中台同事进行补充。

提单的原则在于“谁需要，谁提单”，如果需求方不愿意花个把小时把需求梳理清楚并记录下来，如何要求相应方花上几天来实现呢。

而且事实上大家会发现，提单时偷懒省的时间，会在后面的需求讨论、数据探查、数据校验、交付调整的时候加倍还回去。

3.3 需求分类

通常业务部门提单时，参照中台所提供的指引，大致知道这个需求归属于哪个团队，或者这是一个跨团队的复合型需求。对于归属明晰的需求，由团队直接对接、明确需求owner，对于复合型需求，可以由项目经理组织定期评审，拉上各团队负责人、业务部门产品&开发对接人，讨论后明确数据中台侧的需求owner，后续由此owner主导提供解决方案。

这个部分我们后面再讲一个例子。

3.4 可行性分析与解决方案

这个环节主要是由需求owner主导完成，需要明确需求的参与人和职责，比如数据产品的探查工作，数据开发的编译与调优等，同时给出排期计划，与各方同步。

3.5 数据合规安全判断与审批

需求owner需要判断所提供的数据是否需要数据合规审批，如果需要，则发起数据合规审批。注意此处的数据合规审批与业务部门发起的业务合规审批的差异，数据合规审批需要判断其中是否涉及国家安全、隐私数据等监管禁区.

同时也需要把控数据的加密&解密、跨法律主体使用、是否明文处理、传输链路中的风险等细节。

本着谨慎性的原则，数据合规审批一般由中台的同事发起，这是因为中台是这批数据的提供方，也是可能的责任方，与此同时也更熟悉数据来源、数据分布、数据主体归属，更了解其中蕴含的风险。

当然了，部分企业并不需要进行数据合规安全审批，这个环节主要适用于

• 直面反垄断监管的大体量集团企业
• 掌握用户较多隐私数据的机构
• 通信基础设施型企业
• 承担反赌反诈反洗钱责任的机构
• ······

（有些企业占了其中好几条的，可得多关注了）

3.6 需求交付验收

在开发过程中遇到问题，及时给业务部门反馈，避免交付时才暴露问题，被迫推倒重来。在交付之后，需求owner和项目经理的一个重要工作是推动需求方尽快验收。

怎么算“尽快”验收呢？

我们在需求提单的环节会要求需求方明确“高-中-低”的优先级，对于高优先级的需求，要求需求方1天内启动验收，2天内完成验收或提出修改；

对于低优先级的需求，时间要求可适当放开，但也不宜超过一周。

想必大家都遇到过，拼死拼活交付需求之后，需求方过一个月才开始验收/联调，而此时数据中台同事已经忘的差不多了，此时再回过头调整代码，这其中需要多付出的时间，于业务，于中台，都是巨大的浪费。

3.7 回顾并沉淀能力

这个环节其实与上述几个流程没有强烈的前后因果关系。核心在于定期回顾业务需求，选择其中高频、高耗时的进行抽象沉淀。

当然最优解是在业务之前，预测未来一段时间的业务重心，提前建设相关能力（这可太难了）。

3.8 一个小case

有朋友可能会觉得这个流程有些抽象，各公司都会有类似的流程设计，需要BAT大厂优化多年么？

我们拿上述第3条-需求分类的优化作为例子。很久之前，团队在需求分类的时候，只要遇到跨团队需求，都会由项目管理同事牵头发起需求评审。当需求逐渐增加，流程效率遇到瓶颈，遭遇了一次需求大积压和业务投诉。

因而，我们将各需求类型固化出一套分类指引，业务方只需要回答3-4个 “Yes or No” 的简单问题，便可自动判断出需求owner，或判断为复合型需求移交PM。

判断需求owner的逻辑大致有2类：

• 由开发主力团队leader担任
• 由最终交付团队leader担任

我们需要参考历史情况和团队意愿，在遇到特殊情况时，也可重新评审后进行移交。

这一个看起来不大的优化，在实施1个月后，积压需求减少了70%，周交付需求数量提升30%，单个需求交付时间平均减少了约25%。

4 总结

数据中台的运营与迭代的过程也是各模块相互推进、相互制约从而螺旋式上升的过程，从来不是一蹴而就的，是一个长期的过程。

数据中台的发展离不开领导层和leader们清晰的认知，以及平台开发、数据开发、产品经理、项目管理各个角色的密切配合。

文章来于公众号：大数据兵工厂