上篇文章也谈到BI报表查询，但更多在讲技术人员的价值观，有标题党的嫌疑。本文回归技术分析，题目有点小写意，套用一个火锅店的小故事，重点是MPP与分布式数据库存储上的一个差异点，希望能达到通俗易懂的效果。
数据时代，信息化成熟的企业通常建设了很多BI报表系统，每天各级管理人员根据报表的数据调整企业整体的经营决策和各项具体措施、行动。系统除了保证数据准确，受关注的就是查询的相应效率也就是延迟时间（Latency）。
BI系统为了提供用户需要的报表要做大量的ETL工作，通过预处理加工数据并存储下来，采用空间换时间的方式，提升用户与系统的交互速度。批量处理和联机查询如果在同一个数据库的同一时间段进行，会产生大量资源的竞争，由于批量加工是长任务，从目前的技术来说，是很难进行协调的。所以也会采用批量和联机进行物理分离的方式，来规避资源冲突。即使如此处理后，也会发生联机报表查询响应缓慢的问题。
本文提炼出一个简化的场景，关注对联机查询部分存在的问题，略去了批量部分。
很久之前，有一个的火锅店，顾客盈门，生意红火。涮火锅嘛，大家都知道的，首先是倒入锅底汤料，等汤烧开了，往里面放蔬菜、肉片、海鲜等各种食材，等食材熟了就可以吃了。从食材下锅到吃进嘴里，有个等待的过程，时间的长短取决于两个因素，一是火锅下面的炭是不是充足，火是不是烧得足够旺；二是食材一次不能放太多，特别是一些冷冻状态的食材，否则就会等比较长的时间。
对于BI系统来说，各种食材就是上游系统提供的数据，BI系统的工作就是加工数据并相应客户的查询请求，就是加热食材的过程。BI系统，或者说作为其核心的数据库，就是这个火锅，磁盘大小相当于锅的容量，CPU与内存相当于锅下面的炭火。
这家店比较特别的地方是为了凸显客户的尊贵，食材是由服务员负责放入锅中，食客只管吃。此外，火锅的管理模式是每桌的火锅由一个服务员负责全流程管理，包括火锅的清洗、上菜等等。
不同项目组负责集市的开发过程，运维环节也是由各自的管理员来负责，用户只是终报表的使用者。
在正常情况下，食材被放入火锅后5分钟就可以吃了，客户很满意。不知什么时候开始，情况了发生变化，食客等待的时间越拖越长。终于有一天，客人午餐点的火锅到了晚餐时间还没吃上，客人很恼火找到老板投诉。
业务用户反映报表查询的速度很慢，而且越来越慢，后忍无可忍。
老板找来大堂经理和大厨解决问题，经过各种跟踪、调研，大家终于发现了问题所在。原来向火锅中放食材的时候，有个服务员会往里面加冰块，我们觉得他有点糊涂，叫他小胡吧。小胡不是一个人在战斗，店里的服务员不少都是小胡的同乡，也有这个习惯。显然，冰块会延缓食物的受热过程，所以小胡们服务的客人都要多等很久才能吃到食物，导致了客人的投诉。
对于BI系统来说，延迟缓慢的一个主要原因是SQL写得不合理，导致查询效率很低，也就是我们说的烂SQL，就像小胡加的冰块，无谓消耗了很多系统资源。
正好，老板觉得多个火锅也有问题，每个火锅的清理都是由不同的服务员负责，管理起来也费劲，是不是可以搞一个大火锅，顺便解决管理的问题。
靠技术来带动管理，是不是佳方式 Ivan是有些存疑的，但有时确实有这样的效果。
大厨针对“小胡加冰”问题和老板的管理需求，提出了解决方案，代号“一口大锅”。方案包括两部分，一是换口火力猛的大锅，二是对小胡们进行培训。
具体来说，首先需要一口大火锅（某款MPP数据库）替代现在每桌使用的普通火锅（单机数据库），但要具备两个条件。一是大锅的火力够猛，造价低，实在不够用还可以扩展（基于X86服务器，可水平扩展）；二是后厨团队掌握相应的使用技巧（因为批量加工上已经使用了这种技术，团队对这种技术比较熟悉）。大厨选定的这款大锅是九宫格火锅，每桌食客用一个格子，体验基本是不受影响的。（这个地方不要较真哈^Q^）（项目开发团队和用户都是面对逻辑上独立的数据集市；同时，MPP数据库具备一定的工作负载管理能力。）同时，再出台新的操作规范，针对小胡和他的同乡们进行培训，严禁往火锅里加冰块（发布新的SQL开发规范，要求开发人员不能写烂SQL）
“一口大锅”由于其划时代的革命性，马上在火锅业传开，Ivan也听到了这个方案，唠叨一下自己的看法。
首先来说“操作规范”
这家老店平常也很重视培训、整改，服务员也都是两年以上的老员工，之前已经对小胡们进行过多次培训。同类的培训和规范已经长期、反复推行，这次真能改掉小胡们的坏习惯吗？
对于IT系统，固然，人员基本技能是直接影响系统的交付和运维质量，如果同类的培训和规范已经长期、反复的推行，在培训者和受训方都没有更替的情况下，更加细致的规范能不能提升SQL质量？这项措施虽然是政治正确，但能达到什么样的效果，其实是还蛮可疑的。
如果是普通的大锅，服务员们都在同时操作，一旦有人加冰，所有食客都受到影响，不是更难发现那个惹得麻烦的小胡吗？如果能够把影响够隔离开就好了。
对一般的系统建设来说，仅靠细致的管理制度来强化人员的执行水平，其实是代价高、风险大的事情。而系统架构的设计，其实就是要在更高的层面通过优雅的架构设计规避这种风险。有位同业专家曾经讲过，“真正好的系统，是可以从架构设计上避免运维事件的发生”，其实说的就是这个道理。
银行业监管机构定义了一些系列运维事件定义，用于监督银行的IT系统安全运营。
例如，一级事件：由于重要信息系统服务异常、在业务服务时段导致两个（含）以上省（自治区、直辖市）所有分支行业务无法正常开展达3个小时（含）以上，或一个省（自治区、直辖市）所有分支行业务无法正常开展达6个小时（含）以上的事件定为特别重大突发事件
所以Ivan认为，培训是必要的，但系统的稳健运行不能过分依赖执行层面的因素。
再来说“大锅的构造”
MPP数据库这口大锅能够解决隔离问题吗？Ivan觉得可能还是要商榷的。很多MPP数据库都会遵从的一个基本原则，就是将数据打散平均分配在所有数据节点上。例如一张表有10亿条记录，MPP集群有10个节点，则每个节点会平均存储1亿条记录。对这张表的查询会推送到每个节点上，而后汇总结果返回给数据库的调用方。这样，如果存在一个烂SQL，实际上会拖慢所有节点的速度，只不过当MPP集群足够大的时候，可以更快的执行完这个烂SQL。
处理不同任务间的资源竞争问题，就要谈到“工作负载管理”功能。简单来说，工作负载管理就是对不同的工作任务所需要的资源进行细化分配，来大致锁定任务间对资源的占用，不会抢占资源，导致某些任务受到影响，甚至被饿死的情况。这里的资源包括CPU、内存和磁盘I/O，其中磁盘I/O因为其由于其物理寻道方式，往往很难进行划分管理的。由于上述MPP架构的特点，数据集市合并到一个物理集群后，数据会被平均分配到每个节点，磁盘I/O的竞争可能会加剧，给“工作负载管理”制造更大的难题。所以说，MPP大锅的隔离性可能还不够。
对于“小胡加冰”问题，如果无法做好工作负载管理，就只能通过增加火力的方式，是一种粗放的、资源堆积的方式，不值得提倡。即使有再大的锅，假如某天小胡发烧，加了整桶的冰块，所有食客还是没得吃，潜在的操作风险还是太大。
有更好的大锅吗？
看到这里，大家可能会有自己的答案，Ivan认为更好的方案应该是云数据库或者是可以云化的分布式数据库。
分布式数据库与MPP一个很大的区别在于数据的存储规则上。前者往往不是平均分配，而是将有限的数据副本（通常是3副本）存储在集群中的几个节点上，而这些存储节点可以通过一定的管理策略来约束范围的。这样，至少在系统层面将I/O的竞争区隔开。也就是说，不管小胡加了多少冰，如果只影响到他自己服务的食客，那风险就被能控制在有限范围内。
当然，除了强大的工作负载管理能力，系统的高可用性也很重要，任何系统的集中都会伴随着风险的集中，抛开系统内部设计不说，这种逻辑层面上的单点依赖往往是管理者有所顾虑的，是需要慎重对待的。本文所论述的MPP数据库本身通常有成熟的高可用方案，并没有作为本文的讨论重点，故略过。
说回火锅，伴随着湿热和汗水的夏天就要过去了，吃火锅的季节还远吗？Ivan去过的店，真有不让客户自己放食材的，但具备“工作负载管理”能力的大锅还没碰到，没准有一天真会出现呢。
