柚子快報(bào)邀請(qǐng)碼778899分享：大數(shù)據(jù)知識(shí)框架

http://yzkb.51969.com/

一、數(shù)倉(cāng)建模

漫談數(shù)倉(cāng)五重奏-騰訊云開(kāi)發(fā)者社區(qū)-騰訊云

1、為什么要做數(shù)倉(cāng)分層

分層是站在數(shù)倉(cāng)全集的視角，對(duì)于一系列的計(jì)算過(guò)程抽象出通用的職責(zé)，規(guī)定每一層只做某些職責(zé)，每一層有自己獨(dú)特的命名，并且不同層之間有明確的前后關(guān)系。

持久化可以用空間換時(shí)間，節(jié)省計(jì)算資源。通過(guò)分層的數(shù)據(jù)預(yù)處理，能夠更快滿足應(yīng)用的取數(shù)效率；增加了復(fù)用性，進(jìn)而帶來(lái)一致性的提升和開(kāi)發(fā)效率的提升。 分層處理數(shù)據(jù)，隔離變化，降低維護(hù)成本，從合作層面可以統(tǒng)一建設(shè)思路?；A(chǔ)層只做數(shù)據(jù)整合清洗，高級(jí)層關(guān)注業(yè)務(wù)規(guī)則，應(yīng)用層面向數(shù)據(jù)應(yīng)用，一個(gè)復(fù)雜工作拆分成多個(gè)層級(jí)關(guān)系清晰的簡(jiǎn)單任務(wù)，每一層的任務(wù)邏輯都相對(duì)簡(jiǎn)單且容易理解，當(dāng)數(shù)據(jù)變動(dòng)時(shí)，因?yàn)閷优c層分離，只需變動(dòng)一小塊。如果不分層，業(yè)務(wù)規(guī)則變動(dòng)時(shí)，工作將十分麻煩，影響巨大，不宜處理。

良好的數(shù)據(jù)流向，血緣清洗，為之后面向倉(cāng)庫(kù)的管理優(yōu)化提供便利。

每一層的作用：

數(shù)倉(cāng)層次 說(shuō)明 作用 ods層 （源數(shù)據(jù)接入層） 存儲(chǔ)數(shù)據(jù)倉(cāng)庫(kù)的源接入數(shù)據(jù)，分為兩類：

一類是關(guān)系型數(shù)據(jù)(比如mysql)到hive的存儲(chǔ)， 一類是非關(guān)系型數(shù)據(jù)(比如網(wǎng)站訪問(wèn)日志、廣告日志log)在hive的存儲(chǔ) 此外還有一類數(shù)據(jù)也可歸入ods層，使用到的其他事業(yè)部的數(shù)據(jù)表。? ods作為數(shù)據(jù)緩沖層，是源系統(tǒng)的備份，粒度與源系統(tǒng)保持一致,一般實(shí)時(shí)或者類實(shí)時(shí)加載數(shù)據(jù)。ods層一般提供操作型報(bào)表(不推薦)，此類報(bào)表應(yīng)該是只關(guān)注當(dāng)前數(shù)據(jù)，不關(guān)注歷史的。除開(kāi)發(fā)使用，排查case使用，ods層不允許用戶直接訪問(wèn)進(jìn)行數(shù)據(jù)分析。 ?? 1）制定ods存儲(chǔ)規(guī)則，(增量/全量/快照)；?? 2）監(jiān)控ods核心數(shù)據(jù)的異常; dw基礎(chǔ)明細(xì)層 存儲(chǔ)數(shù)據(jù)倉(cāng)庫(kù)的最底層明細(xì)數(shù)據(jù)，不面向分析，該層數(shù)據(jù)與ods源數(shù)據(jù)粒度相同，是對(duì)ods做過(guò)過(guò)濾、清洗、轉(zhuǎn)化后統(tǒng)一的規(guī)整的數(shù)據(jù)存儲(chǔ)，將分庫(kù)分表的數(shù)據(jù)或者多業(yè)務(wù)線的數(shù)據(jù)做行級(jí)別的數(shù)據(jù)集合。 1）清洗ods數(shù)據(jù)，如ods中存在的一些軟刪除數(shù)據(jù)； 2）多數(shù)據(jù)源的數(shù)據(jù)歸并，如日志的數(shù)據(jù)分散在搜索、推薦、聯(lián)盟（一些情況下有些數(shù)據(jù)源數(shù)據(jù)的字段不一致度較高，建議不合并）； 3）維度一致性處理，維度值不是標(biāo)準(zhǔn)維度的要進(jìn)行轉(zhuǎn)換； 4）事實(shí)一致性處理，如金額字段統(tǒng)一轉(zhuǎn)換為‘元’為單位; dw基礎(chǔ)匯總層 該層存儲(chǔ)對(duì)明細(xì)數(shù)據(jù)的維度匯總數(shù)據(jù)，這里的維度包括(日期維度，業(yè)務(wù)維度等)，通過(guò)明細(xì)層聚合，基于明細(xì)層的一些指標(biāo)基本在這一層定型(如pv,計(jì)費(fèi)單位等)，形成匯總層數(shù)據(jù)。 通常用維度建模構(gòu)建星型模型、雪花模型、星座模型。 dw基礎(chǔ)匯總層主要對(duì)明細(xì)層數(shù)據(jù)歸并，為上層的主題層提供一致性的基礎(chǔ)匯總模型。該層表根據(jù)粒度的粗細(xì)可分為輕度匯總，高度匯總表，即是該層表可以有內(nèi)部依賴。 采用維度建模，事實(shí)表中需要包含主要分析維度的主鍵(包含較少的維度屬性值），事實(shí)的是完全可加的事實(shí)，對(duì)于復(fù)合指標(biāo)如比率，乘積，分子分母需要分開(kāi)存儲(chǔ)。?注：不同粒度的事實(shí)存儲(chǔ)不同的事實(shí)表中。 dm主題層 主題層表加入業(yè)務(wù)邏輯,直觀反應(yīng)業(yè)務(wù)問(wèn)題建模的多維聚合的寬表。 1) 采取反范式設(shè)計(jì)，為方便使用以寬表的形式提供 2) 業(yè)務(wù)主題層應(yīng)該以“寬”的原則進(jìn)行整合，盡可能包含常用屬性 3) 主題表的組織應(yīng)當(dāng)是以業(yè)務(wù)主題為驅(qū)動(dòng)，相同業(yè)務(wù)主題的整合在一張表，而不是維度驅(qū)動(dòng)，把維度相同的數(shù)據(jù)都整合在一起，從而帶來(lái)維護(hù)、效率等方面的問(wèn)題。 由于分析粒度的不同，主題層表可以有內(nèi)部依賴。 1）一類是主題歸并(基于基礎(chǔ)事實(shí)表和維度表，在相同粒度、維度上合并)的寬表； 2）一類是主題內(nèi)基于dw基礎(chǔ)數(shù)據(jù)的高級(jí)分析表(如留存分析，RFM分析)； rpt應(yīng)用層 存儲(chǔ)面向報(bào)表和數(shù)據(jù)產(chǎn)品應(yīng)用的數(shù)據(jù)，包括(數(shù)據(jù)應(yīng)用系統(tǒng)模型、報(bào)表模型等)，該層模型面向應(yīng)用，怎么好用怎么建，可以不同粒度事實(shí)在一個(gè)表，也可以不同粒度數(shù)據(jù)在一個(gè)表。 rpt應(yīng)用層主要生成應(yīng)用數(shù)據(jù)，這些應(yīng)用數(shù)據(jù)可以落地hive，也可以為了查詢快捷落地mysql、Druid等存儲(chǔ)。該層應(yīng)該很少或者沒(méi)有表之間的依賴。 1）考慮應(yīng)用特性，選擇應(yīng)用存儲(chǔ)類型 2）因?yàn)闃I(yè)務(wù)模型變動(dòng)較快，相當(dāng)時(shí)候有回溯歷史數(shù)據(jù)的需要，建模時(shí)考慮變動(dòng)、回溯數(shù)據(jù)的便捷性。

2、范式建模（簡(jiǎn)單易懂的說(shuō)明 數(shù)據(jù)庫(kù)三大范式（通俗易懂）_第一二三范式怎么區(qū)分-CSDN博客）

第一：列獨(dú)立 數(shù)據(jù)庫(kù)表的每一列都是不可分割的原子數(shù)據(jù)項(xiàng) 第二：有主鍵 要求數(shù)據(jù)庫(kù)表中的每個(gè)實(shí)例或記錄必須可以被唯一地區(qū)分 第三：不冗余 任何非主屬性不依賴于其它非主屬性（在2NF基礎(chǔ)上消除傳遞依賴）

3、維度建模

過(guò)程：梳理維度x指標(biāo)矩陣，自頂向下倒退模型所需字段、所需維表。維度表的拆分可以考慮穩(wěn)定性、業(yè)務(wù)特性。

雪花模型和星型模型的區(qū)別：

4、數(shù)據(jù)域

業(yè)務(wù)過(guò)程為企業(yè)活動(dòng)中不可拆分的行為事件，是一個(gè)動(dòng)作，如下單、支付、退款。通過(guò)業(yè)務(wù)過(guò)程對(duì)模型進(jìn)行分類管理，是輔助理解業(yè)務(wù)鏈條的重要手段。 數(shù)據(jù)域是若干個(gè)業(yè)務(wù)過(guò)程的集合，是用于分類管理業(yè)務(wù)過(guò)程的一級(jí)概念。數(shù)據(jù)域既有以對(duì)象為限定的命名（比如商品/會(huì)員），也有對(duì)動(dòng)作事件的命名（交易、互動(dòng)），還有對(duì)范圍限定的命名（廣告、分銷），可見(jiàn)數(shù)據(jù)域不是一個(gè)對(duì)系統(tǒng)的完美劃分（劃分指無(wú)歧義不重不漏）。數(shù)據(jù)域沖突時(shí)：

第一條是動(dòng)作在哪往哪放，比如店鋪的開(kāi)店，這放在店鋪域；但店鋪的曝光，就放在日志域；店鋪的發(fā)券就放在工具和服務(wù)域，所以核心是動(dòng)作的分類，不是主體對(duì)象的分類。 第二條是特殊大于一般，比如廣告的曝光點(diǎn)擊就不放在日志域而放到廣告域，而商品的評(píng)論放在商品域也優(yōu)先于互動(dòng)域，這說(shuō)明同樣的動(dòng)作，具有特殊大于一般的性質(zhì)，劃入精確空間優(yōu)先于劃入粗略空間。 按照阿里的理論，先劃分業(yè)務(wù)線再劃分?jǐn)?shù)據(jù)域，數(shù)據(jù)集市更多是范圍上的劃分。

拉鏈表：緩慢變化維?https://blog.51cto.com/u_150537/4030985

數(shù)據(jù)湖：數(shù)據(jù)湖可存儲(chǔ)結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，是一種面向大規(guī)模、多來(lái)源、高度多樣化數(shù)據(jù)的組織方法。特點(diǎn)是存算分離。iceberg、hudi?數(shù)據(jù)湖初探（一） - 知乎

二、數(shù)據(jù)治理

數(shù)倉(cāng)的目標(biāo)：效率高、質(zhì)量好、成本低、有價(jià)值。

效率、質(zhì)量、成本、安全、元數(shù)據(jù)

1、計(jì)算優(yōu)化

2、存儲(chǔ)優(yōu)化

3、指標(biāo)管理

4、質(zhì)量:準(zhǔn)確性、合理性、一致性、及時(shí)性

三、組件原理

MAPREDUCE

Hadoop MapReduce介紹、官方示例及執(zhí)行流程 - 知乎

SPARK

https://www.cnblogs.com/0xcafedaddy/p/7614299.html

shuffle過(guò)程：

Shuffle有兩個(gè)計(jì)算階段，Map階段和Reduce階段。我們要重點(diǎn)掌握Map階段的計(jì)算流程，我把它總結(jié)為4步：

對(duì)于分片中的數(shù)據(jù)記錄，逐一計(jì)算其目標(biāo)分區(qū)，然后填充內(nèi)存數(shù)據(jù)結(jié)構(gòu)（PartitionedPairBuffer或PartitionedAppendOnlyMap）；當(dāng)數(shù)據(jù)結(jié)構(gòu)填滿后，如果分片中還有未處理的數(shù)據(jù)記錄，就對(duì)結(jié)構(gòu)中的數(shù)據(jù)記錄按（目標(biāo)分區(qū)ID，Key）排序，將所有數(shù)據(jù)溢出到臨時(shí)文件，同時(shí)清空數(shù)據(jù)結(jié)構(gòu)；重復(fù)前2個(gè)步驟，直到分片中所有的數(shù)據(jù)記錄都被處理；對(duì)所有臨時(shí)文件和內(nèi)存數(shù)據(jù)結(jié)構(gòu)中剩余的數(shù)據(jù)記錄做歸并排序，最終生成數(shù)據(jù)文件和索引文件。

在Reduce階段我們要注意，Reduce Task通過(guò)網(wǎng)絡(luò)拉取中間文件的過(guò)程，實(shí)際上就是不同Stages之間數(shù)據(jù)分發(fā)的過(guò)程。并且，Shuffle中數(shù)據(jù)分發(fā)的網(wǎng)絡(luò)開(kāi)銷，會(huì)隨著Map Task與Reduce Task的線性增長(zhǎng)，呈指數(shù)級(jí)爆炸。

最后，從硬件資源的角度來(lái)看，Shuffle對(duì)每一種硬件資源都非常地渴求，尤其是內(nèi)存、磁盤和網(wǎng)絡(luò)。由于不同硬件資源之間的處理延遲差異巨大，我們很難在Shuffle過(guò)程中平衡CPU、內(nèi)存、磁盤和網(wǎng)絡(luò)之間的計(jì)算開(kāi)銷。因此，對(duì)于Shuffle我們避之唯恐不及，要能省則省、能拖則拖。

groupbykey和reducebykey都有做shuffle，reduce還有做聚合。

內(nèi)存管理：

首先是內(nèi)存的管理方式。Spark區(qū)分堆內(nèi)內(nèi)存和堆外內(nèi)存：對(duì)于堆外內(nèi)存來(lái)說(shuō)，Spark通過(guò)調(diào)用Java Unsafe的allocateMemory和freeMemory方法，直接在操作系統(tǒng)內(nèi)存中申請(qǐng)、釋放內(nèi)存空間，管理成本較高；對(duì)于堆內(nèi)內(nèi)存來(lái)說(shuō)，無(wú)需Spark親自操刀而是由JVM代理。但頻繁的JVM GC對(duì)執(zhí)行性能來(lái)說(shuō)是一大隱患。另外，Spark對(duì)堆內(nèi)內(nèi)存占用的預(yù)估往往不夠精確，高估可用內(nèi)存往往會(huì)為OOM埋下隱患。

其次是統(tǒng)一內(nèi)存管理，以及Execution Memory和Storage Memory之間的搶占規(guī)則。它們就像黃四郎招租故事中黃小乙和張麻子的田地，搶占規(guī)則就像他們之間的占地協(xié)議，主要可以分為3條：

如果對(duì)方的內(nèi)存空間有空閑，那么雙方都可以搶占；對(duì)RDD緩存任務(wù)搶占的執(zhí)行內(nèi)存，當(dāng)執(zhí)行任務(wù)有內(nèi)存需要時(shí)，RDD緩存任務(wù)必須立即歸還搶占的內(nèi)存，其中涉及的RDD緩存數(shù)據(jù)要么落盤、要么清除；對(duì)分布式計(jì)算任務(wù)搶占的Storage Memory內(nèi)存空間，即便RDD緩存任務(wù)有收回內(nèi)存的需要，也要等到任務(wù)執(zhí)行完畢才能釋放。

最后是不同代碼對(duì)不同內(nèi)存區(qū)域的消耗。內(nèi)存區(qū)域分為Reserved Memory、User Memory、Execution Memory和Storage Memory。其中，Reserved Memory用于存儲(chǔ)Spark內(nèi)部對(duì)象，User Memory用于存儲(chǔ)用戶自定義的數(shù)據(jù)結(jié)構(gòu)，Execution Memory用于分布式任務(wù)執(zhí)行，而Storage Memory則用來(lái)容納RDD緩存和廣播變量。

小文件問(wèn)題：

原因：

1、數(shù)據(jù)源本身含大量小文件

2、動(dòng)態(tài)分區(qū)插入數(shù)據(jù)，沒(méi)有Shuffle的情況下，輸入端有多少個(gè)邏輯分片，對(duì)應(yīng)的HadoopRDD就會(huì)產(chǎn)生多少個(gè)HadoopPartition，每個(gè)Partition對(duì)應(yīng)于Spark作業(yè)的Task（個(gè)數(shù)為M），分區(qū)數(shù)為N。最好的情況就是（M=N） && （M中的數(shù)據(jù)也是根據(jù)N來(lái)預(yù)先打散的），那就剛好寫N個(gè)文件；最差的情況下，每個(gè)Task中都有各個(gè)分區(qū)的記錄，那文件數(shù)最終文件數(shù)將達(dá)到M * N個(gè)。這種情況下是極易產(chǎn)生小文件的。

3、動(dòng)態(tài)分區(qū)插入數(shù)據(jù)，有Shuffle的情況下，上面的M值就變成了spark.sql.shuffle.partitions(默認(rèn)值2000)這個(gè)參數(shù)值，文件數(shù)的算法和范圍和2中基本一致。

導(dǎo)致的問(wèn)題：

對(duì)于HDFS

從 NN（namenode) RPC請(qǐng)求角度，文件數(shù)越多，讀寫文件時(shí)，由于要和namenode進(jìn)行通信，在namenode壓力大且文件數(shù)過(guò)多時(shí)，會(huì)極大的消耗時(shí)間。

從 NN 元數(shù)據(jù)存儲(chǔ)角度，文件數(shù)越多，NN存儲(chǔ)的元數(shù)據(jù)就越大。

對(duì)于下游流程

下游流程，不論是MR、Hive還是Spark，在劃分分片（getSplits）的時(shí)候，都要從NN獲取文件信息。這個(gè)過(guò)程的耗時(shí)與文件數(shù)成正比，同時(shí)受NN壓力的影響。在NN壓力大，上游小文件多的情況下，下游的getSplits操作就會(huì)比較慢。

主要通過(guò)參數(shù)優(yōu)化：

階段1：map合并，發(fā)生在split操作，可以解決輸入小文件的合并（也可以解決只有map階段的輸出小文件合并），方式是把多個(gè)小文件合并成一個(gè)數(shù)據(jù)分片（split），進(jìn)而交給一個(gè)map task進(jìn)行計(jì)算。

階段2：reduce合并，發(fā)生在shuffle階段，可以解決輸出小文件的合并，方式是減少reduce task數(shù)量，減少小文件的形成

階段3：寫入hdfs之后，可以解決輸出小文件的合并，方式是額外啟動(dòng)一個(gè)job，根據(jù)用戶設(shè)置的閾值來(lái)合并已經(jīng)生成的小文件

執(zhí)行過(guò)程：

1、Spark SQL 任務(wù)執(zhí)行過(guò)程 Spark 完成一個(gè)數(shù)據(jù)生產(chǎn)任務(wù)（執(zhí)行一條 SQL ）的基本過(guò)程可以概括為語(yǔ)法樹(shù)解析-邏輯分析-語(yǔ)法優(yōu)化-計(jì)劃執(zhí)行。 （1）對(duì)SQL進(jìn)行語(yǔ)法分析，生成邏輯執(zhí)行計(jì)劃。 （2）從 Hive metastore server 獲取表信息，結(jié)合邏輯執(zhí)行計(jì)劃生成并優(yōu)化物理執(zhí)行計(jì)劃。 （3）根據(jù)物理執(zhí)行計(jì)劃向 Yarn 申請(qǐng)資源（executor），調(diào)度 task 到 executor 執(zhí)行。 （4）從 HDFS 讀取數(shù)據(jù)，任務(wù)執(zhí)行，任務(wù)執(zhí)行結(jié)束后將數(shù)據(jù)寫回 HDFS。

2、RDD、寬窄依賴

如上圖表示方框表示RDD，實(shí)心矩形表示分區(qū)（partitions）

1，窄依賴表示的是子RDD的分區(qū)只是到父RDD的分區(qū)（一對(duì)一）

2，寬依賴表示的是子RDD的分區(qū)到父RDD的多個(gè)分區(qū)（多對(duì)多），就會(huì)產(chǎn)生shuffer操作

調(diào)優(yōu)方法

自帶的：

CBO：意為基于代價(jià)優(yōu)化策略，它需要計(jì)算所有可能執(zhí)行計(jì)劃的代價(jià)，并挑選出代價(jià)最小的執(zhí)行計(jì)劃。

RBO：對(duì)數(shù)據(jù)是不敏感的，是基于規(guī)則的，比如謂詞下推、列剪枝。

HBO：基于歷史信息的優(yōu)化。

AQE：AQE是Spark SQL的一種動(dòng)態(tài)優(yōu)化機(jī)制，在運(yùn)行時(shí)，每當(dāng)Shuffle Map階段執(zhí)行完畢，AQE都會(huì)結(jié)合這個(gè)階段的統(tǒng)計(jì)信息，基于既定的規(guī)則動(dòng)態(tài)地調(diào)整、修正尚未執(zhí)行的邏輯計(jì)劃和物理計(jì)劃，來(lái)完成對(duì)原始查詢語(yǔ)句的運(yùn)行時(shí)優(yōu)化。

人為的：HiveSQL常用優(yōu)化方法全面總結(jié)_hive sql優(yōu)化-CSDN博客

https://www.cnblogs.com/0xcafedaddy/p/7614299.html

Hive調(diào)優(yōu)及優(yōu)化_hive 兩階段聚合-CSDN博客

KAFKA

FLINK

watermark水位機(jī)制：

ACK機(jī)制 ：將 Acker 開(kāi)啟后，如果下游某一個(gè) Bolt 處理失敗或超時(shí)未完成，上游會(huì)重發(fā)數(shù)據(jù)，以此保證數(shù)據(jù)至少被成功處理一次（至少一個(gè)相應(yīng)的 ACK 被接收），即 At Least Once 語(yǔ)義

檢查點(diǎn)機(jī)制 ：數(shù)據(jù)流中按照固定方式插入 barrier ，對(duì)于一個(gè) task ，每經(jīng)過(guò)一個(gè) barrier ，將創(chuàng)建檢查點(diǎn)，當(dāng)前的狀態(tài)會(huì)以快照的形式進(jìn)行存儲(chǔ)。當(dāng)發(fā)生處理失敗等情況時(shí)，會(huì)從上一個(gè)檢查點(diǎn)的快照開(kāi)始再次，將相應(yīng) barrier 后的數(shù)據(jù)再次處理。當(dāng)一個(gè) task 有多個(gè)輸入源時(shí)，來(lái)自不同輸入源的 barrier 未對(duì)齊，可能導(dǎo)致其中一些輸入源的數(shù)據(jù)被多次處理，即 At Least Once 語(yǔ)義；若進(jìn)行 barrier 對(duì)齊，則為 Exactly Once 語(yǔ)義。

DORIS

優(yōu)點(diǎn) 缺點(diǎn) 適用場(chǎng)景 Doris 1.同時(shí)支持 高并發(fā)點(diǎn)查詢和高吞吐的Ad-hoc查詢 2.同時(shí)支持 批量導(dǎo)入和近實(shí)時(shí)mini-batch導(dǎo)入 3.同時(shí)支持 明細(xì)和聚合查詢 4.兼容Mysql協(xié)議和標(biāo)準(zhǔn)SQL 5.支持Rollup Table 和Rollup Table的智能查詢路由 6.支持多表Join和靈活的表達(dá)式查詢 7.支持Schema 在線變更 8.支持和Hash和Range二級(jí)分區(qū) 1.Doris 目前不支持如?update?或?insert?等操作單條數(shù)據(jù)的 DML 語(yǔ)句 2.不支持實(shí)時(shí)導(dǎo)入 3.不支持精確去重的物化索引 4.RollUP表需要逐個(gè)手動(dòng)建立 1.Doris的聚合模型主要用于固定模式的報(bào)表類查詢場(chǎng)景，實(shí)現(xiàn)原理和Mesa完全一致 2.百毫秒的高性能OLAP查詢 4.大結(jié)果集查詢 5.明細(xì)查詢 Kylin

支持標(biāo)準(zhǔn)SQL，提供JDBC/ODBC接口 通過(guò)預(yù)計(jì)算Cube顯著降低查詢時(shí)的計(jì)算量，數(shù)據(jù)集越大效果越明顯 支持精確去重計(jì)數(shù)，并且由于預(yù)計(jì)算，查詢?nèi)ブ刂笜?biāo)的速度很快 可以支持比較高的查詢并發(fā)

需要學(xué)習(xí)Cube的定義和優(yōu)化，學(xué)習(xí)成本較高 SQL需要具有一定的結(jié)構(gòu)，不支持AdHoc查詢 HBase沒(méi)有二級(jí)索引，過(guò)濾的性能稍遜色 支持的維度數(shù)量不宜過(guò)多（一般不超過(guò)20個(gè)），否則Cube的計(jì)算和存儲(chǔ)開(kāi)銷會(huì)明顯增加 1.固化查詢：指標(biāo)提取、多維分析、dashboard等 2.查詢模式比較固定、SQL表達(dá) 3.數(shù)據(jù)規(guī)模大、指標(biāo)數(shù)量多、去重指標(biāo)要求精確 4.查詢并發(fā)度高對(duì)響應(yīng)時(shí)間要求比較嚴(yán)苛 Druid

支持實(shí)時(shí)攝入數(shù)據(jù)和離線導(dǎo)入數(shù)據(jù)，導(dǎo)入性能高 通過(guò)在攝入時(shí)輕度匯總數(shù)據(jù)，顯著減少查詢時(shí)需要處理的數(shù)據(jù)量 存儲(chǔ)格式采用列式存儲(chǔ)加位圖索引，加快過(guò)濾和聚合的速度 本地存儲(chǔ)數(shù)據(jù)文件，通過(guò)mmap將數(shù)據(jù)映射到內(nèi)存中處理，最大化利用內(nèi)存 可擴(kuò)展性和可用性高

沒(méi)有原生的SQL支持，查詢DSL有一定學(xué)習(xí)成本 只支持單數(shù)據(jù)源的查詢，接入前需要將數(shù)據(jù)提前join好 由于只存儲(chǔ)輕度匯總后的數(shù)據(jù)，不支持查詢明細(xì)數(shù)據(jù) 對(duì)內(nèi)存依賴較重，當(dāng)數(shù)據(jù)量明顯超過(guò)可用內(nèi)存時(shí)，性能嚴(yán)重下降 只支持基于HyperLogLog的近似去重計(jì)數(shù)（0.9.1.1提供了單維度精確去重計(jì)數(shù)的實(shí)驗(yàn)支持） 1.時(shí)序型數(shù)據(jù)的實(shí)時(shí)OLAP分析 2.不關(guān)心事件明細(xì) 3.數(shù)據(jù)產(chǎn)生速率快、原始數(shù)據(jù)量大 4.以簡(jiǎn)單指標(biāo)（sum/count/min/max）為主，去重指標(biāo)不多（1~2個(gè)）

柚子快報(bào)邀請(qǐng)碼778899分享：大數(shù)據(jù)知識(shí)框架

http://yzkb.51969.com/

相關(guān)文章