从Databricks和Snowflake之争，再谈湖仓一体化架构

结合最近的一些项目需求，以及最近几个月比较热闹的Databricks和Snowflake的纷争，再次说说自己对于湖仓一体化架构的理解和认识。

之前我写过一篇关于湖仓一体化的文章《从全域数据赋能的角度谈湖仓一体化》，说了一些基本概念，有兴趣的可以翻阅。

一、Databricks和Snowflake之争

2021年11月初，Databricks和Snowflake因TPC-DS测试结果正面开撕，掐得挺狠，双方创始人都亲自下场了，好久没看到这种名场面了。具体细节可以看这篇文章： https://www.infoq.cn/article/tFVjg1fwBhA9jMLygd2J?utm_source=rss&;utm_medium=article

Snowflake 是新生代的云上数仓的主导者之一，算是云数仓的主要推动者，目前已经实现了基于多公有云架构的云上数仓服务。Snowflake 是完全建立在云上的企业级数据仓库解决方案。Snowflake 是云原生的，因为它针对并基于云环境进行了根本性的重新设计，处理引擎和其他大部分组件都是从新开始开发的。Snowflake 通过提供高度分布式和可扩展的计算能力扰乱了数据仓库市场。

Databricks，是属于 Spark 的商业化公司，一直致力于提供基于 Spark 的云服务，打造了Delta Lake， 已将其能力大幅扩展至传统数据仓库的方向。Databricks正在打造Data Lakehouse，一种新颖的数据湖仓概念。

通过以上分析可以看出，Databricks 最初主要是一家数据湖公司，但一直在添加数仓功能。Snowflake 则是反过来的，作为一家数仓起家的公司，却一直忙于拥抱数据湖功能。

这说明什么？说明湖仓一体化已经成为不可逆的重要趋势，正如Databricks所说的那样：“从长远来看，所有数据仓库都将被纳入数据湖仓”。

二、湖仓一体化的主要特征

湖仓一体化，说起来简单，细究起来还是需要满足一些基本的条件：

• 通过低成本的方式实现全量数据单一存储；
• 提供高性能的数据引擎；
• 支持存算分离，满足架构的敏捷性需求，通过可插拔存储框架实现架构的可扩展性；
• 支持事务，保证事务的一致性；
• 支持数据治理，提供数据质量保证；

同时，还要支持多种的工作负载场景，比如批流一体，批处理、即席查询、数据分析(BI)、机器学习(ML)等，实现多样化工作负载。只有具备以上这些特性，才可以说是一套真正的湖仓一体

三、湖仓一体化的不同路径

通过上面的分析可以看出，从各家技术企业的原始积累出发，湖仓一体化也会有不同的路径，主要有两种方式：

• 在数据仓库上支持数据湖 ，一般是通过在数仓中建外部表来实现，谈论的是数据仓库如何更加灵活，以数仓为核心，支持访问数据湖。以Snowflake为代表的，还包括阿里云的MaxCompute、亚马逊的Redshift；
• 在数据湖中支持数仓能力 ，一般是通过功能性开发，比如多版本并发控制、自适应schema、提供文件级事务等等，来实现传统数仓的功能。以Databricks为代表。

体现在架构图上，第一种方式更像东西向架构，在数据仓旁边建立数据湖并实现湖仓的数据交互和联通；第二种方式更想南北向架构，需要在数据湖上构建数仓的服务层，强化数据治理和数据服务的提供。这两种方式没有优劣之分，适合自己才是最好的，需要根据自身的技术栈和数据需求进行选择和甄别。

无论那种方式，都有一些共性的问题需要解决，比如不同数据域数据打通的问题、元数据一致性的问题、不同数据引擎交叉引用的问题和数据开发工具缺乏的问题。

目前多数企业还没有选择湖仓一体化架构，多数采用的是传统数仓架构，有的是已经构建了初步的数据湖系统。对于数据湖来说，适合还没形成完善的数据价值体系体系，在趋势的感召下，开始尝试数据汇聚，把组织范围内的数据统一汇聚到数据湖中，实现数据集约管理的初衷。这类用户很快就会发觉数据治理和数据管理会是一个比较麻烦的问题，需要在数据湖上面构建一层数据治理和管理服务层。对于传统数仓用户来说，如果采用数仓系统支持湖仓一体化，直接挂接一个数据湖就可以启动了，后续就是关注两域数据的数据打通和元数据的一致性问题。

此外还有大量的使用了传统Hadoop体系的大数据平台用户，重点关注数据源的扩展和数据治理体系的完善，在认清全量数据的基础上，再考虑启动湖仓一体化的时机和关键节点。

湖仓一体要大规模落地，对整个系统的设计维护要求非常高，整体技术成本也比较高，是自建还是全托管，一定要想清楚。