一. 背景分析
传统关系型数据库在企业市场长期占有稳固的统治地位，许多人都不曾意识到除了传统关系型之外还有其他类型的数据库。传统关系型数据库非常善于处理事务的事务性操作，例如更新操作。但是在处理大数据量的批量操作时候就有点捉襟见肘。例如DB2作为IBM公司开发的一套关系型数据库管理系统，被广泛应用于大型数据仓库项目中，特别是移动行业，自构建经营分析系统以来，基本都采用DB2数据库搭建BI主仓来聚焦于数据分析，支撑内部管理决策、营销推广和客户服务等工作。
随着大数据在带来全新商业模式和业务增长，对IT支撑工作提出了更高的挑战，对现有技术架构体系也提出了全新的要求，其中自然包括数据仓库支撑能力。在业务需求快速变化的今天，传统数据库软件显得捉襟见肘，存在较多的不足，主要包括：
1. 性能难以满足业务需要
随着业务的发展，时间积累后数据量呈几何般的增长，业务的复杂度对数据库性能提出了给高的要求。而传统的关系型数据库由于行式存储，运算集中化，在复杂SQL的支撑上对IO，CPU等资源很大的压力而且难以满足业务需求。
2. 扩展性不足
传统数据库扩容只能Scale-up(纵向扩展)，以增加处理器、高端存储容量等资源进行升级以获得对应用性能的要求，但是更大更强的服务器同时也是昂贵的，扩容完还需要进行数据的balance操作，甚至需要进行停库操作，直接会对生产造成影响。
3. 产品高可用性差
传统数据库例如DB2配置文件及逻辑节点的元数据有1份副本，但系统默认在同一目录，且不可更改，不可再备份，其安全性非常低。
4. 投资成本高
DB2的主机需要用IBM的小机，ORCLE需要用 Exadata，所有的存储还需要EMC等这些价格动辄数百万的设备；同时这些软件的Lisence也非常昂贵。而在人员的开支上，这些数据库管理员成本也不低。
二. 方案选型考虑到分布式数据库支持基于X86的部署方式，而X86大量取代传统小机已经成为趋势，具有成本低、扩展性好等优势，传统数据库依赖小机升级的扩容模式走到了尽头等原因，决定引入MPP（Massively Parallel Processor ）分布式数据库取代现有DB2数据库。MPP在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。利用MPP在核心数据仓库完成数据建模之后同步到数据分析集市，同时数据分析集市作为大数据集市承载目前所有的基于数据库标准SQL开发的应用。
产品对比如下：
1. 对比IBM DB2
Vertica | DB2 | |
硬件架构 |
|
|
软件架构 |
|
|
压缩 |
|
|
高可用 |
|
|
日常管理 |
|
|
性能 |
|
|
可扩展性 |
|
|
2. 对比Oracle Exadata
硬件配置对比
Exadata 1/2 Rack | Vertica | 说明 | |
Server配置 | 总共11台，包括4台数据库和7台存储服务器 | 11台DL380p Gen8 | 保持与Exadata的Server数量一致 |
CPU核数 | 数据库节点:64核(2.9GHz,E5-2690) | 176核，2.6GHz, E5-2670 | CPU核数多20% |
CPU处理能力 | 5559 | 7084 | 整体CPU处理能力增加28% |
内存 | 1024GB | 1408GB | 内存增加40% |
硬盘型号 | 600GB SAS盘 15000rpm(3.5) | 900GB SAS盘10000rpm(2.5) | 性能基本一致 |
硬盘数量 | 84 | 275 | 硬盘数量增加3.3倍 |
可用容量 | 22.5TB | 900GB*22*11=218TB | 可用容量增加3.4倍 |
数据加载速度 | 8TB/hour（理论最大值） | 每节点200MB/s，约8TB/hour（实测平均值） | 基本一致 |
软件特性对比
Exadata | Vertica | 说明 | |
数据存储方式 | 行式存储+混合列压缩 | 纯列式数据存储 | Exadata只有在以direct load方式进入的数据才能被列压缩 |
压缩方法 | 6种压缩算法（2种行压缩，4种列压缩） | 12种压缩方式 | Exadata只能针对表级进行压缩指定；Vertica可以对表的各列分别指定不同压缩算法 |
加载与实时查询同时进行 | 在进行direct load加载时通常要disable index，因此实时查询无法同时进行 | 可同时进行 | Vertica支持在数据加载的同时进行高并发查询 |
部署架构 | Shared everything 架构 | Shared nothing MPP 架构 | Shared everything架构无法扩展过多节点，而 shared nothing 的MPP架构扩展性更好，更适合于大数据量的并行处理 |
数据库管理 | 复杂的管理，需要非常有经验的DBA和专用的OEM工具 | 简单，自动，无需过多人为干预 | |
分析函数 | 少数简单的分析函数 | 内嵌多种分析函数与灵活的分析查询 | |
Hadoop接口 | 不支持 | 支持 | Vertica内嵌与Hadoop的接口，支持结构化与非结构化的同时分析 |
成本对比
Exadata 1/2 Rack | Vertica | 说明 | |
硬件价格 | 800-1000万 | 200万 | DL380gen8按每台10万报价，加上一些外围设备和服务 |
软件价格（成交价） | 864万 | 300万 | Vertica价格为估计；Oracle通常会利旧 |
3年服务费 | (800*8%+864*22%) * 2 = 508万 | (200*8% + 300*21%) * 2 = 158万 | 硬件按8%，软件按22%(Oracle)和21%(Vertica) |
3年总体投入 | 2172万 | 658万 | Vertica方案为Exadata投入的30% |
三. 建设方案
1. 环境部署
在容灾方面，同城异地的主备两个数据库集群间可以增量同步，从而实现异地数据灾备。同时，在备份方面，该产品提供专用的VBR备份恢复工具，可以方便地对整个集群中的数据实现全量、增量级别的表粒度或者库粒度的各种形式的备份。支持数据并行备份和并行恢复，备份文件可以分布在不同的备份存储领域上，配置不同数量的备份恢复节点。
平台架构一般设计如下：
1.1. 功能架构
MPP资源池集群建设，主要分为两个独立的MPP数据库建设，分别是核心数据仓库和数据集市。
1.2. 物理部署
集群可以部署3个以上的节点，K-safy值可以设置n，即每份数据有n份冗余数据，每份冗余数据均部署在不同机架中。
为了便于本项目以后扩展，我们建议采用分级网络，既每个机柜配置2台万兆接入交换机，这些交换机再级联到核心交换机。
交换机：
至少配置2台核心交换机组成高可用集群。
每个机柜配置2台万兆交换机，并组成高可用集群；每个柜顶交换机通过2个40G上行口分别与2个核心交换机连接。
为MPP数据库内部集群通信网络设置VLAN以便于外部服务网络隔离。
每台服务器的连线方式：2个10GE网卡通过光纤分别与柜顶两个交换机的10G光口连接，在服务器段绑定成一个逻辑网卡，设置内、外两套网络IP地址，并为内部集群通信网络设置VLAN以便于外部服务网络隔离，形成可靠的内部通讯网络，避免网络故障。
每台计算节点操作系统盘由2块盘做raid1实现热备，或者每7块做1组Raid5,3组Raid5再做Raid0合成1个数据盘，提高存储读写性能，并兼顾数据安全性。
采用万兆业务网络、千兆管理网络，计算节点采用2万兆绑定网络，解决批量数据处理可能存在的网络瓶颈问题。
2. 应用迁移
为了减少省经与一经的相互影响，实现一经与省经解耦，把现有DB2上除一经外的仓库模型、片区化应用、手机经分等省经应用全部迁移到MPP平台上。
本次迁移改造采取按应用逐步实施的策略，遵循如下步骤：
把DB2上执行程序代码直接搬迁到MPP上执行，根据错误调整相应的语法，通过批量调整的模式，保证所有程序能正常执行。
导入数据源后运行程序，将MPP上的结果数据与DB2进行比对，发现差异数据后找到问题并解决，确保两边数据一致。
优化程序（如小表建复制表，大表分区键是否合理）并保证生成数据的时间不晚于DB2生成的时间。
在程序稳定运行半个月后，切换对外接口数据源，最终实现平稳迁移。
系统优化
随着省经业务应用逐步往Vertica上迁移上线，业务数据量出现了超预期的增长，可能会出现了性能下降和容量不足等情况，一般共两大类问题。
（1）装载问题，包括：装载机网络不稳定、装载效率低、稳定性差、装载超时、装载数据质量问题，以及装载文件字段与表结构不一致等问题；
（2）性能问题，包括：数据库运行一段时间后出现性能下降、查询插入语句执行效率慢、垃圾SQL耗尽系统资源、建Projection不合理、大量失效视图和过期表未及时清理等问题。
上述问题既有平台层面问题，也有业务层面（SQL质量和开发规范）问题，为此，从技术层和页面层面方面对系统进行了专项优化。
3.1. 技术层优化
网络优化：升级网卡驱动，修改网卡模式，调整交换机哈希算法完成数据流量的负载均衡，调整TCP相关内核参数，增大内核套接字接收缓存区的大小。改进后网卡流量可稳定2万兆运行，网卡效率与稳定性出现显著提升，丢包和重传现象基本消失。
数据库优化：优化控制文件参数、优化加载并行度、增加预读缓存、优化CPU线程数量、增大装载服务端与客户端之间的通信延时参数、优化装载超时参数，装载失败率由30%左右下降到低于0.5%；优化Projection配置参数，相同SQL的执行时间可以大大缩减时间，例如客户表和账户表之间的大表关联运算，Vertica相比较传统数据库只用了1/5的时间，总体性能提升60%；优化数据库内存参数，提高了系统稳定性。
3.2. 业务层优化
因平台应用开发人员对新产品不够熟悉，部分SQL质量较差（如可以直接分区读取数据，表hash键选取不合理、复制或分布表属性选择不合理等）、执行性能差（多余子查询、笛卡尔积、关联字段不合理），对这些问题分别进行了调整优化。
与此同时，还进行了产品培训及使用指导，发布并持续更新多版MPP数据库开发规范，帮助应用开发者更好地使用MPP平台。这样起码99%以上的SQL运行正常，个别SQL耗时较长的及新开发的SQL还需要继续针对性优化。
四. 国内移动使用情况1. 国内移动使用分布
广泛应用于国内电信行业的数据分析系统
2. Vertica在目前移动行业应用范围
BSS | OSS | MSS | 其它 | |
业务域 | ▲经营分析（BASS） ▲详单（CDR）分析 ▲流量经营分析 ▲精准营销分析 ▲历史库与报表 ▲合作伙伴与电子渠道分析 ▲用户分类与收益分析 ……
| ▲信令分析 ▲网络错误与性能优化 ▲网络分析 ▲网络综合分析 ▲综合监控分析 ▲网络容量管理 ▲客户体验管理 ▲漫游分析 ……
| ▲ERP数据仓库 ▲财务报表系统 ▲集中数据分析 ……
| ▲增值业务分析▲平台 ▲大数据分析平台 ▲互联网分析 ▲用户行为分析 ▲用户位置分析 ▲点击流分析 ……
|
挑战 | ▲数据量大 ▲分析处理能力要求高
| ▲数据量巨大 ▲实时性要求高
| ▲分析性能要求高
| ▲数据量巨大 ▲分析处理能力要求高 ▲分析算法要求丰富
|
HP的优势 | ▲超快分析速度、无限的扩展能力；▲SQL标准和开放性
| ▲实时分析和聚合、无限的扩展能力； ▲SQL标准和开放性
| ▲超快分析速度；▲SQL标准和开放性
| ▲Vertica的开放性和与Hadoop/R的整合能力； ▲超快分析速度、无限的扩展能力；▲非结构化分析
|
3. 项目案例
3.1. 信令分析
准实时分析，大数据变现
60节点
HP BL460c G7刀片（VC Flex10）D2200sb 存储存储（12*1TB7200RPM SATA）
实时数据入库超过200MB/s 包括GB,IUPS,GN,DPI等
原始表入库周期为分钟级别
汇总表入库周期为15分钟级别
保存1个月，总量超过500TB
多种粒度的汇总：5分钟、小时、天
3.2. 网络优化
准实时分析，提升网络服务质量
处理云：Hadoop集群完成数据解析汇总
存储云：HP Vertica集群完成大数据存储
6个节点集群，数据量超过30T
主表单表超过20TB，分钟级准实时入库
3.3. 经营分析
大数据高性能分析支撑精细化营销和差异竞争能力
32节点，数据量360TB
性能大幅提升
--数据压缩比高达9倍
--100亿级数据分析查询，秒级响应，性能提升约50倍
--能支撑上数百用户自助分析
数据自助服务：业务用户自助分析
营销大数据分析：
--各种营销模式和促销手段的大数据分析
--客户属性数据的关联分析，包括客户画像查询、标签客户群刷新、标签分析的数据刷新
正在把经分主库迁移到另外32节点集群
3.4. 移动大数据分析平台
整合BSS/OSS数据，280TB / 40节点
O域http/socket数据，先进入hadoop集群进行清洗
A口信令数据，1-5TB/天，先进入hadoop集群进行清洗
B域经分数据，300GB/天，从DB2中直接提取
综合大数据
用户行为、用户画像分析
自助服务
营销分析
数据保留周期
详细数据：7-15天
汇总数据：6个月-1年
高度汇总：1-3年
厂商
基础平台：华为
ETL/BI：华为创我
精准营销：亚联
移动全网智能监控平台
全网级别监控数据进行深层次分析的智能分析平台，为集团、公司内部和省公司提供数据分析服务
需求：能够低成本扩展已存储高速增长的数据规模；能够处理更多地非结构化数据，如web日志以及物联网的应用日志；能够在大规模数据下进行深度数据挖掘，超越传统的随机采样分析的方法，而代之以全数据级别的分析能力。
