数据中台演进之AI中台

数据中台

数据中台对一个企业,起着至关重要的作用,在数据中台这个称谓成型之前,各个企业分别都在用不同的方式来尽可能的利用数据产生的价值,同时也处理着数据带来的问题。例如各个业务系统以烟囱架构形式存在,长期以往导致数据孤岛,数据隔离,数据一致性等一系列的问题,那么当我们需要充分利用数据的时候,就不得不去考虑怎么解决这些问题。于是各个企业分别形成数据团队或者数据部分开始继续数据整顿工作,数据仓库,数据湖,主数据治理等一系列的工作应运而生。

本质上,这些工作都是因为业务需要不得不进行的一系列数据治理的动作,对于如何利用数据来发力,并没有形成一个强有力的底座。有点像头痛医头,脚痛医脚,各个业务系统规范不一致了,于是开展了元数据治理,数据分析的时候数据关联不上了,于是不得不进行主数据治理。

在进行了很多年的数据工作之后,数据中台这个概念逐渐有人提出了,可能阿里的《企业IT转型之道:阿里巴巴中台战略思想与架构实践》这本书,把这个概念推向了一个高度,似乎定下了一个参考答案。中台战略我们常说:大中台,小前台,在这种模式下非常频繁出现的字眼是:共享。那么共享到底共享的是什么?共享的便是数据的服务。中台战略并不是搭建一个数据平台,但是中台的大部分服务都是围绕数据而生,更加巧妙的地方是中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环。于是,数据和业务系统融为了一体。

上图是一个浓缩的描述,可以看到,数据中台在业务侧解决的还是能用的问题,只是有了数据中台后,我们构建出能用的服务变得更快速,更加的标准化,但是在好用方面,数据中台相对乏力。

因此在中台架构之后我们逐步认识到,原来数据的价值并不只是个运营出个参考的分析报表,做一系列的预算。数据中台为大型企业数据利用最大化提供了一个参考的案例。常说的深度学习,机器学习等等一系列技术在这个平台上似乎找到了一个发力点,开始在这里施展拳脚。

但是,中台并不是数据分析利用的终点,仔细看数据分析的历程,可以归纳发现数据利用大概有如下三个阶段:

第一阶段:响应运营

响应运营是数据分析最直接也是最原始的需求,没有谁会不关心自己的用户留存率,没有谁会不关心自己的营收额。同时对于出现故障,预测分析,同样也是非常重要的事情。但是在运营分析过程中,发现一系列的问题,例如各个业务系统的数据存储格式,存储介质都不相同,那么在进行基本的运营分析的时候则无法流畅的进行,不得不进行一系列的数据治理。常见的主数据,元数据就是发生在这个阶段,只是数据仓库将主数据和元数据治理进行了规范化。

第二阶段:响应业务

数据分析停留在运营阶段的时候,对企业来讲最大的感受就是投入产出比不对称,这个问题在大数据爆发的时间点更为凸显。例如在今天的业务场景下,传统的数据仓库已经解决不了海量数据,异构数据等一系列问题,而大行其道的大数据分析技术,门槛高,硬件需求高。要实施一个大数据平台,成立一个大数据团队,并不是一个小成本的开销,更何况现在有不少数据分析团队会通过机器学习等手段去对数据做分析来响应运营,这就加剧了成本和门槛的进一步提高。

于是像数据中台这样的思想就被提了出来,既然数据是从业务系统产生的,那么是否业务系统也需要数据分析结果呢?对于数据平台来说,数据平台本身提供两大能力:数据存储和数据计算的能力。那么业务系统的数据存储和数据计算能力是否可以剥离到数据平台,仅仅让业务系统很轻量的维护自己的业务流程操作?所以中台剥离的复杂的业务环境,再配合微服务等技术,一下子让人感受一个词:共享。

而对业务场景来说,很多时候是需要数据的服务的,例如用户的基本信息管理,用户的行为数据分析,这些数据不但可以暴露给业务系统使用,甚至可以直接丢给终端用户自行使用,而这种契合点,让数据平台变成了一个服务,提供给业务系统,而对终端用户来说,自己消费自己数据的同时也在继续产生数据,这样数据就形成了闭环。

第三阶段:创造业务

业务不会总停滞不前,因为人的生活会改变,想要的体验会改变,所以业务系统的功能会跟着改变,当我们发现数据可以逐步变成通用服务提供给业务系统的时候,就会思考,数据是否可以变成个性化服务提供给终端用户?例如不一样的得到不一样的推荐?这是一个非常简单的例子。但是当越来越多这样的服务之后,组合创造的可能性会变高,组合带来的个性化体验会更好,这就是数据服务的创造业务的阶段。

数据中台之AI中台

数据中台解决的是第二阶段的问题,对第三阶段对问题并没有特别好的支撑,因为数据中台本身还是围绕数据服务来进行的,而非围绕智能服务来进行的。举个例子,从未来来讲,系统一定会越来越个性化,甚至每一个人看到的登陆界面都不一样,系统可以根据对应的终端用户自行生产出符合该用户习惯的系统界面。那么对于这样的场景和服务产生,我们需要怎样的平台来诞生,我们的整个软件开发架构和流程是否都会重造?

从CI/CD的角度来讲,我们的CI/CD保障了我们的软件输出按照既有的设定测试结果方向靠齐,那么在个性化服务下,我们应该构建怎样的pipeline来管理和发布这些模型?这和工业4.0提出的智能制造非常类似,早期我们通过流水线的形式让各种不一样的业务,不一样的软件通过一种统一的流水线的方式运作,但是在智能制造的前提下我们期望为每一个不一样的终端用户提供不一样的服务,那么统一的流水线是否依旧适用?

AI中台便是数据中台的进一步延伸,也是为了解决上面的问题,让数据利用达到第三个阶段:创造业务。既然有创造业务就有售卖业务,如下图所示:

可以看到,上图是目前最常见的软件平台的运作方式,开发人员开发出了对应的软件服务后,提供给终端用户使用,虽然会有销售售卖该服务,但是更多的是拿着一个锤子找钉子,而不是给钉子快速制作一把合适的锤子再去售卖。

AI中台尝试提供一种能力,来达到这样一个效果:

将整个软件组装出来的服务,如同个性化的产品一样去售卖,这样的服务就是量身定做的,非你莫属的。那么整个运营模式就变成了,AI平台提供了一种快速构建智能服务的过程,服务售卖者将自己动手做出来的服务拿出去售卖,这个和paas平台非常相似,但是paas提供的是一个业务无关性的售卖机制。借助一个平台,将软件的服务个性化的创造,这可能是未来的发展趋势。

通过下图可以看到,各个企业或者行业,都在第三个阶段做了不同的探索和努力:

但是又各自遇到不同的问题,总结起来发现在落地过程中,通常存在以下问题或者挑战:

从数据中台的演进

AI中台不是一蹴而就的,也许达到最终的效果有非常长的路要走,但是我们可以考虑逐步的演进过去,首先的步骤就是可以将数据中台智能化,所谓的智能化是指将在数据中台进行的一系列的数据服务构建操作,更加的智能化,从数据的接入,存储,分析展现,训练,到pipeline都更加智能化。例如对于通用的CI/CD来说,test不过则会构建失败,那么决定一个推荐模型构建失败的条件是什么?显然现有的CI/CD并不能很好的为此服务。

其次,对于中台使用者来说,目前基于数据中台的一个智能服务模型开发来说,流程如下:

基本类似于一个横向的烟囱架构,带来的问题比较明显,因为黑盒的原因导致目前对一个模型的工作进行拆分的时候,都不是特别的顺畅,当然因为目前大部分业务场景依旧以流程为主,没有太多的智能服务,所以一系列的问题并没有明显的被暴露出来:

  • 借助于现有数据平台手工进行数据操作
  • 烟囱架构开发,对人员能力要求高
  • 环节无法有效拆分,响应周期慢
  • 智能场景规模化,管理复杂
  • 训练,部署,发布依赖于手工部署缺乏有效的流水线
  • 和数据平台孤立,缺乏统一的数据服务接口
  • 基础设施隔离,无法动态进行资源的分配和管理

从一个好的体系来讲,AI中台是借助数据中台的能力,但是具备构建智能服务的能力,AI中台尝试解决如下的问题:

  • 和数据平台结合,利用数据平台的能力作为数据支撑,最大化的发挥数据平台的价值
  • 拆分服务构建环节,智能服务开发流程化,快速响应业务需求
  • 利用元数据管理方式,提供统一的标准格式,场景可以多人协同配合开发
  • 基础设施共享化,模型的训练和发布与数据平台有效绑定,服务的构建自动化
  • 统一的元数据管理系统,模型的全生命周期可管理
  • 通用AI能力平台化,降低人员要求,提升协作效率

所以就要求我们对服务构建的过程进行如下拆分:

首先需要从基础设施层面进行集成,常规的数据中台依赖于大量的CPU和内存,而相反,机器学习模型对GPU的依赖反而更高,但是又不能脱离数据中台,因为它依旧需要利用数据中台的存储和计算能力来处理大量的数据,所以如何通过一个接口,一个调度器,一个pipeline来集成整个工作流,就成了需要考量的事情了。

从整个大的来讲,AI中台至少应该分为一下几个层级:

在数据中台的基础上扩展对GPU级别资源的管理和整合能力,调度层提供统一的任务,服务,智能CI/CD等服务,对AI平台来讲,提供的能力聚焦在:利用算法,模型,框架如何动态和快速的组装和产生出能支持创新的服务上。

结尾

AI中台是数据中台在业务上的演进,是系统服务的重组的过程,因素还是那些因素,就像工业4.0里面的螺丝钉还是那些螺丝钉,但是每个螺丝钉都被打上了个性化的标签。不过,被打了标签的钉子,还是原来的钉子吗?这是个问题,但是在落地实施过程中,我能够发现,虽然以AI中台进行落地实施,但是实际的这个过程,却是“持续智能”的一种体现,关于“持续智能”,则是在AI落地的核心思想,后续再做重点分享。

即日起至2019年2月23日前,为技术雷达十周年峰会福利发放时间!购买即可享 早鸟票七折优惠 ,峰会报名仅为¥1024.00元!(数量有限,先到先得!)

Share

白话中台战略2:中台到底长啥样?

在上篇《白话中台战略-1开篇:中台是个什么鬼?》中,我试着依据自己的经验和理解,阐述了中台产生的原因以及最终建设目的,可能会过于抽象,大家听得还是云里雾里,本文就试图通过我的收集和思考,带着大家一起来看看中台到底“长啥样”,以期让大家有个直观的印象。话不多说,咱们直接开讲。

数据业务双中台

提起中台,绕不开也是最先想到的应该都是阿里巴巴的数据业务双中台。毕竟阿里的“大中台小前台”战略人尽皆知,其威力也是显而易见的。

以阿里这么大的体量,经过了这么多年的厮杀,在互联网快速迭代创新的竞争环境中,仍然可以保持快速迭代创新,上演了一场接一场现实版的大象跳舞,中台战略的成功居功至伟。

(摘自《企业核心业务数字化转型最佳实践》)

阿里的数据业务双中台堪称经典,上图摘取自钟华(古谦)于刚刚结束的2018云栖大会《企业核心业务数字化转型最佳实践》分享。

从图中可见,阿里中台主要体现为由业务中台和数字中台并肩构成的双中台,并肩扛起了所有前台业务。

  • 业务中台将后台资源进行抽象包装整合,转化为前台友好的可重用共享的核心能力,实现了后端业务资源到前台易用能力的转化。
  • 数据中台从后台及业务中台将数据流入,完成海量数据的存储、计算、产品化包装过程,构成企业的核心数据能力,为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。
  • 业务中台与数据中台相辅相成、互相支撑,一起构建起了战场强大的后方炮火群和雷达阵。

移动中台

同样来自于2018年云栖大会杭州站,在移动研发平台EMAS专场上,阿里巴巴高级技术专家泠茗带来的分享中就为我们揭开了阿里移动中台的面纱。

(摘自《数字化转型 移动化先行 云栖大会上发布了哪些移动研发新利器》)

可见阿里的移动中台是构建在业务&数据中台之上,为更好更快的利用中台能力、快速迭代移动端产品,又生生的挤出(或是说沉淀)出了一个新的中台层。

移动中台建立在业务数据双中台之上,更靠近移动前端战场,我们可以类比成战场上的坦克群,近距离支撑一线战场。

技术中台

大中台小前台,并不代表前台不重要,相反,大中台的建设就是为了更好地服务好小前台,大中台的威力也需要靠小前台的引导才能真正发挥和体现出来。

就像是深入敌后的前台特种部队如果定位不到敌人的精确位置,就算有再强大的水陆空中台炮火群,也只是一群废铁而已。

大中台小前台战略,其实是给小前台的构建提出了更高的要求,就像我们对于特种兵的要求也比一般的士兵高出很多一样。

那如何快速构建出短小精悍,武器精良,战斗力十足的特种兵前台应用,充分发挥和释放出中台炮火群的威力,就需要依靠这里提到的技术中台。

(摘自《阿里技术手册-研发篇》)

技术中台就是将使用云或其他基础设施的能力以及应用各种技术中间件的能力进行整合和包装。过滤掉技术细节,提供简单一致、易于使用的应用技术基础设施的能力接口,助力前台和业务中台数据中台的快速建设。

如果将业务数据双中台比喻成强大的中台炮火群,可以直接对敌人进行进攻。那技术中台的作用就有些间接,有点像前台特种兵身上各种先进的武器装备。精良易用的武器装备,可以在大幅缩短前台特种兵的建设周期的同时大幅提高单兵作战能力,令敌人胆寒。

研发中台

软件开发是一项工程,涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”,从而助力创新性应用的快速开发迭代,也是我们看到的很多企业正在做的事情,我们可以管这种关注与开发效能管理的平台叫做研发中台。

如果说技术中台为前台应用提供了基础设施重用的能力,那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。

(摘自《阿里技术手册-研发篇》)

上图摘自阿里的技术手册,展示了阿里的效能事业部一直致力于构建的阿里研发效能平台,有兴趣的同学可以去了解一下阿里自家的云效平台。

(ThoughtWorks帮助客户打造的DevOps云平台)

ThoughtWorks在敏捷与开发效能方面一直走在行业领先,持续总结过去的经验,并基于客户自身的需求和实际情况、结合最新的技术,与客户一起携手成功打造了多个定制化的开发效能平台。

总之,开发效能是构建前中台应用过程中必不可少的重要一环。这方面的实践和能力通过沉淀,结合快速开发框架平台,例如微服务开发平台,就形成了企业的研发中台。

如果将技术中台比喻成前台特种兵的武器装备,那效能中台就是前台特种兵的管理训练基地以及可以快速将战士运送到一线战场的机动运输部队。

组织中台

以上无论是业务中台、数据中台、技术中台、研发中台……都是围绕技术展开的,也是企业在中台建设中最关注的方面。

但真正实际经历过几次企业级中台的建设后,我深刻的体会到:围绕技术展开并不是基于在中台构建中技术的重要性,而是因为技术的改进相对简单。

而中台建设真正困难的是组织上的重构,这往往是大家有意无意避而不谈的。

中台战略的成功、能否实现技术架构与组织架构的匹配,是一道绕不过去必须要迈过的门槛。从阿里成立共享事业部,海尔的人单合一、职能并联到近期大家关注的腾讯的组织架构重构都是这些企业在这方面做出的努力。

举个实际的例子,在很多企业中一个新项目的启动,从筹划到申请经过层层审批和评审短则一两月,多则需要几个月的时间。要知道在当前所处的互联网时代,几个月都够人家App都上线了。

(摘自《释放潜能-平台型组织的进化路线图》)

为了真正解决企业创新在组织层面的摩擦和阻力,构建真正的平台型组织。《释放潜能-平台型组织的进化路线图》提出了上图这样一个平台型组织的组织结构。

组织中台很像企业中的内部风投和创新孵化机构,为前台组织和团队构建创新型前台应用提供类似于投资评估(项目甄别)、投资管理、投后管理(孵化与风控),真正从组织和制度上支撑前台组织和应用的快速迭代规模化创新。

知易行难,ThoughtWorks在科技时代精益企业背景下提出的“价值驱动决策”框架并用“EDGE”命名,主要针对如何在市场高速变化时保证投资有效性,即致力于帮助客户在组织上和投资管理上真正的助力创新,也算是在组织中台建设上迈出的一步。

如果还用前边军队的比喻,那组织中台是什么呢?可能你已经想到了,对,就是战场指挥部。

到底中台长啥样?

列举了这么多各式各样的中台,最后都扯到了组织层面,是不是有种越听越晕的感觉,是不是感觉什么东西加个“中台”的后缀都可以靠到中台上来,估计很快就会看到例如AI中台,VR中台,搜索中台,算法中台……对了,算法中台已经有了……

让我们引用一段阿里玄难在接受极客公园采访时提到对于中台的一段我非常认同的描述:

本文中我们一直提到的一个词就是“能力”,从玄难的这段采访也可以看出,在阿里“能力”也是中台的核心。

甄别是不是中台还要回到中台要解决的问题上,也就是我上篇文章主要关注的问题。我认为一切以”以用户为中心的持续规模化创新”为目的,将后台各式各样的资源转化为前台易于使用的能力,帮助我们打赢这场以用户为中心的战争的平台,我们都可以称之为中台:

  • 业务中台提供重用服务,例如用户中心,订单中心之类的开箱即用可重用能力,为战场提供了强大的后台炮火支援能力,随叫随到,威力强大;
  • 数据中台提供了数据分析能力,帮助我们从数据中学习改进,调整方向,为战场提供了强大及时的雷达监测能力,帮助我们掌控战场;
  • 移动及算法中台提供了战场一线火力支援能力,帮助我们提供更加个性化的服务,增强用户体验,为战场提供了陆军支援能力,随机应变,所向披靡;
  • 技术中台提供了自建系统部分的技术支撑能力,帮助我们解决了基础设施,分布式数据库等底层技术问题,为前台特种兵提供了精良的武器装备;
  • 研发中台提供了自建系统部分的管理和技术实践支撑能力,帮助我们快速搭建项目,管理进度,测试,持续集成,持续交付,是前台特种兵的训练基地及快速送达战场的机动运输部队;
  • 组织中台为我们的项目提供投资管理,风险管理,资源调度等,是战场的指挥部,战争的大脑,指挥前线,调度后方。

所以,评判一个平台是否称得上中台,最终评判标准不是技术也不是长什么模样,最终还是得前台说了算,毕竟前台才是战争的关键,才是感受得到战场的残酷,看得见用户的那部分人。

前台想不想用,爱不爱用,好不好用,帮了前台多大的忙,从中台获得了多大的好处,愿意掏出多少利润来帮助建设中台,这才是甄别中台建设对错好坏的唯一标准。 对于中台来讲,前台就是用户,以用户为中心,在中台同样适用。


参考阅读


更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

Share