赵壮实：数据中台的底层逻辑

       导读：2015年以来，“数据中台”已经成为了一个爆款词汇，也经历了2020年阿里“拆中台”的问题，今天主要从科普和企业实践两个角度来介绍一下数据中台。本次分享题目为《数据中台底层逻辑》，主要介绍：

       什么是数据中台

       为什么需要数据中台

       数据中台的原则

       数据中台实践

       01什么是数据中台

       2015年，马云老师去芬兰一家游戏公司supercell考察，这家公司人数不到200人，但是却成为2015年全球营收最高的游戏公司。它曾推出《部落冲突》（Clash of Clans）、《海岛英雄》（Bomb Beach）、《卡通农场》（Hay Day）和《皇室战争》（Clash Royale）。为什么人数不到200的supercell，在2015年可以成为全球营收最高的游戏公司呢？通过组织能力的发现，它的组织架构和一般的组织架构不同，传统的组织架构是从CEO到市场、经营、运营、产品、技术等部门的形式，但是supercell呈现的是一个从中台发散再到各个部门的形式。国内也有类似的模式，如字节后来建立了自己的数据中台、增长中台、营销中台等等，以中台式来支持一个APP工厂进行快速地迭代、试验和审核。

       阿里数据生态的变化经历了13年之久。最早可以追溯至2007年，阿里的“遵义会议”后，确定了阿里是一家数据公司。2014年，阿里确定数据上云，此时的阿里，无论是从思想储备还是技术储备上，都已经达到了数据中台储备的要求。2015年，马老师去芬兰supercell公司考察，年底便成立了阿里中台事业群。到了2020年，出现了一种“中台是毒药还是救命稻草“的争论观点，逍遥子在阿里内网说中台没有达到预期，希望“中台变薄”。大家可能会觉得中台被妖魔化了，也不太被需要了，但我更想说的是，我们当初建立中台的时候，其实是根据企业自身的目标和原则来建设的，自然不会因为中台的污名化就将其舍弃。

       那什么是数据中台呢？从阿里的视角来看，开始的数据开发是烟囱式的，比如淘宝、天猫、1688，但这种开发不能支撑整体的数据运维，后来就变成了由共享数据，从商品、品类、价格、用户、交易、评价等以中台为所有业务线进行数据支撑的方式。

       阿里的数据中台的定义是：方法论 + 组织 + 工具

       • 方法论：OneID+OneModel+OneService

       • 组织：从 IT 支撑到业务赋能的数据、技术、产品相匹配的人才结构，包含数据产品经理、数据研发、数据科学家等多角色

       • 工具：采集、构建、管理、服务等

       广义上，数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。

       我从网上找了一些阿里的中台图，事实上中台并没有一个准确、统一的概念。但是从图中可以发现，OneData和OneService是一直存在的。从我的经验和对中台的理解来说，OneData覆盖的范围包括数据源的统一整理、数据开发和生产、数据模型创建和指标口径的统一。OnePlatForm是以产品形态中台式的建立提供工具给业务方使用。OneSevice更多的是提供API接口，将血缘、引擎、API综合式的从中台提供能力给到业务方的各个平台，包括数据平台、交易类平台等。

       02为什么需要数据中台

       为什么需要数据中台？数据中台主要是解决以下5个问题：

       指标口径不一致。阿里在建设中台之前有三万多个指标，这些指标存在命名相同定义不同的问题。例如DAU（Day Active User），Day的定义可以是0-24时的自然日，也可以是类似2点-2点这种ETL开始数据调度的日期，像一些海外新项目，不同的地区属于不同的时区，也会有不同的时间。所以DAU对于不同的岗位视角或者业务视角，Day的定义也有所不同。又如Active的定义，可能以下载一个app为口径，可能是注册下载，可能是注册手机号之后的行为，可能是打开app等等为口径，这种就会造成口径不一致的现象。

       数据重复建设。数据重复建设主要包括两种情况，一种是数据中台类型和业务型小中台会出现很多数据重复性建设的问题，另外一种是业务线上不同岗位的人，比如数据PM和商分会进行重复性的数据建设，从商分的工作习惯来说，他们会进行很多多口径实验，对数据产出、更新迭代以及维度指标的要求比较丰富，而数据产品不能立刻满足他们的需求，所以便导致了这种常见的重复性建设问题。

       取数效率低。一般大厂都有几万张的表，不同的表从ODS层到APP层各分布在不同的层级，这样便造成了信息的不透明不对等，从而导致取数效率低。比如想要取一张ODS层的表，然后再到一张APP层的表，二者的容纳项可能有非常大的差异，所以就造成了取数效率低下的问题。

       数据质量差。由于多烟囱、多岗位、多部门式情况的存在，导致数据无法全链路勾连，不能成为全链路中的一个血缘，因此必然会产生数据质量差的问题。

       建设成本高。上述问题导致了数据在计算、存储上建设成本高的问题，可能不同部门的人都需要从头到尾了解研发流程的每一个细节，其中的坑每个人都会踩一遍，浪费研发人员的时间精力成本。而且在没有规范管理标准的情况下，也会存在数据表层次力度不清晰的问题，为数据存储带来巨大的成本负担。

       基于此，数据中台是一个比较好解决这些问题的策略。

       下面是一个数据中台解决问题的例子，对于大型公司来说，一般形成了数据中台、业务数据支持、业务前台三者之间的勾连关系。

       数据中台可以解决一些问题，包括数据来源一致问题，例如日志型数据、DB型数据、文件上传型数据和SDK数据；建设口径一致问题，例如可以通过一些建模型的产品工具、指标元数据管理产品来保证建设口径一致；同时可以通过技术引擎和存储管理的迭代来降低存储成本。

       中间层是业务数据支持，它可以保证业务口径的一致，例如保证原生指标、派生指标、衍生指标达到业务口径的一致性以及流程的顺利运转；计算逻辑一致，例如渠道指标和维度达到计算逻辑的一致；提升取数效率，通过SQL、看板还是分析效率型工具来实现取数效率的提升。

       业务前台虽然不直接参与数据建设，但是可以从数据指标搭建、提升分析效率两方面提高数据的使用情况，同时可以从B端或者C端视角对整体的数据链路形成反馈。

       03数据中台的原则

       不是所有的企业都适合建设中台，如果企业具有下述三点特征，可以尝试建设数据中台：

       企业有较多数据应用的场景（3+）。3+以上会出现重复性数据建设的问题。例如一家新零售或者电商公司，它有许多不同的部门，可能包括2C、2B甚至2G，通过建设数据中台，可以实现用户表、区域表、用户画像标签的打通，比较适合数据状态性的建设。

       企业有效率、质量和成本的压力。数据中台是解决数据计算、引擎、存储压力的有效方式，如果公司有效率、质量成本压力，是适合建设数据中台的。

       企业面临经营困难/高速增长/数字化转型，需要通过数据实现精益运营。传统的OA或CSM系统不能实现数据打通，而且数据量比较有限，数据中台可以通过Hadoop、MapReduce来运营更大量级的数据。

       数据中台的组织原则：

       原则一：五指成拳，核心资源给到核心项目。数据中台不太适合业务上的赛马逻辑，因为它本质上是一个不产生效益的职能型部门。业务上一般是RD、算法、工具、数据十八般武艺都会一点，而中台同学，尤其是RD，需要对资源、引擎、数据、算法专业分门类研究得细致入微，所以它不应该采用赛马逻辑，而是核心资源给到核心项目，采取每个同学在自己的方向上精进的逻辑和原则。简单来说就是自己不要卷起来。

       原则二：通用平台而非BP制。BP制容易向某一个业务倾斜，导致中台不能复用，而中台强调通用性。

       原则三：不能急功近利，朝令夕改。作为中台的领导者或是策略的制定者，不能急功近利、朝令夕改。由于中台职能型的性质以及员工的分门别类，中台其实是一个“慢工出细活”、“老火炖鸡汤”的一个部门，可以以半年或一年为粒度，在技术和产品上做一些引领性的东西，达到赋能业务的目标。

       数据中台的方法论原则：

       onedata，“一个生产”。从数据源，到数据建模，到指标维度口径，对数据进行打通形成的全链路就是onedata。

       onemeta，“一个资产”。数据建设完成后，如何进行数据管理、数据地图，方便各个业务线进行数据查找；数据作为一个不停计算的资源，如何进行管理；数据如何进行下线。这些维度都是onemeta的覆盖范围。

       onesevice，”一个服务“。即把不同的引擎技术能力通过API的形式为业务赋能。Onesevice是数据中台正在探索、实验的项目，不同的公司在onesevice的进展上有所差异，但是onedata和onemeta是比较成熟的。

       数据中台的技术原则：

       数据中台的建设一般包括四个模块，通常是“三横一纵”的架构。“三横”自下而上分别为数据接入、数据开发和数据应用。数据接入包括日志接入和业务数据接入。数据开发分为离线/实时数仓开发、数据测试、数据监控与质量监测。数据应用是最上层，例如A/B测试产品。“一纵”是数据管理产品，包括元数据管理、资源管理、资产管理、数据治理和数据安全。

       04数据中台实践

       数据中台建设中onedata比较复杂，存在一些通用性的痛点，可以从来源、口径、规范三个方面来看。

       来源：导致来源和计算逻辑不清。

       口径：包括口径相同、口径不同、口径描述不清晰三种情况。口径即谁创建的？谁以什么逻辑创建的？谁以什么逻辑在什么时候创建的？

       规范：

       口径相同，命名不同，例如，电商和销售领域有订单核销券和订单关闭券两个定义，不同的业务线二者的定义是相同的，都是下单之后订单被接收且没有退单的情况，但是容易误认为两个指标是不同的。

       口径不同，生产者不同，例如，口径是不同部门建设的，还是相同部门不同岗位的人建设的？口径生产者不同，逻辑就会难以追溯。

       口径不同，描述事件相同，例如，描述的都是消费券，但是消费券是否被核销没有被注明，也会造成口径不同。

       口径描述不清晰。例如DAU指标，如果没有对Day、Active和User进行准确的描述，也会造成口径问题。

       针对onedata的困境，对问题进行抽象，分别从来源、口径和规范层面进行修复。

       来源：划分业务线—主题——指标维度

       口径：维度与指标的业务描述和使用场景

       规范：

       命名规范：eg原子指标和派生指标

       组织与生产规范：生产流程、审核流程、授权流程、治理流程

       下面举例说明onedata的实践。

       来源：业务板块为电商业务；电商通常分为人、货、场，或者是用户域、交易域、商品域，该案例的数据域即交易域；业务过程是支付；修饰类型是专场/商品，时间周期分为实时、离线和维度指标（日、月、季、年等），此处为实时；修饰词为单个专场和单个商品；此处的原子指标是销售件数，派生指标为近7天所有专场的爆款率，度量为支付件数。需要注意的是，在指标管理里面可以区分原生指标和派生指标，因为它的输出是业务线上的看板数据，但是对于平台BI类分析型产品，不建议有原生指标、派生指标、衍生指标这种概念，容易造成指标膨胀，建议通过用户宣导来进行维度的分组或过滤，直接提供原子指标和清晰的维度，方便用户理解。维度即专场商品，属性为商品ID和专场ID。

       命名规范：派生指标=原生指标+时间周期+其它修饰词，例如会员有黄金、白金、黑金等修饰词，就会产生派生指标。

       组织与生产规范：业务方提出需求，然后进行业务调研、需求分析和数据探查，需求一般来自于业务线上的运营、产品和分析师；确认需求指标和指标口径之后，对指标的规范进行定义，构建一致性维度、一致性度量和指标，这个过程通常由业务线上的数据PM或数据接口人实现；需求受理之后，进行模型明细设计，构建一致性维度和事实表，同时构建统一指标汇总表；进而完成代码开发、部署、运维和数据应用，最后可以应用于报表、OLAP分析应用或者自主查询分析，这个过程由数据中台的数据PM来完成。

       05总结

       数据中台是通过数据技术对海量数据进行采集/计算/存储/加工，同时统一标准和口径的部门。

       如果你有指标口径不一致，数据重复建设、取数效率低、数据质量差、建设成本高等问题，数据中台是解决这些问题的良药。

       数据中台仍旧适合至少3条业务线/有降本增效需求/长期有耐心的公司。

       数据中台的组织三原则/方法论原则和技术原则。（集中资源/非bp/不急功近利）

       最后，建议数据中台还是要为业务部门提供价值，核心问题就是效率、质量和成本的问题。