精品国产亚洲一区二区三区|亚洲国产精彩中文乱码AV|久久久久亚洲AV综合波多野结衣|漂亮少妇各种调教玩弄在线

<blockquote id="ixlwe"><option id="ixlwe"></option></blockquote>
  • <span id="ixlwe"></span>

  • <abbr id="ixlwe"></abbr>

    【漫談數(shù)據(jù)倉庫】 如何優(yōu)雅地設(shè)計數(shù)據(jù)分層

    大數(shù)據(jù)

    一、文章主題

    本文主要講解數(shù)據(jù)倉庫的一個重要環(huán)節(jié):如何設(shè)計數(shù)據(jù)分層!其它關(guān)于數(shù)據(jù)倉庫的內(nèi)容可參考之前的文章。

    本文對數(shù)據(jù)分層的討論適合下面一些場景,超過該范圍場景?or?數(shù)據(jù)倉庫經(jīng)驗豐富的大神就不必浪費時間看了。

    數(shù)據(jù)建設(shè)剛起步,大部分的數(shù)據(jù)經(jīng)過粗暴的數(shù)據(jù)接入后就直接對接業(yè)務(wù)。數(shù)據(jù)建設(shè)發(fā)展到一定階段,發(fā)現(xiàn)數(shù)據(jù)的使用雜亂無章,各種業(yè)務(wù)都是從原始數(shù)據(jù)直接計算而得。各種重復(fù)計算,嚴(yán)重浪費了計算資源,需要優(yōu)化性能。

    二、文章結(jié)構(gòu)

    最初在做數(shù)據(jù)倉庫的時候遇到了很多坑,由于自身資源有限,接觸數(shù)據(jù)倉庫的時候,感覺在互聯(lián)網(wǎng)行業(yè)里面的數(shù)據(jù)倉庫成功經(jīng)驗很少,網(wǎng)上很難找到實踐性比較強的資料。而那幾本經(jīng)典書籍里面又過于理論,折騰起來真是生不如死。還好現(xiàn)在過去了那個坎,因此多花一些時間整理自己的思路,幫助其他的小伙伴少踩一些坑。文章的結(jié)構(gòu)如下:

    為什么要分層?這個問題被好幾個同學(xué)質(zhì)疑過。因此分層的價值還是要說清楚的。分享一下經(jīng)典的數(shù)據(jù)分層模型,以及每一層的數(shù)據(jù)的作用和如何加工得來。分享兩個數(shù)據(jù)分層的設(shè)計,通過這兩個實際的例子來說明每一層該怎么存數(shù)據(jù)。給出一些建議,不是最好的,但是可以做參考。

    0x01 為什么要分層

    我們對數(shù)據(jù)進(jìn)行分層的一個主要原因就是希望在管理數(shù)據(jù)的時候,能對數(shù)據(jù)有一個更加清晰的掌控,詳細(xì)來講,主要有下面幾個原因:

    清晰數(shù)據(jù)結(jié)構(gòu):每一個數(shù)據(jù)分層都有它的作用域,這樣我們在使用表的時候能更方便地定位和理解。數(shù)據(jù)血緣追蹤:簡單來講可以這樣理解,我們最終給業(yè)務(wù)誠信的是一能直接使用的張業(yè)務(wù)表,但是它的來源有很多,如果有一張來源表出問題了,我們希望能夠快速準(zhǔn)確地定位到問題,并清楚它的危害范圍。減少重復(fù)開發(fā):規(guī)范數(shù)據(jù)分層,開發(fā)一些通用的中間層數(shù)據(jù),能夠減少極大的重復(fù)計算。把復(fù)雜問題簡單化。講一個復(fù)雜的任務(wù)分解成多個步驟來完成,每一層只處理單一的步驟,比較簡單和容易理解。而且便于維護(hù)數(shù)據(jù)的準(zhǔn)確性,當(dāng)數(shù)據(jù)出現(xiàn)問題之后,可以不用修復(fù)所有的數(shù)據(jù),只需要從有問題的步驟開始修復(fù)。屏蔽原始數(shù)據(jù)的異常。屏蔽業(yè)務(wù)的影響,不必改一次業(yè)務(wù)就需要重新接入數(shù)據(jù)。

    數(shù)據(jù)體系中的各個表的依賴就像是電線的流向一樣,我們都希望它是規(guī)整、流向清晰、便于管理的,如下圖:

    大數(shù)據(jù)

    但是,最終的結(jié)果大多卻是依賴復(fù)雜、層級混亂,想梳理清楚一張表的聲稱途徑會比較困難,如下圖:

    大數(shù)據(jù)

    0x02 怎樣分層

    一、理論

    我們從理論上來做一個抽象,可以把數(shù)據(jù)倉庫分為下面三個層,即:數(shù)據(jù)運營層、數(shù)據(jù)倉庫層和數(shù)據(jù)產(chǎn)品層。

    大數(shù)據(jù)

    ODS 全稱是 Operational Data Store,操作數(shù)據(jù)存儲.“面向主題的”,數(shù)據(jù)運營層,也叫ODS層,是最接近數(shù)據(jù)源中數(shù)據(jù)的一層,數(shù)據(jù)源中的數(shù)據(jù),經(jīng)過抽取、洗凈、傳輸,也就說傳說中的 ETL 之后,裝入本層。本層的數(shù)據(jù),總體上大多是按照源頭業(yè)務(wù)系統(tǒng)的分類方式而分類的。但是,這一層面的數(shù)據(jù)卻不等同于原始數(shù)據(jù)。在源數(shù)據(jù)裝入這一層時,要進(jìn)行諸如去噪(例如有一條數(shù)據(jù)中人的年齡是 300 歲,這種屬于異常數(shù)據(jù),就需要提前做一些處理)、去重(例如在個人資料表中,同一 ID 卻有兩條重復(fù)數(shù)據(jù),在接入的時候需要做一步去重)、字段命名規(guī)范等一系列操作。數(shù)據(jù)倉庫層(DW),是數(shù)據(jù)倉庫的主體.在這里,從 ODS 層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型。這一層和維度建模會有比較深的聯(lián)系,可以多參考一下前面的幾篇文章。數(shù)據(jù)產(chǎn)品層(APP),這一層是提供為數(shù)據(jù)產(chǎn)品使用的結(jié)果數(shù)據(jù)

    在這里,主要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù),一般會存放在 ES、Mysql 等系統(tǒng)中供線上系統(tǒng)使用,也可能會存在 Hive 或者 Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用。

    如我們經(jīng)常說的報表數(shù)據(jù),或者說那種大寬表,一般就放在這里。

    二、技術(shù)實踐

    這三層技術(shù)劃分,相對來說比較粗粒度,后面我們會專門細(xì)分一下。在此之前,先聊一下每一層的數(shù)據(jù)一般都是怎么流向的。這里僅僅簡單介紹幾個常用的工具,側(cè)重中開源界主流。

    1. 數(shù)據(jù)來源層→ ODS層

    這里其實就是我們現(xiàn)在大數(shù)據(jù)技術(shù)發(fā)揮作用的一個主要戰(zhàn)場。 我們的數(shù)據(jù)主要會有兩個大的來源:

    業(yè)務(wù)庫,這里經(jīng)常會使用 Sqoop 來抽取,比如我們每天定時抽取一次。在實時方面,可以考慮用 Canal 監(jiān)聽 Mysql 的 Binlog,實時接入即可。埋點日志,線上系統(tǒng)會打入各種日志,這些日志一般以文件的形式保存,我們可以選擇用 Flume 定時抽取,也可以用用 Spark Streaming 或者 Storm 來實時接入,當(dāng)然,Kafka 也會是一個關(guān)鍵的角色。其它數(shù)據(jù)源會比較多樣性,這和具體的業(yè)務(wù)相關(guān),不再贅述。

    大數(shù)據(jù)

    注意:?在這層,理應(yīng)不是簡單的數(shù)據(jù)接入,而是要考慮一定的數(shù)據(jù)清洗,比如異常字段的處理、字段命名規(guī)范化、時間字段的統(tǒng)一等,一般這些很容易會被忽略,但是卻至關(guān)重要。特別是后期我們做各種特征自動生成的時候,會十分有用。后續(xù)會有文章來分享。

    2. ODS、DW → App層

    這里面也主要分兩種類型:

    每日定時任務(wù)型:比如我們典型的日計算任務(wù),每天凌晨算前一天的數(shù)據(jù),早上起來看報表。 這種任務(wù)經(jīng)常使用 Hive、Spark 或者生擼 MR 程序來計算,最終結(jié)果寫入 Hive、Hbase、Mysql、Es 或者 Redis 中。實時數(shù)據(jù):這部分主要是各種實時的系統(tǒng)使用,比如我們的實時推薦、實時用戶畫像,一般我們會用 Spark Streaming、Storm 或者 Flink 來計算,最后會落入 Es、Hbase 或者 Redis 中。

    0x03 舉個例子

    網(wǎng)上的例子很多,就不列了,只舉個筆者早期參與設(shè)計的數(shù)據(jù)分層例子。分析一下當(dāng)初的想法,以及這種設(shè)計的缺陷。上原圖和內(nèi)容。

    當(dāng)初的設(shè)計總共分了 6 層,其中去掉元數(shù)據(jù)后,還有5層。下面分析一下當(dāng)初的一個設(shè)計思路。

    大數(shù)據(jù)

    緩沖層(buffer)

    概念:又稱為接口層(stage),用于存儲每天的增量數(shù)據(jù)和變更數(shù)據(jù),如Canal接收的業(yè)務(wù)變更日志。數(shù)據(jù)生成方式:直接從kafka接收源數(shù)據(jù),需要業(yè)務(wù)表每天生成update,delete,inseret數(shù)據(jù),只生成insert數(shù)據(jù)的業(yè)務(wù)表,數(shù)據(jù)直接入明細(xì)層討論方案:只把canal日志直接入緩沖層,如果其它有拉鏈數(shù)據(jù)的業(yè)務(wù),也入緩沖層。日志存儲方式:使用impala外表,parquet文件格式,方便需要MR處理的數(shù)據(jù)讀取。日志刪除方式:長久存儲,可只存儲最近幾天的數(shù)據(jù)。討論方案:直接長久存儲表schema:一般按天創(chuàng)建分區(qū)庫與表命名。庫名:buffer,表名:初步考慮格式為:buffer日期業(yè)務(wù)表名,待定。

    明細(xì)層(ODS, Operational Data Store,DWD: data warehouse detail)

    概念:是數(shù)據(jù)倉庫的細(xì)節(jié)數(shù)據(jù)層,是對STAGE層數(shù)據(jù)進(jìn)行沉淀,減少了抽取的復(fù)雜性,同時ODS/DWD的信息模型組織主要遵循企業(yè)業(yè)務(wù)事務(wù)處理的形式,將各個專業(yè)數(shù)據(jù)進(jìn)行集中,明細(xì)層跟stage層的粒度一致,屬于分析的公共資源數(shù)據(jù)生成方式:部分?jǐn)?shù)據(jù)直接來自kafka,部分?jǐn)?shù)據(jù)為接口層數(shù)據(jù)與歷史數(shù)據(jù)合成。
    canal日志合成數(shù)據(jù)的方式待研究。討論方案:canal數(shù)據(jù)的合成方式為:每天把明細(xì)層的前天全量數(shù)據(jù)和昨天新數(shù)據(jù)合成一個新的數(shù)據(jù)表,覆蓋舊表。同時使用歷史鏡像,按周/按月/按年 存儲一個歷史鏡像到新表。日志存儲方式:直接數(shù)據(jù)使用impala外表,parquet文件格式,canal合成數(shù)據(jù)為二次生成數(shù)據(jù),建議使用內(nèi)表,下面幾層都是從impala生成的數(shù)據(jù),建議都用內(nèi)表+靜態(tài)/動態(tài)分區(qū)。日志刪除方式:長久存儲。表schema:一般按天創(chuàng)建分區(qū),沒有時間概念的按具體業(yè)務(wù)選擇分區(qū)字段。庫與表命名。庫名:ods,表名:初步考慮格式為ods日期業(yè)務(wù)表名,待定。舊數(shù)據(jù)更新方式:直接覆蓋

    輕度匯總層(MID或DWB, data warehouse basis)

    概念:輕度匯總層數(shù)據(jù)倉庫中DWD層和DM層之間的一個過渡層次,是對DWD層的生產(chǎn)數(shù)據(jù)進(jìn)行輕度綜合和匯總統(tǒng)計(可以把復(fù)雜的清洗,處理包含,如根據(jù)PV日志生成的會話數(shù)據(jù))。輕度綜合層與DWD的主要區(qū)別在于二者的應(yīng)用領(lǐng)域不同,DWD的數(shù)據(jù)來源于生產(chǎn)型系統(tǒng),并未滿意一些不可預(yù)見的需求而進(jìn)行沉淀;輕度綜合層則面向分析型應(yīng)用進(jìn)行細(xì)粒度的統(tǒng)計和沉淀數(shù)據(jù)生成方式:由明細(xì)層按照一定的業(yè)務(wù)需求生成輕度匯總表。明細(xì)層需要復(fù)雜清洗的數(shù)據(jù)和需要MR處理的數(shù)據(jù)也經(jīng)過處理后接入到輕度匯總層。日志存儲方式:內(nèi)表,parquet文件格式。日志刪除方式:長久存儲。表schema:一般按天創(chuàng)建分區(qū),沒有時間概念的按具體業(yè)務(wù)選擇分區(qū)字段。庫與表命名。庫名:dwb,表名:初步考慮格式為:dwb日期業(yè)務(wù)表名,待定。舊數(shù)據(jù)更新方式:直接覆蓋

    主題層(DM,data market或DWS, data warehouse service)

    概念:又稱數(shù)據(jù)集市或?qū)挶?。按照業(yè)務(wù)劃分,如流量、訂單、用戶等,生成字段比較多的寬表,用于提供后續(xù)的業(yè)務(wù)查詢,OLAP分析,數(shù)據(jù)分發(fā)等。數(shù)據(jù)生成方式:由輕度匯總層和明細(xì)層數(shù)據(jù)計算生成。日志存儲方式:使用impala內(nèi)表,parquet文件格式。日志刪除方式:長久存儲。表schema:一般按天創(chuàng)建分區(qū),沒有時間概念的按具體業(yè)務(wù)選擇分區(qū)字段。庫與表命名。庫名:dm,表名:初步考慮格式為:dm日期業(yè)務(wù)表名,待定。舊數(shù)據(jù)更新方式:直接覆蓋

    應(yīng)用層(App)

    概念:應(yīng)用層是根據(jù)業(yè)務(wù)需要,由前面三層數(shù)據(jù)統(tǒng)計而出的結(jié)果,可以直接提供查詢展現(xiàn),或?qū)胫罬ysql中使用。數(shù)據(jù)生成方式:由明細(xì)層、輕度匯總層,數(shù)據(jù)集市層生成,一般要求數(shù)據(jù)主要來源于集市層。日志存儲方式:使用impala內(nèi)表,parquet文件格式。日志刪除方式:長久存儲。表schema:一般按天創(chuàng)建分區(qū),沒有時間概念的按具體業(yè)務(wù)選擇分區(qū)字段。庫與表命名。庫名:暫定apl,另外根據(jù)業(yè)務(wù)不同,不限定一定要一個庫。舊數(shù)據(jù)更新方式:直接覆蓋。

    0x04 如何更優(yōu)雅一些

    前面提到的一種設(shè)計其實相對來講已經(jīng)很詳細(xì)了,但是可能層次會有一點多,而且在區(qū)分一張表到底該存放在什么位置的時候可能還有不小的疑惑。我們在這一章里再設(shè)計一套數(shù)據(jù)倉庫的分層,同時在前面的基礎(chǔ)上加上維表和一些臨時表的考慮,來讓我們的方案更優(yōu)雅一些。

    下圖,做了一些小的改動,我們?nèi)サ袅松弦还?jié)的Buffer層,把數(shù)據(jù)集市層和輕度匯總層放在同一個層級上,同時獨立出來了維表和臨時表。

    大數(shù)據(jù)

    這里解釋一下DWS、DWD、DIM和TMP的作用。

    DWS:輕度匯總層,從ODS層中對用戶的行為做一個初步的匯總,抽象出來一些通用的維度:時間、ip、id,并根據(jù)這些維度做一些統(tǒng)計值,比如用戶每個時間段在不同登錄ip購買的商品數(shù)等。這里做一層輕度的匯總會讓計算更加的高效,在此基礎(chǔ)上如果計算僅7天、30天、90天的行為的話會快很多。我們希望80%的業(yè)務(wù)都能通過我們的DWS層計算,而不是ODS。DWD:這一層主要解決一些數(shù)據(jù)質(zhì)量問題和數(shù)據(jù)的完整度問題。比如用戶的資料信息來自于很多不同表,而且經(jīng)常出現(xiàn)延遲丟數(shù)據(jù)等問題,為了方便各個使用方更好的使用數(shù)據(jù),我們可以在這一層做一個屏蔽。DIM:這一層比較單純,舉個例子就明白,比如國家代碼和國家名、地理位置、中文名、國旗圖片等信息就存在DIM層中。TMP:每一層的計算都會有很多臨時表,專設(shè)一個DWTMP層來存儲我們數(shù)據(jù)倉庫的臨時表。

    0x05 問答

    有朋友問了一些問題,有一些之前的確沒講清楚,補到這里。

    問答一: dws 和 dwd 的關(guān)系

    問:dws 和dwd 是并行而不是先后順序?
    答:并行的,dw 層
    問:那其實對于同一個數(shù)據(jù),這兩個過程是串行的?
    答:dws 會做匯總,dwd 和 ods 的粒度相同,這兩層之間也沒有依賴的關(guān)系
    問:對呀,那這樣 dws 里面的匯總沒有經(jīng)過數(shù)據(jù)質(zhì)量和完整度的處理,或者單獨做了這種質(zhì)量相關(guān)的處理,為什么不在 dwd 之上再做匯總呢?我的疑問其實就是,dws的輕度匯總數(shù)據(jù)結(jié)果,有沒有做數(shù)據(jù)質(zhì)量的處理?
    答:ods 直接到 dws 就好,沒必要過 dwd,我舉個例子,你的瀏覽商品行為,我做一層輕度匯總,就直接放在 dws 了。但是你的資料表,要從好多表湊成一份,我們從四五份個人資料表中湊出來了一份完整的資料表放在了 dwd 中。然后在 app 層,我們要出一張畫像表,包含用戶資料和用戶近一年的行為,我們就直接從dwd中拿資料, 然后再在 dws 的基礎(chǔ)上做一層統(tǒng)計,就成一個app表了。當(dāng)然,這不是絕對,dws 和 dwd 有沒有依賴關(guān)系主要看有沒有這種需求。

    問答二: ods 和 dwd 的區(qū)別

    問:還是不太明白 ods 和 dwd 層的區(qū)別,有了 ods 層后感覺 dwd 沒有什么用了。
    答:嗯,我是這樣理解的,站在一個理想的角度來講,如果 ods 層的數(shù)據(jù)就非常規(guī)整,基本能滿足我們絕大部分的需求,這當(dāng)然是好的,這時候 dwd 層其實也沒太大必要。 但是現(xiàn)實中接觸的情況是 ods 層的數(shù)據(jù)很難保證質(zhì)量,畢竟數(shù)據(jù)的來源多種多樣,推送方也會有自己的推送邏輯,在這種情況下,我們就需要通過額外的一層 dwd 來屏蔽一些底層的差異。
    問:我大概明白了,是不是說 dwd 主要是對 ods 層做一些數(shù)據(jù)清洗和規(guī)范化的操作,dws 主要是對 ods 層數(shù)據(jù)做一些輕度的匯總?
    答:對的,可以大致這樣理解。

    問答三:app 層是干什么的?

    問:感覺數(shù)據(jù)集市層是不是沒地方放了,各個業(yè)務(wù)的數(shù)據(jù)集市表是應(yīng)該在 dwd 還是在 app?
    答:這個問題不太好回答,我感覺主要就是明確一下數(shù)據(jù)集市層是干什么的,如果你的數(shù)據(jù)集市層放的就是一些可以供業(yè)務(wù)方使用的寬表表,放在 app 層就行。如果你說的數(shù)據(jù)集市層是一個比較泛一點的概念,那么其實 dws、dwd、app 這些合起來都算是數(shù)據(jù)集市的內(nèi)容。
    問:那存到 Redis、ES 中的數(shù)據(jù)算是 app層嗎?
    答:算是的,我個人的理解,app 層主要存放一些相對成熟的表,能供業(yè)務(wù)側(cè)使用的。這些表可以在 Hive 中,也可以是從 Hive 導(dǎo)入 Redis 或者 ES 這種查詢性能比較好的系統(tǒng)中。

    0xFF 總結(jié)

    數(shù)據(jù)分層是數(shù)據(jù)倉庫非常重要的一個環(huán)節(jié),它決定的不僅僅是一個層次的問題,還直接影響到血緣分析、特征自動生成、元數(shù)據(jù)管理等一系列功能的建設(shè)。因此適于盡早考慮。

    另外,每一層的名字不必太過在意,自己按照喜好就好。

    本文分享了筆者自己對數(shù)據(jù)倉庫的一些理解和想法,不一定準(zhǔn)確也不一定通用,但是可以作為一個參考的思路。有什么問題歡迎多交流。

    極客網(wǎng)企業(yè)會員

    免責(zé)聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請進(jìn)一步核實,并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏,概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時,應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關(guān)文章源頭核實,溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。

    2017-10-20
    【漫談數(shù)據(jù)倉庫】 如何優(yōu)雅地設(shè)計數(shù)據(jù)分層
    一、文章主題 本文主要講解數(shù)據(jù)倉庫的一個重要環(huán)節(jié):如何設(shè)計數(shù)據(jù)分層!其它關(guān)于數(shù)據(jù)倉庫的內(nèi)容可參考之前的文章。 本文對數(shù)據(jù)分層的討論適合下面一些場景,超過該范圍

    長按掃碼 閱讀全文