作者介绍
梁铭图，新炬网络首席架构师，十多年数据库运维、数据库设计、数据治理以及系统规划建设经验，拥有Oracle OCM、Togaf企业架构师（鉴定级）、IBM CATE等认证，曾获dbaplus年度MVP以及华为云MVP等荣誉，并参与数据资产管理国家标准的编写工作。在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。
时至今日，Hadoop大数据平台已经不是什么新鲜的技术，我们的客户很多也着手围绕hadoop生态体系为基础构建企业大数据中心。但是，目前企业的存量生产系统还是主要由Oracle数据库构成，大数据中心不可避免地要从Oracle数据库中同步海量数据到Hadoop体系当中。
之前，我写的文章主要讲述了Oracle到Hadoop的批量数据同步。但是，批量同步的缺点也很明显，就是数据的时延较大。企业的许多数据分析的要求更为实时的时候，批量同步模式就不再适用。我们需要寻求实时数据同步工具的协助。GoldenGate，这个我们Oracle数据同步的神器也有了大数据版本的支持，正是我们测试的目标。
一、 测试目的以及范围
本次测试目的为：
验证Oracle GoldenGate for BigDATA能否实现Oracle DB以及HADOOP平台的数据同步，具体内容包括如下方面：
● 能否将Oracle DB的数据全量同步到HIVE上
● 能否将Oracle DB的数据增量同步到HIVE上
● 数据全量信息以及增量信息能否还原成Oracle的表
本次测试的测试信息如下
|
名称 |
内容 |
备注 |
|
源端数据库名 |
xxDB |
本次测试Oracle GoldenGate并没有直接部署在源端生产系统，而是部署在其ADG主机上。 |
|
源端数据库集群节点数 |
2 |
|
|
源端数据库归档量 |
日均：2.5TB+/天 峰值：3TB+/天 |
|
|
测试表名称 |
Test_table |
此测试表为无主键表 |
|
测试表大小 |
10+GB |
|
|
测试表数据量 |
1亿+ |
二、 Oracle GoldenGate软件信息
|
名称 |
内容 |
|
GoldenGate版本 |
12.2.0.2.2 |
|
平台信息 |
AIX 7.1 64bit |
|
Oracle数据库版本 |
Oracle DB 11.2.0.3 |
|
名称 |
内容 |
|
GoldenGate版本 |
12.2.0.1.160823 |
|
操作系统平台信息 |
Linux, x64, 64bit |
|
HDFS文件系统 |
/ceshi/OGG_TEST/ |
|
HIVE数据库用户 |
OGG_TESTDB |
三、 Oracle GoldenGate全量数据同步测试
Report at 2018-02-08 09:52:19 (activity since 2018-02-08 09:10:41)
Output to ./dirdat/id:
From Table SYS.test_table:
# inserts: 121366772
# updates: 0
# deletes: 0
# discards: 0
可以从结果看到，表的记录数为121366772，数据导出耗时约40分钟。
关于这个导出结果，需要说明的有两点：
● 基于导出时需要考虑SCN、需要记录操作类型等特殊需求的考虑，此处采取了视图来指向测试表test_table
● 导出的同时是允许导入的，因此总体耗时并非简单的两者间叠加。
Report at 2018-02-08 11:42:34 (activity since 2018-02-08 09:19:27)
From Table test_table to STREAM.test_table:
# inserts: 121366772
# updates: 0
# deletes: 0
# discards: 0
可以从结果看到，表的导入记录数为121366772与导出结果一致，导入耗时约2小时23分。
完成数据到HDFS的同步后，可以在HIVE上创建外部表，并进行查询。
INFO : MapReduce Total cumulative CPU time: 30 minutes 6 seconds 120 msec
INFO : Ended Job = job_1517882185835_40717
+-----------+-------------+------------+--+
| row_head | ora_optype | _c2 |
+-----------+-------------+------------+--+
| AAJhk/ | INSERT | 121366772 |
+-----------+-------------+------------+--+
1 row selected (83.169 seconds)
可以看到，在HIVE上的查询的出的记录与导入结果一致，且rowid的行首信息一致，不存在异常的换行现象。
Oracle GoldenGate可以实现Oracle DB到HIVE的全量数据同步。
本次测试中，仅针对GoldenGate的初始化装载功能做功能测试，并没有实现包括但不限于开并行、开并发等各种方式的调优。此外，针对数据量较大的情况，建议可以考虑通过sqoop等方式进行数据的初始化。
四、 Oracle GoldenGate增量数据同步测试
源端抽取进程运行情况
> stats ex_new,total
Sending STATS request to EXTRACT EX_NEW ...
Start of Statistics at 2018-02-08 16:30:00.
Output to ./dirdat/new/sf:
Extracting from TEST_TABLE to TEST_TABLE:
*** Total statistics since 2018-02-08 09:05:22 ***
Total inserts 1175.00
Total updates 38700.00
Total befores 38700.00
Total deletes 0.00
Total discards 0.00
Total operations 39875.00
End of Statistics.
源端投递进程运行情况
GGSCI (DGNG3CRM-DDB) 4> stats DP_NEW,total
Sending STATS request to EXTRACT DP_NEW ...
Start of Statistics at 2018-02-08 16:30:46.
Output to ./dirdat/new/tf:
Extracting from TEST_TABLE to TEST_TABLE _STREAM:
*** Total statistics since 2018-02-08 15:51:47 ***
Total inserts 730.00
Total updates 20480.00
Total deletes 0.00
Total discards 0.00
Total operations 21210.00
End of Statistics.
通过GoldenGate的LOGDUMP分析，数据同步期间数据的变化情况
GOLDENGATE.TEST_TABLE_STREAM Partition 12
Total Data Bytes 21465617
Avg Bytes/Record 1146
Insert 447
FieldComp 21
GGSPKUpdate 18249
After Images 18717
通过HIVE查询的全量+增量日志信息
可以看到，其中普通数据更新（对应FieldComp）、主键数据更新（对应GGSPKUpdate）均与logdump的结果保持一致，而INSERT的记录数121367219则恰好是logdump中insert记录数447与全量同步测试中数据量121366772之和。
+-----------+-----------------+------------+--+
| row_head | ora_optype | _c2 |
+-----------+-----------------+------------+--+
| AAJhk/ | INSERT | 121367219 |
| AAJhk/ | SQL COMPUPDATE | 21 |
| AAJhk/ | PK UPDATE | 18249 |
+-----------+-----------------+------------+--+
Oracle GoldenGate可以实现了Oracle DB到HIVE的全量数据同步。
通过基于记录数的核对，可以看到Oracle GoldenGate写入HIVE中不存在数据丢失。
本次源端以及目标端分别选择了三个时间格式的字段，以”YYYY”的格式做GROUP BY，核对记录数是否一致。
源端查询语句：
select to_char(BIRTHDAY,'yyyy'),to_char(MARRIEDDATE,'yyyy'),to_char(EXPIREDATE,'yyyy'),count(*)
from NGCRM_DG.CM_CU_INDIVIDUAL as of scn 13732429997989
group by to_char(BIRTHDAY,'yyyy'),to_char(MARRIEDDATE,'yyyy'),to_char(EXPIREDATE,'yyyy') order by 1,2,3
目标端查询语句：
select substr(BIRTHDAY,1,4),substr(MARRIEDDATE,1,4),substr(EXPIREDATE,1,4),count(*)
from ogg_testdb.cm_cu_individual
group by substr(BIRTHDAY,1,4),substr(MARRIEDDATE,1,4),substr(EXPIREDATE,1,4) order by 1,2,3;
经过对比结果数据一致。
五、 测试问题汇总
|
问题 |
解决方法 |
|
数据同步到HADOOP平台上出现乱码 |
源端的字符集为GBK，考虑到HADOOP平台对UTF-8以外字符集支持并不友好，本次测试中，目标端字符集已改为UTF-8 |
|
源端的文本记录存在换行符导致HDFS上一行变成多行 |
采取新的换行符，本次测试中，换行符为'%$^' |
|
java.lang.OutOfMemoryError: Java heap space报错 |
HIVE上做下述设置 set hive.map.aggr=true; |
|
No valid credentials provided报错 |
对ogg做认证 kinit -kt ~/ogg.keytab ogg_test |
230721
1、导入Mongo Monitor监控工具表结构（mongo_monitor…
上面提到： 在问题描述的架构图中我们可以看到，Click…
PMM不香吗？
如今看都很棒