大資料數倉之報表開發

在大資料開發中，主要的資料分析目的可以分為2類。一類是基於歷史資料（就算是實時數倉，接收到資料的時候，其實也已經是歷史資料了）做資料規律或者結果提取；一類是基於歷史資料，訓練模型，做未來資料**或者分類等。

如果是前者，基於已有資料做資料規律和資料結果提取，這時候就可以稱之為報表開發。

參考神策系統，報表開發可以劃分固定維度報表開發，一定維度自由組合報表開發，自由維度報表開發。

固定維度報表開發，一般是一些固定指標，但會加一些固定維度，典型的如年，月，日等

一定維度內自定義組合分析

靈活自定義分析

從上述描述中可以看到，報表從資料維度和計算難度來看，可以分為3大類

固定報表，如果是脫機數倉場景，很多時候使用hive，或者spark，或者mapreduce程式，結合指令碼定時（一般是每天定時任務滾動計算）執行，就可以將這些指標計算出來。

注意，數倉一般會做分層處理，一般都是將原始資料處理後放入ods層，ods層資料處理之後放入dwd層，dws層結果一般從dwd計算而來。所以整個資料流是有先後順序的

一定維度內組合報表，也就是典型的cube。

with cube

grouping sets

roll up

但注意，這三個語法其實在實際開發中，維度過多時，實際使用並不友好。並且計算之後的結果還需要想辦法放到hbase或者mysql來方便外部的快速結果查詢

kylin是純粹的預計算框架，當設定好需要計算的cube，設定好需要計算的維度組合之後，結合kylin的rest api或者jdbc介面，可以讓kylin做每日滾動計算。kylin還會自己把計算後結果放入hbase中（hbase可以提供亞秒級別的資料訪問，不過需要基於rowkey或者索引查詢）；

druid 則有輕度預先聚合，對資料查詢也有加速效果

即席查詢要求有很強的計算效能，因為沒有做預計算或者預聚合，資料量大時，需要有很強的計算效能才能滿足即席查詢的秒級要求。

神策使用的方案是impala，但應對大量資料的計算，還是會受限於impala本身的限制。據說內部其實也做了很多優化，思路包括一定的預聚合和預計算等，所以神策在國內其實屬於領頭羊地位，屬於獨角獸

presto屬於後起之秀，雖然社群內劃分了2個分支，但不影響使用。presto的計算效能其實弱於impala，但結合presto的記憶體表，效能會有很大提公升，就是對記憶體占用以及資料體量會有一些要求。

並且，presto的社群活躍很多，版本迭代快速。有大公司支援，個人人為效能超越impala是預期內的事情。

大資料專案之數倉專案（一）數倉搭建

名稱版本 hadoop 3.1.3 flume 1.9.0 kafka 2.11 2.4.1 zookeeper 3.5.7 mysql 5.1.27 sqoop 1.4.6 spark 3.0.0 hive 3.1.2 本專案採用星型維度建模 1 配置sparkonhive 注意配置spark h...

大資料方案 數倉建設

基於阿里雲日誌服務實現，拉取阿里雲日誌到本地資料庫儲存。優點 實施速度快。缺點 依賴阿里雲日誌服務，擴充套件性和靈活性較差。前端 雲端 nginx等不同格式的日誌傳送到kafka訊息佇列，之後做etl資料清洗，之後可以使用storm做實時計算或使用hive spark streaming做離線批處理...

大資料之數倉平台設計思路01

對於大資料來說，數倉的作用不言而喻，承載著整個公司全業務線的資料，現階段，在hadoop上的數倉主要是用來解決企業內部資料的分析，尤其是各種各樣的統計分析報表。本文主要結合自己公司目前數倉的結構設計和現階段解決的問題而敘述和分享，如有不明，錯誤之處，各位看官可指出，非常感謝！下圖為數倉整體的技術架構...