目前，第三方支付、p2p網貸、寶寶類理财、衆籌等金融産品層出不窮，随着金融知識的普及，全民參與又進一步促進了網際網路的發展。海量交易資料，實時線上通路，業務快速的疊代變化都對傳統金融解決方案提出了更高的要求，而網際網路金融本身的開放性，低門檻，征信資訊的缺乏，又容易發生各類風險問題，這有給傳統金融解決方案帶來的新的挑戰。借助雲計算、大資料、搜尋引擎等新一代高新技術，給網際網路金融帶來了新的機會。
新興的網際網路金融資料主要有以下幾個特點：
由于參與的人數衆多且活躍度較高，日交易單數通常能夠達到十萬甚至是百萬級别，很容易達到一個傳統關系型資料庫的單表上限。
網際網路金融需要不斷發現新的機會，擴充新的業務模式，對底層的資料模型靈活性有非常高的要求。
促銷活動、新産品發售或者是特殊的節假日都會讓通路并發暴增幾個量級，每天的通路量也會和時間段有着密切的關系。
網際網路産品更加注重使用者體驗，金融風控需要在極短的時間内做出風險判斷。
網際網路金融可以從曆史交易資訊和使用者行為日志中對使用者進行多元分析，進而進一步降低金融風險。
業務需要7*24小時運作，部分硬體故障不能影響業務運作。
金融資料從來都需要最高的安全等級，必須保證機器當機等硬體故障不會造成資料丢失，同時資料不會被竊取、洩露。
阿裡雲表格存儲是一款全托管的nosql資料存儲服務，支援 海量資料 的存儲和 單個毫秒級 的單行平均通路延時， 無縫擴充和彈性資源 都非常适合金融場景，更支援到 表級别和api級别 的授權管理以及 虛拟網絡vpc ，全方位保障資料安全。
下面基于表格存儲現有的金融客戶案例，和大家分享一下表格存儲在網際網路風控和金融資料服務上的應用實踐。
傳統金融的風險控制，主要是基于央行的征信資料及銀行體系内的生态資料依靠人工稽核完成，一方面國内的征信服務并不完善，另外一方面，人工稽核的速度也遠遠适應不了巨大的風控需求。
但是依托與雲計算的大資料存儲與分析，結合使用者的網上消費行為資料、通訊資料、信用卡資料、第三方征信資料等豐富而全面的資料，讓系統來完成風險判斷，大大提高了風控的效率和準确率。
目前大多數風控系統都是使用記憶體資料庫存儲風控資料資訊來保證風控系統的實時性，雖然記憶體資料庫有極低的相應延時，但是出現當機等機器故障，風控資料就會丢失，造成風控系統的不可用，且使用記憶體資料庫也導緻風控系統水準擴充較為困難。表格存儲在讀寫性能上與風控資料庫沒有太明顯差别，能夠滿足風控場景的需要，并且保證了資料的持久化和高可用。
基于表格存儲的風控系統架構如下圖：
風控事件的處理流程如下：
使用者在登入時會根據使用者登入的ip、解鎖行為等進行登入風控判斷，防止使用者被盜号或者裝置丢失造成進一步損失。表格存儲的多版本特性可以隻保留使用者最近若幹次的登入資訊，較早的登入資訊系統會自動删除，無需系統維護登入資訊。
比如風控系統需要最使用者最近10次的登入地點進行驗證，來判斷是否需要使用者提供更多的資訊來登入。設定使用者登入資訊最大版本為10，當使用者第11次登入時，最早的登入資訊會被系統自動删除。風控系統在讀取的時候讀取該使用者的登入資訊，指定讀取的版本為10，則會讀出最近10次的登入資訊，大大減小了系統的複雜度。
當使用者進行交易或其他行為事件時，系統将使用者行為寫入表格存儲中。
定期使用大資料計算服務（max compute）或者streamsql對使用者行為日志結合使用者資訊庫進行分析，得到使用者的信用結果，更新該使用者在風控資料庫中的信用度、可用額度、偏好等征信資料資訊。
當需要進行風控的事件産生時，風控引擎會根據觸發事件從風控模型庫中讀取相應的風控模型集合，對從風控資料庫中讀取該使用者的征信資料依次進行計算，來判斷此次事件是否準入。
以線上支付為例，當使用者在國外某地進行一筆5萬塊的線上交易，從風控模型庫中讀取相應的風控模型集合中需要對使用者的額度和交易地點進行判斷，從風控資料庫中拿到的使用者征信資訊中，使用者的額度為10萬，但是上次交易發生在1個小時前，且地點為國内，那麼額度判斷pass，交易地點判斷fail，那麼此次交易有盜刷或者欺詐嫌疑，系統則判定此次交易失敗。
從上述對風控系統的描述中，我們不難發現，進行線上交易時，風控系統的介入時間需要足夠短以保證終端的使用者體驗，那麼對讀取使用者征信資料的延時有着非常高的要求，風控模型庫越豐富，交易風險也就會越小。
同時，不斷擴充的新業務也會需要新的風控模型，使用者的征信資訊也會不斷發生變化，表格存儲schemafree的稀疏表結構免去繁瑣的表結構變更操作，保證了上層業務的靈活性。
風控不僅僅在網際網路金融上是強需求，在網際網路社交上也起着非常重要的作用。
除了風控系統，海量交易資料的收集、清洗、存儲、實時通路和分析也對傳統的解決方案提出了很大的挑戰。讓我們來看看表格存儲配合衆多雲産品是如何來面對這些挑戰的。
基于表格存儲的金融資料服務系統架構如下圖：
一般的金融系統中，使用者的交易記錄或者行為資料會直接上傳至應用伺服器進行資料校驗或資料清洗，但當終端使用者規模較大時，為了避免交易記錄或行為資料在用戶端堆積，需要大量的應用伺服器來保證資料處理的實時性。這個時候，可以将使用者資料寫入消息隊列中(消息服務mns)，再有應用程式訂閱消息隊列中的資料，當有新的資料到達，觸發應用服務的清晰邏輯。
對于經過資料校驗、清洗之後的資料，一方面需要流入到曆史交易資料庫中，提供給線上業務層進行實時通路，比如曆史交易查詢，簡單的彙總分析，比如某個使用者最近一周的交易記錄，交易金額趨勢等。由于表格存儲目前還不支援索引，可以根據業務查詢需求建立相應的索引表，資料流入時，根據需要寫入多張索引表中。比如根據交易機構的曆史查詢或者基于交易類别的曆史查詢。
另外一方面，資料需要流入大資料計算平台中，對使用者行為進行分析，比如使用機器學習根據使用者的曆史交易金額計算出使用者的信用分和信用額度等征信資訊。
這一層直接對終端使用者提供服務，比如使用者的曆史交易查詢、第三方征信資訊擷取，簡單的行為趨勢分析計算。
這一層的再線業務查詢中，有簡單的使用者交易流水查詢，也有對固定的分析結果的查詢，比如使用者的月度交易情況，也有部分多元度的查詢需求，比如來自某一個交易機構的或者交易區間的交易流水查詢。
在表格存儲上，可以建構多張索引表來提供多元度的查詢資訊。比如使用者曆史流水表的主鍵為[uid，timestamp], 基于機構交易的資料表主鍵就可以為[organization_id，timestamp，uid]，用來滿足對交易機構的交易流水查詢。
在上述的資料處理層中，可以很友善的把交易資料通過流計算(stream compute)進行過濾、提取、彙總，寫到表格存儲的不同的表中。流計算支援對同一批資料進行不同的過濾、提取、彙總以及結果寫入到不同的資料表中。這樣就滿足了海量資料的多元度查詢需求。