暂告一段落gp

是时候跟gp暂告一段落了,大概在gp上面又花了有3个月。在这3个月的时间内，感觉自己也确实学到了一点东西，也记了很多的笔记。从实际的需求出发，在完成实际需求的过程中，并不停的优化它，大概主要优化了2次。另外，在做的过程中，自己也有很多的思考在里面。讲告别，虽然自己并不太相连告别，但是迟早都是要移交给别人的，与其别人卸磨杀驴，还不如，自己主动选择离开。

在这3个月内，我从最开始的需求开始，完成360+个字段，然后一张5000万量的表，从各个地方进行n次（n>10)联表操作，完成整个取数任务。在此过程中，我遇到了需要优化问题，而且还有复杂的关联查询，比如join、order by居然也可以使用case when这一神器。良心而已，写这次取数脚本，大概写了我之前从未写过的复杂度，而且随着写得次数多了，我发现我能非常容易的写出复杂的sql了。gp数仓，为啥要选择postgressql，而不是mysql或者别的数据库，个人感觉还是有原因的。postgresql具有非常良好的基因，有非常强大的查询语句，而且，它自身还有非常强大的扩展功能，除了plsql功能，居然还能用python这种编程语言，直接让数据库除了查询，还能完成复杂的计算任务。只要自己能写的出sql，就能算出来，而且，在gp的分布式加持之下，即使5000万的数据，也能最快在20多秒完成计算任务。这让我非常的感慨它的强大功能。虽然，对pg对Python这种扩展，我没有进入过多的深入研究，但是，冰山一脚就让我感叹于它的强大。

其实，此次取数任务，本身更多需要的是postgresql的语法知识，而对greenplum这种架构之类的东西，（对应的书，《GreenPlum从大数据战略到实现》）大概只有查询的时候，需要知道，编写数据表的时候，需要知道（大表指定好分布键、指定按时间分区、列存储），其他的时候，比如5000万任务，按24个节点来计算时，大概每个节点，大概200万数据，所以，对每个节点来说，压力不大。在计算的过程中，尽量不要频繁的挪动、跨分布键来取数，（除非不能避免）。然后很多知识，其实都应该看那本《深入浅出postgreSQL》书。在一些函数上，应该自己翻阅PostgreSQL的官方文档，官方文档也给了我不少的新语法知识。比如，array_agg(字段，排序按另外一个字段），此外，我也尝试读了一些其他的数据，尝试对sql的优化，掌握sql的知识等。其实这些优化，都抵不过一个简单的历史拉链表。（我们可以简单的将一个具有不定周期的数据，看成一个池子。池子有进水口，也有出水口。对于完成生命周期的数据，都应该让其流出出，对于还没有处理的数据，就应该让它还留在池子里。尽量让池子里面的数据，尽可能的少，这样每次每天处理的时候，只需要处理池子里面的内容。我更喜欢把池子水，当做工作区，所以，我希望进尽可能的让工作区的内容不要堆跌太多。至于长期未处理的数据，我们应该会在每个月，集种处理一次，然后我们还能顺便看看这些都是些什么数据）。

其他的，取数技巧任务，等待有时间的时候，我会在取数笔记中完善。