本文圍繞數(shù)據(jù)采集為討論主題，從三個方面——業(yè)務流程梳理、原型注意點、項目上線后復盤總結(jié)進行了分享。

隨著數(shù)據(jù)量的不斷增速，數(shù)據(jù)價值也逐漸被很多公司所關(guān)注，尤其是偏重于業(yè)務型的企業(yè)，大量數(shù)據(jù)的產(chǎn)生，在未被挖掘整合的過程中通常被看作是一堆無效且占用資源的；但一旦被發(fā)掘，數(shù)據(jù)的價值將無可估量。尤其像電商，銀行，服務行業(yè)等等。近段時間有幸參與負責了一個大數(shù)據(jù)項目，今天主要對采集系統(tǒng)做一次簡單的復盤：

數(shù)據(jù)采集系統(tǒng)故名思意就是將數(shù)據(jù)從數(shù)據(jù)源采集到能夠支撐大數(shù)據(jù)架構(gòu)環(huán)境中，從而實現(xiàn)數(shù)據(jù)的采集以便后期對數(shù)據(jù)的二次加工建立數(shù)據(jù)倉庫。

一、業(yè)務流程梳理

在業(yè)務流程梳理的過程中，我們先預設個場景，如：

當公司運營人員提出一個訂單轉(zhuǎn)化率的需求，作為產(chǎn)品人員，首先要確定分析訂單轉(zhuǎn)化率與哪些因素有關(guān)，最終確定從用戶下單，支付這兩個環(huán)節(jié)中分析，如當月有多少用戶提交了訂單，之后有多少用戶確認了訂單，有多少用戶最終支付訂單等；最終呈現(xiàn)了漏斗形的分析主題；因此分析時就需要確定所需要的這些數(shù)據(jù)要從哪些表獲取，都需要獲取哪些數(shù)據(jù)，獲取到后要采集存儲到哪個數(shù)據(jù)倉庫的表中，最終被使用到。

因此從上面的例子中我們可以從以下幾點思考業(yè)務流程：

1. 確定主題，確定主題模型；
2. 確定表和數(shù)據(jù)口徑；
3. 確定需要與目標的映射關(guān)系；
4. 確定表與口徑需要從哪些源下獲取，以及如何數(shù)據(jù)更新的頻率等；

從以上幾點我們可以看出，第一點主題模型我們今天不做過多的介紹，著重從2~4點分析可以將采集系統(tǒng)劃分為數(shù)據(jù)源配置、表結(jié)構(gòu)的管理、源表管理、映射配置和采集任務管理幾大模塊。

• 數(shù)據(jù)源管理包括新增，編輯，刪除等；
• 表結(jié)構(gòu)管理包括表結(jié)構(gòu)的批量導入，查看等；因為采集過程中表是要參與映射的，結(jié)構(gòu)一旦導入是不允許修改的，以免影響后面的采集配置文件的輸出。
• 映射配置主要是配置表與表，字段與字段的映射關(guān)系，過濾條件與增量的設置。作為采集的配置模板使用；為什么不是在之前就與數(shù)據(jù)源關(guān)聯(lián)的目的是因為解耦表與數(shù)據(jù)源的關(guān)系，方便于后期的擴展和用戶易用性。
• 采集任務管理主要是建立源與源之間采集過程以及任務的執(zhí)行情況。

二、原型注意點

1. 數(shù)據(jù)源管理

數(shù)據(jù)源一般會分為很多種類型，因此，我們需要建立數(shù)據(jù)源類型；如ORECAL、mysql、hive等。

添加數(shù)據(jù)源時，對于所填寫內(nèi)容的校驗一般會根據(jù)需要來決定，需要填寫的字段大致包括源名稱，服務器，端口，用戶名，密碼等。

2. 表管理

表結(jié)構(gòu)的獲取一般會有兩種方式，一種是通過連接數(shù)據(jù)庫獲取，一種是本地保存，直接從本地獲取。具體使用哪種方式根據(jù)實際情況來決定。如果是用的第二種，則需要將表結(jié)構(gòu)整理預先導入系統(tǒng)，以便后期使用。

hive的表結(jié)構(gòu)有一些特殊，比一般數(shù)據(jù)庫的表結(jié)構(gòu)多幾列，如：分列名稱，分區(qū)值等。

3. 映射配置

映射配置主要是確定源表和目標表，同時建立字段映射關(guān)系；亦可設置過濾條件，數(shù)據(jù)采集的周期配置設置等。

4. 任務管理

主要是建立源與表，源與源的關(guān)系；同時可以對任務的執(zhí)行周期來進行設置；任務配置的過程中，可以是以目標源為維度，亦可以以目標表為維度建立任務，同時可對歷史任務進行監(jiān)測。

三、項目上線后復盤總結(jié)

1. 需求方面

采集系統(tǒng)在理解前期，產(chǎn)品和研發(fā)考慮的點有所不同，導致原型、規(guī)則在評審后的開發(fā)初期有一些小的改動，不過整體需求上還算可以接受。

2. 交互方面

由于是B端的后臺系統(tǒng)，一般會選用一套共用的的系統(tǒng)框架，因此在出具需求的過程中，只著重說明了需要注意的交互方式，一些共用的交互方式并未做過多的說明；因此在交互這多了很多的溝通成本。

3. 項目執(zhí)行

整體進度還好，不過由于一些組件的提前打包定義，導致在開發(fā)過程中有些不能滿足需求，耽擱了一些進度。

4. 個人方面

對數(shù)據(jù)倉庫的了解和認識上有所提升，對SQL的學習也算是一次鞏固，同時在做的過程中對自己以前遇到過的數(shù)據(jù)需求也有了一些新的思考思路和總結(jié)復盤。總之是收獲滿滿。

#專欄作家#

簡之箐（微信公眾號：簡之箐），人人都是產(chǎn)品經(jīng)理專欄作家，5年互聯(lián)網(wǎng)產(chǎn)品經(jīng)理，曾擔任醫(yī)藥產(chǎn)品經(jīng)理和電商產(chǎn)品經(jīng)理，經(jīng)歷主導過電商平臺的系統(tǒng)整合規(guī)劃。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議