本文的题目虽然有点小写意，却是纯粹的技术分析贴，借用一个火锅店的故事，探讨报表查询场景下的延迟问题和一点数据库的特性。
很久之前，有一个老字号的火锅店，顾客盈门，生意红火。涮火锅嘛，大家都知道的，首先是倒入锅底汤料，等汤烧开了，往里面放蔬菜、肉片、海鲜等各种食材，等食材熟了就可以吃了。从食材下锅到吃进嘴里，有个等待的过程，时间的长短取决于两个因素，一是火锅下面的炭是不是充足，火是不是烧得足够旺；二是食材一次不能放太多，特别是一些冷冻状态的食材，否则就会等比较长的时间。
对于BI系统来说，各种食材就是上游系统提供的数据，BI系统的工作就是加工数据并相应客户的查询请求，就是加热食材的过程。BI系统，或者说作为其核心的数据库，就是这个火锅，磁盘大小相当于锅的容量，CPU与内存相当于锅下面的炭火。
这家店比较特别的地方是为了凸显客户的尊贵，食材是由服务员负责放入锅中，食客只管吃。此外，火锅的管理模式是每桌的火锅由一个服务员负责全流程管理，包括火锅的清洗、上菜等等。
不同项目组负责集市的开发过程，运维环节也是由各自的管理员来负责，用户只是最终报表的使用者。
在正常情况下，食材被放入火锅后5分钟就可以吃了，客户很满意。不知什么时候开始，情况了发生变化，食客等待的时间越拖越长。终于有一天，客人午餐点的火锅到了晚餐时间还没吃上，客人很恼火找到老板投诉。
业务用户反映报表查询的速度很慢，而且越来越慢，最后忍无可忍。
老板找来大堂经理和大厨解决问题，经过各种跟踪、调研，大家终于发现了问题所在。原来向火锅中放食材的时候，有个服务员会往里面加冰块，我们觉得他有点糊涂，叫他小胡吧。小胡不是一个人在战斗，店里的服务员不少都是小胡的同乡，也有这个习惯。显然，冰块会延缓食物的受热过程，所以小胡们服务的客人都要多等很久才能吃到食物，导致了客人的投诉。
对于BI系统来说，延迟缓慢的一个主要原因是SQL写得不合理，导致查询效率很低，也就是我们说的烂SQL，就像小胡加的冰块，无谓消耗了很多系统资源。
正好，老板觉得多个火锅也有问题，每个火锅的清理都是由不同的服务员负责，管理起来也费劲，是不是可以搞一个大火锅，顺便解决管理的问题。
靠技术来带动管理，是不是最佳方式 Ivan是有些存疑的，但有时确实有这样的效果。
大厨针对“小胡加冰”问题和老板的管理需求，提出了解决方案，代号“一口大锅”。方案包括两部分，一是换口火力猛的大锅，二是对小胡们进行培训。具体来说，首先需要一口大火锅（某款MPP数据库）替代现在每桌使用的普通火锅（单机数据库），但要具备两个条件。一是大锅的火力够猛，造价低，实在不够用还可以扩展（基于X86服务器，可水平扩展）；二是后厨团队掌握相应的使用技巧（因为批量加工上已经使用了这种技术，团队对这种技术比较熟悉）。大厨选定的这款大锅是九宫格火锅，每桌食客用一个格子，体验基本是不受影响的。（这个地方不要较真哈^Q^）（项目开发团队和用户都是面对逻辑上独立的数据集市；同时，MPP数据库具备一定的工作负载管理能力。）同时，再出台新的操作规范，针对小胡和他的同乡们进行培训，严禁往火锅里加冰块（发布新的SQL开发规范，要求开发人员不能写烂SQL）
“一口大锅”由于其划时代的革命性，马上在火锅业传开，Ivan也听到了这个方案，唠叨一下自己的看法。
首先来说“操作规范”
这家老店平常也很重视培训、整改，服务员也都是两年以上的老员工，之前已经对小胡们进行过多次培训。同类的培训和规范已经长期、反复推行，这次真能改掉小胡们的坏习惯吗？
对于IT系统，固然，人员基本技能是直接影响系统的交付和运维质量，如果同类的培训和规范已经长期、反复的推行，在培训者和受训方都没有更替的情况下，更加细致的规范能不能提升SQL质量？这项措施虽然是政治正确，但能达到什么样的效果，其实是还蛮可疑的。
如果是普通的大锅，服务员们都在同时操作，一旦有人加冰，所有食客都受到影响，不是更难发现那个惹得麻烦的小胡吗？如果能够把影响够隔离开就好了。
对一般的系统建设来说，仅靠细致的管理制度来强化人员的执行水平，其实是代价高、风险大的事情。而系统架构的设计，其实就是要在更高的层面通过优雅的架构设计规避这种风险。有位同业专家曾经讲过，“真正好的系统，是可以从架构设计上避免运维事件的发生”，其实说的就是这个道理。