Clickhouse「手撕」Snowflake太贵，我们与7位专家聊了聊

“感谢云数据仓库多年来的辛勤付出，但它们引领的霸权时代即将落幕。”

在近期的一篇博客中，Clickhouse 产品VP Tanya在文章开头便放出了这一大胆的观点。Tanya称，以Snowflake、Redshift、BigQuery为代表的云数仓已经不能完全满足客户需求，并且许多企业也已经发现云数据仓库成本不可持续。

此观点一发，也引起了业内人士诸多讨论。

有人认为，云数仓从来就没形成过霸权时代。而Tanya在文中所反复提到的实时数仓，也有从业者表示这并非新概念，早在十年前，实时数仓就已经被提过好几拨。

还有人认为，实时数仓虽是一个发展趋势，但并不能完全代替传统数仓，与此同时，市场对于实时数据分析需求有，但也没那么强......

基于上述的一些讨论，雷峰网独家对话了Clickhouse 产品VP Tanya，了解其写作该文章的由来以及观点。Tanya称，这篇文章她想表达的含义并非是说ClickHouse可以替代所有现有的数据仓库场景，而是希望对其进行演进。

同时，借由这一篇文章，雷峰网 (公众号：雷峰网) 也对话了业内多位专家：阿里云数据库事业部OLAP与工具高级产品专家薛菲、嬴图创始人孙宇熙、PingCAP副总裁刘松、酷克数据副总裁魏一、Airwallex技术专家董大凡、Aloudata CEO周卫林与他们分别聊了聊数仓的发展趋势、云数仓成本、数仓深层计算、生成式AI对数仓影响等几个备受关注的话题。

云数仓的霸权时代结束了？

实时数仓确实一个发展趋势，对话的几名受访者也基本同意这一观点。

PingCAP副总裁刘松过往职业经历与数仓息息相关。职业生涯前期他入职了Oracle，见证了以Teradata为代表的传统数仓的兴起。2014年他加入阿里云后，又见证了以Snowflake、BigQuery、Redshift为代表的云数仓快速冒头。在他看来，数仓的确在沿着从传统数仓，到云数仓，再到实时数仓的方向演进。

这种的演进背后，实际上是客户需求的变化。

阿里云数据库事业部OLAP与工具高级产品专家薛菲谈到了她接触过的一家头部游戏企业。他们一直致力于吸引更多的玩家，并确保玩家在其平台上获得更好的体验。然而，近年来，他们获取新客户成本开始提升，希望获得更实时的数据，了解客户档案、行为，以及客户做了哪些特定的点击，以便快速调整他们的策略。

除游戏玩家有需求外，嬴图创始人孙宇熙提到，他创业的这几年接触国内外不少的金融机构。他发现，随着市场环境变化，许多客户，尤其是金融类客户他们所需要的不仅是事后分析，用数据做决策，而是希望有实时分析。拿银行为例，客户在一边转账的同时，后台做实时风控分析的需求也越来越高涨。

“clickhouse提出要做新一代的实时数仓。基本上业界也同意这样的一个逻辑。”孙宇熙说道。

数仓在朝着实时方向发展，不过新一代的实时数仓仍不能完全代替以前的数仓。

Airwallex技术专家董大凡作为数仓产品的使用者，他表示：“即便企业使用了实时数仓，传统数仓也还是有一席之地。”

为何有一席之地？其一是实时数据分析可能带来更高的成本。Aloudata CEO周卫林在创业之前，在蚂蚁金服担任数据平台部门负责人，他表示，实时数据分析成本增加主要有两个原因：第一，数据越实时，数据采集和更新的频次会越高，数据预计算的比例会越低，因此对数据计算性能要求会越高，这会带来费用的增加；第二，通常需要实时数据的场景，数据分析的颗粒度会很细，分析的灵活性会越高，这样数据分析的数据量会很大，这会带来费用的增加。

对于一家企业来说，在追求数据时效的同时，成本也是不能回避的问题。假设一个公司花了100万，通过数据实时化能把风控引擎的精确度从50%提升到55%，然而这5%的提升所降低的损失低于投入成本，很显然企业投资意愿不会高涨。

因此，实时数仓通常的场景应用会比较明确，ROI 相对确定，对于不确定高的场景很难规模性使用实时数仓，原因是比不过传统数仓的ROI，尤其是 BI 分析场景上。

此外，当下并非所有场景都必须要实时数据分析。就比如双十一，交易额直接在屏幕上面毫秒级刷新固然很爽，但对于老板而言，他可能只要求第二天在办公室里面看报表，了解双十一交易额多少，几点是高峰，他的目的不是为了实时决策，而是为了长期规划和决策。

（接下来，雷峰网将推出《投资人，正逃离分析型数据库赛道》，欢迎加作者微信 mindy1857 交流。）

酷克数据副总裁魏一也表达了类似观点。魏一在加入酷克数据之前，曾就职于SAP，后来在EMC/Pivotal 从事Greenplum数据库技术研发工作，也是数仓领域的资深专家。在他看来，目前企业会存在实时数据分析需求，但除此之外，企业还有批处理的需求，虽然批处理数据时效性不及实时数仓，但是成本更低。

由于企业需求的多样化，也演化了数仓厂商们不同的产品研发策略。有一部分的厂商尝试在打造一个统一的数据服务平台，比如说snowflake、酷克数据、PingCAP。

“对于企业决策者而言，他们一定是需要一个统一的数据服务平台。”魏一说道。五年以前客户做大数据分析，可能的选择是：一个离线分析系统加上一个实时分析系统。比如离线分析选择Hadoop，再叠加一个ClickHouse、Greenplum实时分析的产品。这种做法的劣势是显著增加了运营成本，因为要进行数据搬迁ETL操作，同时客户还需要去管理不同的系统。相对地，统一融合的数据分析平台的优势则在于，解决了由ETL导致的数据传输延迟问题，进一步降低了数据分析的成本投入。

魏一表示，酷克数据的产品HashData云数仓目前已在某国有大型银行稳定运行多年，节点规模超过30000个。从落地运行情况来看，客户的数据冗余减少达到了30%以上，计算资源消耗也降低了30%。整个数据链路得以缩短，平均作业的完成时间加快了3个小时。

还有一部分厂商则不求做大而全的平台，只做部分需求的满足，比如BigQuery、RedShift他们现在并没有把实时数仓作为优先级，仍是服务于传统数仓的需求。而clickhouse则是更专注在新一代实时数仓上。

这两种产品策略没有孰好孰坏，对于客户来说，最终还是要结合自己的需求来进行技术、产品的选型。

数仓如何解决深层计算问题？

实时数仓所重点强调的是数据处理效率要快，那如果进一步追问该问题，当下的实时数仓到底能快到什么程度？孙宇熙认为，即便当下的数仓产品已经让数据分析速度有了极大突破，提升了10倍、或是100倍，但这或许并不意味着什么，市场可能需要到是快1万倍。

为什么这么说？孙宇熙举了银行的例子，不论是08年美国次贷危机、还是近期硅谷银行倒闭，其实背后本质问题都是因为金融机构的流动性受到冲击，所以流动性一直以来是金融机构关注的重点问题。08年金融危机之后，全球所有监管机构都在起草制定防止银行流动性变差的协议，而在其中，设置了一个重要的指标叫做流动性覆盖率（liquidity coverage vision，缩写LCR）LCR超过110%，你的流动性就达标了；如果低于110，但高于100%，那你属于很危险，因为很容易被击穿；如果低于100%，意味着你的流动性已经开始出现严重的问题。

在国内，监管机构给出的要求是，2000亿规模以上的中大型银行都要向监管机构每日汇报一次LCR。“然而，让人十分遗憾的是，我们最头部的大型国有商业银行当中，几乎没有哪一家能每天能把 LCR 这个指标计算一次。有的大型银行甚至只能一个月算一次。”

为什么银行做不到？孙宇熙认为一个原因是，要算LCR指标，需要全行所有的数据。把所有的对公客户、零售客户等等客户数据全汇总起来，很可能每日处理的数据量能达到百亿，这种数据规模是惊人的。另一个原因是，目前数仓计算需要大量的表做关联，“这种表结构最大的问题在于它是低维的，依然是在用行和列来表达这个数据，它天然就不善于去做数据之间的关联分析。”当用几十张表去做关联计算的时候，速度自然就会更慢。

在孙宇熙看来，未来数据分析效率会更快，除了表结构之外，数据仓库应该要支持其他数据计算模式，比如说图计算。图数据库的好处在于它能够执行某些类型的查询，不仅可能更快、更有效，而且在编写这些查询时语法更为紧凑。

嬴图曾在一家大型商业银行内部做过一个实验，这家银行原来的LCR计算大概要算4个小时，而用图计算在2秒钟内，即可完成，“这是一个七千倍以上的性能提升。”

实际上现在已经有许多数据仓库支持除表结构之外的其他数据分析，据薛菲表示，“全文搜索就是一个很好的例子。全文搜索不是结构化数据，它是一种半结构化数据。许多数据仓库已经支持诸如JSON或XML之类的类型，可以用来完成全文搜索的应用，比如阿里云的自研数据仓库AnalyticDB。”

此外，Clickhouse也有一个名为SQL Graph的项目。但Tanya也表示，目前他们的优先级放在了如何将向量搜索与传统分析结合使用上，而图计算这部分项目暂时尚未将其列为重点，其最重要的原因是目前图数据缺乏一个统一的标准。从开发者的角度来看，开发图查询是非常困难的。

不过，当下图计算或图数据库现在面临一个巨大的机会，薛菲表示，可以将其与LLM（Large Language Models）结合起来。“未来，LLM可能会成为处理图数据的新接口，因为用自然语言表达关系问题要比使用尚未发明的图标准更容易。”

LLM浪潮的崛起，也进一步推动了业务和应用对向量能力的需求。薛菲称，目前，阿里云瑶池数据库已全面拥抱向量检索能力，包括通义行业大模型在内的LLM就采用了企业级智能数仓AnalyticDB作为默认的向量检索引擎，性能较开源增强了2~5倍，与全文检索和结构化搜索联合进行多路召回，加速AIGC应用落地。

（接下来，雷峰网将推出《大模型会颠覆分析型数据库？》等文章，欢迎加作者微信 mindy1857 交流。）

云数仓到底贵不贵？

于客户而言，性能与成本都要考量。在成本端，近期关于云数仓到底贵不贵的话题也引发讨论。包括在 Tanya的文章中也重点提到了关于云数仓的成本问题，“与替代方案相比，云数据仓库的用户支付 3-5 倍的费用并不少见。”

在接受雷峰网采访时，她说道：“我们测试了Amazon Redshift，Google BigQuery和Snowflake三大数仓产品后发现，在资源消耗方面，这些数据仓库的表现较差，包括较少的数据压缩和运行查询所需的更多内存。”

雷峰网接触的一些公司中，的确也有公司反映他们在用云数仓之后，整体的数据分析成本变高了。刘松谈到了他们公司的案例。过去他们内部使用BigQuery，一年数仓成本大概是花10万美金。后来选用BigQuery之后，是原来的四倍。

云数仓为何会让人觉得贵，这与其定价模型有关。定价模型涉及各个方面，例如数据扫描量、计算结果和资源利用率。

Tanya称，他们曾对Google BigQuery进行了详细研究，Google BigQuery的定价模型，除非客户有承诺支出，否则实际上是按照扫描的数据量收费。但并非每个人都能做到承诺支出，同时特别对于初创公司在这方面确实很困难，因为他们的业务仍在探索中，很难有公司可以承诺一个特定的资源使用水平。而且承诺支出，也并不能完全弥补价格差距。

而云最大的优势是利用云的弹性和资源调用能力，假如新手开发者发出复杂查询语句——“全表扫描”，它能调动资源，给你不断地算，最后算出一个“天价”的计价单，你后悔也没用。而在传统数仓中，如果数仓做不出全表扫描的查询，它只会死机。

到底如何解决云数仓的成本问题？在过去的一年里，许多客户一直在向薛菲咨询这个问题。

在她看来，要解决成本问题可以从三个方面考虑：第一是，让产品完全实现Serverless（无服务器）架构。第二方面是存储，客户可以使用云存储，利用云上不同的存储类型，为那些不经常访问的数据降低成本。第三，即保持开放。这也是她认为最重要的一个方向。

“云数据仓库之所以昂贵，其中一个原因是它们通常不是开放的，例如，过去如果用户希望数据在数据仓库中，那么就不能从外部计算中心以外的地方创建数据，比如不能从Spark中提取数据。但是现在，我认为许多生态系统都在变得更加开放，即使数据仅存储在数据仓库中，用户仍然可以使用自己的Spark、Presto，以及自己的机器学习平台。在这种情况下，数据不再是冗余的。”

据阿里云向雷峰网透露，阿里云目前已与ClickHouse达成国内独家战略合作，作为ClickHouse在中国独家的云服务提供商，阿里云拥有全球最大的ClickHouse商用集群之一，可提供具备独有企业级能力的云原生ClickHouse企业版。企业版基于存算分离架构，可按量计费，比开源自建成本降低30%+。

在魏一看来，即使云数仓在公有云环境下可能比传统数仓更贵，但考虑到云数仓规模化带来的效率提升优势，从整体来看，云数仓肯定是要更节约成本的。

生成式AI会颠覆数仓？

除关心成本外，今年生成式AI的席卷而来，也让业内人士非常关心其对数据领域的影响，包括一个是数据库系统如何帮助人工智能(DB4AI)，另一个是人工智能如何帮助数据库系统(AI4DB)。

在Tanya看来，生成式AI在训练的过程中，有很多地方可以利用数据平台。首先是数据集筛选与分析，需要对用于训练大型语言模型的数据集进行筛选和分析，其中包括进行临时分析，以确定最适合用于训练的数据集。

一旦确定了训练所需的数据集，就需要构建数据管道，用于将这些数据集转换为模型训练所需的格式。这是一个涉及数据处理和转换的平台建设过程。

生成式AI模型一旦构建完成，需要与现有数据集进行整合。这可能涉及将模型产生的结果与现有数据集相结合，常见的方式是通过构建嵌入来实现，并将其存储在数据库中，然后进行向量搜索与数据分析。

“这是一个有趣的领域，在消费模型的过程中，你可能需要进行向量搜索以及其他数据分析。这可能需要在数据库中实现向量搜索功能，其中存在一个讨论点，即是选择专门的向量数据库还是将向量搜索功能集成到传统数据库中。”

最后，生成式AI应用程序，需要对训练和使用进行观察。你究竟如何观察这些情况？你应该收集哪些类型的事件？这也是一个大数据问题。

在Tanya看来，未来，训练、消费和应用可观察性这三个领域可能都要用到大数据平台。

薛菲表示，目前阿里云也在探索生成式AI与数仓的结合，其中探索的第一件事是LLM是否可以成为数据的单一或最通用的接口，以及自然语言是否可以成为未来的一切接口。

“也许在未来，SQL将会过时，或许SQL只对一小部分人来说还有关联性，大多数人与数据互动的门槛将被极大的降低，因为LLM使得人们不需要了解SQL或者其他的语言就可以试用数据。”

第二个方向是探索AI如何更好地帮助优化数据系统。

“比如它们如何只在需要的地方添加索引，基于AI规定如何优化整个系统。也许我们只需要一个单一的数据系统，只需关心数据源，而中间的一切都可以由机器完成。我们不需要进行手动ETL，不需要手动SQL优化。我们不需要担心所有中间的数据建模。所有这些都可以自动完成。”

这些畅想听起来确实令人兴奋，薛菲称，而自今年年初以来，已经有客户在询问她，如何将生成式AI融入他们的工作流程中。

他们看到客户将业务与AI相结合的过程大概分为三个不同的阶段：第一阶段是试水阶段，客户在这个阶段进行初步尝试，用企业知识库在内部进行验证，探索大模型的能力边界。第二阶段是构建可扩展且价格合理的AI增强应用的阶段。在这个阶段，客户仍然使用原始的企业数据，但通过引入LLM来增强其功能。第三阶段是一些客户开始探索构建AI原生应用程序，进入全新的应用领域。

“在试水阶段，阿里云的数据仓库AnalyticDB可以通过开放的生态以及解决方案模版提供快速的概念验证（POC），以便客户可以轻松地与LLM连接，进行简单的向量搜索，测试他们的想法。”薛菲说。

“在构建可扩展的AI增强应用阶段，正如Tanya提出的一个关键问题，向量能力是作为单独的数据库还是与现有的数据库结合？我的观点认为是后者会赢得市场。构建第二阶段的AI应用必须从现有数据应用中发展而来。因此，客户的核心需求并不是单纯的向量，而是向量搜索需要有机地与其他现有技术结合，如全文搜索和SQL。他们需要确保向量全文搜索和SQL能够完全交织在一起，以保证AI增强应用程序的顺利运行。”

薛菲表示，目前看到市场上有很多客户也纷纷进入这一阶段，尤其是许多在线零售商和从事在线旅行，支持聊天机器人等服务的公司。

而对于未来，可能还会有许多的公司会迈向AI原生应用程序的阶段。“在这一阶段，我们的数据存储需要更深度与大语言模型结合。”薛菲说道。目前阿里云发布了一系列新的能力，其中包括将LLM嵌入到阿里云的数据仓库中，或者构建一站式平台，使数据和LLM能够更紧密地交织在一起，使生态系统更加注重AI而不是数据，以便他们可以构建下一代完全AI-Native型的业务应用。

结语

站在2023年年末，回顾过去一年，不论是对数仓实时性、深层计算等技术问题的讨论，还是对数仓成本等商业化问题的讨论，这些众多议题都在激发着数据库领域的活力和生机。正如古人智者所言：“滚石不生苔”，在碰撞与交流的过程中，事物才能摆脱沉寂，焕发出源源不绝的活力，迎来真正的演变。

展望未来，薛菲提出了三个方向：数据仓库会更加Serverless化（无服务器）、实时湖仓融合以及数据与人工智能的深度融合。与此同时，Tanya强调了“开放”的理念，她坚信未来的创新将在广泛开放社区的土壤中蓬勃发生。

在大模型的引领下、在产业变革的潮头中，数据库将持续演进，而企业对其需求也将灵活变动。接下来，雷峰网也将持续推出《投资人，正逃离分析型数据库赛道》《分析型数据库公司相加，干不过一个李佳琪？》《大模型会颠覆分析型数据库？》等文章，欢迎加作者微信（mindy1857）交流。

雷峰网原创文章，未经授权禁止转载。详情见 转载须知 。