目前，各行各业都在根据自身需求加快自主改造研发的步伐，涌现出许多值得借鉴的优秀项目。本期将详细介绍光大银行首款自主研发的基础软件Pharos如何从HBase二级索引入手，提升多条件复杂查询的性能，扩展HBase的数据使用模式，应对海量低延迟复杂查询。数据。自主研发的可插拔HBase索引组件NoSQL的兴起，无疑是大数据时代的标志性事件。创新者不断打破关系数据库“一种存储模式解决所有问题”的思路，发明出许多不同的产品来处理细节。不同的数据访问方式，它们提供了更好的服务特性，如低延迟、高并发等。HBase是其中非常有代表性的产品。作为Hadoop生态系统的明星产品，如今已被众多企业广泛应用。NoSQL为特定数据使用模式设计存储系统的想法大大提高了性能，但随着存储数据量的激增，对该解决方案整体成本效益的满意度持续下降。毕竟与几TB和几百TB相比，存储成本对用户的影响是不一样的。人们总是不满足于线性增长的成本，希望花更少的钱做更多的事情。通过适度扩展数据访问方式来提升性价比，成为业界众多技术方案所追求的目标。中国光大银行率先在金融行业引入HBase，经过几年的建设积累了大量数据。各方为了满足不同条件的查询而复制一个大小相同的集群是不可接受的。作为KV数据库，HBase的数据访问方式是基于主键的。在面对非主键查询时，其原生的解决方案Filter无法满足大部分线上应用的性能需求。因此，很多基于HBase的二级索引解决方案都在尝试满足复杂查询场景的需求。Pharos是一个基于HBase的技术中间件。研究的起点也是二级指标。致力于提升多条件复杂查询的性能，适用于低延迟、海量数据的复杂查询场景。构建思路三种二级索引方案的选择与分析在开始研发工作之前，我们分析了现有的二级索引方案，除了原有的Filter外，大致可以分为三种。ElasticSearch+HBase是最流行的解决方案。索引信息存储在ES中，HBase存储数据本身，两者配合完成索引查询。该方案的优点是结合了成熟的产品，易于实施；但缺点也很多，首先，整体结构复杂，设备投资增加，运行维护成本高；第二，性能比较低，每次索引查询都要先访问ES获取索引匹配后，再访问HBase读取数据内容，扩展了查询链路，带来了更多的网络开销；最后，开发技能要求比较高，程序员必须熟悉ES和HBase这两个产品接口。PhoenixPhoenix无疑是一个优秀的开源产品。该产品的概念是将SQL放回NoSQL。成熟的产品和Apache社区的背书是该方案的优势。但由于目标远大，Phoenix的体量也比较重，因此如果没有商业厂商的支持，运维难度很大（2019年Cloudera宣布支持Phoenix后，可能会有所改善）。第二点，对SQL的支持成为了它的核心目标，但是在很多查询场景下，SQL并不是不可替代的，高性能是首要目标，性能是Phoenix需要提升的地方。在整体机制上，Phoenix并没有实现完整的索引下推。在很多情况下，索引查询需要从客户端发起与服务器的两次交互。第一次获取的是匹配索引信息，第二次是匹配数据。这无疑带??来了性能损失。云厂商解决方案在云计算时代，HBase已经成为云服务的标配，部分公有云还提供二级索引功能。该方案的优势当然是厂家一站式服务，运维成本极低。缺点首先是部分企业因为安全因素不能使用公有云，比如金融行业；其次是技术方案本身，比如阿里的HBase二级索引，其核心仍然是Elastic和HBase的结合，虽然在接口上的封装降低了开发难度，但是架构带来的性能损失依然存在。通过以上分析，我们发现这些方案都不能满足光大银行的应用场景，所以我们决定自己开发产品。我们将产品命名为Pharos，来源于英文单词【Pharos】，意为灯塔。这个名字有两层意思：一是本身的意思，灯塔为夜间航行的船只指引方向，确保它们安全进出港口。索引指向符合条件的数据地址，用于提高每次查询数据访问操作的效率。两者有相似之处；第二个意思，Pharos原指亚历山大港灯塔，也是世界上第一座灯塔。Pharos是光大银行首次尝试自主研发基础产品。我们希望这个名字能激发团队做出创新产品的灵感。设计目标低延迟、架构简单、非侵入式是Pharos设计目标中最重要的三点：嵌入到业务交易系统中。低延迟是硬性要求；架构简单：开发者容易上手，运维成本也低；non-intrusive：指的是对HBase的入侵，其实除了上面分析的二级索引方案外，还有一些小众的二级索引方案直接改造HBase，但是这种侵入式改造带来了后续的版本维护问题。考虑到大部分企业无法维护独立的HBase版本分支，我们的解决方案直接排除了这条技术路线，必须是对HBase无侵入的。Pharos的研发是从2018年开始的，相对于现在的产品成熟度来说，研发过程有点长，主要是开发人力投入比较少。我们希望随着产品的应用和推广，扩大人员队伍，加快产品的演进。在研发过程中，我们受到了很多同类产品的启发，包括凤凰、华为、360等公司的二级指标解决方案。DesignPoints四个关键的设计权衡我们前面讲了Pharos的外部特性，接下来我将重点介绍一些关键的设计权衡，希望对大家的研发工作有所帮助。存储策略HBase没有索引的概念。我们首先要解决的是如何存储索引。Pharos采用的方法是在数据表中增加一个“独立列族”来存储索引信息，利用独立文件对应的列族的特性，形成一个独立的索引文件，不会直接受到索引的影响。原始数据量并减少磁盘I/OO开销。这种设计还有一个好处就是索引和数据的分布是一样的，所以不需要去干扰HBase的Region分布策略。后续所有设计都基于同一个Region，大大简化了实现的复杂度。这种索引和数据共分布的模式，可以简称为“分区索引”；而索引和数据分开存储的方式称为“全局索引”。“全局索引”的缺点是无法完成索引查询的下推，优点是可以全局控制，比如唯一索引。我们选择“分区索引”是因为我们期望实现低延迟目标。当然，我们也放弃了对“唯一索引”的支持，至少目前没有。存储模型索引记录的关键部分是最开始的Region头信息，保证和数据同分布，然后是索引字段的信息，然后是存储索引名称等信息，最后是索引的key数据记录拼接成尾信息；值部分存储反序列化的元数据。可以看出这种设计的优点是索引检索速度快，存储开销比较小。因此，当查询条件复杂，需要建立多个索引时，整体存储成本还是可以接受的。分页机制传统的后台分页方式是应用服务在每页末尾记录主键。这个主键通常是数据库提供的行号，数据库本身是不感知分页动作的。对于分布式存储HBase，每个Region都可能有分页断点。如果继续这种思路，应用端会记录大量的断点信息，不仅增加了传输的数据量，也增加了开发的难度。在Pharos的设计中，我们以Client作为聚合点来缓存各个Region的断点信息，并在PharosClient中加入了Session的概念。应用程序只需要持有SessionID就可以顺利完成翻页操作。索引与数据的事务一致性（实验版）根据Pharos的存储设计，我们可以知道，索引本质上是另一条与数据行具有相同前缀的行记录。为了保证索引和数据的一致性，使用了跨行事务，但是HBase本身不支持跨表跨行事务就成了死锁，这也是几乎所有的二级索引方案都做的原因不支持索引事务一致性。这个问题的解决比较复杂，先简单介绍一下HBase的内部机制。HBase采用LSM-Tree模型。在线写入时，日志和内存中保留一份数据。两者可以通过MVCC和日志的协调机制保证事务的一致性。我画了一张图来表示HBase1.2.6的事务控制逻辑，如下：HBase内部会监听WAL异常，但是在Coprocessor事件系统中没有启用“回滚标志”，第三方开发者也无法回滚相关数据行。按说这里的问题是没有办法解决的，但是有一天碰巧受到Percolator事务模型的启发，找到了另一种解决问题的方法。由于写过程中无法通过回滚来控制异常情况，我们可以推迟读过程中对异常的补充操作，即在下一次查询操作中重新确认和维护索引的一致性。具体过程是在第一次写入索引信息时，将事务标志置为“不确定”，待数据行更新完成后，将标志改为“成功”；如果发生回滚，则该标志保持“不确定”状态。一旦在查询操作中发现“不确定”标志，则根据索引检查是否存在相应的数据行，如果存在，则将标志更新为“成功”.我们用一个流程图来体现处理过程，如下图所示：这种方式付出的代价是写入时事务标志需要更新两次，相对于只写入数据行来说肯定增加了一些开销（没有索引），在测试环境中，我们发现损失在15%左右，主要是指延迟；虽然在查询环节有确认索引交易的可能，因为它出现的概率极大低，不会对查询产生实质性影响未来展望彻底解决Region分裂问题目前Pharos主要测试内部使用场景，收集需求和问题，我们会在近期发布V0.3未来。新版本将引入一些激动人心的特性，主要围绕查询性能的提升，引入Pharos自身的数据组织形式，提供更丰富的查询加速方式，完成从二级索引组件到完整的技术中间件的演变。其中，最重要的一点就是彻底解决了Region分裂的问题，迫不及待的来剧透一下。Regionsplitting是一种对HBase数据进行再平衡的手段，保证各个数据节点上的数据量大致均匀分布，同时也会起到一定的降温作用。但是，拆分机制破坏了索引和数据的同分布。在类似的方案中，通常会使用大量的更新操作来调整索引的位置以跟随数据的分布。这种做法过于笨拙，更新过程会影响整体解决方案的可用性。因此，在V0.22版本中，Pharos建议将索引加载到后面，以便在数据更新引起的重分布完成后更新索引。在实际运行中，这种方式需要反复读取数据文件，拉长了整体的数据加载周期，对运维操作不够友好。在V0.3中，我们加入了Pharos自带的数据组织方式，以保持Region分裂时索引相同的分布效果。作者介绍王雷（Ivan），光大银行科技部数据领域架构师。曾就职于IBM全球咨询服务部，从事技术咨询工作。在数据领域拥有十多年的研发和咨询经验。目前负责全行数据领域系统的日常架构管理、关键系统架构设计和内部研发，对分布式数据库、Hadoop等基础架构的研究有浓厚的兴趣。本文转载自微信公众号“DBAplus社区”，可通过以下二维码关注。转载本文请联系DBAplus社区公众号。
