證券研究報(bào)告·美股公司深度軟件與服務(wù)產(chǎn)品迭代顯著增強(qiáng)，渠道調(diào)整基本完畢，在預(yù)算波動(dòng)環(huán)境下預(yù)計(jì)保持韌性Snowflake(SNOW.N)核心觀點(diǎn)短期來看，美國宏觀經(jīng)濟(jì)前景不確定性較高，客戶在

IT

預(yù)

算展望方面可能保持靈活性，導(dǎo)致短期面臨下修風(fēng)險(xiǎn)。但

Snowfla

ke

過去

1

年成本優(yōu)化進(jìn)展順利，邊際壓力減輕&AI

敞口擴(kuò)大，成為客戶數(shù)字治理的首選平臺(tái)之一，因此新增

AI

預(yù)算受益確定

性較

高，預(yù)計(jì)韌性較強(qiáng)。產(chǎn)品迭代上近期

Snowpark

下載量相對(duì)

PySp

ar

k

大幅提升，反饋接受度在不斷追進(jìn)

Databricks

產(chǎn)品。渠道調(diào)

整上，24

年規(guī)模以上

SaaS

公司中

Databricks、Snowflake

銷售人

效提升幅度位列第一梯隊(duì)，后續(xù)招聘專注于能帶來收入的銷售&研

發(fā)崗位，預(yù)計(jì)人效延續(xù)平穩(wěn)趨勢(shì)。Snowflake

中長(zhǎng)期發(fā)展態(tài)勢(shì)較

1

年前有較大幅度改善。維持“買入”評(píng)級(jí)。發(fā)布日期：

2025

年

04

月

21

日當(dāng)前股價(jià)：

143.43

美元目標(biāo)價(jià)格

6

個(gè)月：

175.00

美元過去

1

年，Snowflake

在競(jìng)爭(zhēng)格局及行業(yè)

IT

預(yù)算壓力方面邊際改善，其中主要數(shù)據(jù)

競(jìng)爭(zhēng)格局上，Snowflake

擁抱

Iceberg+Polaris

Catalog

后沒有看到存儲(chǔ)收入的壓力，反而吸

引更多

客戶將

負(fù)載遷移至

Snowflake

執(zhí)行。成本優(yōu)化方面，Snowflake

2022

年8

月以來持續(xù)推動(dòng)

SQL

引擎優(yōu)化、自動(dòng)暫停長(zhǎng)時(shí)

間未活動(dòng)負(fù)載等，年化成本節(jié)約達(dá)

20%（2023/10-2024/10），高于同行此前的水平（Mid

to

High

single

digits），我們認(rèn)為大多數(shù)客戶在

IT

預(yù)算優(yōu)化方面實(shí)現(xiàn)絕大多數(shù)目

標(biāo)。后續(xù)的部分壓力主要來自

ETL

向外部遷移，如

采用云廠商或

Spark

生態(tài)的工具可以節(jié)約部分成本，但

邊際壓力有所趨緩。股票價(jià)格絕對(duì)/相對(duì)市場(chǎng)表現(xiàn)（%）1

個(gè)月3

個(gè)月12

個(gè)月-1.01/-35.00236.00/135.4833,420.0033,420.00514.20-13.53/-13.78-16.25/-28.2312

月最高/最低價(jià)（美元）總股本（萬股）流通股本（萬股）總市值（億美元）流通市值（億美元）近

3

月日均成交量（萬）主要股東514.20712.53

行業(yè)IT

預(yù)算方面，Snowflake

AI

敞口擴(kuò)大，客戶預(yù)算粘性增強(qiáng)。隨著

Snowflake

過去

1

年大幅提升產(chǎn)品

&工程迭代速度，AI

產(chǎn)品線日趨豐富，工程環(huán)節(jié)的

SnowparkContainer

Service、Iceberg

等已經(jīng)開始產(chǎn)生收入

，而

應(yīng)

用環(huán)節(jié)的

Native

App、Streamlit、Cortex

AI

尚未明顯貢獻(xiàn)收入，預(yù)計(jì)

CY2H25/26

可能開始貢獻(xiàn)一定體量

的收入（受益于

DeepSeek

降低成本）。The

Vanguard

Group5.40%股價(jià)表現(xiàn)72%52%32%12%-8%Snowflake納斯達(dá)克綜指相關(guān)研究報(bào)告Snowflake美股公司深度報(bào)告行業(yè)成長(zhǎng)邏輯，上云仍然是數(shù)倉核心驅(qū)動(dòng)力，2023

年上云率達(dá)

43.3%，相比于整體

50-60%的工作負(fù)載

上云率，仍有一定的提升空間。據(jù)

IDC，Snowflake

所屬的云關(guān)系型數(shù)據(jù)庫市場(chǎng)

2022-27

年復(fù)合增長(zhǎng)率預(yù)計(jì)達(dá)

20.6%，占數(shù)據(jù)管理領(lǐng)域的份額從

2022

年的

48.5%下降至

46.9%，略低于行業(yè)整體

21.4%的增速。邊際上，S

nowpark

的流行度正在快速追進(jìn)

Spark。2025

年

4

月

Snowpark

下載量大幅提升，4

月

1-11

日的下載量大約為

PySpark

65.0%。這里的下載量是邊際值，因此從存量的角度差距仍然較大，但邊際提升

趨勢(shì)

非常積極，對(duì)于年內(nèi)

Snowpark

商業(yè)化趨勢(shì)具有一定前瞻性。Snowpark

客戶基本上是客戶轉(zhuǎn)向

AI/M

L

的第一步

，后續(xù)是

Dynamics

Tables/Cortex

AI/Streamlit

等，其他

AI/M

L

產(chǎn)品主要處于產(chǎn)品打磨階段，商業(yè)化預(yù)計(jì)仍

需一

定時(shí)間。估值與建議：短期來看，美國宏觀經(jīng)濟(jì)前景不確定性較高，客戶在

IT

預(yù)算展望方面可能保持靈活性，導(dǎo)致短期面臨下修風(fēng)險(xiǎn)。但

Snowflake

過去

1

年成本優(yōu)化進(jìn)展順利，邊際壓力減輕&AI

敞口擴(kuò)大，成為客戶數(shù)字治理的首選平臺(tái)之一，因此新增

AI

預(yù)算受益確定性較高，預(yù)計(jì)韌性較強(qiáng)。產(chǎn)品迭代上近期

Snowpark

下載量相對(duì)

PySpark

大幅提升，反饋接受度在不斷追進(jìn)

Databricks

產(chǎn)品。渠道調(diào)整上，24

年規(guī)模以上

SaaS

公司中Databricks、Snowflake

銷售人效提升幅度位列第一梯隊(duì)，后續(xù)招聘專注于能帶來收入的銷售&研發(fā)崗位，預(yù)計(jì)人效延續(xù)平穩(wěn)趨勢(shì)。Snowflake

中長(zhǎng)期發(fā)展態(tài)勢(shì)較

1

年前有較大幅度改善。按照

FY26E，12

x

EV/Sales

給予估值，目標(biāo)價(jià)

175

美元/股，同行業(yè)可比公司均值為

9.0x，但考慮數(shù)倉在數(shù)據(jù)管理技術(shù)棧的核心地位，市場(chǎng)空間及增速較高，確定性較強(qiáng)，給予一定估值溢價(jià)。FY25

公司回購價(jià)格平均在

130.87

美元/股，但在

FY4Q25

沒有進(jìn)行任何回購，F(xiàn)Y4Q25

回購窗口期公司股價(jià)基本在

150-190

美元/區(qū)間。因此，我們認(rèn)為公司內(nèi)部考慮一定安全邊際后合理估值在

130

美元/股以上，當(dāng)前股價(jià)略高于內(nèi)部估值，這一位置具備一定短線支撐。維持“買入”評(píng)級(jí)。和聲明。Snowflake美股公司深度報(bào)告目錄1.

投資亮點(diǎn)：AI

應(yīng)用技術(shù)棧轉(zhuǎn)型，非結(jié)構(gòu)化數(shù)據(jù)管理需求提升

12.

數(shù)據(jù)管理架構(gòu)：從三層架構(gòu)轉(zhuǎn)向啞鈴形分布，中間層面臨持續(xù)壓力

3存算分離帶來效率提升，成本優(yōu)化空間較大

3統(tǒng)一的數(shù)據(jù)表格式、數(shù)據(jù)治理工具也進(jìn)一步標(biāo)準(zhǔn)化數(shù)據(jù)連接層

5從數(shù)據(jù)管理延伸至

MLOps，構(gòu)建

AI

應(yīng)用技術(shù)棧

9Snowflake

/

Databricks

在架構(gòu)遷移、成本優(yōu)化及

AI

應(yīng)用方面的進(jìn)展11成本優(yōu)化：過去

1

年穩(wěn)定負(fù)載成本節(jié)約

20%11AI

技術(shù)棧成熟度：MLOps

方面

Snowflake

加速追趕

Databricks，應(yīng)用組件領(lǐng)先

Databricks12運(yùn)營效率：人員規(guī)模基本與

Databricks

同步增長(zhǎng)，但在產(chǎn)品/工程方面仍然落后于

Databricks，過去

1

年銷售效率有所提升，領(lǐng)先同行16盈利預(yù)測(cè)19估值：目前交易于

FY26E

9.8x

EV/Rev，略高于同行業(yè)可比公司

20投資評(píng)價(jià)和建議

20風(fēng)險(xiǎn)分析21報(bào)表預(yù)測(cè)22圖目錄圖

1:傳統(tǒng)上數(shù)據(jù)管理的三層架構(gòu)3圖

2:Elastic

不同版本存儲(chǔ)成本與

Snowflake

存儲(chǔ)+傳輸成本對(duì)比（美元/TB/月）4圖

3:Polaris/Catalog

開源版本在數(shù)據(jù)爬取方面自動(dòng)化程度弱于

Databricks

托管的

Catalog7圖

4:Polar

is

僅支持

Iceberg

格式的連接器，而

Unity

Catalog

支持

Delta/Iceberg/Hudi7圖

5:Polar

is

在權(quán)限控制方面整體優(yōu)于

Unity

Catalog

8圖

6:Unity

Catalog/Polaris

在數(shù)據(jù)治理方面表現(xiàn)均較弱8圖

7:血緣追蹤方面，Databricks

托管的

Unity

Catalog

相對(duì)可用，開源版本的

Unity

Catalog/Polaris

幾乎不可用8圖

8:數(shù)據(jù)質(zhì)量管理方面，Unity

Cat

alog/Po

lar

is

處于類似水平，可用性不高8圖

9:數(shù)據(jù)目錄方面，Polar

is

成熟度不高，仍有待提升以改善用戶體驗(yàn)

9圖

10:Snowflake

過去

12

個(gè)月對(duì)優(yōu)化策略改進(jìn)下企業(yè)實(shí)際負(fù)載成本下降約

20%12圖

11:2023

年

8

月-2025

年

4

月

Snowpark/PySpark

下載量12圖

12:2025

年

4

月以來

Snowpark

份額大幅提升12圖

13:Polar

is

Catalog

Github

Stars

大約為

Unity

Catalog

的

50.8%15圖

14:Stack

Overflow

顯示

Streamlit

相較于

Tableau

的流行度更高15圖

15:Snowflake/Databricks

總員工數(shù)量基本同步增長(zhǎng)17圖

16:但

Databricks

工程師數(shù)量高于

Snowflake17圖

17:Snowflake

銷售團(tuán)隊(duì)規(guī)模高于

Databricks17圖

18:Databricks

AI/ML

團(tuán)隊(duì)規(guī)模幾乎是

Snowflake

的2x17圖

19:Databricks

從

Snowflake

挖角員工高于

Snowflake

反向招聘的規(guī)模17和聲明。oYkXoUaUcZmU9ZrQrQ7NaO7NoMpPmOmRfQnNmQkPoMnMaQoPxOMYnQnMxNrNmRSnowflake美股公司深度報(bào)告圖

20:Snowflake/Databricks

員工分布17圖

21:Snowflake

/

Databricks

過去

1

年銷售額增長(zhǎng)的拆分：1）銷售人員的增長(zhǎng)；2）銷售人效的提升

18表目錄表

1:Snowflake

發(fā)展態(tài)勢(shì)評(píng)估總結(jié)1表

2:2024

年

2

月

Elastic

與

Snowflake

存儲(chǔ)成本、傳輸對(duì)比（單位：美元/TB/月）4表

3:三層架構(gòu)與啞鈴架構(gòu)的優(yōu)劣勢(shì)對(duì)比5表

4:Iceberg

對(duì)于數(shù)據(jù)管理架構(gòu)整體成本的影響分析6表

5:Unity

Catalog

與

Polar

is

Catalog

產(chǎn)品功能對(duì)比

7表

6:在

MLOps

及

AI

應(yīng)用技術(shù)棧方面，Un

ity

Catalog

與

Polaris

的對(duì)比

10表

7:Snowflake

vs

Databricks

在

AI

應(yīng)用開發(fā)方面的對(duì)比11表

8:Snowflake

AI

應(yīng)用組件的成熟度及關(guān)鍵限瓶頸11表

9:Snowpark

下載量異動(dòng)時(shí)對(duì)應(yīng)的版本更新13表

10:Snowflake

AI/ML

相關(guān)產(chǎn)品的指標(biāo)14表

11:Snowflake

Streamlit

服務(wù)更新內(nèi)容

15表

12:FY22-26

Snowflake

盈利預(yù)測(cè)（百萬美元）

19表

13:可比公司估值（截止

2025/4/19）20和聲明。Snowflake美股公司深度報(bào)告1.

投資亮點(diǎn)：AI

應(yīng)用技術(shù)棧轉(zhuǎn)型，非結(jié)構(gòu)化數(shù)據(jù)管理需求提升過去

1

年，Snowflake

在競(jìng)爭(zhēng)格局及行業(yè)

IT

預(yù)算壓力方面邊際改善，其中

競(jìng)爭(zhēng)格局上，Snowflake

擁抱

Iceberg+Polaris

Catalog

后沒有看到存儲(chǔ)收入的壓力，反而吸引更多

客戶將負(fù)載遷移至

Snowflake

執(zhí)行。成本優(yōu)化方面，Snowflake

2022

年

8

月以來持續(xù)推動(dòng)

SQL

引擎優(yōu)

化、自動(dòng)暫停長(zhǎng)時(shí)間未活動(dòng)負(fù)載等，年化成本節(jié)約達(dá)

20%（2023/10-2024/10），高

于同行

此前的

水平（Midto

High

single

digits），我們認(rèn)為大多數(shù)客戶在

IT

預(yù)算優(yōu)化方面實(shí)現(xiàn)絕大多數(shù)目標(biāo)。后續(xù)的部分壓

力主要來自

ETL

向外部遷移，如采用云廠商或

Spark

生態(tài)的工具可以節(jié)約部分成本，但邊際壓力有所趨

緩。

行業(yè)IT

預(yù)算方面，Snowflake

AI

敞口擴(kuò)大，客戶預(yù)算粘性增強(qiáng)。隨著

Snowflake

過去

1

年大幅提

升產(chǎn)品&工程迭代速度，AI

產(chǎn)品線日趨豐富，工程環(huán)節(jié)的

Snowpark

Container

Service、Iceberg

等已經(jīng)開始產(chǎn)生收入，而應(yīng)用環(huán)節(jié)的

Native

App、Streamlit、Cortex

AI

尚未明顯貢獻(xiàn)收入，預(yù)計(jì)

CY2H25/

2

6

可能開始貢獻(xiàn)一定體量的收入（受益于

DeepSeek

降低成本）。行業(yè)成長(zhǎng)邏輯，上云仍然是數(shù)倉核心驅(qū)動(dòng)力，2023

年上云率達(dá)

43.3%，相比于整體

50-60%的工作負(fù)載

上云率，仍有一定的提升空間。據(jù)

IDC，Snowflake

所屬的云關(guān)系型數(shù)據(jù)庫市場(chǎng)

2022-27

年復(fù)合增長(zhǎng)率預(yù)計(jì)達(dá)

20.6%，占數(shù)據(jù)管理領(lǐng)域的份額從

2022

年的

48.5%下降至

46.9%，略低于行業(yè)整體

21.4%的增速。表

1:Snowflake

發(fā)展態(tài)勢(shì)評(píng)估總結(jié)存在的問題/積極趨勢(shì)具體內(nèi)容評(píng)估-

為實(shí)現(xiàn)易用性，Snowflake

將計(jì)算、存儲(chǔ)等資源分離，降低配置/部署門檻，但導(dǎo)致資源計(jì)費(fèi)的不透明。-

Databricks/Redshift

Serverless

模式提供更精細(xì)的資源控制，

-

Snowflake

2023

Summit

開始披露

Snowflake達(dá)到一定閾值后自動(dòng)停止運(yùn)行，Snowflake

需要手動(dòng)配置，

Performance

Index/周度更新，SPI

24/10

相比

22/81.1

成本優(yōu)化不透明，自動(dòng)化不足可能導(dǎo)致

IT

支出浪費(fèi)。性價(jià)比提升

40%，年化~20%的節(jié)約，進(jìn)展積極。-

為實(shí)現(xiàn)

IT

支出控制，客戶需要引入外部工具，導(dǎo)致額外運(yùn)維成本，與易用性初衷相悖。-銷售策略上鼓勵(lì)預(yù)購/承諾付費(fèi)，且年度預(yù)購積分未消耗后需要

100%續(xù)約以換取積分使用權(quán)，這導(dǎo)致客戶支出的浪費(fèi)。-這種合同設(shè)置意味著如果初始設(shè)定額度高于實(shí)際需求，將持續(xù)導(dǎo)致資源浪費(fèi)。1.2

銷售訴求與客戶訴求不一致，即成本優(yōu)化與承諾消費(fèi)的沖突。-

2022-23

年客戶集中優(yōu)化，大部分優(yōu)化目標(biāo)在20-30%，目前看基本優(yōu)化結(jié)束，負(fù)面影響基本消化完畢。2024

年銷售人效提升幅度高于同行。-如果持續(xù)聚焦成本優(yōu)化（如

AWS），低成本&閉環(huán)生態(tài)更容易令人接受，但高成本&閉環(huán)生態(tài)對(duì)于構(gòu)建長(zhǎng)期技術(shù)棧的客戶而言是一個(gè)較疑慮的選擇。-

Iceberg

并未帶來負(fù)面影響，Snowpark

客戶接受度高且

AI/ML

收入貢獻(xiàn)~3%1.3

生態(tài)不夠開放可從分析市場(chǎng)切入事務(wù)處理市場(chǎng)，強(qiáng)化核心數(shù)據(jù)處理供應(yīng)商的技術(shù)地位，但該產(chǎn)品仍處于早期預(yù)覽階段，有待進(jìn)一步評(píng)估。2.1

發(fā)布

Unistore

切入

-

2024

年

2月

Snowflake

宣布

Unistore

在部分

AWS

區(qū)域推事務(wù)處理市場(chǎng)出公開預(yù)覽版

，試圖統(tǒng)一數(shù)據(jù)治理。-

持續(xù)推動(dòng)數(shù)據(jù)共享，尤其是大型客戶具備較大規(guī)模的數(shù)據(jù)

-

截止

2023

年

4月，大型客戶

Data

Sharing

采集，在嚴(yán)格數(shù)據(jù)治理?xiàng)l件下，Snowflake

提供企業(yè)級(jí)交換平

用率

70%，總體平均值為

25%。數(shù)據(jù)飛輪效應(yīng)2.2

DataSharing

構(gòu)筑網(wǎng)絡(luò)效應(yīng)臺(tái)，嵌入企業(yè)核心業(yè)務(wù)工作流。確立意味著對(duì)大企業(yè)客戶的

BI分析預(yù)算粘性提和聲明。1Snowflake美股公司深度報(bào)告升。-

其局限性在于

1）可擴(kuò)展性低導(dǎo)致用例不足。目前難以支持

TB/PB

級(jí)的交互，使用場(chǎng)景限于小數(shù)據(jù)集、離線查詢或傳統(tǒng)數(shù)據(jù)庫的交換。2.3

Document

AICopilot

/

Snowpark

等3.1

IT

預(yù)算優(yōu)化/-

增強(qiáng)對(duì)非結(jié)構(gòu)化數(shù)據(jù)的處理能力，并降低交互門檻，可通

AI/ML

CY3Q24

產(chǎn)生~5.6%收入，后續(xù)有望進(jìn)一過

Python/Java/Scala

等語言進(jìn)行操作。步拉動(dòng)增速。-

IT

預(yù)算優(yōu)化仍未結(jié)束，管理層對(duì)

FY24展望謹(jǐn)慎優(yōu)化周期基本見底，2-3Q24

無進(jìn)一步惡化趨勢(shì)。3.2

數(shù)據(jù)安全/合規(guī)治

-

歐盟

AI

法案落地，美國

AI

相關(guān)監(jiān)管法案也在起草，行業(yè)Azure/AWS

等優(yōu)勢(shì)明顯。理嚴(yán)監(jiān)管趨勢(shì)明顯，對(duì)于數(shù)據(jù)管理供應(yīng)商的合規(guī)要求提升。資料：Snowflake

官網(wǎng)，Microsoft

官網(wǎng)，AWS

官網(wǎng)，PyPI，EU

Commision，中信建投邊際上，S

nowpark

的流行度正在快速追進(jìn)

Spark。2025

年

4

月

Snowpark

下載量大幅提升，4

月

1-11

日的下載量大約為

PySpark

65.0%。這里的下載量是邊際值，因此從存量的角度差距仍然較大，但邊際提升

趨勢(shì)

非常積極，對(duì)于年內(nèi)

Snowpark

商業(yè)化趨勢(shì)具有一定前瞻性。Snowpark

客戶基本上是客戶轉(zhuǎn)向

AI/M

L

的第一步

，后續(xù)是

Dynamics

Tables/Cortex

AI/Streamlit

等，其他

AI/M

L

產(chǎn)品主要處于產(chǎn)品打磨階段，商業(yè)化預(yù)計(jì)仍

需一

定時(shí)間。估值與建議：1）AI

方面，Snowflake

利用

AI

增強(qiáng)處理非結(jié)構(gòu)化數(shù)據(jù)能力，并將下游場(chǎng)景從

BI

拓展至AI/ML

等，后續(xù)關(guān)注

MLOps

等環(huán)節(jié)的變化；2）數(shù)倉性能方面，Redshift/Databricks

在較大計(jì)算資源投入下具有較好的性能/成本優(yōu)勢(shì)，而

Snowflake/BigQuery

在中小型計(jì)算資源下具備較好的性能/成本優(yōu)勢(shì)。但據(jù)BigQuery

工程師，99%的數(shù)倉查詢都小于

10GB，絕大多數(shù)企業(yè)的數(shù)據(jù)倉庫都小于

1T

B，因此聚焦大規(guī)模查詢場(chǎng)景的優(yōu)化本質(zhì)是面向

1%的頭部客戶，而忽略剩余

99%需求，在數(shù)倉領(lǐng)域

Snowflake

仍然具備較強(qiáng)的性能和成本表現(xiàn)；3）大數(shù)據(jù)平臺(tái)方面，Databricks

長(zhǎng)期致力于構(gòu)建開放、高性能的

Spark

生態(tài)，在開放性和工具/服務(wù)全面性上領(lǐng)先

Snowflake，Snowflake

通過

Snowpark

/

Unistore

等增強(qiáng)對(duì)非結(jié)構(gòu)化數(shù)據(jù)的處理能力，但總體仍然落后于

Databricks。維持“買入”評(píng)級(jí)。風(fēng)險(xiǎn)提示：①市場(chǎng)競(jìng)爭(zhēng)風(fēng)險(xiǎn)-云數(shù)據(jù)倉庫市場(chǎng)競(jìng)爭(zhēng)激烈，競(jìng)爭(zhēng)可能導(dǎo)致價(jià)格競(jìng)爭(zhēng)、市場(chǎng)份額下降和利潤(rùn)

率壓力。②依賴于云服務(wù)提供商-Snowflake

構(gòu)建在云平臺(tái)之上，例如AWS、Azure、GCP

等。它依賴于這

些云

服務(wù)提供商的基礎(chǔ)設(shè)施和服務(wù)，任何與云服務(wù)提供商之間的合作關(guān)系變化、競(jìng)爭(zhēng)、定價(jià)調(diào)整或服務(wù)中斷

都

可

能對(duì)Snowflake

的業(yè)務(wù)和財(cái)務(wù)狀況產(chǎn)生不利影響。③法律和合規(guī)風(fēng)險(xiǎn)：Snowflake

在全球范圍內(nèi)經(jīng)營，因此

需要

應(yīng)對(duì)各個(gè)國家和地區(qū)的法律、監(jiān)管和合規(guī)要求。④安全和數(shù)據(jù)隱私：任何數(shù)據(jù)泄露、安全漏洞或違反數(shù)據(jù)

隱私

的事件都可能對(duì)

Snowflake

的聲譽(yù)和客戶信任產(chǎn)生負(fù)面影響。⑤技術(shù)風(fēng)險(xiǎn)：Snowflake

的成功依賴于其技術(shù)

平臺(tái)

和解決方案的穩(wěn)定性、可靠性和創(chuàng)新性。然而，技術(shù)創(chuàng)新和發(fā)展也可能帶來技術(shù)風(fēng)險(xiǎn)，如軟件缺陷、系統(tǒng)

故障

、數(shù)據(jù)一致性和性能問題等。和聲明。2Snowflake美股公司深度報(bào)告2.

數(shù)據(jù)管理架構(gòu)：從三層架構(gòu)轉(zhuǎn)向啞鈴形分布，中間層面臨持續(xù)壓力數(shù)據(jù)管理從三層架構(gòu)轉(zhuǎn)向啞鈴形（強(qiáng)化兩端，弱化中間）。傳統(tǒng)上，數(shù)據(jù)湖采用銅、銀、金三層結(jié)構(gòu)，其中銅層主要存儲(chǔ)未經(jīng)處理或僅輕度處理的數(shù)據(jù)，銀層將數(shù)據(jù)直接轉(zhuǎn)換為高度優(yōu)化的分析形態(tài)，金層則是所有消費(fèi)發(fā)生的地方，例如下游的

BI/M

L

場(chǎng)景。這一架構(gòu)存在的問題包括

1）數(shù)據(jù)處理延遲：傳統(tǒng)架構(gòu)需經(jīng)過原始數(shù)據(jù)到中間層（銀層）再到消費(fèi)層（金層）的多級(jí)轉(zhuǎn)換，導(dǎo)致數(shù)據(jù)可用性時(shí)間較長(zhǎng)；2）復(fù)雜性高：需維護(hù)復(fù)雜的中間層邏輯，涉及定制化處理和非通用數(shù)據(jù)模型，增加開發(fā)與維護(hù)成本；3）靈活性不足：未能同時(shí)滿足交互式工作負(fù)載（如儀表盤）與非交互式工作負(fù)載（如批處理分析）的需求。圖

1:傳統(tǒng)上數(shù)據(jù)管理的三層架構(gòu)數(shù)據(jù)：《What

goes

into

bronze,silver,

and

goldlayers

of

amedallion

data

architecture?》1,中信建投針對(duì)這些問題的改進(jìn)包括①分段優(yōu)化（啞鈴架構(gòu)），具體來講

1）跳過中間層：直接從原始數(shù)據(jù)區(qū)轉(zhuǎn)換到優(yōu)化分析存儲(chǔ)，縮短數(shù)據(jù)到洞察的時(shí)間；2）按需定制：針對(duì)特定工作負(fù)載（如威脅建模、實(shí)時(shí)分析）創(chuàng)建定制化語義分析數(shù)據(jù)模型，提升效率2；3）成本優(yōu)化：降低冗余存儲(chǔ)需求，結(jié)合廉價(jià)云存儲(chǔ)（如

De

lta

Lake）節(jié)省原始存儲(chǔ)層成本。②湖倉一體架構(gòu)，涵蓋

1）支持多模態(tài)數(shù)據(jù)：通過

Delta

Lake

等開放格式，統(tǒng)一管理結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)，減少數(shù)據(jù)孤島；2）實(shí)時(shí)處理能力：通過流式處理（如

Kafka

+

Iceberg）直接導(dǎo)入數(shù)據(jù)湖，支持

AI/ML

場(chǎng)景（如自動(dòng)駕駛開發(fā)）。存算分離帶來效率提升，成本優(yōu)化空間較大這一趨勢(shì)背后仍然是存算分離帶來的效率提升。以可觀測(cè)性產(chǎn)品為例，如

Datadog/Elastic

往往主要采取存算一體架構(gòu)，即數(shù)據(jù)存儲(chǔ)和處理都在同一個(gè)節(jié)點(diǎn)上進(jìn)行，但存算分離則強(qiáng)化架構(gòu)的可擴(kuò)展性，增強(qiáng)資源

利用

率，是經(jīng)濟(jì)效益驅(qū)動(dòng)的選擇。這種趨勢(shì)下，底層的存儲(chǔ)架構(gòu)尤為重要，一些客戶引入

Doris/Snowflake

等提供

存儲(chǔ)

，基于外部存儲(chǔ)方案進(jìn)行可觀測(cè)分析，這對(duì)應(yīng)整體成本的大幅下降。Elastic/Datadog

等廠商目前在存算分離方面也有布局，但主要集中于開源方案和一站式方案。Elastic

提供ES-Hadoop/Elastic

與

Snowflake

等集成/Elastic

Cloud，分別對(duì)應(yīng)完全自建/外部集成/一體化解決方案，其中

ES

-1

/what-goes-into-bronze-silver-and-gold-layers-of-a-medallion-data-architecture-4b6fdfb405fc2

相應(yīng)地，把通用負(fù)載卸載至存儲(chǔ)層，并結(jié)合流傳輸?shù)戎苯觽魉椭两K端消費(fèi)環(huán)節(jié)，縮減中間層的運(yùn)維/優(yōu)化成本。和聲明。3Snowflake美股公司深度報(bào)告Hadoop

需要客戶自行構(gòu)建和維護(hù)

Hadoop

集群和

Elasticsearch

集群，Elastic

Cloud

則完全由

Elastic

構(gòu)建和維護(hù)基

礎(chǔ)

設(shè)

施

，

Elastic

與

Snowflake

集

成

則

介

于

兩

者

之

間

。

Datadog

也

有

類

似

的

方

案

，

包

括

Datadog

LogManagement/Archive

to

S3，即

Datadog

提供一站式解決方案或與

AWS

的

S3

存儲(chǔ)集成。對(duì)比

S

nowflak

e

+

Elasticsearch

方案與

Elas

tic

Cloud

方案的成本：定性來看，Snowflake

在存儲(chǔ)成本上

低于Elastic

Cloud，主要由于列式存儲(chǔ)架構(gòu)的性能優(yōu)勢(shì)，但這會(huì)帶來額外的網(wǎng)絡(luò)傳輸成本，即將

Snowflake

的數(shù)

據(jù)傳輸至

Elastic

集群，這可能涉及數(shù)據(jù)跨云/跨地區(qū)遷移。定量來看，2024

年初

Snowflake

在美國北弗吉尼亞

州/歐洲地區(qū)的存儲(chǔ)成本約為$40、$45/TB/月3，而

Elastic

Enterprise

版北弗吉尼亞州冷存儲(chǔ)價(jià)格為$217/TB/月，愛爾

蘭（歐洲區(qū)數(shù)據(jù)中心）冷存儲(chǔ)價(jià)格為$265/TB/月4。根據(jù)測(cè)算，Snowflake

存儲(chǔ)+傳輸后平均比

Elastic

存儲(chǔ)成本

低55%，如果考慮均存儲(chǔ)于

AWS，僅在不同地區(qū)傳輸則成本平均低

64%。因

此，Elastic

等可觀測(cè)性廠商

在存

算分離領(lǐng)域的布局尚不完善。但需要注意，將數(shù)據(jù)分布式存儲(chǔ)可能帶來響應(yīng)時(shí)長(zhǎng)提升，盡管運(yùn)維分析并不

需要

毫秒級(jí)別的響應(yīng)，但也是需要分鐘級(jí)的響應(yīng)，大量數(shù)據(jù)的分布式存儲(chǔ)可能會(huì)對(duì)響應(yīng)速度構(gòu)成挑戰(zhàn)，因此客

戶并

非完全根據(jù)成本進(jìn)行部署決策，而是首要考慮可靠性和穩(wěn)定性，其次才是成本。表

2:2024年

2月

Elastic

與

Snowflake

存儲(chǔ)成本、傳輸對(duì)比（單位：美元/TB/月）ElasticSnowflakeSnowflake

傳輸成本-愛爾蘭Snowflake

傳輸成本-北弗吉尼亞不

同

地

不

同

地不

同

地

不

同

地同地區(qū)/同同地區(qū)/同EUNAEUNA區(qū)/同區(qū)

/不

同CSP90區(qū)/同區(qū)

/不

同CSP90CSPCSPCSP20CSP20Enterprise

265217160135119454545454040404000000000PlatinumGold1951651462090209020902090Standard資料20902090：Elastic，Snowflake，中信建投圖

2:Elastic

不同版本存儲(chǔ)成本與

Snowflake

存儲(chǔ)+傳輸成本對(duì)比（美元/TB/月）Elastic

EnterpriseElastic

PlatinumElastic

GoldElastic

StandardSnowflake存儲(chǔ)+傳輸3002502001501005030%75%62%18%66%77%0EU-同地區(qū)/同

EU-不同地區(qū)/同

EU-不同地區(qū)/不CSP

CSP

同CSPNA-同地區(qū)/同NA-不同地區(qū)/同

NA-不同地區(qū)/不CSP

同CSPCSP數(shù)據(jù)：Elastic，Snowflake，中信建投3

https://www.chaosgenius.io/blog/ultimate-snowflake-cost-optimization-guide-reduce-snowflake-costs-pay-as-you-go-pricing-in-snowflake/4

均選取

AWS

為對(duì)照，根據(jù)

Elastic

官網(wǎng)定價(jià)計(jì)算器(https://cloud.elastic.co/pricing)，Platinum版北弗吉尼亞州/愛爾蘭的冷存儲(chǔ)價(jià)格分別為$160/TB/月、$195/TB/月；Gold版北弗吉尼亞州/愛爾蘭的冷存儲(chǔ)價(jià)格分別為$135/TB/月、$165/TB/月；St

an

dard

版北弗吉尼亞州/愛爾蘭的冷存儲(chǔ)價(jià)格分別為$119/TB/月、$146/TB/月。和聲明。4Snowflake美股公司深度報(bào)告表

3:三層架構(gòu)與啞鈴架構(gòu)的優(yōu)劣勢(shì)對(duì)比響應(yīng)速度成本高延遲（逐層處理）低延遲（直接生成分析模型）高（維護(hù)中間層存儲(chǔ)與計(jì)算）通用模型難以適配垂直場(chǎng)景中等（標(biāo)準(zhǔn)化流程）低（跳過中間層，按需計(jì)算）定制模型精準(zhǔn)匹配業(yè)務(wù)需求靈活性維護(hù)復(fù)雜度適用場(chǎng)景響應(yīng)速度較高（多模型管理與工具集成）高時(shí)效性、垂直場(chǎng)景（如故障排查）低延遲（直接生成分析模型）需長(zhǎng)期穩(wěn)定分析的通用場(chǎng)景高延遲（逐層處理）資料：Snowflake，《What

goes

into

bronze,

silver,

and

gold

layers

of

amedallion

data

architecture?》，《計(jì)算存儲(chǔ)和元數(shù)據(jù)三層分離架構(gòu)下元數(shù)據(jù)和事務(wù)系統(tǒng)的挑戰(zhàn)和關(guān)鍵技術(shù)》，中信建投總結(jié)來看，盡管啞鈴架構(gòu)下增加了對(duì)于按需定制分析模型的需求，帶來額外的開發(fā)及運(yùn)維復(fù)雜度，導(dǎo)致①模型碎片化：每個(gè)定制化分析模型僅適配特定業(yè)務(wù)需求（如

Atlassian

的故障定位、供應(yīng)鏈預(yù)測(cè)等），

導(dǎo)致

大量獨(dú)立模型并存，需單獨(dú)維護(hù)；②技術(shù)依賴增強(qiáng)：需集成多源數(shù)據(jù)（如

Splun

k

日志、SignalFx

指標(biāo)與自

有應(yīng)

用數(shù)據(jù)），依賴

Dremio、Starburst

等工具直接連接原始數(shù)據(jù)和優(yōu)化端，增加了技術(shù)棧復(fù)雜度；③頻繁調(diào)整

需求

：模型需隨數(shù)據(jù)特征變化迭代（如自動(dòng)駕駛車輛傳感器數(shù)據(jù)時(shí)效性要求），維護(hù)團(tuán)隊(duì)需持續(xù)監(jiān)控與更新。但出

于

對(duì)實(shí)時(shí)性要求的提升，企業(yè)仍然傾向于將部分?jǐn)?shù)據(jù)切換至啞鈴架構(gòu)以應(yīng)對(duì)業(yè)務(wù)需求，典型用例包括①超大規(guī)模數(shù)據(jù)（如

PB

級(jí)車聯(lián)網(wǎng)日志）下，模型需實(shí)時(shí)響應(yīng)以支持高

SLA

的場(chǎng)景（如降級(jí)定位、自動(dòng)駕駛決策）

；②

醫(yī)療公司的實(shí)時(shí)患者數(shù)據(jù)分析，使用

Kafka

+

Iceberg

實(shí)時(shí)攝取心電圖數(shù)據(jù)，直接寫入

Databricks

分析層，

將數(shù)

據(jù)生成到預(yù)警縮短至秒級(jí)，傳統(tǒng)架構(gòu)延遲則在分鐘級(jí)。新架構(gòu)相應(yīng)也帶來一些問題，例如啞鈴架構(gòu)的維護(hù)負(fù)擔(dān)可能隨著數(shù)據(jù)規(guī)模增長(zhǎng)而加劇，但企業(yè)可以選

擇利用第三方工具優(yōu)化和統(tǒng)一管理定制化負(fù)載，例如通過工具鏈標(biāo)準(zhǔn)化（如

Iceberg

統(tǒng)一數(shù)據(jù)格式）和自

動(dòng)化

（如Airflow

調(diào)度模型訓(xùn)練）緩解重復(fù)開發(fā)問題。按需定制的啞鈴式架構(gòu)本質(zhì)是企業(yè)在速度、成本、靈活性與復(fù)雜性、資源消耗間的戰(zhàn)略性取舍。其核

心邏輯是：犧牲部分可維護(hù)性以換取業(yè)務(wù)敏捷性。隨著數(shù)據(jù)規(guī)模擴(kuò)大，開發(fā)負(fù)擔(dān)可能上升，但通過優(yōu)化工

具鏈

和采用分層管理策略（如保留原始數(shù)據(jù)+部分中間緩存），企業(yè)可部分對(duì)沖負(fù)面影響。這一趨勢(shì)反映了數(shù)據(jù)

驅(qū)動(dòng)

時(shí)代對(duì)實(shí)時(shí)性與垂直場(chǎng)景深耕的迫切需求。統(tǒng)一的數(shù)據(jù)表格式、數(shù)據(jù)治理工具也進(jìn)一步標(biāo)準(zhǔn)化數(shù)據(jù)連接層S

nowflak

e

于

2Q24

加速支持

Iceberg

開放表格式。Snowflake

在

2023

年

7

月即開始通過

Iceberg

Tables

更新

支持?jǐn)?shù)據(jù)湖工作負(fù)載，但當(dāng)時(shí)主要面向早期用戶。2024

年

6

月后，隨著

Polaris

Catalog

的開源和功能完善，其支持范圍顯著擴(kuò)大。Snowflake

于

2024

年

6

月

3

日正式發(fā)布

Polaris

Catalog，這是一個(gè)支持跨引擎訪問

Iceberg數(shù)據(jù)的開源工具，標(biāo)志著其對(duì)

Iceberg

技術(shù)的深度整合。截至

2025

年

3

月，Snowflake

已有約

500

個(gè)企

業(yè)賬

戶采用Iceberg

格式，表明其支持已進(jìn)入規(guī)模化應(yīng)用階段。Iceberg

支持

ACID

事務(wù)同時(shí)降低鎖定風(fēng)險(xiǎn)，但相應(yīng)犧牲專有引擎的性能優(yōu)勢(shì)。Iceberg

支持

ACID

事務(wù)、模式演變（Schema

Evolution）及時(shí)間旅行（Time

Travel），解決了傳統(tǒng)數(shù)據(jù)湖中原子性更新和一致性難題

。另外，Iceberg

采用

Parquet

文件存儲(chǔ)數(shù)據(jù)，優(yōu)化列式讀取性能，并通過元數(shù)據(jù)抽象層（Tab

le

Metadata）實(shí)現(xiàn)數(shù)據(jù)分區(qū)和文件粒度的索引管理。Iceberg

成為事實(shí)標(biāo)準(zhǔn)后（如

HTLF

選擇

Polaris

與

Iceberg

結(jié)合），用戶

可脫

離專有存儲(chǔ)（如

Delta

Lake），降低遷移鎖定的風(fēng)險(xiǎn)。相應(yīng)地，采用通用格式后

Snowflake/Databricks

過去針對(duì)和聲明。5Snowflake美股公司深度報(bào)告SQL/Photon

引擎的優(yōu)化則影響降低，客戶面臨犧牲性能換取開放性的權(quán)衡。據(jù)騰訊

2023

年的分享5，Iceberg

依賴對(duì)象存儲(chǔ)（如

S3），在一些用例上存算分離導(dǎo)致本地計(jì)算性能損失約

30%，需更多計(jì)算資源彌補(bǔ)延遲。而

AW

S則分享6，對(duì)于實(shí)時(shí)攝入的場(chǎng)景，由于

Iceberg

元數(shù)據(jù)和版本管理的機(jī)制，會(huì)導(dǎo)致比較多的小文件，過多

的小

文件會(huì)導(dǎo)致查詢變慢，也會(huì)帶來更多的

S3

請(qǐng)求數(shù)量，導(dǎo)致成本的增加，因此需要定時(shí)對(duì)

Iceberg

表已經(jīng)維護(hù)。Databricks

針對(duì)

Parquet

文件有針對(duì)性優(yōu)化。Databricks

的

Delta

Lake

通過優(yōu)化

Parquet

文件（如

Z-Ordering）提升查詢效率，但傳統(tǒng)上依賴自身生態(tài)，Iceberg

普及后逐步開放兼容（如收購

Tabular）。數(shù)據(jù)格式通用性也意味著

ETL

的需求相應(yīng)降低，節(jié)約成本。傳統(tǒng)

ETL

需在數(shù)據(jù)寫入后進(jìn)行修正，而

Iceberg通過

ACID

事務(wù)直接保障數(shù)據(jù)一致性，減少額外

ETL

步驟7。在預(yù)處理方面，Iceberg

的元數(shù)據(jù)版本控制

允許

直接查詢?cè)紨?shù)據(jù)，無需預(yù)先轉(zhuǎn)換。例

如，業(yè)務(wù)

可直接

分析

Iceberg

原始表，省去

ET

L

中數(shù)據(jù)標(biāo)準(zhǔn)化的中

間步

驟。元數(shù)據(jù)還支持快速分區(qū)過濾，避免全表掃描，降低

ETL

對(duì)數(shù)據(jù)預(yù)處理的需求。在跨系統(tǒng)查詢/修

改時(shí)，Iceberg

作為開放表格式，支持多引擎（如

Trino、Spark）直接讀寫，避免傳統(tǒng)

ETL

中數(shù)據(jù)在不同系統(tǒng)間遷移的

開銷

。例如，數(shù)據(jù)可直接從

Iceberg

表供分析引擎

消費(fèi)，無需通

過

ET

L

導(dǎo)出到專用倉庫。據(jù)小紅書團(tuán)隊(duì)分享8，引入

Iceberg并結(jié)合一系列數(shù)據(jù)同步策略/架構(gòu)調(diào)整后存儲(chǔ)/帶寬成本優(yōu)化80%+。但

ETL

在復(fù)雜場(chǎng)景/強(qiáng)監(jiān)管的場(chǎng)景下仍具備不可替代性。ETL

可嵌入數(shù)據(jù)質(zhì)量校驗(yàn)規(guī)則

（如去重、空值填充、異常值過濾）。例如，金融業(yè)務(wù)需通過

ETL

移除敏感信息以滿足

GDPR

合規(guī)要求，而實(shí)時(shí)流處理

可能

無法同步完成此類復(fù)雜清洗。另外，面向多種異構(gòu)數(shù)據(jù)源（尤其是遺留系統(tǒng)）時(shí)，由于傳統(tǒng)

ERP

系統(tǒng)接口封閉

，需ETL

適配器完成數(shù)據(jù)抽取，無法直接對(duì)接

Iceberg

等現(xiàn)代格式?？偨Y(jié)來看，對(duì)于絕大多數(shù)業(yè)務(wù)場(chǎng)景，例如

1）存儲(chǔ)成本主導(dǎo)型業(yè)務(wù)，例如大量社交

、電商

平臺(tái)的

用

戶

行

為數(shù)據(jù)、交易數(shù)據(jù)占據(jù)大量存儲(chǔ)資源

，對(duì)

于這類

場(chǎng)景引

入

Iceberg

結(jié)合其他優(yōu)化策略，小紅書團(tuán)隊(duì)實(shí)現(xiàn)存儲(chǔ)/帶寬

成本優(yōu)化

80%+，高于此前騰訊團(tuán)隊(duì)測(cè)試下計(jì)算性能損失

30%的水平，也就是總體系統(tǒng)運(yùn)行成本預(yù)計(jì)仍然是

下降

的；2）中等實(shí)時(shí)分析場(chǎng)景，例如日

志分析（運(yùn)

維/網(wǎng)絡(luò)安

全），結(jié)

合

StarRocks

優(yōu)化查詢性能后，查詢時(shí)長(zhǎng)縮短

80%，也好于計(jì)算性能的損失。但對(duì)于高并發(fā)且強(qiáng)實(shí)時(shí)性的場(chǎng)景，轉(zhuǎn)變架構(gòu)可能帶來成本提升，例如金融防欺詐對(duì)于延遲非常敏感，而

Iceberg

的小文件問題可能因頻繁合并操作推高計(jì)算成本和延遲，相比于原有架構(gòu)性

能改

善不明顯。表

4:Iceberg

對(duì)于數(shù)據(jù)管理架構(gòu)整體成本的影響分析成本維度存儲(chǔ)成本Iceberg

影響（個(gè)例數(shù)據(jù)）減少數(shù)據(jù)冗余與重復(fù)存儲(chǔ)，存儲(chǔ)成本降低

90%存算分離損失

30%性能，小文件增加

S3

請(qǐng)求簡(jiǎn)化管道，減少人工干預(yù)結(jié)果顯著下降計(jì)算成本可能上升（需具體分析）顯著下降ETL

開發(fā)與維護(hù)資料：騰訊云，小紅書，AWS，中信建投注：我們引用個(gè)案數(shù)據(jù)來大體反映影響程度，不具有普遍適用性，且百分比變動(dòng)取決于此前各團(tuán)隊(duì)的數(shù)據(jù)架構(gòu)/配置策略。除統(tǒng)一表格式外，Snowflake

于

2024

年

6

月

3

日首次發(fā)布

Polaris

Catalog，并于

2024

年

10

月

18

日全

面可用（Generally

Available），與

Unity

Catalog

相比，Polaris

Catalog

定位更加開放且中立9。但在產(chǎn)品功能方面，5

/developer/article/22050736

/cn/blogs/china/use-serverless-architecture-to-quickly-build-a-transactional-real-time-data-lake-based-on-iceberg/7

/article/59lbbuvcrzlusmdowjbb8

/post/73423290715753349229

據(jù)

/blog/open-sourcing-unity-catalog，Unity

Catalog

于

2024年

6月

13

日開源。和聲明。6Snowflake美股公司深度報(bào)告Polaris

Catalog

尚處于追趕

Unity

Catalog

的狀態(tài)，例如在元數(shù)據(jù)管理方面，Unity

Catalog

提供更全面的治理功能（如行/列級(jí)權(quán)限、數(shù)據(jù)血緣），覆蓋數(shù)據(jù)、模型、特征全生命周期，而

Pola

ris

僅專注數(shù)據(jù)層；在安

全合

規(guī)方面，Unity

Catalog

內(nèi)置細(xì)粒度訪問控制（如動(dòng)態(tài)數(shù)據(jù)脫敏），更適合高監(jiān)管行業(yè)，而

Po

laris

依賴開源

社區(qū)

的安全策略（如Gravitino）及

Snowflake

原生安全策略。因此

Pola

ris

Catalog

尚處于豐富工具箱的階段，還

沒有

達(dá)到成熟的端到端解決方案，因此主要吸引

Snowflake

生態(tài)內(nèi)的客戶，而非競(jìng)爭(zhēng)新客戶。表

5:Unity

Catalog

與

Polaris

Catalog

產(chǎn)品功能對(duì)比功能/維度SnowflakePolaris

CatalogDatabricks

Unity

Catalog2021

年

5月

26

日發(fā)布12，2022年

4月于

AWS/AzureGA13，2023

年

5月于

GCP

GA14發(fā)布時(shí)間2024

年

6月

3日發(fā)布10，2024年

10

月

18

日

GA11開源，基于

Apache

Iceberg

REST

API，支持跨云/多引擎（Trino、Spark）部分開源，深度集成

Databricks

生態(tài)（Delta

Lake、MLflow），核心功能不開源技術(shù)架構(gòu)元數(shù)據(jù)管理安全與合規(guī)統(tǒng)一管理

Delta/Iceberg表、模型及數(shù)據(jù)血緣，支持聯(lián)邦查詢外部數(shù)據(jù)源（如

Hive、CRM）統(tǒng)一管理

Iceberg

表，支持多云存儲(chǔ)（如AWS、Azure）依賴開源社區(qū)策略，支持行/列級(jí)權(quán)限（依賴

Iceberg），支持

GDP

R

等合規(guī)審計(jì)內(nèi)置細(xì)粒度訪問控制（行/列級(jí)）、動(dòng)態(tài)脫敏，支持

GDP

R等合規(guī)審計(jì)生態(tài)兼容性AI/ML

集成能力開源中立，兼容

Snowflake、Databricks、AWS

等多平臺(tái)通過

Snowflake

Document

AI

支持模型微調(diào)與反饋循環(huán)，但功能較基礎(chǔ)核心功能綁定

Databricks

生態(tài)，可能引發(fā)廠商鎖定與

MLflow

深度集成，支持模型版本追蹤、自然語言查詢（NLQ），提升

AI

治理效率HTLF

案例：簡(jiǎn)化

Snowflake

與

Iceberg集成，但功能尚未成熟（需完善跨平臺(tái)支持）客戶認(rèn)可其開放性與

AI

能力，但未攝取數(shù)據(jù)無法用于建模，需額外開發(fā)資源客戶反饋資料：Snowflake，Databricks，中信建投圖

3:Polaris/Catalog

開源版本在數(shù)據(jù)爬取方面自動(dòng)化程度

圖

4:Polaris

僅支持

Iceberg

格式的連接器，而

Unity

Catalog弱于

Databricks

托管的

Catalog

支持

Delta/Iceberg/Hudi數(shù)據(jù)：《unitycatalog

vs

apache

polaris》15，中信建投數(shù)據(jù)：《unitycatalog

vs

apache

polaris》，中信建投10

/en/blog/introducing-polaris-catalog/11

/en/opencatalog/release-notes#:~:text=October%2018%2C%202024&text=With%20this%20release%2C%20we%20are,available%20as%20a%20preview%20feature.12

/company/newsroom/press-releases/databricks-enhances-data-management-capabilities-with-launch-of-delta-live-tables-and-unity-catalog13

/en-us/updates?id=generally-available-unity-catalog-for-azure-databricks#:~:text=for%20Azure%20Databricks-,Azure%20Databricks,with%20the%20following%20key%20features:14

/blog/announcing-general-availability-databricks-unity-catalog-google-cloud-platform15

/@kywe665/unity-catalog-vs-apache-polaris-522b69a4d7df和聲明。7Snowflake美股公司深度報(bào)告圖

5:Polaris

在權(quán)限控制方面整體優(yōu)于

Unity

Catalog圖

6:Unity

Catalog/Polaris

在數(shù)據(jù)治理方面表現(xiàn)均較弱數(shù)據(jù)：《unitycatalog

vs

apache

polaris》，中信建投數(shù)據(jù)：《unitycatalog

vs

apache

polaris》，中信建投圖

7:血緣追蹤方面，Databricks

托管的

Unity

Catalog

相對(duì)

圖

8:數(shù)據(jù)質(zhì)量管理方面，UnityCatalog/Polaris

處于類似水可用，開源版本的

Unity

Catalog/Polaris

幾乎不可用

平，可用性不高數(shù)據(jù)：《unitycatalog

vs

apache

polaris》，中信建投數(shù)據(jù)：《unitycatalog

vs

apache

polaris》，中信建投和聲明。8Snowflake美股公司深度報(bào)告圖

9:數(shù)據(jù)目錄方面，Polaris

成熟度不高，仍有待提升以改善用戶體驗(yàn)數(shù)據(jù)：《unitycatalog

vs

apache

polaris》，中信建投后續(xù)關(guān)注

Polaris/Unity

Catalog

在如下方面的改進(jìn)：1）自動(dòng)化爬蟲遍歷數(shù)據(jù)并注冊(cè)至數(shù)據(jù)目錄中，降低管理/維護(hù)成本；2）Polaris

是否增加支持第三方身份驗(yàn)證產(chǎn)品，如

Okta、Google

Auth

等；3）增強(qiáng)對(duì)于非Iceberg

格式的支持；4）強(qiáng)化自動(dòng)化數(shù)據(jù)治理工具，例如數(shù)據(jù)保留策略以符合外部合規(guī)要求，提供審計(jì)日志，自動(dòng)化檢測(cè)并進(jìn)行權(quán)限分類；5）強(qiáng)化與后端

M

LOps

的集成。從數(shù)據(jù)管理延伸至

MLOps，構(gòu)建

AI

應(yīng)用技術(shù)棧由于對(duì)非結(jié)構(gòu)化數(shù)據(jù)支持度不足，且下游模型部署依賴外部工具，全生命周期管理能力弱于

Databricks。在

AI/ML

功能集成方面，Databricks

通過統(tǒng)一的數(shù)據(jù)湖倉（Delta

Lake）整合結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)，

直接

支持機(jī)器學(xué)習(xí)全流程（數(shù)據(jù)準(zhǔn)備→特征工程→模型訓(xùn)練→部署監(jiān)控），同時(shí)集成

M

Lflow（實(shí)驗(yàn)跟蹤、模型注

冊(cè)）

、AutoML、Feature

Store（特征管理）和向量索引服務(wù)，減少對(duì)外部工具的依賴；而

Snowflake

以

Snowpark

為核心，通過

Python/Java

API

支持?jǐn)?shù)據(jù)轉(zhuǎn)換和機(jī)器學(xué)習(xí)，但依賴第三方工具（如

Nvidia

NeMo、Dataiku）實(shí)現(xiàn)模型部署和監(jiān)控，由于對(duì)非結(jié)構(gòu)化數(shù)據(jù)支持度不足，且數(shù)據(jù)目錄

Pola

ris

聚焦于

Iceberg

格式管理，無法進(jìn)

行跨

系統(tǒng)的聯(lián)邦查詢和血緣追蹤。Databricks

在

MLO

ps

環(huán)節(jié)具備優(yōu)勢(shì)，但

DeepSeek、Qwen

等團(tuán)隊(duì)在

MLOps

方面的開源推動(dòng)

SaaS

團(tuán)隊(duì)縮小差距。2024

年

2

月

Databricks

宣布以

13

億美元收購

MosaicML，主要考慮是納入其

ML

團(tuán)隊(duì)（此前

發(fā)布

正交微調(diào)框架，優(yōu)化模型微調(diào)效率）。此

后，Snowflake

于

2024

年

5

月考慮以

10

億美元收購

Re

ka，強(qiáng)化自

身

M

L

團(tuán)隊(duì)能力，提供自研模型訓(xùn)練/推理框架，但后續(xù)交易終止。目前

Snowflake

暫無原生的分布式訓(xùn)練框架16。但

考慮到

DeepSeek、Qwen、Google

等團(tuán)隊(duì)在

M

LOps

方面持續(xù)的開源工作，大量中小

SaaS

廠商溢價(jià)收購模

型團(tuán)

隊(duì)的意義正在縮小，跟隨業(yè)界開源工作并做好與生態(tài)的集成適配就能夠滿足大多數(shù)客戶的需求。Databricks

和

Snowflake

在

SQL

引擎方面取向不同，但在復(fù)雜場(chǎng)景下

Databricks

路線具備優(yōu)勢(shì)。Databricks的

Gen

ie

工具適應(yīng)于預(yù)定義語義層后進(jìn)行自然語言轉(zhuǎn)換

SQL，準(zhǔn)確率較高，誤報(bào)/后期驗(yàn)證成本較低；而

Snowfla

keCortex

AI

無需預(yù)定義語義層，但通過

LLM

解析轉(zhuǎn)換

SQL

效果弱于

Gen

ie，容易導(dǎo)致后續(xù)審核/驗(yàn)證的額

外成

本。換言之，在復(fù)雜場(chǎng)景下預(yù)定義語義層可以更精確地進(jìn)行轉(zhuǎn)換，Genie

的效果更佳，而標(biāo)準(zhǔn)化場(chǎng)景下雙方差

異不

大。16

/en/blog/up-to-75-lower-inference-cost-llama-meta-llm/，snowflake

推出

Swift

KV

優(yōu)化推理框架。和聲明。9Snowflake美股公司深度報(bào)告典型的復(fù)雜用例包括自動(dòng)駕駛數(shù)據(jù)標(biāo)注管道、實(shí)時(shí)視頻流特征提取等，而簡(jiǎn)單用例包括財(cái)務(wù)部門報(bào)表

自動(dòng)

化提取。在血緣追蹤方面，Snowflake

覆蓋度不如

Databricks

全面。Databricks

通過

Unity

Catalog（統(tǒng)一元數(shù)據(jù)管理層）實(shí)現(xiàn)了跨數(shù)據(jù)湖、數(shù)據(jù)庫和實(shí)時(shí)流數(shù)據(jù)的端到端血緣追蹤能力，其中

1）包括非結(jié)構(gòu)化數(shù)據(jù)處理（如JSON、圖像、文本）的元數(shù)據(jù)關(guān)聯(lián)；2）Un

ity

Catalog

基于

Delta

Lake

的

ACID

事務(wù)特性，通過事務(wù)日志（Transaction

Log）記錄所有數(shù)據(jù)操作（如

INSERT/UPDATE/MERGE）的上下游依賴關(guān)系，并實(shí)時(shí)更新血緣圖譜。Snowflake

血緣追蹤主要通過

Snowflake

Account

Usage

Schema

提供，但其設(shè)計(jì)更側(cè)重于表級(jí)和查詢級(jí)的統(tǒng)計(jì)信息（如查詢歷史、訪問日志），顆粒度弱于

Databricks，因此無法追溯

Python/Scala/Java

等代碼中的動(dòng)態(tài)數(shù)據(jù)處理邏輯，且對(duì)

Airflow、dbt

等外部工具操作的元數(shù)據(jù)捕獲能力較弱。在

AI/M

L

方面，Databricks

針對(duì)生成式

AI

場(chǎng)景（如微調(diào)、模型部署）設(shè)計(jì)

M

Lflo

w

Tracking17，可自動(dòng)記錄數(shù)據(jù)輸入、模型版本、參數(shù)和輸出結(jié)果，形成完整的實(shí)驗(yàn)血緣；而

Snowflake

的

A

I/ML

功能（如

Snowpark

ML）更依賴外部工具（如

AWSSageMaker），血緣信息需手動(dòng)維護(hù)，難以自動(dòng)化擴(kuò)展。表

6:在

MLOps

及

AI

應(yīng)用技術(shù)棧方面，Unity

Catalog

與

Polaris

的對(duì)比功能對(duì)比Unity

CatalogPolaris

Catalog通過

MLflow

實(shí)現(xiàn)模型注冊(cè)與生命周期管理，但不支持模型層面的血緣追蹤/日志審計(jì)，無原生模型訓(xùn)練/監(jiān)控能力通過

MLflow

實(shí)現(xiàn)模型注冊(cè)與生命周期管理，支持端到端審計(jì)（如

Experian

追蹤模型輸入輸出）收購

Reka

失敗，依賴外部開源工具集（如

HuggingFace

等）AI/ML

功能收購

MosaicML，內(nèi)置正交微調(diào)框架，提升微調(diào)效率集成Genie

工具支持自然語言轉(zhuǎn)

SQL，依賴語義層理解數(shù)據(jù)模式，在定義清晰情況下性能更優(yōu)，但僅限于

Databricks

生態(tài)Cortex

AI

支持

LLM進(jìn)行自然語言和

SQL

轉(zhuǎn)換，無需預(yù)定義語義層（表/列的注釋），可跨系統(tǒng)交互新增

AI

代理開發(fā)能力，管理

API

函數(shù)與工具鏈（如Workday/NetSuite

接口）核心場(chǎng)景圍繞數(shù)據(jù)湖倉遷移，未涉及復(fù)雜

AI血緣覆蓋至模型級(jí)別（如

Experian追蹤模型輸入輸出，符合金

血緣能力限于數(shù)據(jù)層（僅管理

Iceberg表目錄，未數(shù)據(jù)治理與血

融業(yè)監(jiān)管）提模型/特征血緣）緣追蹤無外部數(shù)據(jù)聯(lián)邦治理能力（僅支持

Iceberg

格式），聚焦

Snowflake

生態(tài)內(nèi)數(shù)據(jù)支持聯(lián)邦查詢外部

SQL

源（如未攝取的

CRM

數(shù)據(jù)）閉環(huán)生態(tài)：DeltaLive

Tables

優(yōu)化訓(xùn)練數(shù)據(jù)準(zhǔn)備，與

MLflow結(jié)需搭配多工具鏈（如

Informatica、OpenAI）生態(tài)系統(tǒng)與工具鏈合實(shí)際部署依賴多平臺(tái)（如

Snowflake、Databricks、Azure

SQL）向量搜索可通過

Weaviate

擴(kuò)展金融業(yè)復(fù)雜場(chǎng)景：DataRobot

通過

Unity構(gòu)建財(cái)務(wù)風(fēng)控代理，自

核心場(chǎng)景為數(shù)據(jù)湖倉遷移（HTLF

選擇主因兼容應(yīng)用場(chǎng)景側(cè)重

動(dòng)化合同審計(jì)實(shí)時(shí)

AI

處理：米其林用

DeltaLive

Tables

優(yōu)化供應(yīng)鏈預(yù)測(cè)：Snowflake，Databricks，中信建投Snowflake）未涉及復(fù)雜

AI

場(chǎng)景資料在

AI

應(yīng)用構(gòu)建上，Snowflake

推出

Snowpark

Container

Services、Native

App

Framework、Streamlit

等工具

，而

Databricks

則依靠既有工具組合，例如M

Lflow、Notebooks

等，成熟度低于

Snowflake（工具箱

vs

解決方

案

）。17

/aws/en/mlflow/tracking和聲明。10Snowflake美股公司深度報(bào)告具體到

Snowflake

AI

組件，根據(jù)一些早期反饋18，客戶尋求將部分運(yùn)維的工作負(fù)載遷移至

Snowpark

之上，

在不考慮折扣的情況下，Snowpark

Container

Services

的價(jià)格較

EKS

標(biāo)價(jià)低~20%，但

Snowflake

不具備

EKS

的所有功能，且面臨低/中等吞吐量和高延遲（每筆交易

10-50

毫秒）的限制。而復(fù)雜工作負(fù)載下相比于

Databric

ks

基于

Phonton

引擎，Snowpark

的計(jì)算成本較高，目前更適應(yīng)于簡(jiǎn)單負(fù)載。另外，更長(zhǎng)遠(yuǎn)來看，在

Snowflake、Snowpark運(yùn)行分析負(fù)載后無需支付

CSP

的數(shù)據(jù)傳輸費(fèi)用，長(zhǎng)期來看計(jì)算引擎的優(yōu)化速度快于帶寬19，就地處理負(fù)載

的方案性價(jià)比提升。表

7:S

nowflake

vs

Databricks

在

AI

應(yīng)用開發(fā)方面的對(duì)比SnowflakeAI

應(yīng)用相關(guān)功能Snowpark

Container

ServicesNative

App

FrameworkStreamlitDatabricks

AI

應(yīng)用相關(guān)功能MLflow+

云容器服務(wù)Notebooks

+

dbutils對(duì)比Databricks

依賴云廠商容器，Snowflake

提供全托管服務(wù)Databricks

缺乏模塊化應(yīng)用框架，功能較分散Databricks

無原生低代碼工具，需依賴第三方Tableau/SQL

儀表板資料：Snowflake，Databricks，中信建投表

8:S

nowflake

AI

應(yīng)用組件的成熟度及關(guān)鍵瓶頸組件成熟度中等低適用場(chǎng)景關(guān)鍵限制Snowpark

Container

ServicesSnowflake

Native

AppStreamlit模型部署與輕量級(jí)

AI

服務(wù)數(shù)據(jù)倉庫內(nèi)簡(jiǎn)單應(yīng)用開發(fā)快速原型開發(fā)、數(shù)據(jù)科學(xué)展示生態(tài)案例少，依賴外部工具鏈功能基礎(chǔ)，無法支持復(fù)雜

AI安全風(fēng)險(xiǎn)、擴(kuò)展性不足高資料：Snowflake，Reddit，中信建投關(guān)于

Nativa

App/Streamlit，二者均用于應(yīng)用開發(fā)20，但

Native

App

可將應(yīng)用以包體形式組裝便于分發(fā)和管理版本，而

Streamlit

是一種更松散的形式，主要可用于內(nèi)部應(yīng)用。Snowflake

戰(zhàn)略上傾向于引導(dǎo)合作伙伴/客戶構(gòu)建

Native

App

后在生態(tài)內(nèi)銷售，從而產(chǎn)生規(guī)模效應(yīng)，降低中小客戶的應(yīng)用門檻。目前

Native

App

的典型用例21包括

1）財(cái)務(wù)報(bào)表實(shí)時(shí)分析；2）營銷自動(dòng)化；3）銷售業(yè)績(jī)洞察；4）實(shí)時(shí)整合商品庫存及用戶行為數(shù)據(jù)；5）供應(yīng)鏈報(bào)告自動(dòng)化。Streamlit

此前一直是開源生態(tài)內(nèi)

python

app

開發(fā)的流行框架，成熟度相對(duì)較高，但企業(yè)級(jí)安全等尚待改善。Snowflake

/

Databricks在架構(gòu)遷移、成本優(yōu)化及

AI

應(yīng)用方面的進(jìn)展成本優(yōu)化：過去1年穩(wěn)定負(fù)載成本節(jié)約

20%與

Databricks

引入

Catalyst

優(yōu)化器對(duì)應(yīng)，Snowflake

通過研發(fā)力量引入重大改進(jìn)（成為平臺(tái)默認(rèn)配置）大部分都是自動(dòng)發(fā)生的，無需任何配置或額外的努力來修改代碼。1）查詢執(zhí)行改進(jìn)：縮短執(zhí)行時(shí)間并更有效地處理復(fù)雜的查詢模式。示例包括優(yōu)化連接查詢、自動(dòng)處理偏差和擴(kuò)展對(duì)

Top-K

修剪的支持，以提高具有

特

定

聚

合和過濾模式的查詢的性能。2）數(shù)據(jù)提取和復(fù)制：減少元數(shù)據(jù)復(fù)制所花費(fèi)的時(shí)間，加快克隆速度，并優(yōu)

化大

型數(shù)據(jù)集的提取，以更快、更可靠地將數(shù)據(jù)帶入

Snowflake，從而簡(jiǎn)化工作流程和管道。3）自適應(yīng)優(yōu)化：推出一系列自適應(yīng)優(yōu)化，使

Snowflake

能夠更智能地選擇最佳查詢執(zhí)行策略。例如，擴(kuò)展

Top-K

修剪以包含更廣泛的查詢。4）平臺(tái)效率：Snowflake

繼續(xù)提升平臺(tái)的整體可靠性和速度。例如，團(tuán)隊(duì)縮短克隆操作所需的時(shí)

間，

提高18

/r/snowflake/comments/1eg2iso/eli5_snowpark_container_services_seeking_overview/19

/r/dataengineering/comments/1dl52cu/any_frequent_snowpark_users_here/20

/r/snowflake/comments/1hl17ml/native_apps_vs_streamlit/21

/blog/snowflake-native-apps/unlocking-innovation-real-world-use-cases-of-snowflake-native-apps-in-2025/和聲明。11Snowflake美股公司深度報(bào)告壓縮效率，從而減少資源消耗并使系統(tǒng)運(yùn)行更加順暢。圖

10:Snowflake

過去

12個(gè)月對(duì)優(yōu)化策略改進(jìn)下企業(yè)實(shí)際負(fù)載成本下降約

20%數(shù)據(jù)：Snowflake，中信建投注：Snowflake

采用生產(chǎn)工作負(fù)載上的真實(shí)客戶數(shù)據(jù)來衡量我們的增強(qiáng)性能。2022年

8月以來穩(wěn)定工作負(fù)載的平均查詢時(shí)長(zhǎng)現(xiàn)已縮短了40%。僅在過去

12

個(gè)月中，SPI

就實(shí)現(xiàn)了

20%

的改進(jìn)。AI

技術(shù)棧成熟度：MLOps

方面

Snowflake

加速追趕

Datab

rick

s，應(yīng)用組件領(lǐng)先DatabricksS

nowpark

的流行度正在快速追進(jìn)

Databricks。從

Python

包體下載量看，Snowpark

相比于

PySpark

的

份額大幅追進(jìn)，20