本书纸版由机械工业出版社于2020年出版，电子版由华章分社（北京华章图文信息有限公司，北京奥维博世图书发行有限公司）全球范围内制作与发行。

版权所有，侵权必究

客服热线：+ 86-10-68995265

客服信箱：service@bbbvip.com 官方网址：www.hzmedia.com.cn 新浪微博 @华章数媒

赞誉

作者简介

前言

第1章　数据中台：信息化的下一站

1.1　数据中台产生的大背景

1.2　数据中台的3个核心认知

1.3　数据中台的3个发展阶段

1.4　开启信息化的下一站

第2章　什么是数据中台

2.1　解码数据中台

2.2　数据中台必备的4个核心能力

2.3　数据中台需要厘清的2个概念

2.4　数据中台VS现有信息架构

2.5　数据中台的业务价值与技术价值

第3章　数据中台建设与架构

3.1　持续让数据用起来的价值框架

3.2　数据中台建设方法论

3.3　数据中台架构

3.4　中台手记（一）：我说服老板立项了

第4章　数据中台建设的评估与选择

4.1　企业数据应用的成熟度评估

4.2　企业数据中台建设的应用场景

4.3　中台手记（二）：打仗前手里得有一张“粮草”清单

第5章　数据汇聚联通：打破企业数据孤岛

5.1　数据采集、汇聚的方法和工具

5.2　数据交换产品

5.3　数据存储的选择

第6章　数据开发：数据价值提炼工厂

6.1　数据计算能力的4种类型

6.2　离线开发

6.3　实时开发

6.4　算法开发

6.5　中台手记（三）：选一个适合自己的技术平台真的很重要

第7章　数据体系建设

7.1　数据体系规划

7.2　贴源数据层建设——全域数据统一存储

7.3　统一数仓层建设——标准化的数据底座

7.4　标签数据层建设——数据价值魅力所在

7.5　应用数据层建设——灵活支撑业务需求

7.6　中台手记（四）：即将开启的数据淘金之旅

第8章　数据资产管理

8.1　数据资产的定义和3个特征

8.2　数据资产管理现状和挑战

8.3　数据资产管理的4个目标

8.4　数据资产管理在数据中台架构中的位置

8.5　数据治理

8.6　数据资产管理与数据治理的关系

8.7　数据资产管理职能

8.8　数据资产管理效果评估

8.9　数据资产管理的7个成功要素

8.10　中台手记（五）：家里的这点家底可得管好了

第9章　数据服务体系建设

9.1　补全数据应用的最后“一公里”

9.2　4种常见的数据服务

9.3　3种常见的数据应用

9.4　数据服务背后的产品技术

9.5　中台手记（六）：解决“数据应用最后一公里”问题

第10章　数据中台运营机制

10.1　数据中台运营效果评估模型

10.2　数据中台运营的4个价值切入点

10.3　数据资产运营

10.4　数据成本运营

10.5　数据中台运营的实践经验

10.6　数据中台运营的要素与口诀

10.7　中台手记（七）：让数据用起来

第11章　数据安全管理

11.1　数据安全面临的挑战

11.2　贯穿数据全生命周期的数据安全管理体系

11.3　大数据平台安全管理技术手段

11.4　中台手记（八）：数据安全！数据安全！数据安全！

附录　6大行业解决方案架构图

这本书的大部分作者曾是阿里数据中台部门的实干者，“干过”是一种很宝贵的实力。今天，他们正在用这套数据中台方法论赋能各行各业的数字化转型，并取得了卓越的业务效果。撰写此书是他们践行“让数据用起来”这一使命的又一尝试，将为各行各业的数字化转型的探索者和参与者提供体系化的指导。

——谢世煌　阿里巴巴集团联合创始人/

湖畔山南资本创始人

未来的企业家都应该关注数据的应用，但不是哪个企业都适合建设数据中台。要了解数据中台就从这本书开始吧，因为作者们都是经验丰富的一线实践者。

——邱昌恒（卜鹰）　鲲腾基金创始合伙人/

原阿里集团副总裁

大数据的本质是数据的融合，把原本各自孤立的数据互相关联、融合，通过抽象、加工构建数据资产标签类目体系，从而赋予数据更深层次的语义和价值，洞察事物的本质。大数据背景下的数据突出了数据的人本特性、数据的充分利用，不仅极大地发展了生产力，同时还将深刻地改变生产关系。

本书理论研究和实践应用并重，对于破解当前的信息化发展难题具有非常重要的现实意义。本书会为所有想要了解数据中台丰富内涵的读者，以及从事数据治理的技术和管理人员带来深刻的启发，指导他们的实践和创新。

——周傲英　华东师范大学副校长/数据学院教授/博导

数据中台是企业数字化转型的战略选择，是数字化时代对企业的组织重构、流程再造与技术升级。数据中台并非一个简单的平台，而是对海量数据进行采集、存储、计算、加工与融合的产物。数据中台旨在消除数据标准和口径不一致的问题，实现面向应用的数据共享。数据中台让数据与业务分离，实现面向客户需求的弹性化试错与快速迭代，为客户提供高效服务。

——金小刚　浙江大学计算机科学与技术学院研究员

借助“互联网+”和“智能+”，人类社会正以前所未有的速度向智能时代前进。在这个进程中，数据成为宝贵的资产，数据资产管理与数据服务能力将决定政府管理与社会服务的效率，也影响企业竞争的胜败。如何应对挑战、占尽先机，本书将带给你别具新意的解读。

——陈强　上海工程技术大学计算中心教授

当各行各业的数据累积到一定规模时，数据存储、管理、挖掘、应用等新技术就能帮助我们“把握现在，预知未来”。数据中台就是这样一套让数据持续用起来的机制，能够助力企业的数字化转型。

——魏凯　中国信通院云计算与大数据研究所副所长

因为工作的原因，我经常与国内外众多行业的管理者、数字化的实践者和同行们交流，其中数据中台这个话题谈论得非常多。很多人在深度地研究和实践，不仅产出了很多原创的思考和文字，而且有越来越多的实践案例。作为数据中台领域的布道者，我相信数据中台将有助于推动中国的数字化转型，同时，我也相信这本书将会给数据中台领域的实践者带来有意义的启发和思考。

——史凯　ThoughtWorks中国区数据智能事业部总经理

数据是数字经济的“石油”，但数据的价值不仅在数据量，更在于如何让数据有效释放能量。数据分析能力是让“石油”精炼进而充分“燃烧”的技术，“数据中台”更是当前支持数据分析能力提升的技术热点。这本书系统、全面地讲述了“数据中台”的构建方法论，阐述了从IT到DT的发展方向，从技术实现到体系建设，可谓面面俱到，充分体现了“数据中台”的业务价值和技术价值，为企业开展“数据中台”建设提供了很好的规划蓝本。架构重在实践、贵在落地，相信本书能够为业内人士提供很好的指引。

——付晓岩　建信金融风险合规法律部副总经理/

《企业级业务架构设计》作者

随着DT时代的到来，如何让内部数据助力企业数字化建设已经成为各公司必须面对的问题，而最近大火的数据中台正好迎合了这一历史发展趋势。本书的作者们结合自己的中台建设经验，为读者讲述了数据中台的概念、架构、开发、建设、管理、服务、运营、安全等内容，深入浅出，娓娓道来。

——韩锋　宜信数据库开发与管理主任工程师

有10余年大数据领域从业经验，擅长数据建模、海量数据产品架构设计与实现。原阿里巴巴集团大数据专家，曾在阿里巴巴集团负责消费者数据标签体系、DMP平台等大数据项目设计与实施。2015年以创始人身份组建阿里巴巴集团“11维数据创新工作室”，探索数据创新与数据商业化。

2016年6月离职，联合创办数澜科技，在数澜科技先后负责技术部、咨询服务部和地产事业部。

有10年大数据平台规划、数据安全交换使用、数据应用场景建设方面的实践经验。曾任职于阿里数据平台事业部、阿里云数据事业部，负责阿里数据能力及平台的行业客户赋能，并打造行业的数据共享交换，是ID-Mapping体系能力构建及服务化的核心参与者、数据交易模式的早期探索者。

数澜科技联合创始人，负责管理公司产品技术团队，为客户输出构建和经营数据中台的能力。基于数据中台建设的实践经验，带领团队打造一站式数据应用基础设施数栖，并完成多家行业龙头客户基于数栖的数据中台建设。

曾任阿里巴巴数据产品专家、数据创新梧桐工作室负责人等。对大数据资产设计、资产服务、资产应用在实践的基础上形成了一套完整的数据标签类目体系方法论，擅长对各种复杂业务场景进行需求拆解、数据抽象和数据应用建模，关注采用大数据方法切实解决场景痛点，提升业务效率。

20年企业信息化工作经验，积累了丰富的信息化内部运营、解决方案销售及交付等方面的实践经验。拥有MBCI、CISSP-ISSMP、CGEIT、COBIT 5、ITIL Expert、P3O等国际专业资质证书。曾任职华为ICT规划咨询部，面向企业、政府提供“以数据为核心，聚焦业务场景和价值”的流程信息化与数字化转型规划和落地咨询业务。

有10余年数据产品经验，曾任阿里巴巴集团数据平台产品与运营部负责人，是营销、零售和医疗健康等领域数据应用的探索实践者，专注于企业大数据资产化及应用增值。

10余年数据行业经验，擅长业务架构、数据架构、技术架构的规划和落地实施。曾在阿里巴巴担任DBA，后参与阿里数据中台建设，拥有用户识别、标签设计、动态数据组织等多个发明专利。

2017年加入数澜科技，负责带领解决方案团队，推动数据中台在零售、地产、金融等行业以及综合性集团的落地。

15年信息化和大数据行业从业经验，具备广阔的知识面、丰富的咨询经验，擅长为客户提供创造性的解决方案，尤其擅长数据治理方面的咨询规划和产品设计，服务过数十家政府和大中型企业客户。

“一切业务数据化，一切数据业务化”，回顾几十年的中国企业信息化发展历程，就是“业务数据化”的过程——企业持续在IT方面进行投入和建设，不断将发展过程中业务和经营管理端的各种能力以数据形态沉淀下来。而接下来的“数据业务化”则是将已经成为资产的数据作为生产资料融入业务价值的创造过程，使之持续产生价值。

但是随着DT时代的来临，一路高歌、突飞猛进的企业信息化建设却开始出现诸多发展瓶颈和痛点。

首先，随着信息化的深入，在传统烟囱式IT建设方式下，企业独立采购或者自建的各种企业信息系统，在内部形成诸多数据孤岛；而在互联网、移动互联网背景下，服务号、小程序、O2O平台等新模式下产生的外部数据与传统系统的内部数据无法互通，这进一步加剧了数据孤岛问题……系统多样性和多态性，增加了企业IT架构的复杂度。

其次，随着多云环境的出现，硬件基础设施从IT时代的服务器演变成DT时代的“云”，多数企业将选取多云策略，以避免被单一云厂商锁定，且多云的使用可以让企业IT架构更灵活、更符合自身情况。但这也让企业IT架构变得更为复杂，底层数据的互联互通成为困扰企业发展的痛点之一。

因此在传统企业底层IT架构下，新旧IT系统中沉淀的数据之间难以打通，而在多云环境中，企业内外部数据亦难以快速连接。分散各处难以融合的数据，无法很好地支撑企业经营决策，也无法很好地应对快速变化的前端业务，如何突破发展瓶颈，构建适应新时代的企业IT架构，以阿里、华为等为首的国内顶级公司开始提出“数据中台”的概念。

在笔者们看来，数据中台是企业数字化转型的必然产物。在企业IT架构日益复杂的今天，亟须通过一套机制，联通传统IT架构和各类数据，融合新老模式，整合孤岛数据，沉淀数据资产，快速形成数据服务能力，为企业经营决策、精细化运营提供支撑，这套机制就是数据中台。

DT时代数据中台的使命是“让数据持续用起来”，它的一个根本性创新就是把“数据资产”作为一个基础要素独立出来，将成为资产的数据作为生产资料融入业务价值创造过程，提供推动企业发展源源不断的生产力。

笔者们认为，数据中台作为整个企业各个业务所需数据服务的提供方，通过自身的平台能力和业务对数据的不断滋养（业务数据化），会形成一套高效可靠的数据资产体系和数据服务能力（数据资产化和资产服务化）。这样当出现新的市场变化，需要构建新的前台应用时，数据中台可以迅速提供数据服务（服务业务化），从而敏捷地响应企业的创新。业务产生数据，数据服务业务，业务在阳，数据在阴，阴阳互补，形成闭环。

值得一提的是，数据中台不仅仅是一种技术平台，倘若仅停留于此，就完全忽略了从IT到DT的本质变化是“围绕数据资产进行价值的持续积累和释放”。单纯增大技术投入和人才投入无法保障企业经营效能的持续提升，只有站在数据价值观和方法论的高度，才可能系统性解决企业经营发展中关于数据的诸多问题。谁能率先解决面向数字经济特征的全新数据价值观和方法论的问题，并在其指引下打造出平台级能力，谁就能真正意义上帮助企业把数据用起来。

因此，本书重点落笔于数据中台建设方法论体系的阐述，这也是笔者们多年大数据领域从业经验以及多个数据中台建设经验总结所得。希望这套数据中台建设方法论能为计划进行数字化转型，或已经在数字化转型之路上奋力前行的企业决策者、业务推动者和执行者，提供认知升级的有益借鉴，帮助企业结合自身特点，在战略规划牵引下，从组织、保障、准则、内容、步骤等五个层面全面考虑，建立起一套可持续运行的中台建设机制，以保障数据中台建设实施如期完成，从而加速企业的数字化转型进程。

2019年是数据中台爆发的元年，笔者们认为，数据中台必将依循从概念引爆到迭代试错，再到规模复制的认知升级路径，从行业头部企业普惠至更多中小企业，成为数据应用的“基础设施”。未来，每个企业都会像20年前上ERP、5年前上云那样，标配自己的“数据中台”，为企业数字化转型奠定坚实基础。而作为国内最早的一批数据服务创新者，笔者们希望能将过去十余年沉淀的数据认知和行业经验，与更为广泛的行业人士分享、碰撞、交流，并在此过程中实现认知升级，从而更好地增援企业未来，提升企业硬实力，这就是从2019年5月起，笔者们历时半年撰写本书的初心与梦想。

本书的写作历程是一次共创与感恩之旅。数澜三年，与百家行业头部客户共建数据中台，本书虽只有薄薄数百页，但却承载了数澜与客户合力共创的千余个日日夜夜的思考与探索。感恩在与中信集团、万科地产、兴业银行、百果园等诸多客户共创中沉淀的数据认知与实战经验，让我们得以不断思考“让数据用起来”的真谛与本质，而唯有将这些思想的火花具象成文，集结成册，分享给更多数字化转型之路上同行的人们，方不负大家对我们的期望和厚爱！

这还是一次自我超越之旅，非常感谢机械工业出版社华章公司的策划编辑杨福川老师、责任编辑罗词亮老师、美术编辑王建敏老师，他们的鼓励与指导点燃了我们心中的梦想，让我们这群拙于表达的技术人，竟产出了近20万字的中台理论知识与实践经验总结。半年前看似不可能完成的任务，我们坚持了下来，并沉淀下了多年工作认知和经验思考，于我们自身来说是一份特别珍贵的精神财富。

这更是集体智慧的结晶，感谢赵东辉、谢辉、白松、蔡勇剑、黄飞、黄耐寒、贾松、罗玲、李舵、李远泽、秦文艺、孙昂、陶胜刚、张梦琴等多位数澜专家，他们奋战在数据产品、开发、算法、咨询、治理一线，在异常繁忙的年中冲刺季，挤出时间为本书撰文，可谓字字珠玑；感谢徐锦、谭琼、邵雪、杨莎莎、朱清漪、程国强、李德亮、陶丽婷等组成的内部编委会，十年经验，四月烧脑总结写作，两周封闭萃取，杭京深三地联动，通宵达旦，激情燃烧，让专业的技术术语鲜活起来，让抽象的思维认知灵动起来，让本书逻辑更清晰明了，更具有可读性与吸引力！

数据中台已经掀起了幕布的一角，幕布后面的精彩世界需要政府、产业、行业、领先企业共同激荡演绎。让我们走进数据中台的世界，共同描绘属于我们的新纪元！

经过几年的沉淀和酝酿，数据中台已经成为新的风口。大家好奇它的过去，希望一窥它的全貌，憧憬它的未来，“让数据用起来”是驱动数据中台发展的原动力和大家为之奋斗的目标。本书的重点在于揭示数据中台全貌并分享实战经验，本章则尝试从多个视角梳理数据中台产生的大背景，希望与读者一同感受气势磅礴的时代大潮交汇在数据中台这个点的始末，并抛砖引玉，提炼数据中台应该成为共识的几个认知，展望数据中台应该有的发展阶段，让读者自己形成对数据中台的构想，做好准备与我们共同开启数据中台之旅。

时光机回到公元2019年9月，中国IT界正在掀起一股新的汹涌大浪，“中台”这股技术之浪正在席卷IT界的每个角落，并经由IT工厂人员和各界媒体传导至各个行业。数据中台在DT时代的大背景下尤为引人注意，一些先知先觉的企业在讨论和探索数字化转型，谈论有关“数据中台”的概念，有人认为这是新一波的厂商向甲方企业收“智商税”的概念泡沫，有人认为这是给予CIO影响力的权柄，也有人认为这是企业应对“危”与“机”的快速创新利器。利用数据进行创新，看似机遇近在眼前，但各种问题又充斥在每个相关人士的心中。

“什么是数据中台？”

“数据中台有什么用？”

“什么样的企业适合建数据中台？”

“应该怎样保证数据中台的效果？”

“怎么才能说服我企业的董事长和CEO同意立项数据中台？”

“如何才能保证企业数据不被滥用，又能被开发出价值？”

“在我的行业里，有没有可以参考的成功的数据中台案例？”

“需要多长时间和多少钱才能建起来？建完之后，如何运营才能创造出价值呢？有没有持续优化成本的办法？”

风起于青萍之末，浪成于微澜之间。那么数据中台之浪，又成于哪一朵微澜之间呢？

本书的作者们都是在数据领域里摸爬滚打十余年的老数据人，我们将与各位读者一起穿透时光的迷雾，去追溯数据中台之源，回顾25年的IT到DT的演进史，畅谈“数据创新与数据中台”的实践心路，用不太出彩甚至有点干巴的技术文笔，梳理“让数据用起来”的数据中台机制，回答“数据中台百问”，为在数据创新之路上的读者们贡献一点力量。

1996年8月，爱特信信息技术有限公司成立；1998年2月，爱特信推出搜狐；2000年7月，搜狐公司正式在美国纳斯达克挂牌上市。

1997年6月，网易公司成立；2000年6月，网易公司正式在美国纳斯达克挂牌上市。

1998年12月，新浪公司成立；2000年4月，新浪公司成功在美国纳斯达克挂牌上市。

而在1998年至2000年间陆续成立的腾讯、阿里、百度在十年之后接过中国互联网的大旗，形成了以BAT为首的新一轮互联网化浪潮。

2015年3月5日，国务院总理李克强在政府工作报告 ^[1] 中提出：“制定‘互联网+’行动计划，推动移动互联网、云计算、大数据、物联网等与现代制造业结合，促进电子商务、工业互联网和互联网金融健康发展，引导互联网企业拓展国际市场。”

2019年3月5日，国务院总理李克强在政府工作报告 ^[2] 中提出：“推动传统产业改造提升。围绕推动制造业高质量发展，强化工业基础和技术创新能力，促进先进制造业和现代服务业融合发展，加快建设制造强国。打造工业互联网平台，拓展‘智能+’，为制造业转型升级赋能……促进新兴产业加快发展。深化大数据、人工智能等研发应用，培育新一代信息技术、高端装备、生物医药、新能源汽车、新材料等新兴产业集群，壮大数字经济。”

从1995年到2015年的20年间，互联网科技改变了众多面向个体用户端“2C”的生产关系，通过构建线上平台，方便了人们的衣食住行，丰富了人们的生活体验。而在同样的时间里，在企业内部有一群为了企业生产力而奋战的技术人士，他们利用IT技术提升企业内部的生产力。2014年，马云先生正式提出“DT（Data Technology）”的概念，“人类正从IT时代走向DT时代”。他认为，IT时代是以自我控制、自我管理为主，而DT时代是以服务大众、激发生产力为主。这两者之间看起来似乎是技术的差异，但实际上是思想观念层面的差异。

同样也是在这一年年初，阿里内部的数据平台事业部正在大刀阔斧地建立整个集团的数据资产，笔者们也很有幸深度参与其中，构建了多笔数据资产，此为题外话。

2015年，“互联网+”行动计划的提出，让企业内部IT与企业外部互联网思维产生火花，云和SaaS形态的应用开始出现，从IT到DT正式有了广泛的落地实践。

1995年到2015年，互联网科技在中国从萌芽到提出“互联网+”行动计划，用了20年时间。从2015年“互联网+”提出到2019年“智能+”提出，用时仅4年。我们惊叹于这演进的速度之快，就像一个常常被提及的例子：“从整个地球史来看，人类科技进化速度的陡峭曲线，可以类比成一个猿人扔起一根骨头，等掉下来的时候骨头已经变成了火箭。”

回溯“数据中台”这个在中国被创新和实践落地的产物，就不得不去看它发端的企业——阿里巴巴。

笔者们认为阿里的贡献巨大，主要有两个原因。

2014年阿里从芬兰Supercell公司接触到中台概念后，在集团内部积极践行，开创了“大中台、小前台”的组织机制和业务机制，通过高效、统一的后方系统来支持前端的机动部队，提高作战效率，减少冗余投入。2018年，中台概念开始逐渐深入互联网企业。

·2018年9月，腾讯宣布新成立云与智慧产业事业群（CSIG）和技术委员会，后者将负责打造技术中台。

·2018年11月，阿里云事业群升级为阿里云与智能事业群，并开始对外输出中台能力。

·2018年11月，美团被曝正在打通大众点评、摩拜等各业务间的数据，构建数据中台。

·2018年12月，百度调整组织架构，高级副总裁王海峰同时负责基础技术体系（TG）和AI技术平台体系（AIG）。此后，王海峰曾在公开场合表示，打造技术中台是百度调整组织架构的战略方向之一。

·2018年12月，京东进行了有史以来最大幅度的组织架构调整，增设中台部门。京东商城CEO徐雷还在企业年会上强调：要将中台提升为“永不停歇”的超级引擎。

比如，持续提倡：“未来，数据将会是生产资料，计算是生产力，互联网是生产关系，智能时代是基于这些改变而随之发生的巨大的社会变革。未来30年，智能技术将深入到社会的方方面面，改变传统制造业，改变服务业，改变教育、医疗，所有的生活会因数据、计算而改变。IT让20%的人受益，而DT时代和AI时代的数据技术会让80%的人受益，这就是这个世界未来巨大的机会所在。并进一步落地为城市大脑、ET（Evolutionary Technology）系列。”

2016年10月，云栖大会上城市大脑首次亮相。

2017年3月，云栖大会深圳峰会推出ET工业大脑和ET医疗大脑。

2017年6月，云栖大会上海峰会推出ET环境大脑。

就像ET命名本身的科幻性隐喻，阿里所倡导的数据理念和实践犹如外太空的智慧传递，广泛而又深刻地影响着我们这个社会。

华为是推动中国信息化进程的另一个时代巨人，华为在CT（通信技术）领域成长为国际知名企业，进而转入IT（信息技术）领域和移动终端领域，都取得了举世瞩目的成绩。华为自身独特的流程信息化实践已成为传统行业高效利用信息化、加速数字化转型的问计首选。

笔者们认为，华为对于产业数字化转型的巨大贡献在于其基于一套创造性的“管理架构、流程与IT支撑”的管理体系，在研发、生产制造、供应交付、销售、财经等领域进行持续不断地数据管理和数据应用实践，沉淀了完整且成熟的数据管理相关流程、管控机制、组织建设、人才保障、平台建设、使能服务等体系和机制。在多业务、超大规模和全球化分布式管理的环境下做到了“以数据使能业务”，帮助华为公司在人员不显著增加的情况下，收入、利润、现金流持续有效增长。

2016年华为提出了数字化转型战略，当时希望通过数字化变革重塑华为的商业流程。公司由此提出“+互联网”的概念，希望利用先进的数字、数据技术，改造华为业务流程，致力于率先实现ROADS（实时、按需订阅、在线、自助、社交）体验并成为行业的标杆。

2018年华为建立了数字化转型实践中心（DTPC）并正式投入运营，与运营商一起开展数字化转型的实践探索和能力构建。提出统一的数字化平台必须具备以下特征：充分协同并融入业务流程，统一数据模型并可平滑交换数据，云原生和能力开放，以及智能化。 基于该数字化平台，与内外部生态协作创新，可以快速提供最佳解决方案以满足客户需求，实现商业敏捷。

对于数据中台，虽然华为公司内部流程的IT架构中没有明确的提法，但是华为在对外提供的解决方案中已不断出现“数据中台”字眼，致力于打造信息化、自动化、智能化“黑土地”的华为势必要融入数据中台的洪流之中。通过以下几则有代表的信息，我们可以从侧面了解华为的数据中台。

华为云官网：“（华为智慧）园区中台包含数据中台和业务中台；数据中台对园区数据进行标准化建模，园区各单体子系统数据上传到云端后经过数据治理并存储在数据中台的主题库中……”

江苏移动：“江苏公司秉承集团2019年工作重点‘用户满意度领先’和‘降本增效’两大方针，在提升用户满意度工作方面，携手华为整合SEQ平台、MR地理化平台以及性能平台等多个大数据平台，初步实现江苏移动满意度提升数字化中台战略，通过大数据研究、分析及建模，江苏移动与华为联合研发，全国首次将全网用户业务感知地理化，抢占‘用户满意度领先’的网络高地。” ^[3]

国网天津信通公司：“本次验证工作中，天津公司作为国网公司试点单位，负责开展对华为公司数据中台和云平台相关产品的技术验证测试，从而客观论证华为产品全面支撑天津公司泛在电力物联网建设的可行性。测试工作基于华为产品构建的数据中台和云平台，重点针对功能、性能、开放性、扩展性、兼容性，以及对业务应用的支撑能力开展验证工作。” ^[4]

自2015年起，“互联网+”在政府工作报告中经常被提及。政务在国家层面指引和推动中国经济模式的升级和迭代。既扶植了数字产业化，又推动传统行业和产业数字化转型。

2015年制定“互联网+”行动计划。推动移动互联网、云计算、大数据、物联网等与现代制造业结合，促进电子商务、工业互联网和互联网金融健康发展，引导互联网企业拓展国际市场。

2016年落实“互联网+”行动计划。增强经济发展新动力，大力推行“互联网+政务服务”，实现部门间数据共享，发挥大众创业、万众创新和“互联网+”集众智、汇众力的乘数效应。

2017年扩充“互联网+”模式。深入推进“互联网+”行动计划和国家大数据战略，推动“互联网+”深入发展、促进数字经济加快成长，让企业广泛受益、群众普遍受惠。

2018年完善“互联网+”模式。“互联网+”广泛融入各行各业，加强新一代人工智能研发应用，在医疗、养老、教育、文化、体育等多领域推进“互联网+”，深入推进“互联网+农业”，多渠道增加农民收入，促进农村第一、第二、第三产业融合发展。

2019年全面推进“互联网+”。运用新技术和新模式改造传统产业，推行信用监管和“互联网+监管”改革，优化环保、消防、税务、市场监管等执法方式，加快在各行各业、各领域推进“互联网+”。

中国国际大数据产业博览会（简称“数博会”），2015年在贵阳创办，2017年正式升级为国家级展会活动。作为全球首个大数据主题博览会，凭借国际化、专业化、市场化的领先优势，数博会成为全球大数据发展的风向标和业界最具国际性和权威性的成果交流平台。

历届数博会均受到国家领导人的关怀和指示。中共中央总书记、国家主席、中央军委主席习近平向首届和近两届数博会连续发来贺信。国务院总理李克强、副总理马凯、全国人大常委会副委员长王晨先后出席前五届数博会开幕式并致辞。其中，2019年数博会共吸引448家国内外企业参展、举办专业论坛53场，专业赛事6场、各类活动近百场，来自50多个国家和地区的政要、知名企业家、专家学者、协会组织、科研机构及媒体相继参加各类活动，共话大数据前沿热题，共绘大数据发展蓝图，共享大数据时代发展新机遇。

“数字中国建设峰会”2018年在福州举办第一届，中共中央总书记、国家主席、中央军委主席习近平发来贺信，向峰会的召开表示衷心的祝贺，向出席会议的各界人士表示热烈的欢迎。

2019年第二届峰会在福州举行，为期3天的峰会共对接数字经济项目587项，总投资额4569亿元，其中签约项目308项，总投资额2520亿元。

本届峰会的主题是“以信息化培育新动能用新动能推动新发展以新发展创造新辉煌”。峰会定位为中国信息化发展政策发布平台、电子政务和数字经济发展成果展示平台、数字中国建设理论经验和实践交流平台、汇聚全球力量助推数字中国建设的合作平台。

中国国际智能产业博览会（Smart China Expo，简称“智博会”），是经党中央、国务院正式批准，由科学技术部、工业和信息化部、中国科学院、中国工程院、中国科学技术协会和重庆市人民政府共同主办的展会。

2018年5月，经党中央、国务院同意将中国重庆国际汽车工业展与中国（重庆）国际云计算博览会合并，并更为现名；决定智博会从2018年起，每年在重庆市举办一届。

2019年4月，中共中央总书记、国家主席、中央军委主席习近平视察重庆工作时作出“继续高标准办好智博会，深度参与数字经济国际合作”的重要指示，遵照这一重要指示，2019年智博会坚持“智能化：为经济赋能，为生活添彩”的主题，智汇八方、博采众长，重点围绕“会”“展”“赛”及“论”，集中展示全球智能产业的新产品、新技术、新业态和新模式等。

以构建数据资产体系、释放数据资产价值为核心的数据中台被推到了广阔的舞台中央。

[1] http://www.gov.cn/guowuyuan/2015-03/16/content_2835101.htm [2] http://www.gov.cn/premier/2019-03/16/content_5374314.htm [3] http://www.c114.com.cn/wireless/2935/a1093040.html [4] http://www.tj.xinhuanet.com/xhvision/2019-07/23/c_1124787988.htm

数据中台能否从自发的单点状态、媒体热点，变成数字经济的基础、普惠性的数据服务机制，有赖于以下几个认知能否被业界广泛接受，并为之共同努力。

数据中台所包含的数据技术创新可以在成熟的平台型企业内部孕育，技术的创新和融合应用于很多贴近业务的创新应用场景。但数据中台不仅仅是技术平台，倘若停留于此，就完全忽略了IT到DT的本质变化是围绕数据资产，企业面临的主要矛盾是无法解决业务端的灵活性和经营管理稳定性之间的冲突，单纯地增大技术投入和人才投入都无法保障企业经营效能的持续提升。只有秉持数据价值观和方法论，才可能系统性地解决企业经营发展围绕数据的诸多问题，谁能率先解决面向数字经济特征的全新数据价值观和方法论的问题，并在其指引下打造出平台级能力，谁就能真正意义上帮助企业把数据用起来。

人才永远是瓶颈，并且人才的具体定义在动态变化，需要为人才准备成长的土壤。信息化历程中从简单的搭建网站、单功能系统开发，到复杂系统开发、建设、运营，再到新技术引入等都曾经是人才具体定义的重要关注点。在社会范围内，信息化人才天然趋向两类企业：成熟稳定的平台型企业或有成熟平台潜力的企业。企业只有围绕数据中台明确了人才在企业的定位和职业通道，才可能吸引到或培养出拥有业务、数据、分析等综合素养的新型信息化人才，企业在数据中台人才储备上需要尽快做起来。

“让数据用起来”，既是终极目标，也是数据中台要为处于不同数据认知成熟度阶段的企业实现的一个个具体目标。业务不会停滞，信息化不断追求自身的价值，数据部门力图与业务部门具有同等组织地位和话语权，业务部门不断提出新的挑战，政府在加速拉动数字经济建设……在这些因素的共同作用下，结合普惠数据服务按需取用、业务自流程化 ^[1] 、数据自我治理的特点，在笔者看来，数据中台未来会经过以下几个发展阶段。

这个阶段是个过渡阶段。一方面，传统的数据应用过往都是从外往内的（利用外部的技术、数据和资源来服务内部需求）。例如，零售行业要做精准营销，在广告上砸钱，做用户画像分析，利用外部的技术、数据、资源来服务内部需求，但是做完了会发现企业自身没有沉淀，又回到了原点。另外一方面，还是要借助一个个具体的场景化数据应用来推动企业对数据中台的认知，积累各行业（特别是头部客户）的业务和服务经验快速迭代和打造数据中台。

这一阶段的特点是构建数据中台的技术、理念、方法论是可复制的，市场上已有成熟的支撑数据中台高效运转的平台级产品。企业通过规划、建设、实施数据中台能够具备三方面的基础能力：

·数据的多样性、多态性、多云连接能力（汇聚/交换能力）。交换的能力用来解决企业有哪些数据、数据在哪里等问题。

·数据资产化的能力是数据中台建设的关键，包括清洗、加工、治理、安全、质量等工具模块及实施方法论。（说明：能直接作用于业务领域，业务能阅读、能理解的数据才叫数据资产。）

·数据服务化的能力，用数据技术来使用数据的方法。

到了这一阶段，数据中台已经成为企业数据资产的核心能力和基础，通过快速构建数据资产体系，帮助企业真正实现对其全量数据的有效管理。业务和业务流程本身都可以通过适当的颗粒度进行数字化解耦和标准化，企业能够以自我为中心构建更加宏大的产业、行业价值链范围的数据空间和业务空间，以数据编排的方式响应业务需求，彻底颠覆传统的软件工程方式，业务实现自流程化，数据实现自我管理能力。

这里需要引入业务空间和数据空间的基本概念。

·企业业务空间：企业任何一个业务条线从初始设立到日益精细分化，一般都遵循一个共性的演进过程：清晰定义该业务条线内专项业务的“毛细血管”功能体系、建设或升级相应技术支撑系统、生成专项业务数据。当所有业务条线都遵循这个发展规律，纵横交错的业务条线构成了企业实际运营的多维业务空间。企业的业务空间是产生和形成全量数据的根本依据和前提。

·企业数据空间：在数字化时代，任何一家企业都是市场生态中的一个节点，从数据交换的宏观视角来看，任何一家企业的数据全集只是整个市场数据生态空间中的一个子集。从企业自身视角来看，依据数据的生成和交互方式，企业全量数据的数据空间大致由三个维度构成：自主生产和消费的数据、外部数据（含单向外部获取数据和单向对外提供数据）、内外部交互数据。

[1] 此前没有人正式提过这一说法，在与政府、金融客户沟通时经常会提到：当业务能够实现对象数字化、规则数字化、结果数据化时，业务自身的流程也就可以按照规则自由、自行组建和优化了。

数字化需要探寻、挖掘数据的多维度业务价值，数据能力要在组织中孕育继而成为业务能力的一部分，需要摆脱“需求→立项→建设实施→日常运维”的简单模式，深入思考数据的业务本质。

回顾信息化建设的历程，笔者们发现因为企业自身组织变革和建设能力的限制，在相当长时间内会有多种建设模式并存，以数据中台为驱动的建设模式将有可能成为融汇归一的新型建设模式，如图1-1所示。

图1-1　数据中台建设模式融合

以下为4种主要的信息化建设模式：

·软件功能驱动模式：该模式对组织变革和建设能力要求最低，通常以采购和实施成熟产品为主，目标是业务部门直接能用。

·数据治理驱动模式：该模式的目标是针对同一数据不同问题或不同数据同一问题进行分类治理，通常是业务上遇到了难题，立个专项来解决。

·业务能力驱动模式：该模式对组织变革和建设能力要求最高，目标基于企业架构（EA）自上而下开展规划建设，覆盖组织从战略到执行全业务过程，从业务设计到IT实现。该建设模式实施难度极高，通常会形成顶层规划设计和一系列实施项目。

·业务服务化驱动模式：该模式专注于新技术的引入，通常是面向用户提升体验、面向业务拉通资源调度。

上述4种模式在建设数据中台时都可以有效融合，让组织变革和建设能力能够充分支持业务数据化、数据资产化、资产服务化、服务业务化的数据中台建设特点。

2019年是数据中台爆发的元年，除了数澜科技与Forrester共同发布了首部行业白皮书《拥抱数据中台，加速数字化转型》，围绕数据中台的各种展会、发布会、产品也纷至沓来。

阿里、腾讯、华为做的是云计算基础设施，客户要做云计算的时候，他们就会给出解决方案。同样，数据应用也需要基础设施，当企业需要数据应用时，数据中台就会给出整体解决方案，真正“让企业的数据用起来”。

数据中台已经掀起了幕布的一角，幕布后面的精彩世界需要政府、产业、行业、领先企业共同激荡演绎。欢迎走进数据中台的世界。

伴随着云计算、大数据、人工智能等技术的迅速发展，以及这些技术与传统行业的快速融合，企业数字化、智能化转型的步伐逐渐加快。IDC预测，到2021年，全球至少50%的GDP将被数字化，而每个行业的增长都会受到数字产品与服务、数据化运营的驱动。

数字化转型成功的企业，其内部和外部的交互均以数据为基础。业务的变化快速反馈在数据上，企业能够迅速感知并做出反应，而其决策与考核基于客观数据。同时，数据是活的，是流动的，越用越多，越用越有价值。随着数据与业务场景的不断交融，业务场景将逐步实现通过数据自动运转和自动优化，进而推动企业进入数字化和智能化的阶段。

传统IT建设方式下，企业的各种信息系统大多是独立采购或者独立建设的，无法做到信息的互联互通，导致企业内部形成多个数据孤岛。互联网、移动互联网的发展带来很多新的业务模式，很多企业尝试通过服务号、小程序、O2O平台等新模式触达客户、服务客户，新模式是通过新的平台支撑的，产生的数据与传统模式下的数据也无法互通，这进一步加剧了数据孤岛问题。分散在各个孤岛的数据无法很好地支撑企业的经营决策，也无法很好地应对快速变化的前端业务。因此需要一套机制，通过这套机制融合新老模式，整合分散在各个孤岛上的数据，快速形成数据服务能力，为企业经营决策、精细化运营提供支撑，这套机制就是数据中台，如图2-1所示。

图2-1　数据中台定位

本章主要阐述数据中台的定义和核心能力，并澄清几个与数据中台相关的概念，最后总结数据中台建设能为客户带来的业务价值和技术价值。

与许多新概念诞生之初的境遇一样，数据中台目前正处于“定义混乱期”。

有人认为数据中台是云平台的一部分，同时包括业务中台和技术中台；有人认为数据中台是数据的共享、整合和深度分析；还有人认为数据中台是“计算平台+算法模型+智能硬件”，不仅有云端，还需要智能设备帮企业在终端收集线下数据……从服务方到客户方，对数据中台的理解并不相同，如同一千个观众心中就有一千个哈姆雷特。

笔者们有幸见证了数据中台在中国从0到1的全过程，并在其中实践多年，对于数据中台的定义，笔者们认为：数据中台是一套可持续“让企业的数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。 数据来自于业务，并反哺业务，不断循环迭代，实现数据可见、可用、可运营，如图2-2所示。

通过数据中台把数据变为一种服务能力，既能提升管理、决策水平，又能直接支撑企业业务。数据中台不仅仅是技术，也不仅仅是产品，而是一套完整的让数据用起来的机制。既然是“机制”，就需要从企业战略、组织、人才等方面来全方位地规划和配合，而不能仅仅停留在工具和产品层面。

以中国某大型央企集团的数据中台为例，该集团旗下拥有横跨金融、地产、零售的多条业务线。要做数字化转型，不仅是技术问题，更是组织与业务运转模式改变的问题，需要顶层战略规划和组织架构上的改变。这也是为什么各大互联网公司在宣布中台战略时，会伴随着组织架构调整。

图2-2　数据中台是一套“让企业的数据用起来”的机制

每家企业的业务与数据状况各不相同，业务对数据服务的诉求不同，数据中台的建设将呈现出不同的特点，没有任何两家企业的数据中台是完全相同的。数据中台的实施不仅需要一整套技术产品，更需要针对不同业务、数据、应用场景的体系化的实施方法和经验，过程中涉及企业战略、组织、技术、人才等全面的保障和配合。

早在2015年，数字化领域的领先者已经开始从顶层战略设计入手，调整组织架构，协调内外部的利益，更新方法论和认知体系，着手构建数据中台体系。从2018年下半年开始，以数据中台战略为核心的变革潮流席卷互联网行业，然而多数企业对数据中台内涵的认识仍不够全面，导致业务落地和商业创新还是困难重重。

随着业务的多元化发展，企业内部往往有多个信息部门和数据中心，大量系统、功能和应用重复建设，存在巨大的数据资源、计算资源和人力资源的浪费，同时组织壁垒也导致数据孤岛的出现，使得内外部数据难以全局规划。

数据中台需要对数据进行整合和完善，提供适用、适配、成熟、完善的一站式大数据平台工具，在简便有效的基础上，实现数据采集、交换等任务配置以及监控管理。

数据中台必须具备数据集成与运营方面的能力，能够接入、转换、写入或缓存企业内外部多种来源的数据，协助不同部门和团队的数据使用者更好地定位数据、理解数据。同时数据安全、灵活可用也是绝大多数企业看重的，他们期望数据中台能协助企业提升数据可用性和易用性，且在系统部署上能支持多种模式（见图2-3）。

图2-3　企业看重的数据整合和管理能力

数据就像石油，需要经过提纯加工才能使用，这个过程就是数据资产化。

企业需要完整的数据资产体系，围绕着能给业务带来价值的数据资产进行建设，推动业务数据向数据资产的转化。

传统的数字化建设往往局限在单个业务流程，忽视了多业务的关联数据，缺乏对数据的深度理解。数据中台必须连通全域数据，通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系，以满足企业业务对数据的需求， 如图2-4所示。

图2-4　企业看重的数据提炼和分析加工能力

为了尽快让数据用起来，数据中台必须提供便捷、快速的数据服务能力，让相关人员能够迅速开发数据应用，支持数据资产场景化能力的快速输出，以响应客户的动态需求。

多数企业还期待数据中台可以提供数据化运营平台，帮助企业快速实现数据资产的可视化分析，提供包括实时流数据分析、预测分析、机器学习等更为高级的服务，为企业数据化运营赋能。

此外，伴随着人工智能技术的飞速发展，AI的能力也被多数企业期待能应用到数据中台上，实现自然语言处理等方面的服务。数据洞察来源于分析，数据中台必须提供丰富的分析功能，数据资产必须服务于业务分析才能解决企业在数据洞察方面的短板，实现与业务的紧密结合（见图2-5）。

数据中台通过打通企业数据，提供以前单个部门或者单个业务单元无法提供的数据服务能力，以实现数据的更大价值变现。

图2-5　企业看重的数据资产服务化能力

企业期待数据中台能提升跨部门的普适性业务价值能力，更好地管理数据应用，将数据洞察变成直接驱动业务行动的核心动能，跨业务场景推进数据实践。同时，企业对于如何评估业务行动的效果也十分关注，因为没有效果评估就难以得到有效反馈，从而难以迭代更新数据应用，难以持续为客户带来价值，如图2-6所示。

如前所述，数据中台是一套持续地让企业的数据用起来的机制，要想把数据用起来，四个核心能力都需要不断迭代和提升。从战略上来看，汇聚整合、提纯加工、服务可视化和价值变现的能力是数据中台最核心的竞争力， 是企业真正将数据转化为生产力、实现数字化转型和商业创新、永葆竞争力的保障，如图2-7所示。

图2-6　企业看重的数据价值变现能力

图2-7　数据中台4大核心能力不可分割

[1] 本节部分内容源自2019 Forrester数据中台行业白皮书《拥抱数据中台，加速数字化转型》。

如果同时拥有业务中台和数据中台，则数据中台与业务中台是相辅相成的。业务中台中沉淀的业务数据进入到数据中台进行体系化的加工，再以服务化的方式支撑业务中台上的应用，而这些应用产生的新数据又流转到数据中台，形成循环不息的数据闭环， 如图2-8所示。

图2-8　业务中台与数据中台的数据应用闭环

业务中台与数据中台互相促进，为企业业务的发展、管理者更好的决策提供支持。其中，业务中台的存在是为了围绕公司业务运营进行服务，将获取的多维度数据传递给数据中台，由数据中台挖掘新的价值反馈给业务中台，以优化业务运营。

有人可能会有疑惑：数据中台和业务中台的建设是否有先后顺序？

笔者们以为，这两者的建设没有先后之分，主要依据企业的实际情况进行规划。

从数据层面看，业务中台只是数据中台的数据源之一，除此之外，企业还有很多其他的数据来源，如App、小程序、IoT等多源数据，可以将这些数据的价值直接赋能于现有业务或某个创新业务。

从服务层面看，数据中台的数据服务也不一定经过业务中台作用于业务，它可能直接被上层应用系统进行封装，如电商领域的“千人千面”系统。

而从业务中台的角度来看，如果没有数据中台，可以做一些简单的数据处理，如分析和统计等，而通过数据中台赋能，则可以使业务系统拥有“全维度”、“智能化”的能力，譬如推荐、圈人等，系统将从信息化升级成为一个智能化的业务系统。”

不仅仅是业务中台，目前各种中台层出不穷，但笔者们认为中台不是平台，平台可以有很多，可以有营销平台、风控平台、管理平台等，但是中台，一个企业只需要有一个。 现在还有业务中台、数据中台之分，但我们预测未来数据与业务会更紧密地结合，完全融为一体，会统一成“企业中台”。

如何唤醒沉睡的数据资产，把数据真正用起来，以支持自身业务的智能化升级，这是摆在所有传统企业面前的数字化转型难题。因此，对于是否有必要建设数据中台这件事情，似乎并无太多质疑之声，但真要建设数据中台，尤其是落实到具体建设的实操阶段，企业又开始担心，他们最担心的莫过于，建设数据中台是不是要将企业现有信息架构推倒重来。

信息化时代初期，随着公司的业务发展和战略调整，为了更好地支撑业务，企业的信息化系统不知道被推倒重来过多少次，经历了成千上万次取数，也生成了数以千计的报表。伴随着一批又一批的数据人员的成长和离开、行业专家和业务人员的晋升或转型，数据仓库之间的演进也经常是推倒重来，消耗了企业大量成本。

数据中台作为解决企业级数据应用难题的新方案，不是一套软件系统，也不是一个标准化产品。站在企业的角度，数据中台更多地指向企业的业务场景，即帮助企业沉淀能力，提升业务效率，最终完成数字化转型。因此，数据中台与企业现有信息架构不存在竞争关系，不会导致企业现有系统、功能和应用的重复建设。

举个简单的例子，笔者们此前与一家做轮胎制造的上市公司进行过交流，它当时就用到很多个业务系统，比如OA系统、ERP系统、工艺设计与管理系统、物流系统、生产系统等。该企业的一个核心痛点是：“无法准确知道当前的轮胎能否准时或者提前交付”。制造型企业一般处于产业链的中间位置，非终端或者源头端，比如这家轮胎制造企业，它的上游是橡胶提供方，下游是汽车组装商或者汽车零部件厂商。轮胎的及时交付就意味着公司的生命线——稳定的现金流。而影响轮胎能否及时交付的数据变量是散落在所有系统中的，诸如物流的及时性、对生产过程的控制力、是否有重大的经济压力、甲方工艺设计需求的变化等。

在有数据中台之前，他们是怎么做的呢？企业首先需要拉出所有系统数据库中的表，然后再用Excel去做对应关系，整个过程是非常琐碎且耗时的。如果有数据中台体系，可以通过中台机制汇聚相关系统中的原始数据，并且面向轮胎这一公司经营的实体构建一系列场景化的标签特征。同时，通过离线或者实时的数据交互模式，不断更新特征值，将业务场景所关注的数据的价值直接展现出来。

从上面的例子能看出，数据中台在定位上与业务IT系统并不冲突。企业原有的IT系统依旧会根据业务和IT技术的迭代不断升级，依旧对企业的生产运营或者经营管理提供支撑。数据中台的定位则是在数据领域帮助企业不断沉淀数据能力。两者之间的关系是相互依托、相互赋能、相互促进的。数据中台需要IT系统不断提供数据，而IT系统未来更加需要横向、综合的数据特征来支撑。只有形成了数据中台和IT系统良好的配合关系，才能更好地构建企业整体的IT支撑能力。

在后续的章节中，读者会看到一个完整的数据运营闭环。在这个运营闭环中，既有IT系统需要承载的职能，也包含了数据中台的使命。两者具体如何在技术上进行集成，后续也会具体讲解。

在以客户为中心的时代，数据中台对数字化转型具有重要作用，以数据中台为基础的数据系统将位于企业应用的核心，通过数据从企业降本增效、精细化经营等方面为企业带来巨大收益。具体来说，笔者们认为包含以下三个层面：

在以客户为中心的时代，客户的观念和行为正在从根本上改变企业的经营方式以及企业与客户的互动方式。

譬如，数据中台能够汇聚全渠道的数据，在标签管理、营销圈人、效果分析等应用上实现全域的闭环，优化对客户全生命周期的理解。此外，以数据中台为基础，通过数据化运营提升客户留存、复购和忠诚度，也得到诸多企业的认可。

只有依托数据和算法，将由海量数据提炼的洞察转化为行动，才能推动大规模的商业创新。数据中台在通过算法将洞察直接转化为行动、实现大规模商业创新方面的能力，令人瞩目。

另一方面，数据无法被业务用起来的一个原因是数据没办法变得可阅读、易理解。信息技术人员不够懂业务，而业务人员不够懂数据，导致数据应用到业务变得很困难，数据中台需要考虑将信息技术人员与业务人员之间的障碍打破，信息技术人员将数据变成业务人员可阅读、易理解的内容，业务人员看到内容后能够很快结合到业务中去，这样才能更好地支撑商业模式的创新。

此外，数据中台提供标准的数据访问能力，简化集成复杂性、促进互操作性等特性也非常受企业CIO们的青睐。同时，在快速构建服务能力、加快商业创新、提升业务适配等方面，数据中台也将会发挥重要的作用。

在以客户为中心的时代，只有赢得客户的企业才能在竞争中保持优势。企业能否真正做到“客户至上”，并不断提高对客户的快速响应力来满足客户的需求，甚至引领市场潮流，持续推进规模化创新，终将决定企业能否在充满挑战和机遇的市场上发展壮大，长久保持生命力与竞争力。

面对纷繁复杂而又分散割裂的海量数据，数据中台的突出优势在于，能充分利用内外部数据，打破数据孤岛的现状，打造持续增值的数据资产，在此基础上，能够降低使用数据服务的门槛，繁荣数据服务的生态，实现数据“越用越多”的价值闭环，牢牢抓住客户，确保竞争优势。

数字化转型的需求必将催生多元化的数据场景，而多元化的数据场景将会带来以下技术需求，企业数据中台建设势在必行。

针对不同的数据应用场景，需要能够快速应对多数据处理需求，比如：

要保持原来的报表需求，仍需要保持批量离线计算的能力（Hadoop、Oracle RAC）；

针对准实时的指标统计和实时推荐，需要实时流式计算的能力（Storm、Spark Streaming、Flink）；

针对决策类业务如海量人群的圈人需求和ad-hoc需求，需要即席计算能力（Greenplum、Elasticsearch、Impala）；

针对高并发业务场景（如用户画像），需要在线计算能力（MySQL、Redis、Oracle）。

因此，企业需要一个统一的数据中台来满足离线／实时计算需求、各种查询需求（实时查询和ad hoc），同时在将来新数据引擎（更快的计算框架，更快的查询响应）出现时，又不需要重构目前的大数据体系。

根据全国信标委大数据标准工作组发布的《数据管理能力成熟度模型》（DCMM），针对数据标准提到的数据分类主要有主数据、参考数据和指标数据，但根据目前真实的数据建设情况来看，需要对一类数据进行定义和分类，譬如标签名为“消费特征”，标签值为“促销敏感”“货比三家”“犹豫不决”。数据中台能对这类标签进行快速定义和有效管理。

过去的数据应用场景主要为报表需求，注重数据的准确性，但在更多数据场景下，特别是对于标签数据的应用，越来越多的数据是需要不断“优化”的，数据本身没有准不准确之分，比如某个会员是属于促销敏感人群，这个数据其实更多的说的是概率。

企业早期建设的应用数据层ADS（传统数据仓库ODS/DW/ADS）更多是为某个主题域所服务的，如营销域、人力资源域、风控域，而企业在数据应用的时候往往需要打破各个业务主题，会从业务对象主体出发来考虑数据应用，如人（会员、供应商、渠道、员工）和物（商品、仓库、合同），从全域角度设计完整的面向对象的数据标签体系。

传统的架构中，要将数据应用到业务中，通用的做法都是通过数据同步能力，把计算的结果同步给业务系统，由业务系统自行处理，这会带来一个数据管理问题，即无法获取数据在应用场景中的具体价值和热度，整个数据血缘链路也是割裂的。这种方式笔者们认为是复制数据，而不是复用数据。如何快速复用数据，正是可以在数据中台中解决的问题。

数字化浪潮席卷全球，企业正面临着前所未有的挑战和机遇，必须不断加速数字化转型才能生存和保持领先。数据中台能够帮助企业聚合内外部数据，支撑高效的数据服务，最终提升企业决策水平和业务表现。企业期待通过数据中台把原始数据转化为数据资产，快速构建数据服务，使企业可以持续、充分地利用数据，实现数据可见、可用、可运营的目标，以数据来驱动决策和运营，不断深化数字化转型。总结一句话：数据中台是把数据这种生产资料转变为数据生产力的过程。

不能把数据中台简单看作一个项目或产品，建设数据中台要从战略、认知、组织保障等更高的层面做规划。3.2节重点介绍的数据中台建设方法论体系，是笔者们多年大数据领域从业经验和多个数据中台建设经验的总结。希望这套数据中台建设方法论可以起到指引作用，帮助企业结合自身特点，在战略规划牵引下，建立起一套可持续运行的中台建设机制，从而加速企业在数字化转型上的进展。

数据中台的使命就是持续让数据用起来，它的一个根本性创新就是把“数据资产”作为一个基础要素独立出来，让成为资产的数据作为生产资料融入业务价值创造过程，持续产生价值。

数据中台作为整个企业各个业务所需数据服务的提供方，通过自身的平台能力和业务对数据的不断滋养（业务数据化），会形成一套高效可靠的数据资产体系和数据服务能力（数据资产化和资产服务化）。这样一来，当出现新的市场变化，需要构建新的前台应用时，数据中台可以迅速提供数据服务（服务业务化），从而敏捷地响应企业的创新。业务产生数据，数据服务业务，业务在阳，数据在阴，阴阳互补，形成闭环（见图3-1）。

图3-1　业务与数据闭环

这个价值框架融入企业的运营活动中就能支撑数据中台的组织地位：数据中台必须拥有与企业的设计部门、制造部门、销售部门等同样重要的地位 （见图3-2）。

图3-2　数据中台的组织地位

数据中台不是单纯的技术叠加，不是一个技术化的大数据平台，二者有本质区别。大数据平台更关心技术层面的事情，包括研发效率、平台的大数据处理能力等，针对的往往是技术人员；而数据中台的核心是数据服务能力，要结合场景，比如精准营销、风控等，通过服务直接赋能业务应用。数据中台不仅面向技术人员，更需要面向多个部门的业务人员。这在建设过程中要特别注意，不论是由信息化部门牵头还是由业务部门牵头执行数据中台项目，都需要在整个企业内部形成一张有共识的蓝图：数据是企业的战略资产 （见图3-3）。

图3-3　数据是企业的战略资产

对于图3-4所示的数据中台建设方法论体系，需要从组织、保障、准则、内容、步骤5个层面全面考虑，以确保数据中台建设和实施能如期完成。

·1种战略行动：把用数据中台驱动业务发展定位为企业级战略，全局谋划。

·2项保障条件：通过宣导统一组织间的数据认知，通过流程加速组织变革。

·3条目标准则：将数据的可见、可用、可运营3个核心准则始终贯穿于中台建设的全过程，保障建设在正确轨道上。

·4套建设内容：通过技术体系、数据体系、服务体系、运营体系建设保证中台建设的全面性和可持续性。

·5个关键步骤：通过理现状、立架构、建资产、用数据、做运营5个关键行动控制中台建设关键节点的质量。

图3-4　数据中台建设方法论体系

建设数据中台是为了支撑企业数字化、智能化升级，通过全局的维度支撑业务，让企业在市场上更具竞争优势，因此需要从公司战略层面来规划。在中台建设过程中，会涉及所有相关业态、各块资源的协调和推进，这都需要站在更高的层面来考虑。当然，具体在实施过程中，为了能快速迭代推进，也会采取从点到面的突破方法，从某个业务或者某个部门开始，初步构建看到成效再逐步推广，但不影响其作为核心战略的定位。

数据中台是企业级战略，支撑企业数字化转型，涉及企业的方方面面，数据中台战略的执行必然伴随着企业组织保障以及整个企业数据意识的提升。

数据中台的3项目标准则——可见、可用、可运营，不仅可作为企业在数据中台建设中的具体建设指引，也可用来客观评估目前建设内容的完整度。

这3项目标准则的评估细则见表3-1。

表3-1　数据中台建设目标评估表

技术体系分两个层面：大数据存储计算技术和数据中台工具技术组件，技术体系主要关注点是工具技术组件。大数据存储计算技术，比如Hadoop、Spark、Flink、Greenplum、Elasticsearch、Redis、Phoenix等，相对标准，企业只需要进行合理选型即可，并不需要自己建设，而且技术难度很大，企业也不太可能自己建设。数据中台工具技术组件包括数据汇聚、数据开发、数据资产管理、数据服务管控等。数据中台是企业制定和实施数据汇聚、建模和加工规范的场所，也是企业数据体系存储管理的工具平台。通过工具化、产品化、可视化降低技术门槛，让数据能够被更方便地加工使用。

数据中台与大数据平台的最主要区别是数据能更方便地以服务化的方式支撑业务，而这是通过数据中台服务体系实现的。服务体系是通过数据中台的服务组件能力， 把数据变为一种服务能力，比如客户微观画像服务、信用评估服务、风险预警服务等，让数据能够方便地参与到业务中并为业务带去价值。笔者经常听到的数字化转型、数据化经营，就是让业务决策通过数据而不是仅凭经验，需要的正是数据服务能力。每家企业的业务不同，对数据服务的诉求也不同，数据中台无法产品化地提供企业所需的所有数据服务能力。数据中台通过提供数据服务生成、发布、监控、管理功能，帮助企业逐个建立属于自己的每一个数据服务，逐步完成企业数据服务体系的构建。

数据中台在具体落地实施时，要结合技术、产品、数据、服务、运营等5个方面，逐步开展相关的工作，在构建闭环时会多考虑基础设施部分的能力。一旦闭环建设完成，就可以在各个环节不断丰富能力，逐步成为数据应用的完整体系。根据笔者的实践经验，数据中台的建设过程主要通过5个关键步骤来完成，如图3-6所示。

图3-6　中台建设的5个关键步骤

梳理企业的系统建设、已经拥有的数据以及业务特点等现状，了解企业对数据中台的认知，以及相应的数据文化建设情况。点对点地与业务部门、IT部门进行沟通，获取企业的产品和服务信息，形成业务现状调研报告，同时了解目前企业以怎样的组织形态来保证客户的服务能力。详细调研目前企业的IT建设情况和业务数据沉淀情况，比如采用的什么数据库、数据量、数据字段和更新周期等，以便后续更好地设计技术架构。

根据现状形成整体的规划蓝图，形成技术产品、数据体系、服务方式以及运营重点等相关的方案，梳理并确立各块架构。企业信息架构经常谈到的4A，即业务架构、技术架构、应用架构和数据架构都需要在这个阶段进行确认。这4个架构具体介绍如下：

·业务架构：保障数据中台能够适用于企业的业务运管模型和流程体系。

·技术架构：主要是指技术体系中的数据基座，主要根据业务架构近远期规划，对数据的存储和计算进行统一的选型。

·应用架构：特指数据中台应用架构，后面几个关键步骤的内容所依赖的工具主要由数据中台作为平台应用来承接。

·组织架构：主要是保证中台项目的顺利落地需要企业考虑的整体组织保障，其中的角色有业务人员、IT人员、供应商和相关负责人。

结合数据架构的整体设计，通过数据资产体系建设方法，帮助企业构建既符合场景需求又满足数据架构要求的数据资产体系并实施落地。这个步骤涉及数据汇聚、数据仓库建设、标签体系建设以及应用数据建设，其中最关键的是标签体系建设。所谓标签体系是面向具体对象构建的全维度数据标签，通过标签体系可以方便地支撑应用，大数据的核心魅力和服务能力主要就体现在标签体系的服务能力上。

从应用场景出发，将已经构建的数据资产通过服务化方式，应用到具体的业务中，发挥数据价值。将数据资产快速形成服务能力并与业务进行对接，在业务中产生数据价值，实现数据的服务化、业务化。在服务过程中，数据安全是不得不考虑的问题，哪些人能看到什么数字资产，能选择什么类型的服务都是需要严格审核的。

数据应用于业务后，其产生的价值通过运营的能力不断优化迭代，并让更多的人感知到数据的价值点。数据中台建设是一个持续建设和运营的过程，所谓持续建设和运营是指在架构基本稳定的情况下，不断循环第3～5步，多方角色会围绕核心KPI不断挖掘数据和业务场景的结合点，不断根据质量和价值两个点来运营优化。企业通过多个组织之间的配合推进，会逐步形成企业特有的数据文化和认知，这是企业在数字化转型中非常重要但很难跨越的点。

通过前面对数据中台建设方法论体系的介绍，了解了数据中台的行动、保障、准则、内容和步骤。这一节将让大家了解数据中台的总体架构、包含的模块、模块之间的关系以及运转机制。

数据中台的目标是让数据持续用起来，通过数据中台提供的工具、方法和运行机制，把数据变为一种服务能力，让数据更方便地被业务所使用。图3-7所示为数据中台的总体架构图，数据中台是位于底层存储计算平台与上层的数据应用之间的一整套体系。数据中台屏蔽掉底层存储平台的计算技术复杂性，降低对技术人才的需求，让数据的使用成本更低。通过数据中台的数据汇聚、数据开发模块建立企业数据资产。通过资产管理与治理、数据服务把数据资产变为数据服务能力，服务于企业业务。数据安全管理、数据运营体系保障数据中台可以长期健康、持续运转。

数据汇聚是数据中台数据接入的入口。数据中台本身几乎不产生数据， 所有数据来自于业务系统、日志、文件、网络等，这些数据分散在不同的网络环境和存储平台中，难以利用，很难产生业务价值。数据汇聚是数据中台必须提供的核心工具，把各种异构网络、异构数据源的数据方便地采集到数据中台中进行集中存储，为后续的加工建模做准备。数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等；从汇聚的时效性来分，有离线批量汇聚和实时采集。

通过数据汇聚模块汇聚到中台的数据没有经过处理，基本是按照数据的原始状态堆砌在一起的，这样业务还是很难使用。数据开发是一整套数据加工以及加工过程管控的工具，有经验的数据开发、算法建模人员利用数据加工模块提供的功能，可以快速把数据加工成对业务有价值的形式，提供给业务使用。数据开发模块主要面向开发人员、分析人员，提供离线、实时、算法开发工具，以及任务的管理、代码发布、运维、监控、告警等一系列集成工具，方便使用，提升效率。

图3-7　数据中台总体架构图

有了数据汇聚、数据开发模块，中台已经具备传统数据仓库（后面简称：数仓）平台的基本能力，可以做数据的汇聚以及各种数据开发，就可以建立企业的数据体系。之前说数据体系是中台的血肉，开发、管理、使用的都是数据。大数据时代，数据量大，增长快，业务对数据的依赖也会越来越高，必须考虑数据的一致性和可复用性，垂直的、烟囱式的数据和数据服务的建设方式注定不能长久存在。不同的企业因业务不同导致数据不同，数据建设的内容也不同，但是建设方法可以相似，数据要统一建设，笔者建议数据按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设。

通过数据体系建立起来的数据资产较为偏技术，业务人员比较难理解。资产管理是以企业全员更好理解的方式，把企业的数据资产展现给企业全员（当然要考虑权限和安全管控），数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示，以一种更直观的方式展现企业的数据资产，提升企业的数据意识。

前面利用数据汇聚、数据开发建设企业的数据资产，利用数据管理展现企业的数据资产，但是并没有发挥数据的价值。数据服务体系就是把数据变为一种服务能力，通过数据服务让数据参与到业务，激活整个数据中台，数据服务体系是数据中台存在的价值所在。企业的数据服务是千变万化的，中台产品可以带有一些标准服务，但是很难满足企业的服务诉求，大部分服务还是需要通过中台的能力快速定制。数据中台的服务模块并没有自带很多服务，而是提供快速的服务生成能力以及服务的管控、鉴权、计量等功能。

通过前面的数据汇聚、数据开发、数据体系、数据资产管理、数据服务体系，已经完成了整个数据中台的搭建和建设，也已经在业务中发挥一定的价值。运营体系和安全管理是数据中台得以健康、持续运转的基础， 如果没有它们，数据中台很可能像个一般项目一样，会在搭建起平台、建设部分数据、尝试一两个应用场景之后而止步，无法正常地持续运营，不能持续发挥数据的应用价值。这也就完全达不到建设数据中台的目标。

2月2日　周一　小雪　地点：SL董事长办公室

今天迎来了北京的第一场雪，看着窗外漫天的风雪，思绪也有点飘忽不定。

一周前接到了董事长马胜利的电话，希望能够在今天的IT规划汇报会上，重点谈一下IT助力集团数字化转型的思考和落地措施。

时光回到14年前，我刚从国内某知名大学计算机专业硕士毕业，恰逢其时，SL集团正在全力推进以数据库、ERP为主的底层IT建设，我如愿加入SL集团，成为一名IT研发工程师，跟随公司成长至今，参与并见证了公司信息化建设的全部过程。

SL集团创立于20世纪90年代初，是国内最大的综合性企业集团之一，以房地产为主营业务，旗下覆盖连锁酒店、零售商超、物业管理、文化旅游、供应链金融等多个行业和业态。迄今为止，SL集团已基本完成集团内部核心业务的信息化建设，并且成为支撑企业运作的重要部分。

然而，随着消费升级的到来，市场竞争的加剧，集团希望能借助云计算、大数据和物联网等互联网技术，实现企业持续发展创新和产业智能化升级，而数据服务赋能产业，正是夯实集团战略转型的重要基础工作之一。

作为集团CIO，探索并推动“数字化转型”的破局之道，是我义不容辞的使命和责任，而且我未雨绸缪，早早做了大量技术和人才的储备。

下午四点，如约来到董事长马总办公室，没有想到的是，除了马总，公司负责各业务线的副总裁们也全都悉数到场，看来今天的规划汇报已经升级为公司战略层面的一次汇报了。

我清了清嗓子，将对公司现状的调研及盘点情况向大家娓娓道来。

首先，在技术方面，集团现有的技术架构大多是基于单一业务或业务系统搭建的，而不是从企业全局视角进行考虑的，现有房地产、文旅、零售等十几条几乎完全不同的业务线，每条业务线的信息系统搭建时期都不一样。比如，较早搭建起来的传统数据仓库，根本没有办法对大批量非结构化数据进行存储和计算。因此，会有一些业务线的信息系统的底层技术选型，无法支撑大数据应用场景的技术需求，从而对转型形成掣肘。

其次，在组织方面，由于集团业务的多元化，伴随着各个垂直业务的发展，也形成了一个个垂直的数据中心，从而导致了大量系统、功能和应用的重复建设，更造成了计算资源、存储资源和人力资源的浪费：一方面完全独立的业务系统，其背后的数据存储和计算资源相互隔离，无法共用，资源浪费；另一方面，研发人员每天会消耗大量时间在临时取数和数据咨询上，常常三更半夜还在“跑”数据，很难优化任务，更难有机会思考如何为业务赋能。

最后，在数据方面，由于集团各业务部门的组织壁垒所导致的数据孤岛，使得数据价值不能得到充分挖掘，从而导致业务部门不能共享和应用数据。同时，此前基于单一业务进行的信息化建设，忽视了过程数据和关联数据，导致数据维度不足甚至数据缺失，出现现有数据来源及维度过于单一而无法支撑数字化转型的情况。此外，集团信息化建设过程中也缺乏数据治理以及数据质量管理方面的建设，导致清洗和治理时难以处理或可用性不高。

通过余光，我发现马总全程眉头紧蹙，而且脸色越来越凝重，焦虑的情绪也在办公室内弥漫开来。

这时我意识到，应该趁热打铁，向集团领导申请资源，推动“数字化转型”项目尽快立项。

“马总，对于目前转型中出现的问题，不单单是技术问题，更是集团内部利益协调问题，需要顶层战略设计和组织架构上的支持，希望集团能够尽快立项，并且引入数据中台作为承载集团数字化转型的关键机制。”

“刘总，目前行业大环境不景气，集团业绩增长放缓，数据中台能给我们的业务带来什么价值？别又像之前的IT项目一样，全都是形象工程！”集团营销VP肖总一提起IT，总是满脸不屑，在他眼里，上一套系统不如搞定几个大客户来得实在。

“是的，我也是有疑虑的，上次上新系统，老系统都要推倒重来，这个损失刘总有没有考虑过？”地产公司总经理李总也开始发问了。

“还有，现在各业务线都是独立核算的，按你刚才提到的，后面数据大家都要共享，那业绩是不是也可以共享啊，哈哈！”金融业务的潘总的话引得哄堂大笑。

要是在几年前，碰到这阵仗我肯定会发憷，但是多年的职业生涯让我体会到，IT项目一定是自上而下推行的，因为这背后实际牵涉的是公司的战略规划和顶层设计，然后才是组织建设，最后才体现为技术改造。所以已提前向马总汇报过一轮，基本达成以下共识：

第一，数字化转型项目势在必行，且是以数据中台项目为核心；

第二，数据中台项目就是要打破组织墙和数据孤岛，该得罪还是要得罪；

第三，系统选型尽量保留现有IT资产，避免推倒重来，降低进入门槛；

第四，可以先小范围试点，做出成绩再在集团内大面积推广。

经过一番激烈的争辩，马总最后一锤定音：

“数字化转型是大势所趋，集团变革已经刻不容缓，信息部会后和各部门尽快拿出可行性落地方案，争取年前将项目确定下来！”

两周后，在马总的支持下，由集团领导、大数据事业部负责人以及各子公司、各事业部负责人组成的数据中台战略小组正式成立。至此，SL集团“数据中台战略项目”正式启动，数字化转型进入倒计时。

数据中台战略小组为虚拟组织，主要负责数据中台相关的战略制定、指导原则制定和整体工作方向把握，不负责具体业务。

而我带领的大数据事业部负责数据中台战略项目的具体落地。

人类从石器时代走到信息时代，社会和科技发展的背后，数据的“维”并没有显著增加，“人、物、场景”等足以描述一切，不断变化的是数据的“度”，即如何度量实体对象以及对象之间发生的关系（场景）。这也是我们会从“IT时代”走向“DT时代”的原因。

在这些不变与变的本质之下，每一个企业需要建设的是满足“我的”数据应用需求的数据中台，“我的”代表一种独特的、适配的特质。由于企业自身发展状况不同，在建设中台之前，可能已经展开了数据应用的相关建设和运营。建议在建设数据中台之前，对企业当前的数据应用能力进行自我审视，就像一个练了10年内功的老和尚和一个刚进寺门的小沙弥，获得同样一本武功秘籍时，他们需要根据自己的内功状况来决定自己该如何练。本章中提到的数据应用成熟度评估模型是企业进行自我测评的工具，企业可以根据量化结果，选择适合自己的数据中台“修炼入门方法”。

笔者们选定的评估方法主要是通过企业数据对业务的支撑程度来评估企业应用数据的能力。回顾数据应用实践的过程，数据应用能力成熟度可以总结为统计分析、决策支持、数据驱动、运营优化四个阶段， 如表4-1所示。

针对不同的阶段，从企业战略定位、企业数据形态、数据应用场景、数据应用工具、企业组织架构等多个方面、不同特征维度进行参考判定，也就构成了数据应用成熟度评估模型。依据这个四个阶段的划分标准，企业可以进行数据应用成熟度的自我测评，数据应用能力成熟度越高，则代表数据对业务的支撑能力越强；应用能力成熟度越低，则意味着业务对数据的依赖程度越低。

表4-1　数据应用成熟度的4个阶段

微软公司在1989年发布了SQL Server，加上20世纪90年代UNIX服务器和x86服务器逐渐普及，以及IBM、Oracle等解决方案供应商进入市场，数据库的建设成本和技术门槛开始大幅下降，越来越多的企业逐渐迈进IT信息化时代。通过信息化建设实现生产和管理的系统化甚至自动化，已经不再只是大型企业才考虑的问题，越来越多的中小型企业也在思考如何通过将生产和业务流程从线下迁移到系统中，以实现对整个业务流程的计划、管控和集成。

也正是在这样的时代背景下，日本著名汽车制造商丰田所推崇的精益生产和持续优化的理念通过信息系统得以施展：通过MRP（Material Requirement Planning，物资需求计划）、ERP（Enterprise Resource Planning，企业资源计划）系统的建设将原来线下生产线中的看板转移到系统中。利用信息系统对生产流程中从订单到采购、生产、存货、物流、销售在内的各环节中的每一个细小环节信息进行记录，并从需求拉动的角度对各个环节中的数据进行分析，对流程进行持续优化，从而提升企业的生产管理水平，最终使企业取得了巨大成功。

在以丰田为代表的企业成功案例的推动下，越来越多的企业开始尝试利用信息系统来进行流程和管理优化，因此，MRP、ERP、CRM（Customer Relationship Management，客户关系管理）、OA（Office Automation，办公自动化）等企业管理系统的建设成为21世纪初企业信息化建设的一股热潮。

当企业寄希望于通过各类信息系统来提升管理水平时，往往不会只建一个业务系统，而是义无反顾地投入IT信息化的怀抱，恨不得让信息系统覆盖公司的每一条业务线。这样的建设浪潮也确实让企业成功建成了一条通道，利用业务系统将业务的开展情况通过数据保留了下来，但在想用这些数据的时候企业却犯了难。

一方面，业务迁移至线上后，每天在产生大量业务数据的同时不可避免地会出现一些系统或者数据的问题，而这些问题很多情况下需要专人来监控、管理和维护，因此很多公司就设立了一个新岗位：数据库管理员（Database Administrator，DBA）或数据库工程师（Database Engineer，DBE）。通过DBA/DBE来对公司的底层数据进行设计、管理和运维。

另一方面，由于业务系统会无差别地记录业务流程中每一个环节的所有被定义为需要采集的信息，并把这些数据都存放在数据库中的一张张数据表里。这导致数据库中分散存放了从系统运行第一天至最后一天的各式各样的数据，而且其中部分数据可能还是无效的“脏数据”。而无论是业务人员还是管理人员，除了业务系统界面上的功能和内容外，都无法根据自身的需求在数据库中找到对应的原始数据并形成最终结果，以作为业务和管理的支撑。

因此，为了让管理人员和业务人员能够了解到业务的整体运行情况，很多企业又多了一类岗位：业务数据分析师。这一类分析师和传统数据分析师不同，IT时代的业务数据分析师们所面临的问题不是数据匮乏而是数据过剩。他们的主要职责是在了解业务和管理要求的前提下，通过工具将底层存放在数据库中的原始数据变成一份份图表或者报告，从而实现从数据视角展现当前企业在经营过程中取得的成绩和存在的问题。这个阶段的分析其实还只是停留在对过去业务结果的统计，形成了面向业务主题的客观事实描述和分析结果，但由于维度有限而且停留于历史数据，因此无法支撑企业级别的基于数据的经营决策。

总体而言，该阶段主要是以业务需求为导向，通过IT系统的建设，实现业务过程的流程化、自动化，这个过程中可能会有少量数据记录，但并没有以数据为导向积累数据，主要是通过单一维度的少量数据的统计分析进行业务的总结。

统计分析阶段主要有以下5个特征：

（1）企业战略方面

该阶段的企业战略定位纯粹以业务为驱动，主要以满足企业业务需求，实现业务过程的流程化、自动化为导向。

（2）数据形态方面

该阶段的企业可能有少量的业务数据积累，但没有以数据为导向积累数据，数据主要以业务系统依托的关系型数据库进行存储，数据无组织，各业务数据分散存储和管理，数据维度单一，尚未开始理解全业务链条背后各个环节的数据，无数据质量管控。

（3）数据场景方面

该阶段的数据应用场景只针对业务系统中的关键数据和指标进行简单的、单一维度的统计分析和管理，辅助业务总结，每次基于业务目标的数据统计都需要定制化开发，如周报、月报等。

（4）数据应用工具方面

该阶段业务报表主要基于系统嵌入式报表模块产出，或系统数据导出后通过Excel制作报表，模式相对单一。通过一些统计分析，可以了解系统的一些基本使用情况和经营指标。

（5）组织架构方面

该阶段企业无专门的数据相关部门，主要以IT部门的数据库运维管理和业务部门的数据分析师为主。需要数据相关的能力时，一般用系统中定制的统计报表或者由特定业务部门提供Excel报表。

企业的管理者们意识到，如果对数据的应用仅停留在单系统、单维度的统计分析上，只用于对历史业务开展情况进行简单描述，数据并没有发挥出应有的价值，数据只是辅助企业了解业务运转的情况。企业不再满足于这种现状，希望能通过数据为业务决策提供支撑。因此，企业对数据的需求逐渐开始向更全面、更准确、更贴合业务管理决策的方向演进，其中最明显的特征就是企业开始构建企业级数据仓库，有BI团队来支撑需求分析与决策。

这么多来自于不同系统的数据，口径、规范都不一致，应该用哪一个数据才对？在面对类似这样的问题时，多数企业想到的最简单直接的方案是：寻找专业的团队，使用专业的工具来对这些数据进行抽象和提炼，形成能够反映整个公司业务运转情况的一套指标体系，通过对指标体系的监控间接实现对整个公司运转情况的管理。而正是沿着这个思路，很多企业专门成立了商业智能部门或者数据仓库部门，用来将业务或者管理人员提出的指标需求转化成开发人员能够理解的文档，并同时开始了BI工具、经营决策管理系统和大屏等可视化工具和系统的建设。希望将大量复杂的原始数据抽象为指标，并以体系化、可视化的方式直接呈现在决策者面前，为其决策提供数据支撑。

总体而言，该阶段主要是企业在业务系统建设的基础上，基于业务目标有意识地进行数据的收集、管理、分析，通过企业数据仓库建设，为企业业务提供决策支持。

决策支撑阶段具有以下5个特征：

（1）企业战略方面

该阶段，企业开始具备通过数据支撑经营决策的思路，并在考虑通过数据可视化的方式实现数据与业务的融合，以解决业务问题和支撑管理决策。

（2）数据形态方面

企业开始注重业务过程中的数据积累，开始对各业务环节的数据进行汇聚、管理，数据维度逐渐丰富。以面向业务主题的指标体系为形式进行数据组织，开始注重数据质量的管控，实施数据质量控制。

（3）数据场景方面

该阶段的数据应用场景开始基于数据仓库进行各业务主题的数据收集、管理、分析，为企业管理人员提供决策支持，构建包括领导驾驶舱、企业运行指数、企业第四张报表等场景应用。

（4）数据应用工具方面

开始针对数据收集和管理建立数据仓库、数据开发工具和专业可视化工具，进行系统化数据收集、管理和分析。

（5）组织架构方面

开始出现数据分析师的岗位，可能会设立专门的数据挖掘或商业智能部门来支撑企业进行数据化决策。

不难看出，无论是在统计分析阶段还是决策支撑阶段，业务的运转和数据之间依然是相互隔离的。企业对数据的应用都还停留在对部分维度的业务数据进行分析得到结果后，再由人工对业务开展进行不同程度的干预，最终实现业务优化，其最主要的使用群体是管理者。而随着企业业务数据的不断丰富，加上大数据和人工智能技术的成熟和应用，企业管理者们在迈进DT时代后又开始了新一轮的探索：在应对海量原始业务数据无法直接被业务使用的问题时，业务部门根据需求自建大数据团队以及相应的数据处理能力，通过汇聚、清洗、建模、挖掘等工作，同时借力于IT行业近年来在计算能力和人工智能领域的飞速发展，提升数据处理结果的实时性和智能化程度，将从数据中挖掘的价值服务于业务，从而让数据驱动业务变得更精准、更有效。

最为典型的应用场景就是面向个体用户进行千人千面的推广展示和精准营销：企业首先根据需求，收集千人千面所需要的数据，打通所有相关数据后，通过算法的能力，实现对用户偏好的挖掘，从而实现不同客户所得到的服务是专门量身定制的。就像一些新闻APP一样，当它发现你喜欢某一类新闻时，就不断地推送这类信息，吸引你不停地看，从而提升APP的使用时长。

总地来看，该阶段主要是企业在大数据背景下，开始基于海量数据积累，利用大数据、机器学习和深度学习等技术，进行数据的深度挖掘和分析，通过对多源、异构的全域数据的汇聚、打通，跨界考虑数据价值的应用，通过数据驱动业务发展，为业务应用提供数据服务，实现业务与数据的深度融合。

数据驱动阶段具有以下5个特征：

（1）企业战略方面

迈进DT时代，企业开始将数据作为企业的重要资产和生产资料。通过大数据技术对企业相关数据进行汇聚、打通和分析挖掘，为业务应用提供数据服务，通过数据驱动业务发展。

（2）数据形态方面

业务数据积累具备一定规模，对结构化数据、非结构化数据进行处理与应用。数据在组织形式上开始对业务涉及的相关数据进行汇聚、打通，开始根据需求进行数据清洗加工和标准化处理。

（3）数据场景方面

该阶段的数据应用场景主要以满足业务需求为主，主要是用数据提升现有业务能力，进行智能化升级。与上一个阶段数据主要服务于管理层不同，从该阶段开始，数据开始从管理层逐步转向具体的业务，业务开始认知到数据的价值，开始业务和数据的融合。

利用算法进行深入挖掘和分析，实现数据与业务的深度融合，为业务优化提供数据支撑，最为典型的就是个性化推荐、风控、精准营销等场景。

（4）数据应用工具方面

在该阶段，企业开始通过以Hadoop/Spark生态体系为代表的批计算、流计算、即席计算、在线计算等大数据处理技术及机器学习、深度学习算法进行数据汇聚和开发，并最终为现有的业务场景赋能，以驱动业务升级。

（5）组织架构方面

在该阶段，企业开始设立业务部门的数据团队，为业务场景的需求提供数据能力的支撑。一般会设置大数据工程师、算法工程师、数据科学家等职位，尝试通过大数据、人工智能等技术进行业务创新。

数据驱动阶段，在特定的场景下，数据已经与业务紧密结合，数据在业务运转过程中直接产生价值。但是，由于数据应用都是独立建设的，没有从全局考虑，企业在数据应用的过程中，经常会遇到标准口径不一致、内容重复建设，各业务数据无法融合产生更大的价值、企业数据价值无法被业务快速应用等问题。因此，企业开始考虑从全企业视角进行数据能力的输出，有些企业把这个定义为企业数据资产建设，以数据来驱动企业升级转型。

这个过程涉及汇聚各类企业数据资产、消除物理孤岛、通过Mapping能力将数据进行融合、消除逻辑孤岛，构建企业统一的数据资产，并进行数据治理，使数据资产符合生产要求，通过数据服务化的能力快速服务于业务。同时，过程中针对数据资产的使用和内容进行运营优化，以使得企业数据资产越用越有价值，真正成为企业的核心资产。我们把这种能力的建设定义为数据中台。

企业数据中台完成数据资产建设后，需要保障数据资产在日常生产过程中真实、稳定、准确、可用和高效，以实现数据资产价值最大化。而实现这一目标之前，企业首先要满足以下5个条件：

第一，能够追溯数据资产的形成过程，包括涵盖了哪些数据来源，经过了怎样的加工环节，涉及哪些业务环节和部门等；

第二，能及时获取到数据资产当前的状态，尤其是数据质量和安全情况，如更新频率、合规性、空值率等；

第三，能够知道数据资产被哪些业务调用了，以通过建立数据闭环了解和追溯数据资产所带来的业务价值；

第四，能够对整个数据中台从数据采集到数据应用的整个链路建立监控体系，便于及时发现和排除故障，保障数据资产的稳定性；

第五，建立丰富的数据内外部共享和服务渠道，实现数据价值的释放和交换。

只有同时满足上述五个条件时，企业才有足够的信息来源来支撑整个数据资产的运营及迭代优化。

为此，部分企业已经开始通过数据资产管理工具以及数据资产视图的建设来应对上述问题，同时从组织架构层面成立单独的数据资产管理委员会来统筹数据资产的管理工作，包括牵头制定数据资产的管理政策、拟定数据资产运营规则并监督各部门执行，同时负责整个数据资产平台的运营、组织和协调工作。从而最终实现数据资产在企业内外部高效、稳定地流转并持续为业务带来价值。

总体而言，该阶段主要是企业在大数据和人工智能等相关技术的基础之上，逐步完善，构建一套完善的、体系化的数据处理及服务流程，建立一套源源不断地把数据变成资产并服务于业务的一种可持续让企业数据用起来的机制，构建数据应用闭环，通过运营优化持续发挥数据业务价值。

运营优化阶段具有以下5个特征：

（1）企业战略方面

在该阶段，企业开始建设数据中台，数据中台定位是为企业未来五到十年发展提供数据能力支撑，在DT时代对企业进行智能化升级。注重数据资源使用的合理性和效率，并通过对数据资产及服务的不断运营，建立了从数据资产化到资产业务化的可持续数据应用的高效闭环，为企业源源不断输出数据智能的能力。

（2）数据形态方面

在该阶段，企业数据伴随数据驱动的业务快速发展，数据量快速增长，通过建立企业体系化、标准化的数据采集、存储、打通、应用流程，实现了企业数据的全面资产化。在数据质量方面，通过建立体系化的数据汇聚、加工及应用流程，并逐渐通过运营手段完善数据管理制度和规范，保障数据资产的高效输出和循环落地机制，形成数据资产管理闭环。

（3）数据场景方面

在该阶段，数据应用通过统一的数据资产体系，提供统一、标准化的数据服务能力，为企业各类快速变化的业务应用提供数据服务支撑，包括原有业务的优化以及业务创新。其服务可以通过数据中台自助式完成，缩短企业数据到业务的路径。

（4）数据应用工具方面

在该阶段，企业在数据应用工具方面除了通过API或可视化的形态服务于业务场景之外，开始为企业数据资产的运营和管理者提供专业化的数据资产管理工具，以便对数据资产进行统一管理和维护，并通过构建数据运营指标对数据的价值、质量、安全和标准建设情况进行度量，为数据治理、奖惩考核等机制提供相应的能力支撑，真正形成一套让企业数据持续用起来的机制。

（5）组织架构方面

在该阶段，企业组织架构中开始在管理层设置数据管理委员会、CDO等来负责数据机制的建设和管理，开始为未来数据智能驱动的企业战略升级提供支撑，将数据变成企业的一种独特资产。

同时也会成立专门的数据资产运营部门，一方面保障数据资产应用的合理性和效率，另一方面构建企业数据资产对内和对外服务的通道，将更多的数据服务消费者引入到平台当中。

数据中台并没有行业限制，我们认为所有行业都需要数据中台，只是不同行业，不同阶段的企业所需要的数据应用能力不同，对数据的依赖度也不同。

建设数据中台实际上需要对数据价值有一定的认知，这样才能更好地实现。当行业中的其他企业在用数据的能力服务客户时，别人可以精准定位、精准服务，如果你不具备这种能力，竞争失败是必然的。在IT时代，走在行业前沿的企业，信息化能力都很强。在DT时代，数据中台建设已经是每个行业头部客户的必然选择，它是企业智能化升级的基础设施，也是支持企业快速发展，与对手拉开差距的内功修炼，这种内功的修炼不是一朝一夕可以追赶的，是否实施关乎企业发展战略，其迫切性和成本投入也取决于企业对数据价值的认知程度。

不同行业的不同企业在不同阶段，其数据应用的需求也是不一样的，数据中台的建设是一个持续完善的过程。在这个过程中，不同阶段支撑的场景数据也需要不断迭代。那么，不同行业对数据中台所支撑应用的主要需求有哪些可以参考？笔者通过对多个行业的多个不同企业的调研和访谈，大致总结以下几个行业所处的阶段以及各行业对于数据中台的共性需求，如表4-2所示。

表4-2　各行业的数据中台需求特征

企业是否适合上中台，与企业数字化程度相关，这将跟企业的资源投入、人员能力、投入产出比有直接关系。

具备以下特点的公司可以加速考虑建立数据中台：

·企业最好有一定的信息化基础，沉淀了数据，实现了业务数据化过程；

·企业业务复杂，有丰富的数据维度和多个业务场景，特别是多业态型集团企业；

·企业有数字化转型、精细化经营的需求。

下面通过几个简单的例子来具体了解什么样的企业适合上数据中台。

（1）企业A

主要通过App运营专业类内容，收取广告费，提供免费的Wi-Fi服务吸引顾客，随着DAU的增加，需要给用户提供个性化内容。

大数据场景：目前比较合适的是启动一个内容推荐类的算法项目，但在可预见的将来，看不到更多的数据场景。

（2）企业B

主要通过线下门店和互联网的方式销售水果，目前门店数量已超过1000家。需要用大数据来精细化运营用户和商品，目前已经搭建了大数据平台，构建了数仓。

大数据场景：可视化报表（已有）、商品猜你喜欢、个性化营销信息推送、商品库存优化、卡劵核销风控等。比较适合启动一个数据中台项目。

（3）企业C

主要通过线下售卖服装盈利，同时运营两个品牌：MINI 1和MINI 2。两个品牌的CRM分别由不同供应商提供，为了更好地为会员提供服务，需要打通两个CRM中的用户数据。

大数据场景：无，属于业务中台范畴，需要构建统一的用户中心来为CRM提供数据。

（4）企业D

多业态集团公司，旗下有图书零售板块，有金融保险业务，同时还有多个大型综合购物中心。各个业务板块都有自己的数仓和报表，现需要面向集团构建统一的数据管理平台或数据资产管理平台。

大数据场景：这属于典型的数据中台类型项目。

通过以上内容，相信大家对自己的企业是否需要建设数据中台有了初步的认识。当然，在实际判断中还需要更加谨慎，不要被厂商的一些概念迷惑。

3月6日　周一　小雨　地点：CIO办公室

今天是惊蛰，象征着春回大地，万物更新，项目也在年后紧锣密鼓地推进起来。

我找来了共事多年的得力干将——姚冰，和他一同商量“数据中台战略项目”的落地事宜。

姚冰，28岁，国内知名大学计算机专业毕业，来集团已经6年，痴迷于数据开发与数据应用研究，现负责新成立的大数据事业部的数据技术部门，这次集团的数字化转型工作，他将是非常重要的工作助手。

共事多年，一开始就开门见山地表明了想法：

“姚冰，公司准备启动数据中台战略项目，这可是你梦寐以求的好事情！”

“这个机会太好了，技术部门早就应该从后台走向前台，与业务部门融合，实现IT驱动业务发展的价值路径！”

“嗯，马总要求技术部门出一份集团数据中台战略项目规划，出规划之前必须做的一件事情就是对集团现有的数据情况，以及数据应用情况做一个调研，这个活就交给你了。

第一步，你可以把集团现在有哪些业务线，每个业务线有哪些数据，分别以什么形式存储以及数据的应用情况调研清楚；第二步，可以对照《数据中台：让数据用起来》这本书里提到的数据应用成熟度评估模型，对集团的数据应用成熟度做一个评估，一周后给一个报告。”

一周之后，姚冰快步走进我的办公室。

集团数据的基本情况他已经摸清楚了，对集团的数据应用成熟度也进行了评估，大概情况如下：

·集团有地产、物业、零食、金融、文旅等多条业务线；

·每条业务线单独开发应用，依赖关系非常复杂，有大量的重复建设，仅CRM系统就有SAP、金蝶、用友等多家供应商；

·除了结构化数据，还存在大量非结构化数据，比如物业中的报修语音等，数据应用的情况也很复杂；

·业务数据没有打通，没有统一的口径和规范，这导致各业务线之间不能很好地共享和应用数据；

……

集团各业务线的数据情况如图4-1所示。

图4-1　SL集团各业务线数据调研报表示例

另外，从数据应用成熟度评估模型（见表4-1）来看，集团目前大概处于决策支持阶段到数据驱动阶段的过渡阶段。

看着姚冰的报告，我陷入了沉思……

要构建企业级的数据中台，第一步就是要让企业内部各个业务系统的数据实现互联互通，从物理上打破数据孤岛，这主要通过数据汇聚和交换的能力来实现。在面向具体场景时，可以根据数据类型将汇聚对象分为结构化和非结构化、大文件和小文件、离线与在线等几种，不同类型的数据对存储的要求不同。同时，与业务数据化的方式也有关系，有些场景需要通过线上或线下的方式来实现数据的汇聚。

随着互联网、移动互联网、物联网等技术的兴起，企业的业务形态开始多元化，通过行为埋点、爬虫的方式来收集过程数据是企业非常重要的方法和手段。从空间维度来看，用户行为可以分为线上行为和线下行为两类，采集这两类行为所产生的数据所使用的方法是不一样的，而且方法也在随着技术的演进不断发展和变化。

线上行为的主要载体可以分为传统互联网和移动互联网两种，对应的形态有PC系统、PC网页、H5、小程序、App、智能可穿戴设备等。在技术上，数据采集主要有客户端SDK埋点和服务端SDK埋点等方式。其中客户端SDK埋点主要是通过在终端设备内嵌入埋点功能模块，通过模块提供的能力采集客户端的用户行为，并上传回行为采集服务端。

（1）客户端埋点

常见的客户端埋点方式有三种：全埋点、可视化埋点和代码埋点。这三种方式的应用场景企业可根据自身需求进行选择。

·全埋点：将终端设备上用户的所有操作和内容都记录并保存下来，只需要对内嵌SDK做一些初始配置就可以实现收集全部行为的目的。这也经常被称为无痕埋点、无埋点等。

·可视化埋点：将终端设备上用户的一部分操作，通过服务端配置的方式有选择性地记录并保存。

·代码埋点：根据需求来定制每次的收集内容，需要对相应的终端模块进行升级。

针对这三种埋点方式，企业可以根据实际业务场景来判断和选择。它们的优劣势对比如下：

全埋点适合于终端设计标准化且有统一系统接口的情形，用户在终端上的操作，通过系统提供的事件捕获机制，在对象事件发生时调用埋点工具中的指定处理逻辑，对该事件相关的信息进行记录。这种方法的优点是不用频繁升级，一次性验证并发布后，就可以获取终端的全量行为数据。当突然发现需要对某个对象做分析时，可以直接从历史数据中找到所需的数据，不需要再次进行数据收集。缺点是数据存储、传输的成本会高一些，有些当前不用的数据也需要保留。

可视化埋点适合于需要考虑存储和带宽成本的情形，可通过后端配置来降低对象事件行为采集数量，实现机制和全埋点类似。其优点是发布后不需要频繁升级，成本比全埋点低，并且能够灵活配置；缺点是当需要对某一个对象进行分析，但发现其数据没有被采集时，需要重新配置并等数据采集完成再进行后续工作，容易影响业务进度。

代码埋点主要适合于终端设计非标准化、事件行为需要通过代码来控制的情形。其优点是灵活性强，针对复杂场景可以单独设计方案，对存储、带宽等可以做较多的优化；缺点是成本高，维护难度大，升级周期较长。

图5-1所示为某站点的网站行为埋点日志，该埋点日志中记录了数据的类型（logtype）、内容标题（title）、行为的上一级页面（pre）、用户的屏幕分辨率（scr）、用户标识（cna）、用户名（nick）等各类信息。在收集到这些数据后，后端运营就可以据此进行挖掘和分析，从而指导产品、运营的优化。例如，根据用户的屏幕分辨率数据，可以在产品布局上做更好的适配；通过行为的上一级页面，可以知道用户是从哪个页面进入当前页面的，进而优化用户行为路径等。

图5-1　埋点日志

（2）服务端埋点

除了前面介绍的客户端埋点，常见的线上埋点还有服务端埋点，通过在系统服务器端部署相应的数据采集模块，将这部分数据作为行为数据进行处理和分析。服务端埋点常见的形态有HTTP服务器中的access_log，即所有的Web服务的日志数据。前面提到的客户端的三种埋点方式，常见的简化实现方案一般也会配合HTTP服务器中的access_log来落地，但有时为了更好地融合，会定制一些服务端的SDK，用于捕获服务端系统中无法通过常规访问获取的数据信息，如内部处理耗时、包大小等数据。

服务端埋点的优点很明显，如果需要获取的用户行为通过服务端请求就可以采集到或者通过服务端内部的一些处理逻辑也能获取时，为了降低客户端的复杂度、避免一些信息安全的问题，常常会采用这种方式来收集用户行为数据。但其弊端也很明显，有些用户的行为不一定会发出访问服务端的请求，这种方式就无法采集这部分数据。因此，服务端埋点一般会和客户端埋点的结合使用，相互补充，以完成整个用户行为的采集。

线下行为数据主要通过一些硬件来采集，如常见的Wi-Fi探针、摄像头、传感器等。随着设备的升级，各种场景中对智能设备的应用也越来越多，安防、客户监测、考勤等都开始深入到生活中。常见的主要有Wi-Fi信号采集、信令数据采集、图像视频采集以及传感器探测等。

通过Wi-Fi信号采集周边移动设备是之前比较常用的方式，但由于有些不合规的使用涉及个人隐私，手机操作系统也针对这类现象做了一定的防采集处理，出于隐私保护、系统防护等原因，现在这种采集方式已经不怎么被使用。其主要原理是通过信号探测的协议，当热点附近的移动设备在探测SSID时，会建立网络连接，从网络协议中获取手机的网络设备号。

图像视频主要通过智能摄像头来采集，目标对象进入相应区域后摄像头可以识别相关信息，然后采集和保存图像并生成唯一标识，如Face ID用于信息的组织。

网络爬虫又称为网页蜘蛛，是一种按照既定规则自动抓取互联网信息的程序或者脚本，常用来做网站的自动化测试和行为模拟。Google、搜狗、百度等提供的互联网信息检索能力，都是基于它们内部自建的网络爬虫，在遵守相关协议的情况下，不断爬取互联网上的新鲜网页信息，对内容进行处理后提供相应的检索服务。

当企业的内部信息不足时，可以考虑利用外部互联网的数据进行一些“化学反应”，将外部的数据与内部数据有效融合，从而让内部数据在应用上有更多价值。网络爬虫有多种实现方式，目前有较多的开源框架可以使用，如Apache Nutch 2、WebMagic、Scrapy、PHPCrawl等，可以快速根据自己的实际应用场景去构建数据抓取逻辑。当然，需要遵守相应的协议和法规，同时避免对目标网站造成过大的请求压力。

数据汇聚不同于数据采集，数据采集有一定的数据生产属性，将终端的用户行为信息通过特定的方法记录后，通过中间系统的流转写入目标存储中。当然，也能通过某种形式在某个数据源中落地，如数据库或日志文件等，然后通过数据汇聚的能力实现数据采集和存储。

从数据组织形式来分，数据主要分成三类：

·结构化数据：规则、完整，能够通过二维逻辑来表现的数据，严格遵循数据格式与长度规范，常见的有数据库表、Excel等二维表。

·半结构化数据：数据规则、完整，同样严格遵循数据格式与长度规范，但无法通过二维关系来表现，常见如JSON、XML等形式表达的复杂结构。

·非结构化数据：数据结构不规则或不完整，不方便用二维逻辑表来表现，需要经过复杂的逻辑处理才能提取其中的信息内容，如办公文档、图片、图像和音视频等。

从时效性和应用场景来分，数据汇聚可以分成离线和实时两类：

·离线：主要用于大批量数据的周期性迁移，对时效性要求不高，一般采用分布式批量数据同步的方式，通过连接读取数据，读取数据过程中可以有全量、增量的方式，经过统一处理后写入到目标存储。

·实时：主要面向低时延的数据应用场景，一般通过增量日志或通知消息的方式实现，如通过读取数据库的操作日志（RedoLog、BinLog）来实现相应的实时处理，业界常见的Canal、MaxWell、StreamSets、NiFi等框架和组件都有较多的实际应用。

在数据建设过程中有ETL（Extract-Transform-Load，抽取–转换–存储）的操作，即在数据抽取过程中进行数据的加工转换，然后加载至存储中。但在大规模数据场景下，一般不建议采用ETL的方式，建议采用ELT（Extract-Load-Transform，抽取–存储–转换）的模式，即将数据抽取后直接加载到存储中，再通过大数据和人工智能相关技术对数据进行清洗和处理。如果采用ETL的模式在传输过程中进行复杂的清洗，会因为数据体量过大和清洗逻辑的复杂性导致数据传输的效率大大降低。另一方面，ETL模式在清洗过程中只提取有价值的信息进行存储，而是否有价值是基于当前对数据的认知来判断的，由于数据价值会随着我们对数据的认知以及数据智能相关技术的发展而不断被挖掘，因此ETL模式很容易出现一些有价值的数据被清洗掉，导致当某一天需要用这些数据时，又需要重新处理，甚至数据丢失无法找回。相比存储的成本，这种损失可能会更大。

在数据能力建设过程中，很多企业结合自身的场景和最佳实践也开源了一些优秀的汇聚工具，如Sqoop、DataX、Canal等，适用场景不同，也各有优缺点。

（1）Canal

Canal Server模拟MySQL Slave的交互协议，伪装自己为MySQL的Slave向Master发送dump协议，Master收到请求后开始推送binary log，Canal解析byte流产出解析后的增量数据。主要优点是流程架构非常清晰，部署和配置等相对简单，同时可以额外做一些配置管理、开发改造的工作。Canal的主要缺点是Server中的Instance和Client之间是一对一的消费，不太适用于多消费和数据分发的场景。

（2）Sqoop

Sqoop是目前市面上相对通用的一种解决方案，是在结构化数据和HDFS之间进行批量数据迁移的工具。整体框架以Hadoop为核心，底层使用MapReduce程序实现，MapReduce天生的特性保证了并行化和高容错率，任务运行在Hadoop集群上，减少了服务器资源的使用情况。其主要优势是，在特定场景下，数据交换过程会有很大的性能提升。主要缺点是，处理过程定制程度较高，目前主要通过在命令行中配置参数来调整数据同步操作行为，在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。除此之外，任务运行完全依赖于MapReduce，功能扩展性方面受到比较明显的约束和限制。

（3）DataX

DataX是阿里巴巴开源的一套插件式离线数据交换工具，以实现各种异构数据源之间的高效数据交换为目标而设计，提供数据交换作业全链路的流量监控，将作业本身的状态、数据流量、数据速度、执行进度等信息进行展示，提供脏数据探测功能，支持传输过程中对传输报错（如类型转换错误）进行策略化处理。由于它是基于进程内读写直连的方式，高并发数据交换场景下对机器内存要求比较高。除此之外，DataX不支持非结构化数据的同步，目前支持结构化数据源、半结构化数据源、非结构化数据源，但是非结构化数据源中需要存储的是一张逻辑意义上的二维表，例如CSV格式的文本信息，本质上还是结构化数据。

从上文的介绍中可以了解到，这些工具都无法很好地满足企业复杂的数据交换场景。从数据类型来看，有结构化数据和非结构化数据；从实效性来看，有实时数据交换和离线数据交换。另外，数据交换应该是后续数据作业的起点，因此，相应的交换任务调度及状态要能够有效地与上下游形成依赖，借助统一调度的能力构建数据作业流。

数据交换中心的首要目的是屏蔽底层工具的复杂性，以可视化配置的方式提供给企业用户；其次需要考虑，为了解决数据孤岛，需要满足异构存储、异构数据类型的交换需求；同时，还要考虑不同时效要求下的数据互通。因此，数据交换平台需要屏蔽系统底层协议、传输安全、特性组件等信息，让开发人员在数据接入过程中无须关注数据格式转换、数据路由、数据丢失等，只需要关注与业务本身的数据交换部分。企业信息化建设的多种数据源类型，可以通过同步模块的数据源进行统一管理，方便用户快速通过可视化页面执行数据汇聚工作。

在构建数据交换中心的实践过程中，基于异构数据源、异构厂商集群、数据应用时效性和相关技术栈等因素考虑，采取了不同的同步策略：离线数据同步和实时数据同步。同时，在两种同步服务的产品形态上，可以采用相同的可视化同步配置策略，以降低用户操作成本。

数据源管理主要是管理数据所用的存储，用于平台在做数据交换时，可以方便地对外部存储进行相应的管理。数据源可以是已有系统存储业务数据的地方，作为数据中台的数据来源，也可以是数据应用场景，为应用场景提供结果数据存储的地方。

根据业务系统以及数据应用场景的不同，数据源也有不同的选择。例如，广告场景对时效性要求很高，相应的，对数据源读性能的要求就会很高，有些场景对于大批量数据的多维分析有需求，因此数据源需要支持大批量数据的多维分析能力。针对这些场景，涉及的数据源会有很多种，大致可以分成：

·关系型数据库：如Oracle、MySQL、SQL Server、Greenplum等。

·NoSQL存储：如HBase、Redis、Elasticsearch、Cassandra、MongoDB、Neo4J等。

·网络及MQ：如Kafka、HTTP等。

·文件系统：如HDFS、FTP、OSS、CSV、TXT、Excel等。

·大数据相关：如Hive、Impala、Kudu、MaxCompute、ADB、LibrA、ELK等。

离线数据交换是针对数据时效要求低、吞吐量大的场景，解决大规模数据的批量迁移问题，其实现原理是将不同数据源的交换抽象为从源头数据源读取数据的读取插件，以及向目标端写入数据的写入插件，理论上可以支持任意类型数据源的数据交换工作。采用插件化方式构建，将数据源读取和写入抽象成读取插件、写入插件。

非结构化的数据也可以通过扩展插件方式进行交换，其场景主要是以文件或数据块的方式进行交换，因此只需要适配源或目的存储的相应插件及数据处理的机制，如文件传输，数据块保存为特定格式的文件，即可以满足相应的需求。

·读取插件：数据采集模块，负责采集数据源的数据，将数据发送给数据交换核心模块。

·写入插件：数据写入模块，不断从数据交换核心模块取数据，并将数据写入到目的端。

·数据交换核心模块：用于连接读取插件和写入插件，作为两者的数据传输通道，并处理缓冲、流控、并发、数据转换等核心技术问题。

离线数据同步技术具有以下亮点：

（1）前置稽核

在源端数据同步开始前，可以进行数据质量规则校验，根据配置规则的阻塞、告警等策略控制数据同步是否运行。

（2）数据转换

数据转换是指将各类非标准数据转换成标准数据格式，并且将转换后的数据推送到大数据平台指定的位置或库表。在数据同步、传输过程中，存在用户对于数据传输进行定制化的场景，包括字段截取、替换、编码转换等操作，可以借助ETL的T过程（Transform）实现。

在配置数据同步作业的字段映射关系时，可以对每个字段定义转换（Transform）函数，例如字符串截取dx_substr、字符串替换dx_replace、字符串过滤dx_filter，还支持用户用Groovy自定义转换逻辑。

（3）跨集群数据同步

由于采用插件化的设计思路，数据同步模块可支持不同集群间的数据同步。例如，从A集群上把数据同步到B集群上，只需要开发A集群的Reader和B集群的Writer，便可以新建数据同步作业对数据进行跨集群迁移。

（4）全量同步

全量数据同步分为表全量同步和库全量同步（整库同步）两种方式。表全量同步每次读取表中全量数据并写入；库全量同步策略是把库中所有表进行数据同步，要求源端和目的端的表名称、结构相同，允许目标表不存在，不存在时自动创建目标表。

（5）增量同步

增量同步分为新增、覆盖和更新三种策略。新增策略主要通过在目的端创建新分区或者直接追加写数据实现。覆盖和更新策略在同步配置时选择唯一键，根据唯一键对比同步中的数据和目的端数据，结合增量策略来判断数据是覆盖还是更新。

实时数据交换主要负责把数据库、日志、爬虫等数据实时接入Kafka、Hive、Oracle等存储中，便于后续进行实时计算或供业务查询分析使用，整体技术架构如图5-2所示。

实时同步有两个核心服务：数据订阅服务（Client Server）、数据消费服务（Consumer Server）。

数据订阅服务主要包含数据的订阅和读取、任务实例的启停控制等功能，Client Server采用插件式设计思路，可以支持扩展不同类型的数据订阅读取。

数据消费服务主要包含任务状态控制、数据解析、数据过滤、数据转换、数据写入等功能，通过TCP通信方式和数据订阅方式进行数据读取和传输，经过任务配置的过滤、转换等功能写入到目的端数据源中。数据消费服务也采用插件式设计思路，可以支持目的端扩展不同类型的数据源写入。

将各类数据汇聚后，首先面临的是存储压力，不同类型的数据内容、不同的数据汇聚方式及未来可能的使用场景，对存储的选择也会有较多的考虑。常见的问题有：

存储是选择关系型数据库还是大数据相关的技术（Hadoop等）？

现有的存储与新存储之间的关系是什么？

抛开技术指标的维度对比，选择存储时还需要考虑以下几个方面：

图5-2　实时交换架构图

（1）数据规模

当前的数据规模以及未来的数据规模，这取决于对中台的定位及未来的发展预期，DT时代企业的数据生产方式越来越丰富，数据量越来越大，选择成本可控且容易扩展的存储是当前比较常见的选择。

（2）数据生产方式

有些数据生产端没有存储，因此会通过实时推送的方式将生产数据按特定协议和方式进行推送，这类场景要求数据采集时的存储能够满足数据实时落地的需求。有些目标存储不具备这种高性能落地的能力，因此需要考虑在数据生产端和目标存储端中间加一个写性能较好的存储。

（3）数据应用方式

数据使用场景决定了数据存储的选型，如离线的数据分析适合非人机交互的场景，搜索则需要能够快速检查并支持一些关键字和权重处理。这些能力也需要有特定的存储来支撑。

针对这些复杂的场景，在大规模的数据处理下，任何一个以前认为可以忽视的小问题都可以被无限放大，因此像以前一样靠一种存储能力解决所有问题是不太可能的。在建设中台时，需要根据企业自身情况选择合适的存储组合来满足企业的数据战略和数据应用需求。

在线存储是指存储设备和所存储的数据时刻保持“在线”状态，可供用户随意读取，满足计算平台对数据访问的速度要求，就像PC机中常用的磁盘存储模式一样。在线存储设备一般为磁盘、磁盘阵列、云存储等。

离线存储是为了对在线存储的数据进行备份，以防范可能发生的数据灾难。离线存储的数据不会经常被调用，一般也远离系统应用，“离线”生动地描述了这种存储方式。离线存储介质上的数据在读写时是顺序进行的。当需要读取数据时，需要把磁带卷到头，再进行定位。当需要对已写入的数据进行修改时，所有的数据都需要全部进行改写。因此，离线存储的访问速度慢、效率低。离线存储的典型产品是硬盘、磁带和光盘等。

OLTP和OLAP是相对传统的术语，但是在大数据时代，它们又有新的使命。需要强调的是，OLTP和OLAP并不是竞争或者互斥的关系，相反，它们相互协作，互利共赢，OLTP用于存储和管理日常操作的数据，OLAP用于分析这些数据，如图5-3所示。

图5-3　OLTP与OLAP的关系

OLTP（On-Line Transaction Processing，联机事务处理）是专注于面向事务的任务的一类数据处理，通常涉及在数据库中插入、更新或删除少量数据，主要处理大量用户下的大量事务。一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的事务及查询的数量。在这样的系统中，单个数据库每秒处理的事务往往超过几百甚至几千个，Select语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库就是很典型的OLTP数据库。

OLAP，也叫联机分析处理（On-Line Analytical Processing）系统，有的时候也叫DSS（决策支持系统），就是我们说的数据仓库。常用于报表分析场景，相对于OLTP，对准确性（如id-mapping）、事务性和实时性要求较低。1993年，E.F.Codd认为OLTP已不能满足终端用户对数据库查询分析的需要，SQL对大型数据库进行的简单查询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，他提出了多维数据库和多维分析的概念，即OLAP。

OLAP技术主要通过多维的方式来对数据进行分析、查询并生成报表，它不同于传统的OLTP处理应用。OLTP应用主要是用来完成用户的事务处理，如民航订票系统和银行的储蓄系统等，通常要进行大量的更新操作，同时对响应的时间要求比较高。而OLAP系统的应用主要是对用户当前的数据和历史数据进行分析，帮助市场做决策，制定营销策略，主要用来执行大量的查询操作，对实时性要求低。表5-1对OLTP与OLAP进行了比较。

表5-1　OLTP与OLAP对比

为了应对数据处理的压力，过去十年间，数据处理技术领域有了很多的创新和发展。除了面向高并发、短事务的OLTP内存数据库外（Altibase、Timesten），其他的技术创新和产品都是面向数据分析的，而且是大规模数据分析，也可以说是大数据分析。有的采用MPP（Massive Parallel Processing，大规模并行处理）架构的数据库集群，重点面向行业大数据，如Greenplum、LibrA等；有的采用Shared Nothing架构，通过列存储、粗粒度索引等多项大数据处理技术，再结合MPP架构高效的分布式计算模式，完成对分析类应用的支撑，运行环境多为低成本的PC Server，具有高性能和高扩展性的特点；也有采用从Hadoop技术生态圈中衍生的相关的大数据技术，如HBase等。

（1）分布式系统

分布式系统包含多个自主的处理单元，通过计算机网络互连来协作完成分配的任务，其分而治之的策略能够更好地处理大规模数据分析问题。主要包含以下两类：

·分布式文件系统：存储管理需要多种技术的协同工作，其中文件系统为其提供最底层存储能力的支持。分布式文件系统HDFS是一个高度容错性系统，被设计成适用于批量处理，能够提供高吞吐量的数据访问。

·分布式键值系统：用于存储关系简单的半结构化数据。典型的分布式键值系统有Amazon Dynamo，获得广泛应用的对象存储技术（Object Storage）也可以视为键值系统，其存储和管理的是对象而不是数据块。

（2）NoSQL数据库

关系型数据库已经无法满足Web 2.0的需求。主要表现为：

·无法满足海量数据的管理需求；

·无法满足数据高并发的需求；

·高可扩展性和高可用性的功能太低。

NoSQL数据库的优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web 2.0应用，具有强大的横向扩展能力等，典型的NoSQL数据库包含以下几种：键值数据库、列族数据库、文档数据库和图形数据库，如HBase、MongoDB等。

（3）云数据库

云数据库是基于云计算技术的一种共享基础架构的方法，是部署和虚拟化在云计算环境中的数据库。云数据库并非一种全新的数据库技术，而只是以服务的方式提供数据库功能。云数据库所采用的数据模型可以是关系数据库所使用的关系模型（微软的SQL Azure云数据库都采用了关系模型）。同一个公司也可能提供采用不同数据模型的多种云数据库服务。

数据与数据之间天然存在着显性的和隐性的关系，大数据的极致魅力就在于通过对这些关系的识别和挖掘，创造前所未有的应用场景，带来预想不到的巨大价值。而要实现这一切，首先需要将数据进行物理层面的汇聚，让有价值的数据自动、快速地整合到统一的存储空间，为后面的数据开发、机器学习、数据分析打好坚实的基础。

数据汇聚是数据中台建设的第一个环节，其主要目的是打破企业数据的物理孤岛，形成统一的数据中心，为后续数据资产的价值挖掘提供原始材料。企业的每一个业务端都是一个数据触点，会产生大量的数据，这些数据的生产和采集过程需要符合数据安全、隐私保护的相关要求。同时，异构的数据源所采用的汇聚方法也有一定的差异，本章介绍了常见的数据汇聚的方法和工具，以及企业在使用这些方法和工具的过程中，如何将它们包装成一个简单易用的工具，以便于快速满足数据汇聚的需求。同时，本章还阐述了针对不同的数据汇聚场景，企业所需要考虑的存储选型。

汇聚联通到中台的数据，基本是按照数据的原始状态堆砌在一起的，是企业对过往所有IT信息化建设积累的成果的融合。数据开发是数据资产内容建设的主战场，是数据价值生产过程中的核心环节，可以支撑大批量数据的离线处理、实时处理和数据挖掘等。

业务沉淀的数据就像原始的矿石或商品的原材料，数据开发这个环节就像是“商品”生产的流水线，通过这条流水线将数据转换成数据资产，让数据能根据业务的需求转换成新的形态，将原本看起来没有价值的数据变成对业务有价值的资产，为前端业务源源不断提供所需要的“商品”。

数据开发涉及的产品能力主要包括三个部分，分别是离线开发、实时开发和算法开发，如图6-1所示。

图6-1　数据开发的产品能力

·离线开发主要包括离线数据的加工、发布、运维管理，以及数据分析、数据探索、在线查询和即席分析相关的工作。

·实时开发主要涉及数据的实时接入和实时处理，简化流数据的加工处理过程。

·算法开发主要提供简单易用的可视化拖曳方式和Notebook方式来实现数据价值的深度挖掘。

常见的加工场景有离线和实时数仓建设、算法模型训练、数据化运营分析、数据探索等。在这个过程中，通过数据开发套件对大数据的存储和计算能力进行封装，通过产品化的方式让用户更容易地使用大数据。计算能力与上一章提到的存储能力是紧密联系的，数据规模不断增加，除了存储能力需要细分，计算能力也一样需要细分，因此在建设过程中，也需要对不同场景下的计算能力有一定了解。

笔者们将计算能力根据场景抽象分成四大类：批计算、流计算、在线查询和即席分析。 不同场景配合不同的存储和计算框架来实现，以满足业务的复杂需求，如图6-2所示。

图6-2　数据计算能力的4种类型

（1）批计算

主要用于批量数据的高延时处理场景，如离线数仓的加工、大规模数据的清洗和挖掘等。目前大多是利用MapReduce、Hive、Spark等计算框架进行处理，其特点是数据吞吐量大、延时高，适合人机交互少的场景。

（2）流计算

也叫实时流计算，对于数据的加工处理和应用有较强的实效性要求，常见于监控告警场景，例如实时分析网络事件，当有异常事件发生时能够及时介入处理。例如，阿里巴巴“双11”的可视化大屏上的数据展现是根据浏览、交易数据经过实时计算后展现在可视化大屏上的一种应用。这类场景目前应用较多的计算框架主要有Flink、Spark Streaming和Storm等。

（3）在线查询

主要用于数据结果的在线查询、条件过滤和筛选等，如数据检索、条件过滤等。根据不同的场景也会有多种选择，如营销场景对响应延时要求高的，一般会采集缓存型的存储计算，如Redis、Tair等；对响应延时要求正常的，可以选择HBase和MySQL等；需要进行条件过滤、检索的，可以选择Elasticsearch等。企业一般对在线查询的需求比较旺盛，因此可能会有多套在线计算的能力提供服务。

（4）即席分析

主要用于分析型场景和经验统计。一般而言，企业80%的数据处理需求是在线查询和即席分析。针对不同维度的分析，有多种方式可以提供，提前固定计算的维度、根据需求任意维度的交叉分析（ad-hoc）等都是常见的场景。目前也有很多相应的产品、框架来支撑这方面的应用，如Kylin、Impala、ClickHouse、Hawk等。

随着数据量的不断增加，原有的计算框架已经无法支撑TB、PB甚至EB级规模的数据处理，在这种大数据场景下，提供成本低廉且可水平扩容的计算能力，采用分而治之的方法是必然的。Google的三篇论文开启了大数据处理的序章，其中MapReduce被各大公司作为数据处理的主要方案。传统的数据处理方式通常是将数据导入至专门的数据分析工具中，这样会面临两个问题：

·源数据非常大时，往往数据的移动就要花费较长时间。

·传统的数据处理工具往往是单机的，或系统架构无法快速扩容，面对海量数据时，数据处理的时间也是一个很大的问题。

MapReduce是一种分布式编程模型，采用“分而治之”的思想，将一个大规模数据集分解为多个小规模数据，然后分发给集群中多个节点共同完成计算。这样可以有效降低每一部分的运算复杂度，达到提高运算效率的目的。

MapReduce模型将计算分为两个阶段：Map阶段和Reduce阶段，图6-3为MapReduce模型的数据流图。Hadoop将MapReduce的输入数据划分为等长的数据块，称为输入分片（Input Split），为每一个分片构建一个Map任务，并且由该任务来运行用户自定义的Map函数，以处理分片中的每条记录。Map任务输出时要按照Reduce任务的数量进行分区，即为每一个Reduce任务新建一个分区，同时对每个分区进行排序。Reduce任务启动后，会向所有Map任务拉取数据并在Reduce端合并，Map任务和Reduce任务之间的数据流称为混洗（Shuffle）。最后由用户自定义的Reduce函数处理，其输出通常存储在HDFS上，以实现可靠存储。

MapReduce由于设计上的一些限制，导致处理性能较慢，针对这个问题，业界也有很多优化方案及替代产品，但真正发展起来的，目前主要有Spark。Spark也是一个批量计算框架，它将数据抽象成RDD、DataFrame，这是一种分布式的内存抽象，允许在大型集群上执行基于内存的计算，大大减少了迭代计算所需的开销。相比MapReduce，Spark在以下几方面具有优势：

图6-3　MapReduce机制示意图

·数据处理技术：Spark将执行模型抽象为通用的有向无环图（DAG）执行计划，这可以将多个Stage串联或者并行执行，而无须将Stage的中间结果输出到HDFS中。

·数据格式和内存布局：Spark RDD能支持粗粒度写操作，而对于读操作，RDD可以精确到每条记录，这使得RDD可以用来作为分布式索引。

·执行策略：MapReduce在数据Shuffle之前花费了大量的时间来排序，Spark支持基于Hash的分布式聚合，调度中采用更为通用的任务执行DAG，每一轮的输出结果都可以缓存在内存中。

批计算已经能满足多数大数据计算场景，然而要更快速、高效地获取数据中的价值，批计算已经无法满足需求。此时，一些优秀的实时处理框架，如Storm、Flink、Spark Streaming等逐渐发展起来，被广泛使用。

流计算的常见应用场景如下：

·流式ETL：集成流计算现有的诸多数据通道和SQL灵活的加工能力，对流式数据进行实时清洗、归并、结构化处理。同时，对离线数仓进行有效补充和优化，为数据的实时传输提供可计算通道。

·流式报表：实时采集、加工流式数据，实时监控和展现业务和客户的各类指标，让数据化运营实时化。

·监控预警：对系统和用户的行为进行实时检测和分析，实时监测和发现危险行为。

·在线系统：实时计算各类数据指标，并利用实时结果及时调整在线系统的相关策略，在内容投放、无线智能推送等领域有大量的应用。

在线查询需要处理大规模的数据结果集，同时又需要提供一些快速计算的能力，如条件过滤筛选、在线检索等能力，快速从大规模结果中筛选和检索出结果信息，并且支持高并发、低延迟的快速响应。这种能力批计算、流计算都不具备，因此需要提供在线查询的能力，常见的在线计算框架有Elasticsearch、Redis等，其主要应用场景是OLTP类的简单的增、删、改、查、全文检索等相关操作。

在线查询的常见应用场景如下：

·画像服务：根据对象标识提供具体的查询服务，如通过Redis可以提供低延迟、高并发的查询服务能力；通过HBase可以提供大规模数据的查询服务能力，征信查询就是类似的服务。

·搜索的应用场景：提供搜索引擎的能力，为用户提供模糊匹配、意图识别检索等能力，快速检索需要的内容，如常见的文档搜索、商品搜索等。

·圈人场景：通过一些特定的条件规则，可以快速筛选出业务所需要的群体，为后续的运营、营销等工作的开展提供支撑。

即席分析是指面对大规模的数据集，如何快速进行数据的多维交叉分析，其大部分是聚合型操作，如group by、sum、avg、count等。批计算有足够的灵活性，但耗时比较久，一些传统的关系型数据库以及数仓架构，在一定维度的场景下可以满足响应要求，但数据量受限。在数据应用中，分析类应用的占比一直不低，因此一些优秀的处理框架（如Impala、Kylin、ClickHouse和AnalyticDB等即席计算框架）逐渐发展起来。针对即席分析的复杂场景，通过对时间、空间的权衡，即席分析常见的实现方式有两种：

·ROLAP：以关系数据库为核心，以关系型结构进行多维数据的表示和存储，结合星型模式和雪花模式实现。

·MOLAP：基于多维数据组织的实现，以多维数据组织为核心，形成“立方块”的结构，通过对“立方块”进行各类处理来产生多维数据报表。

即席分析的常见应用场景如下：

·交互式数据分析：企业运营人员在日常工作中经常需要通过SQL从各个维度对当前业务进行分析，提供分析结果以便开展后续工作。离线计算的场景等待时间较久，用户体验不好，即席分析可以比较好地规避这个问题。

·群体对比分析场景：在业务中经常会有A/B测试场景，针对不同的群体，从各个维度对比分析也是即席分析经常支撑的场景。

批计算、流计算、在线查询、即席分析的区别见表6-1。

表6-1　批计算vs流计算vs在线查询vs即席分析

离线开发套件封装了大数据相关的技术，包括数据加工、数据分析、在线查询、即席分析等能力，同时也将任务的调度、发布、运维、监控、告警等进行整合，让开发者可以直接通过浏览器访问，不再需要安装任何服务，也不用关心底层技术的实现，只需专注于业务的开发，帮助企业快速构建数据服务，赋能业务。

将数据汇聚到中台后需要对其进行进一步加工处理，一般来说，企业有60%～80%的场景需要用到离线批处理的能力，这个过程就像一条数据的生产流水线，将采集和汇聚起来的原始数据，通过离线加工的各个环节和相应的数据处理模型，形成有价值的数据资产。在这个过程中，离线开发套件需要一些核心的功能（如作业调度的策略机制、对于数据生产时效的基线控制、企业当前信息化架构下各类异构数据源的适配、数据权限的管控等）来保障数据加工的过程易用可控。

在数据开发过程中，经常需要配置作业的上游依赖作业，这样作业之间便会组成一个有向无环图（DAG，Directed Acyclic Graph），同时会配置作业的开始调度时间。例如，对于图6-4中的B作业来说，其父作业分别是为A和C，调度开始时间设置为05：00。

·依赖调度：所有父作业运行完成后，当前作业才能开始运行。图6-4中的作业B，只有父作业A和C运行完成后，才能开始被调度。

·时间调度：可指定作业的调度开始时间。图6-4中的作业B，只有到达05：00后才能开始被调度。

图6-4　DAG示意图

如果一个节点既有父作业又有调度时间约束，那么在调度过程中只有同时满足两种约束条件时，才能开始被调度。

在大数据离线计算中，由于作业执行时间较长，经常会遇到急着用数据却发现数据还没出来的情形。重新跑需要几个小时，时间已然来不及。因此本书提出一种基线控制方法，用于统一管理数据处理作业的完成时间、优先级、告警策略，保障数据加工按时完成。调度模块会根据最先到达、最短执行时间原则，动态调整资源分配及作业的优先级，让资源利用效率最大化。

同时采用算法对作业完成时间进行智能预测。根据预测，当作业无法正常产出且动态调整无法完成时，调度中心会及时通过监控告警通知运维值班人员提前介入处理，为大数据作业执行留出充裕的时间。

当前，企业内部的计算存储引擎呈现多元化趋势。例如，国内某大型企业同时使用Oracle、IQ、HANA、Hadoop、LibrA等多种数据库，涉及关系型DB、MPP、大数据数仓等多种不同类型。离线开发中心针对每种类型的计算引擎会开发不同的组件，例如，针对Oracle开发Oracle插件，针对Hadoop体系分别开发出Hive、Spark、MapReduce等插件。用户只需要新建各种类型作业，例如Oracle、IQ、HANA、Hive、Spark、LibrA等，在执行时自动根据作业的类型寻找相应插件来运行作业。

在离线任务的开发过程中，会涉及各种各样的任务类型。对于常见的SQL任务类型，SQL检查器会做好严格的管控，做到事前发现问题，避免代码在周期调度过程中或运行完成后才发现问题。校验分为语法校验和规则校验。

·语法校验是对SQL的语法进行校验。不同类型的SQL语法是不一样的，如常用的Hive、Spark、Phoenix等；相同类型而不同版本的SQL语法也不一样，如Spark 1.x、Spark 2.x等。

·规则校验是指SQL检查器根据规则库提供的规则，对SQL进行规则校验。校验的规则是可以动态添加和扩展维护的，比如可以包含代码规范校验、代码质量校验、代码安全校验等。

可以通过环境级联的方式灵活支持企业的各类环境需求，方便对资源、权限进行控制和隔离。例如在新建项目时，企业可根据自身需求配置各种环境和级联方式，每个环境拥有独立的Hive数据库、Yarn调度队列，甚至不同的Hadoop集群。常见环境如下：

·单一环境：只有一个生产环境，内部管理简单。

·经典环境：开发环境中存放脱敏数据、供开发测试使用，上生产走发布流程，用于真实数据生产。

·复杂环境：企业有外部人员和内部人员时，会给外部人员提供一个脱敏管控的环境，外部人员开发完的数据模型经过测试后发布到内部开发环境，由内部员工检查确认及内部测试验证流程，完成确认后发布。在内部生产、内部开发、外部开发等环境中，数据样本也会根据面向的群体不同，进行不同等级的加密和脱敏处理。

在新建项目时，一般会创建开发和生产两个环境，开发环境用于用户开发、任务调试，生产环境即线上环境，系统默认会按天进行周期调度以执行任务。生产环境不允许用户直接操作任务、资源和函数，必须在开发环境下进行新建、修改或删除，在经过提交、创建发布包、同意发布三个操作后，才可同步到生产环境。

随着业务的不断深入，企业对工作流和作业与业务结合的理解越来越深，数据开发人员需要开发的作业会不断累加，峰值时，一个工作流下会挂成千上万个作业。这会让工作流任务的人工维护非常艰难。如何从上千个作业中找到需要依赖的上游作业？如何保证选定了上游作业后，不会因形成环路而导致调度失败？这时候就需要一把利器，能自动推荐上游作业，既能保证准确找到需要定位的上游作业，又能保证不会形成环路。可以看图6-5所示的节点依赖。

图6-5　依赖推荐

已知A、B、C、D、E、F、G及依赖关系，现开发了两个新的任务H和L，需要对H、L设置上游依赖信息。智能推荐依赖的工作原理具体如下：

·获取推荐依赖的核心原理在于上下游作业输入和输出的表级血缘依赖图；

·通过血缘分析当前作业的输入和输出，找到合适的上游作业；

·对合适的作业进行环路检测，剔除存在闭环的作业；

·返回合适的节点列表。

通过图6-5中的关系，可以智能推荐出H节点的上游作业为D、G，L的上游节点为E、G。

由于企业内部计算引擎的多样化，数据权限的管理会面临如下问题：

1）部分引擎拥有独立的权限管理系统（例如Oracle、IQ、HANA、LibrA），导致权限申请需要到每一种引擎上单独操作，让使用变得复杂。

同一种计算引擎，不同厂商的权限系统有多种。例如，Hadoop自身无数据权限系统，由不同厂商各自去实现，目前主要有两种策略：

·RBAC（Role-Based Access Control，基于角色的访问控制）：比如Cloudera用的是Sentry，华为的FusionInsight也是类似的机制。

·PBAC（Policy-Based Access Control，基于策略的访问控制）：比如Hortonworks用的Ranger。

2）数据权限是由大数据集群或数据库运维人员管理的，开发人员无法直接操作或者接触，所有的权限申请都需要运维人员开通，造成运维人员负担过重。在实际开发中，一般需要运维人员把整个库的权限授权给某个开发负责人，然后库里面的表、字段、函数的权限管理由开发负责人负责就行。

3）缺乏一套能同时支持多种计算引擎的权限申请、审批、管理系统。本书提出的数据权限管理目标就是构建统一的权限管理系统来支持多种引擎，可以直接在此系统上进行各种引擎的权限申请、审批和管理，无须接触底层引擎的权限管理系统。在适配不同引擎时，仍旧采用插件化的设计思路，针对每种权限管理系统开发一种插件，并支持用户通过二次开发来扩展插件。

数据权限管理中心提供界面化操作。数据申请方直接在页面上进行各种权限的申请，数据管理方在界面上审核权限，执行同意或拒绝操作。同时，所有权限的申请、审批都会有记录，便于进行权限审计。在统一数据权限服务中，会对接底层的各种权限管理系统，例如Sentry、Ranger、Oracle，同时对数据权限管理中心提供服务，执行权限的申请、授权、撤销等操作。

随着数据的应用场景越来越丰富，企业对于数据价值反馈到业务中的时效性要求也越来越高，很早就有人提出过一个概念：数据的价值在于数据的在线化。实时开发套件是对流计算能力的产品封装。实时计算起源于对数据加工时效性的严苛需求：数据的业务价值随着时间的流逝会迅速降低，因此在数据产生后必须尽快对其进行计算和处理。通常而言，实时计算具备以下三大特点：

·实时且无界（unbounded）的数据流：实时计算面对的计算是实时的、流式的，流数据是按照时间发生的顺序被实时计算订阅和消费的。并且，由于数据产生的持续性，数据流将长久且持续地集成到实时计算系统中。

·持续且高效的计算：实时计算是一种“事件触发”的计算模式，触发源就是上述的无界流式数据。一旦有新的流数据进入实时计算，实时计算立刻发起并进行一次计算任务，因此整个实时计算是持续进行的高效计算。

·流式且实时的数据集成：流数据触发一次实时计算的计算结果，可以被直接写入目的存储中，例如，将计算后的报表数据直接写入MySQL进行报表展示。因此，流数据的计算结果可以类似流式数据一样持续写入目的存储中。

基于Storm、Spark Streaming、Apache Flink构建的一站式、高性能实时大数据处理能力，广泛适用于实时ETL、实时报表、监控预警、在线系统等多种场景。让用户彻底规避繁重的底层流式处理逻辑开发工作，助力企业向实时大数据计算升级转型。实时开发涉及的核心功能点包括元数据管理、SQL驱动式开发、组件化配置以及多计算引擎。

与流计算搭配的消息中间件中的数据往往是没有格式约束的，导致后面进行实时计算时无法直接将消息流映射为结果化对象来进行SQL加工。元数据管理可以将Topic中相应的元数据信息统一维护到元数据注册中心，将数据和元数据进行解耦，Topic中只需要存入数据即可。在进行流计算时，实时开发会根据Topic自动寻找对应的元数据信息进而形成DataStream，以便进行后续的实时计算。实际场景中，巨量的数据加工对存储及网络带宽都会带来一定的压力，选择特殊存储格式和压缩尤为必要。因此，元数据管理还支持配置各种数据存储格式，例如JSON、AVRO、Protobuf。

可以将流计算当作动态数据表中的持续查询，同时动态变动的视图也可以看作变动的数据流。鉴于SQL的普适性，流计算SQL化可以大大节省开发人员的工作量，提高开发效率。将变动的实时数据（如Kafka中不断推送的消息）、较少变动的维度表（如HBase、kudu表数据、csv文件、MySQL表）等加载到流中，注册为临时视图。同时，加工的中间结果也可以注册为视图，这样在视图上就可以做SQL化的转换处理，最后写入结果表中。

为了更便捷地开发流计算任务，需要将流计算的输入源、转换逻辑、UDF函数、结果的持久化等封装为组件。开发人员可以通过拖拽相关组件来进行简单的配置和SQL逻辑编写等，将任务具体化为流计算的加工拓扑图，由平台负责任务的调度、解析及运行。

在流计算中，基于窗口的计算往往需要基于时间维度划分计算窗口。而在实际业务场景中，eventTime的数据来源各式各样，业务时间可能来自某些时间戳、字符类型的字段、多字段中日期与时间的组合，而时间格式也可能不同，因此统一eventTime尤为必要。简单选择或组合字段、日期格式后，由流计算平台做统一eventTime处理，以利于后续基于窗口的加工计算。

对数据流中的加工数据可以配置延迟告警信息。当数据积压超过阈值时，可发出延迟告警，同时会触发流计算的backPressure机制，使输入流的速度变慢，从而不至于使整个流计算任务意外终止。对流计算中各组件的吞吐、流速（读取、加工及写入的速率）等指标做统计分析，能帮助用户更加直观地分析计算瓶颈，进而准确地定位问题并进行优化。

DT时代的数据具有高维稀疏特征，对算法处理提出了更高的要求。面对百亿样本级别的数据量，传统的数据挖掘在辨识价值信息、挖掘数据关系和数据趋势方面捉襟见肘。此外，DT时代的业务具有快速迭代、敏捷开发、灵活试错的特性，新的时代特征为数据智能化发展带来了新的挑战，具体表现在如下方面：

·数据处理难度加大

·业务处理要求变高

·烟囱式的开发模型

·散落各地的模型服务

·模型研发环节繁多

·冗余分散的基础设施

·数据处理/特征工程

·多角色企业研发团队

因此，一款能支撑多环境、多集群、多形态模型服务化能力的算法开发工具对企业创新业务、实现数据智能化起着至关重要的作用。

算法开发作为一站式的企业级机器学习工具，旨在快速赋予企业构建核心算法服务的能力，它集成了以批计算为核心的离线模型训练功能，以流计算为核心的在线机器学习，以及基于在线查询、即席分析的数据探索和统计分析能力。算法开发套件为算法人员提供可视化建模和Notebook建模两种建模方式，集成主流的机器学习、深度学习计算框架和丰富的标准化算法组件能力，在开展数据智能、数据科研、预测分析等方面能够帮助企业快速实现人工智能应用的构建与落地，整体架构如图6-6所示。

图6-6　算法开发套件架构图

面对前台的智能业务需求，传统的数据加工和分析难以满足，作为数据开发的重要工具，算法开发需要满足复杂的学习预测类智能需求，输出算法模型能力，将数据洞察升级为学习预测，驱动业务创新。当数据开发和资产加工无法满足数据挖掘、算法标签生产等场景的需求时，算法开发可为离线开发和实时开发提供算法模型。加工好的数据和标签资产又能被算法开发用于模型训练和学习预测，支持智能需求研发。

不同企业的算法应用场景也不一样，数据的差异性也决定了每个企业的算法效果会有很大差别，数据和特征决定了机器学习的上限。比较常见的应用场景如下：

·金融风控和反欺诈：利用关联分析、标签传播、PageRank和社团发现等图算法组件，构建金融反欺诈核心能力，根据客户本身属性和行为数据识别虚假账号和欺诈行为，增强金融监管能力，保障金融业务稳定和安全。

·文本挖掘分析：利用命名实体识别 ^[1] 、图挖掘等文本算法能力，通过分析非结构化的文本信息自动识别其中的实体以及它们之间的关系，构建关系网，可以深度分析以前未处理的一些线索。

·广告精准营销：通过深入洞察客户需求、偏好和行为，利用特征分箱、LightGBM、PMI等算法组件构建的机器学习模型来智能挖掘潜在客户，实现可持续的精准营销计划和高质量曝光率，有效提升广告点击率。

·个性化推荐：利用协同过滤、XGBoost等推荐场景组件，通过分析海量用户行为数据构建多维用户画像，实现千人千面的推荐，提高转化率。

这些场景的落地通过算法开发工具可以大幅提升效率，当企业缺少算法工程师构建场景时，可以降低企业构建智能化场景的门槛，快速实现企业需求。

可视化建模面向算法工程师和数据分析人员，通过拖曳的可视化交互方式便捷编排算法实验，集数据处理、模型训练和评估、在线预测于一体，帮助开发者实现零代码的开发工作。为达到这一目标，功能设计需要考虑：

·拖曳式实验流：通过可视化拖曳，自由编排数据集、模型以及机器学习/深度学习等算法组件，组成有向无环图。屏蔽了复杂的算法代码开发过程，极大降低了用户进行算法开发或数据分析的门槛，给用户提供“所见即所得”的交互体验，帮助用户在面对智能业务需求时快速响应、快速试错。

·丰富算法组件：提供大量开箱即用的算法组件，支持用户完成数据处理、模型训练、模型评估和预测的实验流程设计和调试，覆盖主流算法应用场景。通过可视化配置算法参数，零基础算法背景的用户也能快速上手，训练出可用的算法模型。同时，对算法模块进行不同的参数设置，能让模型训练过程透明可控，分析结果更准确。

·实验周期调度：在实际智能业务场景中，经常需要根据每天产生的最新数据来定时运行实验和训练算法模型。根据不同的需求灵活安排调度实验，需要支持细粒度的调度周期，包含分钟、小时、天、周、月等级别。

·告警通知：算法模型训练时间往往较长，设置告警通知可以保证在第一时间得知实验运行和模型训练的结果。提供不同的告警方式（邮件、短信、钉钉等），可自定义告警规则和内容，灵活适配不同的用户习惯。

·多角色协同：算法开发是一个团队型工作，需要很多角色共同参与。从底层资源的运维到上层的项目管理，多人多角色分工协作的项目管理模式，可以让算法开发者专注算法建模任务，减轻烦琐的底层资源运维工作，同时保障人员权限隔离和数据安全。

Notebook建模提供了一个集成的Jupyter工具，提供专业算法开发环境和主流算法框架，帮助算法工程师快速、轻松地通过代码开发来构建和训练机器学习模型。Notebook建模环境的构建，需要考虑的功能点如下所示。

·JupyterLab在线编程：最主流的专业机器学习环境，轻便快捷，支持开发结果查看。JupyterLab是一个交互式的开发环境，使用它，用户能够以灵活、集成可拓展的方式处理文档和活动。可开启终端，用于交互式代码运行，支持丰富的输出。它支持代码、Markdown文档、JSON、YML、CSV、各种格式的图片、Vega文件等多种类文件，还支持多种插件，最大程度提升算法开发生产力。

·支持通过API方式调用标准算法组件，内置大量优化的机器学习算法，高效处理海量数据，提高开发人员的开发效率。

·支持多语言：包括Scala、Python、R、Shell等，同时可进行拓展。

·高可用：支持共享存储，实现数据高可用和数据隔离；支持Kubernetes集群，保证服务的高可用和资源隔离。

数据集是算法建模过程不可或缺的原材料。由于企业业务场景的复杂性，算法开发过程需要管理并整合不同来源的数据，同时对数据集进行标注和可视化探查，使数据的使用更高效，简化建模流程。作为统一维护数据集的场所，数据集管理需要考虑的功能点如下所示。

（1）数据接入

支持多种类型的数据，主要可分为结构化数据和非结构化数据。提供多种数据接入方式，包括本地上传数据、HDFS数据上传、Kafka数据接入、数据源接入等，可对数据集进行统一管理，并直接在可视化构建实验流时使用。

（2）数据标注

高质量的数据是模型和算法突破瓶颈的关键因素。通常，数据标注越精准，算法模型训练的效果就越好。大部分算法在拥有足够多普通标注数据的情况下，能够将准确率提升到95%，但要从95%提升到99%甚至99.9%，就需要大量高质量的标注数据。通过对人工少量标注的样本进行建模训练，然后用训练出来的模型进行数据预标注，由人工判断标注是否准确，并反馈结果用于优化算法，直到机器标注的准确率达到要求。支持的数据标注类型包括图片、语音、文本、视频等，通过抽检、多重审核机制把控标注结果的准确性，提升数据输出质量。

（3）数据探查

数据探查是算法开发人员建模前必不可少的工作。通过数据探查可快速评判数据集的质量和可用性，并根据数据集展现的特点评估适用的模型范围。在数据探查时，不仅可对数据内容进行预览，还可以搭配丰富的统计分析组件对数据进行可视化展示，直观反映字段级的数据特征。

为了提高可用性和降低使用门槛，主流机器学习平台都会提供内置的机器学习算法组件，覆盖从数据接入、数据预处理、特征工程、模型训练到评估和导出的完整算法建模过程，辅助用户高效完成复杂的业务建模。主要算法组件如图6-7所示。

（1）数据获取及存储

数据获取及存储组件主要用来从HDFS等存储平台中读取或保存数据和文件，是整个机器学习平台运行的基础。

（2）数据预处理

由于现实中的大多数数据都是不完整、不一致的脏数据，无法直接应用算法，或算法效果不尽人意，因此需要在算法建模和预测之前对数据进行简单处理。此外，机器学习平台往往很难支持全量数据分析，当需要处理或者分析大数据量时就需要借助抽样技术进行样本分析。为了解决上述问题，通常可以采用数据清理、数据集成、数据变换、数据归约以及数据采样等方法。因此数据预处理也是提高数据质量和算法效率的关键因素。常见的组件有随机采样、加权采样、分层采样、拆分、join、归一化、标准化、缺失值填充、类型转换等。

图6-7　算法组件库一览

（3）特征工程

特征工程是指在算法开发过程中，利用特征选择、特征加工、特征降维等技术手段构建对结果具有显著影响或便于模型处理的特征。利用特征工程相关的组件可以快速构建特征体系、快速选择有效特征，进而大幅提高算法的质量，提升分析效率。常见的组件有主成分分析、特征尺度变换、特征离散、特征异常平滑、奇异值分解、one-hot编码等。

（4）统计分析

主要用来探索和分析数据特征及其他相关数据的深层统计意义，涵盖相关性分析、分布、参数校验等功能。常见的组件有直方图、协方差、相关系数矩阵、正态检验、皮尔森系数、T检验、百分位、洛伦兹曲线、经验概率密度图等。

（5）机器学习

机器学习是算法开发的核心模块之一，包含主流分类算法、回归算法和聚类算法，可以满足大多数算法需求。

1）分类

分类是监督学习领域的一个核心问题，分类用于推测输入数据的类别。当分类的类别为两个时称为二分类问题，当分类的类别为多个时称为多分类问题。分类预测在许多领域都有应用，例如，在银行领域用来预测客户是否逾期还款，在新闻领域用来预测新闻所属的类别，在医学领域用来预测病人是否患病等。以预测病人是否患病为例，将历史病人数据作为训练数据，通过数据预处理和特征工程组件将病人的相关体征与信息处理成输入的特征，并将是否患病作为标签列，就可以通过分类组件与机器学习预测组件对后续的病人是否患病进行预测。常见的组件有GBDT二分类、线性支持向量机、K近邻、决策树分类、多层感知机分类、朴素贝叶斯分类、LightGBM分类、随机森林分类、逻辑回归分类等。

2）回归

回归是监督学习领域的一个重要问题，用于预测输入变量和输出变量之间的关系。按输入变量与输出变量之间的关系类型来分，回归可以分为线性回归和非线性回归。许多领域的问题都可以转化为回归问题，例如股价预测、销量预测、营业额预测、房价预测等。以房价预测为例，将过去一段时间的数据作为训练数据，利用数据预处理和特征工程组件将影响房价的信息处理成输入的特征，并将房价作为标签列，就可以通过回归组件与机器学习预测组件对未来的房价进行预测。常见的组件有GBDT回归、随机森林回归、线性回归、LightGBM回归等。

3）聚类

聚类是无监督学习领域研究较多的问题，其目的是将数据分为多个簇，使得簇内的样本较为相似、簇与簇之间样本的差距较大。聚类在许多领域都有着广泛的应用，例如在电商领域用于发现兴趣相似的用户，进而给这类用户推荐相似的商品。通过数据预处理和特征工程组件将原始数据处理成输入的特征，就可以通过聚类组件对数据进行聚类。常见的组件有kmeans、高斯混合聚类等。

（6）深度学习

支持主流的Tensorflow、MXNet、Caffe、XGBoost、LightGBM等深度学习框架，利用这些组件可以灵活、高效地构建深度学习应用。

（7）文本分析

主要包括文本相关的特征处理、模型构建等功能，专门用来实现文本分类、关键词抽取、摘要生成等文本相关应用。包括PLDA、TF-IDF、Word2Vec、Doc2Vec、词频统计、去停用词、分词处理和关键词抽取等。

（8）网络分析

提供了基于图数据结构的分析组件，这些组件一般用于解决包含网状关系的业务场景，例如金融风控、社群发现、最短路径查找等。常见的组件有最大联通子图、标签传播分类、标签传播聚类、Modularity、树深度等。

（9）工具类

工具类组件是解决组件间数据格式不一致，以及满足其他额外数据处理需求的一系列组件，是对现有其他功能组件的补充。常见的组件有自定义SQL、PySpark、表转文件、文件转表等，涵盖数据预处理、特征工程、机器学习、深度学习、文本处理、图像处理、视频处理、人脸识别、OCR识别、车牌识别、知识图谱构建与推理等。

机器学习框架涵盖用于分类、回归、聚类、异常检测和数据准备的各种学习方法。深度学习利用多层神经网络被广泛应用到图像、文本、语音等场景中。机器学习/深度学习计算框架的出现降低了算法开发入门的门槛，让开发人员可以方便地利用内置的算法SDK，大大减少算法模型的开发工作量。算法开发工具需要具备以下功能特性。

支持主流深度学习、机器学习计算框架，包括TensorFlow、PyTorch、CNTK、Chainer、PaddlePaddle、Spark、LightGBM、XGBoost、Angel、LightLDA等。下面简单介绍三种常用的框架：

·TensorFlow：TensorFlow是谷歌研发的用于研究和生产的开源机器学习库，提供了各种API，可供初学者和专家在桌面、移动、网络和云端环境下进行开发，是目前最常用的深度学习框架。

·PyTorch：它是Facebook开源的一个深度学习框架，采用动态计算图架构，具有先进的设计理念、完整的生态和接口易用性，也是目前常用的深度学习框架之一。

·LightGBM：它是一个梯度boosting框架，使用基于学习算法的决策树。它有以下优势：训练速度快、内存占用低、准确率高、支持并行计算。

实现同一个框架不同版本统一运行，可对不同版本进行统一管理。同时支持机器学习/深度学习计算框架与大数据平台无缝打通，共享存储和计算资源。

多版本实现要支持两种技术：一是基于Conda的环境隔离，可以将不同版本的算法框架打包成不同的Conda环境，支持运行时加载，不侵入已有的机器环境；另外一个是基于Docker的隔离，将不同版本的算法框架打包成不同的镜像，运行时根据需要加载不同镜像执行，该方案隔离性更好，但会有虚拟化性能的损失。

数据开发是数据中台的核心能力之一，是数据资产内容建设的主战场，是数据价值生产的核心环节。一个成熟的数据中台，具备大批量数据的离线处理、实时流数据处理、非结构化数据处理和数据挖掘等能力。本章介绍了数据计算能力的4种类型，包括批计算、流计算、在线查询和即席分析，重点阐述了数据开发过程中的三种开发模式，包括离线开发、实时开发和算法开发。

[1] 命名实体识别（Named Entity Recognition，NER）是自然语言处理的一项基本任务，指识别文本中具有特定意义的实体，对于文本信息的后结构化起着关键性作用。