大數(shù)據(jù)BI系統(tǒng)實(shí)操總結(jié):如何做數(shù)據(jù)采集?

2 評(píng)論 9843 瀏覽 66 收藏 8 分鐘

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

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

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

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

在業(yè)務(wù)流程梳理的過(guò)程中,我們先預(yù)設(shè)個(gè)場(chǎng)景,如:

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

因此從上面的例子中我們可以從以下幾點(diǎn)思考業(yè)務(wù)流程:

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

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

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

二、原型注意點(diǎn)

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

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

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

2. 表管理

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

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

3. 映射配置

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

4. 任務(wù)管理

主要是建立源與表,源與源的關(guān)系;同時(shí)可以對(duì)任務(wù)的執(zhí)行周期來(lái)進(jìn)行設(shè)置;任務(wù)配置的過(guò)程中,可以是以目標(biāo)源為維度,亦可以以目標(biāo)表為維度建立任務(wù),同時(shí)可對(duì)歷史任務(wù)進(jìn)行監(jiān)測(cè)。

三、項(xiàng)目上線后復(fù)盤總結(jié)

1. 需求方面

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

2. 交互方面

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

3. 項(xiàng)目執(zhí)行

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

4. 個(gè)人方面

對(duì)數(shù)據(jù)倉(cāng)庫(kù)的了解和認(rèn)識(shí)上有所提升,對(duì)SQL的學(xué)習(xí)也算是一次鞏固,同時(shí)在做的過(guò)程中對(duì)自己以前遇到過(guò)的數(shù)據(jù)需求也有了一些新的思考思路和總結(jié)復(fù)盤。總之是收獲滿滿。

#專欄作家#

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

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

題圖來(lái)自 Pexels,基于 CC0 協(xié)議

專欄作家

木北的產(chǎn)品成長(zhǎng)路,微信公眾號(hào):木北的產(chǎn)品成長(zhǎng)路,人人都是產(chǎn)品經(jīng)理專欄作家,互聯(lián)網(wǎng)產(chǎn)品經(jīng)理,曾擔(dān)任醫(yī)藥產(chǎn)品經(jīng)理和電商產(chǎn)品經(jīng)理,經(jīng)歷主導(dǎo)過(guò)電商平臺(tái)的系統(tǒng)整合規(guī)劃。

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

題圖來(lái)自 Unsplash,基于 CC0 協(xié)議

該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 精彩

    回復(fù)
  2. 感覺沒有說(shuō)到數(shù)據(jù)采集啊

    來(lái)自上海 回復(fù)