Hi there 👋

I recently had the pleasure of joining Databricks, but I often reflect on my profoundly rewarding experience at ByteDance. Before joining ByteDance, I was a software engineer who had written code for a decade. My core responsibility was to tackle system design and code development for complex software while ensuring robust operations in production environments. At ByteDance, however, I led a 16-person technical team (mostly Senior+ engineers) responsible for building the competitiveness of ByteDance’s public cloud EMR open-source engines—a role that was immensely challenging yet transformative for me....

This is the second article of my thoughts for Iceberg Summit 2025 (Here is Part-1), which is not limited to Iceberg but focuses on Data Lake. I am trying to share what these creative teams are doing in this field, why it is a problem, what the solution is, and how it will develop in the future. These insights come from various sharing, discussions, and debates, but are limited by my personal understanding....

I attended the Apache Iceberg Summit 2025 in the US in the past two days. The conference was held at the Hyatt Regency Hotel next to Union Square in downtown San Francisco. This time, two floors of the hotel were rented as the venue. Mainstream companies in the Data field are basically sponsors of the conference, including AWS, Databricks, Snowflake, Cloudera, Dremio, Microsoft, Airbyte, CelerData, Confluent, eltloop, Google, IMB, Minio, Qlik, Redpanda, Starburst, StreamNative, e6data, daft, PuppyGraph, RisingWave, Telmai, wherobots....

最近读了一下 Microsoft 在 2015 年 VLDB 上发表的论文 《Real-Time Analytical Processing with SQL Server》[1]。SQLServer算是业内较早实现并落地 HTAP 行列更新方案的产品，我其实觉得 行存（Row-Wise Index） 在OLTP场景下的各种设计以及取舍，大家都已经讨论的非常清楚了。对于高效率的 毫秒级列存更新 方案，业界有一些方案设计和实现，典型的如Kudu[2]、Positional Delta Tree[3] 等，但远不如行存讨论的多。我仔细的 Review 了一下 SQLServer 的技术方案，觉得他们的设计还是颇具参考意义。本文分享一下我对这篇文章的一些看法。 论文主要讲了 4 个方面的话题： 内存中实现列存表； 对于行存表，怎么实现一个列存索引结构，从而实现分析型 SQL 的极大提速。这部分的重点就是怎么实现列存二级索引的实时更新； 对于列存表怎么实现一个 B-Tree 的二级索引，使得这个列存表可以用来做点查和小范围扫描； 计算层在列存表的扫描性能上做了哪些优化。 第1部分纯内存的列存表相对比较简单，第4部分的列存表扫描在业界的很多论文中都可以找到类似的方案。第2部分和第3部分相对比较独特，可以说是整篇文章的精华，也是我比较感兴趣的部分。 其实第2部分，可以认为是在一个已经存在的OLTP表上，怎么来创建一个OLAP的列存索引，使得这个表可以跑 “TP为主，AP为辅” 的两种QUERY；而第3部分正好完全相反，相当于是在一个纯粹的OLAP列存表之上，创建一个适合做 点查 和 小范围 查询的行存索引，使得这个表可以完成 “AP为主，TP为辅” 的混合QUERY。 “TP为主，AP为辅“ 的索引方案 SQL Server的这种 CSI （Columnar Store Index）更新方案，说实话其实在 写入延迟 和 读取延迟 上处理的还算比较恰当。对于列存索引来说，如果是 INSERT 的话，那么直接 Append 到 Delta Store 里面就行，没啥其他的额外耗时操作；如果是 DELETE 的话，先看一下 DELETE 的 key 是否在 Delta Store 里面，如果在就直接删除即可；如果不在，就插入一条 Delete Marker 到这个由 B-Tree 索引实现的 Delete Buffer。无论是 INSERT 还是 DELETE 操作，都没有特别耗时的地方。可能往 B-Tree 索引实现的 Delete Buffer 里面写 Delete Marker 会有点儿耗时，但这个 Delete Buffer 一般都是最近更新比较热的数据。首先体量不会特别大，其次，大部分的都是热数据，都会被 Cache 到内存。然后，后台有一个任务， 会默默地把 Delete Buffer 里面的 Delete 操作都转换成 Delete Bitmap。...

最近参加了TiDB的Hackthon2019比赛，一直都想写一篇总结，现在总算有点时间来写一下。 这是一个围绕 TiDB 分布式数据库展开的一个编程比赛，在 48 小时内完成一个可以展示的 demo，并在 6 分钟内向评委说明项目思路及展示demo。理论上，要求这个demo从实用性、易用性、性能三个方面来优化TiDB（占评分40%），“当然作品的完成度也是一个很重要的考核方向（占30%)，其他就是创新性（占20%）和展示度了（占10%）。 我们队共有三个同学：队长是来自 PingCAP 美国 office 的吴毅同学，他之前在 facebook 负责 RocksDB 的研发，目前在PingCAP 主要负责 RocksDB 的研发和性能优化，另外一个北京 office 的张博康同学，负责TiKV的研发。由于我们队三个人都是做存储底层的研发，所以就想尝试在今年的 Hackthon 上做一些偏底层的工作。在比赛前，我们大致确认可能会尝试的几个小方向： 第一个是做一套 TiKV 的分布式 trace，用来跟进一个 TiKV 请求整个生命周期的耗时情况，便于诊断性能。由于这是一个非常普遍的方向，我们预估可能会有不少团队跟我们撞车，另外印象中现在 TiKV 已经实现了部分工作，所以就没有选择这个方向。 第二个是把一个图查询引擎套在 TiKV 之上，实现一个图数据库。我们初步想好可以用这个图数据库展示社交网络中的三度人脉。在不需要我们开发前端的前提下，可以借助开源的图查询前端来展示 demo，至少演示上不会吃亏。这个其实是一个不错的候选，但不确定工作量有多大，最后也没有选择这个方向。 第三个是用最新 linux 引入的高性能纯异步实现的 IO 接口 liburing 来重写部分 rocksdb 的实现，期望能给 TiKV 带来更好的性能提升。这个课题看起来跟我们三个成员的背景比较匹配，于是最终我们选择了这个课题。 我们队吴毅和博康选择在北京 office 比赛，而我离上海比较近，所以就去了上海。为此还申请了异地组队权限（感谢下PingCAP 开放的组委会），我们应该是唯一的三人两地的队伍了。 我们大致阅读了 liburing 的技术文档，大致确定可以尝试用这套异步 IO 接口重写 RocksDB 的写 WAL 流程和Compaction 流程。另外也调研到 facebook 之前已经尝试过用 io_uring 重写 RocksDB 的 MultiRead 实现，发现随机读的 IOPS 能翻三倍，接口延迟也下降不少，所以我们想用 TiKV 的一个场景来说明可以从中获得性能收益。...

HBase2.x的写入性能到底怎么样？来，不服跑个分！ 首先，简单介绍一下我们的测试环境：集群由5个节点组成，每个节点有12块800GB的SSD盘、24核CPU、128GB内存；集群采用HBase和HDFS混布方式，也就是同一个节点既部署RegionServer进程，又部署DataNode进程，这样其实可以保证更好的写入性能，毕竟至少写一副本在本地。关于软件版本，我们使用的HBase2.1.2版本以及HDFS 2.6.0版本，Java使用OpenJDK1.8.0_202。 对每一个RegionServer进程，我们正常的线上配置是50GB堆内内存和50GB堆外内存（RS合计占用100GB内存），其中堆内内存主要用于Memstore（~36GB），堆外内存主要用于BucketCache（~36GB）。这里，我们为了保证尽量跟线上配置一样，虽然现在是100%写入的测试场景，我们还是保留了50GB的堆外内存给BucketCache。 在搭建好集群后，我们提前用YCSB压入了100亿行数据，每行数据占用100字节。注意，压入数据时，采用BufferMutator的方式批量写入，单机吞吐可以达到令人恐怖的20万QPS，所以这个过程是非常快的。 正常写入性能结果 接着我们开始测试正常的单行Put（设置autoflush=true）延迟了。我们在100亿行数据集规模的基础上，用YCSB持续写入数据到HBase集群，将YCSB的性能数据制作成如下监控图： 首先，我们可以看到5个节点的总QPS在10w/s左右，单机QPS在2w+/s左右，avgLatency<4ms，P99-Latency<20ms。从基本面上看，这个数据还是很不错的。 但是，图中我们也能发现一些非常明显的问题： 1.QPS曲线呈现出明显的高峰和低谷，而且高峰和低谷是周期性出现的，大概15min出现一次高峰，对应的平均延迟(avg-Latency)也出现相应的周期性。这种不稳定的吞吐和延迟表现，对业务是非常不友好的，因为在低谷时期业务的QPS将受到极大的限制。 2.有时会出现大量P999为150ms的请求，P999曲线毛刺非常突出，而且毛刺点比平均的P999延迟要高100ms，这是一个非常令人困惑的数据。 3.P9999延迟出现部分超过1s的毛刺点。 优化毛刺 我们来分析上述几个问题的原因。首先，我们找了几个QPS低谷的时间点，去RegionServer的日志中看了下，确认低谷时间点基本上是 Memstore做Flush的时间点 。另外，确认P999毛刺时间点也是Flush的时间点。由此，推断出可能的几个原因有： 1.在测试集群中，每个节点的Region数以及各Region数据写入量都非常均衡。这样可能造成的一个问题就是，某一个时间点所有的Region几乎同时进入Flush状态，造成短期内磁盘有巨大的写入压力，最终吞吐下降，延迟上升。 2.MemStore Flush的过程，分成两步：第一步加写锁，将Memstore切换成snapshot状态，释放写锁；第二步，将snapshot数据异步的刷新成HFile文件。其中第一步持有写锁的过程中，是会阻塞当前写入的，第二步已经释放了写锁，所以刷新相当于是异步的，不会阻塞当前的写入请求。如果在第一步持有写锁过程中，有任何耗时操作，都会造成延迟飙升。 第一个问题在真实的线上集群其实不太可能发生，因为线上不可能做到绝对均衡，Flush必然是错峰出现。另外，即使绝对均衡，也可以采用限流的方式来控制Flush的写入速率，进而控制延迟。这个问题我们暂时可以放一放。 第二个问题，我们尝试加了点日志，打印出每次Flush时RegionServer持有写锁的时长。发现一些如下日志： “–> Memstore snapshotting cost: 146ms” 这说明在Memstore snapshot过程中，确实有一些长耗时的操作。在进一步核对代码之后，我们发现一个如下存在问题的栈： 换句话说，在Memstore Snapshot中调用了一次ConcurrentSkipListMap#size()接口，而这个接口的时间复杂度是O(N)的。也就是说，如果有256MB的Memstore，那么这个size()接口会逐个扫描Memstore中的KV，最终统计得出Map中元素个数。ConcurrentSkipListMap为什么要这么实现呢？因为ConcurrentSkipListMap为了保证更好的写入并发性，不会在更新删除Map时维护一个线程安全的size变量，所以只能实时的统计Map元素个数。 这是一个潜藏在HBase代码仓库中很长时间的一个bug，从0.98一直到现在的2.0，甚至3.0，都没有用户发现这个bug。更多详情可以参考HBASE-21738。 其实，找到了问题之后，修改起来也就很简单，只需要把这个耗时的size()操作去掉，或者用其他的方式来替换即可。 我们已经在各分支最新版本中修复了这个bug，建议对性能有更高追求的用户升级。当然，对此我们也做了进一步的性能测试： 从图中看出，至少我们把P999的延迟控制在了100ms以内，另外，我们也可以很容易发现P9999的毛刺也从之前的1000ms下降到200ms~500ms左右。这说明，上述fix对解决毛刺问题还是很有效果的。 采用In-Memory Compaction进一步优化毛刺 但事实上，就目前的情况来说，我们仍然觉得P999~100ms不够好，其实大部分的P999是小于40ms的，但由于毛刺的问题，还是把P999拉到了100ms。进一步分析日志之后，我们发现此时G1 GC的STW是影响P999最大的因素，因为毛刺点都是GC STW的时间点，而且STW的耗时正好是100ms左右。 于是，我们考虑采用社区HBase 2.0引入的In-memory compaction功能来优化集群的写性能。这个功能的本质优势在于，把256MB的Memstore划分成多个2MB大小的小有序集合，这些集合中有一个是Mutable的集合，其他的都是Immutable的集合。每次写入都先写Mutable的集合，等Mutable集合占用字节超过2MB之后，就把它切换成Immutable的集合，再新开一个Mutable集合供写入。Immutable的集合由于其不可变性，可以直接用有序数组替换掉ConcurrentSkipListMap，节省大量heap消耗，进一步控制GC延迟。甚至更进一步，我们可以把MSLAB的内存池分配到offheap内。从此，整个Memstore几乎没有堆内的内存占用。理论上，这个feature的性能表现将非常强劲，我们做个测试来验证一下。 测试环境跟之前一样，不同的是我们会将Memstore配置为CompactingMemstore。注意，目前我们的MSLAB仍然是放在heap上的（若想把MSLAB为offheap，需要设置hbase.regionserver.offheap.global.memstore.size=36864，相当于把36GB的堆外内存给MSLAB）。 RegionServer的核心配置如下： hbase.hregion.memstore.block.multiplier=5 hbase.hregion.memstore.flush.size=268435456 hbase.regionserver.global.memstore.size=0.4 hbase.regionserver.global.memstore.size.lower.limit=0.625 hbase.hregion.compacting.memstore.type=BASIC 最终，我们得到的In-memory compaction测试结果如下： 从图中可以非常明显的看出，P999延迟控制在令人惊讶的50ms以内，同时P9999控制在100ms左右，远低于之前的200ms~500ms。与此同时，吞吐跟平均延迟几乎没有任何损耗。如果使用堆外的CompactingMemstore，理论上毛刺会控制的更加严格，但有可能稍微拉升平均延迟。这里我没有再提供进一步的详细测试结果，感兴趣的朋友可以尝试一下。 总结 社区HBase2.1.2版本的写入延迟和吞吐表现都非常出色，但是某些场景下容易出现较高的毛刺。经过HBASE-21738优化之后，我们已经能很好地把P999延迟控制在100ms左右。这中间大部分时间点的P999<40ms，少数时间点因为GC STW拉高了P999的表现。接着，我们采用堆内的In-Memory Compaction优化之后，P999已经能控制在满意的50ms以内，甚至P9999可以控制在100ms以内。从这些点上来说，HBase2.1.3和HBase2.2.0版本已经是性能非常强悍的版本。

我在 Apache HBase 社区工作了一段时间后，发现有一些精力过人的大咖：十年如一日持续不断贡献的Michael Stack、最近晋升为HBase项目主席的张铎。先说说Stack，一个60后的资深工程师，按辈分我应该叫声大伯，这位大伯精力过人到什么程度呢？我早上打开邮件发现Stack刚回复一个JIRA，到了下午14点打开邮件又发现Stack刚提了个patch；晚上23:30打开邮件居然发现Stack又评论了一下别人刚提交的patch。大伯工作的时间居然能覆盖我整天的工作时间。再说说张铎，就是那个雷军曾在文章中叫过一声铎神的男人，他坐我右手边，我比较了解：白天大部分时间都在各种开会，到了下班不开会了就开始在社区各种写代码了。另外，几乎每个周末都有几个JIRA被他从Create到Resolved吧。 我挺好奇，为啥社区的大佬们都能如此全情投入？不久前看到一个“增强回路”的词，我才有了一点自己的理解。简单来说，就是A刚开始做了一件事情后，收到了一些正面的反馈（有可能是偶然的），然后激发A用更大的热情去做这件事，后面又收到更加强烈的正面反馈，于是A能以更大更持续的热情去做这件事情。我觉得Stack大伯和铎神，应该是走在各自的“增强回路”上的，所以他们才有这么大的热情投入社区。 其实HBase开源社区同样需要一个“增强回路”。首先，有一个非常活跃的研发团队持续不断的优化和改进HBase；然后，用户根据需求找到一些竞品，在各种权衡之后，发现当前的最优解是HBase，选定HBase作为他们的基础依赖；后来，体验很好的用户会向更多人自发推荐HBase，部分用户会发现一些HBase问题和Bug，少数用户着手参与社区解决问题；最终，社区吸引了更多的人参与这个项目，包括推广、答疑、分享、改进、优化HBase。 目前HBase社区是非常活跃的，在2018年度评估中，HBase活跃度在整个Apache项目中排行第二。用户的基数也很大，尤其是国内，HBaseConAsia2019大会吸引了2万用户观看现场直播。但HBase不同于其他开源项目的是：背后并没有一家占据压倒性的商业公司来全权负责项目推广和分享。对用户来说，官方文档和技术博客是一个很好的学习渠道，但当很多人问到希望推荐一本讲HBase原理的书时，我们全都有点不知所措了。所以，我和范欣欣决定写一本结合HBase实践讲原理的书，于是就有了这本《HBase原理与实践》。 说实话，对于工程师来说，写作一本书比写代码投入的精力要多很多，毕竟是从一个轨道切换到另外一个轨道：代码是精确计算的，文字是模糊表达的。为了做到深入浅出，我们不得不做很多铺垫、提炼、推理、提醒、揭示、总结，以便读者们能顺着我们的思路来理解。尽量把一个严谨的工程项目掰开、揉碎、拼接、组织，最终把一个好故事讲的符合逻辑，还能圆满大结局。这真是把我和范欣欣累坏了。 这里，跟大家分享一下本书的一些数据： 1.为了做到从设计角度（而不是源码角度）讲清楚HBase的运行原理，我们在320页的书中，设计了200多幅插图，堪称图解HBase； 2.为了把这本书的故事讲圆、讲通，我、范欣欣以及本书编辑吴怡老师每人通读了不下20遍； 3.为了帮助读者真正理解HBase，我们设计了近50道的思考练习题（包括编程题和设计题）。这是和市面上同类型书籍区别最大的地方，因为我们认为：对读者来说，懂HBase并不是看了多少文档，读了多少行代码，而是解决了多少问题。解决问题的速度和难度是深入理解与否的唯一评判标准。 总的来说，我认为这是一本把HBase原理和实践讲通透了的硬核技术书，但绝对不会是一本让你读起来很轻松的技术书。 下面就是本书的封面和封底的设计了，希望大家喜欢。 当然，我们也非常荣幸地邀请到很多在业界有影响力的前辈为本书写推荐语。 关于本书上市 本书将在2019年9月13日左右在各大电商网站上销售，原价129元。今天到上市日这段时间，是本书的预售阶段，扫描下图二维码下单，只需99元即可获得如下三件套：纸质实体书+电子书+鲜读版作者原稿。过了预售阶段，原价129元只能买到实体书，电子书需要另外单独购买。所以，预售阶段购买是最划算的。我们觉得有责任和义务告知读者这件事情，这也是我们写这篇文章的目的之一吧。 当然，目前当当网和京东网也已经开放预售链接，有兴趣的朋友可以关注下。 当当网预售链接： 京东网预售链接 本书作者简介 胡争 小米公司HBase工程师，Apache HBase PMC成员，负责Apache HBase项目研发及小米HBase集群维护，对HBase及相关分布式存储系统有很多独到的见解。开源技术爱好者，长期活跃在Apache开源社区，热衷技术分享，博客地址: http://openinx.github.io。 范欣欣 现就职于网易杭州研究院数据科学中心，负责HBase以及分布式时序数据库的内核开发运维工作，对HBase的底层工作原理进行长时间的探索和深入研究，撰写了大量有关HBase和时序数据库相关的技术文章，深受读者好评。此外，对大数据生态以及数据仓库有深刻而独到的理解。博客地址: http://hbasefly.com。 利益相关声明 首先，关于定价部分，我和范欣欣作为作者是没有太多话语权的。抛开定价，无论是本书内容还是排版质量，都应该是很棒的。注意，本书并不是传统的黑色印刷，而是双色印刷，即采用黑色和蓝色两种颜色印刷，使得读者的阅读体验更佳。 其次，销售额10%左右作为版税由两位作者平分，相信写过技术书的朋友都知道，2万册销量的技术书已经属于畅销书。受限于HBase的用户总基数，这个版税收入对我们接近两年的业余投入来说，几乎没有任何吸引力，但我们还是去做了这件事，因为我们觉得这将是让用户和HBase社区走向更好“增强回路”的一件事情。 最后，这是一本献给Apache HBase技术社区的书。感谢那些年复一年、日复一日不断贡献和反馈的PMC成员、Committer、Contributor以及庞大的用户群体，你们都是这个项目的 Super Hero！

HBase2.0.0版本自2018年4月30日正式发布起， 到现在已经过了接近15个月。现在的状态是HBase2.0.x已经EOL了，后面不会再发新的Release版本了，HBase2.1已经发布到HBase2.1.6了，个人预计将来也不会维护太长的时间。今后的HBase2.x的稳定版本将会是HBase2.2.x和HBase2.3.x，尤其是HBase2.2.x，可能成为未来真正意义上经过大厂线上严苛考验的版本。 这里，我总结一下未来HBase2.x上需要投入精力去做的一些事情： 1.ProcedureV2和AssignmentV2的引入，能通过框架的方式保证分布式任务流的原子性。这在HBase1.x上曾经是一个非常令人困惑的麻烦。举个简单的例子，在建表流程中，会分成几步：a. 在zk上加个znode；b. 在文件系统上新增表的目录；c. 生成Assign的任务，并分发到具体的RegionServer，让其执行online region的操作。在HBase1.x中任何一步异常了，都可能造成各状态不一致的问题发生，极端情况下可能需要通过类似HBCK这样的工具来进行修复。但在HBase2.x中，已经通过框架来解决了这个问题。需要人操行的地方少了，那代码需要操心的地方就很多了，由于各个任务流都采用Procedure V2进行重写，中间难免会一些bug，所以，后续将这块功能变得更加稳定，是一个优先级非常高的工作。 2.HBCK2支持修复更多的场景。虽说采用ProcedureV2之后，各Region状态不一致的概率大大降低了，但仍然难保可能会存在代码bug，导致有问题。目前的HBCK2主要支持修复Region Assign／UnAssign这样的问题，对于类似Region重叠和空洞这样的问题，期望HBCK2也能得到支持。这样即使集群出问题了，也有合适的工具能辅助修复。 3.In-Memory Compaction功能。可以说这是一个性能优化进步很大的功能，在我们大数据集(100亿行数据)的测试情况下，写入操作的P999延迟可以严格控制在令人惊讶的50ms以内，而且延迟非常稳定。但是社区考虑到其功能的稳定性，暂时没有把它设为默认的Memstore，也就是说默认的Mmestore仍然是延迟控制较差的ConcurrentSkipListMap实现的DefaultMemstore。在我们的测试环境，确实也发现了一些很难定位的BUG，例如HBASE-22608。因此，将这个功能弄的更稳定也是优先级特别高的一个事情。 4.MOB这个功能很好，可以通过同一个API处理各个Value大小的Cell，而且原子语义等跟正常的Cell完全一致。但当前的方案仍然有一些缺陷，例如MOB的大Value compaction现在是由Master端来负责跑的，这种Compaction的数据量会是一个巨大的量，单点来做会非常耗时，毕竟单机网卡流量和CPU资源都非常有限。理想的方案是分担到各个RegionServer去做，但目前还没有实现，这也就是一个必须要做的工作。 5.在读写路径上引入Offheap后，有时候目前会碰到一些字节错乱的bug。这种bug只在特定条件下才触发，不易复现极大地增加了定位问题的难度，而且预计未来可能会碰到一些Memory Leak的问题，毕竟自己管理内存之后，就有这种可能。所以，这块也需要考虑。 6.在HBase2.x中，除了Flush和Snapshot两个流程之外，其他的管理流程全部都Procedure-V2化。所以将Flush和Snapshot搞成Procedure-V2的写法，也是一个非常必要的工作。毕竟现在既有ProcedureV1的写法，又有Procedure-V2的写法，让代码显得较为冗余，搞定了Flush和Snapshot之后，ProcedureV1的框架就可以完全清除掉了。 7.Replicaiton现在仍然是走ZK的，开启串行复制之后，每个Region都会在ZK上维护一个znode。这在大集群上可能会对ZK造成很大的压力。所以Replication从存ZK改成存Meta，也会是一个很必要的工作。之前我尝试去做这方面的研发，后面发现一个比较重要的问题，就是启动时Master和RegionServer死锁的问题，要解决这个问题可能需要对Master启动流程做一些调整，会有一些额外的工作。当时有其他优先级更高的事情，就干其他事情去了，从长远来看，改成走Meta是必须的。 8.CCSMap是阿里巴巴研发的内存压缩型ConcurrentSkipListMap，对写路径上的GC非常友好。目前社区还没有人力投入到Merge到master分支的工作上，未来期望是把它做成一个可插拔的组件，甚至是一个单独的依赖。可以随时替换掉JDK内置的ConcurrentSkipListMap，而且适用于除HBase之外的其他项目。 9.多级BlockCache，L1存Index/DataBlock、L2是基于offheap的BucketCache、L3是基于SSD的BucketCache。这样可以优化掉HDFS的协议栈，同时解决掉locality的问题。读性能能得到很好的优化。

第三届Apache HBaseConAsia 峰会将于7月20日在北京举行。作为Apache基金会旗下HBase社区的顶级用户峰会，HBaseCon大会是Apache HBase™官方从2012年开始发起和延续至今的技术会议。届时将有超20位来自亚洲一线互联网和大数据生态相关企业的技术专家和社区领袖亮相，带来HBase及大数据技术生态的最新洞察和行业实践。 Apache HBase是基于Apache Hadoop构建的一个高可用、高性能、多版本的分布式NoSQL数据库，是Google Big table的开源实现，通过在廉价PC Server上搭建起大规模结构化存储集群，提供海量数据高性能的随机读写能力。 伴随着移动互联网和物联网时代数据的爆炸性增长，HBase作为基础存储系统得到了快速发展与应用。阿里、Facebook、雅虎、小米、华为、腾讯、京东、滴滴、网易、360、快手等众多国内外顶级互联网公司先后成为HBase的重度用户，并深度参与项目优化与改进。目前，中国力量已成为HBase生态积极壮大的核心源动力，国内共有5位PMC成员和17位HBase Committer。其中小米公司累计培养2位PMC成员和9位HBase Committer。 精彩演讲，先睹为快 开场演讲 演讲嘉宾：崔宝秋（小米集团副总裁、技术委员会主席） HBase现状与未来方向 演讲主题：HBase现状 内容简介：具有里程碑意义的HBase2.0.0发布不久，HBase3.0.0已经呼之欲出。资深PMC张铎将与您一起讨论HBase2.x以及HBase3.x的现状和核心改进。分享将包括Procedure-V2、Assignment-V2、HBCK2、跨机房同步复制、异步客户端等核心主题，干货十足。 演讲嘉宾：张铎（HBase PMC成员，小米存储团队负责人，小米开源委员会秘书长） 演讲主题：HBase在云上的优势及技术趋势 内容简介：与传统的物理数据中心相比，HBase在云上的优势是什么？构建云HBase的挑战是什么？未来的技术趋势是什么？这些都将是本次演讲要讨论的重点。除此之外，还将包括以下内容： 1.为何HBase架构天然适用云环境 2.HDFS构建在云盘上的挑战 3.HBase如何充分利用不同的云存储介质 4.HBase Serverless的实现和价值 5.借助云端虚拟机的拓展能力，HBase还能可以做些什么？ 6.云端HBase如何从GPU，FPGA等新硬件中获益？ 演讲嘉宾：沈春辉（HBase PMC成员、阿里巴巴资深技术专家） 演讲主题：HBase BucketCache with Persistency Memory 内容简介：Intel的DCPMM (Date Centre Persistent Memory devices) 是一种新型的非易失内存技术。该设备支持更大内存容量的同时，还能保证数据的持久性。英特尔的资深工程师团队将分享如何将HBase BucketCache构建在这些大容量的非易失内存上，同时将给出具体的性能对比数据。 演讲嘉宾：Anoop Jam John （HBase PMC成员）、Ramkrishna S Vasudevan (HBase PMC成员)、Xu Kai ( Intel 工程师） HBase2.x内核改进 演讲主题：Further GC optimization: Reading HFileBlock into offheap directly 内容简介：HBase2.0.0版本已经将最核心的读写路径做了offheap化，极大的降低了GC对读写请求延迟的影响。但在性能测试中，我们发现当cache命中率不高时，读请求的P999延迟几乎和GC的Stop The World耗时一致。本次分享，将讲述Intel工程师和小米工程师如何一起携手展开一场极致的GC优化之旅。...

初衷 对数据库来说，满足业务多样化的查询方式非常重要。如果说有人设计了一个KV数据库，只提供了Get/Put/Scan这三种接口，估计要被用户吐槽到死，毕竟现实的业务场景并不简单。就以订单系统来说，查询给定用户最近三个月的历史订单，这里面的过滤条件就至少有2个：1. 查指定用户的订单；2. 订单必须是最近是三个月的。此外，这里的过滤条件还必须是用AND来连接的。如果通过Scan先把整个订单表信息加载到客户端，再按照条件过滤，这会给数据库系统造成极大压力。因此，在服务端实现一个数据过滤器是必须的。 除了上例查询需求，类似小明或小黄最近三个月的历史订单这样的查询需求，同样很常见。这两个查询需求，本质上前者是一个AND连接的多条件查询，后者是一个OR连接的多条件查询，现实场景中AND和OR混合连接的多条件查询需求也很多。因此，HBase设计了Filter以及用AND或OR来连接Filter的FilterList。 例如下面的过滤器，表示用户将读到rowkey以abc为前缀且值为testA的那些cell。 fl = new FilterList(MUST_PASS_ALL, new PrefixFilter("abc"), new ValueFilter(EQUAL, new BinaryComparator(Bytes.toBytes("testA"))) ); 实际上，FilterList内部的子Filter也可以是一个FilterList。例如下面过滤器表示用户将读到那些rowkey以abc为前缀且值为testA或testB的f列cell列表。 fl = new FilterList(MUST_PASS_ALL, new PrefixFilter("abc"), new FamilyFilter(EQUAL, new BinaryComparator(Bytes.toBytes("f"))), new FilterList(MUST_PASS_ONE, new ValueFilter(EQUAL, new BinaryComparator(Bytes.toBytes("testA"))), new ValueFilter(EQUAL, new BinaryComparator(Bytes.toBytes("testB"))) ) ); 因此，FilterList的结构其实是一颗多叉树。每一个叶子节点都是一个具体的Filter，例如PrefixFilter、ValueFilter等；所有的非叶子节点都是一个FilterList，各个子树对应各自的子filter逻辑。对应的图示如下： 当然，HBase还提供了NOT语义的SkipFilter，例如用户想拿到那些rowkey以abc为前缀但value既不等于testA又不等于testB的f列的cell列表，可用如下FilterList来表示： fl = new FilterList(MUST_PASS_ALL, new PrefixFilter("abc"), new FamilyFilter(EQUAL, new BinaryComparator("f")), new SkipFilter( new FilterList(MUST_PASS_ONE, new ValueFilter(EQUAL, new BinaryComparator(Bytes.toBytes("testA"))), new ValueFilter(EQUAL, new BinaryComparator(Bytes.toBytes("testB"))) ) )); 实现 Filter和FilterList作为一个通用的数据过滤框架，提供了一系列的接口，供用户来实现自定义的Filter。当然，HBase本身也提供了一系列的内置Filter，例如：PrefixFilter、RowFilter、FamilyFilter、QualifierFilter、ValueFilter、ColumnPrefixFilter等。 事实上，很多Filter都没有必要在服务端从Scan的startRow一直扫描到endRow，中间有很多数据是可以根据Filter具体的语义直接跳过，通过减少磁盘IO和比较次数来实现更高的性能的。以PrefixFilter(“333”)为例，需要返回的是rowkey以“333”为前缀的数据。 实际的扫描流程如图所示：...