建湖还是建仓？StarRocks：现在可以湖仓一体了

11月17日，StarRocks 年度大型技术交流峰会 StarRocks Summit 2023 在上海举行，来自平安银行、华润、腾讯游戏、阿里云、伊利、美的、京东等头部企业的大数据专家，均分享了自家在大数据分析领域的最新技术和最佳实践，吸引了数百名企业用户代表和开发者到场聆听交流。

这是 StarRocks 第三次举行年度技术交流峰会了。作为一款技术领先的开源 OLAP 数据库产品，StarRocks 一直备受大用户青睐，截至目前，已有超过300家市值10亿美金的企业使用 StarRocks，社区用户已突破1万。此次峰会，镜舟科技 CTO、StarRocks TSC member 张友东也跟大家分享了 StarRocks 的最新进展。

过去一年，StarRocks 先后发布了2.5、3.0、3.1三个重磅版本，其中 3.0 版本推出的存算分离架构为开源业界首创。升级到存算分离架构后，用户的存储成本能下降80%，而计算节点则因为无状态，可以通过快速弹性、跨可用区部署等方式来提高计算的可用性，并且计算资源能够进行物理隔离，按需独立弹性伸缩。

到 3.1 版本，开启 Local cache 的情况下，存算分离架构下的性能表现已接近本地存储的水平。

与此同时，现在 StarRocks 的湖仓分析能力已非常完备，不仅支持 internal、Data lake、JDBC、ES 等 catalog，还支持跨数据源的联帮分析。

另外，主键模型的能力在过去一年也得到持续提升，已经同时支持全内存和持久化的索引，并支持了 partial update、conditional update 的能力，在性能方面，针对批量更新的场景，引入了按列更新的模式，性能相比按行更新提升10倍以上。

张友东表示，未来数据演进的趋势是湖仓一体，用户无需关注是建湖还是建仓，不管是构建数据湖还是构建数据仓库，企业最终的目标是低成本、高效地解决数据分析问题。StarRocks 在具备存算分离、湖仓分析、物化视图等一系列重量级特性后，实现了往 Lakehouse 引擎的升级，借助 StarRocks 可兼具数据湖和数据库仓库的优势。

那么，StarRocks 具体又是如何实现的？接下来又将往什么方向发展呢？来看看张友东怎么说——

Q1：StarRocks 从3.0就引入了存算分离的架构，那么跟存算一体相比，它是怎么样保证性能不下降的？

张友东：存算分离的架构，它的性能相比本地数据访问要下降，这个在业界是达成共识的。因为它访问数据延迟变得更高了。 在业界，现在普遍的技术是通过 Cache 的手段去加速。不管是像 Snowflake，还是其他比较流行的数据仓库或者湖仓，都是通过 Cache 的方式去加速的。而 StarRocks 在这里其实也是通过本地 Cache 的方式。

因为现在绝大部分的业务场景下，数据都是有冷热之分的，比如说数据的挖掘，可能最近七天或者半个月的数据的价值，就比半年一年前的数据价值高。存算分离之后，数据通过这种对象存储、统一存储之后，成本变低，但访问变慢怎么办呢？我就把这些需要频繁访问的热数据，放在本地的 SSD，或者 NVMe 盘上存储起来，下次访问我就在本地访问。同时，往上还有内存，整体是一个多级 Cache 的一个机制。

Cache 因为只负责热数据的存储，所以它的整体成本也是相对可控的。可能我有三年的数据，但是我的热数据只有最近三个月的，存储上只有1/10是通过高性能的介质去存储，不会导致整个存储成本的上升，但是它又保证了这种热数据查询的性能。

Q2：目前湖仓一体化是业界发展的一大诉求，如果要实现湖仓一体，需要解决哪些技术难题，目前业界发展到哪一步、实施的服务器托管网效果怎么样？

张友东：如果要做数据分析，数据湖和数据仓库，肯定会二选一：要么构建一个数据仓库，要么构建一个数据湖，它们两者之间的优势劣势也比较明显。

目前的状况是，数据仓库因为发展了几十年，已经是一个广为接受的概念，在从原来的离线数仓到现在的实时数仓演进；数据湖，上一代经过 Hadoop 生态在国内的普及，现在很多企业都有 Hadoop 体系的建设，通过 Hadoop 去做数仓，然后从 Hive 再演进到 Iceberg、Hudi 的数据湖。这是当前的现状。

这两条路线现在开始融合，比如说数据原来在 Hive 里面统一管理，是一个大的湖，但是查询性能不够，可能就把里面的数据一部分导入到另外一个实时数仓——像 StarRocks 这样的产品里面去分析，这就带来数据要做 ETL 的复杂过程。或者有了数据湖的分析之后，同时也有了数据的分析之后，能够同时直接分析数据库的数据。 这两种在目前很多企业的实践里面，虽然逐步地融合，但再融合毕竟它还是两个东西。最终对于企业来说，它的维护复杂度还是很有挑战的。但往后演进，一定会往一体化的方向走，现在也是在这个路上，而且已经有一些头部的企业走在前面，做到了湖仓一体。

湖仓一体做到之后，它达到的效果就是数据统一存储、统一分析，整个数据技术栈管理更简单。

Q3：现在随着大模型的兴起，非结构化数据会有一个“爆炸式”增长，对底层的数据湖、湖仓一体等架构提出了怎样的挑战？和向量数据库有哪些可以结合的点？StarRocks 未来是否能够成为大数据、大模型的技术架构？

张友东：目前大模型，包括 AI 其实非常火热。StarRocks 整个湖仓，从当前来讲侧重于结构化数据和半结构化数据的处理。当前核心定位是面向 BI，在 AI 线路上是探索的状态，AI 因为涉及非结构化数据（训练的稳健数据），针对这些非结构化数据处理，StarRocks 有规划重点投入、提升在这方面的能力。

对于半结构和结构化数据，其实在 AI 应用也非常广。比如说，现在 AI 大模型的底层需要的向量检索类型能力，这方面 StarRocks 有开始一些探索。目前 StarRocks 社区跟腾讯在这方面有合作。现在整个 AI 与数据库的结合，我感觉不缺技术，但是缺落地的场景，因为腾讯有明确的场景，他们用 StarRocks 的体量非常大，业务数据就在这里，怎么样基于这组数据让业务变得更加智能，目前思路是在 StarRocks 内部拓展 AI。比如说向量检索的能力，可以基于现有数据去服务业务，而不是另起一套支持业务。如果顺利的话，可能在明年能够把这方面的能力贡献到 StarRocks 社区，到时候 StarRocks 在整个 AI、大模型体系可以做一些基础能力，但它肯定不是一个完整的 AI 解决方案。

Q4：做数仓，可能或多或少都要对标一下国外的 Snowflake，但是因为 Snowflake 天生是基于云端的云数仓。所以，我想问一下，国内云数仓的应用现状，还有未来的使用趋势是什么？

张友东：关于“云数仓”这一块，目前国内云厂商提供的，像阿里的 AnalyticDB、Holograss、腾讯的 TCF 的一些能力，应用挺广泛的。但是，目前国内的确是有很多场景的出仓构建是没法上云的，它需要在这种私有化的环境里面去维护。但是我觉得这并不阻碍云数仓的发展。

因为从云的角度，目前大家还是能够明显感觉到：不管是应用，还是数据库，还是各种组件，上云已经是一个趋势。数仓的上云，我觉得也是一个趋势，包括现在 StarRocks 去做存储分离的架构。当然你可以在私有化环境去使用，本地搭建这种 HDS 的集群，构建一套存储分离的体系。但是如果想把它的价值最大化，还是在云上去部署，借助像国内的 OSS、COS 这样的系统，才能发挥最大价值，达到成本最低、弹性最好的效果。

从技术的发展、架构的发展趋势，包括业务的趋势来讲，我认为往云的方向演进肯定是不变的。另外，像某些行业的限制，我觉得可能逐步也会发生一些变化。因为即使是在金融机构里面，数据也是分等级的，可能最核心的那一部分需要完全在私域。但是很多业务相关的数据，可以以私有云或者私有域的云形式进行管理。

Q5：从数仓厂商的角色，怎么去看待 HTAP 呢？因为前两年可能数据库公司提到的比较多，今年数仓公司也在往 HTAP 热点上去靠。所以，我们怎么看待 HTAP 的技术热点？

张友东：其实 TP 和 AP 的负载差异太大了。整体从技术上，像目前国内 TiDB 这样的系统，主打 HTAP，这些在中小场景，是能够做到一定的架构简化的。比如说，我的数据以 TP 的 workload 为主，同时有一些简单的报表查询分析，也不复杂，对整个系统的压力也不大，这种情况下，我觉得 HTAP 是可以去尝试的，而且应该也是能够胜任的。

但是对于比较复杂一点的分析场景，使用以 TP 为主的 HTAP 型的数据库，挑战还是非常大的。在一些实际的场景中，比如用户用 StarRocks 和一些 HTAP 的系统去对比，能明显感觉到在这种复杂分析场景下两者的性能差距。

我认为这里面核心的点是 TP 和 AP 本身面向业务的原则是不一样的。TP 是高并发求稳，AP 是求快，一个是尽量要维持这种稳定性，资源可能不能用太多；一个是 M服务器托管网PP 的架构，需要尽量地把资源用得快，这两样东西放到一块，稍微复杂一点的需求就难以调和。

Q6：今天也提到“湖仓一体”，我想问一下，对于现在这种 Zero-ETL 的趋势怎么看？

张友东：我觉得这个趋势还是挺明显的。不管是叫 Zero-ETL，还是叫 No ETL，总之就是减少 ETL 。我们认为在整个数据 Pipeline 构建里面，最复杂的部分可能就是 ETL，比去内部做查询分析的优化更重。

现在 StarRocks 整个“湖仓一体”的架构，其实也是在解决这个问题。湖仓一体的架构，它的核心是说你的数据统一存储，但统一存储不一定要求把数据通过 ETL 导入到 StarRocks 里面存储。如果你已经存好了，就不需要 ETL 了，就直接放到 Hive、Iceberg 这样的系统里面就好了，这样其实在减少 ETL 。

另外，在数据加工、或者加工之后加速的这个维度，我们通过物化视图的技术，让用户尽量感知不到 ETL 的过程。用户还是去做一些查询，构建一个物化视图，接下来调度、刷新的动作，StarRocks 就帮用户做了。也就是说，从整个全链路上，都是在帮用户简化 ETL 的 Pipeline 。

Q7：有没有跟隐私计算结合的这种想法？现在国外数仓跟隐私计算的结合比较火。因为由于法规的要求，国外可能有多个数仓，数据之间不方便流动。但是通过隐私计算的方式可以实现这种数据不动模型动的方式。

国内有没有这种趋势？通过“隐私计算+湖仓一体”的这种方式，实现数据分析或智能应用？这个可能对金融等行业来说，吸引力比较大。

张友东：这个问题很好。我们也一直在思考 StarRocks 往湖仓一体演进之后，后面的数据共享问题怎么解决。从目前接触的客户来讲，这个隐私计算大家会关注，但是真正去探索实践的还是比较少。主要是用隐私计算解决业务问题的需求，体感是非常小的。但是这个问题其实很重要，像 Databricks，它也是一个 Lakehouse，但是它在数据共享上也是通过这种统一的 Catalog，包括一些权限的管理，做到把私有数据分享给其他企业或组织使用，还能控制中间访问的不同规则力度。

所以第一，从趋势的角度，感觉现在国内真正往这个上面投入的不多，也有可能是真正做这一部分的企业，目前还没有考虑 StarRocks，或者只是我们没有感知到。

第二，从技术的角度，目前 StarRocks 的 Lakehouse 架构其实是能够满足未来组织之间这种数据共享的需求，它可以做到这种细腻度的数据访问的控制，让组织间、集群间能很好地共享数据。

Q8：介绍一下接下来的技术产品规划，下一步要研发的一些重点技术或者是大课题吧。

张友东：我们会围绕“云原生实时湖仓”的路径去继续增强 StarRocks 。

云原生很好理解，让 StarRocks 变得更加降本增效，弹性伸缩的这些特性在 StarRocks 更好地体现。

另外，我们会致力于解决用户对于实时分析链路的构建。比如说，一套链路要有一个 Flink 的计算，或者说配合Spark Streaming 的一系列技术做数据的抽取，然后导入到 StarRocks 做一些加工再分析。整个链路特别长，我们是希望把这个链路进一步简化，让实时的链路基于 StarRocks 构建起来更简单。

第三，湖仓统一之后，一定是用户大部分的功能、管理动作都在 StarRocks 内部完成。原来是做交互式的分析，做报表居多，后面可能越来越多的数据加工也会在 StarRocks 里面完成。所以 StarRocks 会围绕统一的 Lakehouse，去把支持 ETL 跑批的一些能力进行增强，真正做到分析诉求完全通过 StarRocks 一个组件完成。