现在是采用湖仓一体的好时机吗？

采访嘉宾 | 关涛

编辑 | 蔡芳芳

近日，大数据独角兽 Databricks 官宣 H 轮融资，经过这一轮 16 亿美元融资，其估值已经飙升至 380 亿美元。Databricks 联合创始人兼首席执行官 Ali Ghodsi 在媒体采访中表示，这笔资金将主要用于加速构建在 lakehouse（湖仓一体）赛道的布局。

作为一个新兴的数据架构，湖仓一体正成为兵家必争之地，赛道上的玩家既有 Databricks、SnowFlake 这样的初创公司，也有亚马逊、谷歌、阿里这样的头部云厂商。湖仓一体新架构真的能落地吗？有哪些可行的落地路径？成本又来自哪里？面向未来的新一代数据架构还有哪些趋势需要关注？我们带着这些问题采访了分布式系统和大数据平台领域专家关涛，他给出了自己独到的洞察和理解。

湖仓一体的不同解法

InfoQ：数据湖和数仓融合架构（即湖仓一体）是当下大数据领域非常重要的议题之一，不仅各大云厂商先后提出了自己的技术方案，开源社区也有一些项目非常活跃。在您看来，目前业内对湖仓一体的定义是否达成一致了？不同厂商推的湖仓一体技术方案有哪些关键差异？

关涛： 我认为目前业内对湖仓一体的整体大方向是高度达成一致的。很多厂商都在重点推湖仓一体的概念，比如 Databricks，它现在整个产品就是基于分析和 AI 的 Lakehouse Platform，Snowflake 和 Redshift 也都向湖仓一体做了非常多的倾斜和资源投入。从这个层面讲，大家都意识到了：数据湖需要更好的管理能力、数据仓库需要更好的灵活性。

但大方向之下，不同厂商的实现路径确实各不相同，这也和厂商自己的产品方向、技术基础直接相关。比如 Databricks，它是以数据湖为轴发展起来的一套系统，所以它更多谈的是从湖向仓怎么走，最终走向湖仓一体。对于像 Redshift 这样的厂商，包括 MaxCompute，是以数仓为核心，所以是从数仓向湖上走。

对于以数仓为轴的厂商来说，通常湖和仓是左右摆布的，左边是一个数据库，右边是一个数仓，然后数据湖和数仓之间有数据流动；对于以数据湖为轴的厂商来说，很多时候他们是在数据湖之上再做一个数仓，更像是一个上下结构。

InfoQ：您在之前一篇关于湖仓一体的文章中曾提到“数据湖与上云无关”，那湖仓一体是否也不一定非要上云？

关涛： 我觉得这个问题需要分两个层面来看。第一个层面，我们如果看数据湖最标准的定义，它实际就是指一个基础的文件存储系统，在文件存储或者数据存储的时候，不用关心数据的格式，不用做非常复杂的建模和数据管理。从这个层面来看，最传统意义上的数据湖定义确实和云没有什么关系。像线下部署的 Hadoop 体系，甚至存储计算不分离，只要它满足刚才说的这些分布式存储的特性，其实都算数据湖。

但是从另外一个层面上讲，现代的数据湖定义实际上跟云强相关。现代的数据湖定义实际上是希望把存储托管到云存储上，使用户能够通过托管避免非常复杂的分布式有状态系统的运维、支持等工作。那从这个层面上讲，现代的数据湖几乎都是以云为轴来做的。

后面一个问题是说湖仓一体是不是不一定非要上云，其实不见得。当然我们说上云更多是指上公共云，很多用户线下有自己的专有云，湖仓一体也可以部署到用户线下自己的所谓云平台上去。但从另外一个层面上讲，云的本质又变成了一个对基础设施的抽象和定义。如果说技术抽象成多层的话，它还是一个云架构，至于是部署在用户的机房里，还是部署在大的云厂商的机房里，只是部署形态的差别。

落地路径与成本

InfoQ：现在大多数企业都已经有了自己的一套大数据架构，他们如何基于已有的架构落地湖仓一体？有哪些可行的落地路径？成本可能主要会来自哪里？

关涛： 现在有一部分企业已经有了自己的大数据架构，这些企业相对来说可能诞生的比较早，大多数都是选的 Hadoop 体系，或是自建的 Hadoop 体系，或是使用云上托管的 Hadoop 体系。这些企业可以有很多选择，他可以选择像 Databricks 那样的方案，也可以选择像 MaxCompute 这样的方案。

这两条路径都相对可行，那怎么选？这通常要看企业是不是希望在大数据技术栈上做更多投入。如果企业觉得没必要在基础设施上投很多资源，而是要把更多资源放在业务上，那选一个更偏全托管版的湖仓一体解决方案更有价值。反之，如果企业技术人员很多，希望底层基础设施足够灵活并且是自己可控的，就可以选择在湖上建仓的模式。

还有一些比较新的企业，比如过去三年内成立的，它们有很多都处于高速增长阶段。这些企业其实天生就长在云上，甚至一开始选的大数据架构就已经是云数仓的架构，这类企业基于现有的架构向前演进相对比较简单。只要尽量使用云基础设施，开通几个云服务就能形成一套湖仓一体架构了，这是一个简单直接且相对单一化的路径。

那成本主要来自哪里？如果企业选择全托管的湖仓一体解决方案，则成本主要来自于对当前数据，比如数仓迁移、数据整理等一次性开支，一旦这部分工作做完，后续在数据治理上形成正循环，整体成本不会太高。如果企业选择自己维护一套湖仓一体架构，则成本主要来自持续维护和调优整套基础设施的人力成本和硬件成本。

InfoQ：根据您的了解，当前企业尝试落地湖仓一体的时候遇到的问题和挑战主要有哪些？现在是采用湖仓一体的好时机吗？

关涛： 现在大多数企业都还没有用到湖仓一体的新架构，他们要么选择了数据湖方案，要么选择了数仓方案。湖仓一体作为一个新兴架构，很多企业目前还在早期探索阶段。有些企业在把数据放到数据湖上之后，发现在数据湖上做好数据治理或者数据管理相对比较困难，这个时候再去采用湖仓一体模式，在现有相对更灵活但不够管理化的数据上，再抽象一层数仓层和治理层，对数据做更好的管理和治理。对于数仓的用户，如果采用的数仓系统支持湖仓一体架构，直接挂载数据湖就好了。

企业尝试落地湖仓一体时会遇到的问题和挑战主要有几点。首先，如果团队没有足够好的数据治理或数据管理经验，挑战会比较大。这也是为什么我们推出的方案几乎都在向全托管或全服务的 SaaS 模式走，就是希望能够降低门槛。

其次，对于自建湖仓一体的企业，他们会遇到的挑战主要是湖仓一体的高复杂度，特别是湖仓之间如何协同的问题，这里面涉及到两套系统存储打通的问题、元数据一致性问题、湖和仓上不同引擎之间数据交叉引用的问题，以及带宽问题、安全问题，等等。另外，由于湖仓一体架构底层是一个二元体系，那向上面向用户的时候，用户是不是能看到两个体系？如果用户能够看到两个体系的话，如何区分和引导？如果用户看不到的话，那底下开发需要做什么样的封装？这些都是自建湖仓体系会遇到的问题。

总之，如果企业并不是一定要大力投入做基础设施的话，直接采用全托管版本的湖仓一体的架构会简单很多。

最后，湖仓一体还是一个新兴的方向，很多问题还在探索中，比如哪些数据放在数仓 / 数据湖？更适合有一定探索和创新意愿的企业。

新一代数据平台的架构迭代方向

InfoQ：您怎么看湖仓一体未来的发展？在湖仓一体推广和大规模落地的道路上存在哪些机遇和挑战？

关涛： 湖仓一体的兴起本质上是由用户诉求推动的，大家希望得到更好的数据治理和管理能力，同时又希望有更好的灵活性，特别是随着 AI 的兴起，完全纯数仓的二维关系表已经无法承接半 / 非结构化数据的处理，AI 引擎不可能只跑在纯数仓模型上。所以湖仓一体一定是未来的发展趋势。做数仓的会有更多数据湖属性，做数据湖的也会有更多的数仓属性，最后根据实际需求去找到中间的平衡。

当然，挑战也不可避免。湖仓一体，相对单一的数据湖或者数据仓库场景，系统确实变得更复杂了。这其中就涉及到了刚才提过的湖仓之间数据重合的问题、一致性的问题，还有元数据系统是打通还是统一的问题。将原本的二元体系做成一体化，会对技术架构带来非常复杂的影响。此外，数据湖本身在访问时就存在比如存算分离导致的带宽问题等等，如果边上还有个数仓的话，这个问题还会加剧。

湖仓一体要大规模落地，对整个系统的设计维护要求非常高。所以，很多云厂商都在试图推出更偏托管化或者服务化的湖仓一体平台，以屏蔽底层不同系统之间的差异。如何能够既实现湖仓一体的能力，又让系统变得更简洁、更健壮，是未来大规模落地必然面临的挑战。

InfoQ：数据服务上云已经是不可逆转的趋势，但与此同时业内也开始出现一些关于云脱钩（上云后又撤出）的讨论，核心观点大致是“虽然上云在企业发展早期确实能实现资源优化，但这种优化效果却在业务规模扩大与增长的同时逐渐减弱，最终负担开始超过收益”，您怎么看待这类观点？云成本是企业在选用云平台数据服务时需要提前考虑的问题吗？

关涛： 目前业界确实有这么一个说法，不过我是一个比较彻底的上云党。为什么选择上云？我认为随着社会和科技的发展，技术分层会带来更高的效率，而集约化和规模化会带来更高的效益。

举一个简单的例子，构建一个 50 台机器的数据中心，和构建 5000 台机器、5 万台机器的数据中心相比，单台平均采购成本差异非常大。如果到了构建 5 万台机器的云平台这样一个规模，甚至在选址、水电开支和周边服务的生态等等都可以做更多的考虑。对于这种大规模集约化的采购，甚至还可以有更好的跟硬件厂商议价的能力，比如要定制化 CPU，量大到一定程度之后，芯片厂商就会为你服务。所以在集约化和技术分层化的影响下，最终云上的裸成本一定是更低的。

如果有一些用户觉得上云比线下自建 IDC 可能还贵了，这其实会涉及两个因素。第一，云上的服务器质量相对比较高，比如通常情况下服务器 3 年就会换一台，但对于线下 IDC，可能就会用 5 年或者更长时间。不同的机器使用寿命也带来了 SLA 的不同，如果只看账面价钱的话，可能感觉好像贵了，但如果把所有 SLA 考虑进去的话，上云其实不贵。

第二，大家更多时候只看了硬件本身的价钱，然后用来比较成本高或低，实际上构建一套云平台以及之上的云服务要投入非常多的人。以 100 台物理机这样一个规模的系统为例（或者 1000 台虚拟机折合 100 台物理机），我预估每年年化费用，连电费都算进来，一台机器大概是 3 万块钱，100 台机器大概的价钱就是 300 万一年。

但如果用户在线下自建 IDC 的话，除了硬件成本，从最底层开始部署运维是需要人力的，100 台物理机基本上需要 3~5 个人左右。就算这 5 个工程师不是特别贵，人力资源成本大概也要 300 万。所以 100 台物理机这样一个规模的资源，如果要线下自建的话，最终的 TCO（总体拥有成本）实际上远大于你看到的硬件设备的费用。

所以从这个层面上讲，我认为对于绝大多数企业而言，上云一定能带来云成本的下降，这些成本并不仅仅是硬件的成本，还包括服务的成本、人力资源、系统安全的成本，而且后面几部分成本是很高的。

InfoQ：您本次在 ArchSummit 深圳负责的专题将跟大家分享新一代数据平台的架构迭代方向，能否跟我们概要地解读一下主要有哪几个方向？为什么这些方向需要重点关注？

关涛： 大数据平台发展至今已经有 20 年历史了，目前架构侧已经有非常多领域开始进入到相对比较固定的成熟期，但仍然有几个趋势我觉得是值得关注的。

第一个趋势是 实时化以及近实时化架构的兴起。 最初整个大数据平台是以离线计算为基础的，后来随着流计算的兴起，形成了以流计算为轴的实时计算，再往后随着交互引擎的发展，比如 ClickHouse，实际上形成了由实时计算做最前面的数据处理、由交互分析引擎做非常快的前端 serving 这样一套架构，这是一个标准的实时化架构。

最近这一两年有两个开源的方向非常流行，一个是 Delta，一个是 Apache Hudi，它们分别来自 Spark 和 Hive 社区。从这两个角度看，大家可以理解成之前离线大数据处理的两个代表 Spark 和 Hive 已经同时开始向近实时化转型了。Delta 和 Hudi 能够大幅降低数据写入的延迟，使数据处理从离线开始转向近实时化。我们认为，在离线处理和实时化处理中间会形成一个近实时化的架构，这个架构的特点是比实时计算代价更低、但又比离线计算实时性更好，可以理解成是在成本和延时之间给用户找到的另外一个平衡点。

我认为以后大多数的离线计算都会向近实时转型，同时有很多现在必须要用实时计算的工作，大家可能想想会觉得也许不用付出那么多的成本，直接用这种近实时化架构就好了。

近实时架构相比实时架构的好处是，它在做数据写入，比如 upsert 处理，几乎都不太采用像 MemTable、LSM 这种更贵但也更实时的架构，而是仍然以文件的模式来做，只不过是以小批量的文件 merge。它的延迟可能在秒到分钟级，数据从写入到真实可见的可能在分钟级，最终到底延迟是什么样的程度，可能跟整个系统的实现的方式有关，但确实不是写入即可读的状态。但对于大多数应用而言，可能端到端 5 分钟的延迟也是可以接受的，如果成本足够低的话。

随着近实时架构的兴起，最终整个计算的频谱就会变成从纯离线到近实时架构再到实时化架构这样一个全频谱，差不多还需要一年左右的时间。

第二个趋势，去年这个时候，国家把数据也变成了生产资料，这样一来，很多有数据的组织，不管是企业还是政府机构，都在寻求怎么让数据发挥更大的价值，这就涉及到数据交换、数据共享以及背后对应的安全和隐私保护。我认为 数据安全、共享、隐私保护 会成为未来的热点。

一方面有数据可变现可交易的强诉求，同时也有安全合规的强要求，在这两个需求和要求中间，会诞生非常活跃的技术。如何更安全地共享数据，既包括一方的数据怎么做差分隐私加密，也包括多方的数据怎么在不共享的情况下通过 Feature 抽取等方式做联邦学习。实际上我们也能看得到非常多大型云厂商和中小型创业公司在这个领域有不错的投资。

第三个趋势是 IoT 数据的采集和处理。现在大数据的绝大多数数据增长都源于人的行为日志数据。最早数据库里存的数据，通常是交易数据，量小但非常贵，比如银行的交易数据、账单、账本等等。而过去这十几年，大数据的增长主要是由人的行为日志数据驱动的。大概 80% 的数据都来源于人的行为日志，只有 20% 可能来自交易数据。未来随着物联网和智能设备的兴起，设备上的数据会越来越多地接入进来，而设备上的数据规模可能在百亿千亿级别，那么如何更好地采集和处理这些 IoT 数据就会形成一个新的热点趋势。

IoT 数据对数据处理的要求相当于又向前走了一步。对于传统交易数据库，是少量但非常贵的数据，就可以用非常贵的手段和设备去处理它，后来的大数据是海量数据，数据的价值更低，于是诞生了像 MapReduce 这样的架构。而 IoT 设备产生的数据，它的数据量可能还会再大若干个数量级，数据价值很多时候就极低。比如大多数传感器数据在不出问题的情况下几乎是没有价值的。这就会催生出数据处理时不同的优化和平衡方式，以及从云到边端的基础架构的部署。比如有海量数据是在端设备上产生的，那设备上就要有一定的数据处理能力，先把一些无用的数据过滤掉，然后再把周期采样数据和异常数据送到云上做集中处理。

最后一个趋势是关于 AI for System 的。AI 作为一个工具，可以做非常多事情，其中一件事情就是优化大数据系统。随着数据的增长，维护数据表的工作量大幅增加。对于拥有大量数据的企业，内部数据工程师一个人维护上万张表很常见。但当一个人需要维护上万张表的时候，他几乎很难去理解每张表的细节状态，这种传统的以人为轴的数据开发和优化模式也即 DBA 模式已经几乎无法再持续下去了。

那如何让大数据系统能做到更好的自动调优、自优化呢？简要地说，怎么让大数据系统自动驾驶起来，这一定是未来的方向。这也可能会成为中台向后演进的一个核心方向，现在中台治理通常是提供工具和指标给到人，给到人建议，由人来做。但现在越来越多治理指标已经交由机器自动完成了，可以说初步实现了领域内大数据系统的自动驾驶能力。未来，我们认为大数据系统的自动驾驶能力会不断提升，可能从三级自动驾驶慢慢演进到五级。