数据迁移实践

      4月下旬，进入了公司的核心升级项目，前期一直处于需求开发阶段。虽然内心一直告诫自己：一定要进行阶段性的总结。但终究还是没能逃过惰性的掌控，这一拖就到了8012的年底。

      这一年来，需要总结的内容主要有以下几点：

1. 账单云系统升级——历史账单数据迁移
2. 核心升级项目
3. 数据迁移

还是从第三点，最近几周的工作开始说吧。

      11月中旬，核心项目功能性开发基本完成，并进入UAT。核心项目的数据迁移事宜原本我是不会触及的，但由于工作协调的原因，有幸参与到了部分数据迁移的工作当中。

      此次迁移并不是简单的跨机房的数据迁移，为了适应新业务，原有数据在迁至新系统后，结构、字段甚至取值逻辑都将发生变化。新系统使用Hbase做为分布式存储，由于hbase和hive同样都是建立在hadoop之上，于是可以方便的将hive table与hbase中的table进行整合，以此来达到数据迁移至hbase的目的。（注：有特定的转码工具，将从主机下载的数据转为utf-8编码的csv文件）

      最初的方案是：从hive中映射hbase table，即创建一个指向已存在的hbase表的hive外部表。向该外部表插入数据，即可完成数据插入hbase。在hive中创建hbase外部表：

CREATE EXTERNAL TABLE hbase_table_xxx (
    key string,
    field1 string,
    field2 string
) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
  WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key,cf1:field,cf1:field2")
 TBLPROPERTIES("hbase.table.name"="table_xxx","hbase.mapred.output.outputtable"="table_xxx");

      这个方法能完成数据插入到hbase不假，但在性能上存在很大的问题：当进插入数据达到百万级别时，就已经开始出现数据不能写入的情况了。后来发现，用这种方式：

INSERT INTO hbase_table_xxx
AS
SELECT 
    key,
    field1,
    field2
FROM table_xxx;

      向hbase插入数据时，每个INSERT，都会构建一个新的Hbase Put对象，相当于并发的向RegionServer发送写请求，这会导致RegionServer的handler被耗尽，从而致使后续的数据不能正确写入了。

      于是改使用importtst&bulkload的方式来导入到hbase，该方法虽然多出了将hive导出为csv这一步，但通过先使用importtsv生成Hfile，再用bulkload将Hfile导入到hbase table，能够避免大量的向RegionServer发送写请求，极大的减缓了RegionServer的压力。

      数据迁移至hbase大致就是这样，后面还会分享一篇关于数据迁移写入ElasticSearch的。

      欢迎各位的关注！