网站策划书10个点怎么写,西安产品设计公司有哪些,网站菜单设置,海口建设企业网站新用户9.9元即可使用6个月云数据库HBase#xff0c;更有低至1元包年的入门规格供广大HBase爱好者学习研究#xff0c;更多内容请参考链接 阿里云HBase增强版(Lindorm)简介
阿里云数据库HBase增强版#xff0c;是基于阿里集团内部使用的Lindorm产品研发的、完全兼容HBase的云… 新用户9.9元即可使用6个月云数据库HBase更有低至1元包年的入门规格供广大HBase爱好者学习研究更多内容请参考链接 阿里云HBase增强版(Lindorm)简介
阿里云数据库HBase增强版是基于阿里集团内部使用的Lindorm产品研发的、完全兼容HBase的云上托管数据库从2011年开始正式承载阿里内部业务的海量数据实时存储需求支撑服务了淘宝、支付宝、菜鸟、优酷、高德等业务中的大量核心应用历经双十一、春晚、十一出行节等场景的大规模考验在成本、性能、稳定性、功能、安全、易用性等方面相比社区版拥有诸多优势和企业级能力更多介绍可以参考Lindorm帮助文档https://help.aliyun.com/document_detail/119548.html
当大数据存储遇上复杂查询
HBase是目前广泛使用的NoSQL数据库其具有Schemeless特性高吞吐海量存储和无限水平扩展的特性因此被很好地应用在了推荐、风控、物联网、画像、表单等所有大数据场景。但是原生的HBase只支持Rowkey索引即按rowkey的二进制排序的索引。HBase的Scan请求可基于此rowkey索引高效的执行整行匹配、前缀匹配、范围查询等操作。但若需要使用rowkey之外的列进行查询则只能使用filter在指定的rowkey范围内进行逐行过滤。若无法指定rowkey范围则需进行全表扫描不仅浪费大量资源查询RT也无法保证。
为了解决用户基于非主键列的查询问题阿里云HBase增强版(Lindorm)内置原生的全局二级索引功能对于列较少且有固定查询模式的场景来说阿里云的高性能二级索引方案能够完美解决此类问题同时仍保持强大的吞吐与性能。这个索引方案在阿里内部使用多年经历了多次双11考验尤其适合解决海量数据的全局索引场景。关于高性能二级索引用户可以参考《数据查询的玄铁剑Lindorm二级索引功能解析》一文https://developer.aliyun.com/article/740009 ), 同时社区也有Phoenix在HBase之上提供了插件式的二级索引以及SQL能力使用SQL可以比较简单地表达一些复杂查询。
但是当面对更加复杂的查询比如表单、日志查询里面的模糊查找用户画像里面的随机条件组合查询等等二级索引方案会显得力不从心。而这些查询正是搜索引擎的优势。 Solr是分布式全文检索的最佳实践之一。Solr支持各种复杂的条件查询和全文索引。通过智能集成SolrLindorm可以充分发挥海量数据的实时存储和检索能力使得其可以高效支撑于需要保存大数据量数据而查询条件的字段数据仅占原数据的一小部分并且需要各种条件组合查询的业务。例如
• 常见物流业务场景需要存储大量轨迹物流信息并需根据多个字段任意组合查询条件• 交通监控业务场景保存大量过车记录同时会根据车辆信息任意条件组合检索出感兴趣的记录• 各种网站会员、商品信息检索场景一般保存大量的商品/会员信息并需要根据少量条件进行复杂且任意的查询以满足网站用户任意搜索需求等。
数据同步的难题
要想在Lindorm中集成Solr必须想办法将业务写入Lindorm的主表数据实时索引到Solr中然而存储主表数据的宽表引擎和存储索引数据的Solr检索引擎有很大的差异性比如数据模型上两者差别较大写入能力上也有巨大的差异。针对宽表与检索两种异构引擎间的数据同步目前市面上主要有两种类似的方案
应用双写
双写是最容易想到也是最容易实现的方案。以用户自己维护的双写HBaseSolr为例 业务将数据写入HBase的同时也将同样的数据写入Solr即可。有些用户使用了HBase的Coprocessor功能hook了HBase的写入逻辑在HBase完成写入时在Coprocessor中写入solr本质上也是双写HBase和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的读写能力
开源Lily HBase Indexer
Lily HBase Indexer下文简称Indexer是Cloudera推出的HBase和Solr之间的数据同步组件。他利用了HBase的Replication功能将自己伪装成一个HBase的Replication sink集群当HBase有数据写入时Replication会通过读取WAL文件获取最新更新传输到Indexer里然后再由Indexer写入Solr。 同样这套方案也存在大量问题同步效率低
Indexer使用的是Replication框架。在Replication框架下一行数据的更新需要先要序列化写入WAL然后通过Replication从WAL中读出反序列化然后序列化成二进制数据发送到IndexerIndexer再反序列化成数据才能写入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)全文索引
通过分析应用双写和开源的Lily 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暂未开放)就可以管理同步映射的SchemaBDS对于用户来说是完全透明的。不像在Lily 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)全文索引与其他方案的一个对比
方案双写Lily 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
原文链接 本文为云栖社区原创内容未经允许不得转载。
