淘宝分布式数据处理实践

淘宝望目前有会员2亿左右，日均UV高达4000万，日交易量高达数亿元，每天产生大量的数据，所以部署了一个大规模的Hadoop集群，此集群规模为：

 

1.总容量为9.3PB，利用率77.09%。

2.共有1100台机器。

3.Master：8CPU，48GB内存，SAS Raid。

4.Slave节点异构:

          8CPU/8CPU（HT）

          16G/24G内存

          1T*12/2T*6/1T*6 SATA JBOD

          12/20 slots

5.约18000道作业/天，扫描数据：约500TB/天用户数474人，用户组38个

其中，从两方面介绍了Slave的规模：

1.Slave机器异构

6T机器磁盘利用率较高  Rebalance 单机速度控制：10M/s 每天9:00-23:30运行

  2.Slave故障率

每周10-20次硬盘规章  每周1-2次主板或其他故障

 

 

 

以下为淘宝基于Hadoop版本介绍

1.基于0.19.1

2.大量Patch，主要来自官方社区0.19.2，0.20，0.21等，少部分自己开发

3.Hadoop客户端和服务端代码开发分离，云梯管理员只负责服务端升级，并保持版本向下兼容。

在Hadoop功能方面的扩展有几个方面：

1.安全性

密码认证   扩展ACL，用户访问其他组的数据

 2.Scheduler

基于FairScheduler的改造    slots动态调整    各个组使用自己的资源

 3.Slave单磁盘容错

DataNode坏掉一块磁盘不需要停止，减少数据分发   TaskTracker坏掉一块磁盘后不对作业造成影响

 

 

周敏还介绍了淘宝在Master节点容灾的解决方案及将来在这方面的工作计划：

1.   3个Master+1个Standby节点

配置文件一致，上传至SVN

 2. JobTracker无元数据，JobHistory每天备份七天前的历史文件

3.  NameNode和SecondaryNameNode

Check point 1天做一次（晚上8点之后），降低NameNode启动时间   Fsimage和edits同时通过NFS写到SNN上，元数据保存两份

4.Standby在NN或JT机时启用

 

 

周敏表示，在这方面还有很多工作要做：

1.JobTracker单点问题

调度效率低下导致集群利用率不足

 2.NameNode HA

AvatarNode

3.Namenode内存瓶颈

Heap Size 40G,CMS gc之后23G 分布式NameNode ,Dynameic Partition Tree

4.Hadoop升级

5.OSD及CRUSH算法

 

由于数据量比较大，有些记录格式有错，使得自己编写MapReduce Job生成的数据总是少了一些，基于Hive很多的有点，所以项目就用Hive来写：

淘宝对Hive的使用时对一下几方面进行了改造：

1.UDFs

2.建立/删除临时函数

3.多线程Thrift server

4.GBK支持

5.完全JDBC

6.Multi Distinct Aggregation支持

7.认证与权限

8.bug fix

 

转载于:https://www.cnblogs.com/hellochennan/p/5370142.html