人柱力和佩恩六道，谁才是湖仓一体的终极形态？

很多小伙伴一直搞不懂什么是湖仓一体，查阅很多资料得到的都是基于不同厂商的产品和方案介绍，而非清晰的概念与行业共识，所以笔者特别策划了一篇湖仓一体的比较分析，通过《火影忍者》中两个重要角色的类比帮你瞬间搞懂湖仓一体。

想必火影老粉对九尾人柱力和佩恩六道这两个角色的印象应该非常深刻，不过在此还是先给不熟悉火影的读者快速科普下。

火影世界有九个巨型怪兽祸乱人间。为了世间和平，尾兽们被封印在了不同人类的体内。人柱在日本文化中被视为一种蕴藏神明力量的灵魂容器，人柱力即被尾兽附身的人，为封印尾兽而存在。人柱力可以通过驯服体内的尾兽获得巨大力量，人柱力与尾兽一荣俱荣，一损俱损。

佩恩六道是由六具死者尸体改造成的六个傀儡忍者，统称为佩恩六道。每个佩恩的脸上和身体都插着能连接信号的黑棒形状的查克拉接收器，六个佩恩能共享彼此的视野。佩恩六道的操纵者长门通过背后插满黑棒作为信号和查克拉接收器操控每个佩恩。

抛开角色的性格和战力，佩恩六道和人柱力最本质的区别就是物理层面的身体隔离：佩恩六道是六个傀儡忍者的战斗组合，而九尾人柱力是一个忍者肉身住了两个灵魂。二者的差别像极了目前软件行业上湖仓分体和湖仓一体概念的架构差异。

在分析型数据库（OLAP）领域，曾先后出现 MPP 和 Hadoop，MPP 数据库主要用作数据仓库，Hadoop 大数据平台承担起数据湖的职能。

因此，随着用户对湖和仓的要求不断提高，自然会出现湖仓协同的尝试和探索，也就形成了 MPP+Hadoop 模式，我们称之为湖仓分体模式。湖仓分体模式下的湖、仓各自独立部署，数据通过 ETL 的方式打通。正如佩恩六道，每个傀儡忍者的肉身是独立的，但视觉是共享的，由长门通过查克拉接收器进行整体操控。

通过佩恩六道形象的理解了湖仓分体，九尾人柱力自然就成了湖仓一体的最佳阐释。湖仓一体架构下的湖和仓是原生一体的，物理层面部署在同一集群，共享同一份数据，没有数据冗余。正如九尾妖狐封印在鸣人（人柱力）体内，肉身层面天然一体，不可分割。

将九尾人柱力比作湖仓一体，将佩恩六道比作湖仓分体，并不意味着湖仓一体和湖仓分体的“战力”也如漫画原著一样存在争议。湖仓一体与湖仓分体不仅在架构层面有着差异，架构设计理念对企业数据基础设施建设的影响也是巨大的。湖仓分体模式，也就是 MPP+Hadoop 模式的最大问题和特点就是数据孤岛，造成数据孤岛的原因有几个方面：

1、技术架构原生造成的数据孤岛

       

        

湖仓分体方案基本上是以湖、仓和其他组件构成，逻辑上为用户提供统一的数据管理，但物理层面湖和仓仍然是分离的，同一份数据在多个集群冗余存储，导致分体模式下的湖和仓各自形成数据孤岛。

2、集群规模受限造成的数据孤岛

       

        

多数的湖通过 Hadoop 构建，数仓是 MPP 数据库，当数据达到 PB 级别，由于 Hadoop 和 MPP 集群规模受限，企业往往会部署和使用多个 Hadoop 集群和多个 MPP 集群，事实上进一步造成了数据孤岛。

3、高并发被迫形成的数据孤岛

       

        

越来越多的分析应用场景导致了逐渐高涨的并发查询需求，无论是 Hadoop 还是 MPP 都法支撑这种复杂查询的并发需求。MPP 数据仓库单一集群支持的并发数仅达到几十左右，而 Hadoop 支持的并发则更低，因此一个遍历数百 TB 数据的复杂查询可能使整个系统的性能受到很大影响。为了满足高并发，企业不得不把业务分割到更多的集群中，造成更严重的数据孤岛。

湖仓一体通过什么样的技术实现的？

随着公有云和私有云的普及，为了保证存储和计算可以独立的弹性扩展和伸缩，数据平台的设计出现了一个崭新的架构，即存算分离架构。MPP 数据库存算耦合，而 Hadoop 不得不通过计算和存储部署在同一物理集群拉近计算与数据的距离，因此 MPP 和 Hadoop 都不再适应云平台的要求。在此阶段，Snowflake 和 OushuDB 突破了传统 MPP 和 Hadoop 的局限性，率先实现了存算完全分离，成为湖仓一体实现的关键技术。       

以 OushuDB 为例，实现了存算分离的云原生架构，并通过虚拟计算集群技术在数十万节点的超大规模集群上实现了高并发，保障事务支持，提供实时能力，一份数据再无数据孤岛。      

火影老粉对九尾人柱力和佩恩六道两角色的战力之争从未停止过，就像现阶段湖仓一体市场上的分歧持续存在着，但是正如九尾人柱力头顶主角光环一样，湖仓一体架构必将在群雄逐鹿之后的数据管理领域成为关注焦点。