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腳本來替換，不然手動一個一個節點去替換也是蠻累的。