【大数据之数据仓库】选型流水记

时间  2020-05-16
标签 大数据之数据仓库 选型 流水 繁體版
原文   原文链接

去年10月份放下了一手打造的缓存服务（NKV和NCR），投身到新成立的数据科学中心从事大数据存储相关的工做，新的部门、新的项目、新的知识，脚踏实地，从零开始。php

第一款调研的对象是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（ 附上异域猛禽彪悍的性能指标）。
这里提到的每一款产品、每个工具都是陌生的，须要重头开始学习摸索，基本上都是摸着石头过河。这是本系列第一篇，后续几篇以下：

本文来自网易云社区，经做者何李夫受权发布。html

原文地址：【大数据之数据仓库】选型流水记java

更多网易研发、产品、运营经验分享请访问网易云社区。 算法

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程