从snowflake上市漫谈云数仓

背景

snowflake上市了，snowflake让普通员工发财了！一上市估值700亿刀！snowflake的IPO，是上个月看到的科技圈爆款新闻之一[1]。snowflake是一家诞生于云时代的，彻底跑在公有云上的数据仓库，底层是大数据技术。很多人说这是“新玩法，云时代的新生物”，也有人说这才是“云时代”的大数据基础设施真正正确的打开方式。

作为一个中国的大数据从业者，在几年前，对公有云的感觉还没有这么强烈。前几年，公有云的主要服务是 云主机（EC2）、云存储（S3），然后配合一些云上的RDS（关系数据库）、CDN、缓存服务等等, 大多都是IaaS层的技术，还没有过多渗透到PaaS层（大数据）这个领域（近两年随着k8s和容器化的发展，公有云不断渗透到Paas层）。伴随着snowflake的上市，以及cloudera、databricks、aws、azure、gcp、aliyun等产品的成熟，大数据从业者必须开始思考一些问题，比如：业界的provider（数据仓库/大数据的提供方）时下的发展趋势是什么？业界的用户们（数仓/大数据的使用方）目前使用姿势又是什么样子，适合自己的路是什么？整个生态未来的终局会是什么样子？使用云数仓技术上难在哪，有哪些风险？向云迁移的过程有哪些风险？

搞清楚了这些问题，企业才能做出相对应的技术决策。本文希望以个人的从业经验及自己对业界的调研思考，来回答这些问题。

目录

1. 云数仓的价值在哪？
2. snowflake高估值，云竞品们百花齐放
3. 面对竞品，snowflake标榜自己厉害在哪，怎么解读？
4. 多云数仓是真是假？多云数仓技术难在哪？
5. 在中国，用云数仓靠谱么？
6. 不同公司可能的选择

1.云数仓的价值在哪？

云数仓顾名思义，是跑在公有云上的数据仓库。要说“云数仓”的价值，得先说说数仓本身的情况，然后结合公有云来再来看价值。数据仓库底层是大数据技术，大数据技术在北美已经火了有近10年了，在国内，这5年大数据也基本成为了互联网公司的标配技能。在互联网圈子提到大数据技术，首先会想到的就是1.使用技术门槛高。 2.维护难。成本高，比较吃人力（没3～5个熟手，转不起来自己的大数据集群） 。

技术门槛，不论是选择自建大数据机房，还是使用公有云上的大数据，面对的都是这些技术,差别不会很大。

而维护难，这个点应该是“公有云”帮助数据用户能解决的大的痛点了。大数据技术栈的维护，可以分为 1.集群搭建 2.集群扩缩容 3.集群调优 4.日常运维 5.监控告警 6.数据治理 等等，详细可以参考：大数据sre的思考[2]。 1.集群搭建 2.集群扩缩容 4.日常运维 5.监控告警 ，一般公有云都能覆盖到，可以归属为公有云的基本能力。3、6需要看具体的提供方能力。在3.集群调优这点上，snowflake是号称“avoiding tuning knobs,only one tuning parameter: how much performance the user wants”.

综合分析来看，“云数仓”是能帮助企业解决“维护难”这个痛点的。使用的技术门槛，云上/云下没有本质的区别，都需要学习基本的数据知识和数据工具。

2.snowflake高估值，云竞品们百花齐放

hadoop、spark是大数据的代表技术，其背后的商业公司cloudera、hontonworks、databricks是这些技术的主要贡献者。过去10年，cloudera和hontonworks的主要产品以售卖hadoop集群的管理系统（集成hadoop稳定的发行版）为主要产品，可事实证明，此条路并未得到资本市场的认可。cloudera在19年合并了hontonworks，可目前的市值并不算高（cloudera估值35亿刀）。另一家公司databricks依托spark和notebook技术，但并不局限于data，它把业务范畴定义为Data&AI，当下的估值也不过62亿刀[3]（Databricks’ Growth Draws $400 Million Series F Investment and $6.2 Billion Valuation - Databricks）。

而snowflake刚上市，却有了snowflake估值600+亿美元。给了从业者们一个大大的surprise。

在snowflake长在aws、azure、gcp上的同时，这些公有云provider也有自己的“云数仓”，比如aws有Redshift，google有BigQuery, azure有Azure-SQL-DW. 这些“云数仓”，或多或少都是云厂商自己的技术栈，有着自己的接口，自己的sql方言，自己的admin api。

随着时间发展，业界有很多使用hadoop、spark等技术自建过大数据仓库体系的企业用户。作为公有云，为了不放弃这些潜在用户，方便他们上云，aws提供了emr（elastic-mapreduce），google提供了dataproc。国内aliyun-emr团队也非常活跃，在spark，dfs技术上亦有自己的积累（jindoFS[4]，jindo-Spark）。

那么在“云数仓，云大数据平台”百花齐放的时候，snowflake的产品&技术有哪些亮点呢？

3.面对竞品，snowflake标榜自己厉害在哪，怎么解读？

为了探索snowflake和竞品在产品、技术层面的差异化，本人刷了snowflake的官网document，刷了snowflake发表在SIGMOD的论文《The Snowflake Elastic Data Warehouse》[5]，也大致刷了其他公有云warehouse产品的docs。snowflake主要有以下几个特别的技术点：

1. 存储/计算分离
2. 支持Semi-Structured数据
3. 一揽子sql性能优化技术
4. 基于一致性哈希的存储cache加速
5. end-to-end的安全方案
6. 支持ACID，支持update，time-travel
7. 软件在线自动升级（用户无感知）
8. 数据治理（new）

这篇paper发表于2016年（4年前），这些技术在当时应该是非常新的技术，but now，看起来倒也不算独树一帜了。我们分别看看几大公有云的数据产品，把数据产品分为“云数仓”和emr两类。“云数仓”偏供应商私有化（接口自定义），emr偏通用（接口兼容hadoop api）。

先看“云数仓“

• aliyun“云数仓”hologres[6]与传统自建OLAP的对比，可以看到 1.存储/计算分离3.一揽子sql性能加速 5.支持更新 也都有支持，但2、4、6未说明。

• aws的RedShift[7]和Athena，并没有介绍特别多花哨的features。大致说了1.可查询s3数据 2.sql有加速能力 3.存储有cache

• Google的BigQuery[8]。从文档看google-bigquery-doc，功能几乎是所有产品里多的。但文档有些乱，功能的介绍并不多，与google的emr（https://cloud.google.com/dataproc）和google的自研流批产品https://cloud.google.com/dataflow的集成介绍的也不够详细。google的产品给人的感觉一向是“技术很牛逼，体验很一般”，看bigquery也有这种感觉。
• databricks的产品[9]。看介绍我总觉得更偏向machine-learning & AI，而不是warehouse。warehouse的数据更新、结构化半结构化、sql加速在databricks产品介绍中提及的并不是特别多但其实也都有，但在机器学习工程师需要的notebook、ML调优、ML生命周期管理等相关功能介绍较多（databricks的数据开发、数据更新、数据安全功能是有覆盖到的）。

再看EMR（云托管的hadoop）

aws、aliyun、google都有云托管的hadoop发行版。功能从文档上看都差不多，本人没有实际使用经验，不好评价太多。emr相比于“云provider的warehouse“，好处是可以做到和自建大数据机房的技术栈一致&api相同，应用迁移成本低。缺点是软件层面的整合、配置应该还需要自己做，没法做到“云数仓”的开箱即用。 而且hadoop集群的elastic-scaleout能力也没有云数仓“存储/计算完全分离”架构来的强大。

总的来说，snowflake是功能丰富且专注于warehouse的数仓产品。redshift和bigquery在产品上做得似乎都差点意思。snowflake在产品技术的特点中，2.支持Semi-Structured数据 、5.end-to-end的安全方案 、 8.数据治理 依然是亮点，可以说snowflake目前在数据仓库领域内产品技术是处于领先地位的，是一个比较完备的“数据中台”体系。

我觉得这就好比在新赛道里的 “创业公司 vs BAT子部门”，虽然BAT子部门有 资金/技术/流量 等各种优势，但在一个特殊赛道，只要你有能力且足够专注，也是能挑战巨头权威的。公有云上产品很多，单就每一个单项领域产品，不一定能赢足够专注的“3rd-party”供应商，snowflake就是好的例子。

另一个很有趣的point在于北美公有云市场的开放，aws、gcp并没有限制snowflake、databricks的接入&生长，这一点很赞。国内的aliyun、腾讯云据说在与其他3rd-party infrastructure供应商合作上并不是十分open。

4.多云数仓是真是假？多云数仓技术难在哪？

大多数商业公司在使用“公有云”时，很怕的一个点是vendor-lockin（供应商锁定）。如果迁移到了一家云厂商后，如果哪一天因为“费用太高”、“功能不够丰富”等原因想迁移出来，是否会很难？如果难度过高（比如所有的应用程序全部需要重构），那就等于被锁死了。公有云或许会标榜自己的产品没有vendor-lockin，会很容易迁移，但事实真的如此么？在巨大的利益面前，公有云的利益 和 客户的利益，其实有点零和博弈的意思。

除开公有云，3rd-party供应商是另外一股力量。3rd-party供应商使用公有云的Iaas层“存储(s3)&计算(EC2 or VPC)”，搭建PaaS层。有的3rd-party会own开源社区，有的并不会。

说到云计算生态，简单从几个参与方组成的市场切入聊聊。如果站在更高的整个市场去看“云计算&基础架构“的生态，是有以下几个方面参与的：
1.公有云 2.3rd-party供应商（开源社区算在这部分里） 3.用户

不同的结合方式，又衍生出3条路：

1. 直接使用公有云
2. 通过第三方平台使用多云
3. 自建基础设施

抛开自建基础设施，path2是比path1看上去更诱人的选择。引入3rd-party，第三方的利益在于向用户收取“Saas层&Paas的服务费”，而非“Iaas层的基础设施费用“，这一点和path1有根本的区别。path2也打破了”公有云“和“开源社区”的矛盾，一定程度避免了“只索取不付出”问题。

回到“云数仓”领域，公有云的“云数仓”是有可能发生vendor-lockin的，比如：数据存储格式不开放、使用api不同、管理api不同、平台化UI使用习惯 等等都是潜在的风险，对用户的风险高，用户轻易不敢把自己的生命交给path1这条路径。 3rd-party的云数仓相对好一些，3rd-party因为自己所处在生态的定位，没有动力赚取计算资源费用，因此对用户风险适中，用户一定程度上可以信赖。 自建机房固然技术依赖上是安全的，但大多数公司承受不了基础架构的维护成本，这也是“公有云”发展的根因。

3rd-party如果是一条好的出路，那么当下3rd-party在multi-cloud多云化这块做的如何呢？我们还是以snowflake来看。snowflake是支持aws、azure、gcp三家公有云的。snowflake的架构图中分三层：下面是存储、中间是多云的计算层、上层是服务层（包括元数据、sql解析路由、事务管理、数据安全、集群管理等等）。

从架构图及有限的文档看，snowflake是能做到在不同公有云部署的。但我认为multi-cloud并不仅仅是能使用多个云，好还能在multi-cloud间“无缝切换”。比如我今天底层使用aws，明天就可以一键在azure上setup整套服务。如果服务是stateless的，multi-cloud无缝切换或许是可能且容易落地的。但回到数仓领域，“无缝切换”就比较有挑战了。公有云除开存储、计算，另外一个比较昂贵的资源即“公网带宽“。如下图，如果cloud1的计算服务挂了，从cloud2的计算资源访问cloud1的存储，会产生大量的跨公网带宽开销。

一个解决方案是使用多云间的vpn，某种程度可以降低些跨公网带宽费用。但在数据仓库领域，如果sql scan的数据量巨大，vpn channel的带宽会成为query performance的瓶颈。

另一个解决方案是存储层同步。则数据服务的“无缝切换”的downtime取决于数据insync的延迟。保持数据insync，可以从写入时就做“双写”，也可以设定一个cloud为master，另一个cloud为slave，从master到slave做“异步同步”。做到了存储层同步，服务“无缝切换”理论上也是能达到的，的缺点就在于cost了（数据在多个cloud间冗余的成本）。

综上，snowflake等类似的3rd-party供应商的“云数仓”确实能做到跨多云（因为在同一套云数仓技术栈内，接口、sql方言、admin-api、存储层format都是统一的），但目前只是有限的“多云数仓”，未能达到多云间服务的“无缝切换”。

那么理论上，跨云的“无缝切换“真的可能么？

multi-cloud migration基本的常识是，在stateless层面是比较容易做的，而在stateful层面会面临挑战。stateful在大数据尤其有挑战，因为大数据的状态非常多。大数据一般可划分为“存储&计算”这两层。

• 计算层一般属于无状态stateless，跨云较容易，但也要注意计算层的“api兼容性”问题，接口，sql方言，admin api 都有可能是压垮跨云切换的后一根稻草（想象全公司的数据仓库都架设在spark引擎，有1/5的etl是用spark-api编程实现的。当切换到aws，要使用redshift，可能要面临大规模的sql重写） ；
• 存储层属于有状态stateful，需要细看。存储的状态一般包括metadata 和 data两部分，如果开启安全加密，还有安全 & key store状态。
• metadata的主要技术瓶颈在于跨云兼容性。如果metadata依赖外部存储（一般为rdbms），主要考察外部存储的跨云兼容性。比如依托mysql的hive metastore就相对容易做跨云，snowflake paper中提到的kv store，api层面如何设计就不得而知了。
• data层的挑战在于存储层难以跨多云，以及存储格式的不统一。存储层依托s3存储，存储格式使用基于parquet、orc等开源标准格式，数据迁移的门槛就小很多，反之门槛很高。数仓服务的跨云间切换downtime取决于存储层数据copy对齐的速度。
• security &key store会更加麻烦一些。security往往涉及账户体系的转移，如果牵扯kerberos还涉及kerberos体系的迁移。key store不但会涉及到KMS的存储&管理api，key还会涉及到已经加密的data层数据如何进行解密。

因此，不论使用3rd-party还是直接使用公有云的“云数仓”，无缝切换都是比较难的。如果开启安全&数据加密，则是难上加难。这恐怕也是“公有云提供商”们依然投资做emr的缘由，emr大多直接使用hadoop、spark、kafka，或者兼容这些api，互相之间migration的挑战相对会低一些。

5.在中国，用云数仓靠谱么？

在上一趴，我们提到了云服务的生态。要评估在中国“云数仓”是否靠谱，我以为要从生态的多方去进行详细的分析。脱离现实谈战略选择，会不够“实事求是”。

#公有云

中国的公有云和美国相比，技术和服务上是越来越接近，长期趋势也是趋同的。在上述生态中不同的即对3rd-party的开放程度。目前头部的云厂商都没有开放给3rd-party的基础架构供应商。（此结论是据业内朋友反馈，但aliyun现在在和databricks合作：aliyun-databricks服务）因此，国内公有云更容易产生垄断，更容易发生vendor-lockin。

#3rd-party供应商

中国做infrastructure的创业公司目前并不多，有也大多是这2～3年才开始起步的（过去中国的底层软件基础薄弱），比如pingCAP，kylinence等。因此，3rd-party供应商生态并不像美国这么丰富，大多数企业也没有形成使用企业级toB服务的付费习惯。目前在国内path2的选择并不多。

#用户

云数仓的用户，即有“数据”需求的企业。几年前，大多是互联网公司；现在，也多了很多进行数据化、数据化改造的“互联网+”企业。 企业选则大数据的路线，有上面提到了path1～path3三条路，path3“自建机房”是过去5年中国大多数规模以上互联网公司的选择。自建机房，依赖的是企业雇佣“专业工程师”。雇佣又分为雇和俑，俑决定于整个人才市场的储备和报酬期望。雇取决于企业的盈利能力能否维持“自建团队”的开销。中国过去5年是积累了不少数据工程师的，中国工程师的报酬期望虽然一直在增长，但和北美相比，it工程师报酬依然较低，工程师人才红利依然存在。自建机房和云数仓相比，除开使用“云数仓”确实能节省数据基础服务维护成本，“云数仓”产生的费用也蛮可观的，往往比自建机房的机器费用要高出很多[10](云因成本高昂屡被关注，上云的价值是什么？-InfoQ)。另外，自建机房在理论上技术也可以做得更加精细，在集群性能、资源利用率、新版本软件上都可能比“公有云”走的更快更深。比如可以做深度的基础设施层调优（hdfs调优、hbase调优、spark/flink调优等等），集群资源超售、集群在离线混合部署、潮汐应用弹性化等等。

总结，在中国，整个云生态由于国内“底层技术公司”的缺失和公有云的不开放，生态的三角里只有公有云、用户这两方，理论上确实更容易产生vendor-lockin。在用户这一侧，由于中国工程师红利&人才市场的存在，很多公司至今仍选择自建机房。未来企业是否使用“云数仓”，主要去平衡“投入产出比”和“vendor-lockin”避免的成本。未来随着时间推进，随着国内3rd-party供应商的增长及工程师红利的褪去，整体可能会趋同于美国市场。（在容器化k8s领域，国内3rd-party供应商已经有百花齐放的趋势了）

6.不同公司可能的选择

上一趴提到了中国公司要根据自身情况去评估自己的“数据”技术路线，不同公司的路线选择也是难讲清楚的。企业多种多样，很难将企业的分类边界定义的非常清晰。需要企业决策者对技术路线之于业务的作用力有清晰的了解，且具备一定的远见。

常规的划分，可以按 公司行业竞争力、公司体量大小、数据应用密集程度、数据量级等维度，依照常识，产生一些定性的结论：

• 大公司自建数据基础设施更划算
• 中小企业直接使用云数仓更好
• 在临界点前提前准备

到底这些维度到达多少量划归到大公司范畴？临界点的定量是多少？这些维度都蛮难定量去分析的。我觉得这里面依然要交给各个公司的技术决策者自己去判断。几个关键点：

1. 自建机房在开始阶段 投入更大，公有云更便宜。
2. 当机器规模到达一定规模，维护公有云和维护自建机房所需要的人力是趋同的。公有云集群依然需要有人维护（集群大了，数据治理很关键，否则钱糊里糊涂就花超了[10]）。
3. 会有一个临界点。在临界点以下，公有云更便宜，在临界点以上，自建机房更便宜。 临界点根据每个公司的实际业务情况而有所不同。

自己的企业在哪个阶段，是否会到达 “自建机房/公有云”总花费的临界点，需要多久到达，都需要企业自行评估。然而，还是有一些确定性的原则是通用的，比如：

1.未来的新兴企业的数据路线定"始"于云数仓。未来的初创企业，数据技术一定始于云数仓了。这一点与5年前几乎有了质变，过去是一定始于自建。这是由于云时代的到来，外部环境发生了彻底改变。

2.终局视野，用发展的眼光动态调整路线。企业要思考终态，企业的终态是什么样子，数据扮演什么价值，要提前做准备。另外企业还需结合自己当下所处的赛道，自己在赛道中的位置，结合数据对自身业务的战略地位，用发展的眼光去看何时切入，从完全依赖“云数仓”向自己把握“数据命脉”转变，包括积累数据人才，积累“跨多云能力”等等。

另外，已使用自建机房的存量企业，在云时代，也是需要做一次全面的路线review的。过去的路线不一定适用当下情况，需重新review：公司行业竞争力、公司体量大小、数据应用密集程度、数据量级 都要认真审视。做到 “先定位，然后做战略，而后拿出详细的实施计划”。上云是有周期的，netflix上云用了整整8年[11]。 twitter也用了4年时间才将部分hadoop集群上云[12][13]。上云在公司CTO线要有一个长期的计划和顶层设计，否则很容易夭折，终整体基础架构更加混乱。在国内也有公司说，“公司发展到一定体量，就不要All in Cloud“，如果说都用云提供的服务的话，可能自己团队的技术能力就会减弱。如果有一天，万一有些原因需要搬离的话，可能就没有这个技术能力去支持迁移的动作了，就和云绑定了[14]。

来源 https://zhuanlan.zhihu.com/p/261389683