数据湖和数据中台的区别?

数据湖和数据中台的区别?

一、数据湖的定义

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

但是随着大数据技术的融合发展,数据湖不断演变,汇集了各种技术,包括数据仓库、实时和高速数据流技术、数据挖掘、深度学习、分布式存储和其他技术。逐渐发展成为一个可以存储所有结构化和非结构化任意规模数据,并可以运行不同类型的大数据工具,对数据进行大数据处理、实时分析和机器学习等操作的统一数据管理平台。

二、数据中台的定义

关于数据中台,笔者查阅了很多资料,也没有找到对于它的确切和标准定义。事实上也是如此,实际上,数据中台是一个具有“中国特色”的概念,在国外并没有太多人谈论数据中台。

通俗来讲,数据中台是一套可持续“让企业的数据用起来”的机制,一种战略选择和组织形式,是依据企业特有的业务模式和组织架构,通过有形的产品和实施方法论支撑,构建一套持续不断把数据变成资产并服务于业务的机制。

三、数据湖与数据中台的关系,数据湖和数据中台的区别

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

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

数据湖和数据中台的区别?

数据中台从技术的层面承接了数据湖的技术,通过数据技术,对海量、多源、多样的数据进行采集、处理、存储、计算,同时统一标准和口径,把数据统一之后,以标准形式存储,形成大数据资产层,以满足前台数据分析和应用的需求。

数据湖更强调应用,离业务更近,强调服务于前台的能力,实现逻辑、算法、标签、模型、数据资产的沉淀和复用,能更快速的相应业务和应用开发的需求,可追溯,更精准。

以上就是思迈特软件今天分享的数据湖与数据中台的相关知识。
感谢您的阅读,更多知识,请继续关注我们,下期再见!
广州思迈特软件有限公司(简称:思迈特软件Smartbi)是国家认定的“高新技术企业”,专注于商业智能(BI)与大数据分析软件产品和服务。我们在BI领域具有15年以上产品研发经验,提供完整的大数据分析软件产品、解决方案、以及配套的咨询、实施、培训及维护服务。

相关内容

中台vs平台区别与联系

  我们都知道中台和平台都是企业通用能力的抽取与沉淀这是毋庸置疑的,那两者之间的区别又是什么呐?为何在平台之上又提出中台概念呐?笔者最近在拜读欧创新大神大作《中台架构与实现---基于DDD和微服务》偶有感悟暂且大胆一说如有谬误及误人子弟之处望各位读者不吝赐教,轻拍轻拍。
  首先中台与传统平台的的区别就是中台提供的的是企业级的解决方案更加贴近业务一线而平台一般来说提供的都是非企业级解决方案其定位更多是通用功能并且有远离业务的倾向以期提供更大的通用性,其造成两者区别的本质原因在于两者的定位和owner不同。具体来说平台只提供了企业级的功能或者解决方案的一部分需要前台部门在此基础上做额外大量开发才能提供用户面向用户的完整功能。这会造成两个问题一个是前台部门还需要花费额外的人力开发,如果功能相似则势必造成重复开发的人力浪费再一个就是由于各前台都在平台基础上做二次开发势必造成用户体验在相似功能上的不一致。
  举例笔者公司微信平台为例说明:
  背景就是微信平台提供的前台调用方可通过openId换取user id功能。但是微信绑定时候是可以绑定多个用户id的,平台在返回时候会把这个openid对应的所有绑定的user id都返回给调用方甚至包括解绑的user id,并加上绑定状态作为区分。
  从平台的角度来说这个设计没有问题基本提供了所有调用方可能用到的所有数据提供了最大的通用性因为他无法确定各个调用方是如何使用这个openId的但是这里就会有前面提到的两个问题比如线下购物团队需要通过微信open id来确认用户身份发现绑定了多个可能会觉得该账号存在问题则直接拒绝认证。而另外团队可能觉得绑定都需要经过非常严密的步骤,安全行都是可以保证的不如每次都取最新的好了。这样两个团队都需要额外开发自己的认证功能并且给用户体验是不一致的,用户在一个功能上可以绑定成功换个功能点竟然怎么绑定都不行肯定会非常的confused。
  如果是最为一个微信认证中台来说设计可能是这样的:他提供一个通用的用户微信平台认证功能,如果open id绑定了多个则比如直接返回最新的user id这样一个企业级的解决方案(为甚说是企业级的因为这个功能对用户来说就是一个完整的功能)。这样不同团队在使用时候就直接拿到了user id不需要额外开发并且对用户来说体验也会非常的一致。
  大家看出两者实现上的背后的原因了么?那就是两者背后的定位和owner不同,作为微信平台来说他只是微信相关功能的一个汇聚他并不了解具体的使用场景是什么样的因为他的owner够不到前台,而后者作为中台他的定位和owner就是用户认证说白了他的owner够的到前台他说了能算。
  所以说如果企业要做中台转型肯定不仅仅是IT部门一帮程序员闷头梳理模型闭门造成就能做成的这个涉及到公司整体组织架构调整以及思路上的一个转变。一个是业务部门要认同这个事情业务部门本身就要界定好那些功能是中台care的那些功能是前台care的,另外一个是中台的演进上中台要作为一个企业级方案提供团队去演进和迭代当然是也可以接受前台部门提供的需求。

中台结构与实现 基于DDD和微服务
赞(1)

文章来源于网络,原文链接请点击 这里
文章版权归作者所有,如作者不同意请直接联系小编删除。