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