美文网首页
对数据中台的理解(23.11.13)

对数据中台的理解(23.11.13)

作者: 次第前行 | 来源:发表于2023-11-12 21:43 被阅读0次

    今天把数据中台来龙去脉讲一下。当我们要去了解数据中台的时候,还是要把传统的单体架构,传统的BI系统,传统DMD主数据系统首先了解清楚。这是我们了解数据中台最基本的知识。只有了解了传统的架构,我们才能够更清楚数据中台是怎么样一步一步衍生出来的。

    所以首先我们看看传统单体架构下面,都采用的是烟囱式的建设。我们会去建设CMS合同管理系统,会去建设SCM采购管理系统,会去建设ERP系统。但是当这些系统建设完成后,形成一个个信息孤岛,在这个时候我们的想法是去走企业的BI商业智能,做企业辅助决策,我们回去建设传统BI系统。在建设BI系统的时候,我们自然会想到我们需要把各个业务系统的数据通过类似ETL工具抽取到我们的整个BI系统里面。所以传统的BI系统当ETL作为数据抽取够来以后,在上层就会有一个ODS库。有了ODS库,我们再结合上层数据建模和维度建模,我们会形成数据集市,或者叫DW数据仓库。这个就是传统BI的核心内容。当我们建设完整的ODS库和DW库之后,就很方便去做更上层的就是最终领导看到的各种报表的分析,各种报表的上钻下钻和维度切片,或者是方便领导关注的驾驶决策舱。

    在传统的架构里面,我们发现一个关键问题,类似我们的供应商、物料等基础数据,这些基础数据可能在多个业务系统中都存在。比如说虚拟的物料在合同管理系统里面管理,但涉及实际生产的物料在采购系统里面管理,物料涉及的采购属性在采购系统里面管理,但是涉及到库存和财务记账类数据又再ERP系统里面。这个时候我们会看到,即使对于同样一个物料基础数据,没有形成一个完整统一的实体。而且物料基础数据分散在多个系统里面,很可能多个系统都在同时对这个系统维护,导致数据不一致。基于这个原因,我们在传统单体架构下面,一般会去建立MDM的主数据管理系统,把原来在各个业务系统管理的基础数据统一集中到主数据系统里面进行管理。在主数据统一管理基础数据后,如果其他业务需要这些数据,我们再通过分发的接口分发给各个业务系统使用。

    当增加了MDM主数据管理系统后,传统BI系统也会出现大的变化。BI系统在各个业务系统抽取数据的时候,原来本身就包含了既要抽取类似供应商、物料这类基础数据,又要抽取订单、合同这类动态数据。在建设完成主数据系统后,我们可以发现BI系统数据抽取分为两个部分。如果仅仅是基础数据抽取,就不再从业务系统抽取,而是直接从MDM系统抽取数据进行使用。对于动态数据,再从业务系统抽取进入ODS库。这就是传统单体架构,传统BI系统为什么会形成主数据管理系统,所以我们还是传统的架构。

    一个数据中台厂商说要把你基础数据进行管理,建立一个类似基础数据管理系统。那这个事情实际上跟数据中台没有任何关系。如果是一个传统单体架构,一个数据中台厂商说要把数据全部抽取出来进行集中整合,然后做一些统计报表,这些工作也跟数据中台没有关系,这顶多是BI系统。

    那么数据中台的变化究竟是在哪些点,为什么会形成从传统BI朝传统数据中台的演变,我们一定要明白这个道理。这个演变不是说自己在演变,其中核心的重点在于我们原来单体架构本身在朝着微服务架构转变。也就是说整个传统单体架构变成了微服务架构,同时企业构建了企业业务中台,同时也做了平台+应用的新的架构模式。在这个时候我们可以看到,原来的就没有传统合同系统,采购系统。更多我叫订单中心、用户中心、物料中心、供应商中心,变成一个个细粒度微服务。在变成微服务中心以后,原来构建MDM系统进行物料、供应商管理就没有任何必要了。因为拆分成业务中台一个个服务中心本身就是一个个独立的微服务中心,没必要把这些数据集中到类似一个主数据系统中去管理。这些中心本身就可以朝上开放业务和数据服务能力。

    第二点当拆成微服务以后我们注意到一个很关键的东西。比如原来上层应用需要一个关键的能力,希望看到整个采购执行情况,就必须访问供应商数据、物料数据、订单数据、采购执行数据,这些数据原来都是在采购系统一个大数据库中。所以,往往采用一个大的关联SQL就获取了想要的数据。但是在进行单体朝微服务的拆解后,我们会发现即使要提供一个采购执行数据服务能力,往往涉及到多个微服务提供出来的数据服务能力的整合才能最终完成这件事情。所以做这件事情反而单体拆解后不方便了。那么不方便后,我们该如何来做这件事情呢?

    我们要去构建一个数据中台来做,在底层我们仍然涉及到ETL或者Hadoop这些大数据技术平台。我们需要去把各个微服数据通过ETL或者通过数据采集的方式先同步到整个数据中台中去。在数据中台我们不用特别强调是ODS库还是DW库,在数据中台中,我们可以命名为数据资产库。在数据资产库里面下方,仍然是数据贴源层,在数据贴源层上方我们进行数据建模。包括数据宽表,包括数据仓库维度模型,这些我们可以认为是在构建我们的数据资产库。当听到这个地方的时候,我们会发现这个数据中台跟传统的BI系统不仍然是一回事吗?

    实际关键的一个差异在哪里呢?我们讲任何中台,不管业务中台还是数据中台,一定是讲的可共享的业务能力、数据能力的下沉。把这个能力下沉后,我不能够是在自己的封闭体系里面。传统BI我们发现数据抽取到ODS仓库后,仅仅能提供个上层数据报表分析使用。但是到了数据中台以后,通过数据资产库形成数据资产以后,就会有一个很重要的层叫数据服务层。我们所形成的数据资产能力,不仅仅是提供给前端BI报表使用,这种仍然是我们常说的OLAP应用。我们更多是希望将数据资产通过数据服务层对外进行能力开放,把开放的能力给到前端应用。这个时候我们会发现当传统BI衍生到数据中台以后,带来的最大的变化是数据中台不在是一个孤立封闭的体系。数据中台在构建数据资产这些核心要素以后,必须通过数据服务层把这个能力进一步通过API接口方式开放给业务应用使用。这个也是经常在讲业务中台、数据中台的时候,讲到数据实时反哺业务。数据不仅仅是用户决策分析,同时要支撑业务的运作。这个数据实时性价值进一步展示出来了。这才是构建数据中台最大的价值。同时我们也可以看到在传统单体架构、BI系统朝数据中台变化的时候,MDM主数据系统已经没有存在的价值。如果传统架构做了微服务架构的改造,更不需要构建主数据平台。主数据平台已经变成业务中台各个微服务中心的能力。

    经过传统单体到微服务结构,从传统单体到业务中台、数据中台演变过程,我们可以更加清楚理解数据中台究竟是如何一步步产生的。最后再总结一下核心数据中台我们可以看到。它往往一般会涉及底层大数据技术平台,比如通过主流hadoop技术构建,当如如果企业全部是结构化数据,也可采用clisk house的MPP数据来完成底层数据技术平台的搭建。有了技术平台以后,上面是核心数据资产层,在数据资产层可以看到相应贴源数据,通过维度加工,加工以后数据,我们实际数据分析模型,维度模型很可能都是体现在我们的数据资产里面。在数据资产上层一个关键内容是去构建数据服务和数据能力开放层。再到上面就会有两个出口,一个出口仍然满足上层BI报表分析应用,另外一个出口是快速反哺业务应用,支撑业务应用。这才是数据中台的本质的内容。

    相关文章

      网友评论

          本文标题:对数据中台的理解(23.11.13)

          本文链接:https://www.haomeiwen.com/subject/ywyrwdtx.html