前言
我想写一个系列的文章(希望能坚持住~~),仔细记录和总结我的数据开发之路,项目的实际
开始时间从2013年5月开始。随着一年多的实际工作,技术会有所变化,我尽量注明。
背景
我所在部门的主要职责是为公司生产的设备提供统一的业务管理平台,相对来说搞数据只是个贫农,没有土豪那么多的人力,也没有土豪那样成百上千台机器的集群,但是贫农也有追求大数据的幸福啊----其实是被现实逼得,之前的MySQL+ETL随着业务量的增长已经无法满足需求,不得不调整。
虽然是贫农,但是该有的还是要有,该用的还是得用,要做就尽量做到最好吧。下面就直接进入正题了,
项目架构
设计目标
- 能够尽快投入生产。选用使用范围广的组件,稳定可靠,文档丰富
- 简单性。能够快速开发,避免重造轮子,只写与业务相关的代码
- 扩展性。每个组件都要能够横向扩展
- 除了离线分析,还要支持实时统计分析。
技术栈
有了设计方向,就开始了开源组件的采购之旅:
- SUN JDK 1.6
公司主要还是以这个版本为主。 - Hadoop 1.0.4
当时的稳定版,目前已升级到1.2.1。 - Zookeper 3.4.5
用于Hbase、Kafka集群、Storm集群。 - HBase 0.94.7
项目前期用于日志数据存储,实现实时的数据写入和用户跟踪,但是随着数据量的快速增长,限于有限的服务器资源,写入性能达到瓶颈。所以,2014年开始舍弃其保存日志数据的功能,而保留了用户跟踪的功能。 - Hive 0.9.0
对于我们团队来说,与pig相比学习曲线低,容易上手。当前已经升级到0.12.0。 - Oozie 3.3.2
用了1年多,感觉还是不错的,不过有机会的话也想试试Azkaban。 - Sqoop 1.4.3
一是用于从MySQL中导入业务数据到hive;二是将hive的计算结果写回到MySQL。写写命令就能实现MySQL的导入导出省了开发人员不少时间。 - Kafka 0.7.2
生产者主要是Web接口服务器,它们接收来自客户端的各种事件上报,然后统一发送给Kafka集群;消费者主要有Storm和Mapreduce,Storm提供实时分析等功能,Mapreduce则直接加载数据到Hive中,供进一步的分析,这也是得我们后期可以舍弃Hbase来保持日志数据。 - Storm 0.8.2
主要用于实时的数据统计;实时的用户跟踪;同时也能进行实时的数据预处理和清洗,减少Hadoop的压力,从统计的整个生命周期来说,能够很大的提高处理速度。 - Avro 1.7.4
由于公司处于快速发展期,我觉得保证数据规范的前向兼容是一个重要的任务,说不定哪天哪个字段就被废弃了,哪天更多的字段又新加入进来,靠文档和人力实在是太累太没保证了,所以借助Avro的前向兼容特点来实现,这样也符合代码既文档的原则。而且,目前Avro贯穿我们整个数据流的大部分,web接口服务器使用Avro封装数据发送给Kafka,Kafka的各个消费者也使用Avro解析数据,Hive也是使用Avro作为数据文件格式。
服务器配置
让大家看看什么叫做贫民,让土豪们尽情的嘲笑吧~~
- Hadoop及Zookeeper及Mapreduce及Hbase,没错我们是在一起的
实体机10台,CPU:4核,内存:16G,硬盘:500G*8 no raid,网卡:1000M
其中1台用于NameNode、HMaster和JobTracker,其它9台用于DataNode、HRegionServer和TaskTracker。在这9台中,3台也用来作为Zookeeper集群,1台用于安装Hive及Oozie,同时作为接口服务器供开发人员及数据分析师使用 - Kafka集群与Avro注册服务(Avro注册服务以后会详细介绍)
实体机2台,CPU:4核,内存:8G,硬盘:SAS 600G RAID1,网卡:1000M - Storm集群
虚拟机6台,CPU:4核,内存:6G,硬盘:50G
其中1台用于nimbus,5台用于supervisor,5台中的2台用于地理位置查询服务,供数据分析和其他业务线使用。
系统拓扑结构
这是最初的设计,截止到目前的改进和调整没有表现出来,以后有时间好好补一下
现状
目前系统为4个业务线提供数据服务,涉及的终端包括PC、智能电视、机顶盒、移动设备,每日处理1.2亿数据,日均运行300个MapReduce任务,涉及200个统计指标。
Kafka集群目前无压力;Storm集群CPU有些压力,可以通过增加机器解决;Hadoop计算压力比较突出,需要精心计划任务的执行时机,如果能增加机器也可解决。
后续
之后的文章会详细介绍各个部分如何搭建、开发、维护、经验和教训。