赞
踩
数据中台概念由阿里提出,即实现数据分层和水平解耦,沉淀公共数据能力,提供数据模型、数据服务与数据开发功能。
数据中台到底是什么?是一种产品?还是一种解决方案型产品?数据中台其实更像一种企业架构方法论,是以"共享"(Sharing)为目标的"业务流程再造"(Business Process Re-engineering)和"企业组织重构"(Organizational Restructuring)过程。
数据中台不单单指系统或者工具,而是一个职能部门,通过一系列平台、工具、流程、规范来为整个组织提供数据资产管理和服务。数据中台负责全域数据集成、数据资产加工和管理、向前台业务部门和决策部门提供数据服务等,因此,数据中台的核心职能是数据资产管理和数据赋能。
2014年12月7日阿里巴巴集团CEO张勇(逍遥子)向公司全体员工发出的一封公开信,宣布启动中台战略,构建符合DT时代的更创新灵活的"大中台、小前台"组织机制和业务机制:作为前台的一线业务会更敏捷,更快速适应瞬息万变的市场;中台将集合整个集团的运营数据能力、产品技术能力,对各前台业务形成强力支撑。
“中台"是一个阿里生造出来的词。英文中frond-end对应"前台”,back-end对应"后台",相应地,middle-end应该对应"中台"。
2014年中期,马云带领阿里巴巴集团高管拜访了位于芬兰赫尔辛基的移动游戏公司Supercell。这家号称世界上最成功的移动游戏公司,以"部落战争"(Clash of Clans)等游戏知名。2015年6月,软银收购其股份,估值高达55亿美元。当时Supercell拥有大约150名员工,平均每人创造了3600万美元的估值。它还是一个跨国公司,在中国有分支机构,2个人。5个人就能组成一个项目团队,单位作战效率非常惊人。
“信息时代的公司架构到底应该是什么样的架构?我举一个例子:在二次世界大战 的时候,美军在打仗的时候以一个师或一个军,几万人作为一个作战单位;到了越南战争的时候,美军的作战单位已经变成几百人的营了,总参谋部直接把一个命令下到一个营去完成;等到伊拉克战争的时候,美军作战单位已经变成了一个班,而一个班真正的战斗人员不到一半,剩下都是拿着对讲机、拿着手提电脑去完成指令。作战组织的演变趋势是这样一个过程,我想公司组织的未来也会是这样。”
2015年4月23日,在阿里巴巴北京员工大会,马云也提出了自己的忧虑:“我们如何建立一个强大的公司管理、运营系统,能够让大家得到足够的支持,使大家有归属感、使大家有真正加入阿里生态系统的感觉,这些问题其实困扰我很久。”
围绕着上述战略,阿里进行了一系列的组织架构调整:成立阿里巴巴集团中台事业群,包括搜索事业部、共享业务平台、数据技术及产品部。阿里巴巴集团零售电商事业群,包括淘宝、手机淘宝、天猫三大业务部门。阿里妈妈、云计算和菜鸟三大事业群,将更为独立地发展。另外,组建集团平台治理部,重组集团公关部和商家事业部。
传统的公司以业务为分类进行组织。各业务部门负责业务线从研发、制造到销售的流程。公司的财务部、市场部、人事部、行政部等,为业务部门提供支持。事业部制度是传统的业务架构的一次进化,每个业务部门在财务上独立核算,部门之间的业务来往,通过部门间的资金流动来完成。公司对业务部门的考核通过盈利情况来实现。这种制度通过严格的财务考核保持了对业务部门的压力,同时也给予了业务部门很大的权力,在一定程度上避免了传统公司架构中的官僚主义和推诿现象,提高了效率。但也容易导致业务部门权力过于集中,而部门之间的争斗,往往损害公司的整体目标。
"中台战略"可以视为传统架构的再一次进化。这一战略的关键在于,从按职能划分的组织转变到以服务为目的的组织。"前台"包括接触客户的销售人员和直接面对需求的研发人员,在传统架构中,即业务部门的核心业务。"中台"指对前台提供支持的部门。在传统架构中,财务部、人事部等中台提供的服务虽然必不可少,但是离业务很远,也并不重要。随着商业模式和技术模式的不断进步,研发变得越来越复杂和庞大,和客户直接相关的部分也相对越来越小。
以在DT时代打造"商业基础设施平台"为己任的阿里巴巴,将数据运营能力和产品技术能力作为重中之重。传统架构中的业务导向,无法再支撑这一目标。解决方法就是,将数据运营和产品技术力量从前台剥离,成为独立的中台,转变为前台提供服务。前台则得到精简,保持足够的敏捷度,能够更快和更灵活地满足业务需求。这就是"大中台、小前台"。在这种架构下,中台不但对前台提供至关重要的支持,而且是整个公司的核心竞争力。
一个中台的服务支持了一堆前台的业务,其中有些做得好,有些做不好。如何评价中台起的作用?在中台资源有限的情况下,按怎样的顺序来满足这些前台需求。这些问题是制定数据中台战略中需要解决的一些问题。关于平台战略管理思维不在这里详细展开了。
2019年3月7日,扎克伯格发布文章《以私域为中心的社交网络愿景》(A Privacy-Focused Vision for Social Networking)中正式提出将打通旗下App。
Facebook打通旗下App,表面上是在Whatsapp上可以接收Facebook、Instagram的信息,背后是Whatsapp代表的手机号账号体系和Facebook账号体系以及数据更深层次的整合。
从某种程度上可以类比为微信上能够接受QQ的信息,并将QQ和微信的账号数据进行打通。实现难度巨大,深陷隐私与安全泥潭的Facebook恐怕也难以立刻提出多赢的解决方案,但背后的账号和数据整合,完善统一数据中台的愿景值得注意。
同为社交帝国,腾讯为什么没尝试过把微信和QQ打通?腾讯和Facebook都怎么看数据中台?
共同点:用户数据的隐私性和安全性
2018年腾讯组织架构调整进程中实现了技术打通,而对数据打通保持谨慎态度。马化腾在2018年11月的世界互联网大会上回应"数据中台论":
腾讯不能套用很多其他公司的做法,把数据直接去任意打通。因为在我们的平台里面,大量全部都是人和人之间的通信、社交行为数据,如果说数据可以任意打通,给公司业务部门或者给外部的客户用,那是会带来灾难性的后果。这方面我们要更加谨慎,这是作为很多平台运营方来说,要始终关注的问题。我们要从用户的角度来考虑,把个人信息和数据保护放在优先地位。
经历过剑桥事件和选举丑闻的Facebook对于用户数据的不当使用有着切肤之痛,而微信官方对于诱导分享、强制跳转、关系链导出、多重分销等行为毫不留情的封杀也说明微信的"克制"并不仅是口头上说说,两大走过十几年风雨的社交巨头在用户数据安全性的重要程度上认知一致。
差异点:腾讯不打通账号体系,Facebook选择脱敏后继续做
Facebook在2012年后的崛起离不开信息流广告的爆发,背后是海量用户数据支撑着NewsFeed推荐算法的不断改进。对于有着数据基因的Facebook,用户数据哪怕是个雷区也要将其充分利用起来,通过内部开放文化、技术流程建设和严格的组织制度确保数据中台正常运转。
数据的脱敏处理是Facebook内部使用数据的前提,数据中台在数据脱敏的前提下实现数据内部开放。数据收集后进行脱敏处理,各个Team都可以使用数据进行优化算法测试产品,但任何一个员工接触到一条权限范围外的信息都将被开除,以此保护用户数据隐私的安全性。
腾讯选择不打通QQ和微信两大账号体系,马化腾解释是出于通信和社交关切用户隐私,不想打开潘多拉魔盒。但现在腾讯实际推行数据中台,也在面临强大的内部阻力。在传统"赛马机制"作用下,每个部门的内部数据成为底牌和核心资产,依靠信息黑盒获取竞争差。在流量入口资源紧俏的背景下,同级竞争资源时底牌更不可能暴露给对方。
在业务层面的考量上,B端业务和C端业务都有不同的数据安全等级,数据的独立性需要隔开,怎么数据以什么口径对外沟通,怎么保障数据不外泄设计到的问题都很大。
在《以私域为中心的社交网络愿景》这篇文章中,扎克伯格一并阐述了Facebook未来的发展愿景, Key Point分享如下:
企业架构理论强调企业业务能力模型的梳理。
企业业务能力模型构建,需要和企业的产品模型构建相融合。因为企业对市场提供的产品和服务是企业能力整合后的外在表现;而企业自身的能力组件是企业的内聚能力核心。
企业支撑多业务板块(通常是按照企业的产品和服务型态切分)对外提供的产品和服务的内部能力是有共享性的。
按照企业业务能力模型演进原理:
(1) 内部专业性提升,是指某个能力的标准化、共享化和服务化的过程,并且伴随着这个过程逐步提升自身专业性能力。
(2) 外部专业性提升,重点强调的是企业聚焦于能够形成自身核心竞争力的能力,把没有必要提升竞争力的领域靠生态资源去协同。
因此中台进行共享能力的提炼、集中、服务建设就是企业内部专业性和外部专业性提升的必然过程。
中台的核心定位包括几个词:
(1) 中台:既可以支撑前台作业,也可以支撑后台决策。
(2) 能力:核心是企业内部某种能力提炼。
(3) 共享:这种能力在企业内部有共享的需求。
(4) 服务:以服务的方式对外提供能力展示。这种服务只有先标准化才能被封装,只有被封装为能力组件,明确自身功能定位(解决什么问题)、调用输入接口是什么、调用的输出接口是什么,才能以服务的型态被共享。
(5) 数据:服务在企业内的调用,都伴随着数据流动。重点是输入、输出、自身处理逻辑、沉淀数据内容。
(6) 组织:谁负责提炼这个能力(企业架构负责人)、谁负责持续运营管理这个能力。没有共享组织的持续支撑,构建这个能力就没有业务责任方。
(7) 赋能:让企业的前后台用户深入理解这个功能对其业务实现的价值,推广和持续性的优化赋能是组织之间协同的必要性。
企业需要有业务能力模型梳理,识别共享服务能力。
企业需要微服务架构,共享能力以能力组件的型态封装,为前后台提供服务。
如果服务需要弹性扩展,企业需要有支撑服务的云化基础。
能力的组件化封装,必须伴随着业务标准(含业务处理流程和规则)、数据标准梳理的过程。
建设数据中台主要就是从数据模型、数据资产、数据治理、数据服务四部分出发。
(1)数据模型
数据模型,就是我们熟悉的数据仓库中的模型,按照数据仓库规范分层开发模型,实现数据的标准化,多采用维度建模。还有一些挖掘模型,如果用的多了,也可以沉淀到数据中台中。我们可以看出数据中台中的模型具有通用性。
(2)数据资产
在数据仓库中我们已经建立了一些模型,但是只有打通数据孤岛后才可以称为资产。数据资产更准确的定义应该是可以产生价值的数据,数据资产即数据价值的现值。需要开发一些指标库,这些指标可以组合处理满足外部人员个性化的指标。需求还包括一些元数据,比如模型信息、血缘关系、数据存储以及访问情况等。
(3)数据治理
数据治理主要是为了保障数据资产的完整性、准确性、一致性、及时性。根据指定的规范开发模型、校验模型、管理模型。
(4)数据服务
数据中台最重要的就是要对外提供统一的服务能力。数据服务包括提供给开发者,让开发者能够快速、简单的访问数据服务;对于业务分析人员可以让他们轻松的进行算法分析,包括模型管理、可视化编排流程,算法模型发布等功能。
最主要的是思维理念不同,数据仓库是"分析数据",数据平台是"管理数据",数据中台是"经营数据",数据中台是为了提供服务或前台经营而生。
数据仓库是一个相对具体的功能概念,是存储和管理一个或多个主题数据的集合,为业务提供服务的方式主要是分析报表。
数据仓库具有历史性,其中存储的数据大多是结构化数据,这些数据并非企业全量数据,而是根据需求针对性抽取的,因此数据仓库对于业务的价值是各种各样的报表,但这些报表又无法实时产生。数据仓库报表虽然能够提供部分业务价值,但不能直接影响业务。
数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台,为业务提供服务的方式主要是直接提供数据集。
数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题,所以先撇开业务需求、把企业所有的数据都抽取出来放到一起,成为一个大的数据集,其中有结构化数据、非结构化数据等。当业务方有需求的时候,再把他们需要的若干个小数据集单独提取出来,以数据集的形式提供给数据应用。
数据中台是企业级的逻辑概念,体现企业价值变现D2V(Data to Value)的能力,为业务提供服务的主要方式是数据 API。数据中台距离业务更近,为业务提供速度更快的服务。
数据仓库是为了支持管理决策分析,而数据中台则是将数据服务化之后提供给业务系统,不仅限于分析型场景,也适用于交易型场景。
数据中台可以建立在数据仓库和数据平台之上,是加速企业从数据到业务价值的过程的中间层。数据中台是在数据仓库和数据平台的基础上,将数据生产为为一个个数据 API 服务,以更高效的方式提供给业务。
数据中台有以下特征:
(1)从数据来源来说,数据中台的数据来源期望是全域数据包括业务数据库,日志数据,埋点数据,爬虫数据,外部数据等。数据的来源可以是结构化数据或者非结构化的数据。而传统数仓的数据来源主要是业务数据库,数据格式也是以结构化数据为主。
(2)建立数据中台的目标是为了融合整个企业的全部数据,打通数据之间的隔阂,消除数据标准和口径不一致的问题。
数据中台通常会对来自多方面的的基础数据进行清洗,按照主题域概念建立多个以事物为主的主题域,比如用户主题域,商品主题域,渠道主题域,门店主题域等等。
数据中台遵循三个one的概念: One Data, One Entity, One Service,就是说数据中台不仅仅是汇聚企业各种数据,而且让这些数据遵循相同的标准和口径,对事物的标识(这里Entity其实指ID标识)能统一或者相互关联,并且提供统一的数据服务接口。就像做菜一样,按照标准化的菜名,先把所有可能用到的材料都准备好。而传统的数仓主要用来做BI的报表,目的性很单一,只抽取和清洗该相关分析报表用到基础数据,新增一张报表,就要从底层到上层再做一次。
(3)在数据应用方面,建立在数据中台上的数据应用不仅仅只是面向于BI报表,更多面向营销推荐,用户画像,AI决策分析,风险评估等。而且这些应用的特点是比较轻,容易快速开发出来,因为重要的数据分析工作在数据中台已经完成并且沉淀,之前工作成果都能被多个应用共享。
而传统的数据仓库主要是面向报表,数据应用的建设就是传统烟囱式建设,每次都从头再来的开发方式。
(4)数据中台是建立在分布式计算平台和存储平台,理论上可以无限扩充平台的计算和存储能力。而多数的传统数仓工具都是建立的单机的基础上,一旦数据量变大,会受单机容量的限制。
(1)大数据和小数据
大部分企业还处在内部数据尚未充分利用的阶段,还没走到需要采集利用物联网数据。数据的应用应当秉承"大数据思维,小数据落地"的思路,从业务价值出发,大中台从"小数据"、“小场景”、“小展示”。顶层设计,全面的梳理数据创新全景蓝图,但是快速找到价值点,从全景图中的一个或多个数据集合,从小数据场景落地。
"小数据"是从数据全景图开始,以高价值数据集场景切入。大处思考,全局拉通,避免后续的数据孤岛,但是从小数据集切入,从可实现性高的场景启动。比如从"天书"或者"数据地图"的数据全景中,快速找到高优先级场景去落地,通过运筹、优化、预测等方法,挖掘小数据的价值。
“小场景"是指数据中台都需要结合具体业务场景,一千个公司有一千个数据中台,数据中台与客户的业务,企业的结构,信息化发展阶段有着紧密的相关性的业务基础架构,是很难买一个大而全的产品来一劳永逸的解决的,大中台一定是面向场景的,而不是面向技术的,因此提倡"大中台从小场景做起”。
"小展示"是要分析不同用户的使用习惯,看报表之间的关联,不断的提炼,发现这些关系,将报表越做越薄,越做越少。指传统企业的数据部门或团队的价值衡量,经常用量化的报表个数,比如,为多少的角色,做了多少的主题的报表,这些报表被浏览了多少次作为绩效。真的用户体验是这样的么?真的是报表越多约好,数据越全越好么?
数据中台的边界问题:
阿里的数据中台算是成功的典范吗?数据中台的边际是动态平衡决定的,当边际价值等于于边际成本时,能得到数据中台的边界。数据中台夹在数据和应用之间,前期要付出更多的不确定性成本,包括中台建设成本、流程优化成本、IT文化重塑成本、用户培育成本、持续运营成本、还有其他一系列的管理成本等等。数据中台一个关键的考核标准是用户的使用,以及使用的价值。数据中台可以建设的东西太多了,数据中台的边界就是为业务赋能创造的边际收益大于平台开发、运维的边际成本。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。