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，客户公司里不同高矮胖瘦的人都可以选到合身的”

• 性能快，十倍级别的快：这是部署方式的问题，是云调度能力和弹性带来的高利用率。
• 好拓展：所有的On-Premise数据仓库用到后面都越用越慢，供需错配在任何行业都是个难题，更何况交给企业数据部门这样一个成本中心来做，发起预算配置新的机器都是漫长的过程。

• Snowflake的底层基本都是用Java重写，没有沿用其他的开源框架。
• Snowflake可以让大数据量需求用128 Servers跑，让小数据量需求用2 Servers跑，然后再按计算量*时长计费。技术架构带来的存算分离远比三大云同行要彻底，这不是定价模式的改变，而是技术架构决定了这样的定价模式是合理的。
• 多云的中立性。如果同时使用AWS和Azure存储的客户，用起Snowflake这样的跨云系统，也更加方便。
• 数据仓库通常是PaaS产品，但标准化的Snowflake做成了SaaS产品。简单易上手，Oracle的DBA也可以迅速适应。SQL结果可以和可视化BI一键切换，Data Sharing和安全管理也很好用。

• Zoom的单客收入增长与员工数相关，企业在发展的时候员工数就会变多，下滑的时候也会遇到裁员
• Twlio和Agora的单客收入增长与C端用户数或者使用时长相关，那我们抽象一下就是直接挂钩客户产品的DAU
• 但Snowflake代表的OLAP是和数据存量和BI分析师数目相关，产品的DAU会下降但数据存量却是上升的，而到现在企业所雇佣的BI人数增速也远远要比开发和产品要快得多，因为BI的基数小。

这样的差别是来自于产品和落地所带来的爬坡周期不同：

• 对于大多数SaaS，“今年的客户增长”代表的就是“今年的收入增长”。1-2年后的老客户，很难再提供高速的收入增长。就好比Zoom这样的产品，三个月内就可以让所有员工形成远程开会的习惯。打个比方客户可能是第一年花了100块，第二年花了150块，第三年花了180块。
• 但对于Snowflake这样的产品，，“今年的客户增长”代表的可能是”两年后的收入增长”。新客户可能第一年花了100块，第二年花了300块，第三年花了500块。

• 第一次：OnPrem迁移到云olap。因为在OnPrem的环境里，受制于运算能力，企业只能雇佣这么多BI，到了云Olap后展开算力后，反过来也需要更多的BI。
  
• 第二次：云Olap后，降低了SQL的使用门槛和易用性，不再有环境部署、安装、教学的难题。更多的岗位可以跑SQL。公司的组织架构也可能调整，让数据更加流通。

Snowflake也有一个很好的阵地，数据仓库是最接近基础设施的SaaS阵营，在SaaS上可以展开更多的应用产品：

• 最典型的就是向BI和Machine Learning拓展。Snowflake的BI产品正在测试，而ML也有很好的技术基础，在底层数据自动化上已经超过了同行。
• 也可以纵向向生产链的上游拓展，例如与OLTP连接的Data Integration，Snowpark或者未来的其他产品可以给客户一个云原生的选择。
• 也可以横向向非结构化数据拓展，统一的查询平台在未来也会与Databricks有更多的交集。

从现在进度来看：

• 好的方面是，Data Marketplace的使用率已经从一年多的不到5%，提高到现在的23%。大多数的客户都是在最近三年加入Snowflake的，经历了两年的爬坡周期，他们刚刚安顿下来，有了使用外部数据或者变现数据的需求。
• 难的方面是，数据变现对于大多数客户不是很有必要，而且还面临隐私和数据安全的问题。需要期待客户的数据部门从成本中心，思考是否要成为利润中心时，能不能找到可以变现的脱敏数据源。现在还主要停留在地理、风控、市场等信息，卖家也主要是第三方数据生产商。
• 而长远来看，共同的数据格式和使用习惯也是逐年提高的产品壁垒。数据好不好外，也需要数据方不方便用。

• 这项业务对我有多重要？是占到云收入2%的自有OLAP重要，还是锁定一个IaaS客户，为他提供更开放的应用层环境重要？
• 对人才有多大的吸引力？我能给得起创业公司更高的待遇和职业路径吗，会打破我现有的薪酬体系吗，我的股票值钱还是创业公司的股票值钱？毕竟这样一个业务放在Snowflake就是千亿美金市值，但放在AWS体内隐含的市值可能也就100亿美金水平。
• 有多重的历史技术包袱？开发OLAP时候，有的是收购来的框架（Redshift），有的是基于自己公司使用发展的路径（BigQuery），有的适用现有IaaS中小客户的需求（Synapse），值得我进行技术路线的重写吗？
• 能够与竞对合作到什么层面？Redshift和Synapse都发布了和对方的打通合作策略，以对抗Snowflake的多云中立性，但比起可能流失一个IaaS客户，OLAP的意义有多重要？又怎么保证双方产品在技术上同时迭代，有相同的吸引力？如果不同时迭代，那迭代慢的那方，岂不是吃亏了……
• 中台和KPI层面能提供多大的重视？对于IaaS厂商来说，销售、架构师通常都会负责所有的产品，二线优先级的产品应该提高到多大的重要程度？KPI又怎么能保证这样收入低、毛利高的产品受到销售重视？这不是产品的问题，这是组织架构和管理导向的问题。
• 还有内部各部门之间的协调。不过计算业务估计不会介意OLAP部门改用存算分离后，由于减少冗余造成的计算使用量减少，毕竟给了IaaS客户更好的产品体验。

• 传统企业，尤其是国企和金融企业，有去IOE的需求，更信赖私有云。
• 互联网企业的CTO和CIO都非常自信，认为自己搭一个开源的OLAP更好，而且只用适配自己，不看长期的更新和功能需求的话，短期来看效果说不定更好。