共计 1829 个字符，预计需要花费 5 分钟才能阅读完成。
一、计划背景
现阶段局部业务数据存储在 HBase 中，这部分数据体量较大，达到数十亿。大数据须要增量同步这部分业务数据到数据仓库中，进行离线剖析，目前次要的同步形式是通过 HBase 的 hive 映射表来实现的。该种形式具备以下痛点：
- 须要对 HBase 表进行全表扫描，对 HBase 库有肯定压力，同步数据同步速度慢。
- 业务方对 HBase 表字段变更之后，须要重建 hive 映射表，给权限保护带来肯定的艰难。
- 业务方对 HBase 表字段的变更无奈失去无效监控，无奈及时感知字段的新增，对数仓的保护带来肯定的艰难。
- 业务方更新数据时未更新工夫戳，导致通过工夫戳字段增量抽取时数据缺失。
- 业务方对表字段的更新新增无奈及时感知，导致字段不全须要回溯数据。
基于以上背景，对 HBase 数据增量同步到数仓的场景，给出了通用的解决方案，解决了以上这些痛点。
二、计划简述
2.1 数据入仓构建流程
2.2 HBase 数据入仓计划试验比照
别离对以上三种实现计划进行合理性剖析。
2.2.1 计划一
应用 HBase 的 hive 映射表 。此种计划实现形式简略，然而不合乎数仓的实现机制，次要起因有：
- HBase 表尽管是 Hadoop 生态体系的 NoSQL 数据库，然而其作为业务方的数据库，间接通过 hive 映射表读取，就类比于间接读取业务方 Mysql 中的视图，可能会对业务方数据库造成肯定压力，甚至会影响业务的失常运行，违反数仓尽可能低的影响业务运行准则。
- 通过 hive 映射表的形式，从实现形式上来讲，减少了与业务方的耦合度，违反数仓建设解耦准则。
所以此种计划在此理论利用场景中，是不应该采取的计划。
2.2.2 计划二
依据业务表中的工夫戳字段，抓取增量数据 。因为 HBase 是基于 rowKey 的 NoSQL 数据库，所以会存在以下几个问题：
- 须要通过 Scan 全表，而后依据工夫戳（updateTime）过滤出当天的增量，当数据量达到千万甚至亿级时，这种执行效率就很低，运行时长很长。
- 因为 HBase 表更新数据时，不像 MySQL 一样，能自动更新工夫戳，会导致业务方没有及时更新工夫戳，那么在增量抽取数据的时候，会造成数据缺失的状况。
所以此种计划存在肯定的危险。
2.2.3 计划三
依据 HBase 的 timeRange 个性（HBase 写入数据的时候会记录时间戳，应用的是服务器工夫），首先过滤出增量的 rowKey，而后依据这些 rowKey 去 HBase 查问对应的数据 。这种实现计划同时解决了计划一、计划二的问题。同时，可能无效监控业务方对 HBase 表字段的新增状况，防止业务方未及时告诉而导致的数据缺失问题，可能最大限度的缩小数据回溯的频率。
综上，采纳计划三作为实现 HBase 海量数据入仓的解决方案。
2.3 计划抉择及实现原理
基于 HBase 数据写入时会更新 TimeRange 的个性，scan 的时候如果指定 TimeRange，那么就不须要扫描全表，间接依据 TimeRange 获取到对应的 rowKey，而后再依据 rowKey 去 get 出增量信息，可能实现疾速高效的获取增量数据。
为什么 scan 之后还要再去 get 呢？次要是因为通过 timeRanme 进去的数据，只蕴含这个工夫范畴内更新的列，而无奈查问到这个 rowkey 对应的所有字段。比方一个 rowkey 有 name，age 两个字段，在指定工夫范畴内只更新了 age 字段，那么在 scan 的时候，只能查问出 age 字段，而无奈查问出 name 字段，所以要再 get 一次。同时，获取增量数据对应的 columns，跟 hive 表的 meta 数据进行比对，对字段的变更进行及时预警，缩小后续因少同步字段内容而导致全量初始化的状况产生。其实现的原理图如下：
三、成果比照
运行工夫比照如下（单位：秒）：
四、总结与瞻望
数据仓库的数据来源于各方业务零碎，高效精确的将业务零碎的数据同步到数仓，是数仓建设的基本。通过该解决方案，次要解决了数据同步过程中的几大痛点问题，可能较好的保证数据入仓的品质问题，为后续的数仓建设打下一个较好的根底。
另外，通过屡次试验比照，及对各种计划的可行性剖析，将数据同步计划同步给一站式大数据开发平台，推动大数据开发平台反对基于 timeRange 的增量同步性能，实现此性能的平台化、配置化，解决了 HBase 海量数据入仓的痛点。
同时，除了以上这几种解决方案之外，还能够尝试联合 Phoenix 应用二级索引，而后通过查问 Phoenix 表的形式同步到数仓，这个将在前期进行性能测试。
作者：vivo 互联网大数据团队 -Tang Xicheng
