数据中台行业应用与实践

智领云第六次技术直播如约而至。智领云科技解决方案架构师文征就数据中台的行业应用与实践与与会的观众进行了深入细致的交流。

在前五次的直播中,智领云科技的诸多技术大咖们分别对数据中台的一些概念、方法论以及底层所涉及到的技术,都做了很详细的讲解,也介绍了一部分智领云的产品。在本次直播中,文征力图结合数据中台在各行业落地的具体应用实践,把前五次直播所讲的内容做一个总结,然后就一些大家始终存在疑惑的问题,例如数据中台与大数据平台的区别,数据中台与传统的主数据的区别等进行结合实例的详细讲解,以帮助大家真正捋清数据中台的概念。

数据中台不只是一个技术平台

根据阿里对数据中台的定义,数据中台包含了三项核心能力OneModel、OneID、 OneService。OneModel负责统一的数据结构、管理;OneID负责将核心的商业要素资产化; OneService负责向上提供统一的数据服务,而智领云认为数据中台的核心能力是数据能力的抽象、共享和复用。这两种对数据中台核心能力的定义看似有很大差异。但如果仔细分析,就会发现两者其实殊途同归,只不过阿里定义的数据中台的核心能力是智领云定义的数据中台的核心能力的结果而已。如果不抽象,如何达成OneModel?如果不共享,为何要做OneID?如果功能不复用,OneService就无意义。所以说智领云对数据中台的定义没有限制于某一个具体的产品形态或者实现方式,可能更通用一点,可以说是对阿里数据中台概念的一个更深层次的拓展与诠释。

那么,数据中台主要解决什么问题?从阿里官网来看,数据中台主要致力于解决以下问题:

1)各个部门数据重复开发,浪费存储和计算资源

2)数据标准不统一,数据使用成本高

3)业务数据孤岛严重,数据利用效率低。

对于这三个问题,我们要先来思考一下。

首先,数据重复开发,浪费存储和计算资源的问题难道只有数据中台可以解决吗?大数据平台不就是为了解决这个问题?包括主数据,也是在解决这个问题。

其次,数据标准不统一、数据使用成本高的问题难道不应该也是大数据平台需要解决的问题吗?

第三,对于业务数据孤岛问题严重,数据效率低的问题,难道有了大数据之后,还会有数据孤岛么?还是会有数据利用低效的问题吗?

这些问题的答案都是肯定的。所以说为什么会有数据中台的概念,主要还是因为虽然建设了大数据平台,但上述这些问题却依然存在。因此,从这个意义上来说,数据中台本质上还是一个大数据平台,是个可以实现数据能力的抽象、共享和复用的新型大数据平台。

但虽然如此,我们还是要思考数据中台“新”在哪里?首先,关于抽象。无论是重复利用或者是共享,那到底是何种类型的数据才值得我们去抽象,才有可能抽象之后去共享、复用?是不是只要是把数据抽象上来,就能够做到OneModel、OneID、OneService?就可以成为数据中台的一部分?

第二,数据中台是只为共享而服务吗?共享复用只是数据中台的最初级阶段,通过共享和复用以后,实际上我们可以创造更快、更高、更新的商业模式。所以说数据中台的作用,不只是为了共享复用,它还可能会创造更高的价值。

第三,做一个能解决上述这些问题的大数据平台就可以了吗?回答是“不仅仅是“。数据中台不仅仅是能够解决这些问题,应该还要能从更高,更广泛的领域和角度去理解数据中台。

同样,大数据平台加主数据等于数据中台,这也是经常误导我们的一个概念。但实际上并没这么简单,这是因为,数据中台并不仅仅只是一个技术平台,而是一种思想。

数据中台是一种思想

就像我们多次重申的那样,在国外并没有数据中台的概念。但其中的原因可能很多人没有仔细思考过。我们认为,之所以国外没有数据中台的说法,并不是他们不存在我们在数据中台中要解决的三个问题,而是因为国外大厂从一开始,就尝试要去解决这些问题,因此,他们已经经历了解决这些问题的阶段,而且是在他们的大数据平台中就解决了这些问题,而在中国经历这个阶段的时候,由于前期建设大数据平台时考虑得不够全面,因此,现有大数据平台无法完善解决这些问题,才会在中国出现数据中台的概念。

那么,我们应该如何看待一个大数据平台或者是一款大数据/数据中台的产品?智领云认为,首先就要看这些平台和产品究竟是如何去实现这种抽象、共享、复用的能力,用什么样的方法论、什么样的组织架构、什么样的产品线去支撑这种能力。如果一开始就是用这种思想去构建系统,数据中台就应该是自然而然的产生。实际上,我们看到,许多数据中台的功能其实是为了弥补以前建设的大数据平台的不足。为什么阿里在做了如此优秀的大数据平台之后,还要去做数据中台?这肯定是因为原来的大数据平台存在不足。那么,为什么我们建设的大数据平台会出现这种情况?这才是我们真正需要进行反思的。如果大数据平台也出现了烟囱,也形成了孤岛。那我们之前所倡导的建设大数据平台可以打破烟囱、实现数据共享的目标不就是空谈了么。

数据中台的思想,其实是引导我们用另外一种视角去重新审视我们的大数据平台,去审视底层资源利用情况,去审视我们自己的业务,审视什么东西最应该去共享,什么东西最应该去抽象,它是不是和我们的战略相关,是不是和我们的主营业务相关。这就是我们最需要思考的问题。

现在,在国外,有一些大厂的大数据或者是云部门,已经从一个成本部门开始转变成了一个利润部门,各部门所消耗的资源已经完全是与产生的效益相关,而他们之所以能够完成这样的蜕变,则很大程度上归功于国内所说的“数据中台”思想。也就是从更高层次的抽象、共享、复用角度去思考,只有这样,才可以更快的去为前端提供服务,更高效的利用现有的资源。

总结来说,首先,数据中台不是一种技术,而是一种思想。如果我们还是以大数据或者是大数据仓库思想去思考数据中台,肯定是做不好的。其次,数据中台思想无处不在,为什么这么说?因为抽象、共享、复用这几个词在没有大数据的时代,甚至是代码时代就已经存在。难道中间件、封装的类、方法、库,不是共享、抽象和复用吗?数据中台无非是在更高的层面,从组织、战略角度去考虑问题,去抽象现在已有的一些组件、功能或者是数据。举一个餐饮的例子,我们把做菜的师傅暂且理解为后台,把收钱的伙计理解为前台。我们尝试着用数据中台的思想去看一下,在这个体系中是否存在中台,首先说后台,做菜的师傅,先把菜切好,前台报菜单的时候,他就可以快速的通过拼装的方式,生成一道菜。这里面的切好的菜、准备好的调料,其实就实现了共享和复用。而菜谱上的微辣、特辣、中辣等信息,其实是对菜的特性的一个抽象,是对放多少盐,多少辣椒的抽象。而前台的伙计,除了传递做菜信息以外,他还可能要做其他一些事情,比如端茶倒水,传菜上菜等,如果用中台的思想,把这些行为、能力抽象一下,其实就是服务员这样一个角色。从中台思想来看,这就是一个数据中台,起到了承上启下的作用。因此,当餐饮企业越做越大,服务员群体就会自然出现,也就是说所谓的数据中台就会自然而然的出现。

通过这个例子,我们对数据中台做一个总结,第一,数据中台无处不在,我们需要用中台的思想去思考问题。第二,中台要做的事,其实我们一直在做,只不过大多数人没有注意,我们只要注意它、抽象它、放大它,就能够形成一个数据中台。第三,中台是一种思想,是一种分析问题的视角,不建设不代表不存在、不需要。

数据中台的行业建设方法论

那么,对于需要建设数据中台的各行业的用户,到底应该怎样去做数据中台?怎样通过抽象、共享、复用,最后达到OneModel、OneID,OneService这种境界呢?这肯定需要一套完整的方法论。

从智领云的角度,我们认为这个方法论有三点非常重要的地方:

首先,是从上至下,先思考的战略。

我们反复强调,只有从上至下的思考,你才不会被一些细节和业务形态所困惑。

其次,要通过战略,寻找服务主体。

其实,无论是做中台也好,还是做其他什么事情也好。如果我们没有依次思考过它的服务主体,服务内容,服务资源以及服务方式,就仓促的去做,效果肯定不会太好。我们需要以这种思考方式,找出动词和名词,从而构建数据中台。

第三,数据中台不是一撮而就的。

我们说中台是一种思想,是从新的角度去重新认识自身的资源和能力,最后将之落在实体之上的过程。而认识也是一个过程,因此,需要采取循序渐进的贯彻始终的迭代思想来进行数据中台的建设。

 

直播问答精选

 

1.对于政府客户,建成了繁杂多样的业务系统(100+个系统),怎么快速实现全域数据汇集和OneID的拉通?

我们的数据门户产品就是解决这个问题的,数据门户可以将业务数据库,数仓,分析程序,数据请求的信息抽取出来,经过整理后形成一整套的数据汇聚和展示。

 

2. 如何看待数据中台和数据治理的关系

数据中台的建设过程中的数据治理是一个关键流程,但是数据中台的数据治理一定是面向全局的,与传统的单业务域的数据治理是有一定区别的。我们认为数据中台的数据治理不一定是一蹴而就,也是可以通过业务驱动,逐渐迭代的。

 

3. 抽象的对象到底是数据还是能力?

都是必须的,可以抽象数据,也可以抽象能力。中台思想是需要思考什么东西可以抽象,可以共享,复用。这是个思考角度。能力包括技术能力、技术能力等。

 

4. 数仓工程是ETL,数据中台是ELT,这个技术选型有什么差异?

之所以有这个ELT的说法是因为数据中台一般都涉及到数据湖的建设,在这个过程中一般会先Extract (采集,提取)然后不经修改的 Load(加载)到数据湖,在数据湖之上再来(Transform)到数仓。但是如果考虑从数据湖到数仓的流程,其实还是一个Extract (从数据湖)到 Transform (转换,汇聚,分析),到Load(加载到数仓)的过程。而且,数据仓库的建设也是数据中台建设很重要的一部分,我们认为ELT和ETL都用得到。

 

5. 数据中台和传统大数据平台区别,能否理解为SaaS模式和传统项目模式?

有这种说法,数据中台可以理解为企业内部的一种DaaS(Data-infra as a Service)。但是我们认为数据中台的建设实际上也是需要各个业务部门参与和持续维护的,与一个拿来就用的SaaS模式还是有一定区别的。

 

6. 数据资产或标签体系有没有方法论?

在数据中台时代,不是简单的元数据管理,应用、API都算资产,什么用户用了什么应用产生了什么数据,中间加载的过程等,这一切都是数据资产。数据中台的范围更广,只有这样才能做到将OneID、OneService抽象出来。

 

7. 传统数仓服务的对象是数据分析,数据中台服务于业务系统,能否这么理解?

首先数据中台的功能应该是包含数仓服务的,甚至可以说阿里所说的数据中台的核心就是一个全局的统一的数仓(OneID, OneModel),然后在上面加上一个OneService。所以准确一点来讲,应该是数据中台可以在统一数仓服务的基础上服务业务系统。

 

8. 数据中台和业务一定相关,那边界在哪里?即数据中台和业务中台的边界?

经营活动中的动作(也就是我们说的动词)是业务中台提供和实现的,业务所产生的数据是由数据中台统一管理的(也就是我们所说的名词)。比如,用户画像就是一个名词,如何使用用户画像来实现个性化服务就是动词。

 

9. 为什么中台这个概念在中国比较流行,而在硅谷却没有这么盛行?

阿里用这个名词定义了这个阶段,但是这个事情在国外也同样发生过,硅谷公司在早期就碰到过同样的问题,国外已经走在前面解决了这些问题,只是阿里把这个阶段定义了一个新名词。但是阿里也是在实际中遇到这些问题,所以才提出中台去解决这些问题,从而让国内去重视。大家都会经历这个阶段,所以需要感谢阿里把这个阶段用新名词的方式提出。

 

11. 有很多企业建立了数据中台,但是失败的案例也不少,那失败的原因可能是什么?

按阿里的中台架构图,就是一个大数据架构,如果按这种理解去做,就是在做大数据平台,失败就有可能了。这样一个架构图可能令大家有些误解。业务数据、业务域等并没有在架构中画出,但是在背后是非常重要的支撑。也可能是没有真正理解中台、或者用大数据架构在套用,从而导致的失败。

 

12. 智领云怎样帮助用户建设数据中台,在中台落地中起到什么帮助?

智领云可以帮助客户在没有大数据平台的情况下从0-1快速落地、持续迭代,或者是基于现有大数据平台建设中台的一整套方案,并结合硅谷方法论,帮助企业用户建设数据中台,发挥数据价值。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章