2012 年， 正值 P2P 火遍中國的時候， 宜信做為中國首家 P2P 平臺， 已經在這個領域耕耘了 6 年。 2015 年美國時間 12 月 18 日上午 9 點 30 分， 宜信公司旗下線上 P2P 網貸平臺宜人貸正式登陸美國紐交所， 成為國內互聯網金融登陸海外市場的第一股。
宜信創建於 2006 年， 總部位於北京， 是一家從事普惠金融和財富管理事業的金融科技企業， 在支付、網貸、眾籌、機器人投顧、智慧保險、區塊鏈等前沿領域積極佈局， 通過業務孵化和產業投資參與全球金融科技創新， 公司創始人兼 CEO 是唐寧。
以下內容是記者對宜信技術研發中心資料庫架構師韓鋒的採訪。
第一次見到韓鋒的時候， 他的穿著很隨意， 這也是大多數 IT 人員的常態。 1999 年畢業的他， 在 IT 圈裡已經算是一個老兵了。
在職業發展初期， 他一直從事軟體發展工作， 後來逐步對資料庫產生了濃厚的興趣。 在工作後的第七年， 韓鋒做出了一個決定，
從最開始的資料庫基礎運維開始， 到後面的優化、設計、架構。 現在主要精力是從事與資料相關的架構、開發、管理工作。
17 年的 IT 生涯， 他經歷過傳統軟體發展商、通訊類外企、互聯網企業、電商平臺等多種類型公司。 對他而言， 豐富的職業經歷， 使他收益頗多。 不僅僅是技術上， 更多的是綜合能力的提升。
除此之外， 他還常活躍於各種技術社區。 作為一個技術佈道者， 他也非常願意將技術傳播給更多的人。 閒暇之餘， 他還筆耕不輟， 將自己多年的心得彙集成書。
宜信的 IT 轉型之路
韓鋒介紹說， 宜信作為一家金融科技企業， 技術的重要性不言而喻。 目前公司 IT 基礎設施及資料庫等等， 正處於如下階段：
基礎設施的發展，
硬體平臺上， 計算層是以 X86 為主， 存儲層逐步放棄使用商業存儲， 改為分散式的解決方案， 部分場景下也使用了超融合架構。
資料庫方面， 主要以 MySQL、MongoDB、Redis 為主。
大資料方面， 使用了 Hive、HBase、ES、Spark、Storm、Impala、Kafka 等。
針對雲戰略層面， 公司有自己的一些規劃， 目前仍以私有雲為主， 只將部分業務放在了公有雲上， 但僅限於少量的非核心業務。 宜信也在籌畫自己的金融雲戰略。
對於超融合技術， 使用目的是為了提高宜信上線服務的效率。 超融合可以提供很好的彈性， 但其性價比並不高， 且在彈性達到一定的規模後， 會受到限制。 在特定非發展階段， 如果中小型公司想快速擴張業務， 用超融合還是比較合適的。
在資料庫方面，
對於大資料領域， 從早期傳統的資料分析報表， 到 BI 分析、資料採擷、機器學習等等， 宜信正在不斷摸索實踐， 探索在金融領域如何提供更好的服務。 旗下宜人貸的“極速模式”， 正是風控模型在大資料領域的成功實踐。
資料庫遷移的啟示
作為資料庫的一個老兵， 韓鋒經歷了很多很多。 他特意強調， 資料是企業的命脈， 資料庫的重要性如何強調都不過分。
他以一次資料庫遷移為例， 向我們說明了 DBA 工作的不容易及給我們帶來的種種啟示：
詳細的技術方案。 在整個遷移過程中， 最消耗精力的是梳理整個遷移流程：包括制定規範、遷移流程，
實施計畫。 具體到實施計畫要盡可能的詳細、完善。 例如， 有很多應用會連接到資料庫， 但有些 IP 位址並不在登記資訊範圍內。
因此， 在遷移準備期就需要注意排查。 這一工作是非常消耗精力的， 也表明先前工作存在不完善的地方。
部門合作。 與相關部門核對遷移方案、做好溝通、協調工作。
做好預案。 在遷移前， 團隊做了很多的預案， 包括正常遷移流程， 以及出現問題後備用的遷移流程， 以及備用的回退方案。
在正式遷移前， 團隊大概一周演練一次， 前前後後演練了四五遍， 每次都是半夜去演練。
演練完之後立即做好記錄， 包括它的操作步驟， 一步一步地去細化， 最終形成了一本厚厚的遷移文檔。 最後，真正遷移的時基本上不用敲命令，只需把腳本粘過來就可以了。
資料管理方法論
韓鋒再次強調，在過去，專利、技術或者運營模式是企業的命脈，而未來資料也是企業的命脈之一，如果企業沒有掌握資料只能被動發展，所以資料管理就顯得尤為重要了。
對公司而言，資料不僅僅只保存在資料庫中，它可以存在不同的地方，以各種形態存在。它可能是一個檔，可能是多使用者上傳的資料片、圖片，還可能是使用者的一些語音。這些資料不僅它的位置是分散的，形態是不一的，價值也是不一樣的。
面對紛繁複雜的資料，如何進行資料管理呢？
首先，企業管理者要對資料高度重視。
其次要做的是對資料進行摸底，瞭解它們在哪裡，存在的形式，以及價值。
最後才能涉及到資料管理問題。
常見的管理方法主要分為三類：
自上而下。傳統的企業，銀行、證券、金融類往往會這麼做。即成立一個類似於建模室或者資料模型部門這樣的組織，然後會有專業的人説明他們做模型設計，做規範。
這樣的辦法對資料的控制力度會很大，但是，會有些不靈活，而且人力投入過高。
自下而上。像很多互聯網公司，通常會有自己的一套系統，針對業務模式自下而上進行管理。
從中間出發。也有些公司，從開發入手，引進一些建模工具，通過它往上推出業務模式，往下構建物理模型。
以上這些方法放到宜信中都會有問題。宜信不像傳統企業，它的發展速度比較快，所以會有大量的業務需要變動，用自上而下就行不通。
而自下而上大都用於單一業務系統，這些是基於資料倉庫的，而宜信的資料倉庫沒有統一，很多開發宜信是不建模的，所以從中間做資料建模也很難。
目前，他正摸索一種適合宜信發展的資料管理方式，從大方向考慮，會選擇從下而上的方法去做。出發點把公司內部資料中共用的、非獨有的拿過來，然後再去收集各自領域的資料，最終逐步形成統一的資料視圖。
DevOps 在宜信資料庫的應用
韓鋒將 DevOps 在宜信的應用階段，簡化為“四化工程”。所謂“四化工程”，是指如下四個層次。很多企業的 DevOps 實施中，也都大致經歷了類似的四個階段。
第一階段
“文檔/標準化”階段：這一階段，往往是企業經過了初期的“人肉”模式後，隨著規模的擴大，運維遇到很多問題。
因此，原有的手工操作被逐步規範下來，形成操作標準，並通過文檔化的步驟，將標準沉澱下來。後續操作，人員只需要遵循文檔即可。通過這種方式保證了運維的品質，提升了回應效率。
第二階段
“腳本/工具化”階段：儘管在第一階段，實現了指定標準文檔化，但運維工作仍然需要大量人工成本。當運維量進一步增大後，如何減少手工操作，加快運維效率就成為重點。
因此，在這個階段，將文檔化的標準操作，通過腳本或者工具的形式固化下來，可以大幅提升運維效率。
第三階段
“自動/平臺化”階段：雖然通過工具腳本是可以完成運維工作，但仍然需要人工觸發。為完成某一具體運維場景，往往需要人工執行一系列的腳本或工具調用，這也耗費了大量人工成本。
為了進一步提升效率，考慮引入平臺自動化。通過梳理運維工作，將一系列工具、腳本整合到統一的平臺中，即可完成整個運維操作，甚至可與監控等系統聯動，實現自動化運維動作。
第四階段
“智慧/雲化”階段：這一階段更多是從運維智慧性及資源提供的形態角度出發。在自動運維的基礎上，通過引入智慧分析能力，可預測故障發生，主動採取運維動作。可評估整體資源使用，更合理地分配使用資源等等。
至於雲化，由於是將基礎設施抽象出來，在運維層面能提供更大的靈活度，可更好的滿足業務快速發展及最大化成本收益。
大資料已經不是新興技術了
他說，大資料已經不是新興技術了，所謂的大資料是什麼？
韓鋒認為，大資料是指在某一個階段所面臨的資料無法處理，把一種新的處理方式取名叫大資料技術，但是，對我們來說它只不過是一個資料處理技術。而大和不大，會隨時間而不斷變化，今天的大可能明天就不大了。
此外，很多的資料庫越來越偏重於大資料，大資料也在向資料庫學習。傳統資料庫裡面有一些大資料的技術，大資料也會被鑲嵌到資料庫裡面。
傳統資料庫積累了三、四十年，對資料的精確掌控程度遠遠超過大資料平臺，從單位生產效率來說，大資料平臺要低於傳統資料平臺。
所以現在大資料平臺要學什麼？要學優化系統怎麼做，學更精准地找到資料，發現資料。
最後，他認為，資料庫只是一個資料的存在形態，資料可存放在庫裡，也可以是大資料平臺，也有可能是其他形態。
新的硬體技術、大資料、人工智慧、雲計算會為資料庫的發展提供一種可能性。但是未來，它究竟發展成什麼樣，現在就很難下定論了。
另外還有一點可以通過自身的學習來獲取一大進步。
分享給超過5萬的程式師朋友下載，這次我把所有資料重新梳理精簡，免費分享給大家 。
究竟有哪些乾貨呢？先給你們一個目錄：
免費領取資料途徑：公眾平臺 “程式師語錄"
最後，真正遷移的時基本上不用敲命令，只需把腳本粘過來就可以了。資料管理方法論
韓鋒再次強調，在過去，專利、技術或者運營模式是企業的命脈，而未來資料也是企業的命脈之一，如果企業沒有掌握資料只能被動發展，所以資料管理就顯得尤為重要了。
對公司而言，資料不僅僅只保存在資料庫中，它可以存在不同的地方，以各種形態存在。它可能是一個檔，可能是多使用者上傳的資料片、圖片，還可能是使用者的一些語音。這些資料不僅它的位置是分散的，形態是不一的，價值也是不一樣的。
面對紛繁複雜的資料，如何進行資料管理呢？
首先，企業管理者要對資料高度重視。
其次要做的是對資料進行摸底，瞭解它們在哪裡，存在的形式，以及價值。
最後才能涉及到資料管理問題。
常見的管理方法主要分為三類：
自上而下。傳統的企業，銀行、證券、金融類往往會這麼做。即成立一個類似於建模室或者資料模型部門這樣的組織，然後會有專業的人説明他們做模型設計，做規範。
這樣的辦法對資料的控制力度會很大，但是，會有些不靈活，而且人力投入過高。
自下而上。像很多互聯網公司，通常會有自己的一套系統，針對業務模式自下而上進行管理。
從中間出發。也有些公司，從開發入手，引進一些建模工具，通過它往上推出業務模式，往下構建物理模型。
以上這些方法放到宜信中都會有問題。宜信不像傳統企業，它的發展速度比較快，所以會有大量的業務需要變動，用自上而下就行不通。
而自下而上大都用於單一業務系統，這些是基於資料倉庫的，而宜信的資料倉庫沒有統一，很多開發宜信是不建模的，所以從中間做資料建模也很難。
目前，他正摸索一種適合宜信發展的資料管理方式，從大方向考慮，會選擇從下而上的方法去做。出發點把公司內部資料中共用的、非獨有的拿過來，然後再去收集各自領域的資料，最終逐步形成統一的資料視圖。
DevOps 在宜信資料庫的應用
韓鋒將 DevOps 在宜信的應用階段，簡化為“四化工程”。所謂“四化工程”，是指如下四個層次。很多企業的 DevOps 實施中，也都大致經歷了類似的四個階段。
第一階段
“文檔/標準化”階段：這一階段，往往是企業經過了初期的“人肉”模式後，隨著規模的擴大，運維遇到很多問題。
因此，原有的手工操作被逐步規範下來，形成操作標準，並通過文檔化的步驟，將標準沉澱下來。後續操作，人員只需要遵循文檔即可。通過這種方式保證了運維的品質，提升了回應效率。
第二階段
“腳本/工具化”階段：儘管在第一階段，實現了指定標準文檔化，但運維工作仍然需要大量人工成本。當運維量進一步增大後，如何減少手工操作，加快運維效率就成為重點。
因此，在這個階段，將文檔化的標準操作，通過腳本或者工具的形式固化下來，可以大幅提升運維效率。
第三階段
“自動/平臺化”階段：雖然通過工具腳本是可以完成運維工作，但仍然需要人工觸發。為完成某一具體運維場景，往往需要人工執行一系列的腳本或工具調用，這也耗費了大量人工成本。
為了進一步提升效率，考慮引入平臺自動化。通過梳理運維工作，將一系列工具、腳本整合到統一的平臺中，即可完成整個運維操作，甚至可與監控等系統聯動，實現自動化運維動作。
第四階段
“智慧/雲化”階段：這一階段更多是從運維智慧性及資源提供的形態角度出發。在自動運維的基礎上，通過引入智慧分析能力，可預測故障發生，主動採取運維動作。可評估整體資源使用，更合理地分配使用資源等等。
至於雲化，由於是將基礎設施抽象出來，在運維層面能提供更大的靈活度，可更好的滿足業務快速發展及最大化成本收益。
大資料已經不是新興技術了
他說，大資料已經不是新興技術了，所謂的大資料是什麼？
韓鋒認為，大資料是指在某一個階段所面臨的資料無法處理，把一種新的處理方式取名叫大資料技術，但是，對我們來說它只不過是一個資料處理技術。而大和不大，會隨時間而不斷變化，今天的大可能明天就不大了。
此外，很多的資料庫越來越偏重於大資料，大資料也在向資料庫學習。傳統資料庫裡面有一些大資料的技術，大資料也會被鑲嵌到資料庫裡面。
傳統資料庫積累了三、四十年，對資料的精確掌控程度遠遠超過大資料平臺，從單位生產效率來說，大資料平臺要低於傳統資料平臺。
所以現在大資料平臺要學什麼？要學優化系統怎麼做，學更精准地找到資料，發現資料。
最後，他認為，資料庫只是一個資料的存在形態，資料可存放在庫裡，也可以是大資料平臺，也有可能是其他形態。
新的硬體技術、大資料、人工智慧、雲計算會為資料庫的發展提供一種可能性。但是未來，它究竟發展成什麼樣，現在就很難下定論了。
另外還有一點可以通過自身的學習來獲取一大進步。
分享給超過5萬的程式師朋友下載，這次我把所有資料重新梳理精簡，免費分享給大家 。
究竟有哪些乾貨呢？先給你們一個目錄：
免費領取資料途徑：公眾平臺 “程式師語錄"