心得体会

不是任何一个数据平台都可以称为数据中台的!(下)

| 点击:

【www.fsgl168.com--心得体会】

五不是任何一个数据平台或组件都可以称之为数据中台IT是业务的后台,数据是IT的后台。要想进行数据化管理,让数据变现,数据中台就越发显得重要了。前文提到:数据中台的内核,简单的来说,包括两方面:一个是应用数据的技术能力,另一个是数据资产的管理。从这两方面出发,数据中台至少需要拥有以下三个方面的基本特征:即业务化、服务化和开放化。这也是传统的数据仓库、数据平台和数据湖等很难兼顾的地方。三者的关系是密切相关的,不可割裂的。业务是根本,是驱动数据中台建设的根本;服务是手段,是数据中台提供共享数据服务的基本;开放是数据中台价值的体现。只有这三者都满足了才能说你的数据中台的基本条件已经满足了。1、业务化是根本业务化是数据中台希望达到的目标,指的是用业务数据驱动数据建设。这也是与数据仓库等建设的出发点截然不同的。数据仓库、数据平台等只是实现了数据的平台化,它们只是完成了从数据来到数据聚合、分类等的数据终点,并没有直接的与业务有关联。平台化现在提的很多,大多数场合提到平台化是指的公司的架构、业务的架构、产品的架构等。这些平台化比较好理解。当谈到数据的平台化的时候,就比较抽象,不少人就难以理解了。平台化思维中,很重要的一点就是把有共性的资源或者有共性的能力合并在一起,然后把这些能面向客户的价值独立出来。专业的人做专业的事情,即便于发挥这些资源的价值,也有利于企业的绩效。不揉在一块了,更加的清晰,这就是平台化的思路。在企业经营中的孵化器、阿米巴等等其实都是平台化的思维。那数据的平台化是什么呢?为方便说明,我们来看一个例子:拿一个服装成衣厂家来说,它可能有多条生产线,生产不同的服装,从原材料采购、服装设计、染色、裁剪、到成品加工有很多的环节。看似十分的复杂,但是,认真梳理的话,其实有很多的环节是类似的,有共同特性的,比如:颜色、纽扣、领口等等。我们可以把每天销售的服装,比如女装的销售数据采集回来,就可以知道每天销售最多的女装的款式是什么?颜色是什么?纽扣类型?纽扣颜色?领口式样?有否飘带?......等等。把那些数据分解后合并起来,更加专业化,并且将它们独立去维护。设计师可以根据根据这些分门别类的数据迅速的设计出明天(近期)将会流行的款式、颜色等等,预计的投放量,投放地区等等......有这样一家服装企业每年推出数万种款式,而且几乎没有库存积压。它就是这样做的。这家企业叫做ZARA。这种分门别类的数据,还可以用来给上游厂家使用,使他们更方便的设计和生产流行的纽扣,流行的布料,流行的颜色等等。把那些不同的数据面向客户,使客户体验和使用不同的数据,使它们独立出来,这就是数据平台化的思路。数据的平台化就是把那些有共性的数据资源放在在一起,然后把那些面向客户的数据价值独立出来。不再是混在一起,更加的清晰。这就是数据的平台化。数据仓库、数据平台、数据湖其实就是这样一个平台,它通过ETL将采集到的数据,通过E(采集)汇聚在一起,然后通过T(转换)统一做转化,再通过L(上载)统一入库。然后进行分层处理建模,最终实现数据的共享,满足不断丰富、变化的数据分析、挖掘类需求。数据治理是帮助企业更好的建立这样一个数据存储和共享的工具和服务。由此可见,数据仓库等完成的整个数据平台化的过程,就是一个从数据到数据的循环,它的出发点是数据,结束点也是数据。这也是很多企业IT部门要上数据仓库等平台,和要上数据治理等工具和服务的时候,总是强调这是一把手工程。为什么呢?因为它们不是从业务出发的,所以没有业务部门为它们背书。这钱对老板来说就是,其他企业都在建,我们不建设好像也不行。但是,建设了对业务有何帮助呢?这个问题得绕上360圈才能扯上一些关系,而且似乎还挺勉强。数据中台的思路是业务化,他是从业务为出发点的。还是拿服装生产厂为例。例如,服装设计师团队如果也要像ZARA一样每年设计几万套服装,而且还要确保大概率是畅销的产品,它需要怎么做呢?设计师需要采集到更多更为仔细的数据,比如:今天的颜色的客户选择排序;纽扣的大小、数量、排列、颜色、类型;领口的开口形状、大小;有没有蕾丝;袖子的长短,宽松等;后背的开口、大小、形状等;布料的质地,销售的地区、数量等......等等,这些数据可以帮助设计师迅速的获得一个十分接近的当天(或近期)流行的服装的款式,他可以用极少的时间,在这些预测流行的服装上添加、裁剪、附加装饰等为修订的方式推出明天的新一款的服装。这种方式,有点像我们软件行业的小步迭代的逻辑体系。而这种数据的获取并不是原来数据仓库的方式,一般,数据采集在一个企业是由统一的采集运维团队负责的。问题是,这对一般的采集运维团队来说,是非常困难的。而数据的采集和解析方式直接决定了业务的价值,这是业务人员(我们的例子中是设计师)的能力。数据中台的业务化特性,是用业务驱动数据的建设,其实是要求打破层级式的数据管理方式,让业务团队直接端到端的完成从业务到数据采集的全过程,业务团队实际承担着产品研发、模型研发、业务算法、数据解析和采集等多种职能,因为只有他们才能理解清楚如何根据新的业务要求来采集全自己所需的数据,从而让上层应用达到业务的要求。2、服务化是手段,是业务化的前提数据中台的数据的服务化绝不仅仅是单一的API形态。业务分析的灵活性和数据维度的无限性,决定了不可能封装出所有的数据服务API。数据服务化是广义的服务:提供的数据能够被前端业务人员或其他应用系统快速方便的使用或调用、共享。数据服务方式可以归纳为:数据模型、数据服务和数据开发和探索。1)、数据模型是数据服务的基础,包括:基础模型:实现数据的标准化融合模型:实现多源异构数据的整合,包含汇总、关联和解析挖掘模型:具有共性的偏应用的挖掘模型,以便开放给其它人使用2)、数据服务:数据模型按照应用要求进行服务封装,通常说的API就是其中的一种方式。值得注意的是,市面上很多的采集、汇总、报表、BI、ETL等工具真心不是数据中台,不管他们怎么包装和宣传。判定方法很简单,如果它只是提供呆板僵硬的界面,没有API等服务封装,那么,它就是一个应用!大数据不实现数据服务化,那么业务化就是空中楼阁了,大数据也就很难规模化和实现变现了。数据服务化的封装是数据中台的一个难点,源于OLTP的变化有限。3)、数据开发和探索:前端个性化的要求倒逼数据中台必须能提供数据开发和探索的服务,包括:标签库(DMP,用户基于标签的组装,快速形成客户群,一般面向业务人员),数据开发平台(用户基于平台访问到所有的数据,进行可视化开发,一般面向SQL开发人员),应用环境和组件(技术人员自主打造个性化数据产品)。数据中台把能复用的数据模型,变成一个数据的能力平台,保证数据质量和一致性,加速从数据到价值的转换过程。3、开放化是价值体现开放是数据中台价值的体现,开放应遵循以下原则,如图示:

数据中台要发挥出价值,光有业务能力和服务能力还不够,你必须告知别人你有这种能力,让人家知道你有哪些数据,数据怎么访问,有什么价值等等。

数据开放不是简单的数据发布和查询,也不是仅仅处在信息公开的层面,也不是仅限于信息资源的定向再利用......,这些都不是数据开放的本质。

对于数据中台来说,开放化指的是:“把数据作为一种基础设施来建设”,开放化本质上是提供一种公共的产品。

所以数据中台的开放化意味着:“易用”和“迭代”。易用:要从操作体验、存储过程、敏捷挖掘、解释性等等非常的方便使用,要求稳定、可靠、数据一致性好、可视化等等。迭代:首先要求所有数据或产品的都能持续的运营,运营的目的就是了解数据中台提供的数据或产品服务,谁在用,用的如何,产生多少收入......,从而给出提升的方法,如此循环往复,数据中台的价值才会越来越大。其次,迭代意味着数据中台需要结合企业实际进行定制化。据了解,目前数据中台定制化的比例超过7成,这表明:你很难找到其他行业的最佳实践为你所用。

六结束语从业务出发,以服务为手段,以开放为价值体现是数据中台的典型特征。不是任何一个数据平台或组件都可以称之为数据中台的!随着AI技术融合入到数据中台,可以让用户更好的获得智能化服务的能力。(全文终)

本文来源:http://www.fsgl168.com/fanwen/208298/