最近阿里巴巴分享了《阿里巴巴数据中台实践》这个PPT（自行搜索原始文章），对于数据中台的始作俑者，还是要怀着巨大的敬意去学习的，因此仔细的研读了，希望能发现一些不一样的东西。

读这些专业的PPT，实际是非常耗时的，你需要把这些PPT外表的光鲜扒光，死抠上面的每一个字去理解底下隐藏的含义，然后跟你的已有知识体系去对比，看看是否有助于完善自己的认知，对于自己不理解的，还需要经常去检索相关的文档。

当然，很多写PPT的用词没这么严谨，临时造概念的不少，或者是独特的说法，因此有时候还要做一些揣测，结合自己的实践去理解，这篇PPT的解读有6000多字，因此请做好烧脑的准备，虽然笔者没去现场听演讲，但希望我的“演讲”也能让你学到真功夫。

就让我们开始吧。

1、题目和背景

看到这个片子的出处，阿里云智能事业部，其实是有点奇怪的，记得阿里的中台事业群包括搜索事业部、共享业务平台、数据技术及产品部，阿里云是一个侧重云业务的平台事业部，它来说数据中台合适吗？

有人会问，平台和中台又有什么区别呢？阿里云来讲中台不是很合适吗？

笔者的疑惑是这样：一般意义上的平台具备业务无关性，潜心技术就可以了，而中台是业务的收敛，跟业务的相关性很大，对于数据中台，其核心竞争力不是平台级的技术，而是数据的理解、处理和挖掘。让一个做平台技术的人跑到前端去理解数据诉求沉淀共性是不现实的，而这是当前数据中台创造价值的核心。

当然讲PPT的可以不问出身，能理解阿里的数据中台就可以了。

2、DT派向左，IT派向右

传统的IT是成本中心，而有了数据后，就可能成为价值中心，这个价值体现在：在管理上可以提供决策支持，在生产上可以提供与管理匹配的智能工具，也就是提升生产关系和生产力的适配能力。

这一点提得是不错的，比如浙江移动大数据中心就是直接定位为利润中心。

这里的IT和DT的对比就不太合适了，两者不是对立的关系，而是融合的关系，D通过IT形成DT，比如原来IT渠道系统仅受理业务，现在在受理的场景下可以加载基于数据的智能推荐。

DT只是马云提得一个突出数据价值的抽象概念，不能生硬去的理解，现在中国移动提了一个三融概念：融合，融通，融智，我觉得IT和DT就要加强融合融通，融合就是搭在一起卖，融通就是能力共享，IT中有DT能力，DT中也要有IT能力。

片子中提到的DT是问题导向，IT是需求导向，这是一个问题的两面，而不是DT和IT的区别；新抛出的DT的授之以渔，IT的授之以网的区别在于方法的观点倒是有点道理，比如DT的智能推荐就是提供了方法，而以前IT的推荐靠的是人的判断。

3、企业组织对于DT的希望

高管团队：看指标发现风险这是BI时代的基本诉求，没啥好说的；大数据更强大的处理、可视化、实时等技术可以提供更好的看数据体验，这是相对于以前BI提升的地方。

业务团队：提到三个变化：

一是通过数据发现问题，而不是拍脑袋。

二是业务人员要既懂业务也懂数据，甚至能自己DIY数据和模型。

三是数据要嵌入生产流程中直接发挥作用，比如标签库要成为营销目标用户的发起地，风控模型要嵌入在用户操作流程中等等。

第一点大家都在做，实际还是以经验为主，数据只是参考和佐证，这种模式本质上没有改变。第二点，第三点执行到位对于大多数企业都很难。

技术团队：提到三个要点：

一是“数据多跑路”是智能平台的核心，浙江的“最多跑一次”就是要靠数据和平台整合实现这个目标。

二是IT人员要有数据化的思维，这个提的很好，缺乏数据思维的人设计IT系统很少考虑智能，现在很多企业的受理系统跟推荐系统是两者皮多少有这个原因。

三是通过数据分析发现新的知识，从而赋能业务，这是数据技术团队的使命。

4、大中台、小前台

这张图诠释了阿里的商业操作系统的引擎：大中台，小前台，展示的很清晰了，特别提醒要理解两个重要概念：业务数据化和数据业务化。

业务数据化：就是所有的商业活动都应该记录下相关的数据，这是业务中台应该承担的使命。

业务数据化挑战其实很大，以前业务平台在设计的时候，是以功能和流程为核心的，只记录对于要实现功能和流程必需的数据，其他的就可有可无了。

比如运营商的一些信令日志记录不全面导致可能影响后续的网络分析或数据价值变现，这就没有做到业务数据化。

但业务数据化有时意味着巨大的成本投入，说来容易执行难，大多企业的数据不是业务数据化战略执行的结果，而仅仅是顺便摘取的低垂的果实。

数据团队的一个使命就是业务数据化，很多好的数据是你进入前端争取来的，这样才能驱动业务记录数据。

数据业务化：本质就是从数据中发现价值，反过来赋能业务，这是很好理解的。

数字孪生这个词现在也比较热了，未来万物互联的世界将你所有的行为实时记录下来，形成另一个数字化的你，这就是数字孪生，如果业务中台是你，那数据中台就是你的兄弟。

5、数据中台赋能的四大典型场景

（1）全局数据监控：本质就是指标+报表+可视化，这是给管理者看得，当然业务人员也要看，以下给了双11大屏示例。

（2）数据化运营-智能CRM：提到要“基于全链路全渠道数据的建立以“人”为核心的数据连接萃取管理体系，对用户进行全生命周期的精细化管理”，这么多形容词懵不懵逼，到底在说啥？

全链路是指纵向记录跟踪整个商业过程的数据（包括商品企划、售前及售中管理、客服管理、订单处理、仓储物流等等）。

全渠道就是各触点的用户行为数据，比如天猫、淘宝、优酷等等。

因此，通过汇聚全链路全渠道的数据才能形成完整的客户画像，然后用连接萃取的方式方便的获得所需的数据进行分析，从字面意思看跟我们的标签库定位有点像。

（3）数据植入业务-智能推荐：这里讲的比较清楚，就是营销闭环管理，从用户细分，千人千面，渠道推荐，再到营销评估，以下是示例。

（4）数据业务化-生意参谋：这个是阿里力推的为数不多的血统纯正的数据产品，是数据业务化和数据直接变现的典型代表，可以为店主提供端到端的分析支撑，网上介绍很多了，下面这张片子着重说明了生意参谋的历史，现在和未来，有点意思。

历史：百家争鸣，虽然提了数据冗余、体验差等问题，但没有百家争鸣，不可能有生意参谋这个整合产品的出现。

现在：生意参谋独霸天下，依托的是数据中台体系，包括OneData、OneService、OnePlatForm等，这个后面会解读。

未来：一个生意参谋还不够，要打造一个产品开发平台，复制出一个个面向不同行业的生意参谋，也就是参谋X，野心很大。

为什么说血统纯正呢？

因为诸如推荐啥的，数据是依附于业务流程上的，你评估数据价值的时候，很难说是业务本身好、流程设计好、还是你数据推荐的好，而纯正的数据产品是数据人员彰显自身价值的更好方式。

6、阿里巴巴做数据中台的缘起

做数据中台的缘起跟一般数据仓库融合模型是一样的，共享复用的需要，比如原来基于淘宝数据的各种业务都自建一套中间层，而这些中间层很多是重复或类似的，比如蚂蚁业务有交易主题，天猫也有交易主题，那能不能抽象出公共的交易主题为两个业务都服务呢？

因此你会看到阿里数据中台抽象出了会员、商品、交易、浏览、广告等公共核心主题层，从而为应用层服务，各个应用层以前要做很多公共层的东西，现在也可以完全复用了，理论上可以提升应用构建的速度。

下面这页片子从数据的依赖关系图比对了前后的变化，一个是网状的，代表了相互之间千丝万缕的关系，冗余肯定是很多的，一个是放射状的，一个节点可以为更多的后端节点服务，代表了共享和简洁。

7、阿里巴巴数据中台全景图

读懂这张图就理解了阿里的数据中台具体到底干了些什么，有五大部分跟数据中台直接相关：数据中台DaaS、数据资产管理IPaaS、数据研发平台IPaaS及计算与存储平台IaaS。

笔者理解广义的数据中台其实包括数据中台DaaS、数据资产管理IPaaS、数据研发平台IPaaS三部分，如果狭义的理解则仅包括数据中台DaaS，数据资产管理IPaaS、数据研发平台IPaaS在笔者的企业叫做能效中台。

（1）计算与存储平台IaaS

流计算SteamCompute：应该指阿里内部的Flink版本。

离线计算MaxCompute：阿里自研的EB级的数据仓库（原来的ODPS）。

实时计算ADS：AnalyticDB的简称，主要是提供实时在线分析，可以认为是阿里自研的OLAP版本。

（2）数据资产管理IPaaS

数据资产管理其实跟元数据管理一回事。

资产地图：本质上是数据字典的图形化版本，阿里有多少数据、如何存储、数据之间关系如何、如何找、如何用都可以从资产地图找到答案，蛮形象的，从网上资料看，其设计还是值得借鉴，以下是一些界面截图。

资产分析：你可以理解为针对元数据的BI分析，什么结构分析，趋势分析什么的，万变不离其宗，你希望通过元数据分析理解现状，发现异常，从而指导数据资产的治理，比如支付类别的数据增长情况如何。

资产应用：你可以理解为利用元数据信息来提升数据资产的利用效率，比如通过影响分析挖掘出无效的数据资产，从而降低数据冗余，这个工作做好，价值是很大的。

资产运营：运营这个词被用烂了，运营其实不是一个功能，而是一个动作，希望通过各种举措来让数据被更多的人使用，从而产生更多的价值，比如新增数据资产的推荐等等。

数据资产使用的二八定律是非常明显的，大多数据其实是没人访问或使用的，而存储的成本可是很高的，只有通过运营才能让沉默的数据被更多的人使用，无效的数据得到清除，从而实现降本增效。

（3）数据研发平台IPaaS

这个平台跟笔者以前文章中提到的DACP是一个东西，就是负责数据的加工，需要一系列配套功能，包括数据规划、交换、处理、开发、调度及监控等等。

（4）数据中台DaaS

垂直数据中心（OneClick）：就是传统数据架构中的ETL，通过离线、实时等方式将各渠道的数据采集过来。

公共数据中心（OneData）：就是数据仓库建模需要达到的目的，保证数据口径的规范和统一，沉淀共性的数据，阿里采用的是维度建模，通过分析业务过程抽象出维度和指标，最后汇总成所需要的仓库模型。

萃取数据中心（OneID）：笔者的理解是阿里为了方便对外提供数据，形成了一套以各种ID（业务核心对象）为唯一标识的宽表，就好比运营商需要形成一套以用户ID（手机号码）、客户ID、账户ID、家庭ID为核心的宽表体系一样。

统一数据服务中间件（OneService）:以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务。

8、阿里巴巴数据中台的沉淀与积累

（1）OneData

数据标准化：实现数据资产各域、主题、模型、字段、指标命名等的统一规范，笔者一直强调数据标准化一定要在源头解决，如果阿里的业务系统数据资产都遵循这个原则，那是厉害的很。

技术内核工具化：我的理解是规范的落地必须依托工具来强制控制，比如你只能按照规范模板的要求来建表，否则就执行不了，阿里在这方面的管控据说是比较给力的。

元数据驱动智能化：有了元数据分析就能科学的计算出对于资源的诉求，而且可以做得非常快速和灵活，摈弃每次规划扩容到处找依据的窘境，这跟前面的元数据应用是类似的。

OneData是阿里数据中台非常核心的内容，其有一个Dataphin引擎，可以实现数据标准规范定义、数据模型的自动化开发、主题式数据服务即时生成等功能。

具体如下面这个片子所示，其包括数据引入-规范定义-数据建模-数据外部关联-数据资产沉淀-数据服务生成整个闭环链条，通过这一链条把数据管理的大多要素都实现了。

这种强规范性的开发模式在一定程度上也降低了灵活性，但其规模效益是非常好的，否则阿里这么庞大的数据资产是根本无法很好管理的，这个笔者深有体会，正如我们运营的DACP一样，我们遭遇到的，他们也一定遭遇到了。

指标标准化是笔者尝试过的事情，因为当初深感重复开发的报表太多了，而通过指标标准化可以解决这类问题，这是报表做到一定程度后自然而然产生的想法，以下阿里的做法跟自己当初做的如出一辙，所谓殊途同归。

（2）OneID

假设有一位用户张三，在第一个手机上使用百度地图， 在ipad上观看百度爱奇艺视频，在第二个手机上使用手机百度app, 在pc电脑上使用百度搜索，如何将同一个用户在这些不同端的用户信息聚合起来呢？

跟运营商的天然的以手机号码为唯一标识不同，互联网公司的各类账号ID要打通的挑战是非常高的，ID-MAPPING是互联网公司的一个核心技术，其需要确保各个领域搜集的数据是可以集成和关联分析的，没有统一ID的支持，多样化的数据集中起来分析是没有意义的，这是另一种形式的数据孤岛。

比如下面的四条用户记录实际上表明的是同一个人。

（3）OneMeta

这里的“数据资产分析”和“数据血缘跟踪”在前面的“数据资产管理IPaaS”都已经提及，是数据管理里非常基本的东西，特别提下数据综合治理。

安全：指的是诸如敏感数据分级和访问控制定义。

质量：指的是数据的质量规则定义。

成本：指基于数据资产的调用情况和处理成本给出一个综合评估。

人员：大概是数据资产指归属组织和个人的定义吧，比如我们的数据字典里就有一个属性，必须标识出这个资产的创建人、修改人以便跟踪追责。

（4）OneService

主题式数据服务：应该是基于元数据构建的简单数据服务查询引擎，面向业务统一数据出口与数据查询逻辑，屏蔽多数据源与多物理表，就是搞一套业务化的伪SQL方便取数。

统一而多样化的服务：一般查询指普通SQL查询，OLAP就是多维分析，在线服务比较抽象，笔者猜测是诸如数据推送、定时任务等定制化服务形式。

跨源数据服务：大数据由于技术组件非常多，不同的数据往往存储在不同的数据库内，比如hadoop，gbase，oracle等等，如果要进行跨异构数据库的即席查询一般就要做先做数据汇聚，但一些轻量级的取数希望能直接进行关联分析得到结果，因此出现了这种服务诉求。

PPT就解读到这里，笔者最大的感受就是阿里的数据中台技术体系很庞大，但又非常关注细节，几个字看着简单，但落地则需要付出巨大的代价，而且是个渐进的过程，比如Dataphin。如要要了解阿里数据中台的更多技术细节，推荐一本书《阿里巴巴大数据实践》。

其实数据中台要搞好不是简单的引进几个工具就可以了，技术仅仅是技术，你能COPY技术但COPY不了管理和文化，而这恰恰是数据中台成功的关键。

数据中台的更大挑战是：你的企业对于数据的理解是否已经达到了一定的阶段，你是否能够驱动公司去建立一套适合自己企业的数据管理机制和流程，而这个是最难的，你得走出自己的路。

作者：傅一平 （微信号：fuyipingmnb）

欢迎加入“MaxCompute开发者社区2群”,点击链接申请加入或扫描二维码
https://h5.dingtalk.com/invite-page/index.html?bizSource=____source____&corpId=dingb682fb31ec15e09f35c2f4657eb6378f&inviterUid=E3F28CD2308408A8&encodeDeptId=0054DC2B53AFE745