如何进行TPS-DS测试
1 简介
随着开源Hapdoop、Map/Reduce、Spark、HDFS、HBASE等技术的商用化，大数据管理技术得到了突飞猛进的发展。如何客观地比较不同数据管理系统，即大数据测试基准的选择，成为一个重要的研究课题。
事务性能管理委员会(TransactionProcessing Performance Council,TPC)，是目前最知名的非赢利的数据管理系统评测基准标准化组织。它定义了多组标准测试集用于客观地、可重现地评测数据库的性能。在过去二十多年间，该机构发布了多款数据库评测基准，如TPC-A、TPC-D、TPC-H和TPC-DS。其中的DecisionSupport（DS）子集，即TPC-DS，是用于评测决策支持系统（或数据仓库）的标准SQL测试集。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
TPC是由十几家服务器厂商组成的（华为是该组织唯一一个中国公司）参与参与制定商务应用基准程序（Benchmark）的标准规范、性能和价格度量，并管理测试结果的发布。TPC Benchmark测试结果是服务器类设备性能拼比核心技术指标。
2 TPC-DS简介
TPC-DS测试基准是TPC组织推出的用于替代TPC-H的下一代决策支持系统测试基准。因此在讨论TPC-DS之前，先介绍一下TPC-H。
2.1 TPC-H
TPC-H是一款面向商品零售业的决策支持系统测试基准，它定义了8张表，22个查询，遵循SQL92。TPC-H基准的数据库模式遵循第三范式，叶晓俊教授等学者认为“它的数据表数据特征单一(如数据不倾斜) ，其数据维护功能仅仅限制了潜在的对索引的过度使用，而没有测试DBMS 执行真实数据维护操作——数据提取、转换和加载(ETL) 功能的能力”。同时，新兴的数据仓库开始采用新的模型，如星型模型、雪花模型。TPC-H已经不能精准反映当今数据库系统的真实性能。为此，TPC组织推出了新一代的面向决策应用的TPC-DS 基准。
2.2 TPC-DS
TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表，17张纬度表平均每张表含有18列。其工作负载包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
TPC-DS的这个特点跟大数据的分析挖掘应用非常类似。Hadoop等大数据分析技术也是对海量数据进行大规模的数据分析和深度挖掘，也包含交互式联机查询和统计报表类应用，同时大数据的数据质量也较低，数据分布是真实而不均匀的。因此TPC-DS成为客观衡量多个不同Hadoop版本以及SQL on Hadoop技术的最佳测试集。这个基准测试有以下几个主要特点：
l 一共99个测试案例，遵循SQL’99和SQL 2003的语法标准，SQL案例比较复杂；
l 分析的数据量大，并且测试案例是在回答真实的商业问题；
l 测试案例中包含各种业务模型(如分析报告型，迭代式的联机分析型，数据挖掘型等)；
l 几乎所有的测试案例都有很高的IO负载和CPU计算需求。
叶晓俊等学者对这些查询的分部总结如表1所示。
这个基准测试的完整信息请参考http://www.tpc.org/tpcds/。
3 TPC-DS测试
TPC-DS测试主要步骤为环境准备、SQL语句兼容性测试以及语句修改、TPC-DS测试和测试结果整理四个部分，其中SQL语句兼容性测试将在1GB数据量使用虚拟机建立集群的条件下进行， TPC-DS测试在500GB数据量下进行。
3.1 环境准备
3.1.1 本地配置
由于TPC-DS进行对性能上的测试，测试环境应为干净的环境。
为确保操作系统干净，可重做raid，再通过《使用iLO口安装操作系统》等将操作系统安装完成，最后依据所需环境，通过《物理机上的Ambari和HDP集群安装手册》或是《物理机上的Cloudera Manager和CDH集群安装》（暂未完成）等安装手册完成测试集群的安装，最后，将集群配置改为测试配置，并对测试配置进行记录。
3.1.2 TPC资源
这个部分主要介绍如何从TPC上获得测试所需资源，入1GB数据、500GB数据的生成，建表语句和sql语句的生成等等。
1、 官网下载tpc-ds压缩包
网址：http://www.tpc.org/information/current_specifications.asp
2、 在linux下解压缩（Windows暂不做介绍）：
[root@node1tpc]# unzipDSTools.zip
3、 在tools文件中执行make
[root@node1tpc]# cd /TPCDSVersion1.3.1/tools
[root@node1 tools]# make
注意：若没有安装gcc会报错！
4、 在tools目录下使用./dsdgen生成数据。
–help查看帮助
常用：
-DIR 生成目录
-SCALE 数据大小（单位GB）
-
DELIMITER 字段分隔符，默认|
-
TERMINATE 末尾是否有分隔符，参数 Y或者N
例子：在/usr/datas目录下生成分隔符为|且末尾没有分隔符的1GB数据：
./dsdgen -DIR /usr/datas -SCALE 1 -TERMINATEN
这样就可以分别生成测试所需的1GB数据和500GB，数据生成的25张表如下，这就是上述描述的7张事实表，17张纬度表，以及1张版本表dbgen_version.dat。
5、 ./dsqgen生成sql测试用例
–help 查看帮助
常用：
-input 输入，读取测试用例包含的模板，一般使用/query_templates/templates.lst即可。
-directory 模板所在目录， 一般使用-directory…/query_templates即可。
-dialect 生成某个数据库的语言，可选项可以查看/query_templates目录，有oracle、db2、SqlServer等。
-scale 数据大小（单位G）
特别说明：/query_templates目录下的每一个query末尾都要加上：
define _END = “”;
ftp上有弄好了的，可以拿来覆盖：\100.0.1.1\admin\soft\tpc\query_templates
例子：./dsqgen -input…/query_templates/templates.lst -directory …/query_templates -dialect oracle-scale 1
由此，可以在tools目录下生成一个query_0.sql，即为生成的sql测试用例。
6、 建表语句
/TPCDSVersion1.3.1/tools目录下，tpcds.sql文件里。很多数据平台可能不能直接使用，需要修改。建表语句的修改主要是依据不同环境支持的数据类型修改和一些基础语法修正，还需依照生成的数据的分割符在建表时指定分隔符。
以hive为例：integer改为int，time改为timestamp，去掉NOT NULL，删除primary key，指定分隔符row format delimited fieldsterminated by ‘|’;等等。
7、 测试用例结果
在目录/TPCDSVersion1.3.1/answer_sets下。
3.2 SQL语句兼容性测试以及语句修改
3.2.1 SQL语句兼容性测试
在测试前最好能进行一次99条语句的格式整理，这是有必要的，原因是获取的脚本中可能含有制表符，当复制这些语句执行或是直接执行脚本时会产生意料之外的错误。
完成database的建立，进入这个database进行建表操作。注意，如果不建立新的数据库，操作将在default数据库中进行。
之后可以在少量数据（1GB）条件下，遍历进行SQL语句的支持情况测试（这个测试可以在虚拟机中完成，因为本测试仅测试兼容性，对测试性能要求较低）。
首先，将本地数据load到刚才建立好的表中，如：
Load完成后，检查各表数据是否完整，这之后开始SQL兼容性测试。主要测试方法是，先遍历执行各个测试案例，如果SQL语句能执行完成，进行可完成的记录；若不能完成，则将系统报错记录，直至所有语句测试完成。
3.2.2 语句修改
通过上阶段的兼容性测试后，可将无法完成SQL的语句的报错进行汇总，将问题分别归类，同类问题一起修改。
修改时必须遵守不改变原语句查询内容、原语句使用的基础逻辑的原则，在遵循这个原则的条件下进行小规模的调整，如：不改变数值的数据类型调整、增加别名、在用做比较的查询后加limit 1等。最好能在修改时将大致的修改方法记录，这样不仅有利于在其他语句遇到同样问题时候的修改，也为之后统计测试结果提供便利。
于此同时，记录无法支持的语句情况，如：rollup、intersect等。再遇到同类问题时可以快速参照之前的处理方式进行修改或是直接跳过。
每修改一次语句都需要对修改后的语句进行测试，这部分测试，为了效率的保证，也是在少量数据（1GB）的条件下进行测试的。在测试中可能会出现别的错误，这时需要立刻着手解决这个问题。
3.3 TPC-DS测试
在完成SQL语句兼容性测试后，将可运行的语句汇总，编写在一个脚本中。在测试环境中重复上述建表和load过程，500GB数据的导入完成后，执行这个脚本，实现TPC-DS测试。这样做的主要原因是，这些SQL案例测试时间较长，可能需要通过利用夜间时间进行不断电测试，否则，也可以采用如同兼容性测试同样的方法，一条一条进行测试。
在执行load以及SQL语句时，需要将log保留，以hive中执行SQL语句为例，首先切换至root用户，新建一个log文档并改变它的读写权限，然后执行脚本：
也可在配置中改变hdfs-site的权限，将dfs.permissions.enabled改为false，然后使用root用户执行脚本。
若想知道语句的执行情况，可以通过cat语句查询log，在脚本出错时需及时停止执行，导出log，分析出错原因，重新执行或是执行下一条语句。
将所有语句执行完成后，将log导出，进行下一步处理。
3.4 测试结果整理
本测试主要关心的因素有：
-
SQL语句的支持情况； -
修改后支持的SQL语句的修改情况； -
可完成查询的语句的时间使用情况（这代表着性能的优劣）； -
查询结果的准确性；
针对上述几种因素，依照测试具体需求，进行分析处理：
1.对于SQL语句支持情况来说，主要通过能通过SQL兼容性测试的语句个数来判别；
2.修改内容可以通过文本比较软件，如Beyond Compare将修改后的sql与生成的query_0.sql进行比较，将修改内容以及不支持的语句情况进行整理统计；
3.将log中的各个平台的SQL执行时间数据制成表格，由此可直观的对比各个平台性能的优劣；
4.要了解具体支持程度，还可以进一步将测试结果正确与否、出错原因进行比对。