TPC-DS是一套决策支持系统测试基准，主要针对零售行业。提供99个SQL查询（SQL99或2003），分析数据量大，测试数据与实际商业数据高度相似，同时具有各种业务模型（分析报告型，数据挖掘型等等）。国内目前相关的翻译文章较少。本文尝试对官网的TPC BENCHMARK DS Standard Specification（下称“原文”）进行翻译。翻译主要参照的是2017年发布的2.6.0版本。
由于原文一共137页，本文在翻译的时候会进行一定的压缩，突出较为关键的信息。本文章节名称，序号，小标题等均严格按照原文翻译排序。
0 前言
0.1 简介
TPC-DS是一个面向决策支持系统(decision support system)的包含多维度常规应用模型的决策支持基准，包括查询(queries)与数据维护。此基准对被测系统(System Under Test's, SUT)在决策支持系统层面上的表现进行的评估具有代表性。
此基准体现决策支持系统以下特性：
1. 测试大规模数据
2. 对实际商业问题进行解答
3. 执行需求多样或复杂的查询（如临时查询，报告，迭代OLAP，数据挖掘）
4. 以高CPU和IO负载为特征
5. 通过数据库维护对OLTP数据库资源进行周期同步
6. 解决大数据问题，如关系型数据库(RDBMS)，或基于Hadoop/Spark的系统
基准结果用来测量，较为复杂的多用户决策中，单一用户模型下的查询响应时间，多用户模型下的查询吞吐量，以及数据维护表现。
0.2 实现TPC基准的通用指导
TPC希望为企业用户提供中肯、客观的表现数据。为此，TPC规范需要基准测试满足：
a) 对使用者而言具有通用性
b) 用户可以个性化的对市场建模
c) 高度仿真市场用户
因此，TPC必须基于商务数据处理软件，并通过SQL执行查询。需要注意的是，TPC基准的使用必须针对于真实商务情景。任何基于TPC基准自建的基准，如果不考虑现实情况，都是不被允许的“特殊基准(special benchmark)”。
对于任何一款基于TPC基准的企业自建基准而言，许多方面都可以用来评价其是否成为了不符合TPC要求的“特殊基准”。我们无需验证这一自建基准的全部方面，只要保证有足够多的或足够重要的性质证明其满足特殊基准测试即可。可以通过以下几方面来评判：
a) 是否具有通用性，可被文档化，以及可被支持？
b) 是否存在使用性或适用性上的某种限制，使得其无法完成TPC测试基准？
c) 该基准自身或其部分是否难以被集成到更大的产品中？
d) 该基准是否特别利用了TPC基准的有限性质（例如：查询、模板、查询组合、并发和/或争用等）进行改动，而这种改动通常不适用于基准所代表的环境。
e) 该基准的应用是否不利于供应商的使用？（这包括未能在其他产品和技术中迁移类似的基准）。
f) 该基准是否要求终端用户、程序员或系统管理员的使用水平格外的好？
g) 定价是否对于供应商或与其他商业案例比较而言不符合惯例？下列定价做法是可疑的：
1. 一小部分潜在客户可以获得折扣；
2. 以不寻常的方式记录折扣；
3. 小批量交易折扣达到25%，或大批量达到50%；
4. 进行一次性定价；
5. 对折扣产品的产品、担保或维修的可转让性存在非常规限制。
h) 该基准是否被购买或使用于基准测试所针对的市场部分（包括beta发布组件）？有多少机构实现了它？有多少终端用户从中受益？如果目前尚未购买或使用，是否有任何证据表明它将被大量终端用户购买或使用？
0.3 结果评价通用指导
TPC测试结果应该能够准确评判系统表现。因此，评价这些结果时，需要遵循一些特定指导。其方式方法均被清楚地写在原文中，或是正在被官方慎重考虑。标准规范中没有表述的评测方法，使用时必须满足：
a) 该方法为工程中公认堪用的实例或标准
b) 该方法对测试结果不会造成提升
c) 用于该方法中的设备，均基于现有质量标准进行校准
d) 公正坦率的公布结果中的一切异常，即使该异常并非原TPC测试基准中的测试内容
0.4 工作独立性
TPC-DS所使用的术语及度量标准与其他TPC系基准类似，但这并不意味着TPC-DS的结果可以与其他基准进行比较。唯一可以与之比较的只有其他遵循相同版本及测量因子的TPC-DS的结果。本基准不能反映一款决策支持系统的全部方面的表现。TPC-DS的表现很大程度上也是依赖于TPC-DS与消费者应用的契合度。基准结果高度依赖工作量，规范需求以及系统设计与实现。这也使得相关系统表现较为多样。基准的设计与实现具有一定的自由度，但是必须满足规范中的要求。
0.5 相关材料
TPC-DS同时依赖一些电子材料。因此在文档中无法直接体现。附录F中将会详细讲述电子材料遵循的版本及规范。下表为明细：
0.5.1 价格请访问 http://www.tpc.org
1 商业情景与基准模型
1.1 概述
TPC-DS所包含的各个部分在技术严格的，以及供应商中立(vendor-neutral)的方式中，仍然可以被广泛用于系统拓扑(system topologies)及实现，同时可以被直接比较。为了方便新接触TPC-DS的人使用，TPC-DS被设计在典型的商业情景中，本章节将对商业模型及模型对本基准的影响进行介绍。
TPC-DS的模型主要针对零售产品供应商的决策支持系统。提供的支持包括诸多关键的商业信息，比如消费者，订单，以及产品的相关数据。最关键的两个部分为：
1. 查询。这些查询可将数据转化为商业信息
2. 数据维护。可以在管理分析过程中同步外部可用数据
基准抽象出信息分析程序中发现的多样性操作，同时保留了基本的性能特征。由于查询及数据转换数量巨大，因此没有一款基准可以模仿一个特定商业环境并且保持很好的泛用性。TPC-DS的目的是模仿现实中，多渠道零售商(multi-channel retailer)的行为。TPC-DS并不仅仅局限于零售行业数据，并且需要周期性更新数据。随着时间的累积，这些数据可以表征该时段内的业务操作。一些基准对真实商务环境下的操作进行建模，并且操作均基于事实数据执行。另一些则解决了更为基础，静态的决策支持系统的测试问题。TPC-DS同时模拟了真实商务中进行决策支持时面临的困难，既包括基于眼前实时数据的短期市场决策，也包括企业的长远规划。
1.2 商业模型
TPC-DS对任何需要管理，销售，以及分销产品的行业进行建模（比如食品，家具，玩具）。它利用了在国内多地有店的大型零售商作为模型。这些零售商除了实体销售还有电商运营。它包括了一个简单的库存系统(inventory system)与提升系统(promotion system)，用表对关联销售与收益建模。这些零售企业可能需要的商务操作有：
1. 从每条销路记录顾客的购买（并追踪其退货）
2. 修改促销价格
3. 保持仓库库存
4. 生成动态网页
5. 维护顾客信息（顾客关系管理）
TPC-DS对操作系统并不限制，它已经考虑到渠道子系统被设计的各不相同，并且在各种硬件上被执行的情况。TPC-DS将商业环境的模型分为三大类：
1. 数据模型与数据访问假设
2. 查询与使用者模型假设
3. 数据维护假设
1.3 数据模型与数据访问假设
1.3.1 TPC-DS模型系统允许可能长时间运行的多部分的查询，任何特定时期，DBA都可以假设数据处理系统是静态的。
1.3.2 TPC-DS数据通过数据维护方法追踪可操作数据库的状态（可能伴随延迟）。
1.3.3 TPC-DS schema是一个雪花型schema，由多个维度表(dimension)与事实表(fact)组成。每个维度表有一个单一的列代表key。事实表可以依托该key进行跨表。维度表可以被分为：
1. 静态型(Static)：指的是当数据库load时，该维度表的内容可以被直接加载并且不会产生时间上的影响。日期维度表(date dimension)就是静态型维度表的一种。
2. 历史型(Historical)：指的是对维度数据的历史改变进行维护，而不是在更新过程中直接进行覆盖。通过为单个业务键值创建多个行，来维护维度数据更改的历史记录。每行都有一列是用来标注该行时效周期(time period)的。事实表与历史型维度表的每一次历史值都有时间关联，从而对事实及记录时间保真。项目表(item)就是历史型维度表的一种。
3. 非历史型(Non-Historical)：在非历史型维度表中，维度数据的历史更改将不被维护，因此随着维度表的值不断更新，先前的值将不断丢失，因此事实表中的数据仅关联非历史型维度表的最新值。客户表(customer)就是非历史型维度表的例子。
1.3.4 系统管理员可以一次性地设置查询和数据维护功能的锁定级别和并发调度规则。
1.3.5 TPC-DS基准测试将模拟几种不同大小的DSS（a.k.a.基准缩放或标度因子）。
1.4 查询与用户模型假设
TPC-DS对于使用者及涉及到的查询主要基于以下特征进行建模：
a) 需要解决复杂的业务问题
b) 使用多样的访问模式(access pattern)，查询，操作符(operators)以及结果集约束条件(answer set constraints)
c) 需要调用不同几次查询中的参数
因此，TPC-DS使用了通用查询模型(generalized query model)，以此满足OLAP查询的交互与迭代性质，数据挖掘等需要长时间运行的复杂查询，以及计划行为(planned behavior)等多方需求。
1.4.1 查询类型
基准中，各种查询（尤其是临时查询和报告查询）被合并为一类，临时查询的工作负载环境被模拟为，用户连接到系统后，发送一个随意的查询。因此数据库管理员(DBA)不能专门为该特定查询优化系统，查询时间也会较长。而报告查询相对可预测，数据库管理员也可以通过分区、聚类、索引等方法对执行时间进行优化。长久以来，在各种基准中，合并这两种类型的查询都是很困难的。因为除了绑定了变量之外，基准中的所有查询都是事先已知的。TPC-DS中，schema被分为了临时查询部分与报告查询部分，为它们各自生成查询集。TPC-DS定义了四个查询类型：
1. 报告查询
2. 临时查询
3. 迭代OLAP查询
4. 数据挖掘查询
TPC-DS测试基准中提供了各种查询对上述四种查询类型进行了模拟。
1.4.2 报告查询
报告查询记录了DSS系统的报告。关于业务的财务和运营的健康状况，可以通过周期性的执行这些查询来监测。虽然报告查询的内容相对稳定，但是依旧可以对其进行微调。比如每次查询之间，可以更改一下日期范围，或者地理位置等等。
1.4.3 临时查询
临时查询则是反映了DSS系统的动态特性，这些查询往往是用来解决一些实时的具体问题。临时查询与报告查询的核心区别就是系统管理员很难对临时查询做出较为有效的预判。
1.4.4 迭代OLAP查询
OLAP查询侧重于分析业务数据，从而发现一些有意义的商业信息。虽然这类查询类似于临时查询，但可以基于查询所处的场景和会话进行区分。
1.4.5 数据挖掘查询
数据挖掘基于大量数据为企业的行为提供建议，对未来的趋势进行预测，是企业可以更好地作出决策。这类查询通常伴随大量的跨表、聚合，并返回大数据结果集。
1.5 数据维护
数据仓库需要最新的数据，因此需要将数据从OLTP系统迁移到DSS。之前的基准评估侧重于DSS的分析组件，但是不包含实际数据的更新过程。相比之下，TPC-DS的评估更为全面。决策支持数据库的更新过程通常包括ETL三个步骤：
1. 数据提取(Data Extraction)：俗称E步。这一步骤指，从OLTP及相关数据库的源数据中精准提取出数据。提取步骤可以包括大量针对OLTP及辅助数据源的独立提取操作。E步在基准中并没有进行建模。TPC-DS的数据维护过程一般以生成flat files为起始，flat files就是外部数据提取之后的结果。
2. 数据转换(Data Transformation)：俗称T步。这一步骤指的是降提取出来的数据进行清洗、整理后，同化成为适合该决策支持数据库的数据格式。
3. 数据加载(Data Load)：俗称L步。这一步是将转换后的数据在决策支持数据库中进行插入，修改和删除。
TPC-DS中，T和L两步的建模也被称为数据维护(Data Maintenance, DM)或数据刷新(Data Refresh)。
基于Figure 1.2展示的商业环境，TPC-DS的DM过程主要解决以下任务：
i)将发往数据仓库的新数据以及被删除或改动的数据进行更新加载。这些数据都是完成过T步的数据。
ii)将更新的数据加载到数据仓库进行数据转换，比如：
1. 数据反归一化(data denormalization)处理（由第三范式到雪花型）。这一步源表将基于以下方式被映射到数据仓库中：
a. 直接将源表映射到目标表中（一对一映射）。此类映射最为常见，适用于在operational schema中具有等价表的数据仓库中的表。
b. 多数据仓库源表进行连接，最终结果被映射到一个目标表中（多对一映射）。这类映射可以完成由operational schema的第三范式到数据仓库中非归一化(de-normalized)形式的转换。
c. 单一源表映射到多个目标表中（一对多映射）。相当不常见，如果发生，则操作系统schema的归一性若雨数据仓库中的schema。
2. 同步清洗数据。
3. 反归一化(de-normalize)。
iii)基于日期插入新的事实记录，删除旧的。
附录A中，有flat files和ddl的结构关系。
