本文圍繞數據採集為討論主題，從三個方面——業務流程梳理、原型注意點、項目上線後復盤總結進行了分享。
隨著數據量的不斷增速，數據價值也逐漸被很多公司所關注，尤其是偏重於業務型的企業，大量數據的產生，在未被挖掘整合的過程中通常被看作是一堆無效且佔用資源的；但一旦被發掘，數據的價值將無可估量。尤其像電商，銀行，服務行業等等。近段時間有幸參與負責了一個大數據項目，今天主要對採集系統做一次簡單的復盤：
數據採集系統故名思意就是將數據從數據源採集到能夠支撐大數據架構環境中，從而實現數據的採集以便後期對數據的二次加工建立數據倉庫。
一、業務流程梳理
在業務流程梳理的過程中，我們先預設個場景，如：
當公司運營人員提出一個訂單轉化率的需求，作為產品人員，首先要確定分析訂單轉化率與哪些因素有關，最終確定從用戶下單，支付這兩個環節中分析，如當月有多少用戶提交了訂單，之後有多少用戶確認了訂單，有多少用戶最終支付訂單等；最終呈現了漏鬥形的分析主題；因此分析時就需要確定所需要的這些數據要從哪些表獲取，都需要獲取哪些數據，獲取到後要採集存儲到哪個數據倉庫的表中，最終被使用到。
因此從上面的例子中我們可以從以下幾點思考業務流程：
確定主題，確定主題模型；確定表和數據口徑；確定需要與目標的映射關係；確定表與口徑需要從哪些源下獲取，以及如何數據更新的頻率等；從以上幾點我們可以看出，第一點主題模型我們今天不做過多的介紹，著重從2~4點分析可以將採集系統劃分為數據源配置、表結構的管理、源表管理、映射配置和採集任務管理幾大模塊。
數據源管理包括新增，編輯，刪除等；表結構管理包括表結構的批量導入，查看等；因為採集過程中表是要參與映射的，結構一旦導入是不允許修改的，以免影響後面的採集配置文件的輸出。映射配置主要是配置表與表，欄位與欄位的映射關係，過濾條件與增量的設置。作為採集的配置模板使用；為什麼不是在之前就與數據源關聯的目的是因為解耦表與數據源的關係，方便於後期的擴展和用戶易用性。採集任務管理主要是建立源與源之間採集過程以及任務的執行情況。
二、原型注意點
1. 數據源管理
數據源一般會分為很多種類型，因此，我們需要建立數據源類型；如ORECAL、mysql、hive等。
添加數據源時，對於所填寫內容的校驗一般會根據需要來決定，需要填寫的欄位大致包括源名稱，伺服器，埠，用戶名，密碼等。
2. 表管理
表結構的獲取一般會有兩種方式，一種是通過連接資料庫獲取，一種是本地保存，直接從本地獲取。具體使用哪種方式根據實際情況來決定。如果是用的第二種，則需要將表結構整理預先導入系統，以便後期使用。
hive的表結構有一些特殊，比一般資料庫的表結構多幾列，如：分列名稱，分區值等。
3. 映射配置
映射配置主要是確定源表和目標表，同時建立欄位映射關係；亦可設置過濾條件，數據採集的周期配置設置等。
4. 任務管理
主要是建立源與表，源與源的關係；同時可以對任務的執行周期來進行設置；任務配置的過程中，可以是以目標源為維度，亦可以以目標表為維度建立任務，同時可對歷史任務進行監測。
三、項目上線後復盤總結
1. 需求方面
採集系統在理解前期，產品和研發考慮的點有所不同，導致原型、規則在評審後的開發初期有一些小的改動，不過整體需求上還算可以接受。
2. 交互方面
由於是B端的後臺系統，一般會選用一套共用的的系統框架，因此在出具需求的過程中，只著重說明了需要注意的交互方式，一些共用的交互方式並未做過多的說明；因此在交互這多了很多的溝通成本。
3. 項目執行
整體進度還好，不過由於一些組件的提前打包定義，導致在開發過程中有些不能滿足需求，耽擱了一些進度。
4. 個人方面
對數據倉庫的了解和認識上有所提升，對SQL的學習也算是一次鞏固，同時在做的過程中對自己以前遇到過的數據需求也有了一些新的思考思路和總結復盤。總之是收穫滿滿。
#專欄作家#
本文原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議