落地，在總部待了兩周後，有些感悟，趁熱記下。

一、科技

這裡所謂的科技，包括了支撐整個業務設計、運營、維護的

研發、開發、項目管理、運維、安全及數據中心等職能部門所做的事。

不同規模、類別的公司，在科技上的投入不一和理解不同，造成了科技部門和責任的多樣化，但基本的框架是差不多的。

研發部門，負責搗鼓在未來時間有很大價值的、或者說對公司業務會產生長期收益促進的產品。

開發部門，負責搗鼓在當下時間內，對公司的業務支撐、拓展必不可缺的產品進行設計、實現、維護和升級。

項目管理部門，負責搗鼓項目的權責、規劃、進度、交付和資源，確保項目在一定的條件下、通過一定的努力，得到一定的交付。

運維部門，負責搗鼓對硬體和網路等物理資源的部署、上線、實施和維護，及對上線產品的監控、管理、預警、彙報等事項負責。

安全部門，負責通過安全產品的實施、安全機制、監控和預警機制等手段的利用，確保公司的核心資源、數據不被竊取、篡改和攻擊。

數據中心，對，數據中心乾什麼呢？

二、數據

坦率的說，業務、運維、安全等系統，各有各的數據存儲方案，從支撐業務正常運行的角度，數據中心的確顯得多餘。

可是，如果各個系統生產的數據越來越大、結構越來越複雜、對付此類數據所採取的策略越來越分化和分級，至少會出現兩種狀況：

• 受限於數據的治理能力，業務系統可能無法發揮應有的價值或無法繼續正常運作；
• 隨著業務系統的多樣化演變，難以建立一個統一的數據視圖。

對於複雜結構、大體量數據的管理，狹義地說，落在了所謂的“大數據”技術領域。

於是，我們有了各種大數據解決方案，比如：

• 建立持久型資料庫、分散式緩存、實例級緩存的分級存儲策略，並輔以同步和更新機制.
• 我們採用單線程、非同步和隊列的的方式，取代多線程和同步執行的方式，獲得更高、更穩定的TPS.
• 我們採用分散式存儲方式、建立分散式文件系統來管理數以PB計的數據.
• 我們採用MapReduce和RDD來完成單機被cpu和記憶體限制的計算任務.
• 我們用Kafka類的系統來埋點，並以準實時的方式收集和清洗數據，然後丟給storm或samza來進行準實時的處理.
• 我們同樣沒有忘記SQL，所以通過Hive或者Phoenix，我們用SQL-like腳本，來互動式地做CRUD.
• 為了查詢數據，我們選擇索引和存儲分離，並用更專業的分散式搜索引擎來處理全文索引和二級索引.

以上，不是最佳方案，但應付80%的大數據場景，足矣。

為了在企業內，建立一個統一的數據視圖，我們應該會採用商業智能和數據倉庫的方案，那又是什麼東西？

三、業務

業務跟商業智能和數據倉庫有關係嗎？
當然，有很大的關係，所以我們說說業務。

業務是簡單的，假設你跟我一樣，是一個普通的開發人員，當你在看到這裡的時候，聯想到你的系統所支撐的業務，你會不會覺得簡單的難以置信，甚至一兩句即可描述完流程？

業務是複雜的，複雜到需要成百上千、資歷各一、專業不同的開發人員，通過複雜的軟體工程和管理手段，才能做到目前這樣的程度，而且你翻開代碼倉庫的一段，你還覺得他缺乏OO、領域、模式和設計的理解，註釋也許寫成這樣“以下函數輸入兩個整形，進行相加，並輸出一個整形”。

有一天，你覺得ETL的事情做膩了，而前端的報表在H5和css3之後，越來越漂亮；
你覺得spring MVC太重了，finatra既不需要tomcat的支持，scala的代碼也更加簡潔易懂；
Mapper和Reducer讓你噁心，RDD縱然輕快，可你也只是輸出了一個報表片段而已。

對了，你想到了數據挖掘和機器學習。

於是也可能憋出這樣的產品思路：

看起來還不錯，但是，這是你的業務嗎？有人願意付出預算和支持，來讓你檢驗自己的想法和對於深度學習的熱情嗎？

請一定不要跳出業務的歷史、現狀去做思考未來，對於絕大多數人來講，你我都很難成為喬布斯。

四、關係

明確業務場景，明確業務系統和數據產品的不同，對於產品的設計，尤為重要。

我們假設一個網貸p2p的業務模型，它的基本業務流程可能是這樣的：

一個類資產證券化的過程，是從“資產端”到“資金端”的匹配，我們嘗試梳理這樣一個業務的痛點：

1. 資產端的團隊在獲取項目後，資產或者說項目的打包情況是怎樣的？經辦人是誰？這樣的團隊業績如何考量？

2. 對一個一億規模的項目，如何進行拆標和上標，才能獲得最佳的資產-資金匹配效果？對於上標環節，能否解放運營團隊的人力資源，做到自動上標？

3. 對於資產端的風險，如何結合線下風控監管和線上風控模型，做到反欺詐、還款能力鑒定和還款意願鑒定？

4. 對於違約、逾期的項目，何時、由何種資源去進行對應的資產保全和催收？是不是在T+0時刻，可以通過回歸，預測出T+N時刻的違約概率？

5. 是否有一種手段，既可以總覽全國的交易額，又可以便捷地審查各區域、各省市的明細？比如，我知道某地、某天應該有多少還款到賬，又知道有多少投資人的利息需要進行兌付？

6. 業務系統的信息流怎麼和第三方支付進行對賬？

7. 如果出現剛性兌付壓力或者滿標壓力，我如何確知那一天我的支持款是夠用的？如果是一個母公司下的子公司，如何瞭解那一天其對我的支持款餘額是真正可用的？

8. 我如何知道我的業務做得好還是不好？

類似的問題，是科技還是數據提出的？

都不是，是業務。科技系統產生了數據，數據忠實地反應著業務的情形。

建立一個統一的數據視圖，建立一個真正的數據倉庫和商業智能系統，是為了從不同的層次和視角、從管理層和運營層的不同需求出發、對業務本身，做出精確刻畫、精準統計和科學預測的基礎。

五、再看數據

商業智能及數據倉庫系統，很重要的一項能力就是要輸出各種報表，而報表的表頭欄位，直接反應著觀察者的基本焦點和需求。

所以，我們要對關鍵的數據做到精準的監控，並對監控項的邏輯關係和層次做到正確的理解和梳理：

如果能夠做到系統化的KPI監控和預警，那麼經營分析就接踵而至了。

比如，我們可以對現金流做出刻畫，可以按項目為單位，來研究WACC和IRR的關係，從而基本回答“我做這個項目是虧錢還是掙錢”的問題：

如果還想做一點常規統計分析之外的“高大上”的東西，比如“數據挖掘和預測分析”，那麼也許可以這樣：

六、後話

如果忘記業務，就會忘記方向。

不要抗拒業務，學習她，擁抱她，科技和數據才會更加生動和有趣。

註：對同我一起戰鬥兩個星期的Andy Wu表示感謝：]，文中引用了你的一些東西。