绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
湖+仓≠湖仓,什么才是真正的湖仓一体?
2022-01-12 14:58:41
文/高博

前段时间Databricks和Snowflake因TPC-DS测试结果在湖仓战场正面开撕,让很多业内吃瓜群众大呼过瘾,我们暂且不论两企业究竟孰强孰弱。众所周知,Databricks自始至终都主打数据湖这张牌,而Snowflake则是靠云数仓库起家,有意思的是两大玩家殊途同归,决赛场最终聚焦在了当前炙手可热的Lakehouse-湖仓一体。这说明了什么?

说明湖仓一体化才是大势所趋啊,兄弟!

数据湖、数据仓、湖仓一体发展历程

提到湖仓一体,就不得不从上世纪80年代开始说起。如上图所示,当时的市场还是数据仓库的天下,当时主要是用来处理BI、仪表、报表等结构化数据,主要用于分析企业的内部的业务数据。这种状态一直持续到2011年前后,越来越多的企业产生了语音、视频等数据的处理分析需求,非结构化数据、半结构化数据的增长促使企业提升了高多样性,高速度和高容量的数据分析要求,数据仓库慢慢不能满足用户的需求。

随着数据仓库局限性的逐步显现,数据湖的概念也随之衍生出来,它能够存储各式各样的原始数据,解决了数据仓库的局限性。但相比于优势来讲,湖的短板也同样明显,比如不支持事务,SQL性能差,无法支撑报表需求。而这也间接推动了湖仓一体概念的出现。

虽然数据湖和数据仓都各自有各自的优势和不足,但不难发现,二者在某些层面是非常互补的,如果我既有成型的数据湖也有现成的数据仓,我直接将数据湖和数据仓库互相“打通”不就可以了?事实证明很多大企业也确实是这么做的,这样做的优点在于,我可以充分利用先前的数据湖和数据仓库资源,利用ETL将二者“打通”,数据湖用来存储各种原始数据,分析报表交给数据仓库来完成,这也可以算是湖仓一体的一个雏形,但湖和仓基本上还是处于各自一体的状态,架构仍然较为复杂,在满足需求的同时也持续提高了企业的运维成本。但不管怎么说,“湖仓一体化”这个概念算是成了!


谁说湖仓一体一定要先有“湖”?


在大家都聚焦于湖仓一体概念的时候,一向专注于数据仓库的偶数科技也逐渐走到聚光灯下。为什么以数据仓库见长的偶数科技也要搞湖仓一体?偶数的“仓”有了,可“湖”在哪呢?

通过笔者与偶数科技解决方案专家钟总的交流,得到了非常前沿的观点,“湖仓一体为什么一定要先建湖?”这颠覆了之前我对湖仓一体的认知。

有“湖”有“仓”,然后连通在一起,并不是真正意义上的湖仓一体,“湖仓一体是‘湖’与‘仓’融为一体,而非各自一体并进行连接。我们虽然没有大力提倡数据湖,但是却依靠创新的数据仓库技术解决了数据湖的问题。”钟总提到,所谓湖仓一体中的“湖”,一方面是对结构化和非结构化数据的支持,另一方面是做对海量数据的存储。因为偶数科技的数仓真正做到了存算分离,弹性可扩展,自然也就支持“湖”的海量数据扩展能力。

细细分析一下也就不难理解,这种方案本质是将数据湖、数据仓真正的融为一体。数据就是一份,底层是企业的全部数据,包括结构化、半结构化、非结构化,中间通过统一的加工处理直接支撑上层所有仓的应用(BI、报表以及湖的应用),不再需要ETL连通,数据能够直接用来进行分析。
可能有些读者也理解到了,偶数科技的技术路线和美国的Snowflake在湖仓一体的思路更为相似。主要依托云原生特性、计算存储分离架构、强事务特性、完整SQL标准支持、高性能并行执行能力等一系列底层技术的变革,从而实现高弹性、高性能、强扩展性、强兼容性,以及机器学习等上层技术的变革,最终帮助企业有效应对大规模、强敏态、高时效、智能化的趋势。

而这种湖仓一体架构往往需要具备必要的特性:


首先需要通过低成本的方式实现全量数据单一存储;高性能的数据引擎也是不可或缺的;要实现存算分离,满足架构的敏捷性需求,通过可插拔存储框架实现架构的可扩展性;当然,通过ACID特性简化应用程序负担,保证事务的一致性也是必须的;此外还要做到在一个平台上支持所有的工作场景、负载场景,比如批流一体,批处理、即席查询、数据分析(BI)、机器学习(ML)等,实现多样化工作负载;最后要通过可落地的数据治理更好的保证数据质量,从而更好地支持应用。只有具备以上这些特性,才可以说是一套真正的湖仓一体。而偶数科技的湖仓一体架构也恰恰符合这些特性要求。

相比于湖、仓各一套集群再打通,偶数科技这种湖仓一体的架构的确更加简单,也正是因为这种极简化,使其在运维人员、硬件投入等方面的投入大大减少;由于OushuDB云原生的产品基因,通过虚拟计算集群技术能够让资源进行弹性伸缩并按需分配,在需要时对资源进行充分运用,不需要时进行资源释放和共享。存储层数据只有一份并实现了实时共享;计算层资源可以按需调度、弹性伸缩,极大提升了资源利用率,降低了企业硬件投入及人员成本。

从市场发展走向来看,“湖仓各自一体”的架构是基于技术发展进程的必经之路,优势很明显,缺点也同样突出,而更为简单的“湖仓原生一体”架构在未来将更加契合用户对于湖仓一体化的诉求。


湖仓一体化,你怎么看?


最后还是要抛出个问题给各位看官,如果您的企业目前已有成型的数据湖和数据仓可用,并通过上文所讲“搭桥”的方式连通“湖”和“仓”,是否还要进行真正的湖仓一体的架构升级?

如果您有自己的想法,不妨评论区大家一起来交流一下!
分享好友

分享这个小栈给你的朋友们,一起进步吧。

万万的技术栈
创建时间:2020-12-22 09:07:13
万万是一名开发者,always running
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • 万万
    栈主
戳我,来吐槽~