浙江移动大数据平台践行之路（下）

在上一篇中，三墩IT人和大家聊了Hadoop集群在建设过程中遇到的问题。本篇我们将围绕大数据平台实时分析技术（内存数据库和流处理技术）和MPP集群进行展开，赶紧点开看吧！...

作者

汤人杰    浙江移动大数据资深架构师

在《浙江移动大数据平台践行之路（上）》篇中（◀可点击浏览），我们介绍了Hadoop集群在建设过程中遇到的问题，本期我们将介绍大数据平台实时分析技术（内存数据库和流处理技术）和MPP集群及建设过程中遇到的一些问题和解决方案。

实时分析技术介绍及问题分析

实时计算系统一般都是针对海量数据进行的，一般要求为秒级。实时计算主要分为两块:数据的实时入库、数据的实时计算。

主要应用的场景：

1. 数据源是实时的不间断的，要求用户的响应时间也是实时的（比如网站的访问PV/UV、用户访问了什么内容、搜索了什么内容、实时信令、实时人流等，实时的数据计算和分析可以动态实时地刷新用户访问数据，展示实时流量的变化情况，分析每天各小时的流量和用户分布情况）；
2. 数据量大且无法预计，但要求对用户的响应时间是实时的。

• 数据实时采集

    需求：功能上保证可以完整的收集到所有日志数据，为实时应用提供实时数据；响应时间上要保证实时性、低延迟在1秒左右；配置简单，部署容易；系统稳定可靠等。

目前的产品：Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘宝开源的TimeTunnel、Hadoop的Chukwa等，均可以满足每秒数百MB的日志数据采集和传输需求。

• 流处理技术

    在流数据不断变化的运动过程中实时地进行分析，捕捉到可能对用户有用的信息，并把结果发送出去。流处理技术具有低延迟、可扩展和容错性等特性。

目前的产品：IBM Streams、Storm、SparkStreaming等。

• 内存数据库

    内存数据库通过将数据放在内存中直接操作的数据库，利用内存的读写速度快速读写、内存随机访问的特点，将数据保存在内存中，在内存中模仿建立表结构和索引结构并针对内存特性进行优化，相比从磁盘上访问，内存数据库能够提高应用的性能。

目前的产品：Redis、SQLfire等。

    内存数据库和流式实时分布式计算系统在互联网公司占有举足轻重的地位，尤其在在线和近线的海量数据处理上。在线系统负责处理在线请求，因此低延时高可靠是核心指标。下面我们介绍实时分析系统建设过程中遇到的一些问题及解决措施：

问题一：多线程模式下提升分布式内存数据库SQLfire的数据导入速率

    问题描述：Sqlfire是一款SQL型的内存数据库产品，支持集群模式，具有高吞吐量，可预测的低延迟低延迟，支持动态和线性扩展，支持数据持久化等特点。我们在进行Sqlfire压力测试时发现，向Sqlfire中导入1W条记录需要7.5s的时间，这对于内存数据库来说是有点慢的。

    问题分析：测试建立的表为分区表，Sqlfire支持分区表和复制表两种表模式，分区表按照建表时指定的分区字段分区，复制表则在Sqlfire集群每个节点都存有一份数据。一般大表适合建立为分区表，浙江移动场景下，比如客户信息表，产品订购表等大表适合建立为分区表，小表比如产品配置表，地区信息表，套餐维度表等一些维表更适合建立为复制表。建立的测试表为用户信息表，包括用户id，地市，县市，年龄，入网时间等11个字段信息。

浙江移动的Sqlfire集群由90个节点组成，主要使用Docker技术在18台物理机上每台隔离出5个Sqlfire节点，共计90个节点。

首先测试单线程模式下的Sqlfire的导入数据能力，以插入1W条记录为例，测试结果为1W条记录耗时为7.5秒。

然后是多线程模式下测试1W记录做insert操作，以开20个线程为例，测试结果1s。程序中开20个线程，每500条记录开一个线程做insert操作。在这种情况下测试10W条记录的插入，耗时为4s，相当于每5000条记录开一个线程做insert操作，进一步可以使用线程池来进行线程的管理。

以上结果可以看出，在一定线程数范围内提高线程数，可以明显的提高内存数据库Sqlfire的导入数据的速率，但对于多线程模式来说，存在的瓶颈就是当线程数达到一定的数量后，对于一定的硬件条件下可能提高线程数据对提高的导入数据速率并无明显的提高，这是因为线程数达到一定数量后，线程间的线程切换也是一个较大的开销。

问题二：IBM Streams与Kafka连接

问题描述：

1. IBM Streams与Kafka进行传输时发现，Streams与Kafka并不能连通；
2. IBM Streams 在与Kafka读写时发现性能不到1万条每秒，这远远没有达到我们设计之初的要求。

    问题分析：通过查阅文档发现，Streams确实存在于Kafka传输的接口，进一步查看Kafka代码发现，原来Kafka本身存在缺乏安全机制，为了解决这个问题，我们在Kafka中间层上加入了Kerberos安全认证，所以Streams在连接Kafka时没有进行Kerberos的安全认证，从而导致Stream与Kafka不能连接。

针对读写性能问题，尝试使用多线程，并使性能达到100万条每秒。

    问题解决:

Streams加入安全认证的部分代码如下：

private static final StringKAFKA_JAAS_POSTFIX = ".Kafka.jaas.conf";

/*** 用户自己申请的机机账号keytab 文件名称*/

private static final StringUSER_KEYTAB_FILE = "user.keytab";

/*** 用户自己申请的机机账号名称*/

private static final StringUSER_PRINCIPAL = "nuodong";

public static void securityPrepare()throws IOException

多线程以下是部分代码：

public class ConsumerMultThread extendsThread

{

private static Logger LOG =Logger.getLogger(ConsumerMultThread.class);     // 并发的线程数

private static int CONCURRENCY_THREAD_NUM =100;

private ConsumerConnector consumer;

问题三：Redis的Slave节点复制Master时，BGSAVE操作存在小概率数据错乱

 隐患问题描述：在主从模式下的从Redis如果开启了定期BGSAVE，并且在做主从SYNC的时候，可能存在数据错乱的问题

    问题分析：Redis的BGSAVE操作和slaveof触发的同步操作是互不相关的（对于从库），所以就完全有可能同时在进行备份和同步。Slave从Master读取最新的rdb文件后，加载到内存的步骤如下：

1. 将读取回来的临时文件rename成server.rdb_filename文件
2. 调用emptyDb方法清空整个数据库
3. 然后调用rdbLoad(server.rdb_filename)将server.rdb_filename文件加载到内存
4. 加载从master接受到的最新数据

−    问题在第一步到跟第三步里面的server.rdb_filename文件可能会被覆盖，因为此时如果有后台的BGSAVE进程由于定期事件触发启动备份后（正好大部分主从都是在从库做备份的），正好此备份程序在一和三之间完成（这中间需要清空所有数据，时间较长），于是 BGSAVE进程会覆盖掉server.rdb_filename文件内容。然后再第3步还是继续去加载server.rdb_filename文件到内存，实际上这个文件完全不是刚刚同步回来的文件，而是slave自己bgsave出来的文件。这样数据库的数据就会出现错乱。

    问题解决：其实主从在做SYNC全量同步的时候，此时并没有必要做BGSAVE，因为等SYNC完成后，自然就会将同步回来的rdb文件覆盖BGSAVE文件 的：rename(server.repl_transfer_tmpfile,server.rdb_filename)，所以BGSAVE等于白做。

MPP集群技术介绍及问题分析

企业级大数据平台通过构建MPP资源池集群侧重于B域数据分析，主要包括核心数据仓库、数据集市）。

• 核心数据仓库：通过引入MPP数据库取代现有DB2数据库。数据只在核心数据仓库建数据模型，完成之后把数据同步到列存数据分析集市，同时列存数据分析集市作为大数据集市承载目前所有的基于数据库标准SQL开发的应用；仅当核心数据仓库出故障时，列存数据分析集市将接管核心数据仓库，避免两套系统同时跑造成资源浪费。
• 数据集市：承担核心仓库的容灾，以及数据集市的功能，向上层应用开放。分行存、列存建设。

    下面我们介绍MPP集群应用过程中遇到的一些问题及解决措施：

问题：MPP集群装载机高可用实现

    问题描述： GBase集群中的三台加载机为三个独立的点，三台机器创建了相同的目录，部署了相同的应用，每台机器人为分配不同的作业，相当于人为实现负载均衡，但是一旦某个点宕机，此节点的作业就被迫停掉。换句话说，加载机无高可用。

    问题解决：三台加载机通过赛门铁克高可用软件实现三方互备，以VIP的方式实现业务漂移，可以做到在节点宕机时做到应用无感知迁移。改造后，三台加载机最可实现2台宕机不影响生产（处理能力会有相应下降）



随着大数据处理和分析技术的不断进步和完善，对大数据的研究和应用必将得到进一步的深化，大数据的价值也可以得到更大程度的挖掘和利用，并在企业运营过程中发挥着越来越重要的作用。

    浙江移动通过企业级大数据平台建设，并探讨建设过程的问题和解决方案，解决了大数据平台运行过程中的一些燃眉之急，同时增强了技术能力和知识储备，为未来大数据百放齐放的应用生态打下坚实的基础。

但正所谓“横看成岭侧成峰，远近高低各不同”，以上的问题分析和解决方案也许并不完全正确或完整，更欢迎有更多志同道合的朋友一起交流和讨论！大数据平台建设不是一朝一夕的事，路漫漫其修远兮，我们永远都在路上。

    关注 三墩IT人