冯宏华:H base在小米的应用与扩展
Upcoming SlideShare
Loading in...5
×
 

冯宏华:H base在小米的应用与扩展

on

  • 468 views

BDTC 2013 Beijing China

BDTC 2013 Beijing China

Statistics

Views

Total Views
468
Views on SlideShare
468
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

冯宏华:H base在小米的应用与扩展 冯宏华:H base在小米的应用与扩展 Presentation Transcript

  • HBase在小米的应用和扩展 冯宏华 小米云平台组
  •  HBase在小米的应用现状  对HBase已做的改迚不扩展  迚行中/计划中的改迚不扩展
  • 集群规模  15个HBase集群:9个在线集群,2个离线处理集群, 4个测试集群  服务小米内部十多个丌同业务  几百台机器:每个数据节点 24 TB ( 12 * 2TB )
  • 应用场景  小米于服务  米聊消息全存储  小米推送服务  MIUI 离线分析  多看 离线分析
  • 部署 – 监控 – 报警 : Minos  自动化部署  集中监控、分类展示、表级指标聚合  已开源:https://github.com/xiaomi/minos
  • 测试  Failover测试 (ChaosMonkey+)  可配置/随机选择action  pre/post数据正确性验证  action/task 可重现  JIRA: https://issues.apache.org/jira/browse/HBASE-9802  压力/性能测试  Longhaul测试  可用性测试:HBase的ping
  •  HBase在小米的应用现状  对HBase已做的改进与扩展  迚行中/计划中的改迚不扩展
  • Delete的语义校正  HBase目前的删除语义: 一个deleteFamily/deleteColumn flag,如果其 timestamp为T,则该flag对所有timestamp<=T的数 据都起作用,无论这些数据写入时间在该flag之前还是 之后写入 (只要该flag尚未被collect)
  • Delete的语义校正(续1) 问题 1: 用户写入一个数据成功返回后,立即发起对该数据 的读(在此过程中确信无其他人/迚程/线程读写该行), 可能读丌到该数据(该数据被一个以前写入的Delete 屏蔽掉了)
  • Delete的语义校正(续2) 问题 2:数据一致性/正确性 ① delete kv with T1, flush ② major compact: Y/N ③ put kv with T0, (flush?) 何时/是否发生major compact影响T0的存在不否,但 major compact对用户是透明的…
  • Delete的语义校正(续3)  修复:校正后的Delete语义为Delete flag只能屏蔽 该flag写入时真实的物理时间之前写入的数据,而丌能 影响到后写入的数据  JIRA: https://issues.apache.org/jira/browse/HBASE-8721
  • 可控粒度跨机房备份 问题:目前HBase的跨机房备份只有per-cluster粒度 Master : T1/T2/T3/T4 T1, T2, T3, T4, Peer 2 T1, T2, T3, T4 Peer 1
  • 可控粒度跨机房备份(续1)  改进:per-peer可配置从master集群replicate哪些 数据(per-table / per-CF) Master : T1/T2/T3/T4 T1, T3, Peer 2 T2:cf1 Peer 1
  • 可控粒度跨机房备份(续2)  优点:  各peer可灵活配置从master备份哪些数据  peer无需创建所有master包含可复制CF的表  peer无需从master接收全量可复制的数据(节省 机房间带宽) JIRA: https://issues.apache.org/jira/browse/HBASE-8751
  • 写吞吐性能优化 – 新写模型  JIRA: https://issues.apache.org/jira/browse/HBASE-8755  效果:性能上限是改迚前的3.4倍 70000 60000 50000 40000 优化前 30000 优化后 20000 10000 0 1 3 5 10 25 50 100 200
  • 反向扫描  问题:HBase的数据模型丌能自然地支持反向扫描 (很长一段时间以来HBase没有此特性,询问此特性的 用户也被告知此特性很难实现而被一直搁置)  实现:通过“seekBefore + seekTo”定位当前行的 前一行(无需buffer/cache block-data)  性能:比正向扫描差30%(不LevelDB的下降相当)  JIRA: https://issues.apache.org/jira/browse/HBASE-4811
  • 可配置比例/抢占式 block-cache  问题:目前block cache是hardcoded的1:2:1 (single : multi : memory),导致某些情形下内存表 的Read性能比普通表还差  修正: ① 上述3者比例可配置 ② in-memory采取抢占式原则
  • DeleteFamilyVersion  需求: ① 删除给定column-family下所有timestamp为给 定值的cell,而无需指定column名字 ② 确保性能(丌能先读回timestamp==给定值的所 有cell以取得column名字再逐一删除:引入读)  JIRA: https://issues.apache.org/jira/browse/HBASE-8753
  • block-index key 优化  情形:每个block index的key是该block的第一个 KV的key  改进:block index的key是一个介亍上一个block最 后一个kv的key 不 当前block第一个KV的key 中间的一 个fake key  优点:改迚后该fake key可能尽量短,从而节省 block index的存储空间,间接提高read性能  JIRA: https://issues.apache.org/jira/browse/HBASE-7845
  • region内跨行原子写  现状:同一次batch操作的同region的跨行写丌保证 一次落地  改进:同一次batch操作的同region的所有写在获得 所有行锁后一次落地  确保按照rowkey大小顺序取行锁,以防止多个并 发batch操作时可能出现死锁  作用:基亍region内跨行原子写可实现native的局 部二级索引(无需借助coprocessor)
  •  HBase在小米的应用现状  对HBase已做的改迚不扩展  进行中/计划中的改进与扩展
  • Compact优化(一) Compact的HFile选择算法的比较-验证框架  作用:方便快捷地比较各种compact算法的优劣  思路:  虚拟HFile生成器:随机间隔生成随机大小的虚拟 HFile文件,并可重现  可配置的compact“损耗”系数  比较标准:生成器停止且compact稳定后,中间 发生的虚拟IO值,越小代表越优
  • Compact优化(二) Adaptive Compact  问题:虽然各个RS均控制自己最多能同时触发的 compact任务个数,但针对集群并没有一个整体的控制, 而compact的io均由底层HDFS执行,占用的是整集群 的io资源,这是导致所谓compact storm的原因  改进:各RS发起compact之前,必须检查当前 compact load是否已到达系统设置的上限,只有可申 请到配额时才能发起(load由compact的IO文件数决 定)
  • Failover优化(一) HLog Reform  问题:因为HLog文件是per-RS的,可能有某region 写入稳定但很稀疏,从而导致其entry散落在很多HLog 文件里,但又因为它写入总量少而未flush HFile,此时 如果发生宕机,failover时需要split很多HLog文件,但 其实每个HLog文件都只有该region的极少量数据  改进:一个后台HLogReform线程,扫描较老的 HLog文件,抛弃已flush成HFile的entry,将有效 entry写入新HLog文件,结束后抛弃原始HLog文件
  • Failover优化(二)  问题:split manager在某splitter超时后,会将该 split task重新标记成unassigned,从而让其他splitter 重新抢占;但一个超时task被其他splitter做极大可能 也会超时,这样会导致一直无法成功  改进:每个split task可允许同时有多个splitter,超 时的splitter也继续做,先做完的splitter通知split manager,后者再取消其他仍在迚行的splitter
  • Master重构  目前Master的架构缺陷: ① region task状态通过zk结点的update-watchnotify机制传逑:ZooKeeper watch的”一次性” 和ZooKeeper notify的”异步”特点,会导致 丢失event ② region task状态存放在ZooKeeper: ZooKeeper client的单io线程是大cluster failover的瓶颈(包含大量region)  改进: https://issues.apache.org/jira/browse/HBASE-5487 ① region task状态通过master-RS rpc传逑 ② region task状态放在另一张系统表里
  • 多租户  问题:目前HBase丌支持类似DynamoDB的 provisioned throughput这样的限制各表throughput 上限的特性,导致共享集群的各应用/表的性能无法得 到保证  改进:提供类似DynamoDB的per-table provisioned throughput,保证丌会因为某个用户对 共享集群的滥用导致其他应用的性能下降
  • 全局事务 – 全局二级索引  问题:HBase丌支持跨表、跨行(跨region行)的事务, 从而也无法实现全局的二级索引  改进:实现类似Google Percolater的跨表、跨行事 务,并基亍此实现全局的二级索引
  • 同步跨机房备份  问题:HBase丌支持同步的跨机房备份(用户的写 由peer replication thread以异步方式push到peer cluster,用户得到成功写返回时,丌能保证数据已经备 份到peer cluster),这导致主集群整体宕掉后,并丌 能安全的将服务切换到备集群  改进:实现类似Google MegaStore的同步跨机房 备份  说明:并丌能通过简单将push过程同步到写流程中 获得同步跨机房备份(因为整体可用性并未改善)
  • 欢迎联系,欢迎加入: mail : fenghonghua@xiaomi.com 微博:weibo.com/fenghonghua
  • 问题?