MaxCompute最佳实践

                       从“步枪”到“机关枪”
                                ---不同体系数据仓库架构的心路思考
    步枪单打能力很强，远程射杀敌人，面对一对一或远程一对少均可应付，然而当敌人近身、面对多数时，步枪的威力远不如机关枪，近处大面积杀伤敌人远比步枪强很多。传统体系架构的数据仓库即关系型数据库加小机的体系架构犹如步枪，面对少量数据，后台小批量处理能力很强；但当面对大数据且要求处理提速时就不如分布式的MaxCompute了，尤其是面对海量数据（百TB以上），MaxCompute就犹如面对大量近敌的机关枪啦,机关枪单位时间内处理的子弹（数据）要比步枪多很多，处理效果明显得多。
   建设数据仓库或者说数据中心首要的是数据采集，即获取子弹，无论传统关系型数据库架构的数据仓库还是采用MaxCompute构建的数据仓库都需要特定规格的子弹，即数据都需要符合特定的格式，不能任意选取；如果工厂出产的弹药不符合规格，需要首先进行转换才能应用。如果用户突然手拿一些弹药（数据）要求直接压入弹仓，步枪反而灵活一些；最近笔者亲身经历客户手拿5G数据要求导入数据仓库，换做关系型数据库如Db2、Oracle应当是比较简单的事情，而MaxCompute需要将文件拆分成小文件，因每次上传是有大小要求的。
   海量数据加工处理当然是MaxCompute的优势，抗战电影中的歪把子机枪突突一分钟，消耗500多发子弹，步枪无论如何也达不到这个速度；当然用机枪点射不如步枪效果好。传统数据仓库数据加工一般采用多层次结构，目的是用空间换时间提升数据处理效率；而MaxCompute拥有强大的海量数据处理能力，但并不意味着不要层次，直接应用采集的原始数据无异于没有构建数据仓库，类似直接访问业务库的镜像、快照，犹如又回到了数据库系统的原始阶段，因此必要的分层加工还是必要的。例如本人遇到的一个业务系统是商品交易网站的后台数仓，从业务数据库同步而来的用户数据、商品销售数据、派送信息、库存信息，如果不进行必要的加工汇总，每次从这些离散的数据表提取信息显然是不可取的，不仅每次多表关联消耗资源而且难以保证数据结果的质量。
   诚然，面对海量数据的处理使用机关枪（MaxCompute）很爽、很痛快，不用担心数据处理能力不足的问题，再加上有专职的“机枪”维护人员，系统的维护也不用担心；完善的调度流程管理不用担心调度系统无缘无故的挂起；但同时也意味着失去了一些灵活性。做数据仓库系统久远了，面对的数据处理“五花八门”，尤其是“紧急情况下”的异常处理，如发现数据不正常，直接删除数据或是更新数据，MaxCompute是很不“配合”的，对于习惯关系型数据库操作的“资深人士”来说，是很不适应的；当然这样做的目的也是规范的一种，当不规范成为习惯且认为是理所当然时是非常遗憾的事儿。

MaxCompute尽管还有这样、那样的问题，还有这样、那样的不习惯，但面对当今的海量数据仓库的建设不乏是最优的选择之一，因为它的方便、因为它的易用、因为它的简单……

   数据仓库的建设伴随着MaxCompute走下去……