slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
HBase 在小米的应用和扩展 冯宏华 小米云平台组 PowerPoint Presentation
Download Presentation
HBase 在小米的应用和扩展 冯宏华 小米云平台组

Loading in 2 Seconds...

play fullscreen
1 / 32

HBase 在小米的应用和扩展 冯宏华 小米云平台组 - PowerPoint PPT Presentation


  • 223 Views
  • Uploaded on

HBase 在小米的应用和扩展 冯宏华 小米云平台组. HBase 在小米的应用现状 对 HBase 已做的改进与扩展 进行中 / 计划中的改进与扩展. 集群规模 15 个 HBase 集群: 9 个在线集群, 2 个离线处理集群, 4 个测试集群 服务小米内部十多个不同业务 几百台机器:每个数据节点 24 TB ( 12 * 2TB ). 应用场景 小米云服务 米聊消息全存储 小米推送服务 MIUI 离线分析 多看 离线分析. 部署 – 监控 – 报警 : Minos 自动化部署 集中监控、分类展示、表级指标聚合

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'HBase 在小米的应用和扩展 冯宏华 小米云平台组' - briar-maxwell


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

HBase在小米的应用和扩展

冯宏华 小米云平台组

slide2

HBase在小米的应用现状

  • 对HBase已做的改进与扩展
  • 进行中/计划中的改进与扩展
slide3

集群规模

  • 15个HBase集群:9个在线集群,2个离线处理集群,4个测试集群
  • 服务小米内部十多个不同业务
  • 几百台机器:每个数据节点 24 TB ( 12 * 2TB )
slide4

应用场景

  • 小米云服务
  • 米聊消息全存储
  • 小米推送服务
  • MIUI 离线分析
  • 多看离线分析
slide5

部署 – 监控 – 报警 : Minos

  • 自动化部署
  • 集中监控、分类展示、表级指标聚合
  • 已开源:https://github.com/xiaomi/minos
slide6

测试

  • Failover测试 (ChaosMonkey+)
    • 可配置/随机选择action
    • pre/post数据正确性验证
    • action/task 可重现
    • JIRA: https://issues.apache.org/jira/browse/HBASE-9802
  • 压力/性能测试
  • Longhaul测试
  • 可用性测试:HBase的ping
slide7

HBase在小米的应用现状

  • 对HBase已做的改进与扩展
  • 进行中/计划中的改进与扩展
slide8

Delete的语义校正

  • HBase目前的删除语义:
  • 一个deleteFamily/deleteColumn flag,如果其timestamp为T,则该flag对所有timestamp<=T的数据都起作用,无论这些数据写入时间在该flag之前还是之后写入 (只要该flag尚未被collect)
slide9

Delete的语义校正(续1)

  • 问题 1:
    • 用户写入一个数据成功返回后,立即发起对该数据的读(在此过程中确信无其他人/进程/线程读写该行),可能读不到该数据(该数据被一个以前写入的Delete 屏蔽掉了)
slide10

Delete的语义校正(续2)

  • 问题 2:数据一致性/正确性
    • delete kv with T1, flush
    • major compact: Y/N
    • put kv with T0, (flush?)
  • 何时/是否发生major compact影响T0的存在与否,但major compact对用户是透明的…
slide11

Delete的语义校正(续3)

  • 修复:校正后的Delete语义为Delete flag只能屏蔽该flag写入时真实的物理时间之前写入的数据,而不能影响到后写入的数据
  • JIRA: https://issues.apache.org/jira/browse/HBASE-8721
slide12

可控粒度跨机房备份

  • 问题:目前HBase的跨机房备份只有per-cluster粒度

Master :

T1/T2/T3/T4

Peer 1

T1, T2, T3, T4

T1, T2, T3, T4,

Peer 2

slide13

可控粒度跨机房备份(续1)

  • 改进:per-peer可配置从master集群replicate哪些数据(per-table / per-CF)

Master :

T1/T2/T3/T4

Peer 1

T2:cf1

T1, T3,

Peer 2

slide14

可控粒度跨机房备份(续2)

  • 优点:
    • 各peer可灵活配置从master备份哪些数据
    • peer无需创建所有master包含可复制CF的表
    • peer无需从master接收全量可复制的数据(节省机房间带宽)
  • JIRA: https://issues.apache.org/jira/browse/HBASE-8751
slide15

写吞吐性能优化 – 新写模型

  • JIRA: https://issues.apache.org/jira/browse/HBASE-8755
  • 效果:性能上限是改进前的3.4倍
slide16

反向扫描

  • 问题:HBase的数据模型不能自然地支持反向扫描(很长一段时间以来HBase没有此特性,询问此特性的用户也被告知此特性很难实现而被一直搁置)
  • 实现:通过“seekBefore + seekTo”定位当前行的前一行(无需buffer/cache block-data)
  • 性能:比正向扫描差30%(与LevelDB的下降相当)
  • JIRA: https://issues.apache.org/jira/browse/HBASE-4811
slide17

可配置比例/抢占式 block-cache

  • 问题:目前block cache是hardcoded的1:2:1(single : multi : memory),导致某些情形下内存表的Read性能比普通表还差
  • 修正:
    • 上述3者比例可配置
    • in-memory采取抢占式原则
slide18

DeleteFamilyVersion

  • 需求:
    • 删除给定column-family下所有timestamp为给定值的cell,而无需指定column名字
    • 确保性能(不能先读回timestamp==给定值的所有cell以取得column名字再逐一删除:引入读)
  • JIRA: https://issues.apache.org/jira/browse/HBASE-8753
slide19

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
slide20

region内跨行原子写

  • 现状:同一次batch操作的同region的跨行写不保证一次落地
  • 改进:同一次batch操作的同region的所有写在获得所有行锁后一次落地
    • 确保按照rowkey大小顺序取行锁,以防止多个并发batch操作时可能出现死锁
  • 作用:基于region内跨行原子写可实现native的局部二级索引(无需借助coprocessor)
slide21

HBase在小米的应用现状

  • 对HBase已做的改进与扩展
  • 进行中/计划中的改进与扩展
slide22

Compact优化(一)

  • Compact的HFile选择算法的比较-验证框架
  • 作用:方便快捷地比较各种compact算法的优劣
  • 思路:
    • 虚拟HFile生成器:随机间隔生成随机大小的虚拟HFile文件,并可重现
    • 可配置的compact“损耗”系数
    • 比较标准:生成器停止且compact稳定后,中间发生的虚拟IO值,越小代表越优
slide23

Compact优化(二)

  • Adaptive Compact
  • 问题:虽然各个RS均控制自己最多能同时触发的compact任务个数,但针对集群并没有一个整体的控制,而compact的io均由底层HDFS执行,占用的是整集群的io资源,这是导致所谓compact storm的原因
  • 改进:各RS发起compact之前,必须检查当前compactload是否已到达系统设置的上限,只有可申请到配额时才能发起(load由compact的IO文件数决定)
slide24

Failover优化(一)

  • HLog Reform
  • 问题:因为HLog文件是per-RS的,可能有某region写入稳定但很稀疏,从而导致其entry散落在很多HLog文件里,但又因为它写入总量少而未flush HFile,此时如果发生宕机,failover时需要split很多HLog文件,但其实每个HLog文件都只有该region的极少量数据
  • 改进:一个后台HLogReform线程,扫描较老的HLog文件,抛弃已flush成HFile的entry,将有效entry写入新HLog文件,结束后抛弃原始HLog文件
slide25

Failover优化(二)

  • 问题:split manager在某splitter超时后,会将该split task重新标记成unassigned,从而让其他splitter重新抢占;但一个超时task被其他splitter做极大可能也会超时,这样会导致一直无法成功
  • 改进:每个split task可允许同时有多个splitter,超时的splitter也继续做,先做完的splitter通知split manager,后者再取消其他仍在进行的splitter
slide26

Master重构

  • 目前Master的架构缺陷:
    • region task状态通过zk结点的update-watch-notify机制传递: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状态放在另一张系统表里
slide27

多租户

  • 问题:目前HBase不支持类似DynamoDB的provisioned throughput这样的限制各表throughput上限的特性,导致共享集群的各应用/表的性能无法得到保证
  • 改进:提供类似DynamoDB的per-tableprovisioned throughput,保证不会因为某个用户对共享集群的滥用导致其他应用的性能下降
slide28

全局事务 – 全局二级索引

  • 问题:HBase不支持跨表、跨行(跨region行)的事务,从而也无法实现全局的二级索引
  • 改进:实现类似Google Percolater的跨表、跨行事务,并基于此实现全局的二级索引
slide29

同步跨机房备份

  • 问题:HBase不支持同步的跨机房备份(用户的写由peer replication thread以异步方式push到peer cluster,用户得到成功写返回时,不能保证数据已经备份到peer cluster),这导致主集群整体宕掉后,并不能安全的将服务切换到备集群
  • 改进:实现类似Google MegaStore的同步跨机房备份
  • 说明:并不能通过简单将push过程同步到写流程中获得同步跨机房备份(因为整体可用性并未改善)
slide30

欢迎联系,欢迎加入:

mail : fenghonghua@xiaomi.com

微博:weibo.com/fenghonghua