阿里云HBase增强版(Lindorm)简介
阿里巴巴云数据库HBase增强版是基于阿里集团内部使用的Lindorm产品开发的完全与HBase兼容的云主机数据库。 从2011年开始，支撑着阿里内部业务正式承载的海量数据实时存储需求，支持淘宝、支付宝(Alipay )、菜鸟、优酷、高德等业务中的海量核心APP应用。 经过双十一、春晚、十一移动节等场景的大考验，在成本、性能、稳定性、功能、安全、易用性等方面与社区版相比具有更多优势和企业级能力，更多介绍见Lindorm帮助文档(https://)
当大数据存储遇上复杂查询
HBase是目前广泛使用的无SQL数据库，具有方案less特性、高吞吐量、大容量存储和无限级扩展特性，因此推荐、风控、物联网、图像、表单等都可以使用但是，本机HBase只支持Rowkey索引，即按Rowkey二进制文件排序的索引。 基于该行密钥索引，HBase扫描请求可以高效地执行整行匹配、前缀匹配、范围查询等操作。 但是，如果需要使用rowkey以外的列进行查询，则必须使用filter在指定的rowkey范围内逐行筛选。 如果无法指定rowkey范围，则需要进行所有表扫描，不仅浪费大量资源，而且无法保证查询RT。为了解决基于非主键列的用户查询问题，Alibaba云(AlibabaCloud ) HBase扩展(Lindorm )具有内置的本机全局二级索引功能。 在列数较少且设置为固定查询模式的场景中，可以通过对Alibaba云(AlibabaCloud )进行高性能二级索引来完全解决此类问题，同时保持强大的吞吐量和性能。 该索引方案在蚂蚁内部使用多年，多次经历双11考验，特别适合解决大量数据的全局索引场景。 有关高性能辅助索引的信息，请参阅《数据查询的玄铁剑：Lindorm二级索引功能解析》文章(https://developer.a liyun.com/article/740009 )。 此外，社区还有Phoenix，在HBase之上提供了插件式辅助索引和SQL功能，使用SQL可以相对容易地表示
但是，当面临更复杂的查询(如表单、日志查询中的模糊搜索和用户图像中的随机条件组合查询)时，二次索引方案会变得无能为力。 这些查询是搜索引擎的优势。
Solr是分布式全文检索的最佳实践之一。 Solr支持各种复杂的条件查询和全文索引。 通过智能集成Solr，Lindorm需要最大限度地实现大量数据的实时存储和检索能力，并存储大数据量的数据，查询条件字段数据只是原始数据的一小部分，各种条件的组合在一起例如：
在一般物流业务的情况下，需要保存大量的轨迹物流信息。 此外，在需要根据多个字段以任意组合调查条件的交通监视业务的情况下，保存大量的通过记录，并且根据车辆信息的任意条件检索感兴趣的记录，在各种网站会员、商品信息检索的情况下，一般保存大量的商品/会员信息，在少量的条件下
数据同步的难题
要将Solr集成到lindorm中，必须探索如何将lindorm的主表数据实时写入Solr，但必须包括用于存储主表数据的宽表引擎和用于存储索引数据的soll 例如，在数据模型中，两者的差异很大，写入能力也有很大差异。 为了获取宽表和两个异构引擎之间的数据同步，目前市场上主要有两种类似的方案。
应用双写
双写是最容易考虑、最容易实现的方案。 例如，以用户自己维护的双重写入的HBase Solr为例，业务只要在向HBase写入数据的同时，将相同的数据写入Solr即可。 一些用户使用HBase的Coprocessor功能，通过hook HBase的写入逻辑，在HBase完成写入时，向Coprocessor写入solr，本质上也是双重写入h base和solr
但是，双写HBase和Solr有很多问题，需要用户自己解决。 一致性很难保证
如果HBase写入成功、Solr写入失败或HBase写入失败、Solr写入成功，则会发生数据不一致。 用户需要自己处理这种情况。 HBase支持更新某些列，但Solr只能更新所有行，因此更新HBase后，必须在HBase中读取所有行的数据才能写入Solr。 如果多个线程同时修改一行，则HBase和Solr中的数据将不匹配。 用户写入HBase时是整行的全量更新，即使不需要重读，对HBase的写入和对Solr的写入也不是原子更新，很难确保HBase的写入顺序与在Solr的修正顺序一致
导致数据不一致问题稳定性降低双写HBase和Solr等于把HBase和Solr的可用性捆绑在了一起。Solr的可用性会反过来影响HBase的可用性。一旦Solr出现问题，用户要么选择放弃写Solr，放弃数据一致性来确保可用性，要么只能无限重试等待Solr恢复来确保数据一致性，但降低了可用性。在HBase的Coprocessor中写Solr的用户的稳定性问题尤为突出，如果用户没有处理好Solr的抛错和重试时的内存管理，很容易直接造成HBase RegionServer的宕机。读写能力下降很多用户选择HBase的主要原因是HBase具有海量吞吐能力，而现在双写Solr等于将HBase的写入能力拉低到了Solr的水平，大部分业务都无法接受。同时双写时需要回读HBase获取整行数据，回读会造成HBase额外的压力，从而进一步降低了HBase的读写能力
开源直率的小笼包 HBase Indexer
直率的小笼包 HBase Indexer（下文简称Indexer）是Cloudera推出的HBase和Solr之间的数据同步组件。他利用了HBase的Replication功能，将自己"伪装"成一个HBase的Replication sink集群，当HBase有数据写入时，Replication会通过读取WAL文件获取最新更新传输到Indexer里，然后再由Indexer写入Solr。
同样，这套方案也存在大量问题：同步效率低
Indexer使用的是Replication框架。在Replication框架下，一行数据的更新需要先要序列化写入WAL，然后通过Replication从WAL中读出反序列化，然后序列化成二进制数据发送到Indexer，Indexer再反序列化成数据才能写入Solr。整个过程非常低效，同步的速率受限于HBase的Replication能力，往往Solr的写入瓶颈还没达到，就已经达到了HBase的Replication瓶颈。Indexer的同步模型是每一个HBase表，都开启一条Replication通道（一个Replication Peer）。有10张HBase表需要同步到Solr，就必须有10个Replication Peer，这意味着同一个WAL，会被读取10次（每个peer都读取一次）随着同步表的增多，对HDFS的压力也就越大。由于HBase是SchemaLess的，Indexer收到Replication发过来的WAL后，无法知道是否在WAL中有整行数据，因此它必须在写Solr之前回读HBase获取整行数据。因此实际上，WAL中的entry发送过来后，有用的只有rowkey，其他的数据还是要依靠回读，这些WAL entry经历了这么长的发送链路，但大部分信息却是无用的。同时，回读会占用HBase资源，影响HBase稳定性。数据一致性无法保证使用Indexer同步HBase到Solr会经常遇到两者之间数据不一致的问题，这也是Indexer的用户吐槽最多的地方。
这些不一致往往发生的非常随机，一般用户也很难查到原因，让人摸不到头脑。我们深入研究Indexer后发现了他的问题所在。由于Indexer依赖了HBase的Replication做同步，而HBase Replication有一个重要的特点就是乱序发送，这对于HBase集群之间的Replication无影响，因为HBase可以用KV的时间戳来保证最终一致。但是Solr是不支持列时间戳的，HBase的写入乱序到达Indexer会导致写入Solr中的数据与HBase不一致。
比如用户有两次更新同一行,。但是在replication过程中， ts2的更新先到Indexer，而ts1的更新后到，这会导致Indexer将Solr中的这行的数据更新成value1，导致HBase和Solr的数据不一致。另外，由于HBase是先写WAL再内存可见，在回读HBase过程中，Indexer也可能没有获取到最新数据导致Solr数据不一致。
同时HBase支持多family，多版本，自定义时间戳，各种类型的删除，Solr模型的支持比较有限，Indexer没有处理好这些问题，我们发现有多个case都会导致HBase和Solr的数据不一致，这里就不一一列举了。Indexer官方已经不再维护Indexer社区代码已经4年没有更新，所有的这些问题都不会再修复，这也是使用Indexer的最大风险，面对这些问题和bug，用户只能自行解决。
云HBase增强版(Lindorm)全文索引
通过分析应用双写和开源的直率的小笼包 HBase Indexer存在的种种问题，Lindorm在研发全文索引功能时，从中吸取相关经验，进行创新的设计，使得宽表和检索两类引擎正确而自然的结合在一起，方便用户即开即用。
在此方案中，我们选用了自研的BDS组件做Lindorm的宽表引擎到Solr检索引擎间的数据同步。BDS是一个cloud native的HBase生态数据同步服务，可以提供高效的数据实时同步和全量迁移能力，关于BDS的介绍，用户可以参照《BDS - HBase数据迁移同步方案的设计与实践》一文(https://yq.aliyun.com/articles/704977 )。
在此方案中，我们使用BDS完美解决了Lindorm的宽表引擎和检索引擎Solr因为模型不一致，WAL乱序等等问题带来的数据不一致问题。不管用户是部分更新，多版本，自定义时间戳，多family写入，还是删除行、列，两个引擎之间的数据都不会产生不一致问题（具体的做法在申请专利中，专利申请完成后再专文对外分享）。同时整个系统采用分布式分层架构，各个组件之间可以独立自由伸缩，BDS服务、Lindorm的宽表引擎服务和检索引擎服务都具备无限的横向扩展能力，从而提供海量数据的无限存储和实时检索。在使用上， Lindorm全文索引功能非常简单易用，用户可以通过HBase Shell(Lindorm原生API暂未开放)就可以管理同步映射的Schema，BDS对于用户来说是完全透明的。不像在直率的小笼包 HBase Indexer方案中，用户还需要和Indexer交互，管理schema。具体的操作大家可以参考全文索引使用快速入门的帮助(https://help.aliyun.com/document_detail/161121.html ),简单来说，用户只需要在HBase Shell中执行一条命令，就可以为数据列创建Solr索引
hbase shell> add_external_index_field 'testTable', {FAMILY => 'f', QUALIFIER => 'money', TARGETFIELD => 'money_f', TYPE => 'FLOAT' }同时BDS还具有丰富的WebUI界面和监控和报警信息，用户可以非常方便地获取同步状态和报错信息。比如在云监控中，我们可以清晰地看到同步的延迟，同时可以通过订阅报警，随时发现异常。
最后是 阿里云HBase增强版(Lindorm)全文索引与其他方案的一个对比
方案双写直率的小笼包 HBase IndexerLindorm全文索引同步效率受限于Solr受限于HBase Replication，扩展性差受限于Solr稳定性会影响HBase稳定性会影响HBase稳定性无影响数据一致性无法保证无法保证可以保证一致性Cloud NativeN/AN/A云原生，支持扩容，升级配置，同步通道可独立扩展，报警监控一应俱全
案例介绍
目前已经有非常多的公司和业务已经在线上使用Lindorm的全文索引。这里给大家介绍几个使用案例。
某快递公司包裹平台
该快递公司的包裹系统原来使用了Oracle，由于业务的增长Oracle的单表数据过大已经造成瓶颈，并且只能存储1个月的数据。在这么大规模的数据下，上万网点的分析查询已经慢到无法接受的程度。该公司采用了Lindorm全文索引的方案改造之后，不仅可以将可查数据扩展到6个月，在引入Solr做多维查询后，查询能力也比之前好了五倍。
某O2O公司订单系统
该公司原来的订单查询系统使用了DRDS分库分表，由于订单量巨大，DRDS分32个库都已经只能放下6个月的订单数据。而该公司希望查询系统能够查询所有订单数据。同时由于查询时有多达15个维度条件的随机组合查询，传统的二级索引方案已经无法满足要求。在选用了Lindorm全文索引方案后，得益于Lindorm的海量存储能力，一个表就能放下所有历史数据。由于单个Solr的表索引数据不宜过大，因此该业务使用了我们推荐的Solr分库分表功能（Alias功能），Lindorm宽表存储中的数据自动增量同步到不同的Solr Collection中（按时间分割），在查询时，无需查询全量Solr数据，只需要根据时间维度查询少量Solr Collection。在新方案下，该公司不仅实现了能够在线查询所有历史数据，还能秒级返回查询结果。
某在线教育公司营销平台
该公司原来的营销平台直接基于MySQL，由于MySQL列不能太多，只能把各个系统的数据分布在多张表内，然后再采用DTS同步的方式，订阅Binlog，再写入到自建HBase的大宽表中。然后把写入事件记在Kafka上，再消费Kafka的消息，回读HBase数据同步到Solr中，最后提供给营销系统使用。整个链路非常长，组件非常多，难以维护，容易出稳定性问题。在使用了Lindorm的全文索引方案后，仅仅使用了一个Lindorm就解决了所有的问题，简单易运维，同时获得了 Cloud native的能力，各个组件都可以无限水平扩展和扩容。
总结阿里云Lindorm全文索引方案给广大用户提供了存储与检索的一站式解决能力，相比之前的方案，不仅简单易用，容易维护，同时能够利用Cloud Native的特性解决一系列运维上的难题。在技术上，阿里云Lindorm使用了一种高性能，低延迟的异构存储同步方案，避免了之前一些方案的性能问题，并完美地解决了宽表引擎和检索引擎的模型差异所带来的数据不一致的问题，在后续的计划中，Lindorm还将提供统一的多维查询能力，系统会自动利用Solr索引对多条件查询加速，而无需应用显示地访问Solr，进一步优化使用体验。目前，有大量的公司和用户已经基于此功能打造了他们的在线查询和离线分析系统，欢迎更多的用户前来试用。产品主页：https://www.aliyun.com/product/hbase ，产品使用帮助：https://help.aliyun.com/document_detail/146604.html