【大数据之数据仓库】选型流水记
去年10月份放下了一手打造的缓存服务（NKV和NCR），投身到新成立的数据科学中心从事大数据存储相关的工作，新的部门、新的项目、新的知识，脚踏实地，从零开始。
第一款调研的对象是cloudera公司刚开源的kudu产品，可以将其理解为是hadoop系统中的hdfs，一个存储引擎，但是和hdfs的不同之处是它支持update操作，这点非常重要！
可能是因为刚开源的缘故，文档中很多的的使用方式、操作步骤的描述都和cloudera manager（简称CM）紧紧的耦合在一起，所以一开始的时候，根本不清楚怎样独立部署kudu集群以及怎样是最佳部署方式。无奈，只好先从cloudera manager管理平台安装部署，然后等到熟悉以后再将其剥离出来，事实上后来剥离的kudu和impala的配置文件的配置参数就直接参考这里的。部署CM&CDH就花了九牛二虎之力，过程就不再细说，都是泪。
就像高富帅择偶一样，大公司cloudera出来的产品，对操作系统也是百般的挑剔，又要有绝对的话语权（root权限），所以一周又一周的要求sa帮忙续命（骚瑞啊，真的不是在耍你们，向sa们致以诚挚的敬意）。成功完成集群安装部署，面临着怎么来测试，用什么工具的尴尬，大家都没经验。
一开始，我们选择了ycsb来进行测试，有两种方式：一种是通过JDBC驱动的方式，另一种是通过kudu bind的方式。前者测试并定位了几天才发现是驱动的问题，无法解决只好作罢；而后者，基本的load/insert/read/update都能正确执行，但唯独scan一直有异常，网络流量、资源消耗都不太正常，如果没有仔细监控则很容易被忽略（scan指标很好），翻了所有的公开资料、搜索了kudu的jira库、联系了国内唯一的kudu committer，依然无果，偶然收到todd（kudu负责人）的回复邮件，说是kudu客户端java驱动包本身缺陷导致，好吧，kudu的scan性能指标缺失。详情请参考：《 【大数据之数据仓库】kudu客户端java驱动缺陷》。这里同时附上 加速kudu insert性能的博文以飨各位大拿！
这个时候，我们开始转向tpcds，因为我们急切的关注kudu对于sql的覆盖率问题。但是，网上搜索了一圈，没有一个项目或者博文有介绍如何使用tpcds测试kudu或者impala的性能指标（这里为什么引出了impala？因为kudu本身只是一个存储引擎，而impala是其最佳配套的计算引擎，没有计算引擎无法谈sql覆盖率）。还好，有一根救命稻草impala-tpcds-kit，这是cloudera公司开源的用于测试impala on hdfs（parquet）的测试工具，但是，它只包含了10张表（tpcds总共有24张表），也仅仅测试了19个query（tpcds总共有99个query）。这里可以分为前后两个阶段：前一个阶段是直接跑这19个query，分别在6台机器和20台机器两个不同的集群上以不同的参数配置（调整kudu和impala的参数）、在不同的数据集下（1T、3T、10T），对比测试parquet和kudu的指标；后一个阶段则是重新测试，补充上剩余的14张表，以及重写自动化测试的脚本，重新分别在6台机器和20台机器两个不同的集群上在不同的数据集下（1T、10T），对比测试parquet和kudu的指标。load数据的过程实在太漫长了，以至于测试10T数据集的时候，一轮就得花一个礼拜，都是insert into xxx select * from yyy惹的祸，几轮测试下来的耗时可想而知，有更好的办法么？
测试结果：sql覆盖率上，因为都是impala计算引擎（kudu pk parquet），所以两者都一样，但是性能指标上，kudu的指标比parquet明显差很多！为什么kudu性能指标这么差？对一个不了解的系统或者说暂时还不能hold住的系统，分析其性能指标差的原因，个人觉得有难度，而且还涉及到两套大系统impala和kudu！各位扪心自问，换作是你，你会怎么来分析？没有对比就没有伤害，花了好几天时间在这个问题上，中间省略三万字，无意中使用了beyond compare工具对parquet和kudu的执行结果profile进行了逐行比对，终于发现了问题所在：kudu支持有限的谓词下推功能（runtime filter） ！详情请参考：《 【大数据之数据仓库】kudu性能测试报告分析》。
对比意味着进步、对比意味着收获！调研到这里，已经获得了一手测试结果，并且发现了两个大问题：一个是kudu的客户端java驱动包scan存在缺陷，而测试impala过程中没有被影响到是因为impala采用的是C++的驱动，理论上这个缺陷影响不大，因为基本上不会有用户直接拿kudu的java驱动来接入；另一个是kudu的谓词下推功能不完善，不支持runtime filter，导致query性能比较弱，这个就让人难以接受了。
第二款调研的对象是pivotal公司的greenplum产品，有别于上面cloudera公司的impala和kudu，它是血统纯正的MPP架构的数据库，2015年10月开源，你可以简单的把它理解为一个数据库。从一开始大家对greenplum是持排斥态度的，认为它的存储和计算合体不符合潮流、认为它的扩展性有问题、认为它只支持P级规模的数据集，但事实上，国内已经有很多大公司采购它来建设自己的数据仓库，度娘下能找到一大堆，隔壁厂（阿里云）的 ApsaraDB HybridDB就是基于greenplum，另外云巨头Amazon在2013年上市的 redshift采用的是基于postgresql的类似greenplum的架构实现（谁让greenplum2015年才开源）、惠普基于DBMS架构的 【 大数据之数据仓库】基准测试之TPCDS》。
第三款、第四款 ... ... 这里不再一一介绍了，这里埋个雷，大伙儿知道为啥没有选择 HAWQ么？请参考《 【大数据之数据仓库】HAWQ versus GreenPlum》
文章看到这里，你一定以为是差不多要收尾了，因为测试结果已经出来了！NO NO NO！一开始面临测试工具尴尬的时候，我们发现好多博文中提到大数据基准测试是用tpch做的，那tpch和tpcds的差异在哪里呢？有说是tpcds的sql包含了过多的聚合和关联操作，说实话我不是很清楚，但我确定的是：tpcds的sql比tpch的复杂，业界貌似除了greenplum没有哪个产品敢拍胸脯成功闯关99个sql的。于是，我又愉快的用tpch从头到尾对kudu、parquet和greenplum做了对比测试，当然，所有的测试脚本都是重新写的，不过有了前面测试tpcds的经验，测试tpch就顺利多了，基本上没有遇到坑。详情请参考：《 【大数据之数据仓库】基准测试之TPCH》。
数据仓库产品：通用性好（高sql覆盖率），必定是MPP架构的精品数据库；而通用性一般的，有应用场景倾斜，可以认为是定制化产品，比如parquet/carbon data/clickhouse（ 附上异域猛禽彪悍的性能指标）。
这里提到的每一款产品、每一个工具都是陌生的，需要重头开始学习摸索，基本上都是摸着石头过河。这是本系列第一篇，后续几篇如下：
本文来自网易云社区，经作者何李夫授权发布。
原文地址：【大数据之数据仓库】选型流水记
更多网易研发、产品、运营经验分享请访问网易云社区。
