天斯
探索云世界
天斯
暂无个人介绍
暂时未有相关通用技术能力~
阿里云技能认证
详细说明背景 目前DLA的一键建仓可以非常方便的进行RDS数据归档任务，只需要简单配置一下，就可以每天同步最新的归档数据到oss上，进而做一些DLA分析查询等。 但是最近有的用户提出，只需要归档一次，下次不再归档，或者下次归档的目录数据不覆盖之前的。这样可以保留每次归档的数据snapshot镜像。这种场景在一些审计校对的业务中，确实会比较实用。本文就针对这个场景，说明如何使用DLA的一键建仓任务，来做各个历史数据镜像的功能。整个过程主要分以下几步： 一键建仓schema的创建与运行 创建oss schema，创建对应的外表映射 删除原来的一键建仓schema 实战例子 下文演示例子：某公司在阿里云RDS上，有一个finance库，这个库中各种表专门记录了公司内部所有财务收支记录。会计部门每个月初，需要对上个月的所有财务收支情况进行审计汇总。审计报告由高层管理人员审核。简单的来讲，用户需要对RDS的数据做周期的一次性归档镜像快照，不互相覆盖，长期有效的存储着这个finance 库历史数据快照，并提供一下低频分析查询的功能操作。如： 2月1号，备份finance库目录为 oss://test/finance/20200201/，子目录有table1、table2、table3.... 3月1号，备份finance库目录为 oss://test/finance/20200301/，子目录有table1、table2、table3.... 4月1号，备份finance库目录为 oss://test/finance/20200401/，子目录有table1、table2、table3.... 5月1号，...... 创建一键建仓任务运行,并获取建表语句 创建一键建仓finance20200401任务，选择 20200401目录为schema数据根目录 立即运行finance20200401建仓任务，等待任务完成 schema管理列表，进入finance20200401 复制建表语句 如图，执行show create table users; 得到如下 CREATE EXTERNAL TABLE `finance20200401`.`users` ( `id` string COMMENT '', `username` string COMMENT '', `cardnum` string COMMENT '', `gmt_create` timestamp COMMENT '' ) COMMENT '' STORED AS `PARQUET` LOCATION 'oss://oss-tiansihz-for-xxxxx-test/20200401/6/users' TBLPROPERTIES ( 'auto.create.location' = 'true' ) 这里注意，看到“users”数据目录这次放在了“oss://oss-tiansihz-for-xxxxx-test/20200401/6/”目录下，于是我们需要创建一个oss schema映射到这个目录下，如下 创建oss schema 创建一个oss schema "20200401_snapshot"，并映射到指定目录下 如图，核心确保这个schema映射到了“oss://oss-tiansihz-for-xxxxx-test/20200401/6/”目录下，创建执行即可 schema管理找到20200401_snapshot，点击“查询数据”进入sql控制台 20200401_snapshot在sql控制台把之前复制的users建表语句粘贴进来，并在location路径最后加上“/”结尾 执行之后，得到了对应的users表，就可以正常查询了。 删除一键建仓任务schema “finance20200401” 此时，就可以吧一键建仓的finance20200401删除了，我们后续要查询的归档数据就用20200401_snapshot 这个schema就可以了。 小结 这里本质上是利用“一键建仓”的schema “finance20200401”完成“一次归档”RDS数据到oss上，然后立即删除这个一键建仓任务schema，防止后续每天都调度。归档过来的数据，使用oss schema 创建的外表来查询即可。整个过程还是比较简单的，方案供参考。当然为了一次建仓归档调度，还有别的方案。比如在DLA创建一个mysql表 usersA，再创建一个oss表usersB, 两个结构相同，然后DLA发起一个insert into B select from A sql就可以了。这里不展开，有需要的可以咨询“DLA答疑”客服。
HBase用户福利 新用户9.9元即可使用6个月云数据库HBase，更有低至1元包年的入门规格供广大HBase爱好者学习研究，更多内容请参考链接 概述 本文整理了HBase+solr 全文服务的相关阅读材料，使用到云HBase全文服务的用户 以及 那些准备给自建HBase增加es/solr/lucene索引服务架构的用户，可以阅读以下资料了解相关原理与应用。 hbase for solr介绍 中国hbase技术社区meetup上海站201809 内容概述：hbase发展为大多数企业的数据kv存储，但偶尔也会需要在这些数据中进行一些复杂的查询和统计，虽然查询频率没有kv那么高，但是依然是企业必须具备的一种能力。例如一个电信话单系统、物流轨迹系统等，除了大量的kv在线检索之外，可能还需要有管理专员定期进行一下复杂的条件查询或者min/max/avg分析统计等。本PPT提出的HBase for Solr就是其中一种解决方案。PPT下载地址 solr增强hbase检索能力基础介绍几场景 内容概述：概述hbase查询特点，以及solr在哪些场景下增强了hbase生态的查询服务能力。使用hbase+solr 架构最大的优点在于两个组件各司其职。hbase负责存储大量的kv数据，可以作为数据存储与kv查询，满足核心在线高性能kv检索业务；solr负责任意条件复杂查询与轻量分析统计，各自优点最大化。并且hbase在线kv查询与 solr复杂分析查询分离，可以有效避免互相影响。ppt下载地址 视频回看地址 Phoenix Search Index功能与应用实践介绍 阿里云栖开发者沙龙上海BigData NoSql Meetup 201905 内容概述：描述了阿里云Phoenix Search index功能与架构，在易用性上得到提高。ppt下载地址视频回看地址附录：云hbase全文服务(solr)使用介绍云HBase SQL服务(phoenix)的search index服务
概述 本文针对已经入门的同学，提供各种类型的场景查询demo，以及一些分析统计型的查询demo。如果未接触过solr的同学，可以先参考 Solr快速入门文档阅读推荐 文章快速入门学习一下solr。本demo积累为企业用户使用咨询时整理的，并不是特别多，正因如此，说明大部分企业查询检索功能都是solr的基础功能，上手简单。还有少许排序导出、分析统计的demo。 基础任意查询功能demo 下载git项目 aliyun-apsaradb-hbase-demo ，在solr模块中，包含了常用的每种简单查询SolrJ api使用方式，还有cursor分页、facet统计等demo，可以基于此直接改造用户业务合适的查询逻辑使用。 数据准备： 创建collection 使用SolrAddDocumentDemo.java示例插入100行示例数据 SolrQueryDemo.java包含的查询demo列表： match all query 全匹配查询 term query 词汇精确查询 wildcard query 通配符查询 fuzzy query 模糊查询 phrase query 短语查询 proximity query 邻近查询 range query 范围查询 multi condition query 多条件任意组合 pagination 常规分页与cursor深翻 facet统计&function query等 全量匹配与导出demo 以下两个demo使用预先插入数据如下 {"id":"1","group_s":"group1","test_i":"5","test_l":"10"}, {"id":"2","group_s":"group1","test_i":"5","test_l":"1000"}, {"id":"3","group_s":"group1","test_i":"5","test_l":"1000"}, {"id":"4","group_s":"group1","test_i":"10","test_l":"10"}, {"id":"5","group_s":"group2","test_i":"5","test_l":"10"}, {"id":"6","group_s":"group2","test_i":"5","test_l":"10"}, {"id":"7","group_s":"group2","test_i":"5","test_l":"1000"}, {"id":"8","group_s":"group2","test_i":"5","test_l":"1000"}, {"id":"9","group_s":"group2","test_i":"10","test_l":"10"}, {"id":"10","group_s":"group3","test_i":"4","test_l":"7"}, {"id":"11","group_s":"group3","test_i":"3","test_l":"9"} Demo1 全量导出复杂条件并带排序的匹配结果数据集合 例如：某公司400亿数据根据各种匹配条件，并按照时间排序导出结果数据列表，再提供第三方机构二次利用。 CloudSolrClient solrClient = new CloudSolrClient.Builder().withZkHost("localhost:9983").withZkChroot("/").build(); String collection = "test"; String currentMark = null; String nextCursorMark = CursorMarkParams.CURSOR_MARK_START; do { currentMark = nextCursorMark; SolrQuery solrQuery = new SolrQuery("test_i:5 AND test_l:[999 TO *]"); solrQuery.setParam("sort","test_i desc,id desc"); solrQuery.add(CursorMarkParams.CURSOR_MARK_PARAM, currentMark); solrQuery.setRows(1); QueryResponse response = solrClient.query(collection, solrQuery); nextCursorMark = response.getNextCursorMark(); System.out.println(response); } while (!nextCursorMark.equals(currentMark)); solrClient.close(); Demo2 分组后取每个分组取min test_i的一条记录，并全量导出所有group public static void main(String[] args) throws Exception{ CloudSolrClient solrClient = new CloudSolrClient.Builder().withZkHost("localhost:9983").withZkChroot("/").build(); String collection = "test"; String currentMark = null; String nextCursorMark = CursorMarkParams.CURSOR_MARK_START; do { currentMark = nextCursorMark; SolrQuery solrQuery = new SolrQuery("*:*"); solrQuery.setParam("fq","{!collapse field=group_s sort=$sort}"); solrQuery.setParam("sort","test_i desc,id asc"); solrQuery.add(CursorMarkParams.CURSOR_MARK_PARAM, currentMark); solrQuery.setRows(1); QueryResponse response = solrClient.query(collection, solrQuery); nextCursorMark = response.getNextCursorMark(); System.out.println(response); } while (!nextCursorMark.equals(currentMark)); solrClient.close(); } 聚合统计 以下两个demo使用预先插入数据如下 {"id":"1","group_s":"group1","test_i":"5","test_l":"10"}, {"id":"2","group_s":"group1","test_i":"5","test_l":"1000"}, {"id":"3","group_s":"group1","test_i":"5","test_l":"1000"}, {"id":"4","group_s":"group1","test_i":"10","test_l":"10"}, {"id":"5","group_s":"group2","test_i":"5","test_l":"10"}, {"id":"6","group_s":"group2","test_i":"5","test_l":"10"}, {"id":"7","group_s":"group2","test_i":"5","test_l":"1000"}, {"id":"8","group_s":"group2","test_i":"5","test_l":"1000"}, {"id":"9","group_s":"group2","test_i":"10","test_l":"10"}, {"id":"10","group_s":"group3","test_i":"4","test_l":"7"}, {"id":"11","group_s":"group3","test_i":"3","test_l":"9"} Demo1 求min、max、avg、sum，单个field 与多个条件function处理的case 最大值如下： curl "http://localhost:8983/solr/test/query" -d 'q=*:*&rows=0&json.facet={x:"max(sub(test_l,test_i))"}' 平均值如下： curl "http://localhost:8983/solr/test/query" -d 'q=*:*&rows=0&json.facet={x:"avg(sub(test_l,test_i))"}' 其中sub(test_l,test_i)即为 "test_l - test_i"的意思，更多函数可以参考Solr官方文档function Query部分 Demo2 针对结果进行facet分类统计，做侧边导航 需求背景为常见的博客、电商网站搜索栏，输入关键字后，除了匹配结果列表给用户展示外，对这些结果能进行二次分类统计，作为二次导航，方便用户快速搜索更相关的内容。场景如下图： 阿里云栖社区搜索”solr”关键字的结果展示中，除了出现右边的相关文章列表外，还对所有匹配solr关键字的结果，进行一个分类统计，例如左上角的框框中，展示这些相关的文章中，博客、问答、聚能聊等主题的匹配条数，如果用户此时需要的是问答相关的文章，那么他就可以快速点击这个问答的tab进一步搜索想要的内容，从而提升了用户搜索体验。实现方式可以参考aliyun-apsaradb-hbase-demo 中SolrQueryDemo.java的 facetRangeDemo、facetFieldDemo 两个示例，可以自定义各种类型的查询，来对匹配结果的二次分类统计。 小结 本文整理了常用的solr 查询demo代码，以及部分需要分析统计的查询示例，如有其他查询需求与疑问，可以留言提问，后续更新可以增加上，方便其他用户拿来即用。
HBase用户福利 新用户9.9元即可使用6个月云数据库HBase，更有低至1元包年的入门规格供广大HBase爱好者学习研究，更多内容请参考链接 概述 本文整理了Solr常见用法涉及的基础章节列表，通过这些章节的阅读学习，同学可以零基础快速入门使用Solr，并能够满足大部分企业的业务检索需求开发，掌握了熟悉使用Solr的基本技能。由于Solr功能丰富，插件灵活，官方文档仅做手册的编辑方式涵盖所有的功能内容描述，但众多地方还是欠缺连贯性。难做到像教科书一样，让同学从头到尾高效学习一遍。这里整理了Solr常用功能涉及的章节列表阅读推荐，并针对具体章节概念做了简单描述，希望未接触过Solr的同学可以快速入门,节省更多的学习时间，快速实践起来。 章节推荐 完整官方文档链接如下：solr7.3完整官方文档入门阅读可以参照如下目录： About This Guide 了解 //默认Solr服务端口8983, 有V1/V2 两种接口访问Solr Getting Started 了解 Solr Tutorial 了解 //启动solr服务，运行index/search demo A Quick Overview 了解 Solr System Requirements 了解 //主要是看具体版本的jdk要求 Installing Solr 了解 //了解solr安装过程 Deployment and Operations 了解 Solr Control Script Reference 熟悉 //熟悉solr -help 命令脚本所提供各种管理功能 Solr Configuration Files 熟悉 //Cloud模式下的solrconfig.xml和managed-schema作用 Using the Solr Administration User Interface Overview of the Solr Admin UI 了解 //主要熟悉Cloud模式下的Solr Admin web UI管理collection Logging 了解 Cloud Screens 了解 Collections / Core Admin 了解 Java Properties 了解 Thread Dump 了解 Collection-Specific Tools了解 Documents Screen了解 Files Screen 熟悉 Query Screen 熟悉 Schema Browser Screen 了解 Core-Specific Tools Ping 了解 Plugins & Stats Screen 了解 Segments Info 了解 Documents, Fields, and Schema Design 熟悉 Overview of Documents, Fields, and Schema Design 熟悉 //熟悉solrconfig.xml和managed-schema配置文件 Solr Field Types 熟悉 Field Type Definitions and Properties 熟悉 //理解 indexed/stored/docValues/multiValued属性 Field Types Included with Solr 熟悉 //理解常见类型int/long/double/float/boolean/string 相对应预定义好的类型 Field Properties by Use Case 了解 //了解根据业务检索用途，需要开启哪些属性的参照表格 Defining Fields 了解 Copying Fields 了解 Dynamic Fields 了解 Other Schema Elements 了解 Schema API 熟悉 //熟悉api修改schema配置文件的各种配置项 DocValues 理解//查询业务涉及到facet&function/sort 时推荐开启 Understanding Analyzers, Tokenizers, and Filters 了解 Uploading Data with Index Handlers 了解 Transforming and Indexing Custom JSON 了解 Searching 熟悉 Query Syntax and Parsing 熟悉 Common Query Parameters 熟悉 The Standard Query Parser 熟悉 Function Queries 了解 //结合facet可以做min/max/avg/sum等聚合统计 JSON Request API 了解 JSON Facet API 了解 Faceting 了解 Pagination of Results 熟悉 //场景分页实现与cursorMark深翻 Collapse and Expand Results 了解 //聚合分组功能，类似group by Result Grouping 了解 Response Writers 了解 Near Real Time Searching熟悉 //理解commit相关配置项 RealTime Get 了解 SolrCloud 了解 Getting Started with SolrCloud 了解 How SolrCloud Works 了解 Shards and Indexing Data in SolrCloud 熟悉 Distributed Requests 了解 SolrCloud Resilience 了解 SolrCloud Recoveries and Write Tolerance 了解 SolrCloud Query Routing And Read Tolerance 了解 SolrCloud Configuration and Parameters 了解 Setting Up an External ZooKeeper Ensemble 了解 Using ZooKeeper to Manage Configuration Files 了解 Collections API 了解 Parameter Reference 了解 Command Line Utilities 熟悉 SolrCloud with Legacy Configuration Files 了解 ConfigSets API 熟悉 The Well-Configured Solr Instance 熟悉 Configuring solrconfig.xml 熟悉 IndexConfig in SolrConfig 熟悉 //SortingMergePolicy实现预排序，业务查询有固定排序需求的可以考虑 UpdateHandlers in SolrConfig 熟悉 //熟悉几个commit参数配置 Query Settings in SolrConfig 熟悉 //理解几个cache配置功能，及其应用 Solr Cores and solr.xml 了解 Format of solr.xml 了解 Config Sets 了解 //可以对collection配置目录管理 Configuration APIs了解 Config API 熟悉 //可以动态修改collection某个配置项 Monitoring Solr 了解 Configuring Logging 了解 Performance Statistics Reference 了解 //了解一些关系的metrics指标含义 Client APIs 熟悉 Choosing an Output Format 了解 Client API Lineup 了解 Using Python 了解 Using SolrJ 熟悉 //掌握CloudSolrClient api使用 小结 上述章节基本涵盖了大部分企业检索查询需求的功能，也是使用阿里云HBase全文服务的 Solr基础知识。如有特殊的需求，再针对性阅读官方手册即可。我们在 solr企业业务常见各种demo与答疑 中整理了许多查询统计场景demo供参考，如有新特性欢迎评论，后续会更新相应demo，供大家使用。 链接 云HBase全文服务使用文档solr7.3完整官方文档solr常用检索查询业务demo
云HBase发布了“全文索引服务”功能，自2019年01月25日后创建的云HBase实例，可以在控制台免费开启此“全文索引服务”功能。使用此功能可以让用户在HBase之上构建功能更丰富的搜索业务，不再局限于KV简单查询，不再苦恼于设计各种rowkey，不再后怕日益变化的HBase复杂查询业务。“全文索引服务”为云HBase增强查询能力而设计，自动同步数据，用户只需重点关注如何使用强大的检索功能来丰富自己的业务架构。 为什么要增强HBase的检索能力 我们在使用HBase的时候都会面临一个问题，就是设计HBase的rowkey。可尽管我们工程师是多么的优秀，整理罗列了所有业务检索需求，并裁剪折中了这样那样的业务，缺依然不能设计一个全能的rowkey来满足各种业务查询需求。例如在某物流管理系统中，我们需要对收件人姓名/手机/地址、寄件人姓名/手机/地址、运单编号/开始时间/结束时间、邮递员姓名/手机等条件，进行任意组合查询。这种复杂查询情况下，HBase原先的KV查询无法满足，尽管我们如何设计rowkey，都不能满足查询条件的任意性。另外，在这些查询中，可能会涉及到姓名/地址/手机号等条件的模糊查询，这也是HBase rowkey不能很好满足的。又例如在某新零售业务中，需要对商品标题或者描述内容进行关键字查询，在HBase中我们只能使用模糊查询来实现，但模糊查询在HBase中是比较低效的。类似这种标题/描述内容中进行关键字查询业务，比较合适使用分词查询，这个功能HBase都无法提供满足。另外，在新零售查询业务中，为了提高用户体验，经常会提高搜索结果进行分类统计的需求，例如我们在电商网站中，搜索关键字“时尚”，在显示匹配此关键字结果的商品中，按照 衣服、电子、日用等类型进行了分类统计匹配结果，这样用户就可以选择对应的大类进行二次查询，快速查询到用户想要的商品，从而提高了用户体验。像这个功能，HBase也无法满足。最终为了适应HBase系统的查询特点，对业务做了折中，只保留部分KV查询的业务，其他可以提高用户体验的各种查询业务被全部砍掉了。 总结下来，我们列出来了几个使用HBase进行查询业务设计时碰到的痛点： 无法满足任意条件组合查询 不能高效支持模糊查询 不支持关键字分词查询 不能高效支持多维度的排序/分页 不能对查询的结果集进行分类统计 云HBase全文索引服务，增强HBase检索能力 全文索引服务是为了增强HBase查询能力而设计，使得HBase除了强大的KV能力外，更加丰富了它的在复杂条件查询下的能力，具体抽象出来以下几个场景： 复杂条件任意查询 多维度排序 复杂条件分页 分词关键字查询 匹配结果集分类统计 常用min/max/avg/sum等stats统计 云HBase全文索引服务使用简单，只需要DDL阶段建立索引，后续自动进行数据索引同步，架构如下： 和自建的区别 功能 云HBase启用全文索引 自建HBase+indexer+solr HBase 简单rowkey查询 支持 支持 支持 复杂查询 支持 支持 不支持 索引同步 支持 支持 不支持 乱序同步 支持 不支持 ——— 强一致 支持 不支持 ——— xml动态列 支持 不支持 ——— 另外，自建hbase+indexer+solr存在几个bug，导致很多用户反馈的自建这种架构丢数据现象；云HBase对此进行了许多bugfix和改进。 如何使用云HBase全文索引服务 云HBase全文索引服务的使用，启用此服务后，只需要简单DDL建立索引即可，插入同步无限管理，用户只需关注后续查询要使用HBase api/Solr api进行构建丰富的业务查询即可。下面我们来简单体验下整个流程。 开启服务 “全文索引服务”属于云HBase的免费扩展服务，自2019年1月25日后创建的云HBase实例控制台，实例左侧点击“全文索引服务”详情页进行服务开启即可，如下：申请后的如下Solr访问地址以及WebUI连接，如图：其中solr zk地址即可构造cloud solr client进行访问，此访问客户端自带负载均衡功能。Solr WebUI访问方式与云HBase WebUI访问一致，第一次访问是设置好用户密码与白名单，然后直接点上面的链接即可跳转到Solr的WebUI。 建立索引 下载索引管理客户端工具 wget http://public-hbase.oss-cn-hangzhou.aliyuncs.com/installpackage/solr-7.3.1-ali-1.0.tgz tar zxvf solr-7.3.1-ali-1.0.tgz 修改solr-7.3.1-ali-1.0/bin/solr.in.sh文件的ZK_HOST如下： ZK_HOST=zk1:2181,zk2:2181,zk3:2181/solr zk地址即为上图控制台开通全文索引服务后的solr zk访问地址。 创建HBase表，开启replication同步机制 create 'solrdemo',{NAME=>'info', REPLICATION_SCOPE=> '1'} 创建Solr表democollection第一步，修改并上传solrconfig.xml/schema，如果不需要修改，可使用demo默认config进行上传，如下： solr-7.3.1-ali-1.0/bin/solr zk upconfig -d _democonfig -n democollection_config -z zk1:2181/solr 第二步，使用刚上传的配置创建democollection，如下： curl "http://hostname:8983/solr/admin/collections?action=CREATE&name=democollection&numShards=1&replicationFactor=1&collection.configName=democollection_config" 其中hostname可以使用master3-1中缀的zk hostname进行替换。 配置HBase solrdemo表到Solr democollection表的字段映射索引关系第一步，编辑index_conf.xml配置映射关系，例如： <?xml version="1.0"?> <indexer table="solrdemo"> <field name="name_s" value="info:q2" type="string"/> <field name="age_i" value="info:q3" type="int"/> <param name="update_version_l" value="true"/> </indexer> 配置描述了hbase表solrdemo的 info:q2 info:3 分别映射成solr democollection里面的name_s和age_i 字段。并指定以string解析info:q2 列保存到name_s字段中，以int解析info:q3 保存到age_i中。其中solr collection的name_s、age_i是何种类型，是根据solr collection的配置觉得，默认采用动态类型推断，即根据collection字段的名字后缀判断类型进行存储。常见类型_i、_s、_l、_b、_f、_d分别对应int/string/long/boolean/float/double。当然，用户也可以直接指定字段类型。最后一个update_version_l为固定写法，保存document级别的最新更新时间。第二步，使用工具将 index_conf.xml 设置关联hbase表solrdemo和solr表democollection的索引映射关系，命令如下： solr-7.3.1-ali-1.0/bin/solr-indexer add \ -n demoindex \ -f indexer_conf.xml \ -c democollection 到此，我们就完成了索引的关系映射，随后正常插入hbase即可，就不需要关心索引同步，它会自动同步hbase solrdemo表的对应字段到solr democollection表的对应字段中。如上例映射如下： 其中，HBase表的rowkey映射到Solr表里面的id字段。 查询检索 查询较为简单，依然完全兼容开源HBase API和Solr API的操作，根据业务使用solr进行条件查询，结果集中，id字段就是所有符合条件的hbase rowkey，我们只有这个id转换为rowkey，并使用HBase API读取属于这个行的原数据即可。流程图大致如下： 展望 索引管理更简单易用 SQL入口接入全文索引服务 全文引擎新一代更高效副本机制 除了异步索引，同步索引也会后续支持 产品入口： https://cn.aliyun.com/product/hbase 使用全文索引服务帮助文档： https://help.aliyun.com/document_detail/88404.html
一、HBase2.0和阿里云的前世今生 福利：国际顶级盛会HBaseCon Asia 2018将于8月在北京举行，目前正免费开放申请中，点击了解更多详情 ApsaraDB for HBase2.0于2018年6月6日即将正式发布上线啦！ ApsaraDB for HBase2.0是基于社区HBase2.0稳定版的升级，也是阿里HBase多年的实践经验和技术积累的持续延伸，全面解决了旧版本碰到的核心问题，并做了很多优化改进，附加HBase2.0 开源新特性，可以说是HBase生态里的一个里程碑。 HBase在2007年开始发布第一个“可用”版，2010年成为Apache的顶级项目，阿里巴巴集团也在2010当年就开始研究,于2011年就已经开始把HBase投入生产环境使用，并成为阿里集团主要的存储系统之一。那个时候HBase已经运行在上千台级别的大集群上，阿里巴巴可以说算是HBase当时得到最大规模应用的互联网公司之一。从最初的淘宝历史交易记录，到蚂蚁安全风控数据存储，HBase在几代阿里专家的不懈努力下，HBase已经表现得运行更稳定、性能更高效，是功能更丰富的集团核心存储产品之一。 阿里集团自2012年培养了第一位“东八区” HBase Committer，到今天，阿里巴巴已经拥有3个PMC，6个Committer，阿里巴巴是中国拥有最多HBase Committer的公司之一。他们贡献了许多bug fix以及性能改进feature等，很可能你在用的某个特性，正是出自他们之手。他们为HBase社区，也为HBase的成长贡献了一份宝贵的力量。当然，也孕育了一个更具有企业针对性的云上HBase企业版存储系统——ApsaraDB for HBase。 ApsaraDB for HBase2.0是基于开源HBase2.0基础之上，融入阿里HBase多年大规模实战检验和技术积累的新一代KV数据库产品，结合了广大企业云上生产环境的需求，提供许多商业化功能，比如 HBase on OSS、HBase云环境公网访问、HBase on 本地盘、HBase on 共享存储、冷热分离、备份恢复、HBase安全机制等等，是适合企业生产环境的企业级大规模云KV数据库。 ApsaraDB for HBase2.0，源于HBase，不仅仅是HBase! 二、深入解读云HBase架构 ApsaraDB for HBase2.0是建立在庞大的阿里云生态基础之上，重新定义了HBase云上的基础架构，对企业云上生产需求更有针对性，满足了许多重要的云上应用场景。其中最常见的有：存储计算分离、一写多读、冷热分离、SQL/二级索引、安全等。下面针对这些场景简单介绍一下ApsaraDB for HBase2.0的基础架构。 2.1 存储计算分离 早期存储和计算一般都是一起的，这样做带来的好处是数据本地化，不消耗网络资源。但是这会带来一个问题，给应用企业对集群起初的规划带来一定的难度，如果一开始使用过大的存储、过大的计算资源，就是一种浪费，但是如果开始规划存储、计算过小，后期运维升级扩展有变得非常复杂，甚至升级/扩展过程会出现故障等等问题，这些都不不企业业务发展规划不可忽略的问题。 随着网络技术的发展，现在已经进入25G甚至100G以上时代，网络带宽已经不再是瓶颈。ApsaraDB for HBase2.0建立在阿里云之上，利用阿里云强大基础技术，实现了云上HBase的高性能存储计算分离的架构。 如上图所示，分布式region如上图所示，分布式region计算层负责HBase相关的数据库逻辑运算操作; 通过分布式HDFS&API接口读写远端底层分布式文件存储系统；其中远端读写质量和安全隔离由QOS层保障，QOS层利用高性能硬件加速远端读写性能，保障了存储分离的性能、安全要求；最终读写落到分布式存储层，分布式存储层通过副本形式保障数据安全可靠，可以容忍单节点、单rack fail的数据可靠性。云上HBase计算存储分离架构的实现，使得用户集群规划则变得简单很多，存储容量动态扩展，计算资源动态升配。基本不需要估算未来业务的规模了，真正做到按需使用，帮助用户在业务运行之初就开始尽可能地降低成本，同时又可以随时满足业务发展导致资源的弹性扩展的需要。 2.2 冷热分离/分级存储 一般企业随着业务数据不断增长，数据量开始变大，这个时候就需要对数据进行冷热程度区分对待，以优化系统整体运行效率，并降低成本。举个例子，如：冷数据写入一次后，可能很久才被访问一次，但是因为和热数据存储在一个数据块上，可能读这个热数据的时候，冷数据也被顺带读到内存中，这可能是没有必要的，我们更多希望被顺带读出来的也是即将被访问的热数据。另外，因为热数据的频繁更新写入，可能会引起系统更多得split、compaction等动作，这个时候，冷数据也被顺带一起多次读写磁盘了，实际上冷数据可能不需要这么频繁地进行这种系统动作。再从成本考虑，业务上如果普遍可以接受陈年旧事——冷数据被访问延时相对高一点点，那么就可以考虑把这些数据存储在成本较低的介质中。 基于这种常见的企业场景需求，ApsaraDB for HBase2.0在阿里云基础体系之上，设计了云HBase冷热分离/分级存储架构，实现企业云上HBase应用的冷热分离场景需求，提高系统运行效率的同时，又降低存储成本。 如图所示，架构分两阶段，第一阶段实现分级存储，用户可以清晰的按照不同访问频度将数据存储到不同冷热级别的表上，从表级别上区分冷热数据，实现分级存储。第二阶段是同表数据冷热数据自动分离，用户可以按照访问频率或者创建时间等条件，指定冷热数据判断标准依据，最终后端自动分离冷热数据分别存储。 2.3 一写多读/读高可用 在旧版HBase运行的时候，当一台机器宕机的时候，这个机器所负责的region主要需要经历3个的处理流程才能恢复读——发现宕机、重新分配此机器负责的region、上线region恢复。其中发现宕机可能就需要几十秒，依赖于zookeeper的session timeout时间。在这个恢复过程中，用户client是不可以读这些region数据的。也就是此架构的读不是高可用的，无法保证99.9%的延时都 <20ms。在某些应用业务里，可能更关心整体读高可用、99.9%读延时，且允许读到旧数据的情况下，这就无法满足。 ApsaraDB for HBase2.0是基于2.0最新稳定版，引入了region replicas功能，实现一写多读，扩充了高可用读的能力。 如上图，开启这个功能的表，region会被分配到多个RegionServer上，其中replicaId=0的为主region，其他的为从region，只有主region可以写入，主region负责 flush memstore成为hfile，从region一方面根据hfile列表类读到数据，另一方面对于刚写入主region但还没有flush到hdfs上的数据，通过replication同步到从region的memstore。如上图所示，client1分别时间间隔内写入x=1、x=2、x=3，在同步数据的时候时，client2进行读x的值，它是可以读任何一台server上的x值，这就保证了读的高可用性，即使有机器挂了也可以有 99.9%延时 <20ms保证。 可以看到这种架构读是高可用的，合适一写多读的场景，数据只保存一份。n台机器挂了(n小于一个region的副本数)，还可以正常读数据。并且这里提供了两种读一致性模式，分别是strong和timeline-consistent模式。在strong模式下，只读取主region的数据返回结果；在timeline-consistent模式下，允许读任何一个region replica的数据返回，这对一些要求读高可用的场景来说，体验是比较友好的。 2.4 SQL/二级索引/全文检索 HBase原生的设计只有按照rowkey的才能快速查询检索，这对复杂的企业业务检索场景来说，是满足不了的。且随着业务的变化，开始设计的rowkey可能已经不能满足当下系统的某些业务检索需求了。这就要求对HBase的检索功能进行加强。 ApsaraDB for HBase2.0支持更完善的SQL接口、二级索引以及全文索引，用户可以使用熟悉的SQL语句操作HBase系统；并且支持二级索引的创建、全量重建索引，以及增量数据自动同步索引的功能；2.0版本还将支持全文索引检索功能，弥补了HBase不能模糊检索的缺陷，把全文检索的功能引入HBase系统当中。 如上图，ApsaraDB for HBase2.0体系内置solr/phoenix内核引擎，进行了深度改造与优化，支持SQL/API方式操作数据库，二级索引支持：全局索引、本地索引、全文索引等。索引支持全量重建、增量数据自动同步更新。在检索查询的时候，索引对用户透明，HBase内部根据索引元信息自动探测用户查询是否需要利用索引功能，增强了HBase系统检索能力，有利于企业在云HBase业务上构建更复杂的检索场景。 2.5 安全体系 在用户使用数据库的时候，都习惯于传统的类型MySQL的账户密码体系，而大数据Hadoop/HBase生态当中，默认却没有一套完整且统一的认证授权体系，组件内置的身份认证仅支持Kerberos协议，而权限控制依赖于每个生态组件自身的控制。 ApsaraDB for HBase2.0基于Alibaba&Intel 合作项目Hadoop Authentication Service (HAS) 开发了一套属于云HBase的认证授权体系，兼容了Hadoop/HBase生态的Kerberos协议支持，并使用人们熟悉的账户密码管理方式，允许对用户访问HBase的权限进行管理，兼容默认ACL机制。 如上图，ApsaraDB for HBase2.0安全体系基于HAS开发，使用Kerby替代MIT Kerberos服务，利用HAS插件式验证方式建立一套人们习惯的账户密码体系，用户体验更友好。 2.6 备份恢复 大数据时代，重要的信息系统中数据就是财富，数据的丢失可能会造成不可估量的损失。对于这种数据重要级别较高的场景，应该要构建一套灾难备份和恢复系统架构，防止人为操作失误、自然灾害等不可避免的偶然因素造成的损失。ApsaraDB for HBase2.0构建在云体系下，支持全量、增量备份，同城/异地灾备功能。 如上图，架构可以允许用户进行冷数据备份，备份数据保存在共享存储中，成本低，需要时可以对备份数据读取还原插入到系统中。同时也支持热备份，集群之间通过全量HFile和增量HLog进行跨集群备份，最终做到同城/异地灾备，业务client可以在访问当下集群不可用时，自动切换到备用集群进行数据访问业务。 三、2.0版本内核解读 开源HBase在2010年正式成为Apache顶级项目独立发展，而阿里巴巴同步早在2010年初已经开始步入HBase的发展、建设之路，是国内最早应用、研究、发展、回馈的团队，也诞生了HBase社区在国内的第一位Committer，成为HBase在中国发展的积极布道者。过去的8年时间，阿里累积向社区回馈了上百个patch, 结合内部的阿里巴巴集团“双十一”业务等的强大考验，在诸多核心模块的功能、稳定性、性能作出积极重大的改进和突破，孕育了一个云上HBase企业版KV数据库ApsaraDB for HBase。 ApsaraDB for HBase发展至今，已经开始进入了2.0 时代。ApsaraDB for HBase是基于开源HBase2.0版本，结合阿里HBase技术和经验的演进过来，其完全兼容HBase2.0，拥有HBase2.0的所有新特性的同时，更享受阿里专家&HBase Committer们在源码级别上的保驾护航。2.0相比1.x之前版本在内核上有了许多改进，内核功能更稳定、高效、延时更低，功能更丰富。下面我们来介绍一下这些重要的功能特性。 3.1 新版Region分配器AMv2——稳定性提高 在早期版本，HBase Server端很多执行业务过程都是使用handler线程实现的，而一个业务线程需要执行的逻辑可能要经历几个步骤。使用handler线程实现的这套机制最大的问题在于不支持异常回滚，没有灾难恢复机制，执行过程中出现异常，那么HBase可能会处在任务的中间状态，引起常见的Region-In-Transition，可能就需要人为去清理。如：客户端调用一个createTable RPC请求，服务端需要创建HDFS目录，写入meta表，分配region，等待region上线，标记region上线完成等等系列步骤，如果handler处理线程中间被中断了，就导致系统残留一下中间状态的数据。 如上图，region信息写入meta表后进程被中断了，而client认为任务已经完成了，实际上整个任务是失败的。在进程恢复后，没有很好的处理这个灾难问题回滚或者继续恢复执行剩下的步骤。 针对这类问题，ApsaraDB for HBase2.0内核做了两个核心的改动，一个是引入ProcedureV2，解决诸如上述分布式多步骤流程处理的状态最终一致性问题；二个是基于ProcedureV2基础上，改造了AssignmentManager，使其在region上线过程被异常或灾难中断后，进程恢复时可以自动回滚中间残留状态信息，重试中断步骤并继续执行。最终避免了类似RIT的问题，实现“NO more HBCK, NO more RIT”，提供稳定性，降低运维成本。 首先我们来看看ProcedureV2的原理，如下图： 它使用ProcedureExecutor调用执行用户提交的procedure队列，并在执行procedure状态变化的时候，使用ProcedureStore记录procedure的状态持久化到WAL中，如此反复。当procedure执行过程当中进程被中断了，在下一次进程恢复时，就可以根据之前持久化的procedure状态恢复到指定步骤，并做必要的rollback步骤，再重试中断的步骤继续下去。 如上图，最常见的就是状态机Procedure，定制每次状态在继续向下执行的时候，应该做哪些操作，以及在中断恢复后，应该处理的rollback工作。回想上面创建表的例子，如果我们同样在"add regions to META"的时候失败了，那么我们在恢复之后，就可以根据这个状态信息，继续执行剩下的步骤，只有当这个procedure 完成的时候，这个create table的procedure 才算完成。当然，client判断是否创建表成功也不再是使用 “MetaReader.hasTable”来利用中间状态得到结果，而是直接根据createTable的procedure Id来查询是否任务完整执行结束。可以看出，在使用ProcedureV2和之前的线程处理有了很大的改进，更灵活的处理业务进程被中断时的各种异常情况。 再来看看AMv2的改进特性，正如上面所述，AssignmentManager V2(简称AMv2)是基于ProcedureV2实现的新版region分配管理器。得益于ProcedureV2的设计实现，AMv2在进行region分配上下线时，可以在被各种情况中断的情况下，自动恢复回滚执行，使得region的状态最终是自动恢复一致性的。除此之外，AMv2还重新设计了region信息保存和更新的逻辑。 在旧版的AssignmentManager实现，是借助Zookeeper协同功能，Master与RegionServer共同完成的region状态维护，代码逻辑相对复杂、效率低。region状态保存在3个地方：Zookeeper、meta表、Master内存，当一个分配流程过程中一端被异常中断时，就容易出现集群状态不一致的现象。如client 访问时报的NotServingRegionException一种能就是region状态不一致，Master认为是分配到这个server上，而实际在这个server并没有上线，此时client rpc请求访问，就会收到这个异常。 下图为旧版AssignmentManager的region assign复杂流程： 如上图流程显示，第1、2、3条线是Master进程的不同线程，第4条是zk，第5、6条是RegionServer上的线程，第7条线是META表。Master和RegionServer都可以更新Zookeeper中region的状态，RegionSever又可以更新 meta表中的 assignment 信息。Master 在将 region assign 给 RegionServer 之前也会更新region 状态信息，Master也可以从 Zookeeper和meta 表中获取 region状态更新。这导致很难维持region处于一个正常的状态，特别是一端处于异常灾难中断的时候。 为了维持region处于一个正常的状态，再加上各种异常中断的情况考虑，HBase内部使用了很多复杂的逻辑，这就大大增加了维护难度，对开发新功能、提升性能的优化工作增加了复杂性。 新版AssignmentManager V2 ，不仅基于ProcedureV2之上以支持各种中断回滚重试，还重新设计了region分配逻辑，不再使用Zookeeper来保存region的状态信息，region只持久化在meta表，以及Master的内存中，并且只有Master去维护更新，这就简化了状态更新的一致性问题。而且，代码逻辑较之前也清晰简洁了，稳定性提高了，维护的复杂性降低，性能也提高了。 如上图，从测试结果来看，2.0中的 region assign 速度比V1提高非常快。综合看，这个AMv2是个非常有重要的改进。 3.2 Netty Rpc Server和Client——增加吞吐，降低延时 在之前的版本中，HBase的RPC Server使用的是基于Java NIO实现的一套框架。在这套框架中有一个Listener线程负责accept来自Socket的连接请求，并将对应的Connection注册到NIO的Selector上。同时，有若干个Reader线程来负责监听这个selector上处于Readable状态的Connection，将请求从Connection中读出，放入对应的Callqueue中，让handler线程来执行这些请求。虽然HBase社区对这套RPC框架进行了诸多优化，包括去掉一些同步锁，减少复制等等，但由于其线程模型的限制，以及Java NIO本身的瓶颈，在大压力测试中，这套框架仍显得力不从心。 而Netty是一个高性能、异步事件驱动的NIO框架， 在业界有着非常广泛地应用，其稳定性和性能都得到了多方面地印证。抱着“把专业的事情交给专业的人去做”的思想，在HBase2.0中，引入了Netty做为其服务器的RPC框架。引入Netty的工作由来自阿里巴巴的committer binlijin完成，并做了相应的测试。完成后HBase的RPC框架如图所示： 从网络上读取请求和写入response都由Netty来负责，由于HBase的绝大部分请求涉及了较多的IO和CPU操作，因此仍然需要一个Handler线程池来做请求的执行，而和网络相关的操作，完全交给了Netty。使用了Netty服务器后，HBase的吞吐增长了一倍，在高压力下的延迟从0.92ms降到了0.25ms，更多的信息可以看下根据binlinjin在一次公开演讲中的展示[附录1]。目前Netty服务器已经是HBase2.0的默认RPC选项。 3.3 读写链路offheap——降低毛刺率，QPS增加 GC一直是java应用中讨论的一个话题，尤其在像HBase这样的大型在线KV数据库系统中，GC停顿会对请求延迟产生非常大的影响。同时，内存碎片不断恶化从而导致Full GC的发生，成为了HBase使用者们的一大痛点。 在HBase的读和写链路中，均会产生大量的内存垃圾和碎片。比如说写请求时需要从Connection的ByteBuffer中拷贝数据到KeyValue结构中，在把这些KeyValue结构写入memstore时，又需要将其拷贝到MSLAB中，WAL Edit的构建，Memstore的flush等等，都会产生大量的临时对象，和生命周期结束的对象。随着写压力的上升，GC的压力也会越大。读链路也同样存在这样的问题，cache的置换，block数据的decoding，写网络中的拷贝等等过程，都会无形中加重GC的负担。而HBase2.0中引入的全链路offheap功能，正是为了解决这些GC问题。大家知道Java的内存分为onheap和offheap，而GC只会整理onheap的堆。全链路Offheap，就意味着HBase在读写过程中，KeyValue的整个生命周期都会在offheap中进行，HBase自行管理offheap的内存，减少GC压力和GC停顿。全链路offheap分为写链路的offheap和读链路的offheap。其中写链路的offheap功能在HBase2.0中默认开启，读链路的offheap功能仍然在完善中，即将在后续的小版本中开启。 写链路的offheap包括以下几个优化： 1. 在RPC层直接把网络流上的KeyValue读入offheap的bytebuffer中 2. 使用offheap的MSLAB pool 3. 使用支持offheap的Protobuf版本（3.0+） 4. 更准确的Memstore size计算和更好的flush策略 读链路的offheap主要包括以下几个优化： 1. 对BucketCache引用计数，避免读取时的拷贝 2. 使用ByteBuffer做为服务端KeyValue的实现，从而使KeyValue可以存储在offheap的内存中 3. 对BucketCache进行了一系列性能优化 来自阿里巴巴的HBase社区PMC Yu Li将读链路offheap化运用在了阿里巴巴内部使用的HBase集群中，使用读链路offheap后，相应集群的读QPS增长了30%以上，同时毛刺率更加低，请求曲线更加平滑，成功应对了2016年天猫双十一的峰值[附录2]。 3.4 In-Memory Compaction——减轻GC压力，减少写放大 回顾HBase的LSM结构，HBase为每个region的每个store在内存中创建一个memstore，一旦内存达到一定阈值后，就会flush到HDFS上生成HFile。不断的运行写入，HFile个数就会变多，这个时候读性能就会变差，因为它查询一个数据可能需要打开所有存在这个行的HFile。解决这个问题就需要定期后台运行Compaction操作，将多个HFile合并。但是这样做会使得同一份数据，因多次compaction而会被写入多次hdfs，引起了写入放大的问题。可以看到，要想减少这个compaction的频率的话，可以通过降低HFile的产生速度，同样的内存尽可能多的保存数据，并且在内存中预先进行compaction操作，提高后期hfile的compaction效率。In-Memory Compaction应运而生。 hbase2.0引入In-Memory compaction技术，核心有两点：一是使用 Segment 来替代 ConcurrentSkipListMap ，同样的 MemStore 可以存储更多的数据，减少flush 频繁，从而也减轻了写放大的问题。同时带来的好处是减少内存 GC 压力。二是在 MemStore 内存中实现compaction操作，尽量减少后期写放大。 先来说说其如何高效实用内存。在默认的MemStore中，对cell的索引使用ConcurrentSkipListMap，这种结构支持动态修改，但是其中会存在大量小对象，内存碎片增加，内存浪费比较严重。而在CompactingMemStore中，由于pipeline里面的segment数据是只读的，就可以使用更紧凑的数据结构来存储索引，这带来两方面好处：一方面只读数据块可以降低内存碎片率，另一方面更紧凑的数据结构减少内存使用。代码中使用CellArrayMap结构来存储cell索引，其内部实现是一个数组，如下图: 再来说说其如何降低写放大。旧版Default MemStore是flush时，将active的store 进行打快照snapshot，然后把snapshot flush到磁盘。新版的CompactingMemStore是以segment为单位组织，一个memstore中包含多个segment。数据写入时写到active segment中，active segment到一定阈值后触发in-memory flush 生成不可修改的segment放到pipeline中。pipeline最后会对这些多个segment进行in-memory compaction合并为一个更紧凑的大segment，在一定程度上延长数据在内存的生命周期可以减少总的I/O，减少后期写放大。 内存compaction目前支持Basic,Eager,Adaptive 三种策略。Basic compaction策略和Eager compaction策略的区别在于如何处理cell数据。Basic compaction不会清理多余的数据版本，这样就不需要对cell的内存进行拷贝。而Eager compaction会过滤重复的数据，并清理多余的版本，这意味着会有额外的开销。Adaptive策略则是根据数据的重复情况来决定是否使用Eager策略。在Adaptive策略中，首先会对待合并的segment进行评估，方法是在已经统计过不重复key个数的segment中，找出cell个数最多的一个，然后用这个segment的numUniqueKeys / getCellsCount得到一个比例，如果比例小于设定的阈值，则使用Eager策略，否则使用Basic策略。 3.5 支持高效对象存储 ApsaraDB for HBase2.0支持Medium-Sized Object (MOB) 主要目的是在HBase中，能高效地存储那些100k~10M 中等大小的对象。这使得用户可以把文档、图片以及适中的对象保存到HBase系统中。在MOB之前，常见有两个设计方案，第一种是直接保存中等对象到HBase中，另一种是使用HBase中只保存对象数据在HDFS的路径，中等对象以file形式存在HDFS中。这两个现有方案业务方案都有弊端。 通常人们直接存储在HBase中时，分两个列簇存储，一个保存普通信息，另一个用来保存中等对象数据。而通常中等对象一般都是几百KB到几MB大小的KV，这些数据直接插入memstore，会使得flush更频繁，可能几百条几千条数据就引起一次flush，产生更多的hfile后，compaction也会被触发得更频繁，I/O 也会随之变的很大，影响到整个系统的运行。 为了降低MOB中等对象直接存储导致的split、compaction、flush问题，人们开始使用另一种方案，把MOB对象数据存储到HDFS文件上，只在HBase保存MOB对象数据的文件路径。如下图： 这样可以减少split/compaction的影响，但是一致性时由客户端来保证的。另一方面，MOB对象一般是100k~10M的数据，此方案就是每个MOB对象在HDFS上保存一个文件，会产生非常多的小物件，很可能系统很快就使用完了文件句柄打开数。如果优化一下，把许多MOB写到HDFS序列文件上，hbase记录保存着MOB对象的文件路径和数据offset，确实解决了小文件问题，但是有带来另一个问题，那就是很难维护这些MOB对象数据的一致性，并且很难维护删除操作。 HBase2.0 MOB功能类似上述的第二种功能，hbase+HDFS文件的方式实现。不同的是，这些都是在server端完成，不需要client去维护数据的一致性。并且保存的HDFS文件不是简单的hdfs序列文件，而是HFile。这样它就可以有效管理这些MOB数据，并且和普通hfile一样处理deleted数据。 MOB数据的读流程是： 1. seek cell in HBase Table and find the MOB file path 2. find the MOB file by path 3. seek the cell by rowkey in the MOB file 读一个MOB的流程总是只open一个MOB file，所以不管有多少MOB file，是不会影响这个读性能的。所以split、compaction也并不是必要的。当然系统会设计compaction策略来定期删除掉那些deleted的数据，以腾出空间来。MOB的实现，使得用户在保存中等对象时，不必自己维护数据的一致性，更兼容了现在的HBase api操作MOB hfile。 3.6 异步client ——提高客户端并发/吞吐 HBase 2.0 前 HBase 的 Client 是同步调用的，HBase2.0后实现了异步的Client。异步客户端有两个好处： 1. 在单个线程中，异步客户端是非阻塞的，不需要等上一个请求的返回，就可以继续再发送多个请求，可提高客户端吞吐。 2. 可一定程度上解决故障放大问题，如因为某个业务的多个处理线程同时访问HBase 某个卡住的 RegionServer （GC原因，HDFS 访问慢，网络原因等）时，这部分的的业务的处理线程都会被卡住，此时业务的可用性要低于HBase 的可用性（HBase 其它的 RegionServer 可能是正常的）。 3.7 异步DFSClient——提高服务端性能 之前HBase 访问HDFS 都是同步的，经常发生因为HDFS 访问慢，而阻塞handler的情况。例如当前的处理HBase RPC的handler为100个，刚好这100个handler访问某个DataNode被阻塞。此时 RPC Server则无法处理前端请求，只能等访问HDFS数据返回或者超时才能释放hanlder 响应新的请求。而异步DFS Client 则不需要等待。可大大提高系统性能以及可用性。 3.8 Region多副本——读高可用，降低延时 ApsaraDB for HBase2.0引入region多副本机制，当用户对某个表开启此功能时，表的每个region会被分配到多个RegionServer上，其中replicaId=0的为主region，其他的为从region，只有主region可以写入，从region只能读取数据。主region负责 flush memstore成为hfile；从region一方面根据hfile列表类读到数据，另一方面对于刚写入主region但还没有flush到hdfs上的数据，通过replication同步到从region的memstore。 如上图所示，client1分别时间间隔内写入x=1、x=2、x=3，在同步数据的时候时，client2进行读x的值，它是可以读任何一台server上的x值，这就保证了读的高可用性，即使有n台机器挂了(n小于一个region的副本数)也可以有 99.9%延时 <20ms保证。可以看到这种架构读是高可用的，合适一写多读的场景。 这里还提供了两种读一致性模式，分别是strong和timeline-consistent模式，strong模式下，只读取主region的数据返回结果；timeline-consistent模式下，允许读任何一个region replica的数据返回。 四、展望 ApsaraDB for HBase2.0 是基于开源HBase2.0之上，融入了阿里HBase多年大规模实战检验和技术积累的新一代KV数据库产品。结合了广大企业云上生产环境的特定需求，定制了许多商业化功能，比如：oss、公网、本地盘、共享存储、冷热分离、备份恢复、安全等等。 接下来，我们在不断完善ApsaraDB for HBase2.0架构基础功能上，会陆续开放与完善更统一高效的SQL平台，并加强云HBase的生态建设，开放图数据库、时空数据库、cube数据库-Kylin等。 如上图所示，在接入层上，ApsaraDB for HBase2.0 陆续支持更多云产品链路直通访问，如：blink、CDP、LogService、emd、物联网套件等，开放HBase上生态组件，如：图数据库、时空、cube数据库等，让企业在云上完成数据库业务架构闭环。 网络层继续支持经典网/VPC专有网络选择，并支持弹性公网开关服务，方便了云上生产/云下开发调试用户需求。 中间件层继续支持并优化SQL 二级索引的创建与使用，支持多语言服务，thrift/rest服务化；ApsaraDB for HBase2.0陆续开放更强大的检索功能，包括全文检索、图检索、空间检索等，满足企业更复杂的业务检索需求。 在HBase内核层+存储层上，ApsaraDB for HBase2.0 采用的最新版的2.0内核，结合阿里HBase多年的技术积累经验，针对企业上云继续完善、优化更多商业化功能。例如： 1. 本地盘：服务器直通本地盘读写，效率高，成本低，相比高效云盘降低5倍。20T起购买。 2. 共享存储：实现HBase共享存储，动态添加容量包，使用灵活，成本低。 3. 冷热分离：冷热数据分别存储不同介质 4. 备份恢复：支持增量、全量备份恢复，支持跨集群跨机房容灾备份。 5. 企业安全：基于Intel&alibaba合作Hadoop Authentication Service安全项目， 兼容hadoop/hbase生态kerberos认证。 6. 离线弹性作业：为hbase批处理业务运行离线作业的弹性计算平台，使得hbase存储计算分离，把系统compaction、备份恢复、索引构建以及用户作业单独启动弹性计算资源进行离线处理，计算完后立刻释放，弹性伸缩。 7. SQL二级索引：支持phoenix二级索引，优化索引构建与查询功能。 8. 全文检索：支持solr全文索引，满足复杂的检索功能。 综合来说，ApsaraDB for HBase2.0是围绕企业HBase上云的使用环境，从内核功能到性能，从自动运维到专家坐诊，从开发效率到生产成本，完善的HBase生态体系，都为用户业务轻松上云稳定保驾护航。 五、申请试用 ApsaraDB for HBase2.0 于2018年6月6号正式发布，并开通公测申请，欢迎大家申请试用！点击了解更多 另外欢迎钉钉扫描关注“阿里云HBase技术交流群” 咨询“云HBase答疑”了解更多。 附录1：https://www.slideshare.net/HBaseCon/lift-the-ceiling-of-hbase-throughputs?qid=597ee2fa-8125-4faa-bb3b-2bf1ba9ccafb&v=&b=&from_search=6 附录2：https://blogs.apache.org/hbase/entry/offheap-read-path-in-production
背景 hbase2.0已经正式发布，对比之前1.x版本，2.0在读写链路上做了完善的优化，offheap、netty rpc等，这里做个小测试实验对比1.x和2.0在读写上的延时情况。本测试基于特定测试环境与软件版本得到的结果，仅供参考。 测试介绍 测试环境 HBase2.0集群，2副本DataNode，单regionserver，便于线性扩展，集群的配置 8core x 16G内存； 4 x 250G ssd云盘； 情况简介 读写，1KB，数据，分有cache的读（命中近100%），无cache读； scan：无cache的scan，有cache 的scan ； 预先分配60region 测试数据 单条读写的延时，99延时，磁盘的util，cpu的利用率，网卡占用率，gc的时间； 对于99延时的话，查看gc的频率，进行调整。大块数据的直接升到年老代等； 步骤，先是把没有做调优的性能数据丢出来，完成以后，在就99延时做调优，主要关注网络以及gc的信息； 测试结果 调优的涉及：offheap，netty server访问，g1 gc 修改。 99延时：offheap，g1 gc 默认开启，默认netty 开启；25MB 带宽峰值，主要做对比！ case 调优点 99延时 1.1版本(99.9延时) /1.4.4版本99延时(99.9延时) 99延时2.0开启优化(999延时) 单条延时1.1/1.4.4 单条延时优化2.0 1.1 rps/1.4.4 2.0rps 写 sync 1 offheap开启 410.840ms(1156.452ms)/392.422ms(510.943ms) 22.634ms(50.184ms) 43.06ms/42.62ms 7.65ms 4616/ 4752 26133 写 sync 2 offheap开启 382.196ms(617.041ms)/337.391ms(499.595ms) 31.038ms(61.771ms) 28.03ms/13.74ms 5.5ms 7172/14023 36085 写 sync 100 offheap开启 164.400ms(820.500ms)/64.055ms(460.636ms) 22.625ms(422.554ms) 5.62ms/3.01ms 3.07ms 34956/63621 67824 读无cache offheap开启 424.796ms(1071.ms)/292.628ms(801.108ms) 185.674ms(622.890ms) 54.63ms/27.50ms 11.64ms 3022/7222 14548 读大部分cache offheap开启 80.200ms(105.828ms)/26.900ms(58.095ms) 17.893ms(31.755ms) 6.30ms/4.98ms 4.80ms 31616/39802 41805 scan 无cache offheap开启 2529.507ms(5736.35sms)/2311.319ms(3204.116ms) 1609.485ms(3441.447ms) 1057.09ms/535.72ms 388.463ms 186*100/387 *100 515*100 scan 命中cache offheap开启 2452.913ms(3472.019ms)/450.97ms(629.903ms) 363.358ms(537.894ms) 测试小结 hbase2.0在读写链路上进行了完善的优化，相比1.1、1.4.4 版本，在延时方面有了比较大的成果。本测试基于特定测试环境与软件版本得到的结果，仅供参考。更多2.0特性优化，钉钉扫描下方二维码关注hbase技术交流群了解更多。 最后播报一下，云HBase2.0 在2018年6月6日将正式发布，点击了解更多
激动 HBase2.0 啥时候发布？好奇宝宝也是期待了很久，曾几何时都把stack问“烦”了，就在2018年4月30日中午， 期待已久的HBase 2.0发布啦！ 你是不是也很迫不及待想了解它？这次，作为一枚HBase搬运工，已经为你准备好了一大波 HBase 2.0.0导读材料，拿走不谢~ 北京时间2018年4月30日(星期一) 中午12:24，HBase的“掌门人”Michael Stack 在Announce Mail List中宣布了HBase 2.0.0 版本正式Release，大家可以开始下载使用了。 膜拜 拜读stack大神announce email原文，激动人心的时刻： The HBase team is happy to announce the immediate availability of Apache HBase 2.0.0. Apache HBase™ is the Hadoop database, a distributed, scalable, big data store. To learn more about HBase, see https://hbase.apache.org/. HBase 2.0.0 is our second major release, the first release off the HBase 2.0 line. Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0 Reference Guide before installing or upgrading for a list of notable incompatibilities, major changes, and features including a new Region assignment manager ("AMv2"), a means for configuring the read and/or write path to run off-heap, and an optional In-Memory Compaction ("IMC", A.K.A "Accordion") facility. According to our adopted Semantic Versioning guidelines[2], we allowed ourselves make breaking changes in this major version release. For example, Coprocessors will need to be recast to fit more constrained APIs and rolling upgrade of an hbase-1.x install to hbase-2.x without downtime is (currently) not possible. That said, a bunch of effort has been expended mitigating the differences; a hbase-1.x client can perform DML against an hbase-2 cluster. A bundled compatibility report showing difference from 1.2.6 may be of help [3]. For the complete list of fixes and improvements, see the included `CHANGES.md` (or online at [1]) and `RELEASENOTES.md`. ...... 邮件简述了HBase 2.0.0 有新版Assignment Manager V2,offhead read/write, in-memory compaction等。你是不是也很好奇，HBase 2.0 到底还有有哪些features？https://s.apache.org/hbase-2.0.0-JIRA-changes 上显示了HBase2.0.0相关的issue多达4551个issue, 这么多改动，还有哪些features值得关注一下呢？ 了解 下面整理了一些HBase2.0.0 主要的feature介绍，更多特性，可以参考上述链接： 1.A new Region assignment manager ("AMv2") ，HBASE-14350 , HBASE-14614 AssignmentManager V2基于Procedure V2实现，能够更快速的分配Region，维护的region状态机存储不再依赖于ZooKeeper。亲可以搭建一个hbase2.0 集群，查看ZK节点列表，已经找不到类似region-in-transistion节点了。 2.Offheaping of Read/Write Path HBASE-11425，HBASE-15179 读写路径中，使用Offheap区的内存，大大减少GC压力，提高稳定性、降低99延时。细节见下面offheap扩展阅读材料。 3.In-Memory Compaction HBASE-17343 重新设计了CompactingMemStore 替代 DefaultMemStore，数据会在内存中事先进行合并compact，有效提高后续常规compaction的效率。 4.NettyRpcServer HBASE-17263 其实并不新鲜，早在1.x 淘宝就有使用，现在2.0 开始默认使用NettyRpcServer 使用Netty替代HBase原生的RPC server，大大提升了HBaseRPC的吞吐能力，降低了延迟 5.Async Client HBASE-16833 HBASE-15921 Client不在是原来同步等待，而是利用异步RPC机制，大大提高Client端请求并发度，有效提高资源利用率，扩大吞吐。 7. Support for MOB (Medium-Sized Objects) HBASE-11339 MOB特性使得HBase支持存储小于10MB 的中等媒体对象数据，相比原来直接存储大对象插入hbase，其读写效率更高；Mob数据存储还是以hfile格式存储，兼容HBase现有特性，如snapshot、bulkload、replication等。MOB数据文件有独立的compaction和expire clean机制，稳定性更可控。 研究 还不过瘾？下面还真为热爱专研的砖友们网罗了一些hbase2.0特性详细的扩展阅读！都是大神执笔的干货： 1. hbase2.0 in-memory compaction 2. hbase2.0 read replicas 功能介绍 3. 基于HBase2.0上的备份恢复 4. hbase2.0 offheap write 5. hbase2.0 offheap read https://issues.apache.org/jira/browse/HBASE-11425 https://blogs.apache.org/hbase/search?q=offheap 6. hbase2.0 MOB 设计文档 7. HBase2.0 MOB 使用手册 8. HBase2.x Backup/Restore 9. HBase2.0 release issue 10. HBase 2.0 NettyRpcServer 11. hbase2.0 In-memory compaction 12. HBase 2.0 AMv2 https://docs.google.com/document/d/1jkIblLGxO4qgjo5lQOhAAypgDfxA_BEfxiPmcgDK0Do/edit https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.xp9zndoycwj https://docs.google.com/document/d/1DS44uwadHCbEK5rbx5itcjan-KsBlfQCQYYXB0A_gAM/edit?usp=sharing 13. HBase 2.0 ProcedureV2 官方下载&指南 HBase 2.0.0 安装包下载地址： http://www.apache.org/dyn/closer.lua/hbase/2.0.0/ 官方阅读： 1. https://s.apache.org/hbase-2.0.0-JIRA-changes 所有hbase2.0相关的jira，subtask 2. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10 最新的HBase 2.0.0官方指南3. http://apache.mirrors.tds.net/hbase/2.0.0/compatibiliity_report_1.2.6vs2.0.0.html 整理了v1.2.6和v2.0.0版本之间的兼容性报告 其他更多优化特性，不一一列举，后续可能会由”云HBase“小组为你带来更多HBase 2.0细节上的特性优化文章分享。 钉钉扫码关注hbase技术交流群，敬请期待。 最后播报一下，云HBase2.0 在2018年6月6日将正式发布，点击了解更多
背景 鉴于上次一篇文章——“云HBase小组成功抢救某公司自建HBase集群，挽救30+T数据”的读者反馈，对HBase的逆向工程比较感兴趣，并咨询如何使用相应工具进行运维等等。总的来说，就是想更深层理解HBase运维原理，提高运维HBase生产环境的能力，应对各种常见异常现象。不同的读者对hbase的了解程度不同，本文不打算着重编写一个工具怎么使用，而是从HBase的运维基础知识介绍开始讲解。为了能帮助大部分读者提高HBase运维能力，后续会写个“HBase运维系列” 专题系列文章，欢迎到最下方扫码关注钉钉交流。 介绍 相信很多自建HBase的企业会经常碰到各种各样的hbase运维问题。比如使用HBase的时候，HBase写入一段时间后开始RegionServer节点开始挂掉，重启RegionServer发现启动很慢，很多region出现RTI问题，导致读写某个region的业务hang住了 。还有一些人的HBase集群多次运维尝试后，直接HBase启动不了了，meta表上线就开始报错，导致最终业务不能正常上线运行等等系列问题。本文就HBase运维的原理基础开始入手，重点讲解数据完整性，以及元数据“逆向工程”恢复数据完整性的原理方法。开启后续一系列的HBase运维知识讲解。 HBase目录结构 本文就1.x版本进行讲解，不同版本大致相通。HBase在HDFS上会单独使用一个目录为HBase文件目录的根目录，通常为 “/hbase”。基于这个目录下，会有以下目录组织结构： /hbase/archive (1) /hbase/corrupt (2) /hbase/data/default/TestTable/.tabledesc/.tableinfo.0000000001 (3) /hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/info/2e58b3e274ba4d889408b05e526d4b7b (4) /hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/recovered.edits/340.seqid (5) /hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.regioninfo (6) /hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.tmp (7) /hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.splits (8) /hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.merges (9) /hbase/data/hbase/acl (10) /hbase/data/hbase/meta (11) /hbase/hbase.id (12) /hbase/hbase.version (13) /hbase/MasterProcWALs (14) /hbase/oldWALs (15) /hbase/.tmp (16) /hbase/.trashtables/data (17) /hbase/WALs/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com,16020,1523502350378/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com%2C16020%2C1523502350378.default.1524538284034 (18) (1) 进行snapshot或者升级的时候使用到的归档目录。compaction删除hfile的时候，也会把就的hfile归档到这里等。 (2) splitlog的corrupt目录，以及corrupt hfile的目录。 (3) 表的基本属性信息元文件tableinfo。 (4) 对应表下的hfile数据文件。 (5) 当splitlog发生时，一个RS的wal会按照region级别split WALs写到对应目录下的的recovered.edits目录上，使得此region再次被open的时候，回放这些recovered.edits 日志。 (6) regioninfo文件。 (7) compaction等的临时tmp目录。 (8) split时临时目录，如果上次region的split没有完成被中断了，这个region再open的时候会自动清理这个目录，一般不需要人工干预。 (9) merges时的临时目录，和split一样，如果没有正常完成的时候被中断了，那么他会在下次被open的时候自动清理。一般也不需要人工干预。 (10) acl 开启HBase权限控制时的权限记录系统表 (11) meta 元数据表，记录region相关信息 (12) hbase.id 集群启动初始化的时候，创建的集群唯一id。可以重新fix生成 (13) hbase.version hbase 软件版本文件，代码静态版本，现在都是8 (14) master执行过程程序的状态保存，用于中断恢复执行使用。 (15) oldWALs 历史wal，即wal记录的数据已经确认持久化了，那么这些wal就会被移到这里。splitlog完成的那些就日志，也会被放到这里。 (16) tmp 临时辅助目录，比如写一个hbase.id文件，在这里写成功后，rename到 /hbase/hbase.id (17) /hbase/.trashtables/data 当truncate table或者delete table的时候，这些数据会临时放在这里，默认1小时内被清 (18) 记录着一台RegionServer上的WAL日志文件。可以看到它是regionserver名字是有时间的，即下一次启动时RS的wal目录就会使用新的目录结构存放wal，这个旧的RS wal 目录就会被splitlog过程拆分回放 HBase涉及的主要文件及用途 HDFS静态文件，HDFS上的HBase 数据完整性 1. hfile文件：数据文件，目前最高版本也是默认常用版本为 3。 hfile文件结构细节可以参考官网http://hbase.apache.org/book.html#_hfile_format_2。我们这里逆向生成元数据主要使用到了HFile fileinfo的firstkey、lastkey信息。 2. hfilelink文件: 在hbase snapshot时用到, migration upgrade 也会使用到。很少碰到这类文件的运维问题，这里不作过多介绍。 3. reference文件：用来指定half hfile，一个region有reference时，这个region不能split。split/merge会创建这个。进行compaction后生成新的hfile后，会把这个reference删除。hfile的reference文件名格式一般是 hfile.parentEncRegion。如：/hbase/data/default/table/region-one/family/hfilename。其region-two有reference hfile文件名格式为：/hbase/data/default/table/region-two/family/hfile.region-one 通常无效引用就是 region-one的hfile不存在了，那么这个引用就会失效。他的修复方法一般是把reference无效的引用移除。 4. ".regioninfo" 文件，保存着 endkey/offline标志/regionid/regionName/split标志/startkey/tablename等 5. tableinfo文件这类文件保存着 tableName/table属性信息/table级别config信息/family信息。其中family信息保存着 famliyName/famiy属性/famliy级别config信息等。 通常，table属性有：REGION_MEMSTORE_REPLICATION,PRIORITY,IS_ROOT_KEY等，一般这些属性默认也是根据配置的一样。family属性有：BLOCKSIZE,TTL，REPLICATION_SCOPE等，一般属性是根据配置使用默认的。 6. hbase:meta表数据内容格式 regionname, info:regioninfo, regioninfo的encodeValue值 regionname, info:seqnumDuringOpen, 序列号 regionname, info:server, region所在的server名 regionname, info:serverstartcode, regionserver 启动的timestamp 元数据逆向生成原理 上述介绍的数据文件中，HBase的主要的元数据主要由meta表、tableinfo、regioninfo构成。这里的逆向生成元数据指的是，根据数据hfile数据文件，反向生成regioninfo/tableinfo/meta表的过程。 1. 逆向生成tableinfo文件 case1. 通过从master进程内存中的tabledescritor cache 完整恢复tableinfo文件，此时恢复的tableinfo是完整的，和之前的完全一样。 case2. 当cache中没有加载过此表的tableinfo时，修复过程只能从表的目录结构list所有familyNames 来恢复tableinfo，这个时候只能得到的是列簇的名字，恢复tableinfo文件内容中，除了表名、列簇名一致，其他的属性均采用默认值。这个时候如果运维人员知道有什么属性是自定义进去的，那么就需要要手动再次添加进去。 2. 逆向生成regioninfo文件 hfile 中的fileinfo读取firstkey/lastkey 排好序，得到region下所有hfile的最大rowkey和最小rowkey，并根据tableinfo中的表名 完整恢复 regioninfo文件。主要这里只能恢复 表明/startkey/endkey, 其他属性如：offline标志，regionName,split标志，hashcode等均使用代码生成或者配置的默认值。 3. 逆向填充meta表行 regioninfo文件序列化，填入meta表 info:regioninfo 列，并同时写入默认的server，等它被再次open的时候，重新分配region到实际的regionserver上，并更新这里的数据行。 逆向工程除了上面的直接文件、数据内容修复外，还涉及到数据的完整性其他方面修复。一个表示由无穷小的rowkey到无穷大的rowkey范围组成，还可能会发生的问题如：region空洞、region重叠现象，如： 如果有region空洞的时候，就会使用他们的空洞边界作为startkey/endkey，再修复创建一个region目录及目录下的regioninfo文件。如果是region重叠，则会把重叠的region进行合并，取所有region的最大最小rowkey作为merge后新region的最大最小rowkey。 元数据工具修复 元数据的缺少或者完整性有问题，会影响系统运行，甚至集群直接不可用。最常见的如 meta表上线失败，region 上线open失败等。这里介绍两个工具，工具一: hbase hbck 在线修复完整性修复元数据信息，工具二：OfflineMetaRepair 离线重建 hbase:meta 元数据表。 在线hbck修复： 前提：HDFS fsck 确保 hbase跟目录下文件没有损坏丢失，如果有，则先进行corrupt block 移除。 步骤1. hbase hbck 检查输出所以ERROR信息，每个ERROR都会说明错误信息。 步骤2. hbase hbck -fixTableOrphones 先修复tableinfo缺失问题，根据内存cache或者hdfs table 目录结构，重新生成tableinfo文件。 步骤3. hbase hbck -fixHdfsOrphones 修复regioninfo缺失问题，根据region目录下的hfile重新生成regioninfo文件 步骤4. hbase hbck -fixHdfsOverlaps 修复region重叠问题，merge重叠的region为一个region目录，并从新生成一个regioninfo 步骤5. hbase hbck -fixHdfsHoles 修复region缺失，利用缺失的rowkey范围边界，生成新的region目录以及regioninfo填补这个空洞。 步骤6. hbase hbck -fixMeta 修复meta表信息，利用regioninfo信息，重新生成对应meta row填写到meta表中，并为其填写默认的分配regionserver 步骤7. hbase hbck -fixAssignment 把这些offline的region触发上线，当region开始重新open 上线的时候，会被重新分配到真实的RegionServer上 , 并更新meta表上对应的行信息。 离线OfflineMetaRepair重建： 前提：HDFS fsck 确保 hbase跟目录下文件没有损坏丢失，如果有，则先进行corrupt block 移除 步骤1： 执行 hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair -fix 最后，两个工具使用说明都比较详细，经过上面的基础介绍，相信都会看的懂的。这里不对工具再细致说明，工具的说明可以参考官网或者工具提示。题外话，有些开源组件设计的时候，向hbase元数据文件写入一些特有的信息，但是并没有修改到hbase工具的修复工具，或者它自己没有维护修复工具，如果这类文件损坏、丢失了，那么相应的组件就会运行不正常。使用这类组件的用户，应该不仅记录好你的表的基本结构，还要记录表的属性配置等，当发生修复运维行为的时候，主要再次核对确认。 小结 本文介绍了运维hbase基础原理中的数据完整性以及逆向元数据修复原理，并举例介绍两个逆向修复元数据的工具和实用执行步骤。后续会出系列文章，说明更多hbase运维基础、运作原理等，希望对大家的运维和使用HBase有所帮助。欢迎更多意见和HBase技术交流，钉钉扫码关注更多：
概述 使用过开源HBase的人都知道，运维HBase是多么复杂的事情，集群大的时候，读写压力大，配置稍微不合理一点，就可能会出现集群状态不一致的情况，糟糕一点的直接导致入库、查询某个业务表不可用， 甚至集群运行不了。在早期0.9x版本的时候，HBase的修复工具还有一下bug，使得即使你懂得如何修复的情况下，依然需要多次重复运行命令，绕过那些不合理的修复逻辑，甚至有时候需要自己写代码预先修复某个步骤。 背景 上周五，某公司使用的某DataHup 大数据产品自建一个HBase集群挂了！整个集群有30+T 业务数据，是公司的数据中心，集群直接启动不了。他们也是经历了熬战一天一夜的情况下，依旧没有解决恢复，还曾有过重装集群重导数据念头。最后，通过钉钉HBase技术交流群找到群主——阿里云HBase的封神。随后其立即下达命令，临时成立 HBase抢救小分队，尽力最大的努力，使用最低风险的方式，抢救最完整的集群。 蹭蹭蹭，几个抢救队员集齐，开始救火。 救火开始 虽然紧急，但是抢救工作不能乱，我们把救火过程主要分为几步： 1. 定位现象问题所在 首先与用户沟通现场环境情况，以及客户在出问题之前做过哪些重大操作，特别是一些特殊操作，平时没做过的。据用户描述已经远程观察了解到，用户使用开源的某DataHup自建了一个HBase集群， 存储公司的大量的业务，是公司的数据中心。集群有7个RegionServer、2个Master，32核256G的机器配置，业务数据量有30+T。HBase的master已经都挂了，两个 RegionServer也挂了，用户使用过“重启大法”，依旧无法正常运行。 寥寥几句没有更多信息，我们只能上集群开日志，打jstack，观察HBase运行流程为什么中断或者挂掉。 首先我们先检查HDFS文件系统，fsck发现没有什么异常。其次开始检查HBase，把Debug日志打开，全部关闭HBase集群，为了便于观察现象，只启动一个Master和一个RegionServer。启动后，发现Master 因为fullscan meta表（master启动的一个流程）timeout Abort 终止了。观察meta region分配到的RegionServer也挂了，查看日志并没有异常，貌似是这个开源的DataHup 当RegionServer scan数据操作超时 会被manager kill掉的样子。打jstack发现，Master确实在等待fullscan meta完成，而接管meta region 的RegionServer确实一直在忙着scan meta数据，确实有忙不过来超时了。按理说，扫描meta表应该很快的才对。 检查发现HDFS的HBase meta表有1T多数据！！！进一步查看现象HFile的内容，发现了大量的Delete famly 的cell存在，而且很多是重复的，序列号（没有截图，想象一下）。问题现象定位了，用户使用这个系列的DataHup 的HBase生态时，有组件存在bug往hbase meta表写了大量的这些冗余的delete数据，导致hbase 启动时full scan meta卡着，最终导致整个集群无法正常启动运行服务。 2. 提出解决方案，评估风险 我们很快生成了两个相对较优的方案。第一个是使用离线compaction，把hbase meta表进行一次major compaction把多余的delete family删除，然后再重启即可。第二个方案是，直接移除meta 表的无用hfile, 逆向生成meta 表数据进行修复meta表即可。 第一个方案做离线compaction对集群来说没有什么风险，缺点是离线compaction并不快，因为meta表region只有一个，执行离线meta表compaction时只有一个task，非常的缓慢耗时。 第二个方案是逆向修复meta表信息。看似风险很大，其实实际操作起来，很多风险可以降低。我们可以备份好核心的元数据，只有就可以在恢复失败的时候，还原到原来修复手术的前状态。这样一来，这个修复过程也就风险极大降低了。 3. 开始实施 秉着更安全风险更低的情况下，我们还是先选择了方案一，给meta表做离线major compaction的方案。但最终因为MapReduce和本地模式的compaction都太慢了，开始会oom，调整后，最终因meta的hfile checksum校验失败中断了。meta表的hfile都存在问题，那么这个compaction过程就不能正常进行了。 我们开始选择方案二，和用户沟通风险后，开始制定操作步骤， 把这个方案的实施带来的风险尽可能降到最低。规避这个方案存在的风险，前提是懂得这个方案会有什么风险。下面我们来分析一下，如图： 可以看到，开源HBase的meta表，是可以逆向生成回来的，但是有可能不同的DataHup生产商可能会有一些额外的信息hack进meta表里，对于这部分信息，在开源的逆向生成过程中是不包含的，存在这个关系数据丢失。但是这些核心的业务数据都存在，只是hack的第三方关联信息不存在了。有人可能会问，会有哪些数据可能hack到这里呢？曾看到过某厂商会在meta表了多加一些额外的字段用来保存virtual hostname信息，还有一些将二级索引相关的信息会保存在tableinfo 文件那里。HBase的开发商越多，什么姿势都可能存在，这个就是可能的风险点。 接下来我们开始实施，这个问题比较典型，用户的meta表里，有1T多的hfile 数据，检查hfile 发现几乎99%的hfile是delete famly相关的内容，我们就移除这些delete famly的hfile到备份目录，只留下一个正常数据的hfile，而这个hfile也仅仅有30M左右的数据。重启HBase后，正常运行。HBase一致性检查发现很幸运，没有坏文件，也没有丢失的tableinfo、regioninfo、hfile相关的block等。如果发现有文件丢失，corrupt hfile等等问题，逆向生成元数据的修复过程就可能会带来风险，但HBase集群核心业务数据依然可以完整挽救。 4. 用户再自己验证一下是否正常 通知用户验证集群运行，业务运行情况。 小结 由于用户的自建HBase集群不像云HBase一样可以我们远程登录管理，只能使用一些远程桌面工具先登录到用户的工作PC再跳到集群环境上，整个操作起来非常的卡顿，影响了问题定位以及最终抢救的效率。 很多用户使用某些开源DataHup自建集群都会碰到各种各样的运维问题，不要害怕，只要HDFS数据不丢失，HBase怎么挂都可以拯救回来的，不用急着格式化HBase集群重装/重导数据。更多HBase 故障恢复技术交流，请关注钉钉HBase技术交流群。 最后播报一下，云HBase2.0 在2018年6月6日将正式发布，点击了解更多
2019年11月
发表了文章
2019-11-22 16:02:17
发表了文章
2019-11-22 14:50:26
发表了文章
2019-11-22 14:50:04
发表了文章
2020-04-03
发表了文章
2019-11-22
发表了文章
2019-11-22
发表了文章
2019-11-22
发表了文章
2019-02-12
发表了文章
2018-06-05
发表了文章
2018-05-13
发表了文章
2018-05-02
发表了文章
2018-05-01
发表了文章
2018-04-16
回答了问题
2019-07-17
之前碰到过有人遇到大量的wal积压，原因是indexer删除某个测试索引的时候，没有删干净，导致这个关联的主表后来的wal都没有删除，大量的积压不可消费timeout。异常timeout的原因无用的索引导致的。如果自己搭建的话，建议搞清楚这个索引映射关系，按着这个链路查看timeout的源头是什么
回答了问题
2019-07-17
像这种情况，可以使用facet计数，设置facet的field为 你说的 “某个字段” 即可，查询结果中，facet info中带有按照“某个字段” 分类进行计数。当然，使用stats也可以； 相关demo可以参考 github中的solr相关demo “https://github.com/aliyun/aliyun-apsaradb-hbase-demo/”
回答了问题
2019-07-17
回答了问题
2019-07-17
回答了问题
2019-07-17
回答了问题
2019-07-17
hbase删除数据比较简单，truncate一下就行。
solr删除所有数据，可以参考：
CloudSolrClient client = new CloudSolrClient.Builder().withZkChroot(zkroot).withZkHost(zkhost).build())；
UpdateResponse response = client.deleteByQuery(collection,"f9_i:[0 TO 5]");
System.out.println(response);
命令行方式可以参考：
curl -X POST -H 'Content-Type: application/json'
'http://localhost:8983/solr/my_collection/update' --data-binary '
{
"delete": { "query":":" } / delete by query all /
}'
回答了问题
2019-07-17
二级索引其实还是比较通用的叫法，每个索引都可以称为hbase的二级索引。目前我们常说的phoenix二级索引，是指的phoenix提供的全局索引和局部索引，这些索引都是使用hbase的rowkey特点来实现的。solr给hbase提供的索引叫全文索引，相关的介绍可以参考：
https://yq.aliyun.com/articles/687098
另外，如果你对阿里云HBase集成solr感兴趣，可以咨询“阿里云hbase答疑”客服，阿里云hbase自2019年1月22日之后，陆续开放控制台可以用户自行开启 全文索引服务。
回答了问题
2019-07-17
lily indexer的同步过程中，如果更新的数据中，没有包含所有需要的列，它需要配置read-row为dynamic，让indexer回读完整数据，这样插入覆盖时，document的数据才全，否则就出现你这个情况。
回答了问题
2019-07-17
你好，可以参考资料：https://yq.aliyun.com/articles/687098
如果是使用阿里云HBase，参考hbase帮助文档，2019年1月22日之后，会陆续发布hbase for solr全文索引服务，用户可以自行在
控制台开启solr全文索引服务。更多资料或者问题，还可以咨询“阿里云hbase答疑”客服了解更多
回答了问题
2019-07-17
replication机制会有一些延时，如果很久没看到数据，可能就是你配置错了。
如果是丢数据问题，参考这个问题下面的回答：https://yq.aliyun.com/ask/448779?spm=a2c4e.11153959.0.0.31b4164aa0dZCO
回答了问题
2019-07-17
开源这里目前有几个问题会有隐患：
1）多副本时，不保证所有副本都成功，可能会异常只写一个leader成功就算成功，如果还没有来得及同步，leader也挂了，那么就可能会出出现数据丢失了。
2）插入数据时，某部分语法的异常，lily indexer没有catch住不断重试，这部分就会被略过了，这个是现在开源的默认唯一动作
3） 同步索引过程中，没有版本的概念，WAL的replication只是按照 RS级别有序，如果一个rowkey1开始在RS1，积压了很多wal没有同步，因为某种原因rowkey1转到RS2，这个时候RS2没有什么wal积压，这个时候rowkey1的最新修改可能会被先同步到solr。
而原来的RS1上的大量wal，可能到来时间是比较晚一点，但正因如此，这些晚到的旧数据会覆盖掉新的数据。
更多hbase+solr+indexer的一些局限性、有点，请参考 https://yq.aliyun.com/articles/687098
回答了问题
2019-07-17
提出的hbase+es和hbase+phoenix的比较，那么你应该会有一些查询需求，可能rowkey无法满足的，而phoenix的最重要的
部分就是二级索引，扩充更多额rowkey设计机会，但是毕竟还是rowkey方式，rowkey总有它的查询局限性。
阿里云HBase提供了 类似的方案，hbase+solr，详情参看 https://yq.aliyun.com/articles/687098 资料对比适用的 场景，供参考。