精华内容
下载资源
问答
  • 数据中台与数据平台关系

    千次阅读 2020-03-30 10:41:53
    想要理解数据台和数据平台的区别,首先应该了解台和平台的区别。我理解的平台是企业或者研发团队为了满足用户需求而建设的基于... 数据中台就是对数据能力的一个建设集合,数据平台可以通过组合数据中台的能力...
       想要理解数据中台和数据平台的区别,首先应该了解中台和平台的区别。我理解的平台是企业或者研发团队为了满足用户需求而建设的基于业务的平台(也就是各种不同类型的能力组合后的产物)。而中台,一般是组合前的能力集合,处于同一中台的能力一般都是相似能力的,前台调用者只需要对中台的各种能力进行组合就可以来满足用户的需求。
    
         数据中台就是对数据能力的一个建设集合,数据平台可以通过组合数据中台的能力来满足用户的需求,数据平台是直接面向客户的能力组合过后的商业产品,而数据中台是企业自身的能力集合。产品层从用户获取需求之后,制定出需要构建的数据能力平台,该能力平台就可以从企业已有的数据中台中获取不同的数据能力,通过能力的组合的方法,将中台中的小能力通过组合,拆分聚合构建起数据平台。如果数据能力中台中不包含某项能力,那么中台的建设者就应该积极去拓展这样的能力。
    
        中台建设的过程中,中台抽象自平台。在平台的搭建过程中,平台来源于对中台能力的组合和聚合。单从用处来讲,中台的出现是为了减少重复劳动,基于用户需求的各种平台可以构建在企业能力中台之上,平台由各种中台能力类似于像搭积木一样构建起来。通过对不同能力的组合,聚合,构建起满足一定用户需求的大功能。中台的建设也需要从平台中借鉴经验,比如,用户需要什么样的功能,如果目前中台对这样的功能无法支持,那么我们就需要对中台能力进行扩充。数据中台就是为了避免重复创造数据能力相关的轮子而出现的数据能力集合。虽然数据平台也是能力集合,单从组成来讲,平台的能力比较基于某种功能,而中台能力集合中的某一个能力往往只基于某一个点。可以简单想象成企业内部的能力库。中台的出现就是为了减少重复轮子的构建工作。
    
    展开全文
  • 文章一经发布后收到了很多网友的私信留言,针对基于数据湖的应用场景应用前景进行讨论,并有网友提出希望聊一聊数据湖与当下热度非常高的数据中台之间的关系。这是一个很好的话题,很早就想针对这个话题写一篇...

    该篇文章首发平台是微信公众号:谈数据。关注微信公众号请在微信上搜索“谈数据”,或直接微信扫描文末二维码进行关注。

    前言:这是一篇拖欠了4个多月的债!今年4月初写了一篇关于数据湖的文章——《探秘亚马逊AWS数据湖》,文章一经发布后收到了很多网友的私信和留言,针对基于数据湖的应用场景和应用前景进行讨论,并有网友提出希望聊一聊数据湖与当下热度非常高的数据中台之间的关系。这是一个很好的话题,很早就想针对这个话题写一篇文章,只是由于工作较忙(借口),加上懒病又犯了(正解),所以一拖再拖,直到今天才写完发出来,请大家见谅!

     

     1 那些让人眼花缭乱的概念

    不知道大家有没有发现,这几年的数据领域有好多的概念,例如:大数据、人工智能、物联网、边缘计算、数据治理、数据湖、数据中台、数据可视化……。这说明数据这个领域真的很“火”,可谓是“百花齐放”!

    新技术、新概念的出现,为企业业务和管理的创新,社会经济的发展,注入新活力,激发新动能。很多企业都认识到了数据的重要性,数据是企业的重要资产,成为了企业的普遍共识。这激活了企业创新和改革的动力,加速了企业向互联网化、数字化方向的转型,提高了企业跨行业、跨领域的学习能力,推动了整个社会的数字化发展。

    纷至沓来的新概念在推动社会的数字化发展的同时,给相关领域的从业人员带来了一定的困惑。一个新概念还未来及吸收和消化,新新的概念又来了。再加上,一些“别有用心”的厂商不遗余力的“忽悠”和“炒作”,导致了很多人的迷茫困惑、心浮气躁!有的人一味追求新概念、新技术而脱离了业务、脱离了实际,认为新概念(例如:数据中台)能够“包治百病”,一些企业花费很大的成本买来数据中台之后才发现:在人家那儿是治病的良药,而到了你这里却成了“埋人的深坑”。所以有人叫苦道:“中台搞了2年,项目叫停,CIO被裁!本以为是个送分题,没想到是个送命题!”

    面对着纷繁芜杂的新概念,面对着浩瀚的数字化海洋,面对着“厂商们”的炒作,不论是企业,还是我们这些IT从业人员,都需要保持好初心,坚守初衷。不要看:“人家都【数据中台】了,你还在做数据报表,人家都【数据湖】了,你还在搞数据仓库,人家都【人工智能】了,你还在抽数、取数”!

    这里说明下,我并不是一个顽固的守旧派,也不是排斥新概念、新技术。反而,我也非常喜欢研究一些新概念,也非常支持大家对新的概念、技术进行探索和实践。但要强调的是,企业也好,个人也好,在使用引进或使用一个新概念和新技术的同时,不要忘记问自己:我们使用它们的初衷是什么?我们的本质需求是什么?要用这些新的概念和技术来帮我们解决什么问题?……

    坚守初心,不被繁杂的概念所迷惑,才能找到适合企业或个人的数字化转型之路!

     

     2 数据湖和数据中台的概念

     

    我们先说说数据湖

    数据湖(Data Lake)概念最早是2011年由CITO Research网站的CTO和作家Dan Woods所提出,其比喻是:如果我们把数据比作大自然的水,那么各个江川河流的水未经加工,源源不断地汇聚到数据湖中。

    数据湖的权威定义(来自维基百科):数据湖(Data Lake)是一个以原始格式存储数据的存储库或系统,它按原样存储数据,而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据(如关系型数据库中的表),半结构化数据(如CSV、日志、XML、JSON),非结构化数据(如电子邮件、文档、PDF)和二进制数据(如图形、音频、视频)。

    数据湖概念的提出时间是仅次于大数据,可以说是一个很老的概念了。笔者认为数据湖本质上就是一个大数据平台,它随着大数据的技术不断完善,目前成熟的数据湖体系已具备了大数据存储、大数据处理、机器学习、大数据分析等等能力。国外公司好像对数据湖情有独钟,像亚马逊的AWS、Informatica、IBM、微软等公司都有数据湖的相关产品和解决方案。而在国内,数据湖到底是个啥?他有啥用?时至今日依然存在着不少的争议。

    正如来自网友 @流风(网名)的疑问:绝大部分企业的需求数据仓库基本都能满足了,只有少部分企业才能用到数据湖或大数据平台,好多企业都被忽悠上了大数据平台,光有个架子,却不知道能用来干嘛。对非结构化数据的处理,大多数企业本身除了数据存储之外,几乎不知道该怎么用。甚至大多数据企业连结构化数据都还处理不好,数据意识还停留在起步阶段。

    @流风(网名)所说的是事实,也是目前的普遍现象。但在笔者看来:一项新技术,一个新事物从诞生到发展到普及,是需要一个由“基础认知---知识学习---能力建设---探索应用---成熟应用”的过程。在这个过程中,各企业的发展水平一定是参差不齐的,没有那两家企业的现状、需求、目标、数据是完全相同的,所以不同企业对数据的意识程度不相同、技术能力不一样、应用水平差异大也是正常的。

    我们再说数据中台

    对于数据中台,笔者阅读了很多大咖的文章,查阅了很多资料,也没有找到关于数据中台的标准定义。事实上也确实如此,数据中台是具有“中国特色”的一个概念,在国外并没有太多的人谈数据中台。而我们中国人创造的数据中台概念,目前还未形成一个统一的认知和基于共识的标准定义。

    中台概念的鼻祖——阿里巴巴的数据产品部总经理朋新宇表示:“数据中台是数据+技术+产品+组织的组合,是企业开展新型运营的一个中枢系统。具象的说,它是一套解决方案,抽象的理解,它是一种新的公司运营理念”。

    数澜科技CDO付登坡表示:“数据中台是让数据用起来持续的一套机制,经过业务数据化、数据资产化、资产服务化,并在有权限管理的情况下以 API 的方式开放出去 ”。

    袋鼠云CEO 拖雷认为:“数据中台可以理解为企业的最核心的数据大脑……是一种理念,一种思维,是一种面向未来的架构”。袋鼠云将其总结为“5+1”模式,5是建设数据中台的五步法,即:咨询、规划、建设、应用、运营,1是是指一个大数据平台,提供大数据的处理、计算、分析、应用。

    云徙首席架构师陈新宇表示:“数据中台与业务中台的一体化,其核心作用便是业务中台天然打通、统一了各个渠道的数据,所有数据都是高质量的,而这些数据通过分析能够反哺到业务本身,业务本身又将数据留给数据平台,从而形成良好的正向反馈”。

    网易严选的魏文庆给出了网易严选对数据中台的定义:“数据中台是高质量、高效赋能数据前台的一系列数据系统和数据服务的组合”,无论是数据中台、业务总台、技术中台,核心都是“标准化”,实现流程都是先“规范化”,然后把规范“产品化工具化”。

    百分点程佳表示:“数据中台是一个集数据采集、融合、治理、组织管理、智能分析为一体,持续促进业务创新为目标的整体平台”。

    我们看到这么多企业都试图给数据中台下一个标准的定义,尽管各家的说法都略有差异,并不相同,但却也有异曲同工之妙!那么,数据湖与数据中台到底有什么关系?我们不妨先看一看业界典型的数据湖和数据中台架构。

     

     3 典型的数据湖和数据中台架构

     

    1、亚马逊AWS数据湖

    亚马逊AWS的张侠看来:“数据湖是一个中心数据存储的容器,这个容器可以存储格式化、非格式化的各种各样的数据;这些数据非常容易被快速缩放、有各种方法和工具对这些数据进行查询、可以做各种各样的分析”。如下图所示,AWS数据湖提供了大量的数据处理组件,支持把数据按需要移动、加载到不同地方;然后把数据清理好,建成数据目录。这些数据要安全的、合规的存好、管好,需要的时候使用工具把这些数据拿出来做各种分析。

    AWS数据湖架构

    2、微软Azure数据湖

    Azure数据湖是在微软内部的大数据平台Cosmos的技术和经验教训基础上构建的。Cosmos用来处理应用程序比如Azure, AdCenter, Bing,MSN, Skype和Windows Live的数据。Cosmos有一个像SQL一样的查询引擎叫做SCOPE,U-SQL是在其上构建的。Azure数据湖包括Azure Datalake Store和Azure Datalake Analytics。前者是存储,有API提供。后者是分析平台。它的分析平台支持Hadoop的那一套,也支持一个全新的U-SQL。如果你想要同时读取在Datalake里面的数据和Datalake外面的数据做分析的话,那就只有U-SQL可以选了。由于U-SQL和Hadoop生态圈不兼容,而且是基于没有多少人愿意学习的C#语言的,这导致了Azure数据湖卖的并不好。也有内部人传由于各种原因,Azure数据湖几乎要凉凉了。

    微软Azure数据湖

    3、阿里系数据中台

    作为“中台”的开山鼻祖——阿里巴巴的数据中台全景图如下图所示:阿里巴巴数据中台核心内核是OneData体系,即数据中台构建的方法论体系总称,包括数据构建管理的OneModel,实现数据融通连接的OneID,再到提供统一数据服务的One Service,贯穿于整个数据研发流程中并且通过工具实施落地,帮助企业高效建设及管理数据。有兴趣可以参考笔者之前写的一篇:《什么是One Data体系?阿里数据中台解读》

    阿里巴巴数据中台

    实际上阿里的数据中台并不是一套产品,而是阿里的数据中台方法论体系+生态产品。这里所谓的数据中台生态产品,就是带着明显的阿里基因的数据中台产品或解决方案,例如:数澜科技、袋鼠云、奇点云、云徙等创业公司都属于阿里生态,他们很多公司的核心成员甚至创始人都是从阿里巴巴出来的,所以带着阿里基因也很正常。阿里基因是什么?笔者认为的阿里基因即做电商或者说2C业务的商业化思维。由于这篇文章重点在写数据湖与数据中台的关系,就不对阿里基因和阿里系数据中台做过多介绍了。其实,通过以下各公司的数据中台架构,您就可以窥探一二了。

    (图片来自数澜科技)

    (图片来自袋鼠云)

    (图片来自奇点云)

    (图片来自云徙)

     

     4 数据湖与数据中台的关系

     

    看过了各大厂的数据湖和数据中台的介,我们回过头来再来看数据湖与数据中台的关系。

    大数据时代,数据量越来越多,数据形式日益复杂,而以数据仓库为代表的、现有的数据存储和处理技术无法满足海量、多样的数据处理需求的背景下产生的。“数据湖”是将复杂的事物具象化,偏技术一些,以一个形象的名字,反应了它在大数据存储和大数据处理方面的优势和能力。

    数据湖作为一个集中的存储库,可以在其中存储任何形式(结构化和非结构化)、任意规模的数据。在数据湖中,可以不对存储的数据进行结构化,只有在使用数据的时候,再利用数据湖强大的大数据查询、处理、分析等组件对数据进行处理和应用。因此,数据湖具备运行不同类型数据分析的能力。

    数据中台从技术的层面承接了数据湖的技术,通过数据技术,对海量、多源、多样的数据进行采集、处理、存储、计算,同时统一标准和口径,把数据统一之后,以标准形式存储,形成大数据资产层,以满足前台数据分析和应用的需求。数据中台更强调应用,离业务更近,强调服务于前台的能力,实现逻辑、算法、标签、模型、数据资产的沉淀和复用,能更快速的相应业务和应用开发的需求,可追溯,更精准。

     

     5 数据湖和数据中台那家强?

     

    我们都数据中台了,为什么老外还在数据湖?

    在近代史上,由于欧美国家的工业起步早,所以在科技领域我们的创新能力(从0到1的能力)一直不如一些欧美国家,但是中国人的应用能力非常强,更注重商业和管理的创新(商业模式的各种玩法和创新),中国人始终要比老外玩的溜,也就是说我们从1到100的能力是极强的。因此,更强调业务和应用的“数据中台”在国内以迅雷不及掩耳之势,迅速成为了国内IT界的“头牌网红”。

    随着以大数据、云计算、人工智能等新技术为主要特征的第四次工业革命的到来,中国大数据战略的布局和“新基建”的发展,我相信,在这场数字化的变革中,我们的技术创新能力也一定会追上甚至超越欧美的!

    最后,再回答网友的一个问题:数据湖与数据中台哪家强?

    在笔者来看,不论是数据湖还是数据中台,都是“千人千面”的,不同的人理解不同,数据湖和数据中台也没有孰弱孰强之说。对企业而言,不为眼花缭乱的“概念”所迷惑,一切要从实际需求出发,不能人云亦云,盲目跟风,也不能墨守成规、固步自封。企业数据项目的建设还是应当从企业的业务需求出发构建与企业相匹配的一套数据管理和使用流程,以及与之需求相匹配的数据平台和工具。

     

     

    展开全文
  • 中台概念着实火了一把,继去年购买了“数据中台”的百度搜索指数后,昨天我又购买了“业务中台”的百度指数,可能是由于刚刚购买,全量数据还没有统计汇总出来,所以当我们在百度指数,搜索业务中台的时候,目前...

    中台概念着实火了一把,继去年购买了“数据中台”的百度搜索指数后,昨天我又购买了“业务中台”的百度指数,可能是由于刚刚购买,全量数据还没有统计汇总出来,所以当我们在百度指数中,搜索业务中台的时候,目前只有 4 月 6 日的数据。

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    即便如此,我们依旧能从这张图能清晰地看出,中台、数据中台的热度在 2019 年 5 月份开始崛起,在年底达到顶峰,已经持续超越了数字化转型的关注度。

    在本篇文章,我不去重复中台的各种概念和定义:中台是企业级能力复用平台。

    从另外一个角度,历经了企业 BPR,ERP 实施等传统项目,再到现在的云计算、大数据、等数字化项目,在一个从业二十年的 IT 老兵的眼中,中台的崛起可能不仅是“能力复用”,它所代表的意义是更丰富和巨大的。

    在我的认知中,“中台”这个概念的火爆不是昙花一现,更不是机缘巧合,它是中国企业信息化发展的必由之路,是本土企业信息化历史上的一个里程碑,它有以下两个代表性:

    1、“中台”是国人自主提出并孵化成一个市场的原创概念

    从 1999 年靠写程序挣了人生第一笔工资开始,我所接触到的所有的 IT 领域的概念,基本上全都是“舶来品”,中国的企业信息化市场的关键概念,包括大数据、云计算、移动互联网、Web、J2EE、EAI、SOA、ESB、ERP、商务智能、数据仓库等无一例外,都是从海外由咨询公司或者大型厂商引入的,而中国的企业信息化历程就是由这一个个关键概念牵引着前进的。

    理论指导实践,好的理论能够统一愿景,领导行业的方向。好的概念能够让行业统一认知,形成共识,从而更快的规模化发展,比如云计算、大数据、ERP 这些概念,教育了众多企业的高管,构建起了中国数字化的基石。

    在我的记忆里,中台是第一个由国人自己提出,持续被关注,不断走高成为现象级企业信息化领域的概念。

    同时,通过行业的不断讨论和迭代,“中台”这个概念,已经像云计算、大数据一样,逐渐成为了一个独特的市场领域,众多的中台创业公司不断涌现,国内企业都在思考并且实践如何建设中台,巨大的市场需求正在形成。

    虽然到目前为止,中台的概念在中国以外的市场落地的案例还不多,但是作为国人自主提出,并且已经孵化成一个市场的原创概念,中台这两个字,已经创建了太多的第一,这两个字足以在中国的信息化历史上画上闪亮的一笔。

    2、“中台”代表着本土企业数字化转型理论的一个丰碑

    在中台以前,中国的企业信息化领域出的书大部分都是偏实操和工具类的书籍,而介绍企业级架构、方法论的原创书籍不多。

    对比美国的IT界,很多软件大拿非常擅长总结抽象理论体系,比如敏捷、演进式架构、微服务这些体系就是 Martin Fowler 和 Neal Ford 这样的软件巨匠提出并升华到企业架构级别的。

    所以,中台概念的崛起,绝对是中国企业信息化领域的一个里程碑式的事件,它对于企业信息化已经带来并且还在持续带来巨大的推动作用。

    当我回顾这个里程碑事件的时候,我隐约感觉到了一个模糊的关联,这些关联随着思考不断的深入,随着与同行们不断的碰撞越来越清晰,中台的本质是什么,它的发展将何去何从?

    中台的崛起是从“服务化”到“去 ERP 化”

    10 年前,阿里掀起了一场声势浩大的“去 IOE”活动,其本意是,在阿里巴巴的 IT 架构中,去掉 IBM 的小型机、Oracle 数据库、EMC 存储设备,代之以自研或在开源软件基础上开发的系统。

    站在技术的视角看“去 IOE 化”的过程,就是将原来的中心化的、封闭的 Oracle 商业数据库软件替换为去中心化的、开放的开源数据库软件,将原来封闭的 IBM 的主机、EMC 的高端存储设备替换为以 X86 为代表的云化硬件设备。

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    对应到典型 IT 架构的层次,去 IOE 化都是在企业的基础架构层面,包括应用基础架构的工作,也就是从 IaaS 到 PaaS,而应用层并没有太大变化。

    但是,当我们看中台的概念的时候,我们发现,中台要解决是两个方面的问题:业务中台和数据中台。业务中台通过抽象,封装可复用的逻辑,提升企业的响应力,而数据中台通过打通企业的数据,构建自学习服务的数据能力,让企业更智慧,一个是应用层, 一个是数据层,也就对应到 Application 和 Data。

    行业里普遍比较认同中台的构建就是业务数据化,数据业务化,也就是围绕微服务架构的过程。

    但是如果我们把业务中台和数据中台与过去二十年的信息化历程关联到一起,我们会发现中台的建设可以分为两个阶段,第一个阶段是“服务化”,第二个阶段是“去 ERP 化”,而最终对于企业来讲追求的是用新的数字化技术去替换遗留的 ERP 系统的过程。

    企业中台实施第一个阶段:服务化

    目前很多企业所实施的中台,主要的工作是将遗留的后台系统,比如 ERP/MES/CRM 的公共部分进行拆解复用,形成类似于交易中心、用户中心,订单中心这样的微服务集合供前台调用,从而保证逻辑的一致性同时更快的响应前台的变化。

    这个阶段,中台以“通用能力服务化”为核心。如下图所示,左边是业务中台,业务中台将后台的通用业务能力,比如用户接口、订单接口、支付接口等统一抽象成微服务提供给多个业务前台使用,从而保证前台业务数据化的过程的标准化、统一化,提升了业务数据化的一致性和准确性,同时也加快了前台的响应速度。

    右边是数据中台,数据中台从后台获取全域数据,并且通过结合人工智能的算法技术挖掘产生业务洞察,并提供唯一的数据查询和统计服务给到业务前台和业务中台,从而驱动业务朝智能化转型,优化现有业务同时转型和创新业务。

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    整个这个过程,都是业务响应需求的发展,进行微服务改造的过程。下面我们以一个最典型的订单服务为例来仔细剖析这个过程,从而阐述业务中台和数据中台的关系以及他们的业务价值。

    下图是一个典型的电商订单服务的流程,用户在某电商自营 APP 下一个产品订单,这个应用负责把订单数据保存到数据库里。

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    随着这个企业的发展,该电商企业拓展了多个渠道,构建了其他的 APP,提供给用户使用。

    于是,用户下订单就有了两个方法,分别在不同的应用里,比如自营 APP 和微信小程序,这样最典型的两个渠道。而真实的情况可能是一个电商企业会有非常多的渠道,有自营的,还有代运营的,还有线下的 POS 系统,还有合作伙伴通过 API 接入的,多个应用会同时创建订单。

    这样的情况下就会出现多个应用都会创建订单。

     

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    这样带来的问题很明显:

    1. 用户体验不佳,一个用户不能看到在不同渠道的订单。
    2. 数据一致性差,订单数据分散在不同的应用系统中,数据不一致,同步复杂。
    3. 维护困难,当一个订单逻辑发生了变化,所有的应用逻辑都要重写,带来的很大的维护工作量,响应慢。

    在这种情况下,如何解决这些问题呢?

    为了解决订单数据一致性的问题,一般会在 OrderDB_1 和 OrderDB_2 之间做同步更新,从而保证用户能看到自己的全部订单。

    为了能够掌握全局的销量情况,企业会构建数据仓库系统,将不同系统的数据都通过 ETL 的方式抽取到数据仓库中进行分析,这就是 OLAP 的过程。但是由于数据量比较大,处理过程复杂,往往 OLAP 都是 T+1 以上的响应速度,也就意味着,比如企业要想看所有渠道的销量分析报表,只能看到一天以前的,而不能看实时的数据,如下图所示。

     

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    上图的橘黄色箭头表示在线交易处理流程,是生成数据的过程,而绿色箭头表示在线分析处理流程,是抽取处理分析的过程。

    这是典型的数据仓库和商业智能的场景,而这样的数据利用的问题也是很明显的:

    1. 数据分析不实时,不能够实时出报表。
    2. 数据仓库往往都是单体架构,受限于数据的处理计算能力,扩展能力不强,往往只能分析一个阶段的数据。
    3. 响应慢,ETL 的过程依赖于预设的分析主题设计,当要分析的数据结构发生变化时需要重新设计抽取逻辑,导致响应慢。

    以上是现在很多企业现存的典型的应用和数据利用场景,在这个基础之上,业务部门提出了更高的需求,比如如何能够实现精准营销,如何能够实现动态的价格?

    这就是数据中台和双中台的典型用例和业务价值所在,下面我们用三个典型场景用例来阐述中台服务化的价值。

    下图是典型的数据中台的业务场景:精准营销。

    利用分布式的数据架构替换传统的数据仓库,将 ETL 的过程更换成 ELT 的过程,结合批流一体的架构,保证数据的全面覆盖,源数据抽取,实时数据和历史数据并存。

    在这个基础上,数据中台借助机器学习等算法能力,构建精准营销模型,能够供前台业务应用直接调用,而不需要做成报表以可视化的形式提供给业务人员,业务人员根据自己的经验在去做手工的用户运营。当用户在访问商品清单的时候,根据用户画像、产品销量等全域数据,实时生成最新的产品推荐,通过数据中台的 API 推荐给用户。

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    这是一个典型的数据智能化的过程,通过数据中台整合了企业相关应用系统的全域数据,通过分布式存储和计算能力,结合人工智能技术和算法,为业务系统提供直接可调用的实时数据和智能服务。

    业务中台的典型场景用例:订单生成

    实现智能化,是所有的企业希望达到的目标,但是智能化对于数据的质量要求很高,而多个分别创建订单服务,导致的问题很明显,而且随着前台应用系统的不断增多,业务数据化的过程越来越复杂,导致数据与真实的业务出现了很多的不一致和偏差。

    同时,随着业务变化的速度越来越快,同时维护多个订单服务的工作量很大,响应速度越来越慢,这就要求对于所有的订单服务进行抽象、复用和包装,这就是业务中台出现的原因。

    如下图是最简单的业务中台的服务,也就是订单中心的服务,所有的前台应用当需要创建订单的时候,统一调用业务中台的订单服务,由这个服务统一生成产品订单,从而保证了订单逻辑的一致性和维护的高响应性。

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    双中台的典型场景用例:动态价格

    数据中台不仅为前台应用直接提供调用服务,并且也能够为业务中台提供数据和智能的服务。

    下图是典型的双中台协作的场景用例:动态价格。

     

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    这个场景在很多需要实时计算动态价格的业务中存在,比如机票预订和滴滴打车的下单服务中,每一个订单的价格都是实时根据当前的数据计算生成的。

    如上图所示,业务中台统一为不同的应用提供订单生成服务,而在生成订单的过程中,需要根据不同用户的情况,动态计算一个价格。这种情况下,业务中台就需要调用数据中台中的动态价格计算模型。

    这个模型从分布式数据网格(Data Mesh)中获取产品、用户等历史数据,同时获取实时的订单数据,最终计算出最优的价格,返回给业务中台的订单服务。

    而这个动态价格的智能服务可以同时被业务中台和其他业务前台所调用,所以,数据中台是同时为业务中台和业务前台提供数据和智能服务的。

    部分企业目前所实施的中台,都是和以上三个业务用例类似的场景,就是将一些共有业务流程做服务化改造,从而变成可以被前台快速调用的业务服务,提升业务的响应力,让业务更智慧。

    当我们看双中台服务化的过程时,不可避免地要面对很多已经有了后台系统,特别是已经有了套装 ERP 软件的情况。这个时候,我们要解决的就不仅仅是服务化几个核心能力的问题,而是以 ERP 为代表的遗留企业架构和以中台为代表的新兴企业架构的博弈问题了,这时候,中台的实施就进入了第二个阶段。

    企业中台实施的第二个阶段:“去 ERP 化”

    十几年前,我作为早期做 BPR(业务流程再造)和 ERP(企业资源管理系统)的顾问,经历了原来以进销存为核心、系统分散数据不拉通的蛮荒阶段。那时候的企业对于 ERP 的追捧,就和现在追捧中台一样。

    当时要解决的问题是将企业的流程梳理清晰,做到资源的集约化管理,从本质上讲也是解决流程复用、业务能力化的问题,只不过那时的技术实践方法是套装软件,通过 Oracle EBS 或者 SAP ECC 这样的商业闭源软件,开箱配置后使用,用国外成熟标准化的流程来驱动企业的业务。

    曾几何时,ERP 是企业现代化管理制度的代表,上了 ERP 表示企业流程优化、资源集约化的成功,但是经过了十几年的发展,原来的 ERP 系统已经不足以满足当今企业的诉求,主要原因如下:

    套装 ERP 软件的弊端

    • 商业软件,响应慢大部分的 ERP 系统是商业软件,是按照 License 来授权的,企业只有使用权,这就导致当企业的业务发生变化的时候,需要找到原厂进行重新配置或者新开发,响应比较慢。
    • 封闭架构,不开放套装 ERP 软件是封闭架构,技术不开放,导致企业无法对它进行大的功能上的扩展,只能像打补丁一样,构建一些外挂,而且效果往往都很不好。
    • 单体架构,弹性不够过去的套装 ERP 软件一般都是巨型单体架构,天生的弹性不够,不能够满足持续增长的性能需求。
    • 昂贵的升级和维护成本套装 ERP 软件的升级和维护成本一般来说都很贵,导致有的的企业抱怨,不上 ERP 会死,但是上了 ERP,费用太高,负担很重。

    过去,企业使用套装 ERP 的核心原因是需要复制和遵循 ERP 软件里内置的那些业务流程,在某种角度上讲,过去 ERP 系统的实施其实是“买流程送软件”

    但是,中国的企业已经建立了适应中国市场特色的组织结构和业务流程体系,而且互联网的快速普及,导致原来静态,标准化的业务流程已经不足以支撑企业的快速响应。

    这种情况下,一些领先的企业对于 ERP 这样的核心业务系统的价值诉求从原来的固化流程到了快速响应前台市场变化的新阶段。

    而与此同时,ERP 这样的以流程为核心的组织形式也转向平台化的组织形式,而这也是中台的核心理念。

    企业组织结构从流程式协作走向平台式协作

    ERP 的实施过程中,会制定很多的流程、岗位、职责,从而让多个部门能够在统一的流程下有机的协作起来,我把这种组织形式叫流程式协作,如下图所示:

     

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    这样的好处是,在预设好的业务流程、分工职责下,不同的部门做各自的事情。比如研发部门就关注产品的先进性,采购部门就关注采购的低成本,生产部门就关注产品的高质量,我们默认为只要各个部门按照制定的流程和 KPI 协作,就可以实现企业的业务战略。

    但是,我们会发现,这个图是从企业内部视角来看的,并不是从客户价值视角来看的,天然把企业分成了外部和内部。

    而随着互联网的出现,外部竞争格局越来越复杂,企业需要围绕客户价值来组织经营,一些领先的企业倡导,所有组织单元和业务部门都要产生客户价值。

    但是 ERP 时代的流程式协作就在客户价值之间构建了一堵无法逾越的墙,因为研发部门只关注技术的先进性,不关注客户是否买单,而采购部门只关注低成本,不关注技术的先进性。每一个流程节点和业务部门重点关注的是给自己设定的 KPI,而不是客户价值,导致局部利益大于全局利益。

    如何打破这堵墙?

    这不是一个简单的事情,从原有的遗留系统,特别是 ERP 这样的套装软件中区解耦业务流程,做服务化改造本身是一个很复杂的工作,并且在改造的过程中,牵一发而动全身,很多企业会发现,最终的结果就是会将原来的单体 ERP 系统拆解成为分布式的,去中心化的 ERP 微服务集合,我称这个阶段为“去 ERP 化”阶段。

    中台建设对于一些已经有 ERP 系统的企业来说,就是“去 ERP 化”,将中心化的单体 ERP 系统拆解成分布式、微服务架构的开放平台,而不仅仅是“能力复用平台”。

    在这样的业务开放平台的基础上,能够打破企业内外部的边界,让所有的业务部门从后端走向前端,通过中台支撑敏捷前台,创造客户价值,我们把这样的协作形式称为“中台时代的平台式协作”。

     

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    ERP 系统的典型场景是流程的复用,定义业务流程模板,然后把一套业务流程尽可能的复制到不同的业务领域和客户需求上,从而实现资源调度的集约化,是典型的计划型经济的思路,强调标准化和资源的复用节约。

    而在 VUCA 的市场环境下,企业面临的是客户越来越多样化,个性化的需求,越来越强调以客户为中心去动态的组织资源为客户提供服务。

    这就要求后台业务系统能够更加灵活的支撑前台不断变化,个性化的客户需求,这和 ERP 系统的核心理念及本质是相违背的。

    这种情况下,原来的 ERP 系统必须要将以流程为独立单元的模块拆解为以客户价值为独立单元的模块。

    同时,这样的转变也带来一个巨大的挑战,就是如何给员工打绩效。

    原来 ERP 时代的员工绩效比较直接清晰,就是将业务流程绩效分解到每一个岗位,比如完成率、审批率等。

    但是,当转变成以客户为核心的时候,如何度量绩效呢?

    企业希望每一个业务节点,所有的参与方都可以对齐到客户价值,用产生的客户价值来度量贡献,这样能够更直接的激励员工。

    这是一个很好的愿景,但是实现起来是困难的,那就是对于一些后端赋能型的业务单元,如何将它们关联到直接的客户价值上,这里就需要利用全域的数据分析、建模,通过敏感性分析等算法技术来实时计算,这也就是数据中台所需要提供的能力。

    总的来讲,对于那些拥有 ERP 系统的企业来讲,中台实施的深水区必然涉及到要重构原有 ERP 系统,因为传统 ERP 和中台的核心理念是冲突的,所以我用“去 ERP 化”作为企业中台实施第二个阶段的名称,不意味着一定是要抛弃 ERP 软件,而表示要将传统的以资源计划为核心,以集约化为目的的业务系统转型为以客户为中心的业务中台。

    “去 ERP 化”的过程一般会分为两个步骤,由于篇幅原因,这里我们简单介绍一下:

    一、将相对比较独立的真正的企业后台,比如财务,人力资源这些模块保留在后台 ERP 系统,其他的业务模块基本上都会从单体架构变成分布式的微服务架构,如下图所示:

     

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    这个拆解重构的过程,最重要的一个标准就是将原来的 ERP 流程拆解出可独立提供业务价值的微服务。

    在这个阶段,我们认为,偏后端的 ERP 模块,比如财务、人力资源,还是会保留的,拆解的目的不是为了微服务而微服务,是为了能够对齐和提供客户价值。

    二、一切应用云化,应用与数据分离。

    在第一步的基础上,我们展望未来,会发现有一个趋势:最终,一个个的单体架构的后端系统都会随着云计算、大数据处理技术的发展,变成一个个的可独立运行的微服务。

    企业的后台系统会被分解成一个个的分布式的微服务架构,能够被管理、被编排、被治理,每一个微服务有自己基于云的数据存储,物理上是分布式的。

     

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    小结

    我用下面这张图来概括中台发展的三个阶段,最终我们发现,对于那些已经有 ERP 系统的企业来讲,中台的建设本质就是利用微服务架构构建开放业务平台来替换闭源单体架构的 ERP 系统的过程。

    你知道数据中台,但你不知道它和ERP、数据仓库背后的关系

     

    中台的构建过程是企业转型的过程,是企业从流程为核心走向以客户为核心的转型,是企业从以人的经验驱动走向数据智能驱动的转型。

    中台概念的崛起和落地代表了中国部分领先企业逐渐走入了企业管理体系的无人区,已经没有以前的西方先进管理经验可以照搬,需要的是快速试错和高速响应的能力。

    而这一切,也许要从“去 ERP 化”开始,让我们和过去的 ERP 说一声“珍重”。

    展开全文
  • 目录数据平台数据中台数据平台与数据中台的区别与联系区别联系整体架构硬件层&虚拟化数据平台存储能力计算能力管理平台数据中台数据仓库数据集市数据开发数据运维赋能对象赋能管理者赋能业务运营赋能业务中台...

    数据平台

    • 数据平台是在数以万计的硬件之上建立统一的基础数据存储和计算的服务,当然我们所建设的数据平台需要周边一些辅助的服务来支撑核心服务的运行,以及一些数据平台管理类工具,辅助日常SRE工作

    数据中台

    • 数据中台是抽象了数据能力的共性形成的数据服务能力,是一系列数据服务,用系统化思路解决数据前台对数据获取的难度,更好的赋能业务

    数据平台与数据中台的区别与联系

    区别

    • 核心区别是-是否跟业务强相关
    • 数据平台和业务的联系并不密切,提供基础的存储,计算,调度,数仓工具等基础的技术服务,至于业务数据怎么存储,数据表如何组织,数据模型如何建,数据如何服务业务,数据平台并不关心
    • 数据中台的目的是通过系统化思路的去组织数据,让数据更好的服务业务,包括数据前台的报表,自助分析,OLAP,维度指标管理,业务中台等

    联系

    • 数据平台是数据中台的基石,数据中台要基于需求业务体系,在数据平台之上去建设数据体系
    • 数据中台的建设,也会给数据平台带来更多的技术需求和压力,促进数据平台技术栈更加多样性,性能向更优化方向发展

    整体架构

    • 此处的图是包含了这个数据生态的基本体系架构,从低向上的依赖关系
      在这里插入图片描述

    硬件层&虚拟化

    • 基础的IT设施,提供基本的运力
    • 万物上云,为云上的服务提供动态缩放的能力,降低整个it设施的成本,提高it设备利用率,当然很多公司的数据平台还有很多直接基于硬件搭建的

    数据平台

    存储能力

    • 分布式文件系统,不论是基于磁盘还是基于内存,只是不同存储成本的文件系统,带来不同存储性能和特性
    • MQ类的主要支持数据采集和实时计算
    • 数据库主要支持查询类和实时计算,类别很多,关系型,nosql,各有千秋

    计算能力

    • 离线计算,提供批处理计算能力,主要负责天,周,月等数据生产,主流的像早期的mr,后期的spark等
    • 实时计算,提供实时数据处理能力,负责实时数据生产,当然实时离线是我们人为划定的时间界限,对于引擎而言,像spark,flink都提供实时和离线的解决方案
    • 算法平台,主要提供机器学习,人工智能,数据挖掘的计算能力,算法框架的选择也是很多,当然在大数据生态还是需要运行在yarn这样资源管理平台,才可以发挥大数据的价值
    • 查询类服务,提供一些和用户交互的查询能力,像一些mpp框架等,多数提供sql查询能力

    管理平台

    • 管理平台,是在原生的大数据生态的基础之上,为了更好的管理集群服务,管理集群的资源,提供灵活SRE能力和资源核算审计能力的一系列工具和合称

    数据中台

    数据仓库

    • 数据中台包括数据仓库的全部内容,数据仓库为数据中台提供了数据对外提供服务的基础资源,数据中台将数据仓库建设的投入价值进行最大化,以加快数据赋能业务的速度
    • 大家都知道数据仓库需要分层建设,需要面向业务主题,但是规范和落地往往是有差异,中台可以帮助数仓建模流程从文档化向标准化迈进,降低由于团队认知差异带来的数仓规范不统一的风险

    数据集市

    • 集市层主要面向具体应用做开发,是数仓向数据前台数据的重要连接层,数仓建设的好坏,对数据集市的建设影响很大
    • 数仓和数据集市同样都面临数据重复建设,数据不一致的问题,需要中台协助数仓和数据集市规范化落地

    数据开发

    • 数据中台需要改变原来的开发模式,提供全流程的数据开发解决方案,规范开发流程的每一个步骤,达到大一统的效果
    • 维度指标元数据管理
    • 指标树主要维护了指标和指标之间关系,比如某个衍生指标是有哪些基础指标通过什么计算公式计算得到,这个关系很重要,这是做智能异动分析的基础,可以实现很多自动化的异常数据监控和分析能力
    • 指标地图主要维护了指标和数据的物理存储的关联关系,通过地图我们可以轻松到找到哪些维度指标存储到了哪些物理存储里面
    • 建模工具来帮助数仓和数据集市规范的落地,如果没有工具协助,我们制定再好的仓库分层方案,仓库建模方案都是徒劳的,经过长期的累计和人员流动,非常容易导致规范落地不标准,导致数据不一致等一系列问题
    • 开发工具主要协助RD对ETL代码管理,如果还是通过原始命令+sql文件方式来管理ETL,那开发效率会很低,而且对依赖关系和调度的管理也是问题,开发工具会贯穿几乎开发的全流程,来加速开发

    数据运维

    • DQC,数据质量监控,提供日常数据质量监控能力,是保证数据一致性的基础,DQC一般提供的基础的质量监控,比如基础的同环比阈值监控,条数监控,空数据监控,均值监控等
    • SLA,数据按时生产的参考标准,etl任务健康度评估的重要指标,保证数据按时交付,确定etl任务的优化目标
    • 异动分析,为业务提供自动化的数据波动分析能力,帮助业务人员定位异常根源,快速调整业务决策
    • 资产管理,数据中台的核心资源就是数据,数据以资产形式管理起来,可以是我们精确的知道我们拥有数据的情况,以方便对数据资源的管理
    • 生命周期管理,数据都有时效性,随着时间推移,需要对数据进行生命周期管理,做合理的清理,属于数据治理的子模块

    赋能对象

    赋能管理者

    • 赋能管理者,大盘类,大屏类产品,提供综合的,上层的业务视角的数据,来为管理者提供管理决策需要的基础数据
    • 提升一点,可以配合业务经验和AI,来提供辅助决策意见,辅助管理者做决策

    赋能业务运营

    • 赋能业务运营,报表类,自助分析类产品,提供了比支持管理者产品更细粒度的数据,可以渗透到业务细节中,为底层运营决策提供精准的数据支持能力

    赋能业务中台

    • 赋能业务中台,没有数据的赋能,业务中台也还是偏向于业务公共服务的抽象,只有数据中台的赋能,才能使业务系统是一个智能化的业务系统
    • 比如像"千人千面"的推荐系统

    赋能数据变现

    • 赋能数据变现,精准营销的广告系统,为广告带来更高的流水

    赋能合作伙伴

    • 赋能合作伙伴,强大的数据服务能力,可以为合作伙伴提供正确的决策方向,达到共赢的状态
    展开全文
  • 大数据中台

    千次阅读 2020-08-28 11:17:11
    数据中台的由来 数据中台最早是阿里提出的,但真正火起来是2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设...数据中台包含数仓体系、数据服务集BI 平台。 1、是...
  • 个人理解数据中台与大数据平台区别
  • 问题导读: 1、如何理解数据中台? 2、数据仓库、大数据平台、数据中台都是什么? 3、大数据平台硬件架构如何设计?... 技术层面的有数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台...
  • 近期总有朋友咨询各类云平台的性能相互关系,现整理出几个概念,希望对大家能有帮助: 理解云平台要从三个层次来理解,同时考虑其是开源还是闭源的: 1、IaaS(Infrastructure as a Service:基础设施即服务)...
  • 前言 2010年左右,还是在上学的时候,学过一门...如今,十年风云际会,大数据早已成了行业绕不开的话题,这其中我们或多或少会接触到很多新兴的概念,例如数据湖、数据中台等,通过一些碎片化的学习,也是大概知...
  • 导读:随着“中台”战略的提出...本次直播,宜信科技中心AI中台团队负责人王东老师分享了宜信AI中台的具体实施路径,并重点介绍了AI中台的智能产品——智能聊天机器人平台,包括智能聊天机器人平台的背景理念、设...
  • 2、解读中台 -- 中台的作用

    千次阅读 2019-10-06 19:43:41
    中台与企业现有的ERP,CRM是什么关系? 如果建设了中台,中台应当如何发挥作用,而不是又让企业陷入建设另一套IT系统的老路? 1、中台的分类 中台是从多个相似的前台业务应用共享的需求产生的,因此最先提出的中台是...
  • 大数据与线上事务系统(OLTP)的联动场景非常多,比如我们在电商平台查询个人所有历史订单,再比如一些刷单、反作弊的实时拦截,以及一些实时推荐等,这些都是通过将数据的运算交给数据中台部门处理,前台部门直接...
  • 就在刚过去的半年里,「中台」成了技术圈内讨论的热门词汇,就连一些名不见经传的小公司,也都纷纷喊出了「要向中台转型!」的口号,甚至有人说「不做中台,那就等着死吧!」 如果我没有记错,「中台...
  • 中台思想

    千次阅读 2018-11-08 17:34:40
    中台这个概念 主要用于 大型的互联网项目架构企业组织架构平台中平台。 举例:1.大型互联网项目。 京东,淘宝。一个购物商城平台。 如果是烟囱式的架构,从头到尾, 那可能会大到 产品研发人员自己都不知道...
  • 全渠道零售中台与数字化转型(1)-中台的前世今身

    千次阅读 多人点赞 2019-06-25 15:37:59
    本系列博客的目标是计划使用近半年时间创造: ... 全渠道零售中台与数字化转型(2)-中台给企业业务带来什么实际的价值 全渠道零售中台与数字化转型(3)-中台给企业技术带来什么实际的价值? 全渠...
  • 将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务台和数据中台构建起数据闭环运转的运营体系,供企业更高效地进行业务探索创新,实现以数字化资产的形态构建企业核心差异化...
  • 数据中台就是以云计算为数据智能提供的基础计算力为前提,与大数据平台提供的数据资产能力与技术能力相互结合,形成数据处理的能力框架赋能业务,为企业做到数字化、智能化运营。 目前,外界与业内很多人对于数据...
  • 内容来源:宜信技术学院第3期技术沙龙-线上直播|AI中台——智能聊天机器人平台 主讲人:宜信科技中心AI中台团队负责人王东 导读:随着“中台”战略的提出,目前宜信中台建设在思想理念及架构设计上都已经取得了很多...
  • 内容来源:宜信技术学院第2期技术沙龙-线上直播|宜信敏捷数据中台建设实践 分享嘉宾:宜信数据中台平台团队负责人 卢山...它们宜信数据中台是怎样的关系?又是如何驱动各种日常数据业务场景的? 本次分享对这些问...
  • 如何搭建企业中台

    千次阅读 2019-08-10 22:53:09
    1.解读一:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,我们叫它“技术中台”。 2.解读二:中台就是一组公共的微服务平台,像最常见的什么用户中心、订单中心、商品中心等等,各种...
  • BI工具数据中台有什么区别?

    千次阅读 2019-05-15 20:12:44
    说到BI工具数据中台,不得不先说数据。数据是由企业在日常管理、经营活动、行业信息外界的市场动态等产生的综合信息。这些信息经过分析,得出的数据决定了企业能够就产品、服务、员工、战略等做出正确决策的关键...
  • 前言 中台架构一词最近在技术圈内比较火,波波基于自己的经验视角,也来凑个热闹聊聊什么是中台架构。...Kubernetes平台封装了构建微服务技术中台所需的关键基础服务,它是波波推荐的,构建微服务...
  • 数据中台到底是什么?

    千次阅读 2019-06-29 20:01:05
    阿里提出了“大中,小前台”,其中事业部包括搜索事业部、共享业务平台、数据技术及产品部,数据技术及产品部应是数据中台建设的核心部门。 那么,数据中台到底是什么?具体包含哪些内容?跟大数据平台是什么...
  • 数据中台设计方法论

    万次阅读 2020-05-24 14:00:44
    数据中台建设过程涉及到大数据平台建设、数据仓库建设、模型算法、数据治理、数据服务等一系列工程,不可能一蹴而就,我们需要梳理业务场景,看他们需要什么样的服务先找一个业务场景,搭建起数据中台的服务能力,...
  • 什么是前台?什么是中台?什么是后台?

    万次阅读 多人点赞 2019-12-05 15:57:42
    什么是前台? 首先,这里所说的“前台”“前端”并不是一回事。所谓前台即包括各种用户直接交互的界面,比如web页面,手机app;也包括服务端各种实时响应用户请求的业务逻辑,比如商品查询、订单系统...什么是...
  • 今天咱们第一课,来讲讲大家一直很关注的...对于中台每个人可能有不同的理解,行业里也没有严格的定义,但我更认同其中一个说法就是:中台是企业级能力复用的平台。 那这句话怎么理解呢? 既然核心是能力复...
  • 微信开放平台 主要面对移动应用/网站应用开发者,为其提供微信登录、分享、支付等相关权限服务。 微信开放平台还提供了数据统计功能,用于开发者统计接入应用的登录、分享等数据情况。 接入步骤 已京东APP举例...
  • 台和这个,两者有什么关系呢? 中台这个概念就是在2015年,被马老师以及阿里团队提出来的。在参观了一家游戏公司后,回来就在阿里整个集团层面启动了 “大中,小前台” 的战略。 现在中台已经越来越流行了,...
  • 数据中台你想知道的都在这里!

    千次阅读 2019-06-30 11:38:38
    数据台和数据仓库,数据平台关系是什么? 数据台和业务中台的区别是什么? 数据中台建设的最大挑战是什么? 数据中台的数据质量应该如何保障? 数据中台的典型架构是怎样的? 企业...
  • 5个步骤,打造你的业务中台

    千次阅读 2020-04-13 16:15:49
    因此业务中台的架构思路整体策略保持一致,并进行必要的补充。以下,Enjoy: 01 业务抽象 在业务抽象阶段,通过业务调研业务分析,设计业务蓝图抽象业务元素,为下一阶段的中心建模阶段准备顶层思想...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 249,945
精华内容 99,978
关键字:

平台和中台的关系