KAOS模型

问题描述：

我们开发了一种针对时序数据的文件格式TSFile，本身不支持sql查询。为了让公司分析人员能够用SQL进行分析，并且应用一些机器学习算法进行预测，需要设计并实现一个TSFile与SparkSQL 的连接器。在实现这个连接器之前，首先需要建立一个KAOS模型。来明确具体的需求。

目标模型：

需求说明文档

1. 引言

1.1目的

此文档定义了Spark-TSFile连接器的需求说明，包括功能性需求和非功能性需求。

文档的主要读者是开发人员、测试人员和分析人员。目的是使分析人员、软件开发人员、测试人员能够对此项目的需求有一个直观的理解，使之成为开发过程和使用的基础，并为开发过程提供需求说明。

1.2范围

本软件是一个连接器中间件，用来连接SparkSQL与TSFile，使公司的分析人员可以通过SparkSQL对TSFile中的数据进行查询，并且可以使用Spark中的机器学习算法进行分析预测。

使用此连接器，可以利用spark的并行计算优势，并行地处理TSFile，每个子任务处理一个partition。这样就可以用于工业生产。

1.3定义和缩写

Partition：每一个文件的分片，默认按照hdfs的block进行划分。

HDFS：Hadoop的分布式文件系统，将文件存储在多个节点上，逻辑上看起来像是一个文件系统。

Block：HDFS自动将文件切分成多个block。分布在不同节点。

SparkSQL：一个SQL on Hadoop系统，可以扩展外部数据源，作为其中的一张表，支持sql语法。

TSFile：时序数据文件格式，专门存储工业传感器数据。列式存储。、

RowGroup：TSFile中的数据块，每个RowGroup中只存储一个Deviceid。

QueryEngine：TSFile的读数据接口。一切与文件交互的方法都要通过QueryEngine。

Connector：特指本连接器。

time：时间戳。

delta_object：设备名。

1.4引用

An Architecture for Fast and General Data Processing on Large Clusters。

1.5概述

接下来本文档会介绍具体的需求，包括各种需求模型。

1. 综合描述

   2.1产品概述
   
   本连接器设计外部开发环境包括Hadoop和Spark，支持的操作系统为Unix。主要包括三个接口。第一个接口是向HDFS中传文件的接口。第二个接口是为sparkSQL提供schema的接口。第三个接口是为sparkSQL提供数据的接口。本连接器作为一个外部jar包添加进spark中，启动spark shell时添加就可使用。

   2.2产品功能
   
   本产品功能主要有三部分，第一个部分获取TSFile文件的Metadata，转化为一张关系型表交给sparkSQL。第二个部分读取TSFIle中的数据，转换成一定的格式交给sparkSQL。第三个部分为语法分析器，将sparkSQL接受的sql语句转换成TSFIle认识的SQL。

   2.3用户特征
   
   使用本产品的用户需要有一定的大数据背景、机器学习背景，要有SQL基础。

   2.4约束
   
   需运行在类unix系统上。
   
   在启动spark-shell时需要指定本jar包。
   
   创建表时需要指定一个hdfs路径，指定文件的存放位置，以map参数
   
   形式传入，key必须为“path”。

   2.5假设和依赖
   
   文件切分依赖默认的HDFS切分算法，无法自己控制。
   
   TSFile文件必须提前放在HDFS上。

   2.6需求分配
   
   未来的版本里，可能加上从Spark中写回TSFile文件，实现读写双向联通。
   
   在处理分区查询时，还可以进行查询优化，只请求此分区内的设备号。避免每次查询所有的设备，返回很多空的查询结果。
   
   还可以进行更高效的查询优化。目前由于TSFile本身的数据存储格式是列式存储，天生进行了很多优化，在以后添加join时可以考虑新的优化规则。

2. 具体需求

   3.1目标模型
   
   这部分包含了多个目标模型图，首先，系统需求包括功能性需求和非功能性需求。
   
   功能性需求包括支持SQL查询，支持机器学习算法。为了满足这个要求，需要设计一个连接器，将spark与tsfile相连接，利用spark的数据挖掘算法进行分析预测。
   
   其中支持SQL查询这部分，TSFile本身是文件，不支持sql语法，且数据是按列存储的。首先需要为数据建立一个展示的表结构。此处表结构设计为一下几个字段。
   
   time：时间戳，由于是时许数据，每个数据点都对应一个时间点。
   
   delta_object：设备id，允许传感器挂载到设备上。每个传感器都属于一个设备。
   
   s1，s2，s3...：代表传感器的值。
   
   由于只有文件读取接口，而读取接口需要指定时间和值得过滤条件，不支持delta_object过滤，这样就需要将这张表对应的SQL转化为文件查询引擎支持的查询配置。需要在connector中实现一个SQL语法解析器，将where后边的子句进行拆分，转化为析取范式拆分成多个互不相关的子查询。这部分包括生成查询计划，其中又包括逻辑查询计划和物理查询计划，逻辑查询计划和物理查询计划没有关系，物理查询计划需要访问文件获得一些数据的统计信息。根据分区信息将每个子查询翻译成文件支持的格式。

为了支持机器学习算法，需要将TSFile文件中的数据提供给sparkSQL，主要包括两个部分，提供表结构，提供数据。其中每个文件对应一种表结构，除了time与delta_object相同，其他列都是动态添加的。数据也按照表结构的格式提供给sparkSQL，一行一行提供。

支持分布式并发查询，开启分片功能，采用HDFS自动分片算法，按block大小进行切分。每个子任务处理一个文件分片，只读取对应分片中的数据。这样就实现了分布式数据导入。

一个系统构建简单与强鲁棒性，高可靠性是矛盾的。所以要在工程复杂度与系统性能之间平衡。

服务请求相应：前提条件是建立的表和查询的表是同一张表。分析人员会进行两种请求，建表请求和查询请求。建表请求发出后需要Connector提供表结构，查询请求发出后需要Connector提供数据。

服务请求：spark负责提供接口，获取表结构和获取数据的接口。Connector负责提供表结构和数据。分析人员来发出请求。

3.2责任模型
SparkSQL的责任模型：包括维护task状态DAG图，为分析人员提供shell用来输入命令。解析SQL语句，生成逻辑查询计划。读取TSFile中的文件。Master节点负责分发任务给worker节点，worker节点在获取数据后统一返回给master节点。当创建表时负责请求表结构，在查询数据时负责请求数据，都是拉去数据的模式。

3.3对象模型

TSFile对象模型：每个TSFile文件包括一个Metadata，记录了数据的组织结构和分布。每个文件包含多个RowGroup，每个RowGroup对应一个Device。每个文件对应一个QueryEngine，获取文件的数据和格式都要通过QueryEngine。

3.4操作过程模型
当创建表事件发生后，导致请求表结构执行，创建一个请求表结构的子任务，调用查询文件的metadata，将metadata作为输入交给scheam转换器，输出表结构交给spark。
当查询事件发生后，导致请求数据执行，创建多个请求数据的子任务，每个子任务请求一个分片的数据。调用查询数据的接口，将数据作为输入交给数据转换器，输出符合表结构的数据交个spark。

3.5潜在障碍
在并发读取数据时，单个节点在解析分片时有可能出现内存溢出，需要实现文件的分批读，每次读取一小部分数据。
每个子任务在查询分片数据时，有可能由于任务执行到一半失败，重启后导致数据读取重复。需要设计相应的预防算法。
在对SQL语句进行语法解析生成逻辑查询计划和物理查询计划时，还有很多优化规则没有添加。可能需要在以后实现。