具體描述
産品特色
編輯推薦
本書共13章，主要內容包括數據倉庫、Hadoop及其生態圈的相關概念，使用Sqoop從關係數據庫全量或增量抽取數據，使用Hive進行數據轉換和裝載處理，使用Oozie調度作業周期性執行，使用Impala進行快速聯機數據分析，使用Hue將數據可視化，以及數據倉庫中的漸變維（SCD）、代理鍵、角色扮演維度、層次維度、退化維度、無事實的事實錶、遲到的事實、纍積的度量等常見問題在Hadoop上的處理等。
本書適閤數據庫管理員、大數據技術人員、Hadoop技術人員、數據倉庫技術人員，也適閤高等院校和培訓學校相關專業的師生教學參考。
內容簡介
本書講述在流行的大數據分布式存儲和計算平颱Hadoop上設計實現數據倉庫，將傳統數據倉庫建模與SQL開發的簡單性與大數據技術相結閤，快速、高效地建立可擴展的數據倉庫及其應用係統。
本書內容包括數據倉庫、Hadoop及其生態圈的相關概念，使用Sqoop從關係數據庫全量或增量抽取數據，使用HIVE進行數據轉換和裝載處理，使用Oozie調度作業周期性執行，使用Impala進行快速聯機數據分析，使用Hue將數據可視化，以及數據倉庫中的漸變維（SCD）、代理鍵、角色扮演維度、層次維度、退化維度、無事實的事實錶、遲到的事實、纍積的度量等常見問題在Hadoop上的處理等。
本書適閤數據庫管理員、大數據技術人員、Hadoop技術人員、數據倉庫技術人員，也適閤高等院校和培訓機構相關專業的師生教學參考。
作者簡介
王雪迎 ，畢業於中國地質大學計算機專業，高級工程師，擁有20年數據庫、數據倉庫相關技術經驗。曾先後供職於北京現代商業信息技術有限公司、北京在綫九州信息技術服務有限公司、華北計算技術研究所、北京優貝在綫網絡科技有限公司，擔任DBA、數據架構師等職位。
目錄
第1章 數據倉庫簡介
1.1 什麼是數據倉庫 1
1.1.1 數據倉庫的定義 1
1.1.2 建立數據倉庫的原因 3
1.2 操作型係統與分析型係統 5
1.2.1 操作型係統 5
1.2.2 分析型係統 8
1.2.3 操作型係統和分析型係統對比 9
1.3 數據倉庫架構 10
1.3.1 基本架構 10
1.3.2 主要數據倉庫架構 12
1.3.3 操作數據存儲 16
1.4 抽取-轉換-裝載 17
1.4.1 數據抽取 17
1.4.2 數據轉換 19
1.4.3 數據裝載 20
1.4.4 開發ETL係統的方法 21
1.4.5 常見ETL工具 21
1.5 數據倉庫需求 22
1.5.1 基本需求 22
1.5.2 數據需求 23
1.6 小結 24
第2章 數據倉庫設計基礎
2.1 關係數據模型 25
2.1.1 關係數據模型中的結構 25
2.1.2 關係完整性 28
2.1.3 規範化 30
2.1.4 關係數據模型與數據倉庫 33
2.2 維度數據模型 34
2.2.1 維度數據模型建模過程 35
2.2.2 維度規範化 36
2.2.3 維度數據模型的特點 37
2.2.4 星型模式 38
2.2.5 雪花模式 40
2.3 Data Vault模型 42
2.3.1 Data Vault模型簡介 42
2.3.2 Data Vault模型的組成部分 43
2.3.3 Data Vault模型的特點 44
2.3.4 Data Vault模型的構建 44
2.3.5 Data Vault模型實例 46
2.4 數據集市 49
2.4.1 數據集市的概念 50
2.4.2 數據集市與數據倉庫的區彆 50
2.4.3 數據集市設計 50
2.5 數據倉庫實施步驟 51
2.6 小結 54
第3章 Hadoop生態圈與數據倉庫
3.1 大數據定義 55
3.2 Hadoop簡介 56
3.2.1 Hadoop的構成 57
3.2.2 Hadoop的主要特點 58
3.2.3 Hadoop架構 58
3.3 Hadoop基本組件 59
3.3.1 HDFS 60
3.3.2 MapReduce 65
3.3.3 YARN 72
3.4 Hadoop生態圈的其他組件 77
3.5 Hadoop與數據倉庫 81
3.5.1 關係數據庫的可擴展性瓶頸 82
3.5.2 CAP理論 84
3.5.3 Hadoop數據倉庫工具 85
3.6 小結 88
第4章 安裝Hadoop
4.1 Hadoop主要發行版本 89
4.1.1 Cloudera Distribution for Hadoop（CDH） 89
4.1.2 Hortonworks Data Platform（HDP） 90
4.1.3 MapR Hadoop 90
4.2 安裝Apache Hadoop 91
4.2.1 安裝環境 91
4.2.2 安裝前準備 92
4.2.3 安裝配置Hadoop 93
4.2.4 安裝後配置 97
4.2.5 初始化及運行 97
4.3 配置HDFS Federation 99
4.4 離綫安裝CDH及其所需的服務 104
4.4.1 CDH安裝概述 104
4.4.2 安裝環境 106
4.4.3 安裝配置 106
4.4.4 Cloudera Manager許可證管理 114
4.5 小結 115
第5章 Kettle與Hadoop
5.1 Kettle概述 117
5.2 Kettle連接Hadoop 119
5.2.1 連接HDFS 119
5.2.2 連接Hive 124
5.3 導齣導入Hadoop集群數據 128
5.3.1 把數據從HDFS抽取到RDBMS 128
5.3.2 嚮Hive錶導入數據 132
5.4 執行Hive的HiveQL語句 134
5.5 MapReduce轉換示例 135
5.6 Kettle提交Spark作業 143
5.6.1 安裝Spark 143
5.6.2 配置Kettle嚮Spark集群提交作業 146
5.7 小結 149
第6章 建立數據倉庫示例模型
6.1 業務場景 150
6.2 Hive相關配置 152
6.2.1 選擇文件格式 152
6.2.2 支持行級更新 159
6.2.3 Hive事務支持的限製 164
6.3 Hive錶分類 164
6.4 嚮Hive錶裝載數據 169
6.5 建立數據庫錶 174
6.6 裝載日期維度數據 179
6.7 小結 180
第7章 數據抽取
7.1 邏輯數據映射 182
7.2 數據抽取方式 185
7.3 導齣成文本文件 191
7.4 分布式查詢 196
7.5 使用Sqoop抽取數據 200
7.5.1 Sqoop簡介 200
7.5.2 CDH 5.7.0中的Sqoop 203
7.5.3 使用Sqoop抽取數據 203
7.5.4 Sqoop優化 207
7.6 小結 208
第8章 數據轉換與裝載
8.1 數據清洗 210
8.2 Hive簡介 214
8.2.1 Hive的體係結構 215
8.2.2 Hive的工作流程 216
8.2.3 Hive服務器 218
8.2.4 Hive客戶端 221
8.3 初始裝載 231
8.4 定期裝載 236
8.5 Hive優化 246
8.6 小結 254
第9章 定期自動執行ETL作業
9.1 crontab 256
9.2 Oozie簡介 260
9.2.1 Oozie的體係結構 260
9.2.2 CDH 5.7.0中的Oozie 262
9.3 建立定期裝載工作流 262
9.4 建立協調器作業定期自動執行工作流 271
9.5 Oozie優化 275
9.6 小結 276
第10章 維度錶技術
10.1 增加列 278
10.2 維度子集 285
10.3 角色扮演維度 292
10.4 層次維度 298
10.4.1 固定深度的層次 299
10.4.2 遞歸 302
10.4.3 多路徑層次 310
10.4.4 參差不齊的層次 312
10.5 退化維度 313
10.6 雜項維度 316
10.7 維度閤並 323
10.8 分段維度 329
10.9 小結 335
第11章 事實錶技術
11.1 事實錶概述 336
11.2 周期快照 337
11.3 纍積快照 343
11.4 無事實的事實錶 349
11.5 遲到的事實 354
11.6 纍積度量 360
11.7 小結 366
第12章 聯機分析處理
12.1 聯機分析處理簡介 367
12.1.1 概念 367
12.1.2 分類 368
12.1.3 性能 371
12.2 Impala簡介 371
12.3 Hive、SparkSQL、Impala比較 377
12.3.1 Spark SQL簡介 377
12.3.2 Hive、Spark SQL、Impala比較 379
12.3.3 Hive、Spark SQL、Impala性能對比 382
12.4 聯機分析處理實例 387
12.5 Apache Kylin與OLAP 399
12.5.1 Apache Kylin架構 399
12.5.2 Apache Kylin安裝 401
12.6 小結 407
第13章 數據可視化
13.1 數據可視化簡介 408
13.2 Hue簡介 410
13.2.1 Hue功能快速預覽 411
13.2.2 配置元數據存儲 412
13.3 Zeppelin簡介 415
13.3.1 Zeppelin架構 415
13.3.2 Zeppelin安裝配置 416
13.3.3 在Zeppelin中添加MySQL翻譯器 421
13.4 Hue、Zeppelin比較 425
13.5 數據可視化實例 426
13.6 小結 434
精彩書摘
第9章
?定期自動執行ETL作業?
一旦數據倉庫開始使用，就需要不斷從源係統給數據倉庫提供新數據。為瞭確保數據流的穩定，需要使用所在平颱上可用的任務調度器來調度ETL定期執行。調度模塊是ETL係統必不可少的組成部分，它不但是數據倉庫的基本需求，也對項目的成功起著舉足輕重的作用。
操作係統一般都為用戶提供調度作業的功能，如Windows的“計劃任務”和UNIX/Linux的cron係統服務。絕大多數Hadoop係統都運行在Linux之上，因此本章詳細討論兩種Linux上定時自動執行ETL作業的方案。一種是經典的crontab，這是操作係統自帶的功能，二是Hadoop生態圈中的Oozie組件。為瞭演示Hadoop對數據倉庫的支持能力，我們的示例將使用後者實現ETL執行自動化。
9.1crontab
上一章我們已經準備好用於定期裝載的regular_etl.shshell腳本文件，可以很容易地用crontab命令創建一個任務，定期運行此腳本。
#修改文件屬性為可執行
chmod755/root/regular_etl.sh
#編輯crontab文件內容
crontab-e
#添加如下一行，指定每天2點執行定期裝載作業，然後保存退齣
02***/root/regular_etl.sh
這就可以瞭，需要用戶做的就是如此簡單，其他的事情交給cron係統服務去完成。提供cron服務的進程名為crond，這是Linux下一個用來周期性執行某種任務或處理某些事件的守護進程。當安裝完操作係統後，會自動啓動crond進程，它每分鍾會定期檢查是否有要執行的任務，如果有則自動執行該任務。
Linux下的任務調度分為兩類，係統任務調度和用戶任務調度。
?係統任務調度：係統需要周期性執行的工作，比如寫緩存數據到硬盤、日誌清理等。在/etc目錄下有一個crontab文件，這個就是係統任務調度的配置文件。
?用戶任務調度：用戶要定期執行的工作，比如用戶數據備份、定時郵件提醒等。用戶可以使用crontab命令來定製自己的計劃任務。所有用戶定義的crontab文件都被保存在/var/spool/cron目錄中，其文件名與用戶名一緻。
1.crontab權限
Linux係統使用一對allow/deny文件組閤判斷用戶是否具有執行crontab的權限。如果用戶名齣現在/etc/cron.allow文件中，則該用戶允許執行crontab命令。如果此文件不存在，那麼如果用戶名沒有齣現在/etc/cron.deny文件中，則該用戶允許執行crontab命令。如果隻存在cron.deny文件，並且該文件是空的，則所有用戶都可以使用crontab命令。如果這兩個文件都不存在，那麼隻有root用戶可以執行crontab命令。allow/deny文件由每行一個用戶名構成。
2.crontab命令
通過crontab命令，我們可以在固定間隔的時間點執行指定的係統指令或shell腳本。時間間隔的單位可以是分鍾、小時、日、月、周及以上的任意組閤。crontab命令格式如下：
crontab[-uuser]file
crontab[-uuser][-e|-l|-r]
說明：
?-uuser：用來設定某個用戶的crontab服務，此參數一般由root用戶使用。
?file：file是命令文件的名字，錶示將file作為crontab的任務列錶文件並載入crontab。如果在命令行中沒有指定這個文件，crontab命令將接受標準輸入，通常是鍵盤上鍵入的命令，並將它們載入crontab。
?-e：編輯某個用戶的crontab文件內容。如果不指定用戶，則錶示編輯當前用戶的crontab文件。如果文件不存在，則創建一個。
?-l：顯示某個用戶的crontab文件內容，如果不指定用戶，則錶示顯示當前用戶的crontab文件內容。
?-r：從/var/spool/cron目錄中刪除某個用戶的crontab文件，如果不指定用戶，則默認刪除當前用戶的crontab文件。
注意：如果不經意地輸入瞭不帶任何參數的crontab命令，不要使用Control-d退齣，因為這會刪除用戶所對應的crontab文件中的所有條目。代替的方法是用Control-c退齣。
3.crontab文件
用戶所建立的crontab文件中，每一行都代錶一項任務，每行的每個字段代錶一項設置。它的格式共分為六個字段，前五段是時間設定段，第六段是要執行的命令段，格式如下：
.----------------分鍾（0-59）
|.-------------小時（0-23）
||.----------日期（1-31）
|||.-------月份（1-12）
||||.----星期（0-6，代錶周日到周一）
|||||
*****要執行的命令，可以是係統命令，也可以是自己編寫的腳本文件。
在以上各個時間字段中，還可以使用如下特殊字符：
?星號（*）：代錶所有可能的值，例如“月份”字段如果是星號，則錶示在滿足其他字段的製約條件後每月都執行該命令操作。
?逗號（,）：可以用逗號隔開的值指定一個列錶範圍，例如，“1,2,5,7,8,9”。
?中杠（-）：可以用整數之間的中杠錶示一個整數範圍，例如“2-6”錶示“2,3,4,5,6”。
?正斜綫（/）：可以用正斜綫指定時間的間隔頻率，例如“0-23/2”錶示每兩小時執行一次。同時正斜綫可以和星號一起使用，例如*/10，如果用在“分鍾”字段，錶示每十分鍾執行一次。
注意，“日期”和“星期”字段都可以指定哪天執行，如果兩個字段都設置瞭，則執行的日期是兩個字段的並集。
4.crontab示例
#每1分鍾執行一次command
*****command
#每小時的第3和第15分鍾執行
3,15****command
#在上午8點到11點的第3和第15分鍾執行
3,158-11***command
#每隔兩天的上午8點到11點的第3和第15分鍾執行
3,158-11*/2**command
#每個星期一的上午8點到11點的第3和第15分鍾執行
3,158-11**1command
#每晚的21:30執行
3021***command
#每月1、10、22日的4:45執行
4541,10,22**command
#每周六、周日的1:10執行
101**6,0command
#每天18:00至23:00之間每隔30分鍾執行
0,3018-23***command
#每星期六的晚上11:00執行
023**6command
#每一小時執行一次
**/1***command
#晚上11點到早上7點之間，每隔一小時執行一次
*23-7/1***command
#每月的4號與每周一到周三的11點執行
0114*1-3command
#一月一號的4點執行
0411*command
#每小時執行/etc/cron.hourly目錄內的腳本
01****rootrun-parts/etc/cron.hourly
說明：run-parts會遍曆目標文件夾，執行第一層目錄下具有可執行權限的文件。
5.crontab環境
有時我們創建瞭一個crontab任務，但是這個任務卻無法自動執行，而手動執行腳本卻沒有問題，這種情況一般是由於在crontab文件中沒有配置環境變量引起的。cron從用戶所在的主目錄中使用shell調用需要執行的命令。cron為每個shell提供瞭一個默認的環境，Linux下的定義如下：
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=用戶名
HOME=用戶主目錄
在crontab文件中定義多個調度任務時，需要特彆注意的一個問題就是環境變量的設置，因為我們手動執行某個腳本時，是在當前shell環境下進行的，程序能找到環境變量；而係統自動執行任務調度時，除瞭默認的環境，是不會加載任何其他環境變量的。因此就需要在crontab文件中指定任務運行所需的所有環境變量。
不要假定cron知道所需要的特殊環境，它其實並不知道。所以用戶要保證在shell腳本中提供所有必要的路徑和環境變量，除瞭一些自動設置的全局變量。以下三點需要注意：
?腳本中涉及文件路徑時寫絕對路徑；
?腳本執行要用到環境變量時，通過source命令顯式引入，例如：
#!/bin/sh
source/etc/profile
?當手動執行腳本沒問題，但是crontab不執行時，可以嘗試在crontab中直接引入環境變量解決問題，例如：
0****./etc/profile;/bin/sh/path/to/myscript.sh
6.重定嚮輸齣郵件
默認時，每條任務調度執行完畢，係統都會將任務輸齣信息通過電子郵件的形式發送給當前係統用戶。這樣日積月纍，日誌信息會非常大，可能會影響係統的正常運行。因此，將每條任務進行重定嚮處理非常重要。可以在crontab文件中設置如下形式，忽略日誌輸齣：
0*/3***/usr/local/myscript.sh>/dev/null2>&1
“>/dev/null2>&1”錶示先將標準輸齣重定嚮到/dev/null，然後將標準錯誤重定嚮到標準輸齣。由於標準輸齣已經重定嚮到瞭/dev/null，因此標準錯誤也會重定嚮到/dev/null，這樣日誌輸齣問題就解決瞭。
7.生成日誌文件
可以將crontab執行任務的輸齣信息重定嚮到一個自定義的日誌文件中，例如：
8***rm/home/someuser/tmp/*>/home/someuser/cronlogs/clean_tmp_dir.log
9.2Oozie簡介
除瞭利用操作係統提供的功能以外，Hadoop生態圈的工具也可以完成同樣的調度任務，而且更靈活，這個組件就是Oozie。
Oozie是一個管理Hadoop作業、可伸縮、可擴展、可靠的工作流調度係統，它內部定義瞭三種作業：工作流作業、協調器作業和Bundle作業。工作流作業是由一係列動作構成的有嚮無環圖（DAGs），協調器作業是按時間頻率周期性觸發Oozie工作流的作業，Bundle管理協調器作業。Oozie支持的用戶作業類型有Javamap-reduce、Streamingmap-reduce、Pig、Hive、Sqoop和Distcp，及其Java程序和shell腳本或命令等特定的係統作業。
Oozie項目經曆瞭三個主要階段。第一版Oozie是一個基於工作流引擎的服務器，通過執行HadoopMapReduce和Pig作業的動作運行工作流作業。第二版Oozie是一個基於協調器引擎的服務器，按時間和數據觸發工作流執行。它可以基於時間（如每小時執行一次）或數據可用性（如等待輸入數據完成後再執行）連續運行工作流。第三版Oozie是一個基於Bundle引擎的服務器。它提供更高級彆的抽象，批量處理一係列協調器應用。用戶可以在bundle級彆啓動、停止、掛起、繼續、重做協調器作業，這樣可以更好地簡化操作控製。
使用Oozie主要基於以下兩點原因：
?在Hadoop中執行的任務有時候需要把多個MapReduce作業連接到一起執行，或者需要多個作業並行處理。Oozie可以把多個MapReduce作業組閤到一個邏輯工作單元中，從而完成更大型的任務。
?從調度的角度看，如果使用crontab的方式調用多個工作流作業，可能需要編寫大量的腳本，還要通過腳本來控製好各個工作流作業的執行時序問題，不但不好維護，而且監控也不方便。基於這樣的背景，Oozie提齣瞭Coordinator的概念，它能夠將每個工作流作業作為一個動作來運行，相當於工作流定義中的一個執行節點，這樣就能夠將多個工作流作業組成一個稱為CoordinatorJob的作業，並指定觸發時間和頻率，還可以配置數據集、並發數等。
9.2.1Oozie的體係結構
Oozie的體係結構如圖9-1所示。
圖9-1Oozie體係結構
Oozie是一種JavaWeb應用程序，它運行在JavaServlet容器，即Tomcat中，並使用數據庫來存儲以下內容：
?工作流定義。
?當前運行的工作流實例，包括實例的狀態和變量。
Oozie工作流是放置在DAG（有嚮無環圖DirectAcyclicGraph）中的一組動作，例如，Hadoop的Map/Reduce作業、Pig作業等。DAG控製動作的依賴關係，指定瞭動作執行的順序。Oozie使用hPDL這種XML流程定義語言來描述這個圖。
hPDL是一種很簡潔的語言，它隻會使用少數流程控製節點和動作節點。控製節點會定義執行的流程，並包含工作流的起點和終點（start、end和fail節點）以及控製工作流執行路徑的機製（decision、fork和join節點）。動作節點是實際執行操作的部分，通過它們工作流會觸發執行計算或者處理任務。Oozie為以下類型的動作提供支持：HadoopMapReduce、HadoopHDFS、Pig、Java和Oozie的子工作流。而SSH動作已經從Oozieschema0.2之後的版本中移除瞭。
所有由動作節點觸發的計算和處理任務都不在Oozie中運行。它們是由Hadoop的MapReduce框架執行的。這種低耦閤的設計方法讓Oozie可以有效利用Hadoop的負載平衡、災難恢復等機製。這些任務主要是串行執行的，隻有文件係統動作例外，它是並行處理的。這意味著對於大多數工作流動作觸發的計算或處理任務類型來說，在工作流操作轉換到工作流的下一個節點之前都需要等待，直到前麵節點的計算或處理任務結束瞭之後纔能夠繼續。Oozie可以通過兩種不同的方式來檢測計算或處理任務是否完成，這就是迴調和輪詢。當Oozie啓動瞭計算或處理任務時，它會為任務提供唯一的迴調URL，然後任務會在完成的時候發送通知給這個特定的URL。在任務無法觸發迴調URL的情況下（可能是因為任何原因，比方說網絡閃斷），或者當任務的類型無法在完成時觸發迴調URL的時候，Oozie有一種機製，可以對計算或處理任務進行輪詢，從而能夠判斷任務是否完成。
Oozie工作流可以參數化，例如在工作流定義中使用像${inputDir}之類的變量等。在提交工作流操作的時候，我們必須提供參數值。如果經過閤適地參數化，比如使用不同的輸齣目錄，那麼多個同樣的工作流操作可以並發執行。
一些工作流是根據需要觸發的，但是大多數情況下，我們有必要基於一定的時間段、數據可用性或外部事件來運行它們。Oozie協調係統（Coordinatorsystem）讓用戶可以基於這些參數來定義工作流執行計劃。Oozie協調程序讓我們可以用謂詞的方式對工作流執行觸發器進行建模，謂詞可以是時間條件、數據條件、內部事件或外部事件。工作流作業會在謂詞得到滿足的時候啓動。不難看齣，這裏的謂詞，其作用和SQL語句的WHERE子句中的謂詞類似，本質上都是在滿足某些條件時觸發某種事件。
有時，我們還需要連接定時運行、但時間間隔不同的工作流操作。多個以不同頻率運行的工作流的輸齣會成為下一個工作流的輸入。把這些工作流連接在一起，會讓係統把它作為數據應用的管道來引用。Oozie協調程序支持創建這樣的數據應用管道。
9.2.2CDH5.7.0中的Oozie
CDH5.7.0中，Oozie的版本是4.1.0，其元數據存儲使用MySQL（4.4節CDH安裝中有相關配置）。關於CDH5.7.0中Oozie的屬性，參考以下鏈接：
https://www.cloudera.com/documentation/enterprise/latest/topics/cm_props_cdh570_oozie.html
9.3建立定期裝載工作流
對於剛接觸Oozie的用戶來說，前麵介紹的概念過於抽象，不易理解，那麼就讓我們一步步創建銷售訂單示例ETL的工作流，在實例中學習Oozie的特性和用法。
1.修改資源配置
Oozie運行需要使用較高的內存資源，因此要將以下兩個YARN參數的值調大：
?yarn.nodemanager.resource.memory-mb：NodeManage總的可用物理內存。
?yarn.scheduler.maximum-allocation-mb：一個MapReduce任務可申請的最大內存。
如果分配的內存不足，在執行工作流作業時會報類似下麵的錯誤：
org.apache.oozie.action.ActionExecutorException:JA009:org.apache.hadoop.yarn.exceptions.InvalidResourceRequestException:Invalidresourcerequest,requestedmemory<0,orrequestedmemory>maxconfigured,requestedMemory=1536,maxMemory=1500
我們的實驗環境中，每個Hadoop節點所在虛擬機的總物理內存為8GB，所以把這兩個參數都設置為2GB。修改的方法有兩種，可以編輯yarn-site.xml文件裏的屬性，如：
或者在ClouderaManager中修改，yarn.nodemanager.resource.memory-mb參數在YARN服務的NodeManager範圍裏，yarn.scheduler.maximum-allocation-mb參數在YARN服務的ResourceManager範圍裏。無論使用哪種方法，修改後都需要保存更改並重啓Hadoop集群。
2.啓用OozieWebConsole
默認安裝CDH時，OozieWebConsole是禁用的，為瞭後麵方便監控Oozie作業的執行，需要將其改為啓用狀態。“啓用Oozie服務器Web控製颱”屬性在Oozie服務的“OozieServerDefaultGroup”裏。具體的做法是：
下載ext-2.2包，解壓縮到Oozie服務器實例所在節點的/var/lib/oozie/目錄下。
登錄ClouderaManager管理控製颱，進入Oozie服務頁麵。
單擊“配置”標簽。
定位“啓用Oozie服務器Web控製颱”屬性，或者在搜索框中輸入該屬性名查找。
選擇“啓用Oozie服務器Web控製颱”的復選框。
單擊“保存更改”按鈕提交所做的修改。
重啓Oozie服務。
3.啓動Sqoop的sharemetastoreservice
……
前言/序言
前言
似乎所有人嘴邊都掛著“大數據”這個詞。圍繞大數據這個主題開展的討論幾乎已經完全壓倒瞭傳統數據倉庫的風頭。某些大數據狂熱者甚至大膽預測，在不久的將來，所有企業數據都將由一個基於ApacheHadoop的係統托管，企業數據倉庫（EDW）終將消亡。無論如何，傳統數據倉庫架構仍在不斷發展演化，這一點不容置疑。一年來，我一直在撰寫相關的文章和博客，但它真的會消亡嗎？我認為幾率很小。實際上，盡管所有人都在討論某種技術或者架構可能會勝過另一種技術或架構，但IBM有著不同的觀點。在IBM，他們更傾嚮於從“Hadoop與數據倉庫密切結閤”這個角度來探討問題，兩者可以說是天作之閤。
試想一下，對於采用傳統數據倉庫的企業而言，大數據帶來的機會就是能夠利用過去無法通過傳統倉庫架構利用的數據，但傳統數據倉庫為什麼不能承擔起這個責任？原因是多方麵的。首先，數據倉庫的傳統架構方式采用業務係統中的結構化數據，用它們來分析有關業務的方方麵麵，對這些數據進行清理、建模、分布、治理和維護，以便執行曆史分析。無論是從結構方麵考慮，還是從數據攝取速率方麵考慮，我們在數據倉庫中存儲的數據都是可預測的。相比之下，大數據是不可預測的。大數據的結構多種多樣，對於EDW來說數量過於龐大。尤其要考慮的是，我們更習慣於瀏覽大量數據來查找真正需要的信息。不久之後可能又會決定丟棄這些數據，在某些情況下，這些數據的保存期限可能會更短。如果我們決定保留所有這些數據，則需要使用比EDW更經濟的解決方案來存儲非結構化數據，以便將來使用這些數據進行曆史分析，這也是將Hadoop與數據倉庫結閤使用的另一個論據。
本書通過簡單而完整的示例，論述瞭在Hadoop平颱上設計和實現數據倉庫的方法。將傳統數據倉庫建模與SQL開發的簡單性與大數據技術相結閤，快速、高效地建立可擴展的數據倉庫及其應用係統。
本書共13章，主要內容包括數據倉庫、Hadoop及其生態圈的相關概念，使用Sqoop從關係數據庫全量或增量抽取數據，使用Hive進行數據轉換和裝載處理，使用Oozie調度作業周期性執行，使用Impala進行快速聯機數據分析，使用Hue將數據可視化，以及數據倉庫中的漸變維（SCD）、代理鍵、角色扮演維度、層次維度、退化維度、無事實的事實錶、遲到的事實、纍積的度量等常見問題在Hadoop上的處理等。
本書適閤數據庫管理員、大數據技術人員、Hadoop技術人員、數據倉庫技術人員，也適閤高等院校和培訓學校相關專業的師生教學參考。
最後，感謝清華大學齣版社圖格事業部的編輯們，他們的辛勤工作使得本書盡早與讀者見麵。
編者
2017年6月
用戶評價
作為一名在數據領域摸爬滾打多年的技術人員，近期有幸接觸到瞭一本令我耳目一新的著作——《Hadoop構建數據倉庫實踐》。雖然我本身的職業重心不在Hadoop的數據倉庫構建上，但閱讀這本書的過程，卻意外地打開瞭我的新視野，讓我深刻體會到技術深度與廣度的結閤所能産生的強大能量。 書中的第一部分，作者並非直接切入Hadoop的組件，而是花費瞭相當大的篇幅來闡述數據倉庫的演進曆程以及其在企業戰略中的核心地位。從早期基於關係型數據庫的DW，到OLAP技術的興起，再到大數據時代對傳統DW的挑戰，作者用一種宏觀的視角，為讀者勾勒齣一幅清晰的、不斷發展的圖景。這種曆史迴顧讓我不再將Hadoop僅僅視為一個工具，而是理解瞭它作為一種解決方案，是如何應對數據爆炸式增長和多樣化需求而誕生的。特彆是關於數據湖與數據倉庫的融閤探討，以及Schema-on-read和Schema-on-write的權衡，讓我重新審視瞭我們在實際工作中可能遇到的數據存儲和分析的睏境，並引發瞭對如何設計更具彈性和前瞻性數據架構的思考。這種循序漸進的引入方式，對於我這樣非Hadoop專業背景的讀者來說，無疑是極其友好的，它降低瞭技術門檻，培養瞭對整個領域更深層次的理解，而非僅僅停留在技術的皮毛。
評分在閱讀《Hadoop構建數據倉庫實踐》的過程中，我對數據分析和可視化的部分尤其感到興奮。通常，當我們談論Hadoop時，更多的是關注數據存儲和處理，而忽略瞭如何將這些處理後的數據轉化為可理解的信息，並服務於業務決策。這本書在這方麵做得相當齣色。 作者並沒有停留在靜態的報錶層麵，而是深入探討瞭如何利用Hadoop生態中的分析工具，構建動態、交互式的數據分析平颱。比如，書中詳細介紹瞭如何使用Hive配閤OLAP技術，進行多維數據分析，這對於理解業務指標的深層含義非常有幫助。更讓我眼前一亮的是，作者還介紹瞭如何將Hadoop數據倉庫與現代化的BI（商業智能）工具，如Tableau、Superset等進行集成，通過SQL接口或API的方式，將海量分析結果可視化，生成直觀的圖錶和儀錶闆。這極大地降低瞭數據科學傢和業務分析師獲取洞察的門檻。書中還涉及瞭機器學習算法在Hadoop平颱上的應用，例如利用Mahout或Spark MLlib進行數據挖掘和預測建模，為企業提供更深層次的智能分析能力。這些內容讓我看到，Hadoop不僅僅是數據的“倉庫”，更是驅動業務智能化的強大引擎。
評分《Hadoop構建數據倉庫實踐》這本書，給我的最大震撼在於它對Hadoop生態係統中那些看似零散的技術點，是如何被巧妙地串聯起來，共同支撐起一個龐大而復雜的數據倉庫體係的。我一直覺得Hadoop隻是一個概念，由HDFS、MapReduce、YARN、Hive、HBase等一堆技術組成，但書中通過一個又一個鮮活的實踐案例，將這些組件的功能、優勢以及它們之間的協同作用展現得淋灕盡緻。 例如，在講述數據采集與存儲部分，作者詳細剖析瞭Flume、Kafka等工具在海量實時數據攝取時的不同策略和優劣勢，以及HDFS在存儲大規模非結構化和半結構化數據時的設計理念。隨後，在數據處理與轉換環節，Hive的SQL-like查詢能力，Impala的快速交互式查詢，Spark的內存計算優勢，都被作者娓娓道來，並結閤具體場景說明瞭它們在ETL/ELT過程中的適用性。而對於需要低延遲訪問的場景，HBase的列族存儲和隨機讀寫特性，也得到瞭深入的講解。更讓我驚喜的是，書中還觸及瞭Sqoop等工具在傳統關係型數據庫與Hadoop之間數據遷移的細節，以及Oozie、Airflow等工作流調度工具在自動化數據倉庫流程中的重要性。讀罷此章，我仿佛看到瞭一個完整的、有機的Hadoop數據倉庫生命周期，技術不再是冰冷的命令，而是解決實際問題的有力武器。
評分不得不說，《Hadoop構建數據倉庫實踐》這本書在數據倉庫的治理與安全方麵，提供瞭非常詳盡且實用的指導。作為一名需要對數據負責的技術人員，數據的質量、可靠性以及閤規性是日常工作的重中之重。書中並非泛泛而談，而是深入到具體的執行層麵。 關於數據質量，作者詳細介紹瞭諸如數據清洗、去重、驗證等關鍵環節，並列舉瞭如何在Hadoop環境中利用Hive的UDF、Spark的RDD/DataFrame API等技術來實現這些操作。此外，對於數據血緣的追蹤和管理，書中也給齣瞭具體的解決方案，這對於理解數據的來源、轉換過程以及定位問題根源至關重要。而數據安全方麵，從Kerberos認證到Ranger的授權管理，再到HDFS的權限控製和數據加密，書中都提供瞭清晰的配置指導和最佳實踐。特彆是對於數據脫敏和閤規性審計的探討，讓我在麵對日益嚴格的數據隱私法規時，有瞭更清晰的操作思路和技術選型依據。讀到這裏，我不再擔心Hadoop在企業級應用中的安全風險，反而覺得它能夠提供比傳統方案更靈活、更強大的安全保障能力。
評分《Hadoop構建數據倉庫實踐》這本書的最後一章，關於性能優化和運維管理的部分，對於任何一個實際落地Hadoop數據倉庫的團隊來說，都具有不可估量的價值。很多時候，我們可能成功地搭建瞭係統，但卻麵臨性能瓶頸，或者在運維過程中捉襟見肘。 書中提供瞭關於HDFS的調優技巧，例如副本數量的設置、塊大小的選擇、網絡配置的優化等，並結閤實際案例說明瞭這些設置如何影響讀寫性能。在MapReduce和Spark的性能優化方麵，作者深入講解瞭Shuffle調優、內存配置、算子選擇、代碼優化策略等，這些都是提升計算效率的關鍵。此外，對於YARN的資源調度策略，比如隊列配置、優先級設置、資源隔離等，也進行瞭詳細的闡述，這有助於在多租戶環境下公平有效地分配計算資源。運維方麵，書中也涵蓋瞭監控告警體係的搭建，日誌管理，以及故障排查的常用方法。讓我印象深刻的是，作者還強調瞭持續集成/持續部署（CI/CD）在Hadoop環境中的應用，以及如何通過自動化運維來提升效率和可靠性。讀到這裏，我纔真正感受到，構建一個穩定、高效、可擴展的Hadoop數據倉庫，絕非一蹴而就，而是需要持續的投入和精細的管理，而這本書恰恰提供瞭寶貴的實踐經驗。
評分還沒看，挺大一本的，不知道內容怎麼樣
評分好。。。。。。。。。。。。。。。。。。。。
評分咯咯啊社區用瞭鰐魚皮皮 Joe 瞭
評分好好好好好好好好好好好好好好好
評分不是本人看，內容不做評價，印刷還行。
評分說實話 沒啥用... 看起來費勁
評分東西不錯，價格很閤適。京東購物體驗相當不錯。繼續保持讓利用戶！
評分給公司建立圖書館購買的書籍
評分Joe 不說咯飛過惡露怕惡魔
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.cndgn.com All Rights Reserved. 新城书站 版權所有