HBaseCon Asia 2018精华总结

本文针对HBaseCon Asia 2018大会的所有技术分享内容,做了简要的总结,希望能为大家带来一些帮助。因为这个总结存在较多主观的因素,难以概括到所有的要点,与演讲者自身希望传达的信息也可能存在较大的出入,如有理解偏差,欢迎联系本文作者交流或请直接留言。

文末部分给出了8月18号圆桌会议讨论的几点关键信息。

大会演讲议题与演讲者信息,请参考下图中的会议议程。文中内容聚焦于技术本身,将不再单独列出每一个议题的演讲者信息:

CCSMap & Efforts on SLA Improvement

CCSMap的原理,在阿里已经公开的一篇文章中详细公开过了。我们知道,MemStore的核心数据,存放在一个ConcurrentSkipListMap中(通常缩写为CSLM),但这个结构包含大量的冗余对象,也导致冗余的内存占用,对于Heap区的GC压力极大,因此,CCSMap的核心设计包括:自管理内存,采用内存分页的技术,显著改善内存碎片问题;采用无锁技术;去掉海量结构化JVM对象,减少冗余内存占用,从源头上有效控制GC问题。CCSMap再结合定制的JDK/GC算法,YGC/CMS的GC时间与发生频率均有了显著降低,而长达数十秒的Full GC问题已被基本消除。

第二部分内容,与SLA改进相关,包括:分离Client与Server端的ZooKeeper,分离Client与Server端的Meta访问请求队列,来有效避免Client过多的连接/访问而影响RegionServer正常服务;尽可能减少RegionServer Abort;加强RegionServer的健康自检能力;对于宽行(包含多列数据的行)数据的写入加以限制,否则对Handler的过长占用会影响整体的吞吐量等等。

HBase On Persistent Memory

随着3D XPoint的不断普及,现有的软件栈也将会发生较大的变化,这已经进入了一个硬件倒逼软件演进的时代。LSM-Tree的架构可以说是基于Disk的IO模型设计的,3D XPoint硬件技术的接入,可以说会颠覆现有的LSM-Tree架构,这个演讲的内容就介绍了HBase基于AEP之上所做的一些工作。

我之前曾经写过一篇文章《从HBase中移除WAL? 3D XPoint技术带来的变革》,里面有更加详细的阐述,这里不再过多展开。

HBase At Xiaomi

HBase在小米的应用现状:

数十个HBase集群,以在线集群为主,大部分集群被部署在公有云环境中。

数据可靠性方面,结合采用了容灾+备份能力,而且支持基于WAL的增量备份能力。

多租户实践:为HBase设置独立的HDFS集群;为重要的业务设置独占的HBase集群。

RPC消息流控机制:支持RCU与WCU的设置,同时考虑了请求的数据大小与请求数量。支持Hard Limit与Soft Limit两种模式,在Soft模式下,如果RegionServer的总体Quota没有超出,允许个别用户的请求超出Quota限制。关于流控,依然是DynamoDB的设计最为经典,但这两种情形有所不同,DynamoDB并不允许任意的超出Quota限制,它的机制是用户如果在上一个时间窗内的Quota有余留,可以补偿给下一个时间窗用来应对一些陡增的流量需求,也就是DynamoDB的Burst能力。

Synchronous Replication: 核心设计思想为,写Master Cluster WAL时,同时将这部分数据写到一个Standby Cluster的RemoteWAL中,现有的异步复制流程依然存在,数据复制过去后,将Standby Cluster中对应的RemoteWAL删除。如果Master Cluster集群故障,可能有部分数据没有通过异步复制流程复制过去,这部分数据在Standby Cluster中可以通过Replay RemoteWAL来回滚这部分数据。但这里的复杂之处在于如何应对各种故障场景。

HBase At Didi

滴滴内部关于HBase的应用类型,可以说非常丰富,包含了Phoenix,GeoMesa等等。

Replication方面,能够支持RS Group级别的数据复制;安全方面,结合现有的ACL框架,融入了用户管理能力,直接将用户信息存储在一个名为userinfo的系统表中。

滴滴在历史订单查询上,使用了Phoenix。在Phoenix的实践上,有几点关键分享:使用Covered Index,将一些关键数据存储在Index Table中,这样可以加速关键路径的查询;跨Coprocessor共享Connection,减轻对ZooKeeper的压力;采用Reverse RowKey + Pre-Split的设计避免数据热点。

GeoMesa部分,主要应用于Road Detection与Trajectory场景中。最后一部分是关于监控与运维方面的经验分享,涉及一些具体的监控指标项建议,这里不展开过于细节的内容。

HBase And OpenTSDB Practices At Huawei

HBase实践部分

1. HMaster启动时间优化:HMaster启动较慢的原因包括:加载Region的Data Locality信息非常耗时;因Namespace信息初始化失败导致Abort;TableInfo信息加载耗时过长。该问题在一个大集群中尤为明显。基于这几点原因做了针对性优化以后使得启动时间缩短至原来的1/3左右。

2. Replication增强:超时时间可自适应/自调整;支持Kerberos跨域互信;

3. Region Assignment可靠性增强,应对多种RIT场景以及Region双重部署问题。

4. MOB数据丢失案例分享:因Compaction时设置了Ignore MVCC,Compaction后的HFile中的Sequence ID被置为0,导致大量的数据行中的MOB File指针信息失效,读取时遇到FileNotFound Error。最后只能通过临时开发的工具来重建 MOB File的索引信息。

OpenTSDB实践部分

先简单普及了OpenTSDB的基础概念以及基础流程,而后重点介绍了针对OpenTSDB的优化:

1. OpenTSDB Compaction下移:原来的OpenTSDB Compaction流程需要将数据从服务端读取到Client侧的TSD进程中,将一个时间线的过去一小时的数据合并后再覆盖原来的一行数据,这过程涉及严重的写放大问题。新的流程是在HBase Compaction执行的时候同步执行OpenTSDB Compaction,使得OpenTSDB写吞吐有数倍提升。

2. 线程模型优化:将原来的两层线程模型修改为三层线程模型,使得查询并发度有3倍以上的提升。

3. 支持Metric级别的数据生命周期管理。

HBase at Pinterest

HBase在Pinterest的应用现状:

2013年开始在在线应用中使用HBase。

近50个HBase集群,采用1.2版本。

内部版本中包含的关键特性包括ZSTD, CCSMAP, Bucket Cache等等。

第一部分内容,主要是双活/容灾方面的实践,值得关注的一个能力为:为多个Source Cluster设置了一个共享的Replication Proxy,所有的数据都汇聚在这个Proxy中,数据本身带有Annotation信息用来标注数据的目标地址,这个Proxy的数据都发布到Kafka中,Annotation信息会被写到WAL中但在MemStore中会被移除。Pinterest使用HBase存储了一些关键的业务数据,因此,对高可用性的要求很高。日常备份数据存放在S3中,具体的备份方式按Snapshot + WAL备份结合,备份数据可被应用在离线数据分析中。HBase本身不支持直接将数据导出到S3中,只能通过HDFS周转,所以 Pinterest内部开发了将HBase数据直接备份到S3中的方案,HFile在上传到S3之前被预先切块。在备份HFile时,可能涉及到大量的重复文件,如第一天的备份中包含了HFile1,在第二天的备份中也同样包含了HFile1,因此,在Pinterest的方案中,实现了HFile去重能力。

HBase Heterogeneous storage based on layered compaction

基于Compaction机制实现的冷热数据分级存储方案,来降低冷数据的存储成本,提升热数据的查询性能。该方案在具体实现上参考了DateTieredCompaction机制,但在窗口划分上有所变化。数据RowKey中带有数据的业务时间戳信息,Compaction执行时,参考该业务时间戳区分Hot/Warm/Cold数据,而后将不同热度的数据写到不同的HFile中,不同热度的HFile文件还可以选择不同的压缩编码/存储策略。在查询上,尽量在查询之初根据业务时间戳将冷数据HFile过滤掉,结合(Prefix) Bloom Filter以及Lazy Seek特性,来对一些具体的查询场景进行优化。

值得一提的是,在HBaseCon Asia 2017烽火的演讲中,也曾介绍过一个简洁的基于Compaction的分级存储方案。

HDFS optimization for HBase at Xiaomi

介绍了HBase在使用HDFS时的几点优化,包含Short Circuit Read的几点细节优化(Domain Socket连接重用加速Slot Releaser;Preallocate Shm等),HDFS配置优化(增大Backlog,Peer Cache Bucket Adjustment,降低超时等待时间从而可以快速响应),提前发现Dead Datanode能力。

Kerberos Based Authentication Solution

Hadoop/HBase的现有安全机制都是基于Kerberos实现的,而Kerberos无法与企业自身的身份认证系统进行集成,例如在公有云服务中,每家公有云厂商都有自己的身份认证服务,该服务就无法与Kerberos进行对接。Intel提出的HAS的方案,允许企业的第三方认证服务以插件化的形式接入,具体思路为:用户提交认证请求后,可以通过定制的插件连接企业的用户身份系统进行用户合法性校验,校验成功后为用户返回一个Kerberos TGT,用户基于TGT可正常访问现有的Hadoop系统。

该方案可以说是在不改动现有Hadoop安全框架的基础上,提出的一种”曲线救国”的策略,但Hadoop的现有安全框架仍然需要进一步演进。

Apache Kylin on HBase

大家可能都已经比较了解Kylin,它是一个基于Cube的ms级OLAP分析引擎,Kylin选择了基于HBase作为它的后端存储系统,这个演讲主要介绍了Kylin选择HBase作为后端存储系统的初衷,以及基于HBase的表设计细节。

MySQL Compatability for HBase

AntsDB中提供了基于MySQL Driver来访问HBase数据的方案,这很容易被拿来与TiDB对比,但两者的定位有显著不同:TiDB是一个完整的数据库产品,早期版本基于HBase,但现在已经基于自己实现的分布式LSM-Tree引擎,而AntsDB则紧抱HBase的大腿,充分利用HBase能力来提供MySQL的兼容性。AntsDB充分利用了Caching能力来加速查询,将分布式事务转换为本地事务,将Distributed Joins转换为Local Joins。AntsDB针对HBase的GC问题,也做了不少工作:大量使用Unsafe来改进Skip List, Cache, WAL以及Row Locking,尽量使用小于4G的Heap等等,改进后的性能数据:Scan 100万行/线程/秒,Insert 20万行/线程/秒。AntsDB的写入性能约为MySQL的9.3倍。

HTAP DB System: HBase Phoenix and Spark

Phoenix为HBase提供了SQL能力,但它所擅长的,其实只是一些简单的OLTP类型的查询,但疲于应对复杂的分析型查询任务,而复杂查询恰恰是SparkSQL擅长的。这个演讲的内容,就是基于Phoenix与SparkSQL来提供的一套统一的在线SQL分析引擎解决方案,这个架构可以说是一个典型的Lambda架构:Batch Layer基于Spark SQL实现,Serving Layer依赖于HBase/Phoenix来提供低时延查询能力,Speed Layer则基于Kafka/Spark Streaming。

关于Phoenix的最佳实践建议,包括:建表时配置UPDATE_CACHE_FREQUENCY;推荐使用Pre-splitting Keys而不是Salted Table,不要将SALT_BUCKETS误认为Pre-Splitting Regions;为Index Table指定Pre-Splitting信息;大表关联查询时要采用USE_SORT_MERGE_JOIN等等,另外,设计组合RowKey时要充分考虑查询条件字段信息,大表中应该使用Global Index,应控制索引的数量避免对写入吞吐量带来较大的影响。

SparkSQL On HBase部分,可以直接读取HFile文件,其它优化手段则是比较常见的Partition Pruning, Column Pruning, Predicate Pushdown等。

JanusGraph on HBase

图数据库技术目前已经越来越火热,JanusGraph是一个分布式图数据库技术,后端可以支持多种存储系统,这个演讲介绍了JanusGraph on HBase的设计细节。

在这个公众号中,我们也曾写过两篇文章,详细剖析了JanusGraph的Property Graph在HBase表中的设计细节,以及关于JanusGraph/Titan的待改进点,供参考:

图解JanusGraph内部数据存储结构

从扩线查询能力分析分布式图数据库Titan的设计改进点

Scaling 30TB’s of Data Lake with Apache HBase and Scala DSL

这个演讲围绕零售分析案例展开, 介绍了他们的数据湖处理平台。零售分析业务定义如下:

Explain the who, what, when, where, why and how they are doing Retailing.

典型的业务场景举例:

1. 在合适的地点与合适的时间进行合适的推销

2. 一个消费者在这个商店中购买了什么样的香烟?从而基于该信息为未来的购买进行预测

3. 消费者的购买模式是什么,有哪些商品通常会一起购买

4. 商品的时序特点,按年/月/周/日区分不同的商品应该适合在什么样的商店销售

零售分析案例的业务挑战有:

数据按周更新,每周有46亿条事件数据。

历史数据处理:一次Bulkload共导入约30TB/近170亿条事务记录。

关联查询约涉及170亿条事务记录,而且数据带有偏态分布特征。

有数据去重的需求。

在这个数据库处理平台中,以HBase(0.98.12)作为主存储系统,结合了Kafka、Spark Streaming、Elasticsearch、Spark、Presto、Hive等技术。最后还介绍了Spark HBase Connector,专门为Spark访问HBase定义了强大的DSL语法。

HBase Real-Time Cold Data Backup

一个独立于HBase进程之外部署的实时冷数据备份方案,全量备份基于HFile的Copy,而增量备份则基于HLog。

基于HFile的复制,一个最基本的问题就是HFile时常发生变化,如Compaction,Region Split等等,解决这个问题的思路为:当要复制的HFile不存在时,则刷新列表然后进行重试(如果复制了一半,是否意味着要全部重做?为何不尝试去归档路径中寻找不存在的HFile文件?)。增量数据基于HLog进行,在一个外部的Log Tracker中跟踪所有新产生的日志(HLog老化被删除如何应对?),新产生的HLog全部记录在ZooKeeper中,然后由多个Worker进程执行HLog复制操作。

Serving Billions of Queries In Millisecond Latency

来自Bloomberg的Niju Nair为大家分享了关于HBase的理解,主要是一些的基础内容,涉及HBase数据模型介绍,数据分片与数据排序,Table/Versioning/ACIDity,Cache,Compaction,Short Circuit Read,GC,Region Replica,Monitoring等等。

值得关注的地方在于,演讲中提供了一些有价值的参考数据:不同的HFile Block Size的读取时延的差异(16KB Block Vs 64 KB Block)以及Bloom Filter数据与Index数据所占用的大小信息;61GB Cache与93 GB Cache在查询时延上带来的差异;启用Region Replica时,将Primary Call设置不同的超时时间对Stale Calls数量的影响等等,限于篇幅这里不贴出具体的图片内容,感兴趣的同学可以查看本文附件中的内容。

HBase at China Telecom

HBase在中国电信的应用现状:

HDFS集群拥有322台物理机,32 Cores, 256GB Memory, 3.6 T * 12 Disk。

共有6个HBase集群来应对不同的应用类型,包含在线应用,Kylin,Streaming任务的持久化等等。

共有520TB数据,每天的增量数据为1TB。

HBase版本为1.2.0。

演讲中介绍了数据采集系统到核心系统的架构方案,涉及Kafka,Spark Streaming,HBase,Hive等组件,而后围绕DPI Data Service以及基于位置的数据服务介绍了基于HBase的在线读写应用。基础Metrics监控信息,基于Ganglia来提供,告警则基于Zabbix。在HBase优化方面,从CMS算法切换到了G1,并且采用了读写分离策略,这里的方案未见具体的细节。

HBase Practice At China Life Insurance

HBase在中国人寿的应用现状:

3 Clusters,200+ Nodes。

HBase数量总量在300TB+;最大的表的数据量为30TB+,共有2500个Region。

数据处理:每天有数百个MR/Hive/Spark任务,每天的增量数据有50TB+。

每天共有数千万查询请求。

演讲重点涉及三部分内容:应用场景介绍;HBase应用优化实践;遇到的几个典型问题。重点提一下人寿在应用场景:采用宽表设计,在一行数据中尽可能存放所有信息;数据从RDBMS导入HBase的方式为:RDMBS -> TextFile -> HFile -> BulkLoad;数据处理阶段,构建索引信息;构建了一个以Entity为中心的统一查询服务,提供类SQL查询接口;存放与HBase中的数据导出到Hive中以供批量查询与分析。

HBase Practice At ke.com

贝壳使用HBase主要是因为在业务中广泛使用了Kylin。Kylin的应用现状:

800+ Cube、16+业务应用

数据总量为200TB,1600亿条数据,每一个Cube中关联60亿数据

查询请求100万次每天,95%的查询请求时延在500ms以下,99%的查询时延小于1秒

使用HBase时所用到的优化举措包括:利用HDFS Short-circuit Read;Data Hedged Read;利用MultiWAL提升写入吞吐量。

HBase Practices At Meituan

在美团的分享中,共涉及三个方面:

1. 多租户实践:利用RS Group/DN Group特性来支持异构集群环境,不同的RS Group/DN Group可能涉及不同的资源配置类型。Replication能够支持按RS Group级别进行同步,同样的实践在前面滴滴的分享中也提到了。

2. 对象存储:涉及HBase MOB特性的应用。

3. 大查询隔离:大查询可能会过长时间占用Handler线程资源,如果与Get/Small Scan使用相同的Queue/Handlers,这将会导致所有的Handlers变的拥堵,因此,为大查询设置了独立的Queue/Handler来有效解决该问题。

The Application Of HBase in New Energy Vehicle Monitoring System

在新能源汽车监控系统中选型HBase的初衷以及所遇到的挑战。

选择HBase的初衷为:高写入性能;低查询时延;易横向扩展;基于Phoenix能提供SQL访问接口等。

使用HBase所遇到的挑战/痛点:RowKey设计门槛过高;HBase自身不支持二级索引,只能依赖于Phoenix;表设计需要认真理解业务需求;复杂查询很慢,即使Phoenix提供了SQL与索引能力,查询在未命中任何索引是时延过高。

圆桌会议讨论

1. 会议开始,Stack主动征询大家关于版本可靠性/性能测试的方法。

2. 将基于JIRA的work-flow迁移到Github的可能性,因为习惯使用Github的用户更多。

3. 关于HBase易用性提升的几点建议,可以允许用户基于WebUI进行建表,查询等基本操作。

4. 3.0版本关键特性的几点畅想:

1) Native SQL的支持。这次大会中,可以说听到了诸多关于Phoenix的吐槽,所以希望HBase能提供一些简单的SQL查询能力。

2) Secondary Index的支持。

个人观点:HBase的SQL与Secondary Index的确已经是越来越普遍的需求,但是否应该将这些内容在HBase Kernel中,却是值得商榷的。HBase Kernel部分本应该保持它的精简性,Kernel就应该聚焦于提供简单的基于KeyValue模型的接口即可,但现在已经变得越来越”臃肿”。个人更希望将Secondary Index与SQL放在一个外部项目中实现,如果可以基于Phoenix改进自然最好,但复杂度太高。

One comment

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注