通过大数据分析与Spark构建企业级大数据平台
主要工作：集成了HPE Vertica enterprise database和Spark开源大数据计算引擎
优势：
可以快速、可靠地在Vertica和Spark中传输数据，并将spark生成的机器学习库部署在Vertica，来分析Vertica中的数据。这种架构扩展了Vertica的丰富的SQL分析功能和Spark的机器学习库，给Vertica用户提供了大量机器学习的功能。用户也可以将Spark作为一个先进的ETL引擎，用来针对那些需要Vertica保证的性质的数据
Vertica：
大规模并行处理（MPP）列式存储的分布式数据库，具有传统事务语义。是传统的关系型数据库，特点是按列存储。适合OLAP。
分ROS和WOS，WOS支持写时不排序不压缩，所以吞吐率较高。ROS是个高度优化的面向读的磁盘存储，包括压缩和索引。密集包装，不浪费磁盘页。排序压缩。定期从WOS转移到ROS，异步和批量做。 适合ETL结果存储。
一张表的各个列通过不重复的hash排列分到不同机器上，hash结果的不同范围存在不同机器。
k-safety。也可以一张表在一台机器上。
支持高级SQl分析，用户定义扩展。分析功能可以支持很多算法。
Spark：
支持批处理，流式计算，并行的机器学习算法，SQL，图形计算。但是数据管理比较弱，与商业数据库系统相比。
不支持数据共享的足够的孤立语义，不提供数据完整性保证。不适合重要任务的交易数据。不支持共享数据访问和ACID特性。
主要的数据抽象是RDD （弹性分布式数据集 ），RDD是不可更改的内存结构，被切分成不同的partition，分布在集群中，RDD本身不可持久，但是可以保存在外部存储。工作节点管理本地task的执行，来操作RDD的数据。task无状态，互相不可通信。一个job包含多个task。
DataFrames：类似数据库的表，对RDD进行了包装，加入了schema。不可更改。
工作介绍：
可靠的数据转换：精确一次语义
-V2S：并行算法 消除了所有Vertica节点间的data shuffling
Vertica-centric： push-based
Connector在load api中被唤醒，支持额外的处理操作（过滤，选择，计数），Connector将这些操作下推至Vertica，来减少数据的网络传输。将Vertica的一张表
传输到spark是原子的，会load一个一致表。
可以利用Vertica的数据分布和ACID特性来支持快速数据传输来读取一个一致的数据并保持精确一次语义。
请求的数据存在本地Vertica节点。
pull模型，需要数据时，启动spark任务，从Vertica中取数据。
形成唯一的查询，请求需要的数据中各个不重复的部分，并且将各个查询结果聚合在一张表中。
每个partition对应一个或多个相邻的hash环的segment，保证了请求本地数据
使用vertica的时间版本特性，请求时指定版本，保证了一致性，避免了重复数据。
-S2V：并行算法 避免了部分或重复的导入。
Vertica-centric： pull-based
Connector在save api中被唤醒，支持保存到一张已经存在的表（appending）或新创一个表。转化是原子的。不会由于部分导入或重复导入污染目的表。
利用了Vertica的ACID特性保证精确一次语义（通过一个单独的spark作业）的数据存储。
由于tasks之间不通信，用Vertica的一张表来记录全部转换进程，每个task通过这张表来查看其它task的处理状态。
批量导入会包含被拒绝的行组。让用户指定可以容忍的被丢弃的行，并且提供丢弃的行的样例。如果丢弃的在范围内则success，否则fail
spark作业启动时，会有一个setup阶段，会创建3张临时表和1张永久表，Staging表，和targe表schema一样。task status表，每行一个任务状态（task/partition id，行成功数，失败数，任务完成状态）。Last committer表，包括最后提交的task
id。Final status表，包含唯一job name，失败行比例，作业的最终状态（以防止spark崩溃时用户不确定job状态）。这个阶段还会查询所有Vertica节点的ip。并且可以对DF重新分区来得到并行度。
每个task包含5个阶段：
第一阶段：和一个vertica节点连接，将数据写进staging表，并将task status表的完成状态写成true并提交（只有当前完成状态是false），否则放弃事务。写staging表和更新task status表在同一个事务中，来保证task中的记录将数据持久化。
第二阶段：task检查task status表来检查是否所有task都完成了（包括自己），如果有一个没完成，那么这个task就完成。如果所有都完成了，就到第三阶段，可能有多个task同时到达第三阶段。
第三阶段：更新las committer表（用task id），如果id依然是空则再次提交，否则终止。这来产生领导人。
第四阶段：读last committer表，如果看到自己不是领导人，就终止。这样读两次表来保证不重复提交数据。
第五阶段：last commiter表中的task是仅剩的task了，检查failed rows 总是是否满足要求。如果满足，则把staging table提交成targe table并更新final status表（如果final status表的finished是false），否则终止。保证staging表到targe表只做一次。在overwrite模式，就是改个名，在append模式，需要复制数据到targe表中。
1、2阶段保证DF数据保存到staging 表，是作业的主要部分。
3、4、5阶段保证最后staging表到target表只提交一次。
由于staging表的存在，最坏的情况spark和vertica挂了，target表不会被影响。
-将spark构建的机器学习模型在vertica中部署并执行，为 MD（Model deployment）
由于模型种类不同，不同的PMML模型不能放在同一个表中，需要存在内部分布式文件系统中。可以通过数据库查询隐形和UDF访问。
DeployMPPLModel方法：将模型存在DFS中，并将metadata信息插入一张vertica表中。
当模型部署了，可以用来做数据库内的预测。这需要写UDF来读取模型并用JPMML构建模型评估器来预测。为了简便，提供了一个通用的模型评价器，来评价那些输入时一个数值向量输出一个数值的模型。
用户可以在数据库中运行预测器，通过SQL查询。
总结：数据在Vertica中，想用机器学习模型来分析，把数据导入spark中，用MLLib生成模型，将模型写到vertica中并部署，在vertica中运行模型查看结果。
实验：
将数据存在hdfs上，通过spark存到vertica中，再读到spark中。
关掉了k-safety复制。来简化评估数据转移而不是数据库容错。
D1：csv格式的100列8字节浮点数140G，100M行。
D2：csv格式的2列twitter数据，140G，1.46B行。
4个vertica节点，8个spark/hdfs节点
比较不同并行度对v2s和s2v的影响。