一文读懂 | 数据中台如何为企业赋能？

上一篇在【案例篇】数据中台的行业应用场景中介绍了数据中台在一些行业里的应用场景，但是很多管理者和开发者对于数据中台到底是如何工作的，还只有个很模糊的概念。本次就从互联网企业的视角，看看数据中台是如何为各个部门赋能的。

组织架构

很多企业在羡慕阿里巴巴、字节跳动等企业拥有全局数据能力和快速迭代能力的同时，却发现自己现有的架构无法满足建立全局数据能力的要求。伴随着粗放式的管理成为过去式，人口红利逐渐消退，烟囱效应造成部门墙、数据孤岛，数据维护成本增加及数据价值发掘难度增大，企业数字化运营的压力越来越大。

在阿里巴巴的模式下，业务部门必须用数据中台团队提供的数据能力。图中展示了阿里的技术中台、数据中台、业务中台与各个业务板块的关系。根据这张图，我们可以设想，如果中台出现问题且无法及时解决，业务部门的运作将会受很大影响。那么，业务部门为什么要冒险去尝试类似数据中台这样的新架构？如果没有马云的全力支持，很难让阿里巴巴的业务部门冒着业务受影响的风险来尝试这个新架构。而且，并非所有公司的技术团队都如阿里巴巴般强大，并非所有的公司都能像阿里巴巴一样强势要求业务部门无条件配合。这就产生了一个问题，对于一般的企业来说，究竟应该如何打造类似于数据中台的能力？

阿里巴巴数据能力共享示意图

实际上，数据中台复用的这些能力并不一定要由专门的数据中台部门来抽象和提供，也可以由业务部门来提供。比如在Twitter，用户分析部门做用户画像，反欺诈团队做识别机器人和恶意账号的API，完成之后分享接口，其他部门也可以使用。因此，建设数据中台并不一定要像阿里巴巴一样重组机构，设置一个专门的中台团队，将一些通用能力划分给这个团队管理。但如果一个企业想要建设符合自身需求的数据中台，那么按照企业的组织架构来规划数据中台就很有必要。因为数据中台的目标是实现高效的数字化运营，使企业中绝大部分人员能够用数据来支撑自己的日常工作，所以了解数据中台在这些组织架构中的运作方式、选择最适合自己的中台组织架构，将对企业规划数据中台的建设很有帮助。不过需要强调的是，这种由下而上的抽象和共享虽然很常见，但也不是万应灵丹，还必须由相应的工具和流程来支撑。

下面，我们以一般互联网企业为例来说明数据中台如何为各个部门赋能。

一般而言，在一个互联网公司中我们会看到如下部门设置。

决策部门

CEO、COO、CFO、CTO、CIO等。

业务部门

产品部门：产品决策、设计
运营部门：产品运营、会员运营、用户增长等
销售部门：销售、客户服务
市场部门：渠道、推广、商务合作
财务部门：预结算、资金管理

研发部门

IT部门：公司内部IT、产品运维
产品研发：架构、开发、测试
大数据部门：提供数据能力支撑

下面我们看看企业的各个部门是如何使用数据中台

能力来提高工作效率、达到更好的工作效果的。

决策部门

在数字化运营的企业里，数据对于决策层的重要性不言而喻，日益普遍的CDO（首席数据官）和CDS（首席数据科学家）职位的设置就是很好的证明。2015年，美国政府将来自LinkedIn的数据科学家DJ Patil任命为白宫的CDS，就是希望他在互联网企业的数据经验能够帮助政府和其他行业做出更科学的决策。对于企业的管理决策层而言，数据中台可以为其赋予五大能力。

（1）快速智能的商业决策支持

数据中台能够为管理决策层提供全局、多维度的报表来反映各条业务线的情况，比如告诉管理决策层哪个广告渠道带来的转化率最高，并快速提供可视化报表。除了传统的业务报表之外，数据中台还能够利用全局的数据整合能力提供超出传统数据仓库的智能和全局商业洞见。例如，在整合了用户行为、销售管理、供应链数据之后，数据中台可以提供类似于“某个地区供应链问题造成用户活跃度显著下降”的自动报警功能，这种功能在传统的商业报表中是很难事先定义或者自动发现的。还有一个例子是，企业决策部门经常需要判断现有系统是否能够支持以及能够多快地支持某个产品，这时，数据中台提供的数据能力全景视图是非常关键的。

（2）精细化的运营和管理

实现每个产品线的数字化运营标准，对全公司进行高效的数字化运营。例如每个产品都必须有量化的运营指标，必须进行A/B测试等；对运营数据进行自动分析和报警；形成完善的数据标准和数据应用资产体系，打通各条业务线的数据，最大限度发挥数据的价值，并在做出重要决策的时候能够快速得到数据的支持。

（3）产品线的快速迭代

在数据中台的支撑下，新产品能够利用现有的数据能力快速上线，而且能够利用现有的数据积累加快推广和实施的过程，比如实现各条产品线和各个部门之间的协同与市场拓展，快速满足市场需要。举个例子，产品经理在设计一款新产品时，需要判断目标用户与现有用户的重合度以及其在目标区域的分布来决定产品的推广方式。同时，上线之前还需要做A/B测试，上线之后必须马上拿到性能反馈，而且这些功能最好能够充分利用现有工具快速实现。这些都需要通过数据中台打通不同部门之间的数据协调、前后端数据来实现。

（4）内部数据能力的共享和复用

解决重复造轮子的问题。通过数据中台，管理决策层可以清晰看到公司目前有哪些数据资产，哪些业务已经有了数据、应用和接口，如何提升某条业务线的运营效率，还有哪些数据需要收集、处理和分析。同时，还能够避免重复造轮子，及时发现冗余或者无用的数据。比如，在双12需要向中年用户进行推销活动的时候，可以复用双11向年轻人进行推销活动开发的服务，并且只需微调即可快速上线，无须重新开发。不过，需要注意的是，在强调内部数据能力的共享和复用时，还要关注各部门快速自主迭代和全局统一规划的矛盾。

（5）完善的ROI管理

大数据项目通常需要大量资源，因此我们经常会看到巨大的开销和不清晰的部门和项目分配。为了最合理地使用资源，确保核心业务的性能，我们需要数据中台为每个数据应用进行精确的ROI规划和管理。

以上功能会随着数字化运营程度的不断提高而日益完善，但是企业管理决策层对这些能力的重视和理解肯定是数据中台项目的一个核心驱动力，这也是我们说数据中台是个“一把手”工程的原因。

公司管理层一般以何种形式来使用这些能力？在宏观上，当决策层需要做数据支持的决定时，会有很多关于市场、产品、用户、人员、资源量化的问题，这些问题应该由数据中台快速、准确、全面地回答。一个CEO曾这样向我们解释他们公司需要建设数据中台的原因：“每次需要实现一个业务功能时，我们的IT部门都可以在一两个星期内做出反应；但每次我有一个数据问题时，他们都要花上四到五个星期才能给我一个解决方案。这个时候我就意识到应该有个系统的数据解决方案了。”

在具体形式上，一般都会有专门服务于决策层的数据分析师（团队），所有决策层的问题由这个数据分析师转化和分解成具体业务指标的查询，并将各个业务部门的数据指标进行汇总整理，然后以管理层最容易理解的形式呈现出来。这个数据分析师的角色有时就由CDO或CDS来承担，这是因为只有对公司的全局业务和具体数据模型有相当深刻的了解，才能保证数据及其产生结果的准确性。一般情况下，在转化和分解决策层的问题时如果发现有些问题很难回答，这其实就是发现了现有数据系统的不足和缺失，这个时候就需要CDO或CDS来改进和完善公司数字化运营的机制。

在工具方面，管理层有时会使用通用的数据工具，而更多的时候数据平台团队会为其定制包含核心指标的可视化看板、实时/定时报表以及一些工具。例如，在Ask.com早期使用大数据平台取代传统BI的时候，最先实现的就是每天早上的定时报表（包含CEO最关心的一些通用运营指标以及重要市场活动的每日更新）、每个星期一的市场营收周报（按可配置的多维度分析）和用户画像报告以及一些重要市场活动的实时数据分析看板（管理层可以随时查看）。一般来讲，这个层次的工具很难有通用产品，其形式和数据的使用是高度个性化的，而且会随着市场的变化而变化，因此最好由专门的团队来支持管理层的数据需求。但是，一个好的底层架构可以让这个定制开发流程更快捷，让数据的准确性、实时性和可解释性有更好的支持。

业务部门

数据中台能够为业务部门和IT研发部门提供的主要功能可以根据一个产品的生命周期来划分。产品生命周期理论是美国哈佛大学教授Raymond Vernon于1966年在其《产品周期中的国际投资与国际贸易》一文中首次提出的。产品生命周期（Product Life Cycle）是产品的市场寿命，即产品从进入市场到被市场淘汰的整个过程。产品一般要经历开发、引进、成长、成熟、衰退几个阶段。

以互联网产品为例，对于一个具体的产品来讲，其生命周期基本可以划分为前期调研→立项→需求研发→开发→测试→发布→运营。对于一家公司来讲，必须快速应对变化，这就要求其对产品的生命周期有更精细的掌控。但是在一个充分数字化运营的环境中，产品的迭代周期会越来越短，传统的瀑布式开发流程已经在很多地方被抛弃，快捷开发、敏捷迭代逐渐成为主流。这时，数据中台就会承担起决策依据的重担。

对于业务部门来讲，它们对数据中台的需求贯穿了整个产品生命周期。数据中台能够为业务部门带来如下能力。

获得市场洞见：通过对现有用户和市场数据的分析，了解市场和用户的情况。
预测产品的市场：在将产品全面推向市场之前了解市场可能的反馈。
监控产品的性能：在产品推出后快速了解产品运营的各种指标。
持续跟踪用户行为及反馈。
自动发现市场的异常并快速响应。

上述大部分功能涉及数据的全面整合和持续集成，这些功能以自助工具的形式提供给各个业务部门。例如，我们可以汇总用户在所有产品里的行为，生成全面的用户画像，并根据用户画像给用户打上标签。然后，运营人员可以使用标签体系定位到某个特定的用户群体，并针对这个群体采取相应的市场营销方式，如发送促销邮件或通知等。

实际场景：产品的决策

在Twitter的产品迭代过程中，数据平台起到了核心作用。从产品想法的产生、这个想法的初步验证，到实现一个可观察到的概念验证（POC）、产品的上线，再到产品性能的持续追踪，业务部门都离不开数据平台提供的功能。一个新产品想法可能有很多来源，比如对竞品和用户行为数据的分析、用户的反馈或者产品经理的灵感。有了想法之后，产品经理要做的第一件事就是量化这个产品可能会产生的影响。例如，一个产品经理想做一个有关电影推文的IMDb集成，为对电影感兴趣的用户提供更好的体验。在开发这款产品之前，产品经理可以到数据平台上看一下产品推荐部门做的用户画像，看有多少用户可能会对电影感兴趣，然后到广告部门提供的数据里看这些用户点击广告的概率有多大，最后到用户增长部门提供的数据里看看喜欢电影的用户人数最近的增减情况。有了这些数据之后，产品经理可以很快判断这个产品能否为公司带来显著的用户或营收增长，而不是靠拍脑袋决定要不要开发这款产品；还可以对投入的人力和资源有一个大概的估算，让公司在立项的时候有一个更好的决策依据。

不过，并非各个业务部门需要的所有数据功能，数据中台都能马上提供。这时业务部门可以独立开发和测试自己需要的功能，只需符合数据中台要求的数据标准即可。这些功能将会呈现在数据能力全景地图里，其他部门可以直接使用。例如，数据分析中有一个常用功能是过滤掉来自某些固定IP段的请求，因为这些IP段一般都是由机器人、合作伙伴或内部使用的。维护这个网段的工作往往是从反欺诈部门先开始的。反欺诈部门将这个网段列表以及相应的数据服务API做好之后，其他业务部门的数据分析或数据应用也可以使用，因此它们的应用就没有必要重新开发和维护该功能了。更重要的是，通常所有部门必须使用统一的数据功能，例如上述过滤网段功能必须全局统一，否则统计的口径就会出现差异。

研发部门

产品研发部门希望能集中精力在业务逻辑的开发上而无须考虑数据处理的细节，因此数据中台应当具备与DaaS（Data as a Service）平台相似的能力：

需要的数据都能够随时获得，并且能保证数据的可用性及正确性；
要有方便的数据处理流程，有一套标准，能够很方便地进行数据处理；
要有数据服务，提炼出有价值的数据后，能够通过数据服务将其开放出来进行共享和使用；
要有数据应用，能轻松地进行A/B测试、做大屏、进行数据监控等。

在开发业务应用的时候，研发部门一般会有更多数据方面的要求，也就是数据的建模以及对业务逻辑的还原。它们会考虑产品上线之后的数据分析需求，并在开发的时候加入相应的数据埋点、数据记录和日志条目。但是，研发部门不需要担心这些记录的数据是如何采集、存储和汇总的，这些都应该是数据中台自动处理的工作。

如果研发部门的数据记录机制符合数据中台的要求，那么数据中台可以提供自动或半自动的数据汇总、测试、监控功能。当然，这需要借助一些内部框架。例如，在Twitter内部的数据平台中，如果业务部门的数据是按照标准方式记录的，那么数据就可以自动对接到一个A/B测试框架中，系统上线后数据中台可以自动进行A/B测试、产生报告，并产生标准的监控大屏。

在具体形式上，一般大数据平台部门应该提供一个类似于“数据驱动应用开发标准和SDK”的文档和一个类似于“数据驱动应用工作台”的Web工具。业务部门按照这个开发标准来设计记录数据的建模，然后按SDK中的接口安排好数据的记录，一般是将数据按指定格式写到一个指定的端口或者文件，后台的大数据流水线就会按照协议自动采集、汇总、分析这些数据并产生预制的报表。研发部门可以到“数据驱动应用工作台”上查看数据的情况和具体的报告，如果有特殊或者定制的需求，也可以使用相关的工具进行自助的ad-hoc分析。

大数据部门

在数据中台的建设中，大数据部门处于核心位置，但是大数据部门的工作除了搭建大数据基础能力平台之外，更要侧重于全局的数据能力统一管理和赋能。

传统大数据团队的主要任务一般如下：

安装和运维Hadoop、Hive、Spark、Kafka这些大数据基础组件；
提供ETL工具的运维支持，有时候帮助业务部门写一些查询，进行一些查询的优化；
提供大数据平台集群用户的管理、权限的分配及数据的管理与备份等；
负责大数据系统的运维、扩容和升级，帮助业务部门解决系统问题。

而在数据中台的运营中，大数据部门除了上述工作之外，还需要

建立数据标准并确保数据标准的执行；
提供自助的数据工具供各个业务部门使用；
开发支持业务系统的数据处理框架、测试框架、数据分析框架，避免各个业务IT部门重复开发；
确保各个业务部门能在数据平台上发布、共享它们的通用数据能力；
提供数据应用发布、运维、更新的全生命周期管理；
精细化运营整个大数据平台，确保每个数据应用的ROI都得到追踪。

这些工作对大数据团队的技能要求提高了，而且数据和业务的结合是全方位的，对数据平台的扩展性、稳定性、实时性、可用性有了更高的要求，这也是本书要着重介绍的内容。

并不是处于任何阶段的任何企业都需要马上建设数据中台，数据中台提供的是建设数据能力最合适的方法论和体系架构，因此我们建议所有计划实现数字化运营的企业都采用数据中台的方式来建设适合自己的大数据平台和数据仓库。

本次介绍了几种常见的由数据中台提供的数据能力及其使用场景。这些数据能力是企业推进数字化运营、在市场竞争中获得先机的利器。一家企业之所以决定建设数据中台，一般是因为业务部门需要这些能力，而现有的数据系统无法提供快速高效的支持。

因此，我们应该在数据中台建设之初就明确定义需要提供的业务能力及应用场景，这样才能做到有的放矢，正确衡量数据中台建设的效果。

以上内容摘自《云原生数据中台：架构、方法论与实践》部分章节。

关于作者：彭锋，智领云科技联合创始人兼CEO。武汉大学计算机系本科及硕士，美国马里兰大学计算机专业博士，主要研究方向是流式半结构化数据的高性能查询引擎，在数据库顶级会议和期刊SIGMOD、ICDE、TODS上发表多篇开创性论文。2011年加入Twitter，任大数据平台主任工程师、公司架构师委员会大数据负责人，负责公司大数据平台及流水线的建设和管理。

宋文欣，智领云科技联合创始人兼CTO。武汉大学计算机系本科及硕士，美国纽约州立大学石溪分校计算机专业博士。曾先后就职于Ask.com和EA（电子艺界）。2016年回国联合创立智领云科技有限公司，组建智领云技术团队，开发了BDOS大数据平台操作系统。

孙浩峰，智领云科技市场总监。前CSDN内容运营副总编，关注云计算、大数据、人工智能、区块链等技术领域，对云计算、网络技术、网络存储有深刻认识。拥有丰富的媒体从业经验和专业的网络安全技术功底，具有超过15年的企业级IT市场传播、推广、宣传和写作经验，撰写过多篇在业界具有一定影响力的文章。

点击上图了解及购买

一文读懂 | 数据中台如何为企业赋能？相关推荐

一文读懂数据中台技术架构
一文读懂数据中台技术架构 https://www.toutiao.com/i6836923386560512516/?tt_from=weixin&utm_campaign=client_sh ...
一文读懂数据中台架构体系（收藏）
当前,大部分企业不再建设从源数据采集到分析应用的烟囱式系统,更倾向于数据集中采集.存储,并应用分层建设.这种方式一方面有利于应用系统的快速部署,另一方面也保证了数据的集中管理与运营,体现数据的资产.资 ...
一文读懂“数据分发服务DDS”（Data Distribution Service，RTPS，OMG）
一文读懂"数据分发服务DDS"(Data Distribution Service,RTPS,OMG) https://blog.csdn.net/DDS_CSIT/article ...
一文读懂数据要素（附研究文档大合集下载）
最近数据要素这个词不断出现在大数据圈里也同时出现在公众视野.各个研究机构,政府部门都在重点关注数据要素及其作用及发展,并提供各类政策性的指引,那么什么是数据要素呢? 本文将综合目前主流的研究进行归纳整 ...
大数据平台搭建_一文读懂数据平台、大数据平台、数据中台
作者 | June 来源 | 智领云科技(ID:LinkTimeCloud) 造概念,在 IT 行业可不是一件陌生的事儿,中文博大精深,新名词.新概念往往简单准确,既可以被大众接受,又可以被专家把玩, ...
一文读懂数据平台、大数据平台、数据中台
作者 | June 来源 | 智领云科技(ID:LinkTimeCloud) 造概念,在 IT 行业可不是一件陌生的事儿,中文博大精深,新名词.新概念往往简单准确,既可以被大众接受,又可以被专家把玩, ...
一文读懂「中台」的前世今生
导读:中台,通过业务.数据和技术的抽象,形成了服务能力的复用,构建了企业级的服务能力,消除了企业内部各业务部门.各分子公司间的壁垒,适应了企业,特别是大型企业集团业务多元化的发展战略. 基于中台,可快 ...
超级干货：一文读懂数据可视化
前言数据可视化,是指将相对晦涩的的数据通过可视的.交互的方式进行展示,从而形象.直观地表达数据蕴含的信息和规律. 早期的数据可视化作为咨询机构.金融企业的专业工具,其应用领域较为单一,应用形态较为保 ...
一文读懂数据治理怎么做
股份制改革对我国银行业来说只是一个开始,企业在风险管理.创造价值等方面还有很长的路要走.风险管理要求提供精准的数据模型.创造价值要求充分银行数据资产,这是数据治理的外部推动因素.此外,随着第三次工业革 ...

一文读懂 | 数据中台如何为企业赋能？

一文读懂 | 数据中台如何为企业赋能？相关推荐

最新文章

热门文章