蜜桃av色欲a片精品一区,麻豆aⅴ精品无码一区二区,亚洲人成网站在线播放影院在线,亚洲 素人 字幕 在线 最新

  數(shù)據(jù)倉(cāng)庫(kù)建模實(shí)踐

發(fā)布日期：2022/8/9 11:14:26      瀏覽量：

我們都知道，倉(cāng)庫(kù)的一般意義是指一個(gè)特別大的是用于存放各種物品的庫(kù)房，所以，數(shù)據(jù)倉(cāng)庫(kù)常?？梢越o人一個(gè)很直觀的理解，就是一個(gè)可以存放各種數(shù)據(jù)的大的存儲(chǔ)。

在建設(shè)數(shù)據(jù)倉(cāng)庫(kù)時(shí)，我們常常要對(duì)數(shù)據(jù)進(jìn)行分層，比如常見分層方式：ODS層->DWD層->DWB層->DM層->ADS層。

數(shù)據(jù)倉(cāng)庫(kù)建模通常是指DWD層的建模，因?yàn)镈WD是數(shù)據(jù)倉(cāng)庫(kù)中使用最廣泛的數(shù)據(jù)分層，我們需要盡可能保證這一層的易用性。DWD層的模型很大程度上影響了一個(gè)數(shù)據(jù)倉(cāng)庫(kù)項(xiàng)目甚至數(shù)據(jù)平臺(tái)項(xiàng)目的成敗。本文將針對(duì)DWD層數(shù)據(jù)建模分享一下我們?cè)陧?xiàng)目上的實(shí)踐經(jīng)驗(yàn)。

數(shù)據(jù)倉(cāng)庫(kù)基本特征

開始之前，我們先來(lái)了解一下數(shù)據(jù)倉(cāng)庫(kù)的特征。

數(shù)據(jù)倉(cāng)庫(kù)的相關(guān)概念最早是由 W. H. Inmon 于90年代提出來(lái)的，Inmon也因此被大家認(rèn)為是數(shù)據(jù)倉(cāng)庫(kù)之父。在Inmon的數(shù)據(jù)倉(cāng)庫(kù)理念里，數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)面向主題的（Subject Oriented）、集成的（Integrate）、非易失（Non-Volatile）且時(shí)變（Time Variant）的數(shù)據(jù)集，用于支持管理決策。

面向主題、集成、非易失且時(shí)變是數(shù)據(jù)倉(cāng)庫(kù)的四個(gè)基本特征。其中，面向主題可以認(rèn)為是一種面向分析的數(shù)據(jù)分類和映射；集成的是指將不同的數(shù)據(jù)源的數(shù)據(jù)集合到一起以便于分析；非易失可以理解為穩(wěn)定，是指進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)不會(huì)發(fā)生修改；時(shí)變是指數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)需要保留歷史，以便于任何時(shí)候回頭對(duì)數(shù)據(jù)進(jìn)行分析。

數(shù)據(jù)倉(cāng)庫(kù)主鍵

時(shí)變這個(gè)特征對(duì)數(shù)據(jù)倉(cāng)庫(kù)建模提出了最基本的技術(shù)上的要求，我們的數(shù)據(jù)模型要如何建立才可以保留所有歷史數(shù)據(jù)呢？Inmon在《數(shù)據(jù)倉(cāng)庫(kù)》這本書里面提出了一些新的概念，可以幫助我們實(shí)現(xiàn)時(shí)變這個(gè)特點(diǎn)。

首先，每一張數(shù)據(jù)庫(kù)表都應(yīng)當(dāng)有一個(gè)主鍵，它可以唯一標(biāo)識(shí)一條數(shù)據(jù)，以便支持?jǐn)?shù)據(jù)的查找、更新、關(guān)聯(lián)。這是當(dāng)前業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)模型設(shè)計(jì)的一個(gè)基本指導(dǎo)原則。很多數(shù)據(jù)庫(kù)設(shè)計(jì)指導(dǎo)甚至?xí)ㄗh為所有表設(shè)計(jì)一個(gè)自增且無(wú)業(yè)務(wù)含義的字段作為主鍵。唯一字段主鍵為數(shù)據(jù)查詢及關(guān)聯(lián)提供了很大的方便。

實(shí)際操作中，我們可以認(rèn)為業(yè)務(wù)系統(tǒng)的所有數(shù)據(jù)庫(kù)表中均存在一個(gè)主鍵，如果沒(méi)有單一字段主鍵，也應(yīng)該有多個(gè)字段可以組合成為一個(gè)主鍵。多個(gè)字段形成的主鍵在數(shù)據(jù)庫(kù)設(shè)計(jì)中被稱為復(fù)合主鍵。

我們可以向業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)人員了解主鍵字段是哪些，也可以通過(guò)基本的數(shù)據(jù)分析找出主鍵（比如，觀察表中的非空字段可以輔助發(fā)現(xiàn)主鍵字段）。其實(shí)，就算業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)人員告知了我們哪些字段是主鍵，本著懷疑的態(tài)度，我們也應(yīng)該要從數(shù)據(jù)層面進(jìn)行主鍵驗(yàn)證。通常我們可以通過(guò)執(zhí)行SQL來(lái)驗(yàn)證主鍵，對(duì)比多字段唯一計(jì)數(shù)（count(distinct concat(col1, col2))）和數(shù)據(jù)庫(kù)數(shù)據(jù)總行數(shù)（count(*)）的值，如果兩者相等，則這些字段可以作為主鍵字段。

保存數(shù)據(jù)歷史其實(shí)就是根據(jù)數(shù)據(jù)主鍵進(jìn)行保存，歷史數(shù)據(jù)將包含每一個(gè)主鍵（每一條條數(shù)據(jù)）對(duì)應(yīng)的所有的變更。

如果我們直接將所有歷史數(shù)據(jù)存儲(chǔ)到一張表里面（保持與業(yè)務(wù)系統(tǒng)表字段一致），那么數(shù)據(jù)庫(kù)倉(cāng)庫(kù)中的表的主鍵就將變得模糊不清，不便于使用，（這是ods層的數(shù)據(jù)情況，所以一般不建議直接從ods取數(shù)使用）。一般而言，我們會(huì)為數(shù)據(jù)倉(cāng)庫(kù)的表額外設(shè)計(jì)一個(gè)唯一字段主鍵。為了區(qū)分原表的主鍵和數(shù)據(jù)倉(cāng)庫(kù)新引入的主鍵，我們可以給它們換個(gè)名字。通常，原表的主鍵被稱為業(yè)務(wù)鍵、業(yè)務(wù)主鍵或自然鍵，數(shù)據(jù)倉(cāng)庫(kù)新引入的主鍵被稱為代理鍵或數(shù)據(jù)倉(cāng)庫(kù)主鍵（下文稱業(yè)務(wù)鍵和代理鍵）。

數(shù)據(jù)倉(cāng)庫(kù)外鍵

有了數(shù)據(jù)倉(cāng)庫(kù)代理鍵，單表的歷史數(shù)據(jù)保存問(wèn)題就解決了。除了單表歷史數(shù)據(jù)問(wèn)題，我們常常還需要解決表間關(guān)聯(lián)的歷史數(shù)據(jù)問(wèn)題。

比如，在電商的場(chǎng)景下，昨天某店鋪以100元賣出了一款產(chǎn)品，由于市場(chǎng)變化，今天需要調(diào)整產(chǎn)品價(jià)格為120，此時(shí)，當(dāng)我們查詢昨天的那筆訂單時(shí)，應(yīng)該需要能找到昨天對(duì)應(yīng)的價(jià)格。由于產(chǎn)品價(jià)格和訂單常常存儲(chǔ)于不同的表中，這就形成了典型的表間關(guān)聯(lián)的歷史數(shù)據(jù)查詢問(wèn)題。

也有的文章將這種歷史數(shù)據(jù)稱作數(shù)據(jù)快照。比如，典型的情況是對(duì)每天的數(shù)據(jù)生成一個(gè)快照。

如何解決表間關(guān)聯(lián)的歷史數(shù)據(jù)問(wèn)題呢？還是可以基于代理鍵來(lái)實(shí)現(xiàn)。只需要實(shí)現(xiàn)一個(gè)轉(zhuǎn)換邏輯，將原來(lái)的每張數(shù)據(jù)庫(kù)表的外鍵轉(zhuǎn)換為代理鍵即可。

代理鍵設(shè)計(jì)

如何來(lái)設(shè)計(jì)數(shù)據(jù)倉(cāng)庫(kù)代理鍵呢？傳統(tǒng)的數(shù)據(jù)庫(kù)設(shè)計(jì)理論會(huì)建議我們使用一個(gè)與業(yè)務(wù)無(wú)關(guān)的自增值作為代理主鍵。但是，在當(dāng)下流行的基于分布式計(jì)算的數(shù)據(jù)倉(cāng)庫(kù)技術(shù)下，如果使用自增鍵，我們將遇到很多技術(shù)挑戰(zhàn)。比如：

• 需要預(yù)先查詢當(dāng)前最大主鍵值
• 分布式環(huán)境下生成主鍵，需要在各個(gè)計(jì)算節(jié)點(diǎn)進(jìn)行任務(wù)協(xié)調(diào)，導(dǎo)致速度變慢
• 除非預(yù)先指定非常嚴(yán)格的數(shù)據(jù)排序，否則重復(fù)計(jì)算將生成不同的主鍵，計(jì)算任務(wù)也就無(wú)法實(shí)現(xiàn)冪等（數(shù)據(jù)任務(wù)的冪等性是指，對(duì)同樣的輸入，任務(wù)每次運(yùn)行都產(chǎn)生一個(gè)同樣的輸出。數(shù)據(jù)項(xiàng)目中的任務(wù)冪等性非常重要，試想，如果每次生成的主鍵不一樣，那么當(dāng)主鍵重新生成時(shí)，上層所有依賴任務(wù)需要重新計(jì)算。這將帶來(lái)大量的額外計(jì)算，大大降低效率。）

對(duì)于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)而言，自增主鍵帶來(lái)的優(yōu)勢(shì)主要是占用存儲(chǔ)空間低和計(jì)算速度快，但在分布式數(shù)據(jù)存儲(chǔ)和計(jì)算的前提下，這個(gè)優(yōu)勢(shì)其實(shí)并不明顯。

基于Hive的數(shù)據(jù)倉(cāng)庫(kù)支持多種類型的存儲(chǔ)格式，我們常見的如ORC或Parquet格式都是列式存儲(chǔ)并支持壓縮的。 對(duì)于文本類重復(fù)率較高的數(shù)據(jù)常?？梢杂泻芨叩膲嚎s率，從而緩解存儲(chǔ)空間占用大的問(wèn)題。同時(shí)，由于分布式計(jì)算的存在，字符串比較產(chǎn)生的性能損失也顯得不那么明顯。

我們?cè)?jīng)做過(guò)一個(gè)測(cè)試，先隨機(jī)生成一個(gè)長(zhǎng)整型數(shù)據(jù)，然后計(jì)算其md5值，接著比較兩者的存儲(chǔ)空間和表連接效率，發(fā)現(xiàn)結(jié)果相差無(wú)幾。（見文末測(cè)試報(bào)告）

所以，結(jié)合我們的實(shí)踐經(jīng)驗(yàn)，我們建議數(shù)據(jù)倉(cāng)庫(kù)代理鍵使用以下方式生成。

• 找出業(yè)務(wù)鍵對(duì)應(yīng)的字段（可能是多個(gè)）；
• 找出數(shù)據(jù)更新時(shí)間字段，如果是全量表，可使用接入數(shù)據(jù)的日期；
• 將業(yè)務(wù)鍵字段及數(shù)據(jù)變更時(shí)間字段計(jì)算哈希值生成代理鍵；

對(duì)應(yīng)的sql表達(dá)式示例：

sha1(concat(sha1(business_pk1), sha1(business_pk2), sha1(update_time)))。

使用這種方式生成的代理鍵可以很好的解決任務(wù)冪等性問(wèn)題，并且不會(huì)有太大的性能損失。

有了任務(wù)冪等性，我們就可以更從容的應(yīng)對(duì)DWD層的修改。這樣的修改可能比想象的更頻繁，比如：

• 業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)引入了一個(gè)新的字段，需要在DWD層模型中新增這個(gè)字段進(jìn)行分析
• • 由于對(duì)業(yè)務(wù)數(shù)據(jù)理解出現(xiàn)問(wèn)題，或者業(yè)務(wù)系統(tǒng)提供的數(shù)據(jù)編碼值不對(duì)，或者業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)編碼值改變等情況，原來(lái)的DWD層中的數(shù)據(jù)清洗或轉(zhuǎn)換規(guī)則需要更新
  • 對(duì)于上述更新，我們就無(wú)需重新運(yùn)行所有上層計(jì)算任務(wù)了，只運(yùn)行依賴這個(gè)變更字段的任務(wù)即可。

重新建模

很多時(shí)候，我們一講數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)平臺(tái)，幾乎馬上就可以讓人想到維度建模。維度建模在數(shù)據(jù)倉(cāng)庫(kù)建設(shè)中的重要性可想而知（這里的維度建模通常就是指dwd層的建模）。

但是，如果我們看下維度建模的發(fā)展就知道，維度建模是早在1996時(shí)由Ralph Kimball首次提出來(lái)的。在當(dāng)下的技術(shù)環(huán)境下來(lái)看，維度建模的理論還是有效的嗎？有哪些到現(xiàn)在還是好的實(shí)踐，哪些應(yīng)該摒棄呢？

維度建模的目的是為了更好的進(jìn)行數(shù)據(jù)分析。維度建模的理論將數(shù)據(jù)表分為事實(shí)表和維度表。大部分的數(shù)據(jù)分析將從事實(shí)表出發(fā)，關(guān)聯(lián)到維度表，再進(jìn)行統(tǒng)計(jì)。這一理論揭示了數(shù)據(jù)分析的規(guī)律性，不僅使得數(shù)據(jù)分析實(shí)施起來(lái)更有章法，還給相關(guān)的技術(shù)工具的設(shè)計(jì)提供了理論支持。

但是，一旦我們將維度建模的理論應(yīng)用于實(shí)際項(xiàng)目，我們常常很快就會(huì)陷入困境。因?yàn)榫S度和事實(shí)其實(shí)不那么容易區(qū)分，它們常常是相對(duì)的概念。比如，訂單看起來(lái)是一個(gè)事實(shí)，而其關(guān)聯(lián)的產(chǎn)品應(yīng)該屬于維度。但是，一般情況下，一筆訂單下會(huì)存在多個(gè)商品，如果我們對(duì)訂單下的某一個(gè)商品進(jìn)行分析，此時(shí)是不是該商品變成了事實(shí)，而訂單則是該事實(shí)的關(guān)聯(lián)維度？

所以，維度模型為了完善其對(duì)于數(shù)據(jù)分析的抽象，還引入了很多相關(guān)的較為復(fù)雜的概念。比如橋接表等。這些相關(guān)概念的引入給數(shù)據(jù)分析帶來(lái)了更多的學(xué)習(xí)成本，對(duì)于維度模型理論的推廣帶來(lái)了阻力。

另一方面，越來(lái)越多業(yè)務(wù)人員正在成為數(shù)據(jù)分析師（大部分?jǐn)?shù)據(jù)分析只需要sql就可以實(shí)現(xiàn)，所以，簡(jiǎn)單的數(shù)據(jù)分析是可以由業(yè)務(wù)人員自己完成的，這是更高效的做法，同時(shí)也是業(yè)界正在推進(jìn)的實(shí)踐）。這樣一來(lái)，維度建模的復(fù)雜性就更難接受了，因?yàn)槲覀儾粦?yīng)該要求業(yè)務(wù)人員先去學(xué)習(xí)復(fù)雜的維度建模再來(lái)進(jìn)行數(shù)據(jù)分析。

從技術(shù)上看，由于都是基于關(guān)系型數(shù)據(jù)庫(kù)，其實(shí)，維度建模得到的模型與三范式模型并無(wú)太大區(qū)別，幾乎可以一一對(duì)應(yīng)起來(lái)。在上一篇文章中，我們建議在對(duì)數(shù)據(jù)理解不深的時(shí)候，不要進(jìn)行重新建模和模型映射。在這里，我們有相同的結(jié)論，即，不建議進(jìn)行復(fù)雜的維度模型建模，而是簡(jiǎn)單的將業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)中的三范式模型數(shù)據(jù)表進(jìn)行事實(shí)維度標(biāo)記。這樣得到的數(shù)據(jù)表與三范式數(shù)據(jù)表相比，可能只是表名不一樣，稱為維度模型似乎不太相稱，我們可以稱其為簡(jiǎn)單維度模型。

建立簡(jiǎn)單維度模型只需要花費(fèi)很少的時(shí)間，這避免了前期進(jìn)行過(guò)重的復(fù)雜的設(shè)計(jì)，是一種更為精益的做法。

碼值映射

為了更好的進(jìn)行數(shù)據(jù)分析，我們希望數(shù)據(jù)分析時(shí)可以更容易的獲取和理解數(shù)據(jù)。這對(duì)于數(shù)據(jù)字段提出了一些要求，一個(gè)典型的問(wèn)題就是碼值問(wèn)題。

什么是碼值呢？舉個(gè)例子，從業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)的視角來(lái)看，為了提升性能常常會(huì)選用占用存儲(chǔ)空間更少的字段類型進(jìn)行數(shù)據(jù)存儲(chǔ)，于是一些通常只有幾個(gè)取值的狀態(tài)值字段，如訂單狀態(tài)，就會(huì)使用tinyint這樣的單字節(jié)字段類型進(jìn)行存儲(chǔ)。此時(shí)，狀態(tài)值會(huì)被映射為數(shù)字進(jìn)行存儲(chǔ)，如1代表已創(chuàng)建，2代表交易成功等。我們常常把這里的數(shù)字稱為碼，而其對(duì)應(yīng)的值稱為值。

這里的碼值問(wèn)題就是說(shuō)，在數(shù)據(jù)分析時(shí)，我們無(wú)法直接從數(shù)據(jù)中知道某一個(gè)碼對(duì)應(yīng)的是什么值，常常需要進(jìn)行一層碼值轉(zhuǎn)換才能知道。這對(duì)于數(shù)據(jù)分析顯然是不友好的，要么取數(shù)據(jù)邏輯更復(fù)雜，要么數(shù)據(jù)分析師需要在頭腦里面記住這個(gè)碼值映射關(guān)系。

一些二值字段同樣可以從這樣的實(shí)踐中獲益，一般而言，我們可以將二值字段映射為嚴(yán)格的true false值，從而避免潛在的null值，使得DWD層的數(shù)據(jù)更為規(guī)范好用。

所以，在DWD層解決這個(gè)問(wèn)題將帶來(lái)很高的價(jià)值。

出于性能考慮，傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)建模理論可能會(huì)建議我們將這些碼值映射保存到一張單獨(dú)的碼表中，但此時(shí)查詢的便利性還是較差。

由于列式壓縮存儲(chǔ)可以很好的緩解性能問(wèn)題，我們建議在DWD層對(duì)于所有碼值進(jìn)行解碼操作，通過(guò)添加一些列，將原有的數(shù)字映射為真實(shí)的值進(jìn)行保存。

原值保存

在進(jìn)行數(shù)據(jù)清洗時(shí)，我們會(huì)將一些字段處理為更規(guī)范的字段。為了進(jìn)一步提高DWD層的靈活性，一個(gè)實(shí)用的建議是將原來(lái)的字段值保留下來(lái)。這樣一來(lái)，即便我們數(shù)據(jù)清洗規(guī)則有問(wèn)題，或者要新增數(shù)據(jù)清洗規(guī)則，在數(shù)據(jù)分析師進(jìn)行數(shù)據(jù)分析時(shí)都有數(shù)據(jù)可用，不用等待DWD層重新構(gòu)建。

對(duì)于上文提到的碼值映射，我們就可以保留字段原值。在實(shí)踐時(shí)，我們會(huì)將原來(lái)的字段重命名，添加一個(gè)original的前綴。其意義在于，我們不推薦使用原值字段（加一個(gè)前綴使字段名更長(zhǎng)而不便于使用），但是我們保留使用字段原值的能力。

對(duì)于主鍵而言，如果業(yè)務(wù)系統(tǒng)表的主鍵由多個(gè)字段組成，我們建議通過(guò)對(duì)這些字段進(jìn)行哈希生成一個(gè)單一字段主鍵，這將在表關(guān)聯(lián)及數(shù)據(jù)訪問(wèn)時(shí)提供額外的靈活性。此時(shí)原來(lái)的主鍵也應(yīng)保留下來(lái)供分析使用。

時(shí)間處理

時(shí)間是一個(gè)特殊的類型，很多數(shù)據(jù)分析都是基于時(shí)間來(lái)開展的。比如每天的銷量，每月的銷量，節(jié)假日客流量等。所以，我們常常把日期作為一個(gè)單獨(dú)的維度表進(jìn)行構(gòu)建，該維表內(nèi)會(huì)存儲(chǔ)節(jié)假日、星期幾時(shí)段等常用的分析維度信息。如果有對(duì)于時(shí)間的分析需求，也可以建立時(shí)間的維表，以便保存常見的早中晚等時(shí)段信息。

其他的表如何關(guān)聯(lián)日期和時(shí)間呢？可以通過(guò)外鍵實(shí)現(xiàn)。所以，在數(shù)據(jù)表里面出現(xiàn)日期或時(shí)間字段時(shí)，可以根據(jù)該字段建立對(duì)應(yīng)日期和時(shí)間維表外鍵。

由于日期和時(shí)間的取值非常固定，可以用一個(gè)整數(shù)來(lái)表示。比如，日期可以是8位整數(shù)，如20210101，類似的，時(shí)間可以表示為6位整數(shù)，如120101。所以，日期和時(shí)間維表常常用這樣的整數(shù)來(lái)作為主鍵（此時(shí)也是代理鍵，因?yàn)槿掌诤蜁r(shí)間維表無(wú)需保留歷史）。使用整數(shù)作為主鍵，可移植性和易用性可以得到一定程度的增強(qiáng)。

數(shù)據(jù)倉(cāng)庫(kù)建模總結(jié)

經(jīng)過(guò)上面的討論，我們可以得到這樣一些數(shù)據(jù)倉(cāng)庫(kù)建模的經(jīng)驗(yàn)：

• 代理鍵生成使用sha1和concat, 并注意處理null
• 外鍵列保留對(duì)應(yīng)的業(yè)務(wù)鍵字段
• 做了碼值轉(zhuǎn)換的字段保留原字段，命名為original_{原字段}
• 處理date/time的字段，除了生成外鍵列，需要保留一個(gè)timestamp字段，方便后續(xù)使用

在實(shí)踐過(guò)程中，我們把上述幾條規(guī)則當(dāng)做dwd層建模原則來(lái)對(duì)待。

有了這樣的建模原則，dwd層的構(gòu)建幾乎可以完全自動(dòng)化的完成。只需要我們開發(fā)一些數(shù)據(jù)工具進(jìn)行輔助就可以了。在后面的文章中，我們將一起來(lái)看一下，這樣的建模工具應(yīng)該如何設(shè)計(jì)實(shí)現(xiàn)。

附錄

文本字段和數(shù)值型字段對(duì)比測(cè)試

運(yùn)行以下sql可以測(cè)試文本類型字段和整數(shù)型字段的存儲(chǔ)空間占用及關(guān)聯(lián)查詢性能。

-- 生成1000,000條數(shù)據(jù)，其中有1000個(gè)不同的值，進(jìn)行md5編碼后存儲(chǔ)起來(lái)create table test.test_join stored as Parquet TBLPROPERTIES ("transactional" = "false") aswith rand_list_ as (select t.f1,t.start_r - pe.i as seq_no from (select ’ABC’ as f1, 1000000 as start_r, 0 as end_r) t lateral view posexplode(split(space(start_r - end_r - 1),’’)) pe as i,s),rand_list as (SELECTcast(rand() * 10 as INTEGER) * 100 + cast(rand() * 10 as INTEGER) * 10 + cast(rand() * 10 as INTEGER) as n,seq_no as idfrom rand_list_select id, n, md5(cast(n as string)) sn from rand_list;-- 將數(shù)值型字段和文本型字段分別寫入到不同的表中，比較存儲(chǔ)空間占用，可以發(fā)現(xiàn)均占用約1.2MB的空間create table test.test_join_n stored as Parquet TBLPROPERTIES ("transactional" = "false") as select n from test.test_join;create table test.test_join_s stored as Parquet TBLPROPERTIES ("transactional" = "false") as select sn from test.test_join;-- 測(cè)試使用數(shù)值型字段進(jìn)行關(guān)聯(lián)和使用文本型字段進(jìn)行關(guān)聯(lián)，兩者都在10秒左右完成select count(1) from test.test_join j join test.test_join_n n on j.n=n.n;select count(1) from test.test_join j join test.test_join_s s on j.sn=s.sn;

運(yùn)行上述測(cè)試之后可以得到的結(jié)論是：

• 數(shù)值型字段和文本型字段的存儲(chǔ)空間占用差異不大
• 數(shù)值型字段和文本型字段在表連接時(shí)性能差異不大

基于在多家企業(yè)多個(gè)項(xiàng)目的經(jīng)驗(yàn)總結(jié)，我們沉淀出一套企業(yè)數(shù)據(jù)開發(fā)工作臺(tái)，可以幫助團(tuán)隊(duì)高效交付數(shù)據(jù)需求，幫助企業(yè)快速構(gòu)建數(shù)據(jù)能力，工作臺(tái)地址：https://data-workbench.com/

我們開源了其中的核心模塊--ETL開發(fā)語(yǔ)言，開源項(xiàng)目地址：https://github.com/easysql/easy_sql