2014DTCC小记

前几天突然被老大派去听了DTCC一天半的议程，见识挺多，直接能用的没有。回来后公司要求写点东西，毕竟拿人手短就稍微做了一点总结，很多东西没听明白，就不指望写出来了，出现主次不清、概念错误的情况勿怪，聊以记录一个经历。

上周参加了第五届中国数据库技术大会(DTCC)第一天下午及第二天全天的议程，主要关注了Hadoop技术、内存数据库及存储和文件系统三个方面。一天半的时间里各位演讲嘉宾各显神通，新技术、新思路层出不穷，颇有些应接不暇，下面进行一些简单的总结。

Hadoop技术

1. Spark

目前Spark如日中天，MapReduce昨日黄花。几位分享者都提到，目前Hadoop方面在开两种会，一种是夸Spark的，一种是骂MR的。从几位分享者的分享来看，优劣主要存在于以下几方面：

Spark支持交互式操作。易用性上比MR提高非常多，简单的几行脚本就可以完成wordcount。
支持机器学习(Mlib)和图计算(GraphX)，能够适应更多的处理场景。
支持流式数据处理。通过将数据集存储在内存中并管道处理，避免了中间结果来回写入磁盘(并且还要写三份)的落地过程，大大提高了数据处理效率。MR为离线计算，Spark为实时计算。
支持SQL语句。可以直接使用HIVE SQL类似的语句进行日志统计。

当然，Spark并不能支持MR的全部功能，这两个技术是一种共生互补的关系。阿里的搜索离线技术平台使用的就是目前的主流整合框架，即使用YARN管理所有的调度系统的资源分配，如MR、iStream、Spark等。

2. 数据处理

数据处理是一个比较宽泛的概念，大会关于Hadoop技术的主要内容还是这部分。一个高效的系统，需要优化的是从前端记录存储到后端统计输出的所有内容。目前我对这部分内容了解甚少，仅做一些简单的介绍。

元数据优化。如在网页处理上，使用反转url作为分区依据，将同一网站内容集中，提高扫描效率。
使用消息队列，提高整个流程的实时处理能力。
根据存储内容设定Block大小，使用Gzip或Snappy压缩。
资源动态分配，根据场景及需求快速切换调度系统及任务。
多个框架相结合，日记和数据存储、在线和离线统计、数据查询和更新，各种技术相结合构成数据平台。

我们公司目前的框架还处于非常原始的阶段，只使用到了HDFS、MR及Hive，MR的调度算法都是FIFO的。目前正在构建数据仓库，以后随着数据量增大会逐步更新，如MR调度器、Hbase、日记消息队列等。

3. Hadoop运行数据采集及监控

作为一个运维人员，对服务运行状态的关注是不可避免的。Hadoop自带metric采集发布功能，目前我们也将运行数据采集到Ganglia上进行分析，另外还通过jobtracker job日志记录进行job运行统计。来自中国移动研究院的分享者提到了Ambari管理平台，可以有效的进行Hadoop的部署与监控。Ambari是一个开源项目，整合了另外几个系统，主要功能有：

使用Puppet部署和管理Hadoop服务。
使用Ganglia收集Hadoop服务数据生成图表。
使用Nagios监控集群服务状态发送告警。

Ambari是Hortonworks贡献的，无法直接在Apache Hadoop上使用，需要进行一定的适配工作。不过目前来看，Ganglia和Nagios我们都已经单独运行，由于目前集群规模很小，暂时对Puppet需求不大。后续如果有需求，再调研Ambari。

内存数据库

从去年Q3开始，我们线上redis服务器数量也开始增多，从近期的观察来看，未来还需要采购更多的服务器，因此对内存数据库技术也比较关注。内存数据库的数据读取速度非常快，非常适合存储key-value形式的大规模存取的数据。分享者主要分享了以下内容：

常用内存数据库为Memcache和Redis，资源消耗以内存为主，硬件发展方面内存增长速度最快。
多级缓存提高速度。最活跃的数据存储在内存，次之为SSD和RAID硬盘。通过缓存技术节约存储成本，提高访问效率。
高可用使用本地HA与异地备份方式，异地缓存更新使用消息队列。
本地HA使用Zookeeper。ZK最开始是使用在Hadoop Hbase中的，目前Mysql等多种服务都可以通过该框架实现高可用，多位分享者在不同的系统中都有使用。

另外来自微智云科技的分享者介绍了Couchbase，这是一个目前很小众的内存数据库，与会者调研或使用过该数据库的人只有百分之一左右(当然也可能大家都懒得举手)。Couchbase具有以下优点：

对等网。小规模集群(200台以下)可以使用对等网结构，集群内的所有节点对等，任何节点失效集群对外服务不受影响。
安全的冗余机制。在对等网的基础之上，每个节点的数据分片都备份集群的其他某个节点上。
灵活的节点增删。冗余的数据节点可以动态自动调整，当删除节点时，对应的备份分片自动提升为活动状态，当增加节点时，集群内的分片自动转移到该节点，与HDFS块存储方式类似。
分布式。所有节点可以同时对客户端服务，客户端知道任意key所在位置。这比传统的拆库方式简单，节点变更不需要更改客户端配置。
管理界面。Couchbase有着和RabbitMQ类似的管理页面，能够非常方便的查看节点状态进行节点管理。

Couchbase非常符合我们的需求。目前线上Redis压力较大，不得不进行拆库进行分担，每次调整客户端都需要进行相应改动并且有一定的时间中断，另外，Redis的备份机制导致内存使用量不能超过物理内存的50%，对资源存在较大浪费。不过Couchbase不支持部分Redis功能如list、set，需要考察线上Redis使用情况后进行具体应用。

存储和文件系统

会议上提到的存储及文件系统都是分布式的，主要特性为：

主节点高可用。Hadoop2.0以前NN高可用存在的问题是，尽管主从节点都可以加载元数据，但数据节点只向主节点汇报块信息，因此无法进行实时切换。新的存储技术都避免了该问题，一方面实时将文件变更信息同步到从节点，一方面数据节点发送两份心跳数据。
降低存储成本。主要通过校验码实现，类似RAID。传统的HDFS存储，如果想要保持3副本允许2副本失效，就需要3倍存储成本。采用4+2校验码之后，同样的效果只需要1.5倍存储空间，节省了一半。
文件及块分配变更。TFS存储的文件基本都小于block大小，为了提高效率，索引结构为一个block存储多个文件，文件使用block位置及偏移量进行寻址。

分享者主要针对校验码进行了说明。比如为了不影响写入效率，编码与写入流程解耦；为了提高编码效率，以block为单位进行；block损坏后后台恢复，但遇到读取时实时恢复；支持编码后的文件更新及解除编码等。

OTCC分享的是当前最流行最先进的技术，虽然其中大部分内容我们无法直接使用或者场景不同，但是依然能够给我们很多借鉴之处，也指明了业内现状以及未来的发展方向。部分设计思路巧妙，大涨见识。才疏学浅，虽然只是浮光掠影的总结，仍难免贻笑大方，见谅。