hive源碼編譯
Ⅰ hive的安裝配置
你可以下載一個已打包好的hive穩定版,也可以下載源碼自己build一個版本。
安裝需要 java 1.6,java 1.7或更高版本。 Hadoop 2.x或更高, 1.x. Hive 0.13 版本也支持 0.20.x, 0.23.x linux,mac,windows操作系統。以下內容適用於linux系統。 安裝打包好的hive
需要先到apache下載已打包好的hive鏡像,然後解壓開該文件 $tar-xzvfhive-x.y.z.tar.gz設置hive環境變數 $cdhive-x.y.z$exportHIVE_HOME={{pwd}}設置hive運行路徑 $exportPATH=$HIVE_HOME/bin:$PATH編譯Hive源碼
下載hive源碼
此處使用maven編譯,需要下載安裝maven。
以Hive 0.13版為例 編譯hive 0.13源碼基於hadoop 0.23或更高版本
$cdhive$mvncleaninstall-Phadoop-2,dist$cdpackaging/target/apache-hive-{version}-SNAPSHOT-bin/apache-hive-{version}-SNAPSHOT-bin$lsLICENSENOTICEREADME.txtRELEASE_NOTES.txtbin/(alltheshellscripts)lib/(requiredjarfiles)conf/(configurationfiles)examples/(sampleinputandqueryfiles)hcatalog/(hcataloginstallation)scripts/(upgradescriptsforhive-metastore) 編譯hive 基於hadoop 0.20
$cdhive$antcleanpackage$cdbuild/dist#lsLICENSENOTICEREADME.txtRELEASE_NOTES.txtbin/(alltheshellscripts)lib/(requiredjarfiles)conf/(configurationfiles)examples/(sampleinputandqueryfiles)hcatalog/(hcataloginstallation)scripts/(upgradescriptsforhive-metastore) 運行hive
Hive運行依賴於hadoop,在運行hadoop之前必需先配置好hadoopHome。 exportHADOOP_HOME=<hadoop-install-dir>在hdfs上為hive創建 mp目錄和/user/hive/warehouse(akahive.metastore.warehouse.dir) 目錄,然後你才可以運行hive。
在運行hive之前設置HiveHome。 $exportHIVE_HOME=<hive-install-dir>在命令行窗口啟動hive $$HIVE_HOME/bin/hive若執行成功,將看到類似內容如圖所示
Ⅱ Hive優化之Hive的配置參數優化
Hive是大數據領域常用的組件之一,主要用於大數據離線數倉的運算,關於Hive的性能調優在日常工作和面試中是經常涉及的一個點,因此掌握一些Hive調優是必不可少的一項技能。影響Hive效率的主要因素有數據傾斜、數據冗餘、job的IO以及不同底層引擎配置情況和Hive本身參數和Hivesql的執行等。本文主要從建表配置參數方面對Hive優化進行講解。
1. 創建一個普通表
table test_user1(id int, name string,code string,code_id string ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',';
2. 查看這張表的信息
DESCRIBE FORMATTED test_user1;
我們從該表的描述信息介紹建表時的一些可優化點。
2.1 表的文件數
numFiles表示表中含有的文件數,當文件數過多時可能意味著該表的小文件過多,這時候我們可以針對小文件的問題進行一些優化,HDFS本身提供了解決方案:
(1)Hadoop Archive/HAR:將小文件打包成大文件。
(2)SEQUENCEFILE格式:將大量小文件壓縮成一個SEQUENCEFILE文件。
(3)CombineFileInputFormat:在map和rece處理之前組合小文件。
(4)HDFS Federation:HDFS聯盟,使用多個namenode節點管理文件。
除此之外,我們還可以通過設置hive的參數來合並小文件。
(1)輸入階段合並
需要更改Hive的輸入文件格式,即參數hive.input.format,默認值是org.apache.hadoop.hive.ql.io.HiveInputFormat,我們改成org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。這樣比起上面對mapper數的調整,會多出兩個參數,分別是mapred.min.split.size.per.node和mapred.min.split.size.per.rack,含義是單節點和單機架上的最小split大小。如果發現有split大小小於這兩個值(默認都是100MB),則會進行合並。具體邏輯可以參看Hive源碼中的對應類。
(2)輸出階段合並
直接將hive.merge.mapfiles和hive.merge.mapredfiles都設為true即可,前者表示將map-only任務的輸出合並,後者表示將map-rece任務的輸出合並,Hive會額外啟動一個mr作業將輸出的小文件合並成大文件。另外,hive.merge.size.per.task可以指定每個task輸出後合並文件大小的期望值,hive.merge.size.smallfiles.avgsize可以指定所有輸出文件大小的均值閾值,默認值都是1GB。如果平均大小不足的話,就會另外啟動一個任務來進行合並。
2.2 表的存儲格式
通過InputFormat和OutputFormat可以看出表的存儲格式是TEXT類型,Hive支持TEXTFILE, SEQUENCEFILE, AVRO, RCFILE, ORC,以及PARQUET文件格式,可以通過兩種方式指定表的文件格式:
(1)CREATE TABLE ... STORE AS <file_format>:在建表時指定文件格式,默認是TEXTFILE
(2)ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT <file_format>:修改具體表的文件格式
如果要改變創建表的默認文件格式,可以使用set
hive.default.fileformat=<file_format>進行配置,適用於所有表。同時也可以使用set
hive.default.fileformat.managed = <file_format>進行配置,僅適用於內部表或外部表。
擴展:不同存儲方式的情況
TEXT,
SEQUENCE和
AVRO文件是面向行的文件存儲格式,不是最佳的文件格式,因為即便只查詢一列數據,使用這些存儲格式的表也需要讀取完整的一行數據。另一方面,面向列的存儲格式(RCFILE,
ORC, PARQUET)可以很好地解決上面的問題。關於每種文件格式的說明,如下:
(1)TEXTFILE
創建表時的默認文件格式,數據被存儲成文本格式。文本文件可以被分割和並行處理,也可以使用壓縮,比如GZip、LZO或者Snappy。然而大部分的壓縮文件不支持分割和並行處理,會造成一個作業只有一個mapper去處理數據,使用壓縮的文本文件要確保文件不要過大,一般接近兩個HDFS塊的大小。
(2)SEQUENCEFILE
key/value對的二進制存儲格式,sequence文件的優勢是比文本格式更好壓縮,sequence文件可以被壓縮成塊級別的記錄,塊級別的壓縮是一個很好的壓縮比例。如果使用塊壓縮,需要使用下面的配置:set
hive.exec.compress.output=true; set io.seqfile.compression.type=BLOCK
(3)AVRO
二進制格式文件,除此之外,avro也是一個序列化和反序列化的框架。avro提供了具體的數據schema。
(4)RCFILE
全稱是Record Columnar File,首先將表分為幾個行組,對每個行組內的數據進行按列存儲,每一列的數據都是分開存儲,即先水平劃分,再垂直劃分。
(5)ORC
全稱是Optimized Row Columnar,從hive0.11版本開始支持,ORC格式是RCFILE格式的一種優化的格式,提供了更大的默認塊(256M)
(6)PARQUET
另外一種列式存儲的文件格式,與ORC非常類似,與ORC相比,Parquet格式支持的生態更廣,比如低版本的impala不支持ORC格式。
配置同樣數據同樣欄位的兩張表,以常見的TEXT行存儲和ORC列存儲兩種存儲方式為例,對比執行速度。
TEXT存儲方式
總結: 從上圖中可以看出列存儲在對指定列進行查詢時,速度更快, 建議在建表時設置列存儲的存儲方式 。
2.3 表的壓縮
對Hive表進行壓縮是常見的優化手段,一些存儲方式自帶壓縮選擇,比如SEQUENCEFILE支持三種壓縮選擇:NONE,RECORD,BLOCK。Record壓縮率低,一般建議使用BLOCK壓縮;
ORC支持三種壓縮選擇:NONE,ZLIB,SNAPPY。我們以TEXT存儲方式和ORC存儲方式為例,查看錶的壓縮情況。
配置同樣數據同樣欄位的四張表,一張TEXT存儲方式,另外三張分別是默認壓縮方式的ORC存儲、SNAPPY壓縮方式的ORC存儲和NONE壓縮方式的ORC存儲,查看在hdfs上的存儲情況:
TEXT存儲方式
默認壓縮ORC存儲方式
SNAPPY壓縮的ORC存儲方式
NONE壓縮的ORC存儲方式
總結 :可以看到ORC存儲方式將數據存放為兩個block,默認壓縮大小加起來134.69M,SNAPPY壓縮大小加起來196.67M,NONE壓縮大小加起來247.55M,TEXT存儲方式的文件大小為366.58M,且默認block兩種存儲方式分別為256M和128M,ORC默認的壓縮方式比SNAPPY壓縮得到的文件還小,原因是ORZ默認的ZLIB壓縮方式採用的是deflate壓縮演算法,比Snappy壓縮演算法得到的壓縮比高,壓縮的文件更小。 ORC不同壓縮方式之間的執行速度,經過多次測試發現三種壓縮方式的執行速度差不多,所以建議採用ORC默認的存儲方式進行存儲數據。
2.4 分桶分區
Num Buckets表示桶的數量,我們可以通過分桶和分區操作對Hive表進行優化:
對於一張較大的表,可以將它設計成分區表,如果不設置成分區表,數據是全盤掃描的,設置成分區表後,查詢時只在指定的分區中進行數據掃描,提升查詢效率。要注意盡量避免多級分區,一般二級分區足夠使用。常見的分區欄位:
(1)日期或者時間,比如year、month、day或者hour,當表中存在時間或者日期欄位時,可以使用些欄位。
(2)地理位置,比如國家、省份、城市等
(3)業務邏輯,比如部門、銷售區域、客戶等等
與分區表類似,分桶表的組織方式是將HDFS上的一張大表文件分割成多個文件。分桶是相對分區進行更細粒度的劃分,分桶將整個數據內容按照分桶欄位屬性值得hash值進行區分,分桶可以加快數據采樣,也可以提升join的性能(join的欄位是分桶欄位),因為分桶可以確保某個key對應的數據在一個特定的桶內(文件),所以巧妙地選擇分桶欄位可以大幅度提升join的性能。通常情況下,分桶欄位可以選擇經常用在過濾操作或者join操作的欄位。
創建分桶表
create
table test_user_bucket(id int, name string,code string,code_id string )
clustered by(id) into 3 buckets ROW FORMAT DELIMITED FIELDS TERMINATED
BY ',';
查看描述信息
DESCRIBE FORMATTED test_user_bucket
多出了如下信息
查看該表的hdfs
同樣的數據查看普通表和分桶表查詢效率
普通表
分桶表
普通表是全表掃描,分桶表在按照分桶欄位的hash值分桶後,根據join欄位或者where過濾欄位在特定的桶中進行掃描,效率提升。
本文首發於: 數棧研習社
數棧是雲原生—站式數據中台PaaS,我們在github上有一個有趣的開源項目: FlinkX
FlinkX是一個基於Flink的批流統一的數據同步工具,既可以採集靜態的數據,比如MySQL,HDFS等,也可以採集實時變化的數據,比如MySQL
binlog,Kafka等,是全域、異構、批流一體的數據同步引擎,大家如果有興趣,歡迎來github社區找我們玩~
Ⅲ Hive內置函數之時間函數
零、生產常用組合方式
(0.1)離線數倉獲取昨天的日期作為分區,格式yyyyMMdd
regexp_replace(date_sub(from_unixtime(unix_timestamp(),'yyyy-MM-dd'),1) ,'-','')
或者
date_format(date_sub(from_unixtime(unix_timestamp(),'yyyy-MM-dd'),1),'yyyyMMdd')
一、源碼部分
Hive的函數類為:org.apache.hadoop.hive.ql.exec.FunctionRegistry
二、常用時間函數
對於函數,除了知道怎麼用,還需要知道返回值是什麼類型,這里給出官方文檔,文檔中給出了函數的返回值類型
官方文檔見: https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions
(2.1)from_unixtime(bigint unixtime[, string format])
示例:
select from_unixtime(1591627588); -- 2020-06-08 22:46:28
select from_unixtime(1591627588,'yyyyMMddHHmmss'); -- 20200608224628
(2.2)unix_timestamp()、unix_timestamp(string date)、unix_timestamp(string date, string pattern)
示例:
select unix_timestamp('2020-06-08 22:50:00'); -- 1591627800
select unix_timestamp('20200608225000','yyyyMMddHHmmss'); -- 1591627800
(2.3)to_date(string timestamp)
示例:
SELECT to_date('2009-07-30 04:17:52'); -- 2009-07-30
(2.4)year(string date)、month(string date)、day(string date)、hour(string date)、minute(string date)、second(string date)
這些函數是差不多的,都是從一個時間字元串中抽取出某個特定的時間欄位。具有相同功能的還有extract(field FROM source)函數
示例:
SELECT day('2009-07-29 20:30:40'); -- 29
SELECT minute('2009-07-29 20:30:40'); -- 30
(2.5)date_add(date/timestamp/string startdate, tinyint/smallint/int days)、date_sub(date/timestamp/string startdate, tinyint/smallint/int days)
這兩個功能是類似的
示例:
SELECT date_add('2009-07-30 20:50:59', 1); -- 2009-07-31
(2.6)datediff(string enddate, string startdate)
截圖中結果是錯誤的,應該為-1。
示例:
SELECT datediff('2009-06-30', '2009-07-02'); -- -2
SELECT datediff('2009-07-30', '2009-07-28'); -- 2
(2.7)current_date、current_timestamp
這兩個函數使用desc function extended 查看會報錯
示例:
(2.8)date_format(date/timestamp/string ts, string fmt)
示例:
SELECT date_format('2015-04-08', 'yyyyMMdd'); -- 20150408
Ⅳ 如何編譯Zookeeper源碼
riak華師大的吧--下面來簡單介紹各個組件的作用:HDFS(Hadoopdistributefilesystem)——Hadoop生態系統的基礎組件Hadoop分布式文件系統。它是其他一些工具的基礎HDFS的機制是將大量數據分布到計算機集群上,數據一次寫入,但可以多次讀取用於分析。HDFS讓Hadoop可以最大化利用磁碟。HBase——一個構建在HDFS之上的面向列的NoSql資料庫,HBase用於對打量數據進行快速讀取/寫入。HBase將Zookeeper用於自身的管理,以保證其所有組件都正在運行。HBase使得Hadoop可以最大化利用內存。MapRece——MapRece是Hadoop的主要執行框架,它是一個用於分布式並行數據處理的編程模型,將作業分為mapping階段和rece階段。開發人員謂Hadoop編寫MapRece作業,並使用HDFS中存儲的數據,而HDFS可以保證快速的數據訪問。鑒於MapRece作業的特性,Hadoop以並行的方式將處理過程移向數據。MapRece使得Hadoop可以最大化利用CPU。Zookeeper——Zookeeper是Hadoop的分布式協調服務。Zookeeper被設計成可以在機器集群上運行,是一個具有高度可用性的服務,用於Hadoop操作的管理,而且很多Hadoop組件都依賴它。Oozie——Oozie是一個北極測很難過到Hadoop軟體棧中的可擴展的Workflow系統。用於協調多個MapRece作業的執行。它能夠處理大量的復雜性,基於外部事件來管理執行。Pig——Pig是對MapRece編程復雜性的抽象,Pig平台包含用於分析Hadoop數據集的執行環境和腳本語言(PigLatin)。它的編譯器將PigLatin翻譯為MapRece程序序列。Hive——類似於SQL的高級語言,用於執行對存儲在Hadoop中數據的查詢,Hive允許不熟悉MapRece的開發人員編寫數據查詢語句,它會將翻譯為Hadoop中的MapRece作業。類似於Pig。Hive是一個抽象層,適合於較熟悉SQL而不是java編程的資料庫分析師。Hadoop生態系統中還包含一些用於與其他企業級應用進行集成的框架,例如上圖所示的Sqoop和Flume:Sqoop是一個連通性工具,用於在關系型資料庫和數據倉庫Hadoop之間移動數據。Sqoop利用資料庫來描述導入/導出數據的模式,並使用MapRece實現並行操作和容錯。Fulme是一個分布式的、具有可靠性和高可用性的服務,用於從單獨的機器上將大量數據高效的收集、聚合並移動到HDFS中。它給予一個簡單靈活的架構,童工流式數據操所。它藉助於簡單可擴展的數據模型,允許將來自企業中多台機器上的數據移到Hadoop中。
Ⅳ 如何配置hive,使hive能使用spark引擎
使用Scala寫一個測試代碼: object Test { def main(args: Array[String]): Unit = { println("hello world") } } 就把這個Test視為類,項目組織結構如: 然後設置編譯選項: 然後在項目文件夾下面可以找到編譯好的Jar包: 復制到Spark指定的目...
Ⅵ Hive入門概述
1.1 什麼是Hive
Hive:由Facebook開源用於解決海量結構化日誌的數據統計。
Hive是基於Hadoop的一個數據倉庫工具,可以將結構化的數據文件映射為一張表,並提供類SQL查詢功能。本質是:將HQL轉化成MapRece程序
Hive處理的數據存儲在HDFS
Hive分析數據底層的實現是MapRece
執行程序運行在Yarn上
1.2 Hive的優缺點
1.2.1 優點
操作介面採用類SQL語法,提供快速開發的能力(簡單、容易上手)。
避免了去寫MapRece,減少開發人員的學習成本。
Hive的執行延遲比較高,因此Hive常用於數據分析,對實時性要求不高的場合。
Hive優勢在於處理大數據,對於處理小數據沒有優勢,因為Hive的執行延遲比較高。
Hive支持用戶自定義函數,用戶可以根據自己的需求來實現自己的函數。
1.2.2 缺點
1.Hive的HQL表達能力有限
(1)迭代式演算法無法表達
(2)數據挖掘方面不擅長
2.Hive的效率比較低
(1)Hive自動生成的MapRece作業,通常情況下不夠智能化
(2)Hive調優比較困難,粒度較粗
1.3 Hive架構原理
1.用戶介面:Client
CLI(hive shell)、JDBC/ODBC(java訪問hive)、WEBUI(瀏覽器訪問hive)
2.元數據:Metastore
元數據包括:表名、表所屬的資料庫(默認是default)、表的擁有者、列/分區欄位、表的類型(是否是外部表)、表的數據所在目錄等;
默認存儲在自帶的derby資料庫中,推薦使用MySQL替代derby存儲Metastore
3.Hadoop
使用HDFS進行存儲,使用MapRece進行計算。
4.驅動器:Driver
(1)解析器(SQL Parser):將SQL字元串轉換成抽象語法樹AST,這一步一般都用第三方工具庫完成,比如antlr;對AST進行語法分析,比如表是否存在、欄位是否存在、SQL語義是否有誤。
(2)編譯器(Physical Plan):將AST編譯生成邏輯執行計劃。
(3)優化器(Query Optimizer):對邏輯執行計劃進行優化。
(4)執行器(Execution):把邏輯執行計劃轉換成可以運行的物理計劃。對於Hive來說,就是MR/Spark。
Hive通過給用戶提供的一系列交互介面,接收到用戶的指令(SQL),使用自己的Driver,結合元數據(MetaStore),將這些指令翻譯成MapRece,提交到Hadoop中執行,最後,將執行返回的結果輸出到用戶交互介面。
1.4 Hive和資料庫比較
由於 Hive 採用了類似SQL 的查詢語言 HQL(Hive Query Language),因此很容易將 Hive 理解為資料庫。其實從結構上來看,Hive 和資料庫除了擁有類似的查詢語言,再無類似之處。本文將從多個方面來闡述 Hive 和資料庫的差異。資料庫可以用在 Online 的應用中,但是Hive 是為數據倉庫而設計的,清楚這一點,有助於從應用角度理解 Hive 的特性。
1.4.1 查詢語言
由於SQL被廣泛的應用在數據倉庫中,因此,專門針對Hive的特性設計了類SQL的查詢語言HQL。熟悉SQL開發的開發者可以很方便的使用Hive進行開發。
1.4.2 數據存儲位置
Hive 是建立在 Hadoop 之上的,所有 Hive 的數據都是存儲在 HDFS 中的。而資料庫則可以將數據保存在塊設備或者本地文件系統中。
1.4.3 數據更新
由於Hive是針對數據倉庫應用設計的,而數據倉庫的內容是讀多寫少的。因此,Hive中不建議對數據的改寫,所有的數據都是在載入的時候確定好的。而資料庫中的數據通常是需要經常進行修改的,因此可以使用 INSERT INTO … VALUES 添加數據,使用 UPDATE … SET修改數據。
1.4.4 索引
Hive在載入數據的過程中不會對數據進行任何處理,甚至不會對數據進行掃描,因此也沒有對數據中的某些Key建立索引。Hive要訪問數據中滿足條件的特定值時,需要暴力掃描整個數據,因此訪問延遲較高。由於 MapRece 的引入, Hive 可以並行訪問數據,因此即使沒有索引,對於大數據量的訪問,Hive 仍然可以體現出優勢。資料庫中,通常會針對一個或者幾個列建立索引,因此對於少量的特定條件的數據的訪問,資料庫可以有很高的效率,較低的延遲。由於數據的訪問延遲較高,決定了 Hive 不適合在線數據查詢。
1.4.5 執行
Hive中大多數查詢的執行是通過 Hadoop 提供的 MapRece 來實現的。而資料庫通常有自己的執行引擎。
1.4.6 執行延遲
Hive 在查詢數據的時候,由於沒有索引,需要掃描整個表,因此延遲較高。另外一個導致 Hive 執行延遲高的因素是 MapRece框架。由於MapRece 本身具有較高的延遲,因此在利用MapRece 執行Hive查詢時,也會有較高的延遲。相對的,資料庫的執行延遲較低。當然,這個低是有條件的,即數據規模較小,當數據規模大到超過資料庫的處理能力的時候,Hive的並行計算顯然能體現出優勢。
1.4.7 可擴展性
由於Hive是建立在Hadoop之上的,因此Hive的可擴展性是和Hadoop的可擴展性是一致的(世界上最大的Hadoop 集群在 Yahoo!,2009年的規模在4000 台節點左右)。而資料庫由於 ACID 語義的嚴格限制,擴展行非常有限。目前最先進的並行資料庫 Oracle 在理論上的擴展能力也只有100台左右。
1.4.8 數據規模
由於Hive建立在集群上並可以利用MapRece進行並行計算,因此可以支持很大規模的數據;對應的,資料庫可以支持的數據規模較小。
Ⅶ 大數據分析應該掌握哪些基礎知識
Java基礎語法
· 分支結構if/switch
· 循環結構for/while/do while
· 方法聲明和調用
· 方法重載
· 數組的使用
· 命令行參數、可變參數
IDEA
· IDEA常用設置、常用快捷鍵
· 自定義模板
· 關聯Tomcat
· Web項目案例實操
面向對象編程
· 封裝、繼承、多態、構造器、包
· 異常處理機制
· 抽象類、介面、內部類
· 常有基礎API、集合List/Set/Map
· 泛型、線程的創建和啟動
· 深入集合源碼分析、常見數據結構解析
· 線程的安全、同步和通信、IO流體系
· 反射、類的載入機制、網路編程
Java8/9/10/11新特性
· Lambda表達式、方法引用
· 構造器引用、StreamAPI
· jShell(JShell)命令
· 介面的私有方法、Optional加強
· 局部變數的類型推斷
· 更簡化的編譯運行程序等
MySQL
· DML語言、DDL語言、DCL語言
· 分組查詢、Join查詢、子查詢、Union查詢、函數
· 流程式控制制語句、事務的特點、事務的隔離級別等
JDBC
· 使用JDBC完成資料庫增刪改查操作
· 批處理的操作
· 資料庫連接池的原理及應用
· 常見資料庫連接池C3P0、DBCP、Druid等
Maven
· Maven環境搭建
· 本地倉庫&中央倉庫
· 創建Web工程
· 自動部署
· 持續繼承
· 持續部署
Linux
· VI/VIM編輯器
· 系統管理操作&遠程登錄
· 常用命令
· 軟體包管理&企業真題
Shell編程
· 自定義變數與特殊變數
· 運算符
· 條件判斷
· 流程式控制制
· 系統函數&自定義函數
· 常用工具命令
· 面試真題
Hadoop
· Hadoop生態介紹
· Hadoop運行模式
· 源碼編譯
· HDFS文件系統底層詳解
· DN&NN工作機制
· HDFS的API操作
· MapRece框架原理
· 數據壓縮
· Yarn工作機制
· MapRece案例詳解
· Hadoop參數調優
· HDFS存儲多目錄
· 多磁碟數據均衡
· LZO壓縮
· Hadoop基準測試
Zookeeper
· Zookeeper數據結果
· 內部原理
· 選舉機制
· Stat結構體
· 監聽器
· 分布式安裝部署
· API操作
· 實戰案例
· 面試真題
· 啟動停止腳本
HA+新特性
· HDFS-HA集群配置
Hive
· Hive架構原理
· 安裝部署
· 遠程連接
· 常見命令及基本數據類型
· DML數據操作
· 查詢語句
· Join&排序
· 分桶&函數
· 壓縮&存儲
· 企業級調優
· 實戰案例
· 面試真題
Flume
· Flume架構
· Agent內部原理
· 事務
· 安裝部署
· 實戰案例
· 自定義Source
· 自定義Sink
· Ganglia監控
Kafka
· 消息隊列
· Kafka架構
· 集群部署
· 命令行操作
· 工作流程分析
· 分區分配策略
· 數據寫入流程
· 存儲策略
· 高階API
· 低級API
· 攔截器
· 監控
· 高可靠性存儲
· 數據可靠性和持久性保證
· ISR機制
· Kafka壓測
· 機器數量計算
· 分區數計算
· 啟動停止腳本
DataX
· 安裝
· 原理
· 數據一致性
· 空值處理
· LZO壓縮處理
Scala
· Scala基礎入門
· 函數式編程
· 數據結構
· 面向對象編程
· 模式匹配
· 高階函數
· 特質
· 註解&類型參數
· 隱式轉換
· 高級類型
· 案例實操
Spark Core
· 安裝部署
· RDD概述
· 編程模型
· 持久化&檢查點機制
· DAG
· 運算元詳解
· RDD編程進階
· 累加器&廣播變數
Spark SQL
· SparkSQL
· DataFrame
· DataSet
· 自定義UDF&UDAF函數
Spark Streaming
· SparkStreaming
· 背壓機制原理
· Receiver和Direct模式原理
· Window原理及案例實操
· 7x24 不間斷運行&性能考量
Spark內核&優化
· 內核源碼詳解
· 優化詳解
Hbase
· Hbase原理及架構
· 數據讀寫流程
· API使用
· 與Hive和Sqoop集成
· 企業級調優
Presto
· Presto的安裝部署
· 使用Presto執行數倉項目的即席查詢模塊
Ranger2.0
· 許可權管理工具Ranger的安裝和使用
Azkaban3.0
· 任務調度工具Azkaban3.0的安裝部署
· 使用Azkaban進行項目任務調度,實現電話郵件報警
Kylin3.0
· Kylin的安裝部署
· Kylin核心思想
· 使用Kylin對接數據源構建模型
Atlas2.0
· 元數據管理工具Atlas的安裝部署
Zabbix
· 集群監控工具Zabbix的安裝部署
DolphinScheler
· 任務調度工具DolphinScheler的安裝部署
· 實現數倉項目任務的自動化調度、配置郵件報警
Superset
· 使用SuperSet對數倉項目的計算結果進行可視化展示
Echarts
· 使用Echarts對數倉項目的計算結果進行可視化展示
Redis
· Redis安裝部署
· 五大數據類型
· 總體配置
· 持久化
· 事務
· 發布訂閱
· 主從復制
Canal
· 使用Canal實時監控MySQL數據變化採集至實時項目
Flink
· 運行時架構
· 數據源Source
· Window API
· Water Mark
· 狀態編程
· CEP復雜事件處理
Flink SQL
· Flink SQL和Table API詳細解讀
Flink 內核
· Flink內核源碼講解
· 經典面試題講解
Git&GitHub
· 安裝配置
· 本地庫搭建
· 基本操作
· 工作流
· 集中式
ClickHouse
· ClickHouse的安裝部署
· 讀寫機制
· 數據類型
· 執行引擎
DataV
· 使用DataV對實時項目需求計算結果進行可視化展示
sugar
· 結合Springboot對接網路sugar實現數據可視化大屏展示
Maxwell
· 使用Maxwell實時監控MySQL數據變化採集至實時項目
ElasticSearch
· ElasticSearch索引基本操作、案例實操
Kibana
· 通過Kibana配置可視化分析
Springboot
· 利用Springboot開發可視化介面程序
Ⅷ hive join數據錯誤
我們生產使用的hive3.1.2版本,hadoop也是3版本,用戶通過使用hive發現join數據錯誤。分析SQL發現,當3表(含3表)以上,hive join出來的數據是錯誤。後來我通過測試發現,不管是left join、inner join還是right join,數據都會出現錯誤,通過後來的其他測試發現,兩個表使用in和exists作為條件查詢,出來的數據也是錯誤的。這是hive3的一個重大bug,使用hive3的小心了。
這個bug糾纏了我好久,後來定位出來hive的bug,我們生產環境通過修改hive源碼已經修復了該bug。分析發現hive從2.6.1版本就開始有這個bug
in 和exists案例sql:
Ⅸ spark thrift server 與 網易 kyuubi thrift server
thrift server可以實現通過jdbc, beeline等工具,實現連接到spark集群,並提交sql查詢的機制。
默認情況下,cdh安裝的spark沒有包含thrift server模塊,因此我們需要重新編譯spark。
另外,為了不影響cdh自帶的spark,而且spark目前都是基於yarn運行的,本身也沒有什麼獨立的服務部署(除了history sever)。
所以,在一個集群中,可以部署安裝多個版本的spark。
我們使用源碼編譯的spark 2.4.0(其中hive的版本是1.2.1)
cdh集成的spark版本和Hive版本如下:
使用jdk1.8
修改spark提供的mvn,使用自行安裝的maven 3.8.1
使用make-distribution.sh可以幫助與我們編譯之後打包成tgz文件
修改pom.xml文件的配置如下。
最後,執行編譯命令如下:
這樣打出的包,就含有thrift server的jar包了。
最終打包文件,根目錄下。
之後就是解壓到其他目錄下後即可。
將hive-site.xml的文件連接過來,這樣spark就可以讀取hive的表了。
為了確保spark提交到yarn上運行,需要配置
cp spark-defaults.conf.template spar-defaults.conf
另外,可以在spark-env.sh中設置環境變數。
HADOOP_CONF_DIR
環境變數,也可以在/etc/profile中設置
啟動日誌可以查看,注意下埠佔用問題,如下。
啟動時候,使用beeline工具連接上,主要這里不用使用cdh默認安裝hive提供的beeline工具,應為版本太高。
使用編譯後spark生成beeline工具
參考beeline使用教程。
https://github.com/apache/incubator-kyuubi
kyuubi是基於thrift sever二次開發,在系能和安全上優於thrift server。
鑒於目前hive的版本是2.1,而最新的kyuubi的hive是2.3,所以採用前天版本的kyuubi,採用0.7版本,保證hive的版本小於當前集群中的hive版本。
使用build目錄下的dist腳本進行編譯和打包。
編譯成功後,會在更目錄下出現tar.gz的壓縮文件,如上圖。
之後解壓到目錄下。
配置bin/kyuubi-env.sh腳本,設置spark路徑
執行bin/start-kyuubi.sh命令即可。
訪問的方式同樣採用beelin,注意使用上面章節的beeline工具。
訪問後,可以通過beeline訪問到hive的表(在spark中已經配置了hive-site.xml)
!connect jdbc: hive2://xxxx:10009 即可。
Ⅹ hue/oozie 調度shell執行hive腳本
前面已經有篇文章介紹如何編譯包含hive的spark-assembly.jar了,不清楚的可以翻看一下前面的文章。clouderamanager裝好的spark,直接執行spark-shell進入命令行後,寫入如下語句:valhiveContext=neworg.apache.spark.sql.hive.HiveContext(sc)你會發現沒法執行通過,因為cm裝的原生的spark是不支持sparkhql的,我們需要手動進行一些調整:第一步,將編譯好的包含hive的JAR包上傳到hdfs上配置的默認的spark的sharelib目錄:/user/spark/share/lib第二步:在你要運行spark-shell腳本的節點上的/opt/cloudera/parcels/CDH-5.3.0-1.cdh5.3.0.p0.30/lib/spark/lib/目錄下面,下載這個jar到這個目錄:hadoopfs-gethdfs://n1:8020/user/spark/share/lib/spark-assembly-with-hive-maven.jar(具體路徑替換成你自己的)。然後這個目錄下面原來會有個軟鏈接spark-assembly.jar指向的是spark-assembly-1.2.0-cdh5.3.0-hadoop2.5.0-cdh5.3.0.jar,我們把這個軟鏈接刪除掉重新創建一個同名的軟鏈接:ln-sspark-assembly-with-hive-maven.jarspark-assembly.jar,指向我們剛下載下來的那個JAR包,這個JAR包會在啟動spark-shell腳本時裝載到driverprogram的classpath中去的,sparkContext也是在driver中創建出來的,所以需要將我們編譯的JAR包替換掉原來的spark-assembly.jar包,這樣在啟動spark-shell的時候,包含hive的spark-assembly就被裝載到classpath中去了。第三步:在/opt/cloudera/parcels/CDH/lib/spark/conf/目錄下面創建一個hive-site.xml。/opt/cloudera/parcels/CDH/lib/spark/conf目錄是默認的spark的配置目錄,當然你可以修改默認配置目錄的位置。hive-site.xml內容如下:hive.metastore.localfalsehive.metastore.uristhrift://n1:9083hive.metastore.client.socket.timeout300hive.metastore.warehouse.dir/user/hive/warehouse這個應該大家都懂的,總要讓spark找到hive的元數據在哪吧,於是就有了上面一些配置。第四步:修改/opt/cloudera/parcels/CDH/lib/spark/conf/spark-defaults.conf,添加一個屬性:spark.yarn.jar=hdfs://n1:8020/user/spark/share/lib/spark-assembly-with-hive-maven.jar。這個是讓每個executor下載到本地然後裝載到自己的classpath下面去的,主要是用在yarn-cluster模式。local模式由於driver和executor是同一個進程所以沒關系。以上完事之後,運行spark-shell,再輸入:valhiveContext=neworg.apache.spark.sql.hive.HiveContext(sc)應該就沒問題了。我們再執行一個語句驗證一下是不是連接的我們指定的hive元資料庫:hiveContext.sql("showtables").take(10)//取前十個表看看最後要重點說明一下這里的第二步第三步和第四步,如果是yarn-cluster模式的話,應該替換掉集群所有節點的spark-assembly.jar集群所有節點的sparkconf目錄都需要添加hive-site.xml,每個節點spark-defaults.conf都需要添加spark.yarn.jar=hdfs://n1:8020/user/spark/share/lib/spark-assembly-with-hive-maven.jar。可以寫個shell腳本來替換,不然手動一個一個節點去替換也是蠻累的。