一文览尽HBaseCon Asia 2018大会精华内容

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

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

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的过长占用会影响整体的吞吐量等等。

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

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

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的应用类型，可以说非常丰富，包含了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实践部分：

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在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去重能力。

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

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

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

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

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

大家可能都已经比较了解Kylin，它是一个基于Cube的ms级OLAP分析引擎，Kylin选择了基于HBase作为它的后端存储系统，这个演讲主要介绍了Kylin选择HBase作为后端存储系统的初衷，以及基于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倍。

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是一个分布式图数据库技术，后端可以支持多种存储系统，这个演讲介绍了JanusGraph on HBase的设计细节。

在公众号“NoSQL漫谈”中，我们也曾写过两篇文章，详细剖析了JanusGraph的Property Graph在HBase表中的设计细节，以及关于JanusGraph/Titan的待改进点，供参考：

图解JanusGraph内部数据存储结构

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

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

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进程之外部署的实时冷数据备份方案，全量备份基于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在中国电信的应用现状：

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在中国人寿的应用现状：

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主要是因为在业务中广泛使用了Kylin。Kylin的应用现状：

800+ Cube、16+业务应用

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

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

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

在美团的分享中，共涉及三个方面：

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来有效解决该问题。

在新能源汽车监控系统中选型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改进自然最好，但复杂度太高。

hbase

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。