记一次 datax 数据导出作业 （从hive导出到oracle）的性能排查与优化

    不管企业数据平台的底座是企业级数仓平台 eds，还是大数据数据湖 datalake，或者当前大热的湖仓一体 lakehouse， 抑或所谓的数据中台，大数据与RDBMS之间的数据导入和导出都是企业日常数据处理中常见的一环，该环节一般称为 e-t-l 即 extract-transform-load。市面上可用的 etl 工具和框架很多，如来自于传统数仓和BI圈的 kettle/informatica/datastage, 来自于hadoop生态圈的sqoop/datax，抑或使用计算引擎 spark/presto/flink 直接编写代码完成etl作业。

    笔者在这里分享一次使用 datax 从 hive 导出数据到 oracle 的作业的性能问题的排查和优化思路，希望对大家类似问题的排查有所帮助。

    接到业务人员反馈导出作业执行很慢的消息后，笔者首先查看了对应的作业的datax的日志，以获得详细的性能指标，如下是最近两次作业执行的datax的日志，可见任务平均流量分别是上一次的 38KB/S 和 最近一次的26KB/S，这样的速度确实是有问题的，需要进一步排查；仔细留意日志可以发现Task waitWriterTime 是远远大于Task waitReaderTime，也就是说等待写的时间是远远大于等待读的时间的，所以性能跟读取上游 hive 数据 没有关系，瓶颈是在写入 Oracle 数据。

   datax是相对成熟的框架，oracleWriter 插件也比较成熟，所以接下来的排查思路，一方面是去排查 oracle 数据库服务器的性能和oracle性能相关参数配置，另一方面是排查 oracle表的结构和索引等是否合理。

    首先登陆数据库服务器节点，通过 df -h, free -h 和 top 三连发查看机器配置和当前负载， 磁盘和cpu都还好，但明显看到内存只有46g 且当前 available的只有1.3G了 （且配置的swap 为 63g）；使用 sqlplus 登陆 oracle 数据库后，通过show parameter sga 可以看到配置的 sga_target 是40064MB, 相对于该节点实际的内存明显超配了；