干货分享！坑爹的亚马逊之Redshift

0

写公众号一年来多来，思维上现在和开始写公众号的时候比，有两个比较大的变化。

第一个变化是对职场个人的行为的分析，放到组织架构这个层面看，才能够看明白更多的道理。人毕竟是群体的动物，脱离了组织没有意义。

第二个变化是技术的分析，结合企业的经营模式来看，才能够看得更清楚。任何企业都是需要赚钱的，这必然会影响到技术本身。

今天我们谈的是Redshift。亚马逊的这款数据仓库云产品可谓非常的成功，同时也是非常的坑人。要理解这里面的坑，不能只看技术。

1

一年前就有人和我说Redshift是个大坑，收费贼贵。当然，和我说的这个人没有和我说明白怎么个贵法。

我陆续听到各种相同或者类似的例子。企业还小的时候，用Redshift，用的很舒爽。然后企业慢慢变大，亚马逊一张大账单过来，Redshift从舒爽变成了酸爽。企业觉得自己做了冤大头，决定另谋出路。

这个版本的故事很多。最新的一个是Airbnb。这个公司一度把数据分析跑在Redshift上，终于在某年付出了几千万美元之后决定自己干。于是它们选择了Presto。从此以后再也不花那么多冤枉钱了。

2

另外一件事情是今年Oracle的Openworld。Larry Elison怼上了亚马逊。详细的情况大家可以去看看我的这篇文章（加链接）。

Larry Elison算得上是彻头彻尾的商人。商人说话，总是要打折扣的。然而Larry Elison在他的KeyNote里面有这样的一段话，非常值得我们深思。

Larry说，你们把在Redshift的数据迁移过来，在Oracle的云上跑。同样的查询，不但会更快，而且还会更便宜。我可以写进合同里去，每个月Oracle给你们的账单不会高于亚马逊的50%.

Larry何来此种自信？毕竟写进合同的东西不是胡说八道就可以的。Larry Elison可不是吃干饭的。无利不早起的他，怎么可能胡说八道呢？

结合这两个事情，让我下定决心好好研究一下Redshift。这一研究才发现，亚马逊的这个坑，挖的很漂亮，很值得大家去研究一下啊。

我这篇文章的分析不长。但是里面的干货不少。最重要的，我不是要大家理解技术上的东西，而是能够理解怎么样通过对业务逻辑和技术需求的结合，去理解为什么Redshift会倾向于某些特定的技术实现方式。这种思维方式，是我们看待现实问题的时候，值得去思考的。

倘若您觉得这个分析对您有所启发，还请你没关注的加个关注，有没有关注的都帮忙转发一下。

3

作为分析的第一步。我们先看看用户的合理需求是什么。如果我是一个用户，对我来说，下面的要素是重要的：

1. 我的SQL查询是什么

2. 我查询的数据是哪些表

3. 我需要最晚多长时间里拿到结果

当这些要素确定以后，提供服务的服务商就可以给出一个价格了。至于这个定价模型怎么来，那当然是服务商的问题。

这个定价模型的合理性在于，在一个用户看来，数据，查询本身，和最长等待时间是他唯一关心的和服务有关的因素。

这里面有一个大坑，就是为了在规定的时间里面，对这些数据做这个查询，我可能有很多种不同的方案。这些方案里面有的需要更多的资源，有的需要更少的资源。但是结果都是一样的。

如果我们按照资源的使用量来收费，那么我们是应该按所有的可能的方案里的资源使用最少的那个来算钱，还是资源最多的那个来算钱，还是取平均呢？

至于我最后选的是哪个执行方案，用了多少资源，这个不应该和定价相关。如果相关的话，那么作为服务提供商，就可以总是选择最贵的来服务客户。而且这种选择对很多客户一定程度上是个黑盒子，用户并不知道服务商是用了什么办法来做。

这样的定价模式有一个很明显的好处，它鼓励服务提供商去创新。在不改变其他条件的情况下，服务商因为有了新技术新解决方案，从而只需要更少的资源就可以做同样的事情。这种技术的进步，可以实实在在的带给服务商好处。

4

那么亚马逊是怎么样算账的呢？如果亚马逊是按照这个做法的话，那我也就不说亚马逊坑爹了。

实际上亚马逊算钱的方式就是看你实际用了多少存储和多少计算资源。这个可以理解，10个节点用了5分钟，最后就算成了50节点分钟的使用，乘以单价就是这个查询的钱了。

这种收费模式就非常有意思了。我们退一万步讲，今天亚马逊招了个天才进去，比如把飞总我招进去了。然后我很天才的发明了某种技术，这个技术对所有的查询都只需要原来10%的机器，而且时间还是原来的一半。

这个技术很牛逼吧。加入你是Redshift的老大，你敢让我上这个技术么？呵呵。肯定不敢。

只要上了这个技术，每个客户的账单立刻只有原来的5%了。你说如果发生了这样的情况，Jeff Bezos是应该笑到天亮呢，还是应该把你给开了呢？

5

这个坑就是这样出来的。亚马逊的Redshift组，对于单纯的减少计算资源的查询计算方案没有任何兴趣去提高。

所以亚马逊真正有兴趣的是增加计算资源但是运算时间也变长或者相等的。或者增加了运算资源，但是运算时间减少，可是总节点时间数是增加的技术。

前者自然是不可能的，因为用户体验差。后者当然是亚马逊最喜欢的，增加资源这个东西不一定明显，减少运算时间是个用户都能感受到。

所以和传统的数据仓库比，亚马逊的Redshift对于查询优化并不重视。我听说过不少的传闻说Redshift的优化器做的一般。之所以优化器不需要太好是因为很多优化器的优化是通过减少数据的访问量，来降低查询的执行时间。这个违背了亚马逊的赚钱的初衷。

还有一个著名的说法是Redshift不喜欢构建索引，相反的更喜欢通过大规模的并行数据读取来做查询。这个也很有道理，因为大规模并行读取，一方面可以提高查询的速度，一方面可以增加机器的节点数。既给了用户好的体验，又多收了钱。

6

Oracle的云其实很不一样。这个不一样体现在两个方面。首先Oracle是云数据库的后来者，如果产品不牛逼，它没有生存的空间。

其次是Oracle的非云端的数据库已经存在几十年了。非云端的数据库反正是按年收钱，所以优化器如果能够节省资源又让查询快的话，这种优化必然是要做的。

而Oracle断然不可能给云从无到有重新搭一套数据库。所以关于Larry Elison的Oracle如果跑同样的workload，会比亚马逊省至少一半的钱的宣言我完全有理由相信。

通过减少数据的读写来降低运行时间，对于Oracle这样的数据库来说，不但是可行的，而且是已经早就实现了的。而亚马逊的收钱方式注定了它一定不会热衷于去采用减少资源使用量的方式来提高查询速度。

那么大家可能会问为什么数据量小的时候不觉得贵而数据量大了觉得贵。这个如果说有做分布式数据处理的同学，肯定知道re-partition 的实现的时候，是需要在所有节点之间两两挪动数据的。

这种数据挪动的代价很大尺度上可以认为时间复杂度是数据量的平方。当然这个估计其实不准确，因为里面有很多的优化可以做。而需要做re-partition而不是broad-cast很多时候又是和数据量大小有关。

总的来说，就是Redshift基于商业模式选择的技术路线，决定了它会倾向于通过大规模并行读写挪移大量数据来处理查询。而Oracle的数据的优化器则更可能减少数据的读取量。当数据量足够大的时候，Redshift的做法更有可能要做re-partition，而数据挪动的代价某种程度上等价于数据量的平方。因此，即使Oracle数据库单节点的价格贵，而亚马逊的单节点的价格很便宜。只要过了某个临界点，数据量一上去，亚马逊累积收取的钱就会滚雪球一样变得非常的可怕。

所以这个事情在我看来还是屁股决定脑袋。收费模式决定了技术的走向。Redshift不可能也不会去努力优化可以大量减少资源使用的查询执行方式。如果谁还想入Redshift的坑，不妨先想想自己的数据规模有多大。

欢迎打赏欢迎交学费