在数据仓库环境中，OLAP数据库（主要数据库）的选型是过去一直在一边使用和一边探索的过程。笔者从事通信行业数据仓库已有近十年工作经验，这类数据库选型和使用从Teradata到DB2，再从DB2到Vertica，期间老板决策说要用hadoop生态组件替代Teradata和DB2（成本因素和集团的去IOE决策，分公司都在寻求适合自己的替代方案），但项目最后烂尾，不得不再次进行招标，参与竞标的有Vertica、Gbase和Greenplum，最后Vertica竞标胜出（因为笔者参与了整个招标过程，商业的游戏就不多阐述了，不过在后期对于Vertica的使用上来说，整体感知还是不错的），以下对笔者使用的三款分布式数据库简单对比（后续会放出对于Teradata介绍和DB2介绍相关文档）
Teradata：
优点：稳定、周边产品齐全
缺点：成本高、扩展性差、开放性差（基本在网上不大找得到）
DB2：
优点：稳定（基于IBM小机和AIX系统），较开放
缺点：成本高、扩展性差、周边产品不足（资源管控组件能力不足）
Vertica：
优点：成本低、扩展性较好（如不按倍数扩展节点，rebalance巨慢）、开放性好、周边产品齐全（有MC控制台、完整的产品指导手册）
缺点：售后支撑服务一般（大中华地区售后只有5*8服务，要额外购买专家服务），对客户自有人员能力需求高（基本安装部署、扩容、版本升级都由本人完成了，以往Teradata或DB2都是厂商操作完成）
一、Vertica的相关介绍
以往用过Teradata和DB2的服务，基本会有人员短期的驻场支撑和周期的数据库巡检，Vertica在这块上如果购买了专家服务是可以约时间短期驻场支撑的，当然成本很高，但没有数据库巡检这项服务，当然成本决定一切，也许也是HP对自身产品的自信。
从以上数据库的演变来看，在大数据解决方案中，市场对于OLAP场景数据库选型在朝着：开放性、低成本、高可用、可扩展（在线）、列式存储、基于x86硬件环境，如果人员能力足考虑使用开源产品，如果对稳定性和保障性需求高可选择商用产品（笔者所处的环境是开源+商用的组合架构）
Vertica数据库是HP的大数据解决方案，基于MPP架构（分布式并行处理架构）的列式存储数据库（原Teradata和DB2均为行式存储数据库，IO瓶颈极大）
后面简要说明下Vertica的独有特性（偷点懒，直接使用之前整理给内部的培训文档）
Vertica的高可用实现（K安全性）
在默认情况下，Vertica采用一主一副两副本的形式存放副本，主副两副本存放在相邻节点上
所以根据RDBMS（关系型数据库）的事务管理ACID，只要不存在相邻节点down掉的情况，仍然能取出完整的数据，数据库仍可以使用，当然在实际生产环境中会比这个架构复杂很多，根据机架信息构建fault group实现，避免机架断电的极端情况出现。
Vertica特有对象：Projection
在其他关系型数据库中，Table提供数据的物理存放，但在Vertica中Table有点类似其他数据库的View，其下还有一层称之为Projection指明表列的数据物理存放，所以依照前面提出来Vertica默认一主一副两副本的存储，在Vertica中创建table会默认生成两个projection。
Vertica数据特性：数据分布
在MPP数据库环境都存在分布键的概念，即选择合适的一个或多个字段进行数据分布，保证数据的均匀分布能有效提升MPP的DML操作性能，在Vertica数据库中如未指定分布键，系统会自动选择前8个非字符串类型字段进行分布，我们需要根据唯一性和访问频率进行合理选择
Projection默认继承Table参数指定
涉及物理存放，字段太多会影响增删改效率
Vertica数据特性：有序存放
在Vertica数据库中创建Table和创建Projection时需要指明排序列，如未指明会默认取表第一列进行ASC即进行正序排序存放数据，我们需要根据访问频率进行合理选择，选择是否合理对后面访问会有很大性能影响
Projection默认继承Table参数指定
涉及物理存放，字段太多会影响增删改效率
Vertica执行计划：Merge Join
通过以上特性能很清楚意识到，在其他数据中Merge Join并不是通常最优的执行计划选择，因为需要进行sort，会耗费大量资源，但在Vertica中就不一样了，因为数据是有序存放，故而通常Merge Join会是最优的选择，当然在一些业务场景中我们不得不使用非序字段关联分析，那么Vertica此时会选择Hash Join，对内存的需求就增大了，所以Vertica的资源池resource pools（类比其他数据库的workload manager）对这内存资源的限制参数会比较丰富。
二、Vertica的尴尬
Vertica的尴尬：并发
Vertica安装部署较为简单，不像其他数据库，安装完软件还需要配置一系列的数据库参数才可有效使用，Vertica几乎不用设置任何参数即可使用，但是这带来的就是对硬件配置指向性较高同时linux操作系统并发控制依赖较高
e.g.：一个事务至少要获取到1C的核心，同时Vertica需要关闭超线程，一般的x86服务器配置在20C-24C已经算很不错了，那么除去预留系统用的，看上去事务并发有效最高只能达到18-22个了。
Vertica的尴尬：存储资源控制
Vertica不像其他数据库，有如DB2的表空间、Teradata的子库空间可直接或间接控制用户对于存储资源的使用限制，而是把总的存储当成一个大池子，任何用户都可以肆无忌惮的使用存储资源，管理员只能通过规范和考核限制用户的行为，但对于数据集市这类场景复杂，用户量巨大的环境，以及一些不太敢得罪的用户，管理员只能督促规范使用，没有成效则只能选择扩容了（这会不会是HP的小心机呢，扩容就有钱赚了，细思极恐），这块据说没有革新的计划。
Vertica的尴尬：无分发的安装部署
Vertica的安装部署和后期的配置修改还是比较简单的（后续考虑关于Vertica Enterprise的安装部署放送出来），但是当节点数较多时问题就产生了：
需要一台一台服务器的安装和配置（无法像cloudera manager这类进行分发部署hadoop相关组件），暂未收到未来有考虑在MC控制台增加这项功能
Vertica的尴尬：非倍数的扩容
Vertica的扩容操作比较简单（续考虑关于Vertica Enterprise的扩容过程放送出来），但存在两类问题：
（1）需要一台台修改服务器配置（如hosts文件修改）
（2）rebalance巨慢（需要进行数据拆分和复制）
在笔者最近一次的集群扩容操作中17节点扩容至26节点，踩到了非倍数的扩容，rebalance几乎持续了一个月的坑（当然rebalance窗口也是十分有限的），后面为加快rebalance，不得不采取DBA重建对象的操作（RENAME ,CREATE ,INSERT ,DROP）
三、Vertica的未来
Vertica的未来：hadoop组件兼容+AI
Vertica近几次版本的更新均提到了对于kafka等开源组件以及机器学习等算法的支撑更加完备。
对接kafka：笔者所在集群环境已部署生产上线通过Vertica微进程消费kafka数据，但这块当前遇到一块难点，对开启安全认证的kafka环境当前Vertica微进程存在访问不到topic（即安全认证失败的问题），当下Vertica专家还未给与解决方案
对于机器学习等，因笔者所处环境并未涉猎还未开展相关探索（当然也是笔者毕业时忘记把大学学的关于数据和算法大部分内容带出来了，有点棘手）
Vertica的未来：读写分离（Eon Mode）
关于这块这里就不做过多说明了，后续会有专门章节介绍（笔者对这块最近已做了Vertica+HDFS的部署实施并产生了一份测评报告）
Vertica提出这块也是要解决市场对于读写分离的需求以及自身产品并发不足的问题，目前应用主要集中在Amazon S3，但国内很少有用户会使用到亚马逊云服务，据反馈对于基于HDFS的Vertica Eon Mode解决支持已走上日程，最快可能2020年即会发布支撑
