風控系統（四）上線後記

在調研了陌陌框架、flink框架之後，我們最終使用了flink進行了風控開發。但是再與業務人員核對資料的過程中，我們發現我們作出的風控功能是與其他團隊有重合的。

我們的需求是由其他同事向業務人員了解後整理完成的。風控模型也是其他同事設計完直接寫好文件給我們看的，我們基於文件直接找到了相對應的業務人員了解了基本的邏輯後，就開始了開發過程。

整個過程當中我們沒有對需求進行乙個很好的評估，也沒有關注業務人員的需求驗收標準，這就導致風控模型上線後當天大量預警、產生誤報。這是因為我們設計的模型中條件過於寬鬆，將很多正常的資料、業務人員不關注的資料都預警了出來。

再之後專案中我們一定要將需求的背景調研好，需求的邊界劃分好，了解業務人員的真實需求，與他們的驗收標準。

這次專案中，我們頭痛主要有兩個地方：溝通，以及開發測試上線環節的不熟悉。

在溝通方面，對其他團隊技術負責人並不熟悉，不了解其他系統具體做什麼，不了解其他系統底層資料是如何來的，導致我們風控模型在取數階段資料就可能不准。

在開發測試上線環節，我們並不清楚開發、測試、上線環節應該找誰，而且flink、kafka、nifi等大資料元件都需要我們自己安裝運維。測試的同事對功能性應用測試流程比較熟悉，但是對我們這類資料類應用的測試流程還是很陌生的。

總結起來，在前期的設計工作我們應該從三個方面進行考慮：

1、資料架構

資料架構應該直接對標業務需求，能從邏輯層面將業務模型轉化為資料模型。保證資料從輸入、轉化、輸出三個方面符合業務邏輯，輸出方面能夠滿足業務人員的驗收標準。

2、應用架構

應用架構指的是我們應該通過什麼方式實現業務架構，通過哪些工具實現輸入、轉化、輸出。比如同樣乙個資料業務需求，使用流處理還是批處理，資料的輸入從哪種儲存介質中獲取，資料的轉化使用什麼工具，輸出使用哪種介質進行儲存。

在這次的開發中，我們的資料輸入主要有mq和mysql兩種，我們通過apache nifi的mq消費元件從源資料進行攝取，使用apache nifi與flink分別作為單流與雙流的轉化過程，使用kafka作為每個轉換過程的儲存介質，使用mysql作為最後的輸出介質。

3、軟體架構

軟體架構主要指應用執行時的網路環境、資料傳輸過程、儲存位置、以及部署方式等。這一部分是我們本次專案做的最不好的地方。

這部分主要涉及到與外部資料的互動過程，是在開發過程最容易被忽視的環節。

接下來的工作還是要繼續完成，一定要理解好需求，劃定好需求邊界。

風控系統（四） 上線後記