知識圖譜建模

咱們的目標在業務上是反欺詐，現有的特徵不能使用，由於已經有建模的團隊了。 爲了提高反欺詐的效果，咱們只能從數據角度出發，挖掘出更多更好的變量，不用現有的任何特徵，目標倒是比現有的模型效果更好。

瞭解了情況以後，因而開始作關係網絡，由於這塊是公司空缺的領域，並且整個行業來看的話，作的好的公司也沒有幾家。

說幹就幹，工做從研究數據類型，關係， 數據清洗開始。 遇到的第一個問題是 sql, 沒法構形成圖結構。 因而本身動手 寫代碼用 java 讀寫 hdfs 數據，在內存裏面構圖，計算特徵。儘管搞到一臺256G內存的機器，依然遇到 內存不夠用的狀況。 查的緣由是 須要加載到內存的邊太多，幾億條。 接下來，優化數據結構的內存開銷，能用short 就不用integer, 能用long 就不用 string. 甚至本身作數據作分片。 計算特徵的時候，僅僅加載該分片須要的全部數據到內存裏面來。 終於第一個里程碑作到了， 特徵有了， 標籤有了。 從開始工做到第一個模型的創建，中間花了1.5個月。還好模型效果顯著，獲得了老大們的支持。

既然模型效果好，僅僅用了 xgboost 就效果顯著了。那麼就努力上線啊。這個時候才知道上線纔是最大的困難。由於這個模型上線須要優先作到實時關係網絡的構建。

關係網絡數據存哪裏？試過 Neo4j , OriginDB, Titan 等圖數據庫。 花了3個多星期用來寫各類demo, 測試邏輯準確性，測試性能等等。 獲得的結論是沒有一個開源的圖數據可以知足需求。

捉急啊，有價值的模型竟然由於技術實現問題難以上線。總不能放棄吧。 最終決定只把邊這一種數據保存到 HBASE 表裏面。 讓HBASE 幫我解決存儲問題。 採用Flink 實時流框架，寫了一堆代碼暴力的往 HBASE裏面寫入 增量的邊。 歷時2個多月，完成 FLINK + kafka 作到實時關係網絡的構建， 延時不到1秒。 併發的進程數量高達30多個。

後續還須要作 圖的完整性測試，時效性測試，測試ok 後。 還須要本身寫基於關係網絡的特徵工程，模型預測，預測結果還須要上線觀察一個月。 真正意義上的上線都已經10月份了。從2月底開始嘗試去作，到作成上線一共經歷了7個月。

整個過程下來，建模的工做不超過2周。流計算，實時關係網絡構建，特徵工程，特徵準確性測試等技術工程實現上花的時間佔用99%。一條龍所有本身作。而業務使用上，只是到 hbase 的一張表裏面根據 rowkey 拿模型預測分就行了。卻沒法感知上線路程之艱難。

模型的實際效果好，爲之辛苦值得。