近期 Scott 投入了大量业余时间进行技术回馈，系统梳理了经典著作《Designing Data-Intensive Applications》（DDIA），输出了长达 40 多个小时的技术分享，并组织了多场面向社区学友的系统设计模拟面试。在交流群中，诸如丁聪等技术同仁对深奥分布式概念的精准剖析，也促成了高密度的思想碰撞。
---
[04:58](https://www.youtube.com/watch?v=KvVe3xIGn2M&t=298s) 中美 Infra 现状对比：知乎的极客运维与 SaaS 采购现实
Scott 谈及自己在 2021 年 1 月底回到中国北京，准备在未来一两周内从 Uber 正式辞职开启创业之路。回国后与国内技术同行的交流让他对国内外的基础架构（Infra）环境差异产生了深刻感触。国内互联网大厂与独角兽企业对基础设施的极致压榨与成本控制，与北美工业界重度依赖商业 SaaS 的模式形成了鲜明对比。
他分享了一个具有代表性的真实案例：上周与知乎的技术负责人（Tech Lead）交流时得知，知乎维护着万亿级体量的日志（Logs），集群规模超过 10,000 个节点，然而整个 Infra 团队加起来竟然只有 24 个人。这 24 个人不仅涵盖了日常 SRE 运维，还要负责深度自研与维护 Presto、Hive、Hadoop、Flink、Spark 以及底层数据库等极其复杂的全套大数据技术栈。"每个人都是多点的 single point of failure（单点故障）"，例如负责 Presto 的工程师可能需要一人独揽 24 小时 On-call，一旦逢年过节生病请假，系统宕机甚至面临无人能顶上的风险。这种极其精简的人力配置反映出国内在自研 Infra 维护上的极致节约。
[07:38](https://www.youtube.com/watch?v=KvVe3xIGn2M&t=458s) 传统数仓与 Cloud Data Warehouse：弹性与成本的博弈
探讨云数据仓库（Cloud Data Warehouse）的核心价值，必须将其置于传统自建数仓的参照系中。企业日常产生大量结构化与非结构化数据，若未能妥善持久化存储，数据的遗失就意味着业务洞察与潜在商业营收的直接损失（"Loss of Insights, Loss of Revenue"）。在传统模式下，自建数仓如同自建物理仓库：企业必须采购硬件设备、租用物理机房并雇佣专业团队管理。这种模式极其僵化（rigid），当业务爆发导致数据量从 100 平方米瞬间飙升至 1000 平方米时，企业面临着重新选址、异地租赁与复杂的网络拓扑规划难题，伴随而来的还有电力供应稳定性、电压波动、机房散热冷却等琐碎却致命的运维负担。
```mermaid
flowchart TD
accTitle: Snowflake Query Compilation and Execution Flow
accDescr: Flowchart illustrating how a query transitions from Cloud Services parsing to parallel physical execution across compute nodes.
subgraph CS["Cloud Services (大脑控制层)"]
A["客户端 SQL 请求"] --> B["SQL Parser<br/>(生成 AST)"]
B --> C["Logical Plan 生成与 Binding<br/>(交互 Catalog 校验类型/元数据)"]
C --> D["Optimizer 查询优化<br/>(利用 Zone Maps 做微分区剪枝)"]
D --> E["生成 Physical Plan<br/>(确定 Worker 数量及 S3 文件分配)"]
end
subgraph FDB["元数据存储 (独立服务)"]
M["FoundationDB<br/>(分布式 KV / SSI 事务支持)"]
end
```mermaid
flowchart TD
accTitle: Comparison of AWS Redshift Architecture Evolution
accDescr: Diagram contrasting traditional Shared-Nothing Redshift with the modern Shared-Storage Spectrum architecture.
```mermaid
flowchart TD
accTitle: Uber Data Pipeline Architecture
accDescr: Data flow from Uber transactional databases through Kafka and Hudi into Hadoop, queried by Hive and Presto.
现场观众紧接着询问其联合创始人是否为卡内基梅隆大学（CMU）数据库领域泰斗 Andy Pavlo 教授的门生。Scott 给出了肯定回答，并赞同观众所说的合伙人目前在清华大学“姚班”（交叉信息研究院）担任教授的背景，引来现场“太强了”的赞叹。Scott 透露，他们三位联合创始人的初创项目目前仍处于严格保密的筹划阶段；随着他自己即将正式离职全职投入，届时将向外界公布更多产品与技术细节。
随后，Scott 在屏幕上展示了自己的联系邮箱（`shim88@gmail.com`），并欢迎大家通过邮件或微信直接交流系统技术与创业构想。主持人最后对 Scott 带来的深度干货分享表达了由衷谢意，向参与者介绍了 System Meetup 群、后续活动日历与录播发布渠道，并呼吁大家取消静音（unmute）一起开麦道谢。在线近百名观众纷纷送上掌声与致谢，活动在热烈的交流氛围中圆满结束。
## Notable quotes
> [04:58](https://www.youtube.com/watch?v=KvVe3xIGn2M&t=298s) 每个人都是多点的 single point of failure（单点故障） — Scott Shi
> [07:38](https://www.youtube.com/watch?v=KvVe3xIGn2M&t=458s) Loss of Insights, Loss of Revenue — Scott Shi
> [10:35](https://www.youtube.com/watch?v=KvVe3xIGn2M&t=635s) 我们还没想好怎么写这个 query，就是先把 data 存上去。 — NEC 客户
[4:58] Scott Shi: 每个人都是多点的 single point of failure（单点故障）
[7:38] Scott Shi: Loss of Insights, Loss of Revenue
[10:35] NEC 客户: 我们还没想好怎么写这个 query，就是先把 data 存上去。
[25:08] 现场听众: 他刚才那张 slide 他说他有一个 stealing，那我在想他是……如果不需要跟那个 Straggler 聊的话，他怎么知道他要哪一个 file？
[38:52] Scott Shi: Snowflake 绝对不是银弹（Silver Bullet）
[38:52] Capital One 高管: 我们到底为什么一年要在这玩意儿上花掉 2 亿美元？！
[38:52] Scott Shi: 很多代码看起来跟外星人写的一样
[45:00] Scott Shi: 三四岁的 baby
[65:43] 陆奇: 90 年代我们在微软做事务处理时，物化视图方案是完全走不通的，谁要是敢搞物化视图谁就要被点名批评。为什么你们现在又要做 Materialized View 了？
[65:43] 陆奇: 时代变了
[72:47] Scott Shi: 很多时候你查询一行数据，可能要等半个小时
[76:15] Scott Shi: 选择比努力更重要，其实 Hackathon 我每次参加都非常 disappointed（失望），参加一次半年都不想再碰了。
Original transcript
[0:00] OK. Hello, everyone. Welcome to Microsoft System Meetup, the 14th. We're talking about the information about the system and the system. Today we have a guest speaker, Scott. He is Uber Senior Self-Engineering 2. It has a lot of system design and system systems. And in the past 5th, Uber was able to bring to his friends. So he has a desire to provide 4 months of system design and mock interviews. He shared these videos and content to the website, such as "1 m 3 d" and YouTube. I've seen a lot of videos that are very useful. you cloud data warehouse snowflake and beyond Today's content is the main app. It's a bit different from the use of the use. It's a bit different from the use of the use. modern Database management system, and industry are very similar. I hope you like it. that we just Scott, let's talk about this. Thank you. Oh, very much. Thank you, Mozaka. This one, I'll just do a disclaimer. This slide is my team. This is John Huanfeng's slide. He is the professor of清华尧. We were together in the team. So I'm a team. I'm a team. I was invited to talk to him in the last 10th of July, but I was really busy. And then I was able to take a while, and then I was able to take a while. I was able to take a while to take a talk. And then I was able to take a while to take a while to take a look at the database strategy in a conference on the cloud data warehouse. He worked at Snowflake in Snowflake. So I think this slide is pretty good, and then I use it. It's kind of a way to get it. So there's no many original things, but I just wanted to share it with Snowflake's work and Snowflake's work. In the same way, Snowflake's CMO has a tech talk, in the database group. and also invited Snowflake to talk about But then it was 18 years From architecture perspective, there is no big change. It is still the same. uh, I'll just briefly introduce myself. I was in 2007 in the tournament tournament, and I was in the tournament tournament. I was in 2009 to SFU. Then 2012 in EA Canada, I was a system software engineer. Then 2013 I was a research professor at UIOC. And in 2015, 2017 was in Salesforce Analytics Cloud, which is the analytical database and ELT related to the data. And then build up a data flow Data flow system is from scratch build. I was in the fourth year, I went to winter and started. Then I started to go and go and go. Then I started to build a data flow system. It was a system. It was a optimistic logging. In 2017, I joined Uber Safety Team. It's the second engineer. And then I started a project called Safety Report Project. To make all the Uber Safety Data into a整理 and clean. and to gather the same information, and there are many other requests. The project was from the beginning, I was a engineer um, But there are 200 people, actually a lot of people are operations, and several engineers and several data analysts Actually manager has been 10% of the users. And then grow is faster, one year and a half grow is faster. But after Uber was born in the 19th century, it was not growing. Um, And then in the last 5th, like Moseca said, Uber has been a lot of friends, and I gave a system design talk. The system design talk was from last 5th to 9th, It was about 3 months ago, two weeks ago. I still have to spend a lot of time. I have to spend about 10 minutes to prepare for a while. Then I have 40 hours of talk. So this is the size of the size. It is not good. Because this is the time to prepare for it. The other side, I have a lot of knowledge. There are a lot of things that are not good. The other side, I have a lot of things that are not good. And then this talk is mostly in two areas. One is the design data intensive application. This book is a book over a few years. The other part is the mock interview, the system design mock interview experience.
[5:00] 就是讲了一下常见的这个Mocking field这个套路啊然后并且给群里面的这怎么叫水友吗?还是朋友们,那叫学友吧,给群里面的学友们进行那个Mock Interview。然后这边的话其实有几个讨论情嘛,有几个微华讨论情,其实我觉得群里面大半讨论的都比我做的好,我觉得尤其是Tax,就是解决了Tax丁聪同学,解决了很多这个非常非常这个比较难理解的概念,到时候我有空的话也把这个丁聪邀请过来然后我们可以跟大家一起聊一个 Ask Me Anything的一个 session然后从今年1月底的时候就相当于回国了,因为我见面的话,其实我是想创业,所以说这个其实我估计会在一到两周内从Uber赐责,辞职以后开始创业然后我回国了以后只有现在的北京家里面我北京家里面睡这个也是回来以后也见了很多人吧就是见了很多很有趣的地方见了很多人所以我感觉这个国内的环境确实和之前也不一样了然后啊也学到了很多东西,我感觉就是和之前的不一样,并且国内用的技术呢,和这个美国的这个真的很不一样。啊,比如说我上周的时候遇见了一个这个知乎的一个Tech Leader,然后他们说他们之呼maintain的是万亿级数量的logs,万亿级数量logs,然后一万多个nodes,然后一万多个NOZ只有24个人维护就是加SRE加上这个加上这个比如说develop这个Presto,Hive,Hadoop,Flink,还有Spark,还有这个Database所有的人加起来24个人啊,每个人都是多点的singified failure,就是感觉这个这个使用的这个和这个和国外这个差的很多,就是也看出来国内这个确实很省啊,就是国内这个这个这个Infra Team真的很省。另一点来说的话就是,如果你尝试Sales这个RashShift和Snowflake给他们,那他们也是不会买的,因为实在太贵了。整个1万多个Nodes24个人维护的话这个。整个使用的technology和这个tech stack和国外的还是有些区别的还是有一些区别的吧谢谢然后就是我们应该可以开始说这个讲 TechTalk 的东西,OK,嗯我们之后的话可以有一些问答环节,然后大家可以问我一些问题,我们现在开始讲这个Cloud Data Warehouse好了。嗯是其实如果有一个对比的话,那么这个Data Warehouse就可以用传统的Data Warehouse来对比,是吧?你左边有一大堆Data,并且有各种Structure on structure data,然后呢,你需要去把这个Data存储起来,否则的话这个Data就丢失了,丢失的Data就像Loss of Insights,就可能Loss of Revenue,是吧?那你存储起来的话,你可以选择自己建一个仓库,那么就是自己买设备,然后自己雇工人来管理,但是不管是工人还是场地都是要花钱的并且这个相对来是比较rigid的比如说你要租一个100平方米的仓库结果你对它增长很快突然从100平方米就是增长到1000平方米了那你还得重新租仓库是吧然后如果你这个附近没有仓库的话你甚至还可能租在不同地方是吧这都很麻烦并且的话这个人员管理也是个很大的额外的cost比如说刚才举了知乎的例子1万多个nose 24个workers其中某个人要24小时on call这presto down掉以后只有一个人24小时on call比如说假期了要生个病的话这个presto down掉都受不了所以说这时候呢就是其实我们可以有更 reliable 的一种 cloud data warehouse 是吧,就是 SaaS model也就是说你只要付费就可以了,你不需要管一些细节,你不需要管你是不是缺了某种equipment,是不是缺了点擦线板啊,你不需要管这个机房的冷却是不是出问题了呀,啊你也不需要管这个机房电是不是不稳定呀,电压不稳定呀,机房是不是断电了呀,你只要付钱就可以了,你付钱了以后,他给你返回一个service,就是这个Cloud Data Warehouse 的一个Maintainance Service。然后根据你的使用呢也多了很多elasticity,就是多了很多灵活性,如果你比如说你今天只用一个cloud data warehouse的容量的话,你就只用一个,如果你突然增长了100个的话,你可以使用100个,这都是增长了很多灵活性的。所以说这个呢总体来说呢是就是非常好用的但是其实也是关于cost的我记得上研究生的时候我们我们研究生导师研究生研究生老师就distribute systemCS525的一个老师就说第一门课的大概第二节就是讲说我们怎么样计算一下这两个cost哪一个低然后你会把他所有的东西列出来说我如果需要这个的话假设我增长年growth rate是多少那么我能算出一个具体数字来我记得当时的数字那是13年时候当时的数字的话好像是
[10:00] 可是嗯比较小的话就比如说7人的一个startup的话那7 8个人的startup的话好像还是还是这个cloud data warehouse是比较便宜的但之后变大的话的话相对来说你其实自己建个data center还是更便宜的但是自己建data center的话你就相当于比如说不能有single-point failure的话你可能还要每个人都要加一个备份是吧所以说这个这个cost也是比较难说的但总体来说的话考虑到大部分中小business你是没有这个能力去建这个cloud data warehouse的或者是你有各种各样的杂事你其实不愿意去建这个事情那总体来说cloud data warehouse是相对来说是一个比较好的choice其次的话你即使有钱有能力去建你也不能找不一定能找见非常专业的人才sre这块非常专业的人才是比较难找的你有一大堆杂事是吧security啊各种各种这个比如说cloud data warehouse采用什么样的topology啊这种都是有一大堆杂事去做的事就是你需要一些这些专案的人才糖drug怎么搞定那么我们要怎么样 build 一个 Cloud Deliver Warehouse 呢?最早的 architecture 也是非常简单的 architecture,就是 CR Naution architecture。就是说当你有一个 core 的时候,你就过来做 parallel core execution,然后呃当你需要有比如说你communicate需要预见Pypebreaker的话,比如join和aggregate,那你就进行suffle一下data是吧,就是相当于community的一下data。啊这个的话在这个open source的analytical cloud,啊analytical这个database里面,比如说droid,pnoy和这个clickhouse都是用这个share nursing architecture。啊这个是对某种某种data distribution是非常适用的,比如说传统的star schema,是非常适用的,就是star schema,就是说你有一个fact table,有一大堆dimension table,就是非常适用的,fact table,比如说拿Uber的例子的话,就有一个trip,有trip大概有可能有两三百个column,你比如trip起始的时间,trip起始的地点,trip中止的地景,trip中止的时间,还有一些到底是trip是谁tick的,谁是rider,谁是driver,有一大堆信息,就像是一个fact table,你有一大堆dimension table,比如常见dimension table,是在哪一个city,city的话最多有一两千嘛,就只有一两千,并且这个 city这个 dimension table 是一般是不常变动的对于这个 start schema 呢 它是非常适用的 因为你可以把这个 trip 呢partition 到各个这个 nodes 上 是吧 把这个 trip 到各个 nodes 上然后把 dimension table 直接发到各个 nodes 上 每个 nodes 上 copy 一份然后你直接进行 join 就可以了这是这个 click house 就是实践的时候就这样是很快的一个方法就是很快的方法但是现在的很多这个很多这个 join 特别现在数据复杂了有很多 structure data 和 unstructured data 不满足这个 start schema 比如说你很多时候有可能有两个 fact table join 什么两个非常大的 table 进行 join那你这种情况下的话你就非常非常麻烦了你就处理起来的话这个传统的就就不支持了COS我不知道现在支持不支持,反正我看18年TALK是不支持两个FactTable像Join,因为它这个运算复杂度,它实在处理不了,它只需要于它设计的非常rigid的一个STAR Schema,但是它处理的非常快,对于它那个CASE是很快的。然后其次的话这块的话如果是用Sharan Asin architecture的话,它的cluster resizing的话是要说data要进行redistribution的。你虽然可以用Consistent Hashing,就是保证这个Redistribution是proportional to data on the nodes,但是你还是需要Redistribution,是吧,你还需要额外的overhead,然后其次的话,这个你也很难去provision correctly,你经常会浪费很多Compute resource,这边给大家就是普及一个概念,就是相对来说在AWS上,Compute nodes是远远贵于Storage nodes的,具体比例忘了,可能这样10:1的样子具体比例我忘了,Cost可能是比1的样子,甚至更多。然后但是很多人使用的时候就是比如说我知道知道有一个Cloud Data Warehouse 的一个一个 user 啊就是日本的 NEC 公司啊他们他们就是就是这个 Cloud Data Warehouse 最大的user但是他只把 data 存上去 他没有任何 query就基本上 query 数量等于零然后他们这个 Cloud Data Warehouse 方就问这个说哎 你为什么不用 query 你有几个 pp 的 data 在我们 data warehouse 上你是我们最大的 customer 花了一年花好几个 million好几十,上百 million,你为什么没有任何 query?然后他们说,我们还没想好怎么写这个 query,就是先把 data 存上去,还没想好写怎么 query,但如果你用share nothing architecture的话,你整个 compute 的 resource 在这儿呢,全部浪费掉了,你既要配 storage,也要配Starter对应的Compute的钱,这个其实cost是非常非常大的,相当于是你配了10倍的价格近10倍的价格在这个你完全不用的一个东西上,computer resource上。所以说这个Shar Nassen architecture是有这样的问题的。这时候呢就有一个disaggregated compute storage 的一个概念出现了,叫存储计算分离。也就是说我不把data存在各个
[15:00] Compute nodes上了,我把它存在一个专门的一个Storage的地方,比如说Amazon S3是吧,这种存存Storage的地方。那这样的话,我如果需要Compute的时候,如果来Core的话,我就启用对应的computer nodes来进行这个query的computation是吧这个对应的computer nodes呢相当于可以用来做cache用来做cache 那它有很多好的地方就是你的存储和计算是可以完全的相互的independent的去scale的,比如说刚才NEC的意思,它可以只用storage nodes行了,所以它的这个这个cost bill,是吧,它这个bill可以直接slash 90%以上它只要用这个storage 行来说,它根本没有任何query进来嘛,它根本没有任何compute的用档嘛,所以它这个bill可以直接减少90%以上十几个minn就省下来了然后,但是performance的角度怎么讲呢那performance的话,因为这块的话用storage layer的话微层network是他实际上他的那个延迟是10毫秒到100毫秒之间的啊如果你读啊有很多这个benchmark嘛但是一般来说读S3的话P99可能500毫秒也很正常500毫秒甚至1秒都很正常就是S3的P99的话啊,average 的话可能确实在10毫秒到100毫秒之间,总体来说这个lentense是很高的,所以你如果是一些transactional的这个loads的话是肯定不可以的,在你这个lentense太高了,但是这个Analytical的loads呢,相对来说是可以接受的,因为Analyticals的话,就是如果你看过我之前讲的DDIA的话,其实Analytical的 bottleneck在throughput,在data throughput上,它不在lentency上,所以那个是它优化的重点好我们来去下一眼呃并且存储计算分离另一点的情况下是因为你可以skill这个independently,所以比如说在很多可能大部分情况下你都是storage 是多的,然后compute 少了,但你可能有这种非常burst 的一种 mode 是吧,比如说你在不同的 department 的话有不同的这个cord pattern,啊你比如说如果是在financial department,或这个tax department,可能一年只有一次,一年只有几天,或者一个月只有几天,你是有非常密集的cord,那这种情况下的话你可以就是瞬间,就是initialize 很多这个compute的东西,nodes 来帮你进行这个cord的处理然后中间的话可以有unlimited的版本是这个unlimited的打引号的因为这个受制于physical的topology你是怎么安排的还有这个physical的这个storage nodes的这个带宽但是理论上是可以把它变得unlimited 是吧你可能比如说replicate的话你可能变成了unlimited总体来说这个这个存储计算分离是非常适合于不同的access pattern能节省一些cost的好,我们在这块的话稍微暂停一下好了,大家有什么问题的话我也可以稍微回复一下,解答一下,就是存储计算分离和Sharna C architecture如果没有的话就记下了好,那我们就讲一下Snowflake的architecture,所以这个整个Snowflake的architecture呢,其实就是build在这个assumption上的,就是说存储和计算分离。它这边的话就是我们把它分成三层,下面的话是Data Storage层,上面一层是这个Virtual Warehouse层,最上面一层是Cloud Service层。然后Data Storage这个层呢,它是相当于是把所有的Data都存在Amazon SA或者是这个Azure的这个Object Store上了嗯然后Virtual Warehouse呢就是我们刚才讨论了这个Compute Node层然后它是可以完全的就是独立的经营skill的然后最下面这层呢是这个Cloud Service一层它就是存储一些Meta Data存储一些Transaction Management还有存储一些这个Security和Access Control的一些东西所以这三层是完全相当于是分开的我看到好像有人提question,但我这边好像不太方便切。莫塞卡一会儿这样吧,我讲完了以后,你能帮我就是,嗯,moderate 一下 question 吗?我在看群里面的,就 chat 里面有的 question 我会回,然后有问题的话我到时候也会说,莫萨卡也可以说。好的好的,那我继续了,谢谢你们。好,我们一层一层讲,先从这个Data Storage来讲,这块的话是用Amazon S3做Data Storage的。这个我跟那个PinkCAP的一位那个马肖一聊,他就觉得这个想法非常大胆,觉得非常大胆,是第一次接着拿S3来做这个Storage这层,觉得非常大胆,因为这个,你可能这个,刚刚我们之前讲过,它那个Performance其实可能会变得非常糟糕,就并且并且非常不可控。但是另一点的话,另一点的话,这个,它设计会非常简单,然后它的Availability和Amazon S3的Availability和Durability呢,基本上是unbeatable的,就是现有的任何产品是不能打败它的Availability和Durability的,然后你的Bandbase也是可以Skills非常简单的。
[20:00] 然后然后并且你可以read这个object一部分,好像换成说就是Snowflake最早的时候也尝试去实践自己的data storage,但是他发现不管这么自己实践一个什么样的data storage,其实都不能,击败S3的这个availability, durability,然后他们就是觉得这个其实用S3也OK,对于它的identical workloads,用S3也OK,那他们就选择用AmazonS3了。但是这个其实也带来一个问题,就是说他们这个,这个Lentency呢相当于是自带一个10毫秒到100毫秒的overheight,就相当于是这个任何一个carray的话,如果他没有在local,他没有在compute node local cashflow的话,那其实他自带一个10毫秒到100毫秒的overheight。然后这个他们这个data呢是相当于是不管你有多大的一个table,它是把这个table呢分成了一个micro partition一般来说是几十个Megabyte 我记得原来Talk他写的是个60还是多少来的中间好像还改变过几次啊就是他根据他具体的数字来进行optimization然后它这个Data Format也是用一个Pax Format,也就是说它是用Columnar这个Data来存的。就是说他把每个column呢,变成一个单位来进行存储,然后这样的话你就可以做很多,玩很多事了什么,比如说,如果你说肉进行存储的话,你的compress的其实不太好compress,但你进行column存储的话,首先他们data type是相同的是吧,你不管是一个integer还是一个enum这种,类似enum的这种,还是类似一个double,你可以进行compress,并且compress rate可以相对比较高。和最早就是2000年之前的那些那个column不一样的话是,他把这个column是存在一个block上的,就是一个data block上的,所以你读的时候一个data block可能读到都有column最早的,再早之前的column这个design呢,是一个column是放到column是放到不同的data block上所以你读的时候其实是需要很多这个硬盘要来回scan的,所以这个效率会低很多但是总体来说的话,它是一个column的一个storage,所以你读的时候先读header,然后再用compress来就是解决问题然后这个为什么要用column呢?因为大部分analytical query,比如说你是读的时候使用率是相对比较低的这块把使用率扣的使用率就比如说你比如说Uber的拿Uber这个chip的进行chip factable作为例子的话它可能200多个column但是你每次使用的时候可能固定的就使用5到6个column如果你用Row的这个RowOrientated Storage的话,那么你实际上是每个Row存的时候,你必须把整个Row读出来,然后你从这200多column,你只使用了其中5%的data,那你整个效果是比较低的,但如果用Column来存的话,相当于是我只存我那五个相关的column,你的使用率是比较高的好 那我们Storage这层就聊完了我们可以聊这个Virtual Warehouse这层就Compute这层Compute的地层呢,它是采用了这个,呃,就是被称作这个这个这个这个这个比较有趣的一层是,你是on demand的去来拿的,比如说你现在的话,根据你的不同的access pattern,比如说讲过这个,我们刚才讲了一个例子,就是你一个公司的财报部门是吧,或者是tax部门,可能只有月底的时候有比较做呢Compute的任务,所以它可能只有月底的时候,一个月的或者一周的时候,会有一个密集的时间,有一些很多burst mode的这个ad hoc calling,那你这种情况下,你就可以create,瞬间create100个Compute的任务,然后用完以后就消除就可以了对吧并且每个node呢其实是有X码到4X large的并且这个node也有不同的这个是吧比如说你可以有是这种CPU nodes啊或者GPU nodes啊然后现在的话还有一些其他的这个这个这个不同的这个configuration nodes,像最近的话其实这个CPU好像我看了一些这个Token CPU已经到1000核了就是1000核这个Nodes已经变成passable了这个已经讨论其实业界已经讨论了很多年了这个1000核CPU Nodes可能已经passable了那之后的话当你有1000核的时候转你可能有一些非常powerful的一个special的Nodes然后其次的话你可以做一些performance isolation,比如说刚才说的这个financial部门,它有非常burst mode 的这个chore,那还有一些regular的这个chore,比如说这个你可能是一个可能就是一个这个BI层面或者是S层,S这个部门,那它就有非常constant的一种pattern是吧,那你不能说这个financial这个突然burst mode这个corry直接把其他部门的这个Corey变得这个瘫痪掉了,那这样的话就是相对来说两个部门要吵架了,所以说你可能需要就是不同的这个Compute nodes,Worker nodes,来处理不同部门的request。这种情况下的话,他们其实是share的data但是每个都是有自己的 private computer 的Private compute 的这样的话总体来说两个是没有从
[25:00] 然后这个share data,首先又是immutable data,所以是非常clean的一个design,就是你不担心有任何这个非常奇怪的什么data,就是cruption啊,或者这个data这个,这个这个什么rease condition啊,什么这种这种这种没有很奇怪的存在是吧。谢谢大家这里面所有的worker nodes都是非常短暂存在的,就是你积拿机器,你取完了以后,你用完了以后直接返回这个worker pool就行了,其实那个Snowflake也maintain了一个就是非常warm up的一堆这个virtual nodesVirtual Nodes然后他是随时就是给你这种ad hoc用的,有点像这个thwrap pool那种感觉,有点像thwrap pool的感觉,就是你随时可以用的那种。然后这个呃每个这个local instance呢其实是有自己cache的是吧你可以用least recently used cache因为这个也是就是就是提高这个效率很多时候你虽然是Corey是有AdHoc Core,但你Corey这个读的Data可能是有一些Consistent PathPattern 是吧,如果你有cache了没有cache了,performance可能会差很多。这边为了保证你读的同一个tablefile总是到同一个node的,所以他会用consistent hashing,保证你从一个table file,就是同一个node,所以你这种repeated,短时间的repeated这个read呢,是可以读一些local table cache的,不需要去真的去读这个s3,因为s3这个penal也实在太大了。然后呃其次的话这个Snowflake也实践了这个file stealing啊就是非常聪明的一种file stealing就是不是那种传统的那种从那个struggler里面要夺取资源那种就是传统的这个struggler就是传统那种实践的话是你有一个struggler然后它其实已经很慢了但是你要从它那边说我从里面再拿去一些东西,它本来已经很慢了,你从它在跟它talk的时候可能会导致它更慢,但是这面的话就相当于是直接直接download的file从S3就不经过这个bottleneckstruggler了所以就叫这个work stealing还是比较聪明的一种方法我在这里有一个问题啊啊,你说。他刚才那张 slide 他说他有一个 stealing,那我在想他是,如果不需要跟NextJagler talk的话,他怎么知道他要哪一个file?因为这个metadata是在上面maintain的比如说是就是你上面有一个Masternodes这种感觉,就知道谁在卖了,然后就直接bypass它,然后找另一个nose去download file就可以了也就是说 Master 其实知道那个 Struggler 他有哪些任务然后他可以把某一些任务分给其他的然后其他人其实不用通过 Struggler 去 Talk 而通过跟 Master 进行沟通就可以拿得到对好,OK,Thank you.好,然后其次的这些就是一些这个,这个Analytical DB的基本操作了,就是可能有一些SIM的instruction啊,然后有一些这个,呃,Vectorization啊,这个就是基本操作,这边的话,呃,大家可以vick一下,我对这面不是很熟,但是相当于是它把多个column就是因为你这个CPU其实能处理比较多,如果你一次只处理一个column的这个compute的话,其实有很多浪费,他就把多个这个Computation和多个Column一一起处理,这样的话利用CPU的Utilization Rate能把那个CPU的这个同时也增加这个处理这个处理record的这个throughput然后呃还有一些就是额外的优化就是叫later materialization啊这个idea也是其实也是比较旧的later materialization也近有十几年快20年的历史了也就是说你在处理这个core的时候你其实有一大堆intermediate data就是intermediate results,你这个可能很大,但你最后的final results,可能数量不是太多的,所以你实际上就是尽量推迟这个Materialization的时间你到最后的时候它进行materialization你就可以减少很多这个这个overhead 减少很多这个cost来做这个就是late materialization然后最后的话就是这一层就是Execution Engine这层是没有Transaction Management,它是在上面这层进行Management然后自然而然我就讲到最上位这层叫Cloud Service这层了。这层的话相对来说是比较多的,比如说有Authentication和Access Control,这块就bypass不了了。然后Security这块也bypass不了了,Optimizer的话也是非常复杂的一部分,我们只聊其中非常简单的一部分,Optimizer这块非常非常复杂的。Infrastructure Management的话我们避开不了我们计划的话就简单聊一下这个MentadataOptimizer和Transaction Manager这边的话我们可以拿其中一个例子进行举例啊比如说当你有一个SQL query进来的时候首先要经过这个Optimizer来进行这个
[30:00] 要做几个事啊,首先它是这个CV Query呢,Pause成一个Abstract Syntax Trades,然后呢再生成一个Logical Plan然后logical plan呢经过optimizer呢就是optimize下这个logical plan然后呢这时候呢他呃在logical plan生成的过程中他也跟这个catalog聊比如说你这个Select A from Table B 是吧,你需要去跟这个Catalog 聊,说我这个Table A存在不存在那我table B存在不存在,table A的这个,table A,这个,这个,这个,这个,column, sorry,column A,它的data type是什么,是吧,然后能不能进行你specify的运算是吧,那你会做很多这个,这个checking工作,这个,这部分叫banding,banding工作。然后你读到这个这个States以后呢你就生成一个Logical PlanLogical Plan以后经过Optimizer的话会这个这时候呢你会把它说我要去啊进行比如说你要进行trisection的话你要lock这个status你要lock这个对应的这个table status然后lock完了以后呢你开始进行就是生成这个physical plan就是进行这个physical fly,然后这个physical fly是parallel这个这个execute的,然后分布到不同 nodes上,然后这个从logical plan translate,从physical plan这块也得决定,大概要就是initialize多少个 nodes,是吧,你要initialize多少个 nodes,然后每个 nodes去读哪些s3的file,是吧,然后怎么样进行这个,怎么样进行这个join和aggression,是吧,这个都是要相当于是处理完的,有的时候这个join和aggression是可能是在这个master nodes上执行的,有时候可能是在这个execute,Executor nodes就是下面这个nodes上去行的好呃这边的话他这个catalog呢是实际上用了一个非常就是standalone service 用foundation db 的啊这个foundation db 啊其实啊是比较有趣的一个database啊是啊他是实现了serialized snapshot isolation 我记得serialized snapshot isolation 然后支持这个multi-object的这个two-phase commit这个transaction,所以是去个key value style,其实是key value style,相对来说是一个比较有趣的一个这个database 然后 没什么能说我没讲吗然后 serialization isolation 是什么意思这个叫SSI的话 你可以看一下那个Serialize snapshot isolation 您可以看一下那个DDI那一张,他讲了这个,就是他相当于是相当于是一种optimistic这个Lokinism,然后它实践了这个Serializable,就是你相当于是多个transaction同时进行commit的时候,你就像sf在每个transaction排好对了那种进行commit的那种效果,这个细节比较多了,这个detail的knowledge要求比较多,你可以查一下对应的这个知识。我们今天就不讲这一块了好的都行,然后对,然后这个,然后它这块的话有些low latency的lookup,比如说这个你要进行catalog lookup,stats lookup,就比如说什么是min value,什么max value,然后然后同时呢有一些这个,有一些room maps,我们一会会讲room maps,然后整个这个Snowflake的这个transaction呢是Fully Transactual 支持 Snapshot Isolation 的,就是 MVCC 的。其实它这个整个这个Data Model 确实是比较适合 MVCC 的,就是每次往上面喷的就可以了。其次的话,这个 Snapshot Isolation 对于 Analytical Workload 应该是最高 Level 的 Isolation 了。因为你不需要就是,你不需要 Handle 任何这个,这个这个就是serialization的问题是吧因为你其实是呃其实是那个前面你会有一个transactional database 你帮你handle了到底谁是winner 谁是loser的问题了你只要保证你读的是在某个时间点下你读的他是这个snapshot是crack就可以了所以你只要满足snapshot isolation就可以了然后然后就是这个pruning和reclustering呢就是当你进行读这个data的时候,就是我们刚才讲过,就是在这个里面的话,就是你比如说有一大堆table,有一大堆fact table,比如说拿Uber的这个trip fact table进行举例好了,你可能这个trip table可能有几个,一个pb好了,你把这一个pb的data呢,你会分成非常非常细的,分成了,就十个megabytes作为一份,十个megabytes作为一份,你可能分成了十个八次方分是吧,就是100个million份,100个million分,然后那对于每一个这个每一份来说的话,你可能就有一大堆这个这个states,就是比如说什么是minimum value,什么是maximum value,如果这个data呢,如果一开始没有clustering好,比如说我们看右边这个例子,一开始没有clustering好的话,你很有可能出现这个问题,就是你有三个三个
[35:00] 这个microMicro Partition但是这三个Micro Partition, Minimum和Max Value呢,都是非常跨幅非常宽所以当你要去说我想找这个对于这个CE的column来说我要找CE这个value大于S的情况下这三个Micro Partition都要去读取那这种情况下的话,你每次scan的数据量就比较大了。但如果你进行这个重新把它sorted,你就是不需要完美的sorted,你只要mostly sorted就可以,因为完美的sorted的话这个cost非常大,你可以用一些approximate的algorithm进行mostly sorted,当你进行一些sorted的时候,reclustering之后,那你再进行这个读取的话,那你其实每次需要读取的data就非常少了,比如这种情况下,你只要读取最后一个microMicro Partition就可以了,相对来说你对这些Data会少很多。好,那这样的话我可以对Snowflake进行一个总结了就总体来说整个Snowflake的architecture是比较简单的是比较简单的,想法也是这个主要想法也是相对来说是比较直白的,就是存储和计算分离。首先Snowflake是一个非常纯粹的一个SaaS model,就是跟Southforce一样的SaaS model,就是你只要使用就可以了,你很少有这个tubes,你要去tune很少有的Nobst你就要去Tune,这个其实也不是用户能处理的,比如说你现在有个Core过来,我怎么决定这个Core有多少Compute nodes,是吧?这个用户其实也很蒙逼的,即使是非常expert,即使是用户也很蒙逼的,然后所以说这个话就交给这个expert处理,是吧?就像是Snowflake自己通过分析这个Core,通过分析这个data,然后决定有多少Compute nodes来进行处理。你只要访问一个就是通过一个client的端访问或者通过一个website访问就可以了,always on,always update,就是传统的SaaS model,非常非常好用的。其次的话,它存储计算完全分离的话,那么你其实根据你的这个使用的这个access pattern,就是你可以完全使这个两个bill分开,反正这个storage这块是很便宜的吧,那你一直data存着也可以,但你计算的话,就根据你到底有多少这个compute requirement,来进行这个使用是吧你如果computer requirement比较少的话那你其实其实cost还是比较低的就不会存在NEC这个日本公司存了几个PB的对话从来不使用结果付了十几倍十几倍相当于他应该所付的价钱的账单这种情况了这个是也不会算这种情况的然后它额外的话提供Fully elasticity,是吧,就是当你,可能大部分情况你的这个所需要的compute是proportional,比那个storage要小很多,但是你可能有这种burst mode的话,你需要大量的compute,但是这种存储和计算分离的话,你就可以,当你需要大量compute的时候,你可以就是initialize很多这个compute node来帮你进行计算,然后也增加了performance isolation,使用户的体验更为好一点。很多大客户是不想再lock in到一个cloud上的,从business model讲的,是不想lock in到一个cloud上的,所以说他也支持multip cloud support,这个其实对他们实践,technical实践是非常容易了,但是对于这个business selling point是非常重要的一点。做Cloud的话就不会lock in到一个vendor上了好,Snowflake这块讲完了我后面讲一些其他的大家有什么问题吗我们来可以稍微讨论一下嗨,Scott,谢谢你的演讲,我有一个问题就是关于在paper里面,Snowflake说的是他们的storage layer用的是Amazon AWS S3,然后后来我看他们的产品其实已经支持了其他的,比方说Azure和GCP,然后在paper里面他有说到他们的design decision被S3非常大的影响了那我就在想当他们支持其他的Cloud比方说Azure的Blob Storage会不会需要改他们的一些内在的很多逻辑来adapt好问题 我觉得其实内在逻辑好我个人感觉应该是不会的,我确实没有在Snowflake工作过,所以我没有第一手资料他们到底会不会,我个人感觉不会,因为其实从他们的角度来讲你肯定是separate consumer,就是这块的话,我就把这个不管是来自于Amazon S3,还是来自于Azure,还是来自于Google Cloud的话,我就相当于把它作为一个这个,我就相当于把它作为一个API来存取,看到,就是简单的读。取和写是吧是吧读啊就是Crew的简单的Crew的操作嘛那他到底performance是怎么样子他之后做什么优化那其实相对来说作为这个Snowflake
[40:00] 来讲嗯也不是那么care 是吧他只要看这个performance没有decreation就可以了一般来说你S3的Performance总是不会有Degregation嘛,你Cost也是一直在变低的嘛,你不可能Cost再变大或者是这个Performance越来越差,这是不可能的嘛,那否则要那么多Engineer干嘛,是吧,是说,我觉得唯一可能出现的是突然出现一个创新性的产品,然后他这个是从Revolutionary是,比这个S3更适合作为Data Storage,这是有可能的,就是你整个出现一个创新的产品,10倍速度余,或是10倍cost低于S3,或是10倍速度比S3,10倍速度更可能,10倍cost不太可能。就是10倍少的cost不太可能,然后其次的话,Snowflake不是Silver Bullet,Snowflake其实这个design呢是,我觉得是你从从从high level来看,我觉得更像一个非常simple的一个design,非常simple的design,它不是不是一个完美的design,更不是一个silver bullet比如说用S3作为Data Storage,你带来这个Lintensive penalty就在10毫秒到100毫秒左右,这个其实你所有的这个real time的analyticalAnalytical 你这个 penalty 都很大了,你做 real-time analytics 的时候,你跟其他比,就自带了这个劣势,自带了10毫秒的100毫秒的Lintensy劣势这个其实就很有问题了好的,谢谢。我们在chat里面,Joel Reini有一个问题,是问,We'll talk about pitfalls or risks of snowflake.谢谢大家Race的Snowflake就是cost太贵了我前两天刚听他们那个Capital One是Snowflake最大的用户好像一年给Snowflake贡献1亿美元到2亿美元然后Capital One就说我靠为什么要一年花2亿美元在这个上面这个cost太贵了然后其次的话就是嗯很多技术方面它确实不是Silver Bullet吧,还有很多能 improve 的地方。比如说这个比如说刚才刚讲过这个S3 Data Storage, Data Storage 这块它不是 Silver Bullet 确实可以被influed,还有一些其他可以input的地方,其实可以被input的地方还是蛮多的。谢谢啊我想在这个问题上再问一个就是关于competitor 比方说aws introduce他们自己的cloud data warehouse 他们已经有了叫redshift 啊或者azure引进自己的data warehouse 然后用同样的存储计算分离这种现金的理念 那么Snowflake在这种竞争的环境下有什么怎么保持自己的优势呢这其实不是很technical 但是更像产品方面的问题啊对好问题其实这个redshift我下一页就讲redshift这页就讲redshiftRedshift早些年是一个share nothing的architecture,就是你看到leader nodes和worker nodes就是你刚才说那个leader其实就是处理coria,然后bending,postor,logical plan,optimize,然后他会生成那个physical plan,然后给worker去执行啊,所以他这个其实早天天说share nothing的architecture,那这个snowflake出来以后呢,他发现这个performance确实差一点,然后他就有个新的projectspectrum,Spectrum好像已经19年还是2000年的时候不是2020年的时候deploy反正是近几年过去一年两年deploy了然后它就相当于是在这个上面做了额外的一层 layer,然后做了这个存储和计算分离了,这个Spectrum就相当于是compute nodes然后下面的话这个Storage呢就是Amazon S3,相当于是在这个之前的这个redshift的cluster上就实践了一下这个snowflake的这个所以它现在的话其实performance和Snowflake基本上没有差距了,就是已经很快很快了你变成一个hybrid的architecture了如果你挡住上面这部分把上面这部分 Redshift cluster 变成 Cloud service 的话其实下面这部分就完全是 Snowflake 的 architectureHybrid architecture的,Performance其实差点不是很多。然后问题是他们竞争壁垒是什么?竞争壁垒就是这个player很难实现,整个这个cloud data warehouse其实没有几个player,非常难首先你需要很多的 expertise这里面不管是任何一层都很难,其实最难的一层是optimizer,并且optimizer的人才非常少,optimizer这部分人才是非常非常少的,可能只有在Oracle, Redshift,或者是之前做个postpress啊这款postpress optimizer好像做的最好的有这样的人才但总体来说这optimizer人才是非常非常少的非常非常难造的大家都是就是没有optimizing的经验这块你很多code看见跟万幸球来的似的就是这样子然后其次的话你build的一个这个也很复杂比如说我们看见刚才那个看起来Snowflake像是一个非常简单的architecture
[45:00] Noflake从2012年8月份开始build的,然后他融资是从来没有断过的,就是他中间大概融了四五轮,就是非常好拿钱,因为这个确实是确实很强,非常好拿钱,然后但是他们到第一个GA产品是2015年6月。也就是说它整整被我的三年才能有一个勉强能用的产品然后他们整个15年到现在呢特别是今年2020年整个一年是没有有新的feature的因为他为什么呢他要把整个所有的精力就是处理在这个stable上,让整个系统stable下来。然后我记得那个,我忘了谁跟我说,他去Snowflake进行参观的时候因为他是个大佬嘛所以Snowflake当时派了很多这个architects跟他聊然后聊了一半然后大家都跑去oncall了因为这个foundation db 挂掉了就是他们这个survey非常不稳定foundation db 挂掉了然后他就被他就被那亮到那里了然后就是这个还是很不稳定就是说虽然Snowflake 8年了但是其实你可以认为是相对来说是一个可能就是一个三四岁的baby的样子就是还有很多地方不稳定所以他们不打算加任何feature好的,谢谢。Skyl,对不起,请问我可以问一个问题吗?好。是这样的,我们其实现在是Snowflake的用户,就是说我感觉用起来还蛮方便的,但现在我碰到一个问题,就是这样的,就是说这个,我们现在这cloud上面snowflake用的是挺好但是我们有一些客户要求是要有on-premise的这个也就是说是不通过云的,你觉得有什么办法可以,就是说怎么样去选择一个这个,就是Snowflake equivalent的一个存储的solution,就是unpromised的,在客户的自己的Data Center里面就不上云的这个。什么样的 criteria比较好好问题,这个这个因为我我我我我我几两天在做startup 时候这个相关的就是其实我做了很多,相对做了很多research,就是我觉得我算一个科普科普blocker,这个离expert里大很多,但是算算将来做了很多research然后这边的话是这个嗯你其实可供选择的比较少但是我觉得现在现有的话其实click house 是经过prove就是在就是上千个nodes上万个nodes上经过prove的啊所以说click house是一个选择但是click house有很多自己的问题就比如说那个你需要大量的人去maintain它啊在click house上的话它的design是非常非常简单的design就是它是个share nothing character然后你比如说来一个table它你就说这个table需要configure在哪个nodes上你需要manuallyconfigure如果你增加nodes比如说这个table之前是在三个nodes上是吧你这个nodes是40%30%30%如果你说这个table变大了,我要manually增加一个node,你需要有人去做configuration change,真的要人去做configuration change,然后把它从三个node变到四个node,然后其次的话,刚才提过一点,就是clickhouse这个上面是不支持两个backtable进行join的,你两个backtable join,它就是直接的,就整体就不支持了所以它的Use Case就是非常传统的STAR Schema所以这个就不支持所以这个 但是除此之外,它是没有一个center的这个master nodes 的概念,它相当于是所有的nodes,你的chorex可以发到它所有的nodes上。然后它所有的nodes呢就是有knowledge说这个应该是讲你的coring能发到任何一个nodes上它任何一个nodes都有knowledge这个table data在哪边存储的比如说是40 30 30的分配在nodes 1 2 3上那么我知道它怎么存储的它相当于是nodes的这个就是这个data到nodes的assignment是在nodes上自己maintain的并且所有的 nodes knowledge 是一样的对吧然后我记得 ClickHouse 它这个 replication 也是非常非常fundamental的,就是说它是你这个replication你需要自己去specify,就是可能有的table replication是一,就是replicate,有table就没有replicate。我看他这个index自己研发的时候,他做的这个replication是直接把data replicate了两个data center上,那这样的话performance肯定还是多少有点影响的,因为你这个replicate两个data center上比较慢。总体来说,你没有太好的solution,你用clickhouse也是非常头疼的一部分,非常头疼的。OK OK,那就是我们好像同时在Evaluate这个Single Store和这个就是就是traditional database 或者是比如说sql server或者那个oracle relation
[50:00] 但是你谈的这些都不是analytical database,这个都是oracle这种是transactional database,如果你用transactional database的话,就刚才说的问题,就比如说你用你是按肉层的,然后你读五个column,200个column读五个column,这个performance就炸了是吧?这个我知道我们现在没有这么大的问题,就是说,这个我们的这个Colin Utilization还是相对来说比较高的,所以就是说这个column-based storage is nice to have,但是不一定就是说不是一个killer是这样的,不是Keller的话我对HTAP这块没有太多了解,我前两天去PinkHab,我前两天去参观PinkHab,跟他们那个其实跟平台的CEO,CTO,刘奇啊,东旭,还有那个崔秋三位创始人都聊了一下,也跟他们那个第一个员工和第二个员工也都聊了一下嗯唐流和那个申利都聊了一下,就是我感觉其实你可以尝试用一下PinkApp的Service,PinkApp好像我不知道是不是on-premise的,但是它确实有这种它是个HTAP并且支持一些这个支持一些这个就是啊,就是你说的这个这个analytical这个这个好嘞好谢谢浅试一下PinkApp对对对好谢谢Scon啊我们在chat里面还有一个问题是问能否比较一下Data Breaks然后因为我们时间有限要不我们先回答呃我们回答完这个问题之后就让Scott你先继续present完我们再统一问问题可以吗好的,我这边对Data Break的这个理解其实不是太深,就是我确实时间有限,没有对所有的地方都很了解。Data Break的话,我现在了解的就是,它其实一开始做的是一个compute engine嘛,相当于是这个就是就是之前主要Hadoop太傻逼了,这个这个太慢了,这个整个这个效果实在太慢了,然后它那个之前设计像那个像玩具擦就是积木这个搭建的这个这个这个也很有问题,然后这个Spark从14年开始建向到15年开源迅速火的原因就是就可以就是可以100倍于Hadoop是吧,100倍 faster的Hadoop,然后它之后的话就是发现这个,这个Spark SQL 其实更有前途一点,然后就做了一些Spark SQL 啊什么的用法。嗯,你如果读Spark 的这个User Experience,其实是比较糟糕的。你比如说,我举个例子好了,就拿Spark Streaming 处理和这个这个 Flink Streaming 处理。就来做个例子如果你用flink streaming处理的话你这个其实是有一堆worker nodes就是相当于是随时rided的就直接给你进行处理但你用spark的话你首先还得通过一样的YARN来调度资源,你上来就有一个overhead,就挺慢的,然后YARN调度资源以后,还warm up一下,才能使用。所以这个overhead,就是你这种ad hoc的overhead,实际就是比较糟糕可能是在分钟级的这个等待前提的overhead在分钟级的等待是比较糟糕的然后这个snowflake呃这个databreak是在Snowflake受到这场过度的关注和过热的关注以后呢,他们其实和这个Snowflake都是想做一样的事情,就是想做一个一统的这个Data Platform。他虽然是一开始是做的一个compute engine起家但是他想做个一统的data platform所以他也在这个上面进行这个Column吧,但是总体来说,现在这个Spark的User Experience是比较糟糕的,就是各种各样的原因吧,它是在那个Big Data Ecosystem的,从中来说这个,在Hadoop那套Big Data Ecosystem,从中来说User Echirants我读到是比较糟糕,但我不是这个方面的这个,我没有读太多,所以我这块的话其实也是,我之后可能会了解一下,如果有更多了解的话,我可以随外分享一下。我们还有就是额外的问题,没有了,谢谢你。好的好的,那我们去下一个吧,下一个slide。好 所以说我们其实看一下这个这个这是这是换层的一个观点就是我觉得这个观点非常非常好非常非常非常有趣,据说我们其实现在不是被resources所constrained的,我们其实在Cloud database上,或者Cloud data warehouse上,你其实所有东西都是关于cost你比如说传统的database,你其实就是一个read/write的performance trade-off。当你加一个index的时候,你其实就是加了一些read amplification,但是你使read的performance变得很好当你比如说,你其实是 read, write, straight off,比如说当你加了个 materialized view 的时候,那你也是相当于是 write amplification但你锐的会更好
[55:00] 然后但是现在其实不是了,现在因为在cloud上你可以index everything,是吧?你比如说你data ingest进来的时候,你可以在node1上进行这个这个road index是吧,在node2上进行column的这个columnar的这个index,road3上进行elasticsearch的index是吧,你可以index everything,inverted index,node4上可以做这个什么text index是吧,如果它是个什么location data,你还可以什么gis index是吧,都可以做,然后是说现在这个Cloud database 上其实你这个就不是瑞德和Rate的performance trade-off,而是performance和cost trade-off。基本上就有两个极端的,一个是Rockside的这个公司,是一个非常新的刚拿到B轮投资的公司。它做的就是什么呢?就是Data Ingesting来,我把所有的column,它能所有进行index的方式全部进行index所以它既有Roy, Columnar, Inverted Index, Text Index当我有一个块来读的时候我就根据最适合它的index来进行读取,就是最适合它的index进行读取然后这是这个Rockset做的事情那反方向就是Amazon, Athena, Athena这块就是我相当于是不做任何预处理它就是它下面是用Presto 实践的所以它是这个叫 serverless就是 serverless 这个 architecture 同时是这个叫 Schema on Raid我只有在读的时候,我才进行这个就是我才去读这个schema然后再把它就是把那个data underlying data返还给你它就没有任何write的这个amplification它write的这个 penalty 比较低但是它这个read penalty 比较高就是完全两个极端完全两个极端,但是实际上都是一些这个performance和cost的一个trade-off。那么我们就有很多问题可以思考一下了,是不是我们可以more aggressively create materialized video 是吧?这边其实有很多想法的,就比如说我们不管是这个这个Cloud Data Warehouse 还是这个 Data Lake 是吧, 呃, 如果你不是给 Machine Learning 用的话, 就是你 Machine Learning 用, 你可能需要是吧, 读取大量 data, fetch 大量 data, 如果你不是给这个 Machine 用的话, 那你其实大部分都是人读的, 但你人读的 data 是有限的是吧,你一个人能消化了这几个Mbps的数字差不多了,100MB已经撑死了是吧你只不过是中间要经过大量的RAW data然后进行运算,然后最后生成这个几个MB到100MB的Data那么如果是人度Data,那你其实不管是几个Mbps,100MB data,你其实是完全可以放到Materialized View上的那我们是不是可以再更aggressively create materialized view 在Cloud上是吧?并且你create materialized view的话,有另一个好处是,你可以这个data可以increemental的这update而不是说一上来就是就是一上来每次进Core的时候都重新呢,把这几个billion行扫一遍,然后再生存一个几个megabytes行的这个这个这个materialize view是吧,这个这个这个access pattern本身就有很多资源的浪费,你可以说这个我先我先对某个snapshot的把这个读取出来,然后之后的所有的update都是incremental的update,那这样的话你这个lentency也很低,这个display lentency也极低,那么还有一点值得考虑的是, data compression 是不是真的帮助 performance?有很多非常大的 compression,比如说 column 的 database 你可以做非常复杂的 compression但是你其实就相当于是,就是你花了更多的CPU resource,然后换成了这个减少了这个throughput的压力,是吧,就变得更大的throughput。但是你相当于是你花了更多CPU的resource那这个是不是真的有帮助尤其在现在的话这个Data Storage这么便宜的情况下那到底是CPU bounded 还是 throughput bounded 呢你其实其实这个tradeoff可能需要就是想思考一下的也不是说Heavy Compress 一定会有好处的然后再其次的话是不是可以通过更detail stats来就是来avoid bad plants 是吧你是不是可以有一些bloom filter啊是不是可以用bloom filter 做的一个index 是吧啊也有这么做的还bloom filter 做的一个index 是吧你是不是有更detail stats而不是用最简单的这个min max 来来就是那个就是做那个tree pruning也是有很多值得思考的地方然后有更多值得思考的地方是比如说你一个机器run 100个小时和100个机器run 1个小时那其实是一样的是吧但是你最后的user experience 和这个可能是完全不一样的东西那么对于每一个operator来说,那你是用什么样的virtual machine的instance是吧,那是不是,呃,是不是得思考一下,比如说这个你如果用hash join的话,是不是用比如说hash join我也不知道Hashion是不是应该用个memory比较好的一个instance,就举个例子吧,Hashion的话是不是可能是用某个instance比较好那用另一个的话另一个什么Aggregation 这个的话是用另一个 instance 的 performance 会比较好我感觉好像还需要用一个memory比较好的一个instance比较好那么这个这个selection怎么样进行Ultimate是吧,怎么样进行tradeoff怎么样通过这个
[60:00] 实践的方式来找到一个最合适的这个这个instance,那其实有很多值得优化的地方其次的话 Cloud Database和传统的Betabase很不一样的一点就是传统的Database,比如说Oracle Database,你如果是在每个机器上进行安装的话,其实作为database的provider,你是不知道你的用户data是长什么样子的。就是你其实不知道你用户的贷款是什么样的,你也不知道用户的常见的Corey Pattern是什么样子。但是 Cloud Database 不一样,就是,如果是 Snowflake 的话,它其实知道所有的用户 data 大概形状是吧,它到底是更多像star schema呢还是已经是非常就是那个on structure data经常有n个table进行join,n个fact table进行join呢还是什么样的然后他cory的时候他是使用什么top n color 更多呢还是这个top k color 更多呢还是使用什么John Aggregation更多还是使用了很多recursive的chory是吧我能不能根据这个Corey pattern进行额外的优化是吧那这个其实是Cloud database是对比这个传统DMBS有无与伦比的优势,尤其它可以根据具体的比较大的customer进行额外的优化,是吧?他比如说这个Captain Y说我要走了,是吧?一年花两个月我要走了,那我是不是说,哎,我能对你优化,别见你先别走,是吧?你这个,我觉得你这个Data Pattern和这个Corey Pattern我能进行额外的优化,我肯定保证你在我上面cost比你自己建一个低,是吧?是吧?因为这个Corey Optimizer这一块人才非常稀缺的,但是我能进行优化的话,是吧?能保证这个低。我可以然后其次的话这个呃有很多tune的oportunity,比如说这个一个core用多少个nodes,computer nodes,然后这个storage,这个micro partition,就是这个怎么样多少的这个megabytes适合一个micro partition,你比如说还有这个还有额外的是你怎么样做clustering比较好,这都是可以进行额外的这个tune的opportunity,你有上千个点可以进行额外的tune的opportunity,每一点进行tune好的话可能都成几个million,几个billion dollar的话,你有很多可以值得research的地方是吧,最后的话是你可以进行很多这个,就是就是cross user之间你又可以进行很多这个query optimization,这也是cloud database的好处嘛,就是如果用传统database的话,你是不知道用户data的 你是不知道用户data 你是不知道用户corey pattern的 都是不知道的但是Clouded by Basin 只有这个data的。好,然后我最近呢,我刚才一开始提了,就是我很快会这个月内会向Uber辞职,我自己想做一个startup。我想做一个Streaming Data Warehouse,就是和Snowflake不一样的Streaming Data Warehouse或者是steering database,这些terminology就不细究了。就是你看Snowflake的话因为它在M3上做所以它这个Lentense本身就很高10毫秒100毫秒之间所以你如果是一些real time 的的话它是没法处理的所以我这块想了一个就是我们这个idea就是也是来自我co-founder 不是来自于我啊就是我们我们还在还在讨论一些东西但是基本的话就是说我们可以既courry real-time data in historical data也可以做一些streaming data injection然后呢,这个现在相对来说,这个Snowflake还是不支持,他这个Data ELT还是在几个小时到一天之间然后其次的话也可以支持Complex Query Spot和Short Query Processing Time其中的话,这里面的话是第一条和最后一条,Snowflake是相对来说是不支持的。那就是我们观察到所有东西的话就是看到有很多有趣的地方就是嗯大部分Corey其实是predefined的Coreypretty fine 的 query 。就是说,呃,从这个 query 的 life cycle 来讲的话,可能是这样子的,就是你现在有个 data analyst 说,哎,我老板要一个 dashboard 是吧,要一个 dashboard 那我就先去看看我这个data从哪几个table去Data Quality怎么样,然后就不停的Iterate,然后Iterate出来一个Dashboard,那这部分呢,它相当于是都是一对Ad-Hoc Quality,当这个dashboard生成了以后,因为你是human readable data,是吧,你其实就几个migabyte,是吧,几个migabyte,到几百个migabyte之前,可能有一些data你读取出来是给这个machine进行处理的,但我们假设你只是human readable data,几百个migabyte之间的话,那么其实你这块呢,你这个data size是比较小的,并且你的cory,当你这个data analysis处理完的时候,你的cory是固定式的,那Core是固定死的你固定死了以后呢,然后你就生成一个dashboard,你这个correl生成了以后,你其实很少去改变,然后就开始投入使用了。就Corey可能是像比如说这块可能是这种BI Corey也可能是个mobile app是吧你可以是个可以做b2b2c做个Mobile App,就是你相当于是做一个App,然后它其实就是一个SegleCore,然后你直接deploy到Mobile上,然后进行显示是吧,比如说举个Coronavirus这个Break down by country, Break down by city,就是一个mobile
[65:00] 你可以做成一个非常快的做成一个Mobile App然后deploy过去,你可以有IoT上面有很多应用,然后gaming上有很多应用并且如果你是有predefined query,让data flow进来的话,其实你fundamentally change了一个data pattern,就是之前的时候data pattern都是,你给一个Core过来给你个Response,给你一个Core过来给一个Response,是吧,request response model,但是如果你有这个predefinedCore的话,你其实就把它Data pattern变成了一个这个,相当于是你的这个Core和Application固定的DataFlow进来接他flow进来就相当于是整个这个flow的方向就变了,现在就对他flow进行实时的对你的application update,所以和之前的访问模式也不一样了。相对来说也更有趣一点然后就是更实实一点,这个lentency可以很低是吧,你就没有这个100毫秒的这个sv访问的这个 penaltyLentancy可以很低,其次的话,其实这也是大部分访问的Pattern,是吧?然后其次的话它是event driven refresh这个也是可以很快的把Data最新的Data访问出来,然后我觉得大部分AXS翻译可能都是这样子的然后我最近在做这个,就是我很快的话,就越趋势的话,我就打算全职做这个了。如果有兴趣的话可以联系我,我下面给了一个个个人的邮箱就是有兴趣想要讨论一下的话,你可以发个email然后我们可以讨论一下细节好,这就是我想分享的所有内容了,我觉得现在大家有什么问题的话,我可以帮你解答一下。一开始的时候你提到了就是知乎他用非常少的人来manage非常大的数据请问他们是用了什么就是特别的solution嘛没有人用特别solution,他们用非常simple的solution,他们想把Spark用flink干掉,就是因为他们没有人力来maintain这个这个Spark,然后他们就是想用非常simple的solution,然后他们这个他们相当于只是把这个Data Hive, Presto 都是进行了简单的就是进行简单的处理吧也就是说他们这24个人其实更偏向于SRE上有少量的研发但是研发不是重点然后他们说的速度设都采用最简单的速度设就是减少TagStack,然后进行其简单的词读词。然后我再额外提一下,我突然想到了一点,我刚才忘说了,就是我们做的这个其实是一个better materialized view,就是或者在cloud上的一个materialized view,上周我和我们几个同学一起见陆奇来着,我们跟陆奇聊了一下,有个奇迹论坛,陆奇就问我们说,你们为什么,他们当时是90年的时候陆奇是做transaction的吗?然后在Microsoft做transaction,然后说他们那会儿做materialized view全部都是不行的,如果这个有materialized view这个人要被批评呢?我先说但是现在为什么要做MaterializedView了?就是因为其实现在在Cloud的情况下,你MaterializedView,做MaterializedView和这个做Transaction的Database可以不在一个Node上。所以说你其实又不是这个read和write tradeoff了,Materialized view如果和transaction的这个这个复理在一个nose上的话是个read和write的tradeoff但现在不是啦现在是performance和cost的tradeoff所以MaterializeView可以在其他nose上进行做吗所以这个确实是,这个situation不一样了。然后说完之后他的反应是什么陆琪的反应就是表示赞同他肯定会感叹时代变了嗯,对吧,反正我们也很短了,就是只有20分钟,就是因为陆琪好像因是奇迹论坛嘛,他要审批很多项目,我们实际上就只占了他20分钟时间。但是还是很犀利的,非常销售非常犀利的一个人,还蛮有气的。在chat里面荆州有一个问题问的是,What's the difference with droid?啊这个注意你difference with注意的是这个上面difference with注意的是吧啊就Juid和Penoid是比较像的它是那个呃它也是一个analytical database但是它是建在big data system上它是在big data ecosystem上所以它是用了很多这个呃就是big data那一套的比如说它用rutekeeper来maintain它这个
[70:00] segment到node的assignment它是把data分成segment了就是每个segment可能是segment可能是10的6次方肉还是10的8次方肉来的就是它把这个data分成segment然后它是用rutekeeper来map从segment到node上然后它还用了一些用了一个relational databasemaintained additional dataadditional data这个metadata也是segment related additional data在这个这个就是MetaData上然后他还做了很多吧他比如说他这个Data Injection是用Spark做Data Injection的然后我想想还有什么来着他Corey的时候也是有一堆这个预热的这个Corey nodes来处理的我想想最大的不同是最大的不同是注意的其实还是建在Java那套就是那个Hadoop那套Big Data System上的他那套performance都会比较糟一点就是你用Java本身的这个Java Machine的话有很多这个performance penalty然后这个整个这个Hadoop这套是效率是非常低的就是比较慢的因为你这个做这个你像Redshift Snowflake它是自己写的话它这个performance是比这个Hadoop这套快很多的。然后再其次的话是这个,注意的是,注意的比pnode更糟糕一点是,注意的是没有一个single的contributor的。也就是说,你往注意的是上面提交代码是最不可能被rejected的,也最容易过的。然后注意的也是最难去revert代码的。所以这注意的community,我觉得和pnode的对比可能是最早死掉的。因为这个你如果没有一个权威的那个company或者是管理他的话你这个代码库这个开发的这个开源代码库开发的思维是极其混乱的啊然后是这个然后还有什么额外的事情注意的啊注意的是share nursing architecture注意的是share nursing architecture然后没有了吧就是我们做的思维还是不一样注意的其实还是一个就是data warehouse嘛我们做的是一个 event-driven我们想做的是一个 event-driven就是 low latency 的 materialized view所以做的东西还是不太一样你可以说是之后是 competitor但现在做的东西不太一样现在做的是 event-driven low latency 的 materialized view谢谢在 chat 里面 Joe Rini 还有一个问题问的是 could you say a bit more about transactional database the possible conversions between transactional and analytic pipelines and in Uber's example possible or appropriate to add more analytical events to mezzanning directly问题太长了我得看原文啊啊,Transactional Database,然后 Convergence-based Transactional Analtic Pipelines就是我我也不知道 Transactional Database,就是你想知道 Transactional Database 哪一部分吧然后但是总体来说现在这个Uber那套的话,是 Transactional Database 可能有几个嘛就是一个是MySQL,还有一个是 SchemeList,或者是 DockStore,就是 Shared MySQL他上面多加了一层但是其实是shard in Mexico然后还有的话就是Cassandra然后这个data呢是通过这个CDC就是通过Kafka然后然后Uber有一套自己的叫HoodayKafka就有个Kafka然后就相当于经过一个Uber自己的那个KafkaModifyKafka叫Watch Tower它里面是有schema的然后呢然后呢经过hood然后 ingest到 Hadoop上然后呢再通过Hive进行CoreHive和Presto进行Core就是Uber这一套嗯也work但是总体来说Hive和Presto那一套还是比较慢的所以你不可能拿这个Hadoop这套做这个streaming和这个event driven low latency的这个这个这个这个是不可能的你整个Hadoop那一套就很慢的你很多时候你Core一个肉你可能要等半个小时啊所以这个是performance是比较糟糕的然后在uber examplepassable property rate to add more analytical eventto Mozani directlyMozani 你是指uber你有Mozani吗我不是很理解这个问题啊可能是uber的一个产品吗我也不是很清楚可能我对这块也不太了解因为这个Uber其实还是挺大的所以它中间有很多产品我确实不是很清楚是一个name of the project好的谢谢你
[75:00] 其他的问题吗谢谢大家谢谢我就是有点感兴趣想问一下就是您这个这个stuff 是就是是不是有点这个idea是不是有点像那个就是那种lambda architecture就是说你不断的用从streaming把这个新的delta给啊给ingest起来然后就是就是这样就是用这种方法来maintain materialized view啊对的,您可以认为是有点像Lambda architecture,其实是想replace lambda architecture但是想 replace lambda architecture 很多,Pinot也想 replace lambda architecture大家都想replace marketer,对我们这块的话我这块想的就是Focus还是说只是replace low-learning性这部分。Low-Lintensive就是Event-Driven的这个Materialized View这部分嗯哼OK OK 谢谢大家还有什么额外的问题吗,我可以帮助回答一下。Scott 我看你的那个个人介绍里面有说你参加了Hackathon 我自己读书的时候也参加了一些Hackathon 就是那种36小时的Hackathon 做了一些小产品 你有一些什么比较想分享的经验吗啊对啊我想分享的分享就是我觉得参加Hackzone就是选择比努力更重要吧其实Hackzone我每次参加我都非常disappointed的所以我参加一次我就不想参加了半年就不想参加了,然后就知道下半年的时候,我觉得我就不想参加个Hackson了,几次参加Hackson都比较disappointed,但是我感觉总体来说,我参加过Machine Learning Hacks,Uber的Machine Learning Hacks,大概200队里面拿到过第二名,但是我们成绩是最好的啊,最后那个Chief Santez 还给我们写了封信说为什么是第二名,挺郁闷的啊,但是我们成绩是最好的,然后参加了那个,嗯,Blockchain Hackathon,我们也是,嗯,大概40多个对拿到前四名吧,第四名。还有参加过什么Hackson就是Hackson我觉得有两条相对来说是我觉得是你取得好名次比较好的点嘛,一条就是你要是做most earnest people,most earnest guys,有点创业一样就是你要非常认真,你要真的非常认真去思考一下,然后这个的话一般能guarantee你有一个好的名字,然后其次的话就是选择比努力更重要嘛,你的Hackson除非能给你选好题目呢,否则的话你选择做什么其实是比这个,努力更重要的就是你选题要选好,找到这个问题的关键,或者找到一个很好的切入点。是比较重要的 但是总体来说我参加Hackson是参加一次失望一次主要是对评分标准和这个评委比较失望,参加了以后,并且参加是挺累的嘛,就是你要比如说48小时Hackathon,或者一周的Hackathon,参加一次就是真的半年就不想干活了。不想再参加了可能 judges 会有 bias好好对我看今天有90多人近100人来参加平常还是比较多的,OK比平常多了好多大家还有什么问题我可以帮助解答吗刚刚在 chat 里面有人问你会不会跟我们分享你的 slides分享slides嗯啊如果你愿意的话我们可以把它放到我们的那个Midup的网站上谢谢大家我本身没有太多问题啊,但是这个还是要干,我这个slide是投我队友的,换成的,我说我得咨询一下他行不行,否则的话这个这个slide,我这次是借花献佛嘛,是说这个,我问一下他好了,他如果不介意分享的话可以分享,那我自己的话是没有,我没有objection的。嗯,没关系,那如果scott到时候说可以分享好,我们也会把它放到我们的网站上边,我们把我们的网站的地址也发在里头了。嗯Scott,你那个co-founder 是CMU教授Andy的学生吗?是的啊我知道他他现在在姚班当教授对吧对的太强了对了我们三个co-founder 现在的话还是在囚划阶段的我马上离职的话相对来说就可能就能公布一些细节讯息现在还是不是很方便所以如果对Scott的Startup Project感兴趣的话,欢迎跟他联络
[80:00] 他刚刚在啊在他的最后一张slide里边放了他个人的邮箱所以可以聊一聊对我再share一下,这是我个人邮箱,大家感兴趣的话可以跟我聊,这是我的中文名,shim88@gmail.com有信仰可以回聊一下细节或者是你直接Witchhide pin我也可以,我觉得可能今天加上大部分人都有Witchhide的,你直接pin我也可以。好的,如果大家没有问题的话,那我们今天的MateUp就到这里结束了。谢谢Scoop给我们带来精彩的演讲。最后说一下,因为大家很多没有在我们的SystemMateUp的群里面,如果你们对我们这个SystemMateUp感兴趣,还有想参加以后的MateUp的话,我们有这么一个网站放在了那个chat里面,还有所有的YouTube recordings,每周的calendar,还有我们还有一个微信群,你可以加灵文的微信,9151加他微信然后他会把你拉进我们的群里好谢谢大家参加好 拜拜最后如果大家方便的话,请Amiere自己跟Scott说一声谢谢吧。我们很荣幸能邀请到Scott来给这个talk。谢谢你。谢谢。谢谢。谢谢。谢谢。感谢Scott。非常感谢。拜拜 谢谢 谢谢回答我的问题都市下多谢多谢谢谢大家谢谢大家
![[Chinese] Cloud Data Warehouse, Snowflake and Beyond — Scott Shi](https://reducer.xgoose.org/media/thumbnail/3892.jpg)