1.从16年的Snowflake论文开始
Snowflake从最初2016年那篇论文开始，《The Snowflake Elastic Data Warehouse》 是一篇当时跨时代的论文，也让云OLAP进入了一个新的时代。在这篇文章里，Snowflake提到：
AWS的EC2和S3已经很好了，要做一个完全云原生的系统现在主流的是Sharing Nothing的数据库架构(Teradata和AWS Redshift)，这个架构主要的问题就是计算和存储没有分离，所以会导致：1）当集群增扩容的时候，需要重新分配数据；2）不容易Shut off不用的计算资源，始终会有浪费Snowflake要在Share Disk的基础上做一个计算和存储完全分离的架构，称作Multi Cluster，Share Data Architecture，这个新架构有不少好处：1）Share Disk是个老概念，原来的瓶颈是计算资源加多了后，会争抢Disk资源，Snowflake根据调用频次给数据做了多备份和缓存，减少了摩擦成本；2）在这个体系里，计算和存储是双重弹性的，大的Query可以从计算层调用非常大的资源；3）Snowflake将计算层划分出了不通的Virtual Warehouse，而且分成不同的级别，就像“S、M、L、XL不同的T-shirt，客户公司里不同高矮胖瘦的人都可以选到合身的”2.论文所描述的也成为了产品的特点
相比Teradata、Oracle等On-Premise的数据仓库，Snowflake和其他的云OLAP一样：
性能快，十倍级别的快 ：这是部署方式的问题，是云调度能力和弹性带来的高利用率。好拓展：所有的On-Premise数据仓库用到后面都越用越慢 ，供需错配在任何行业都是个难题，更何况交给企业数据部门这样一个成本中心来做，发起预算配置新的机器都是漫长的过程。
而相比Resdshift、Synapse、BigQuery这样的三大云产品：
Snowflake的底层基本都是用Java重写，没有沿用其他的开源框架 。Snowflake可以让大数据量需求用128 Servers跑，让小数据量需求用2 Servers跑，然后再按计算量*时长计费。技术架构带来的存算分离远比三大云同行要彻底，这不是定价模式的改变，而是技术架构决定了这样的定价模式是合理的 。多云的中立性 。如果同时使用AWS和Azure存储的客户，用起Snowflake这样的跨云系统，也更加方便。数据仓库通常是PaaS产品，但标准化的Snowflake做成了SaaS产品。简单易上手，Oracle的DBA也可以迅速适应 。SQL结果可以和可视化BI一键切换，Data Sharing 和安全管理 也很好用。
1，2两点就带来了Snowflake在大数据量级别的性能优势，和最方便的计算可拓展性。无论是Redshift、BigQuery或者Spectrum，都没法满足**“让一张急用给老板汇报的的超大数据量Dashboard”比“其他普通需求”**能够效率快得多的完成。做过BI的人应该都有过这种感觉，看着进度干着急的痛苦，这个给老板的需求很急，但来不及了……Fivetran的中立测试(网页链接)也说明了Snowflake大数据量级别所花的时长是最短的，更何况这是在相同算力的情况下，而Snowflake还可以随时拓展算力。彩蛋的是，Fivetran也同时解释了其他测评报告为什么出现了偏颇……
3.NDR隐藏了Snowflake发展增速的秘密
SaaS/PaaS因为其计费模式的特点，我们很容易了解到他的单客户增长与什么Driver相关，就比如：
Zoom的单客收入增长与员工数相关，企业在发展的时候员工数就会变多，下滑的时候也会遇到裁员Twlio和Agora的单客收入增长与C端用户数或者使用时长相关，那我们抽象一下就是直接挂钩客户产品的DAU但Snowflake代表的OLAP是和数据存量和BI分析师数目相关，产品的DAU会下降但数据存量却是上升的 ，而到现在企业所雇佣的BI人数增速也远远要比开发和产品要快得多，因为BI的基数小。
这也使得Snowflake产品本身有更稳定的NDR。 *（NDR是SaaS/PaaS公司衡量增长可持续性最常用到的指标，NDR=老客户在今年的月均recurring revenue/老客户在去年的月均recurring revenue）*而当我们用NDR这个视角去看待Snowflake时候，却发现Snowflake的NDR与其他的企业有很大的不同。没有其他高NDR SaaS标的的新客户收入占比如此低，不到10%。
这样的差别是来自于产品和落地所带来的爬坡周期不同：
对于大多数SaaS，“今年的客户增长”代表的就是“今年的收入增长” 。1-2年后的老客户，很难再提供高速的收入增长。就好比Zoom这样的产品，三个月内就可以让所有员工形成远程开会的习惯。打个比方客户可能是第一年花了100块，第二年花了150块，第三年花了180块。但对于Snowflake这样的产品，，“今年的客户增长”代表的可能是”两年后的收入增长” 。新客户可能第一年花了100块，第二年花了300块，第三年花了500块。客户的增速被延迟了，报表的收入满足感也被延迟了。
而带来这一变化的是OLAP产品的特性，以及企业上云整体的复杂安排，使得客户的爬坡周期能延长到接近2年。对于大多数企业而言，他们从OnPrem数据库迁移到云OLAP的爬坡周期可能是像下面这张图一样：
这也使得OLAP客户，可以很快地将存储打满到60-70%水平，但在计算的迁移上总是很缓慢。而在迁移完成后，因为解放了数据算力，BI分析师扩招后还会提供长期的增长。所以当Snowflake的CFO Scarpelli在业绩会上提到“未来几个季度的NDR都会非常稳定”时候也就不难理解了，独特的老客户增长特点使得这家公司的收入增速降得更慢，也能保持更长期的收入快速增长。这也让Snowflake更有机会完成10年20倍甚至30倍这样的高速收入增长。当我们拉长到25年维度看PS和PE的时候，估值就不一样了。
4.抽象去看OLAP行业，天花板仍然在不断提高
在很长的一段时间内，我们都认为交易型数据库OLTP比起分析型数据库/数据仓库OLAP，是个更好的生意。因为OLTP与开发环境/生产环境相关，有更高的迁移壁垒，比OLAP多快一倍的预算，以及与业务发展直接的调用次数关系。但现在随着数据利用效率的直线上升，这个变化正在改变。调研了解到的很多美国的集成商，都一致反映他们手上的OLAP订单增速比OLTP快得多。数据的使用可能正在经历，或者还需要经历两次飞跃性的变化 ：
第一次：OnPrem迁移到云olap。因为在OnPrem的环境里，受制于运算能力，企业只能雇佣这么多BI，到了云Olap后展开算力后，反过来也需要更多的BI。第二次：云Olap后，降低了SQL的使用门槛和易用性，不再有环境部署、安装、教学的难题。更多的岗位可以跑SQL。公司的组织架构也可能调整，让数据更加流通。
当我们去审视现在的互联网企业的时候，字节跳动、拼多多这样数据驱动上升到价值观的企业已经站在了第二次跳跃的中后期，不少产品经理甚至运营都可以自主写SQL进行一线的数据分析。衡量腾讯这样的古典产品经理主导的公司，还停留在第一次和第二次跳跃的中间。产品经理需要向BI提出需求，需求要在类似JIRA的系统中排期，而到了BI在分析的时候，还会严重受制于数据仓库的性能、不同部门数据仓库的割裂，以及数据治理上的严重问题。从而使得大部分的数据研究只能供给决策层汇报时使用。而到了更多数量的传统企业，他们远远没有达到腾讯的使用效率，还停留在第一次跳跃前的阶段。**而在5到10年后，我们甚至有可能经历第三次数据使用效率的飞跃：SQL像Excel一样成为员工的基础技能。**而这也需要更可视化的界面，和更高度集成的语言。而随着Python在青少年和大学生中的进一步普及，这很可能不是一件难事。回顾到20年之前，做报表要用Excel、做估值要用Excel搭模型，也是难以想象的。
5.Snowflake的业务不止在OLAP领域
好的SaaS企业能够依托迁移壁垒最高的阵地，进行横向或者纵向拓展，典型的案例就是并购王Salesforce和扎根医疗的Veeva。
Snowflake也有一个很好的阵地，数据仓库是最接近基础设施的SaaS阵营，在SaaS上可以展开更多的应用产品：
最典型的就是向BI和Machine Learning拓展。Snowflake的BI产品正在测试，而ML也有很好的技术基础，在底层数据自动化上已经超过了同行。也可以纵向向生产链的上游拓展，例如与OLTP连接的Data Integration，Snowpark或者未来的其他产品可以给客户一个云原生的选择。也可以横向向非结构化数据拓展，统一的查询平台在未来也会与Databricks有更多的交集。
最有想象力的还是Snowflake希望做成的Data Cloud设想，搭建一个可以自由数据交易的Marketplace ，或者按我们通俗的理解”数据的应用商店“。比起三大云的Marketplace，Snowflake肯定有优势。多云属性使得客户存在任何一个IaaS厂商数据，都可以进入Snowflake的市场。与传统的数据使用方式相比，可以直接在OLAP内与自身的数据做关联，不需要二次导入到Python里。
从现在进度来看：
好的方面是，Data Marketplace的使用率已经从一年多的不到5%，提高到现在的23%。大多数的客户都是在最近三年加入Snowflake的，经历了两年的爬坡周期，他们刚刚安顿下来，有了使用外部数据或者变现数据的需求。难的方面是，数据变现对于大多数客户不是很有必要，而且还面临隐私和数据安全的问题。需要期待客户的数据部门从成本中心，思考是否要成为利润中心时，能不能找到可以变现的脱敏数据源。现在还主要停留在地理、风控、市场等信息，卖家也主要是第三方数据生产商。而长远来看，共同的数据格式和使用习惯也是逐年提高的产品壁垒。数据好不好外，也需要数据方不方便用。
举一个不恰当的例子，很多互联网的业内人士都了解过之前的路由器数据市场，有很多我们耳熟能详的数据买家。如果有更安全、更合规的数据售卖，使用的场景也可以非常广泛。
6.大公司在抵御Snowflake时的困局
对于Snowflake大部分的攻击都在于”OLAP的技术壁垒不高，三大云发力很容易追上“对于在大公司内积累了丰富失败经验的我，有很深刻的体会。在回答要不要破釜沉舟的时候，总得回答几个问题：
这项业务对我有多重要？ 是占到云收入2%的自有OLAP重要，还是锁定一个IaaS客户，为他提供更开放的应用层环境重要？对人才有多大的吸引力？ 我能给得起创业公司更高的待遇和职业路径吗，会打破我现有的薪酬体系吗，我的股票值钱还是创业公司的股票值钱？毕竟这样一个业务放在Snowflake就是千亿美金市值，但放在AWS体内隐含的市值可能也就100亿美金水平。有多重的历史技术包袱？ 开发OLAP时候，有的是收购来的框架（Redshift） ，有的是基于自己公司使用发展的路径（BigQuery） ，有的适用现有IaaS中小客户的需求（Synapse） ，值得我进行技术路线的重写吗？能够与竞对合作到什么层面？ Redshift和Synapse都发布了和对方的打通合作策略，以对抗Snowflake的多云中立性，但比起可能流失一个IaaS客户，OLAP的意义有多重要？又怎么保证双方产品在技术上同时迭代，有相同的吸引力？如果不同时迭代，那迭代慢的那方，岂不是吃亏了……中台和KPI层面能提供多大的重视？ 对于IaaS厂商来说，销售、架构师通常都会负责所有的产品，二线优先级的产品应该提高到多大的重要程度？KPI又怎么能保证这样收入低、毛利高的产品受到销售重视？这不是产品的问题，这是组织架构和管理导向的问题。 还有内部各部门之间的协调。 不过计算业务估计不会介意OLAP部门改用存算分离后，由于减少冗余造成的计算使用量减少，毕竟给了IaaS客户更好的产品体验。
但如果退一步想，一个发展迅速的第三方OLAP，刺激了客户在云厂商更大的存储需求，并且没有影响到三大云互相之间的IaaS竞争格局，还证明了SaaS/PaaS的Marketplace是正确的平台发展策略。又怎么权衡呢？
7.中国有Snowflake式产品的土壤吗？
中国是与美国是不同的土壤。中国最大的特点是：
传统企业，尤其是国企和金融企业，有去IOE 的需求，更信赖私有云 。互联网企业的CTO和CIO都非常自信，认为自己搭一个开源的OLAP更好，而且只用适配自己，不看长期的更新和功能需求的话，短期来看效果说不定更好。
这也使得国内能够给类似Snowflake这样公司提供的客户群比美国要少。云厂商，是现在就拥抱云原生，困难但坚持引导客户全都上公有云。还是满足客户的现有需求，帮他们配置OnPrem或者私有云，还是争论的焦点。而到了创业公司，因为客户群小的原因，在技术投入上也很难直接采用ROLAP的路线。