摘要

中台的概念遍地开花,业务中台,研发中台,数据中台,AI中台,各种名称遍地开花。一个概念不会成为泡沫的一个核心的东西就是需要有具体的基础设施,业务场景来承载。也就是我们常说的:可落地。反过来看那些不可落地的概念似乎都有着这样的特性:

  • 啥都能做,啥都解决不了。
  • 每个人都有自己的理解,感觉都对。
  • 找不到一个标准的流程和实施的路线图来承载。
  • 市场发展多年,都看不到产品。

例如依旧还算处在风口浪尖的,人工智能,深度学习,看起来啥都能做,但是如果稍有经验的又会发现局限约束太多,啥都做不好。一个强大到可以解决一切的规则,必然平庸到无法解决稍微有一点特定的需求,因此如何选择合适的实施方案和场景,是最为重要的,至于是不是这个概念,相比真正要解决到问题,则不是那么重要。

数据中台的概念

今天我们来聊聊数据中台,我们的CTO说,关于数据中台本身,和中台本身的关系,就像Java和JavaScript的关系,那就是没有关系,我曾经花了很多时间去理解各个xx中台的意义,价值,落地实施,包括像理解数据中台和中台的关系,JavaScript和Java它咋的就没关系了呢,至少前四个单词长得一样不是。后来逐步慢慢的总算似乎能够想清楚一些概念和实施步骤。

首先数据中台更是业务发展到今天,曾经的技术架构跟不上业务的诉求,需要不断演进,成长。而中台似乎更像一个别人家的优秀答案,一旦在自己的企业执行的时候,不叫演进,那叫改革(我瞎说的)。改革自然有风险,毕竟有的答案是炒都炒不会的。

曾经做数据分析的时候,我们从手工算数,到Excel,再到数据仓库,甚至演进到目前的大数据平台,我们可以发现中间的改变,并不单纯的是概念的提升和总结,伴随而来的是整个操作流程,人员要求,技术体系的迭代。

因此,每当和客户沟通,或者自己输出能称之为:数据中台的解决方案的时候,我都会自己问自己,或者自己问客户这样的问题:

  • 这套方案/概念实施后,对于当前企业的角色,例如数据工程师,机器学习工程师,Java工程师,他们手上开发的内容,和之前有没有不一样的地方,作为一个数据工程师,在接收到公司说我们要实施数据中台方案的时候,我接下来的工作跟我过去一年有没有区别?
  • 这套方案/概念实施后,我们选择的编程语言,技术框架,工具和以前相比,有没有焕然一新?
  • 这套方案/概念实施后,公司的组织结构或者协作流程和以前有没有明确的区别?
  • 这套方案/概念实施后,公司的业务流程,体验和交互,相比以前是否有改变?

如果这些答案都是:没有。那么我们可以继续延续之前的工作模式,可以做任何优化,可以继续搞规划,甚至可以继续把PPT画的很漂亮,但是不能否认一个事实,那就是:我们没有做数据中台,或者我做出来的东西,那不是数据中台。

既然今天聊的是数据中台,那么就不绕过这个概念了,就来明确的定义和说说,什么是数据中台。同样按照前面的思路,对于Excel做数据分析,数据仓库,大数据平台,这个里程碑的叫法,我们不会有什么疑义。同样当我们说我们要做Excel的数据分析,数据仓库的时候,我们对其的Scope也可以在不用特别明说的情况下,大家的心里达成一个大差不差的一致性。

那么数据中台呢?如果我是数据平台,怎么样我就是数据中台了?我今天要写和昨天怎样不一样的代码,我这个数据工程师,可以在简历上写一个:参与了数据中台的开发?

我不在开篇直接就给出这个定义,而尝试用不同的段落来描述我们要解决的问题,该怎么解决,是不是每个企业都要解决这些问题,用这些维度逐步来讲述,最后我们总结初一个中台的定义。

数据中台存在的意义

曾经我画了这样一幅图,来表达数据中台的一个历史演进路线,可以看到在不同的时间点,我们对数据的诉求是不一样的:

image

无论什么时候我都会强调上图的一个核心概念,那就是上面的四个阶段仅仅代表各个企业对数据的不同阶段诉求,各个解决方案没有高低贵贱之分。至今为止仍然有大部分企业,依旧靠着Excel流畅的进行着数据分析,用来支撑企业辉煌的业务,这就是合适他们的解决方案。因此,从解决问题的视角来看,我们重要的是找到合适自己的阶段,和要解决的问题,而不是一味的追求概念。

那么回过来看看,我们现在有什么样的诉求?总结总结,似乎想做数据中台,或者做了数据中台的企业,大题都有这样的感官诉求:

  • 希望业务侧可以有更多的数据赋能体现。
  • 希望数据和业务可以快速配合,灵活响应。
  • 希望数据可以变现,产生价值。

而之所以会出现上面的诉求,原因不外乎是,当下软件正在由功能即服务,正在向体验即服务转向,曾经只要有功能,能解决问题,就可以称之为软件服务,慢慢的当功能足够全,遍地开花的时候,我们便开始思考怎么可以更好用,用的更舒服,即体验即服务。

恰好,目前的各大技术,无论是大数据,还是机器学习,提供这样的一个实施层面的解决方案。而大部分企业经过这么多年的功能迭代,已经沉淀了不少号称为“大数据”的宝贝。于是干柴烈火,一点即着,于是轰轰烈类的要一场大事,在数据这个领域,用来支撑体验即服务这个东西,目前被冠以了一个高大上的称呼:数据中台。

那么就需要思考一下了,曾经我们有数据仓库,或者说大数据平台,看起来它似乎解决不了上面的问题。为什么呢?大概的原因就是这样了:

  • 大数据平台/数据仓库依旧以数据挖掘和分析为主,并不是特别关心数据服务,顶多就是给一个数据库,业务自己去玩,实在一个服务,那也的手动造一个类似SpringBoot的WEB给你个API,这还的数据团队的人再三前调:给你开发Web API不是我们的本质,下不为例啊,下不为例啊 。
  • 大数据平台/数据仓库本质上的架构是以跑批类的非强低延迟的系统架构为主,基本不考虑并发,架构重技术扩展不注重业务响应。
  • 大数据平台/数据仓库的开发同学通常更加注重分布式处理的算力技术,例如常见的Hadoop这套全家桶,而不是很熟悉k8s,网络压缩,负载均衡,毫秒级低延迟等业务系统侧的架构。
  • 大数据平台/数据仓库的整体架构通常和企业的上层业务的IT规划是脱节的,最多和IT规划在 IAAS层复用,稍微好一点的可以做到PAAS级别。

想明白了上面的流程,就可以发现,无论何种原因,我们总需要一个东西,去解决上面这些问题,只是我们给他起了一个名字,叫数据中台。

构建数据中台之规划

规划这个事比起实施更为重要,因为不是每一个企业,都一定要做数据中台,也不是每一个企业都具备实施数据中台的要素。和前面讲的同理,一个企业如果真的靠Excel分析就能解决大部分问题,并且并不觉得有多冗余和高成本,又何必执着于追求概念本身。

那么从前提条件来讲,一般我们需要去构建数据中台至少有以下前置条件:

  • 规模化的数据服务开发诉求:目前在业务系统存在大规模的功能升级改造,都需要数据能力支撑,例如现在我们的业务系统有一个登陆功能,登陆功能有一个校验是验证码,都知道,验证码对登陆者就是障碍,仅仅对服务提供者有用,当我们想把这个功能升级成:只有有风险的用户登陆的时候才出现验证码。这个功能自然不能由业务侧独立完成,需要太多的依赖,那么实现这个服务的职责自然会落到数据能力线。当出现非常多这样的诉求的时候,我们就有必要独立的成立一个能力线,综合考虑来解决这一系列的问题。
  • 常态化的数据服务迭代诉求:前一点提到了大规模的服务诉求,如果这类诉求会随着业务演进不断的产生,需要持续的投入开发。
  • 不可规模化的高门槛人员诉求:搞平台,中台,基础设施除了提升响应速度之外,还有一个很重要的点就是降低人员门槛,要招一个精通底层,应用层,数据领域各个技术栈的人,很难,但是招一个只用在web ide里面写机器学习代码的人,则相对容易。因为业务诉求,企业对人员规模的增长是有一定诉求的。

有了以上的基础条件,那么我们会认为,确实需一个一个数据中台的基础设施,来解决这一类的问题。在真正实施之前,我们需要规划整个步骤,第一步就是业务价值和迭代规划,通常我们会参照以下的三维度来进行规划计划:

image

首先能够进展到这一步,也就意味着我们已经达成了一个共识,那就是:我们确实需一个数据中台这样的东西,来解决我们对问题。因此我们会按照这三维度来设定我们的排期计划,其具体的逻辑如下:

  • 业务:我们需要梳理出所有的可以做业务赋能的业务全景图,例如前面提到的验证码的例子。
  • 数据:对于前面整理出来的业务提升全景图,背后所需要的数据,当前企业是否具备。
  • 技术:对于利用这个技术要达到的业务效果,当前企业是否具备这个能力,例如这个功能需要做图像识别,目前市面上深度学习最好,企业只有有人能够掌握这个能力达到实施的效果。

通过这三个维度进行过滤,三者都满足的业务作为优先级最高的开发计划,满足其中部分的后排,同时会催生出一些其他功能,例如数据的采集等。此流程和ThoughtWorks的Inception流程类似,差异的地方事对业务的梳理和对优先级以及价值的评判的差异。

总体来说,对于数据中台的实施,我们需要遵循下面的几个小原则:

image

也就是敏捷软件研发的小步迭代,逐步交付。

构建数据中台之实施

前面经过业务的梳理,到现在进入到实施的阶段,实施也就是我们需要给自己的数据中台设计具体的技术架构。那么在这个环节,我们就可以开始思考了,我们将要一套什么样的技术架构,才能支撑上面的业务诉求?以及为什么在技术层面大数据平台和数据仓库满足不了?

image

上图展现了数据完整的生命周期的过程,仔细分析可以发现,即便是大数据平台,也仅仅到了数据分析这个阶段,而传统的数据仓库,我会更倾向于把它定位为结构化的数据治理,甚至还没有到分析这个阶段。

但是仔细分析前面的业务诉求,会发现业务需要的是一个可以支撑到数据服务和生态的技术架构。

想到这就会对技术架构的要求更加明确了,我们的这个架构至少需要有以下特点:

  • 我有一个数据集,仍到某个地方,就会给我返回一个API,我可以通过这个API对数据进行访问,这个API是广义API,可以是HTTP API,也可也是RPC API,甚至是DB和消息队列。
  • 当我扔一个数据集到某个地方的时候,他可以支持我设定这个API的权限,例如数据的行列权限,和可使用的时间范围。
  • 这个API服务在使用的时候,支持低延迟,高扩展,高并发。
  • 数据集也是广义的数据集,可以是表,可以是文件,可以是模型。

到这我们可以发现,以上问题的解决,早已有了现成的方案,那就是目前运行在业务系统微服务架构体系,也就是说从技术视角来说,数据中台的实施,本质上是打通了业务和数据在底层不复用的问题。前面我提到数据基础设施和企业IT架构无法在服务层进行复用,但是如果进行中台实施的时候,这一层壁垒被打破了。微服务架构体系,和以业务系统的非功能性要求全部在数据领域进行了落地。

作为一个数据中台开发团队,或者说升级为数据中台的开发团队来说,自己将要写的代码,使用的技术,和以前不一样了。以前我只需要写一个Spark Job,扔到Hadoop集群,导出结果一个BI工具,完事。现在需要考虑开发一个服务,让它自动的读取数据集的变更,并且提供一个服务来访问。作为一个数据开发工程师,于是不得不关心数据服务如何集成到k8s,一个模型如何在kubeflow里面运行。tfserving和spring grpc哪个更好。

我们会把数据加工的过程,抽象类比成一个现实中的工厂,就像这样的:

image

各个部门互相协作,相安无事,其乐融融,有产有销,价值链之完备。

总结到数据中台的技术架构,看这张老生常谈的图:

image

它并不是简单的拖了几个框框,而是在数据领域诠释了一个数据处理系统从产生到消费的全生命周期。

也就是说,如果没有实现数据服务的消费,没有数据服务的体系,没有数据价值的定价系统,那么这样的数据中台不能称之为数据中台,构建也毫无意义。

也许有人会有一个问题就是,我投入这么大的成本,构建了一个数据中台,没有人怎么办。不好意思,如果一个企业构建了一套数据中台没有意义,那么根本不会走到这一步,在前面的规划阶段就被打掉了。

构建数据中台之组织结构

前面提到的都是规划和实施,当一个数据中台开发趋于稳定后,后续是针对该数据中台的持续运营。因为数据中台的服务是贯穿了数据的生命周期,那么自然不会没有组织结构,或者职责的重新圈定,否则受限于康为定律,数据中台能够发挥的价值也会大打折扣。

image

一般来说,上图的组织结构是我们所推荐的,从团队来说会将涉及数据中台范畴的团队划分为如下三个:

  • 数据中台开发团队:主要承载的是数据中台本身的开发,例如如何实现一个数据服务,如何在基础设施层面打通数据在微服务架构的部署。
  • 数据中台运营团队:数据中台的拥有者,针对通用的数据服务的开发,对数据中台的运营工作进行开展。对权限,数据中台资源分配等操作进行管理,作为数据中台服务的提供者。
  • 数据服务开发团队:作为数据中台的消费者,在数据中台上构建自己的数据服务,开发和业务相关的数据服务,并且按照业务需要进行发布。

为什么叫组织结构调整呢,是因为这里面对于第一点和第二点,通常企业现有的数据能力团队可以承担,但是对于第三定,则不能由现有的数据能力团队承担,通常由业务部门进行组合而成。工作在数据中台之下,人员考核可以归于业务团队,也可以归于数据中台团队。

之所以需要从业务部门进行抽调,是因为业务团队的人更加清楚的知道需要什么数据服务,如果由业务团队传递给数据中台团队,中间需要经过信息的转换,理解,会延长交付周期,同时质量也不见得会更好。另外如果由数据中台团队承接,当业务一旦扩展起来,数据中台团队将会成为组织运作的瓶颈,变成一个庞大而产出极低的群体。

尾声

可以看到,数据中台的构建大体会有三大步骤:规划,实施,组织结构调整。因此数据中台是一个体系化的事情,而不是一个技术套餐本身。而相比大数据平台本身,数据中台无论是在技术本身,还是人员要求,都较为之前有着较大的差异。合理的实施数据中台,利用好数据中台,怎么在企业展现真正的价值,是领导者需要承担的责任。


扫码手机观看或分享: