构建数据中台的三要素：方法论、组织和技术

知道要转型，要建设数据中台，却不知咋做，咋办？

现在有很多讲“如何建设数据中台”文章，观点各不相同：

数据中台是数据建设方法论，按照数据中台设计方法和规范实施就可建成数据中台
数据中台背后是数据部门组织架构变更，把原先分散的组织架构形成一个统一中台部门，就建成数据中台
一些大数据公司说，他们可卖支撑数据中台建设的产品技术

盖房前，先得设计图纸，知道如何盖这房？然后还要有好用工具（如水泥搅拌机、钢筋切割机）帮你盖好这房。盖房子离不开一个靠谱施工队伍，这里面涉及很多角色（泥瓦工、木工、水电工等等），人须高效协作，才能盖出好房。

如把建数据中台比作盖房：

设计图纸就是数据中台建设方法论
工具是数据中台的支撑技术
施工队伍就是数据中台的组织架构

本文以全局视角从宏观了解如何建设企业级数据中台。

1 数据中台建设方法论

2016年阿里提出数据中台建设核心方法论：OneData、OneService。很多公司都进行实践，但你很难找定义去描述这些方法论。

1.1 OneData

所有数据只加工一次。

电商业务建设数据中台前，每个部门内部都有一些小数仓完成本部门数据分析需求。

有天，供应链团队接到一个数据需求，即计算“商品库存”指标，供应链的运营需根据每个商品的库存制订商品采购计划，部门的数据开发从业务系统同步数据，进行数据清洗、聚合、深度加工，最终，产出这个指标花1周时间。

恰逢大促，市场部门也需根据每个商品的库存，制订商品促销计划。该数据开发接到紧急需求（与供应链团队类似）从需求开发到上线，花费1周。同部门运营抱怨说，为啥数据需求开发这么慢，根本无法满足大促高频市场运营决策。对公司而言，等1周意味巨大损失，该促销商品没有促销，不该促销的却低价卖了。

如你是公司老板，肯定问，既然供应链团队已计算出来商品库存数据，为什么市场部门不直接用，还要从头再计算一遍？这看似傻行为，却处处出现在日常数据建设。

数据中台就是要在整个电商业务形成一个公共数据层，消灭这些跨部门小数仓，实现数据复用，所以强调数据只加工一次，不会因为不同的应用场景，不同的部门数据重复加工。

如何才能实现数据只加工一次？

如你构建了数据中台，但存在几万张表，又有几十个数据开发维护这些表，如何确保这些表管理效率？建议你选择划

主题域

可将这几万张表划到不同主题域，如电商业务中，商品、交易、流量、用户、售后、配送、供应链都可作为主题域。好的主题域划分，相对稳定，尽可能覆盖绝大多数表。

还要对表的

命名规范化统一

表的名称中最好能够携带表的主题域、业务过程、分层及分区信息。如仓储域的一张入库明细表的规则命名：

接着，构建全局的指标字典，确保所有表中相同指标的口径须一致（06文）。

为实现模型的复用，数据中台适合分层设计，常见分层：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS/DM 应用数据层/数据集市层。

**最后，数据中台的数据须尽可能覆盖所有业务过程，**数据中台每层的数据要尽可能完善，让数据使用者尽可能使用汇总后的数据。

OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而非成本。资产和成本差别在于：

资产可沉淀，可被复用
成本是消耗性质、临时、无法被复用

1.2 OneService

数据即服务，强调数据中台中的数据应通过API接口被访问。

为何数据要通过API被访问，而不通过API接口，直接提供数据表给用户？

如你是数据应用开发，当你要开发一个数据产品，先要把数据导到不同查询引擎：

数据量小的，MySQL
大的，可能HBase
多维分析的，可能Greenplum
实时性要求高的，要用Redis

总的来说，不同的查询引擎，应用开发需要定制不同的访问接口。

如你是数据开发：

当某任务无法按时产出，发生异常时，想了解这个表可能影响下游哪些应用或报表，但却发现单纯依赖表与表的血缘无法触及应用，根本无法知道最后这些表被哪些应用访问
当你想下线一张表，因不知道谁访问这张表，无法实施，最终造成“上线易，下线难”

而API接口：

对应用开发屏蔽了底层数据存储，使用统一标准的API接口查询数据，提高数据接入速度
对数据开发，提高数据应用的管理效率，建立表到应用的链路关系

2 如何实现数据服务化

2.1 屏蔽异构数据源

数据服务要能支撑类型丰富的查询引擎，满足不同场景下数据的查询需求，常见如MySQL、HBase、Greenplum、Redis、ES等。

2.2 数据网关

要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪，如有一些模型长时间没被访问，应下线。使用数据的每个应用都应通过accesskey、secretkey实现身份认证和接口权限管理。

访问日志可方便在访问出现问题时，加快排查速度。

2.3 逻辑模型

从用户视角出发，屏蔽底层的模型设计的实现，面向用户提供逻辑模型。什么是逻辑模型呢？熟悉数据库的同学应该知道，数据库中有一个视图的概念，视图本身并没有真实的数据，一个视图可以关联一张或者多张表，每次在查询的时候，动态地将不同表的查询结果聚合成视图的查询结果。逻辑模型可以类比视图，它可以帮助应用开发者屏蔽底层的数据物理实现，实现相同粒度的数据构造一个逻辑模型，简化了数据接入的复杂度。

**性能和稳定性：**由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。

OneService 体系目标是提高数据共享能力，让数据被用得好、爽。

3 数据中台支撑技术

这个图完整地描述了数据中台支撑技术体系，底层以Hadoop为代表的大数据计算、存储基础设施，提供大数据运行所须的计算、存储资源。都属基础设施范畴：

HDFS为代表的分布式文件系统
Yarn/Kubernates为代表的资源调度系统
Hive、Spark、Fink为代表的分布式计算引擎

若把数据中台比作数据工厂，它们就是工厂的水、电。

在Hadoop之上：

浅绿色，原有大数据平台范畴内的工具产品，覆盖从数据集成、数据开发、数据测试到任务运维的整套工具链产品。同时包括基础的监控运维系统、权限访问控制系统和项目用户的管理系统。由于多人协作，所以还有流程协作与通知中心
灰色，数据中台核心组成：数据治理模块。它对应的方法论就是OneData 体系。以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的5个产品，分别对应的就是数据发现、模型、质量、成本和指标的治理
深绿色，数据服务，它是数据中台的门户，对外提供了统一的数据服务，对应的方法论就是OneService。数据服务向下提供了应用和表的访问关系，使数据血缘可以延申到数据应用，向上支撑了各种数据应用和服务，所有的系统通过统一的API接口获取数据。

在数据服务之上，是面向不同场景的数据产品和应用，包括面向非技术人员的自助取数系统；面向数据开发、分析师的自助分析系统；面向敏捷数据分析场景的BI产品；活动直播场景下的大屏系统；以及用户画像相关的标签工厂。

这套产品技术支撑体系，覆盖了数据中台建设的整个过程，配合规范化实施，你就可以搭建出一个数据中台，关于具体的细节我会在实现篇中逐一分析讲解，这里你只需要知道这个框架就可以了。

4 组织架构

在网易电商数据中台建设之前，各个部门都会存在一些小的数仓，那么你有没有想过，为什么会存在这些分散的小数仓？ 归根结底是因为建设这些数仓的人分散在各个业务部门。所以，如果你要建设数据中台，单纯有方法论和支撑技术还不够，还必须要有一个独立于业务部门的中台团队。

数据中台提供的是一个跨业务部门共享的公共数据能力，所以，承担数据中台建设职责的部门一定是一个独立于业务线的部门。这个部门的负责人应该直接向公司的CTO汇报工作，当然这个也要取决于数据中台建设的层次，例如在网易内，有云音乐、严选等多个产品线，数据中台的建设层次是在产品级别的，也就是说，云音乐有一个数据中台，严选有一个数据中台，所以严选的数据中台应该向严选的CTO汇报。

而独立部门的最大风险是与业务脱节，所以我们对数据中台的组织定位是：**懂业务，能够深入业务，扎根业务。**数据中台要管理所有的指标，而每个业务线之间的指标既有差异，也有交叉，要理解指标的口径定义，就必须要了解业务的过程。同时，当我们要制定一些新的指标时，必须要了解各个业务线新的业务目标，指标的本质还是为业务目标服务的。

啥样的组织架构适合数据中台建设？

数据产品部门：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护（有的部门是由分析师管理）。
数据平台部门：负责研发支撑数据中台构建的产品，例如指标系统、元数据中心、数据地图等。
数据开发团队：负责维护数据中台的公共数据层，满足数据产品制定的数据需求。
应用开发团队：负责开发数据应用产品，比如报表系统、电商中的供应链系统、高层看板、经营分析。

而且，中台组织的绩效目标一定是要与业务落地价值绑定的，比如在电商中，我们提供了供应链决策系统，有智能补货的功能，会根据商品的库存，各个地区的历史销售情况，生产加工周期，自动生成补货决策，由人工审核以后，直接推送给采购系统。那我们评估价值时，我们会拿由系统自动生成的采购计划占整体采购计划的比例来衡量数据的应用价值。

最后，数据中台的组织架构改革涉及原有各部门利益，所以这个是数据中台构建最难又不得不做的地方，必须要取得高层领导的支持和重视。

5 总结

数据中台建设的三板斧：方法论、支撑技术和组织架构。

适合数据中台的组织架构是建设数据中台的第一步，数据中台组织一定是独立的部门，同时要避免与业务脱节，深入业务，要与业务目标绑定。
数据中台支撑技术大规模落地，需要有成熟的系统工具作为支撑，同时要注意这些系统工具之间的联动和打通。
数据中台的方法论可以借鉴，但是不能完全照搬，每个公司的数据应用水平和当前遇到的问题都不相同，可以针对这些问题，分阶段制定数据中台的建设计划，选择性的应用一些技术，例如当前最主要的问题是数据质量问题，那就应该优先落地数据质量中心，提升质量。