一文览尽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改进自然最好，但复杂度太高。