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

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

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

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

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

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

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

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

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

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

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

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

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

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

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