淘宝分布式数据处理实践
淘宝望目前有会员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
