2014DTCC小记

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


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

Hadoop技术

1. Spark

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

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

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

2. 数据处理

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

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

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

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

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

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

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

内存数据库

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

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

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

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

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

存储和文件系统

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

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

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

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

Loading Disqus comments...
Table of Contents