《2022云原生数据中台.docx》由会员分享，可在线阅读，更多相关《2022云原生数据中台.docx（490页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、云原生数据中台：架构、方法论与实践目录第一部分数据中台与硅谷大数据平台第1章全面了解数据中台1.1 数据中台概念的起源1.1.1 艺电的“数据中台”改造1.1.2 Twitter的数据驱动1.2 什么是数据中台1.2.1 数据中台建设的目标1.2.2 如何实现数据中台建设的目标1.2.3 数据中台的定义和4个特点1.3 大数据平台与数据中台1.3.1 为什么要建设数据中台1.3.2 数据中台与传统大数据平台的区别1.3.3 数据中台的评判标准1.4 数据中台建设方法论总纲1.5 本章小结第2章数据中台能力和应用场景2.1 数据中台不是“银弹”2.2 数据中台的核心能力2.2.1 全局商业洞见2
2、.2.2 个性化服务2.2.3 实时数据报表2.2.4 共享能力开发新业务2.3 数据中台的行业应用场景2.3.1 互联网行业2.3.2 连锁零售业2.3.3 金融业2.3.4 物联网2.4 数据中台如何为企业赋能2.4.1 组织架构2.4.2 决策部门2.4.3 业务部门2.4.4 研发部门2.4.5 大数据部门2.5 本章小结第3章数据中台与数字化转型3.1 数字化转型的4个阶段3.1.1 信息化3.1.2 数据仓库（数据平台1.0）3.1.3 大数据平台（数据平台2.0）3.1.4 数据中台（数据平台3.0）3.2 数据驱动3.2.1 面向用户的数据驱动产品及服务3.2.2 面向内部业务
3、部门的数据驱动服务3.2.3 数据驱动的系统管理3.3 数据中台如何支持数字化转型3.3.1 从技术层面支持数字化转型3.3.2 从组织架构层面支持数字化转型3.4 本章小结第4章从大数据平台到数据中台4.1 大数据平台建设阶段4.1.1 大数据平台起步4.1.2 系统自动化4.1.3 大数据平台的生产化4.2 数据管理及应用阶段4.2.1 数据湖/数据仓库建设4.2.2 数据管理4.2.3 数据安全4.3 数据能力中台化阶段4.3.1 全局的数据治理4.3.2 数据能力的复用和共享4.3.3 云原生架构的支撑4.4 DataOps4.4.1 什么是DataOps4.4.2 DataOps解决
4、的问题4.4.3 DataOps的目标功能4.4.4 DataOps的主要技术4.4.5 DataOps与数据中台4.5 本章小结第二部分数据中台架构与方法论第5章数据中台建设须知5.1 数据中台建设需要一套方法论5.2 从失败的大数据项目中吸取教训5.3 数据中台建设中的常见问题5.4 评判数据中台建设效果5.5 数据中台建设的人员规划5.6 数据中台的技术选型要求5.7 本章小结第6章数据中台建设方法论6.1 基础架构6.2 数据工具6.3 顶层架构设计6.4 数据规范6.5 业务驱动6.6 关键指标6.7 明确责权利6.8 管理迭代6.9 数据中台建设流程6.10 本章小结第7章数据中台
5、的架构7.1 数据中台的功能定位7.2 数据中台架构设计的9大原则7.3 典型的硅谷大数据平台架构7.3.1 Twitter的大数据平台架构7.3.2 Airbnb的大数据平台架构7.3.3 Uber的大数据平台架构7.3.4 云平台作为大数据平台的通用底座7.3.5 硅谷大数据平台架构的共性和建设思路7.4 数据中台架构7.5 数据中台子系统7.5.1 应用基础能力平台7.5.2 数据基础能力平台7.5.3 数据集成开发平台7.5.4 数据资产运营平台7.5.5 数据业务能力层7.5.6 数据中台重点建设内容7.6 本章小结第8章数据中台与云原生架构8.1 云原生架构及云平台8.2 PaaS
6、平台的主要功能8.2.1 资源管理8.2.2 应用全生命周期管理8.2.3 高可用和容错8.2.4 运维平台8.3 传统方式下搭建数据中台的难点8.4 云原生架构对于数据中台建设的5大意义8.5 数据中台的IaaS层选择8.6 本章小结第三部分数据中台技术选型与核心内容第9章数据中台建设与开源软件9.1 开源软件的起源和建设过程9.2 开源软件的合理使用9.3 集成开源软件的5个注意事项9.4 应用基础能力平台的开源选择9.5 数据基础能力平台的开源选择9.6 数据集成开发平台的开源选择9.7 本章小结第10章数据湖与数据仓库10.1 数据湖10.1.1 数据湖的起源与作用10.1.2 数据湖
7、建设的4个目标10.1.3 数据湖数据的采集和存储10.1.4 数据湖中的数据治理10.2 数据仓库10.2.1 数据建模方式10.2.2 数据仓库建设的层次10.2.3 数据仓库中的数据治理10.2.4 数据清洗10.3 数据中台中的数据仓库和数据湖建设10.4 本章小结第11章数据资产管理11.1 数据资产管理的难题11.2 数据资产管理定义11.3 主数据管理11.4 元数据管理11.4.1 元数据的分类11.4.2 元数据管理系统的功能11.5 开源的元数据管理系统11.6 数据资产的ROI11.7 本章小结第12章数据流水线管理12.1 数据流水线的定义与模型12.2 数据流水线中的
8、应用类别12.3 数据流水线的运行方式12.4 数据流水线示例12.5 数据流水线管理系统面临的挑战12.6 数据流水线管理系统的功能需求12.6.1 自动化流水线12.6.2 数据管理12.6.3 性能要求12.7 数据流水线管理系统的组件12.8 批流合一的数据流水线12.9 本章小结第13章数据中台应用开发13.1 数据应用的形态13.2 应用开发工具13.3 3种典型的数据中台应用13.3.1 数据即服务13.3.2 模型即服务13.3.3 用户标签系统13.4 数据中台应用的开发和管理13.4.1 应用调度系统13.4.2 多租户管理13.4.3 持续集成和发布13.5 本章小结第1
9、4章数据门户14.1 数据门户出现的背景14.2 硅谷的数据门户建设14.2.1 Twitter的DAL和EagleEye14.2.2 LinkedIn的DataHub14.2.3 Airbnb的DataPortal14.2.4 Lyft的Amundsen14.2.5 Netflix的Metacat14.2.6 Intuit的SuperGlue14.2.7 硅谷数据门户总结14.3 数据门户的定位及功能14.4 数据门户的实现原理14.5 数据门户的社交属性14.6 数据应用的自助及协同工作14.7 数据智能运维14.8 本章小结第15章管理数据中台的演进15.1 不断演进的数据中台15.2
10、人员变动下的数据管理15.2.1 数据安全15.2.2 数据能力的传递15.3 数据和应用的演进15.4 资源的演进15.5 演进中的关键指标15.6 本章小结第四部分数据中台案例分析 第16章EA“数据中台”实践16.1 建设背景16.2 组织架构调整16.3 建设过程16.4 体系架构16.5 数据治理16.5.1 数据标准和规范16.5.2 元数据管理16.5.3 数据质量管理16.6 数据应用产品16.6.1 推荐系统16.6.2 打造动态游戏体验16.6.3 标签系统及游戏运营16.7 EA“数据中台”功能总结16.8 本章小结第17章零售行业的数据中台17.1 零售行业的数字化转型
11、17.2 零售行业数据中台解决方案17.3 零售行业数据中台的建设17.3.1 数据汇聚17.3.2 业务调研17.3.3 数据仓库建设及数据分析17.3.4 业务系统的能力反馈17.4 零售行业数据中台的应用场景17.4.1 用户标签体系17.4.2 精准市场营销17.5 本章小结第18章物联网领域数据中台建设18.1 现代物联网的产业链18.2 物联网与ABC18.3 物联网数据中台架构18.4 智慧建筑物联网数据中台应用18.5 本章小结前言数据中台的概念从刚刚提出时的火热到最近的降温，似乎已经加速走过了Gartner技术成熟度曲线的一半周期：从出现，到受吹捧，到遭质疑，再到进入低谷。数
12、据中台将逐渐消失，还是在成熟后成为像数据仓库一样的数据基础架构？最终的答案当然要由市场给出，但我们想在本书中基于我们的经验与思考，介绍数据中台出现的根本原因、它在实现数据价值中的关键作用以及它的建设方式。对于数据的价值，在大数据概念普及多年后的今天，大家应该是普遍认可的。我一直都在从事与数据相关的工作和研究，1996年在武汉大学跟随何炎祥老师做分布式数据挖掘方面的研究，2000年在美国马里兰大学做流式数据引擎相关的探索，2005年加入A做分布式操作系统的数据存储工作。2008年大数据概念出现，我在A做了一个非常明智的决定使用开源的Hadoop（而不是我们内部的分布式操作系统）替代日益昂贵、不堪
13、重负的Oracle数据仓库，虽然我们的内部系统比Hadoop快一个数量级。替换了Oracle之后，我们还基于Hadoop平台开发了一系列数据驱动的产品，满足了不断增长的数据产品需求。2011年，我加入Twitter并负责大数据流水线的建设，我在实践中看到公司如何从数据中获取价值，实现整个企业的数据驱动。与此同时，我也与硅谷其他公司同行进行了广泛的探讨，这些使我坚定了自己的认识：未来的企业一定是数据驱动的企业，未来的大数据一定会和Word、Excel、数据库一样，成为企业运营人员的必备技能。虽然数据的价值得到普遍认可，企业数字化转型的必要性也是大部分CEO的共识，但业界对一个关键问题的看法还远没
14、有达成一致：数据中台是不是支撑企业数字化转型的最合理的数据基础架构？在我们与国内企业交流的时候，很多企业的CEO、CIO仍对数据中台到底应该是什么形态有不少疑问。与之不同的是，硅谷的大多数知名独角兽公司有与数据中台架构相似的数据基础架构，即数据平台（Data Platform），并以此作为企业数字化运营的基础。这些数据平台虽然没有被称为中台，但却包含了我们通常认为中台需要承载的任务：打通企业各个部门之间的数据，形成统一的数据开发和使用规范，在企业各个部门之间实现数据能力的抽象、共享和复用。因此，本书试图找到这些数据平台的架构与国内普遍认可的数据中台架构之间的通用理念，并从对业务的实际需求层面探
15、讨这些架构设计理念的合理性和必要性。与传统技术中间件不一样，数据中台虽然也是承接底层数据和上层业务的中间层，但它的价值更多体现在与业务结合的能力矩阵，而不是简单的数据标准化和报表工具上。各个业务部门可以使用不同的技术中间件，这样虽然效率可能低一些，但是同样可以满足业务的要求。然而，分割的数据层无法对核心业务流程进行全局还原和支持， 无法实现数据驱动的全局决策和产品研发。与传统的数据仓库受事前建模的限制不一样，数据中台一般使用数据湖来存储可以反映全局业务情况的原始数据，能够对核心业务流程进行更全面、更深入的分 析，并在此基础上加快对市场的认识和反应，降低产品研发和试错的成本，缩短时间。因此，定义
16、好业务能力矩阵，让业务部门看到数据中台实现从0到1的关键数据能力，将大数据平台从成本中心变成利润中心，应该是每个企业建设数据中台的目标。除了确定对于业务的价值之外，建设数据中台的一个根本问题是技术架构的选择及设计。我在Twitter架构师委员会担任负责大数据平台的架构师期间，每个星期都会参加由CTO组织的产品架构评审和讨论会。这些会议给我留下最深印象的不是对各种前沿技术的讨论，也不是架构设计中的技术难点攻关，而是技术架构对业务的重大影响。很多时候，我们看到一个快速发展的业务因为早期架构设计的问题而难以迭代，或者企业的发展受限于IT部门的效率。而一个高效的架构能够解放业务部门的生产力，真正赋能业
17、务人员去完成以前想都不敢想的任务。其实数据中台这个概念会在国内出现，很大程度上也是因为架构的问题。试想一下，如果我们在设计大数据平台的时候就已经考虑到了消除数据孤岛、应用孤岛，统一数据规范，那么还需要单独建设一个数据中台吗？因此，我们在本书中讨论了云原生架构对于数据中台的必要性。数据中台的一个天然特性是支持多元异构的数据以及处理这些数据的工具。虽然很多时候孤岛的产生有组织架构的原因，但是缺乏统一的数据平台，无法快速支持不同部门对数据的不同需求，这些也是产生孤岛的重要原因因为业务部门需要不断建设独立的系统以满足眼前的紧迫需求。在Twitter的大数据平台建设过程中，公司规模从300 人发展到40
18、00人，集群规模从80台服务器扩展到8000台服务器，利用云原生架构我们快速满足了各个部门对不同数据的需求，并极大简化第一部分数据中台与硅谷大数据平台要说近几年IT界最火热的技术名词，“中台”当仁不让。这个由阿里巴巴创始人马云“发明”的新词一经出现，就在业界掀起了一波中台建设的浪潮，国内互联网巨头相继加入这波浪潮，一时间，中台之风横扫业界。而随着中台概念的盛行，以实现数字化运营、构建数据驱动企业为目标的“数据中台”脱颖而出，成为业界竞相追逐的目标，以至于2019年被定义为数据中台爆发的元年。然而，在最早推行数字化运营和数据驱动的硅谷互联网企业中，像早期的Google、Apple、Faceboo
19、k、Twitter、LinkedIn、Netflix，以及后起之秀Uber、Lyft、Airbnb、Pinterest，却没有听说过“数据中台”。那么，是这些硅谷的企业不需要数据中台，还是数据中台只是一个新瓶装旧酒的伪概念，抑或另有隐情？在这一部分，我们通过探讨数据中台这个概念的起源，它与大数据平台、数据仓库之间的传承关系，以及它在数字化转型过程中解决的问题，试图对“数据中台”下一个明确的定义，并以此为基础确定数据中台的使用场景、建设内容和原则。第1章全面了解数据中台说起数据中台，就不能不提大数据。大数据的概念源自硅谷，并迅速在全球普及。从第一个开源的Hadoop项目，到Facebook、 T
20、witter、阿里巴巴、字节跳动等一系列改变人们社交和商业行为的公司，到由大数据专家指导的美国大选，再到中国政府将大数据作为核心基础设施之一来建设，不过十多年时间，大数据已经在方方面面深刻影响了我们的生活。实际上，数据中台作为大数据平台进一步发展的产物，与大数据的关系非常密切。而要理解为什么数据中台能在国内得到如此多的关注，首先就需要了解大数据的最终目的和发展历程，大数据如何赋能企业的数字化转型，以及IT系统、大数据系统是怎样一步步发展到今天的形态的。因此，在本章中，我们将介绍数据中台与大数据平台、数据仓库等易混淆概念之间的关系以及数据中台的目标及其应用范畴。由于本书主要介绍数据中台相关的理论
21、和实践，因此一些常规的大数据概念和功能，例如基于Hadoop的大数据平台、数据仓库的一些传统实践， 在这里只进行简单介绍。但需要强调的是，“数据中台”只是一个名称，就像“大数据”一样，其具体内容和定义根据它要实现的目标和要解决的问题来确定。1.1 数据中台概念的起源尽管大数据产生于硅谷，数据中台与大数据关系密切，但硅谷却没有数据中台这个名词，因此，我们首先要来看看“数据中台”的概念是如何在其倡议者阿里巴巴内部产生的。下面的故事想必很多人都听说过。2015年年中，马云带领阿里巴巴集团高管拜访了一家芬兰的小型游戏公司Supercell。让马云及其高管团队感到惊讶的是，这家仅有不到200名员工的小型
22、游戏公司竟创造了高达15亿美元的年税前利润！该公司典型的开发模式是以小团队为单位的单独“作战”，每个团队不超过7名员工。每个团队都可以自己决定开发什么样的游戏产品，然后以最快的速度推出公测版，如果不受欢迎，就立刻放弃，寻找新的方向。这种开发模式使Supercell能非常快速和敏捷地找到玩家喜欢的方向，从而更容易开发出能够迎合玩家需求的游戏产品。而Supercell之所以能够支持多个团队快速、敏捷地推出高质量的游戏作品，其强大的中台能力功不可没。因此，在拜访Supercell的旅程结束之后，马云决定对阿里巴巴的组织和系统架构进行整体调整，建立阿里产品技术和数据能力的强大中台，构建“大中台，小前台
23、”的组织和业务体制。当然，Supercell的研发模式并不是什么革命性的创新，绝大部分硅谷公司也有类似的模式：本来就不大的公司被分成若干个小组。这样做的好处是各小组可以快速决策、研发并将产品推向市场，而不需要重复开发游戏引擎、数据分析、服务器等后台基础设施和服务。这里，“游戏引擎”可以看作业务中台，“数据分析”可以看作数据中台，“服务器等后台基础设施”可以看作PaaS/IaaS平台，也就是有些文章中所说的技术中台。实际上，虽然硅谷并没有“数据中台”这一叫法，但硅谷的公司早已自然形成了中台的意识。从早期的中间件（Middleware）、面向服务的架构（SOA）到后来的IaaS/PaaS/DaaS
24、平台、微服务（Microservice），都有中台思想的影子，都来源于避免重复造轮子、快速迭代、数据驱动、业务驱动这些硅谷工程师文化的核心理 念。国内类似的概念“技术中台”就源于中间件、PaaS平台。但是这种中间件、平台、中台的功能一般并非由一个顶层设计得出，而是一步步建立起来的。在硅谷的企业中有一个非常重要的理念就是不要做“过早优化”（Premature Optimization），也就是说，不要在不需要的时候进行优化。一定要先完成功能再优化，因此不需要中台的时候没有必要刻意建一个大而全的中台。当然，在建设数据中台的不同阶段可以使用不同的技术，只要保证中台建设能够平滑过渡即可。下面就来简单介
25、绍笔者曾在硅谷负责建设的两个典型大数据项目，看看它们和数据中台的关系。1.1.1 艺电的“数据中台”改造EA（艺电）是一家总部位于硅谷的知名跨国游戏公司，创造和发行了众多深受游戏迷喜爱的游戏，例如FIFA足球Madden橄榄 球NHL冰球和NBA篮球等体育游戏，令军迷们狂热的战 地及星球大战系列游戏，以及经久不衰的模拟城市模拟人生植物大战僵尸等游戏。这些游戏都是由EA位于全球各地的游戏工作室开发的，但是游戏里所涉及的数据分析工具却是由位于硅谷总部的大数据团队提供的。在有统一的大数据平台之前，EA的每个工作室都需要开发自己的大数据平台，编写自己的大数据分析程序。各个工作室的数据能力参差不齐，数据
26、质量得不到保证，有的产品甚至完全没有数据分析。各个工作室之间无法共享数据和用户资源，总部在汇总全集团的营业数据时也费时费力。这可以说是一个非常典型的数据孤岛的情况。2011年，EA开始逐步建立全局大数据平台（类似于具有数据中台功能的平台），将各个工作室的数据逐渐汇聚到这个全局大数据平台上，并为各个工作室提供统一的数据分析和数据服务工具。各个工作室不再需要自己维护大数据平台，也无须自己雇用大数据平台开发人员，它们既可以使用集团的数据分析系统得到自己需要的业务报表， 又可以使用系统提供的反欺诈、产品推荐等服务，专注于业务使它们能够快速推出新产品。同时，由于各个游戏的数据得以打通，用户数据得到统一，
27、EA可以构建更全面的用户画像，帮助工作室更精准地为用户提供个性化服务，提升用户体验。而且，集团总部能够快速且自动地获得全局的运营信息，而无须等到各个业务部门提交月度报表之后再手工合并和审核。通过大数据平台的建设，在2012年和2013年被评为最差劲体验游戏公司、营收逐年下降的EA，一举华丽转身，2014年被评为最佳体验游戏公司之一，2015年更是创下43亿美元的营收历史新高。本书作者之一宋文欣作为主要技术和团队负责人带领了EA大数据平台团队的组建以及该平台的设计和建设。第16章将详细描述其类似于Supercell的平台的建设历程。1.1.2 Twitter的数据驱动Twitter是硅谷社交三驾
28、马车之一，其陌生人/公开社交与Facebook的熟人/私有社交、LinkedIn的职场社交都对互联网产生了极大影响。这三驾马车出现于20062008年，在时间上与此相耦合的一个现象是大数据的发展。Facebook成立于2004年，Twitter成立于2006 年，LinkedIn成立于2002年（但发展期是20062010年），而作为大数据的启动项目，Hadoop的首发时间是2006年。熟悉大数据早期发展历程的业内人士都知道，虽然Hadoop起源于Google，由Yahoo!开源，但是Facebook、Twitter和LinkedIn却是硅谷早期推动大数据发展的核心力量，Hive、Pig、HB
29、ase、Mesos、 Kafka、Spark、Storm、Thrift、Presto、Parquet以及其他很多现在广泛使用的大数据组件，都是由这三家公司开源或提供最早的企业级应用和支持的。究其原因，除了这几家公司的工程师文化和对开源的推崇之外，更重要的是实际业务的数据驱动需求，因为它们都需要通过分析海量的数据来推动产品研发、用户拓展和核心营收的增长。以Twitter为例，整个公司的管理都基于数据驱动的理念，而其底层支撑是一个全局共享的大数据平台。从CEO需要的BI部门实时业务报表、广告部门的精准定位、产品部门的个性化推荐，到用户拓展部门的增长黑客技术、反欺诈部门的异常监控、研发部门的实时产品
30、反馈、运维部门的智能运维，相关的数据应用都通过统一的数据工具运行在同一个大数据平台之上。整个平台中的数据能力共享和复用随处可见：产品部门研发的用户画像可以被广告部门用来精准定位目标客户，社交图谱被用来实现用户拓展；反欺诈部门的机器人识别功能被广告部门用来识别恶意点击，被BI部门用来精确统计日活用户；广告部门开发的实时数据处理体系被产品部门用来提升推荐的实时性；诸如此类。公司从2011年的300人发展到2014年的4000人，大数据平台从80台服务器的单纯Hadoop集群扩展到8000台服务器的核心数据处理平台， 都没有出现数据孤岛、应用孤岛及重复造轮子的问题。更为重要的是，因为有了强大的数据能
31、力核心平台，Twitter的产品迭代速度得到大幅提升。在2011年以前，开发和发布产品的流程非常冗长，产品经理需要到各个部门调研可以使用的数据，并协调数据的生产化问题。在产品推出之后，需要专门的数据工程师支持，定制单独的数据看板和报表才能拿到产品的反馈。在大数据平台逐渐完善之后，产品经理可以直接在平台上探索现有的数据和各种API，与研发人员合作使用各种数据服务快速形成产品原型，然后通过数据平台提供的测试框架快速发布测试，在发布后可以直接通过平台提供的数据看板查看用户反应，而无须自己编写程序。整个产品的开发和迭代流程从以月计改为以周计，活跃用户数也从2011年不到1亿增长到2014年接近3亿。本
32、书作者之一彭锋作为Twitter架构师委员会中负责大数据体系的高级架构师，在大数据平台的建设中负责架构设计和项目审计，经历了从80台机器的Hadoop集群到8000台服务器集群的整个建设历程。本书会穿插介绍Twitter大数据平台建设的一些思路和经验。1.2 什么是数据中台阿里巴巴提出的数据中台源于Supercell的实践。从上面介绍的两个典型硅谷大数据平台的实践来看，它们的思路及效果与Supercell的“数据中台”类似：中台提供数据能力的共享和复用，前端业务部门可以快速获得全局的数据洞见及现成的数据工具，快速推出由数据支持的产品。那么，数据中台到底与我们常说的大数据平台有何区别和联系？ 要
33、回答这个问题，首先必须明确地定义数据中台这个概念。1.2.1 数据中台建设的目标要定义数据中台，首先要明确数据中台建设的目标。虽然数据中台有新瓶装旧酒的嫌疑，但是阿里巴巴提出的数据中台要解决的问题还是清晰且真实存在的：各个部门重复开发数据，浪费存储与计算资源；数据标准不统一，数据使用成本高；业务数据孤岛问题严重，数据利用率低。思考试验 以上问题都是真实存在的，但如果我们的大数据平台没有这些问题，还需要数据中台吗？根据数据中台要解决的问题，我们可以确定数据中台建设的终极目标。数据中台首先是一种IT系统，而IT系统建设的最终目标是服务企业，因此数据中台的建设遵循我们常说的以业务为导向的路径。虽然企
34、业的发展目标多种多样，例如阿里巴巴的目标是“让天下没有难做的生意”，腾讯的目标是“以技术丰富互联网用户的生活”，但是这些大目标都有一个共同的子目标，即最高效地实现资源的合理配置和利用，创造最大的企业利润，简单来讲就是精细化运 营，开源节流。从最早的会计系统，到计算机普及时代的信息化建 设，到现在的大数据、数字化转型、智能化，都是服务于这个目标 的。特别是在网络时代，很多产业形成赢家通吃的局面，企业更需要比竞争对手先行一步，在激烈的市场竞争中占据先机，获取更高的利润。因此，建设数据中台的最终目标是通过高效的数字化运营，实现“快速市场响应，精细化运营，开源节流”。数字化运营是让企业在市场竞争中取得
35、相对优势的必要手段，其目标是让企业做到以下几 点：比对手更早洞察市场的动向；比对手更了解用户的反应；比对手成本（包括生产和管理成本）更低；推出比对手的产品更符合用户需求的产品；比对手更快地将产品推向市场；比对手更快地迭代产品。值得注意的是，这里的重点是相对优势，也就是与市场常态相比的优势。例如，如果市场中的参与者都采用粗放式管理，那么率先实现信息化的企业就比其他企业更有优势。实际上，信息化已有近30年历史，不同行业的信息化水平有些差异。例如，银行、保险这些主要与数字打交道的行业的信息化水平相对领先，而制造业、农业的信息化水平则相对滞后。一般来讲，相对优势都是针对本行业而言的，因此信息化和数字化
36、的落地程度主要与行业相关。在完成初步的信息化之后，如果想比其他企业更有优势，企业就需要有更强大的信息化系统，也就是大数据系统，其建设初衷是获得更多的数据以及更快、更全面的市场反馈。然而现在的情况是，很多企业虽自称拥有大数据系统，但其效果并不是很好，于是就产生了数据中台建设的需求。不管叫不叫数据中台，所有数据工具的建设目的都是从数据中提取价值来支持更有效的数字化运营。这里所说的数据价值又被称为 “可指导行动的洞见”（Actionable Insight），其重点之一是可指导实际的商业行为，重点之二是洞见，即在建设这个数据工具之前无法得到或发现的知识。二者缺一不可：如果不能指导实际行动，创造实际价
37、值，那么这个数据工具以及从中产生的知识就是无用的；如果不是新发现的知识，那么就没有必要花大价钱来建设这个数据工具。说到底，数据工具的建设要用ROI（Return On Investment，投入产出比）来衡量。数据中台的出现，很大程度上就是因为原有大数据系统建设的ROI不尽如人意。根据所指导的行动的领域，“可指导行动的洞见”可分为两类（参见前面数字化运营的目标）。商业智能（Business Intelligence）：也叫数据驱动的决策，也就是要有对业务更深层次、更全面、更多维度、实时性更强的洞见，从而指导机构的运营。这是给实际数据使用人员使用的，一般表现形式为各种报表、看板、BI查询工具、大
38、屏等。数据驱动的应用（Data Driven Application）：可以实现由数据驱动的业务应用（参见3.2节对数据驱动的介绍）。与传统固定行为的应用不同，数据驱动的应用通过分析各种数据（用户行为、市场数据、第三方数据）来决定应用的行为。其中一般都会涉及对数据的复杂分析，需要使用机器学习、人工智能（AI）算法来从数据里发现模型，然后用模型来指导应用行为。我们一般说数据的用途就是BI和AI，这也是传统大数据平台和数据仓库建设的目的。从这个角度来讲，数据中台与传统大数据平台和数据仓库的建设目的是一致的。但是数据中台有一个比传统大数据平台和数据仓库层次更高的要求：实现数据能力的全局抽象、共享和复
39、用，从而提高数据价值实现的效率和ROI。可以说，数据中台强调的是大数据平台和数据仓库的建设方式。虽然大数据平台和数据仓库也强调数据能力的抽象和复用， 但是它们并没有从方法论、工具和流程上强调如何支持和要求数据能力的抽象、共享和复用。传统大数据平台提供的主要是各种大数据组件的安装和运行，数据仓库建设主要集中在业务的建模和数据的清晰度上，二者的功能都是数据中台需要的。数据中台需要在它们之上提供整套工具、流程和方法论来实现数据的抽象、共享和复用。基于上面的分析，我们可以确定数据中台建设的目标：通过提供工具、流程和方法论，实现数据能力的全局抽象、共享和复用，赋能业务部门，提高实现数据价值的效率。1.2
40、.2 如何实现数据中台建设的目标在明确了数据中台建设的目标之后，下面我们以EA的实践为例， 看看数据中台如何实现这些目标。第一，实现这些目标必须有相应的数据能力，也就是从数据中产生价值的能力。如前所述，数据的价值一般从两方面体现：数据驱动的决策（BI）和数据驱动的应用（AI）。从原始数据到数据产生价值，中间有一个很长的链条，需要的工具都是提供数据能力所必需的。数据中台（包括底层的大数据平台和数据仓库）应该提供高效的工具来支持这个链条中的所有功能。例如，在EA，各个游戏工作室都会用统一的大数据平台来完成用户行为分析、反欺诈、动态定价等一系列关键的数据驱动的功能。这些功能无法用预先设计好的算法或程
41、序来完成， 必须根据实际数据采取相应行动才能实现。这些都是数据能力的典型代表。第二，要实现这些目标，必须完成全局的数据汇聚和治理。这就需要有统一的数据规范，使数据生产者、数据消费者通过这个规范达成共识。例如，EA大数据团队花了一年时间整理出像字典一样厚的数据规范，形成连接生产数据的游戏工作室与消费业务数据的分析部门的桥梁。比如，游戏里有一些简单的代码，表示的是战车、手榴弹、手雷、机关枪或冲锋枪等武器，而业务分析部门通常是看不懂的。另外，各游戏工作室传上来的游戏数据格式都有统一的规范， 有一些是通用的基础指标，还有一些是不同游戏自带的特殊数据。有了这种统一而详细的数据规范标准，各业务分析部门就可
42、以轻松整合所有的游戏数据，形成公司层面的数据资产，然后对其进行挖掘和分析，得到各自需要的有价值数据。第三，企业必须高效完成从汇总好的数据到价值的转换，需要进行数据能力的抽象，然后实现能力的共享和复用。这个过程有两种实现方式。一种是由大数据部门做顶层设计来实现。举例来讲，不少游戏都存在作弊玩家，他们通过创建僵尸账号来收集游戏币，然后在黑市上转卖这些游戏币，这会给游戏公司带来巨大损失，每个月可能会损失超百万美元。而大数据部门就要通过顶层设计来解决这类欺诈问题。EA大数据团队设计了一个反向索引的分析系统，各游戏工作室从黑市上买了游戏币以后，只要把这些游戏币的ID输入系统里，就可以通过反向索引查到并清
43、除掉收集这些游戏币的僵尸账号。这个数据能力是各个工作室都需要的，虽然它们的需求会有细微差异，但是大数据平台将其中的共同点提取出来，形成一个通用工具，各个工作室可以配合自己的特定参数来使用。这就是一个从顶层设计来抽象数据能力，帮助业务部门解决问题的例子。另一种方式是一个业务部门开发供自己使用的服务，但发现其他业务部门也需要，于是就对这种服务进行抽象，以供全公司复用。举例来讲，FIFA游戏推广团队有一个需求是，每天通过电子邮件向特定用户群体推送打折券。以往，需要进行很复杂的查询才能得到目标用户的ID，要从几百万个用户中筛选出几百个，而且一天可能只能做一次。FIFA游戏推广团队与大数据团队合作开发了
44、一套标签系统，利用它可以快速定位这几百个用户。比如这个群体是美国加州的用户，年龄在3545岁，年收入为5万8万美元，过去7天平均玩游戏的时间超过1小时，游戏内消费金额为20003000美元。确定这些标签后，几秒就可以完成层层过滤，锁定目标用户群体，然后可以很简单地通过模板将打折券推送给他们，而且这样的操作一天可以做十几次。后来， 别的业务部门也需要这个功能，FIFA游戏推广团队就将这个功能进行了扩展，供其他游戏推广部门使用。这就是业务部门自行开发，然后进行抽象的例子。第四，在实现数据能力的共享和复用的过程中，需要协调复用和效率的矛盾。如果一个业务部门为了满足其他部门复用某个服务的需求而做了大量
45、工作，结果影响到自己的工作效率，这就得不偿失了。这里首先需要有一套平衡的工具和机制，其次是要有能够精确衡量数据能力的ROI，让业务部门有动力共享它们的数据能力。1.2.3 数据中台的定义和4个特点综上所述，我们认为数据中台可以如下定义：数据中台是企业数字化运营的统一数据能力平台，能够按照规范汇聚和治理全局数据，为各个业务部门提供标准的数据能力和数据工具，同时在公司层面管理数据能力的抽象、共享和复用。数据中台与传统数据仓库和大数据平台的最根本差异，就是强调从工具和机制上支持对数据能力的全局抽象、共享和复用。应该说， 数据中台是建立在数据仓库和大数据平台之上的，让业务部门可以更好、更有效率地使用数
46、据的运营管理层。因此，根据我们的定义，数据中台需要具备以下特点。1）能够借助汇聚全局的数据为用户赋能。数据本身就是能力，从某种程度上讲数据比上层的应用更重要， 而且打通的全局数据所提供的价值将超过隔离的局部数据的总和。为了打通数据，在工具层，需要提供全局数据存储、治理分析服务以及数据/应用治理和管理的功能；在业务层，必须让每个业务部门能够方便地依据标准提供相关业务数据，自动与其他部门的数据打通并汇总。从这方面讲，这不是一个纯技术问题，更多的是一个业务问题。例如互联网公司要打造全局的用户画像，需要制定公司的业务相关数据/应用的标准，并要求各个部门的业务应用按照标准采集和存储本部门负责的用户信息，这样中台才能够按照标准处理这些局部信息来形成全局的用户画像。从某种意义上来说，数据标准实际上也是数据能力的组成部分。2）实现数据能力的抽象。数据能力的抽象是数据中台建设中的难点，如何尽可能抽象出通用的功能，又不使抽象的功能过于细碎，这是需要仔细考虑的问题。这个问题有点类似于微服务的拆分，也与编程里抽象出对外API有着异曲同工之妙，拆大了不好，拆小了也有