因近期準備進行歷史庫割接，但歷史庫中數(shù)據(jù)陳舊且種類繁多，需要梳理連接歷史庫有哪些主機，哪些進程，訪問了哪些用戶對象，方便做后期遷移方案和業(yè)務(wù)切換規(guī)劃。因此我們通過DOMP平臺對歷史庫的會話信息進行定期采集。采集的基礎(chǔ)信息入庫到GP中,奇怪的事情從這里就開始了。

一般現(xiàn)場正常的數(shù)據(jù)采集流程如下：

構(gòu)思數(shù)據(jù)采集需求→編寫采集腳本→創(chuàng)建GP入庫表→變更入庫腳本→重啟數(shù)據(jù)入庫程序。這種流程基本是已固化的，然而本次配置完成后，出現(xiàn)了醒目的ERROR！

以上報錯比較明顯，應(yīng)該是編碼錯誤導(dǎo)致,于是查了GreenPlum數(shù)據(jù)庫默認編碼格式：UTF8,再查了查主機的編碼,都是UTF8，暫時沒有發(fā)現(xiàn)什么異常。

進一步排查錯誤到底是出在哪里,難道是文件的編碼導(dǎo)致的？馬上驗證了一下，結(jié)果如下：

可以通過結(jié)果看出來該文件的MIME-type是application/octet-stream；charset=binary，我想問題應(yīng)該找到了。所有文件都是保持一致的，為什么單單就這個文件出現(xiàn)這個情況呢？

采集的數(shù)據(jù)首先會進入到kafka中，檢查kafka里對應(yīng)topic生產(chǎn)數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)后面多了’u00000’。

GreeenPlum官網(wǎng)解釋為字符中包含了u00000,但是實際查詢確實沒看到有這種特殊字符出現(xiàn)。

這時我們想到是否是平臺的問題，趕緊聯(lián)系了開發(fā)的同事，開發(fā)仔細檢查了相關(guān)的代碼，確定并沒有改變文件編碼的地方，開發(fā)的同事建議發(fā)現(xiàn)kafka消費生成的csv文件中存在特殊字符^0^。

生成的csv文件部分內(nèi)容：

重新又在oracle庫上查詢了一下數(shù)據(jù)，并未發(fā)現(xiàn)有特殊字符

繼續(xù)排查這個特殊字符的來源，我們嘗試用引號拼接的方式，查出machine值中確實有空格的情況存在，且這種空格的machine值也正好對應(yīng)上kafka消費生成的csv文件那幾行有問題的數(shù)據(jù)。終于看到了希望的曙光。

繼續(xù)通過字段的截取和ascii碼轉(zhuǎn)換發(fā)現(xiàn)該值就是0，真是個大坑。

最后通過修改采集腳本，將肉眼看不到的空格替換為空解決了問題。采集任務(wù)拉起來后，數(shù)據(jù)已正常進入GP庫中。

oracle采集的數(shù)據(jù)有空字符串，而空字符(ascii碼0，在程序里一般寫作"