大數據開發筆記

0 Brief

• 整體流程

定義Event時間模型作爲數據結構 -> 採集、清洗、存儲至分佈式文件集羣 -> 分佈式計算供給各個業務線運營

• 數據結構

靈機數據模型：“事件模型（Event 模型）”，用來描述用戶在產品上的各種行爲，這也是靈機數據中心所有的接口和功能設計的核心依據。

PV 模型無法滿足一些更加細節的、更加精細化的分析。例如，我們想分析哪類產品銷量最好，訪問網站的用戶的年齡和性別構成，每個渠道過來的用戶的轉化率、留存和重複購買率分別如何，新老用戶的客單價、流水、補貼比例分別是多少等等。這些問題，都是以 PV 爲核心的傳統統計分析沒辦法解答的問題。

因此，靈機數據中心採用事件模型作爲基本的數據模型。事件模型可以給我們更多的信息，讓我們知道用戶用我們的產品具體做了什麼事情。事件模型給予我們更全面且更具體的視野，指導我們做出更好的決策。
(所謂的精細化運營就是將各個信息都保存起來，然後從不同維度去做統計，根據統計指標（量化結果）得出事件結論？)

Event 的五要素
一個 Event 就是描述了：一個用戶在某個時間點、某個地方，以某種方式完成了某個具體的事情。一個完整的 Event，包含如下的幾個關鍵因素：Who、When、Where、How、What。

• 數據開發：(單條業務線) 埋點 + 上傳存儲 + ETL清洗 + 運營指標計算 + 接口開發； 實時？離線
  Hadoop業務的整體開發流程：
  

Hadoop
Hadoop的核心爲HDFS與MapReduce，HDFS分佈式文件系統在Hadop中是用來存儲數據的；MapReduce爲Hadoop處理數據的核心
Hadoop是一個開源框架來存儲和處理大型數據在分佈式環境中。它包含兩個模塊，一個是MapReduce，另外一個是Hadoop分佈式文件系統（HDFS）。

• MapReduce：它是一種並行編程模型在大型集羣普通硬件可用於處理大型結構化，半結構化和非結構化數據。
• HDFS：Hadoop分佈式文件系統是Hadoop的框架的一部分，用於存儲和處理數據集。它提供了一個容錯文件系統在普通硬件上運行。

Hadoop生態系統包含了用於協助Hadoop的不同的子項目（工具）模塊，如Sqoop, Pig 和 Hive。

• Sqoop: 它是用來在HDFS和RDBMS之間來回導入和導出數據。
• Pig: 它是用於開發MapReduce操作的腳本程序語言的平臺。
• Hive: 它是用來開發SQL類型腳本用於做MapReduce操作的平臺。

注：有多種方法來執行MapReduce作業：

• 傳統的方法是使用Java MapReduce程序結構化，半結構化和非結構化數據。
• 針對MapReduce的腳本的方式，使用Pig來處理結構化和半結構化數據。
• Hive查詢語言（HiveQL或HQL）採用Hive爲MapReduce的處理結構化數據。

摘自Spark入門基礎教程
目前按照大數據處理類型來分大致可以分爲：批量數據處理、交互式數據查詢、實時數據流處理，這三種數據處理方式對應的業務場景也都不一樣；
關注大數據處理的應該都知道Hadoop，而Hadoop的核心爲HDFS與MapReduce，HDFS分佈式文件系統在Hadop中是用來存儲數據的；MapReduce爲Hadoop處理數據的核心，接觸過函數式編程的都知道函數式語言中也存在着Map、Reduce函數其實這兩者的思想是一致的；也正是因爲Hadoop數據處理核心爲MapReduce奠定了它註定不是適用場景廣泛的大數據框架；

可以這麼說Hadoop適用於Map、Reduce存在的任何場景，具體場景比如：WordCount、排序、PageRank、用戶行爲分析、數據統計等，而這些場景都算是批量數據處理，而Hadoop並不適用於交互式數據查詢、實時數據流處理；

這時候就出現了各種數據處理模型下的專用框架如：Storm、Impala、GraphLab等；

1、Storm：針對實時數據流處理的分佈式框架；
2、Impala：適用於交互式大數據查詢的分佈式框架；
3、GraphLab：基於圖模型的機器學習框架；

1、MapReduce簡單模型

這時候如果一個團隊或一個公司中同時都有設計到大數據批量處理、交互式查詢、實時數據流處理這三個場景；這時候就會有一些問題：

1、學習成本很高，每個框架都是不同的實現語言、不同的團隊開發的；
2、各個場景組合起來代價必然會很大；
3、各個框架中共享的中間數據共享與移動成本高；

就在這時候UC Berkeley AMP推出了全新的大數據處理框架：Spark提供了全面、統一適用與不同場景的大數據處理需求（批量數據處理、交互式數據查詢、實時數據流處理、機器學習）；Spark不僅性能遠勝於Hadoop而卻還兼容Hadoop生態系統，Spark可以運行在Hadoop HDFS之上提供爭強 功能，可以說Spark替代了Hadoop MapReduce，但Spark依然兼容Hadoop中的YARN與Apache Mesos組件，現有Hadoop用戶可以很容易就遷移到Spark；

Spark中最核心的概念爲RDD（Resilient Distributed DataSets）中文爲：彈性分佈式數據集，RDD爲對分佈式內存對象的 抽象它表示一個被分區不可變且能並行操作的數據集；RDD爲可序列化的、可緩存到內存對RDD進行操作過後還可以存到內存中，下次操作直接把內存中RDD作爲輸入，避免了Hadoop MapReduce的大IO操作；

1 Java

常用語法
WEB開發：springboot

.java文件編譯過程和執行過程分析以及計算機簡單認識:系統的講解了計算機的組成和java文件編譯，jvm解釋的過程

2 SQL

常用SQL語法
增刪改查、內連外連等

3 大數據組件底層原理

瞭解基本原理和使用方法即可

EMR - 阿里雲大數據平臺/工業場景下的大數據工具

E-MapReduce介紹
E-MapReduce的用途

通過E-MapReduce，您可以從繁瑣的集羣構建相關的採購、準備和運維等工作中解放出來，只關心自己應用程序的處理邏輯（8-10步驟）即可。
E-MapReduce還提供了靈活的搭配組合方式，您可以根據自己的業務特點選擇不同的集羣服務。例如，如果您的需求是對數據進行日常統計和簡單的批量運算，則可以只選擇在E-MapReduce中運行Hadoop服務；如果您有流式計算和實時計算的需求，則可以在Hadoop服務基礎上再加入Spark服務。
E-MapReduce的組成
E-MapReduce最核心也是用戶直接面對的組件是集羣。E-MapReduce集羣是由一個或多個阿里雲ECS實例組成的Hadoop和Spark集羣。以 Hadoop爲例，每個ECS Instance上通常都運行了一些daemon進程（例如，NameNode、DataNode、ResouceManager 和 NodeManager），這些 daemon 進程共同組成了Hadoop集羣。其中運行NameNode和ResourceManager的節點稱爲Master節點，而運行DataNode和NodeManager的節點稱爲Slave節點。
包含一個Master節點和三個Slave節點的E-MapReduce集羣

E-MapReduce集羣是基於Hadoop的生態環境搭建的，可以與阿里雲的對象存儲服務（OSS）進行無縫數據交換。此外，E-MapReduce集羣也可以與雲數據庫（RDS）等雲服務無縫對接，方便您將數據在多個系統之間進行共享和傳輸，以滿足不同業務類型的訪問需要。

• Hadoop集羣
• Kafka集羣
• Zookeeper集羣
• Druid集羣

HDFS - 分佈式文件系統

與普通文件系統（Win、Linux、Mac）的不同就是，hdfs是分佈式文件系統。
good - HBase和HDFS的關係
hdfs簡單操作

MapReduce - 分佈式數據處理引擎

https://yq.aliyun.com/articles/340381
MapReduce是Google開發的C++編程工具，用於大規模數據集（大於1TB）的並行運算。概念"Map（映射）“和"Reduce（化簡）”，和他們的主要思想，都是從函數式編程語言裏借來的，還有從矢量編程語言裏借來的特性。
當前的軟件實現是指定一個Map（映射）函數，用來把一組鍵值對映射成一組新的鍵值對，指定併發的Reduce（化簡）函數，用來保證所有映射的鍵值對中的每一個共享相同的鍵組。

Map(映射)/Reduce(簡化)
https://www.liaoxuefeng.com/wiki/897692888725344/989703124920288

操作名稱	目的	輸入：輸出	並行
Map	映射	1:1	可以高度並行
Reduce	定義一個化簡函數，通過讓列表中的元素跟自己的相鄰的元素相加的方式把列表減半，如此遞歸運算直到列表只剩下一個元素	2:1	依舊可以並行，雖不如Map函數那麼並行

分佈和可靠性
MapReduce通過把對數據集的大規模操作分發給網絡上的每個節點實現可靠性；每個節點會週期性的把完成的工作和狀態的更新報告回來。如果一個節點保持沉默超過一個預設的時間間隔，主節點（類同Google File System中的主服務器）記錄下這個節點狀態爲死亡，並把分配給這個節點的數據發到別的節點。每個操作使用命名文件的原子操作以確保不會發生並行線程間的衝突；當文件被改名的時候，系統可能會把他們複製到任務名以外的另一個名字上去。（避免副作用）。
化簡操作工作方式很類似，但是由於化簡操作在並行能力較差，主節點會盡量把化簡操作調度在一個節點上，或者離需要操作的數據儘可能進的節點上了；這個特性可以滿足Google的需求，因爲他們有足夠的帶寬，他們的內部網絡沒有那麼多的機器。
用途
在Google，MapReduce用在非常廣泛的應用程序中，包括“分佈grep，分佈排序，web連接圖反轉，每臺機器的詞矢量，web訪問日誌分析，反向索引構建，文檔聚類,機器學習，基於統計的機器翻譯…”值得注意的是，MapReduce實現以後，它被用來重新生成Google的整個索引，並取代老的ad hoc程序去更新索引。
MapReduce會生成大量的臨時文件，爲了提高效率，它利用Google文件系統來管理和訪問這些文件。

HBase - 分佈式數據庫/NoSQL數據庫

HBase - 分佈式數據庫/NoSQL數據庫

Hive - 數據倉庫軟件/NOSQL數據庫

Hive - 數據倉庫軟件/NOSQL數據庫

Kudu - 大數據存儲引擎(列數據儲存結構)

Apache Kudu是一個爲了Hadoop系統環境而打造的列存儲管理器.
KUDU 的定位是 「Fast Analytics on Fast Data」，是一個既支持隨機讀寫、又支持 OLAP 分析的大數據存儲引擎。
在Kudu出現之前，Hadoop生態環境中的儲存主要依賴HDFS和HBase，追求高吞吐批處理的用例中使用HDFS，追求低延時隨機讀取用例下用HBase，而Kudu正好能兼顧這兩者。
數據高效處理的祕訣——Kudu實戰
Kudu異常總結

Kudu的主要優點：

• 快速處理OLAP（Online Analytical Processing）任務
• 集成MapReduce、Spark和其他Hadoop環境組件
• 與Impala高度集成，使得這成爲一種高效訪問交互HDFS的方法
• 強大而靈活的統一性模型
• 在執行同時連續隨機訪問時表現優異
• 通過Cloudera Manager可以輕鬆管理控制
• 高可用性，tablet server和master利用Raft Consensus算法保證節點的可用
• 結構數據模型

kudu使用時的優勢：
1）一個table由多個tablet組成，對分區查看、擴容和數據高可用支持非常好
2）支持update和upsert操作。
3）與imapla集成或spark集成後（dataframe）可通過標準的sql操作，使用起來很方便
4）可與spark系統集成

kudu使用時的劣勢：
1）只有主鍵可以設置range分區，且只能由一個主鍵，也就是一個表只能有一個字段range分區，且該字段必須是主鍵。
2）如果是pyspark連接kudu，則不能對kudu進行額外的操作；而scala的spark可以調用kudu本身的庫，支持kudu的各種語法。
3）kudu的shell客戶端不提供表schema查看。如果你不通過imapla連接kudu，且想要查看錶的元數據信息，需要用spark加載數據爲dataframe，通過查看dataframe的schema查看錶的元數據信息。
4）kudu的shell客戶端不提供表內容查看。如果你想要表的據信息，要麼自己寫腳本，要麼通過spark、imapla查看。
5）如果使用range 分區需要手動添加分區。假設id爲分區字段，需要手動設置第一個分區爲1-30.第二個分區爲30-60等等
6）時間格式是utc類型，需要將時間戳轉化爲utc類型，注意8個小時時差

常見的應用場景：

• 剛剛到達的數據就馬上要被終端用戶使用訪問到
• 同時支持在大量歷史數據中做訪問查詢和某些特定實體中需要非常快響應的顆粒查詢
• 基於歷史數據使用預測模型來做實時的決定和刷新
• 要求幾乎實時的流輸入處理

kudu的產生背景和應用場景
1.在 kudu 之前，大數據主要以兩種方式存儲：
第一種是靜態數據：以 HDFS 引擎作爲存儲引擎，適用於高吞吐量的離線大數據分析場景。
這類存儲的侷限性是數據無法進行隨機的讀寫和批量的更新操作。
第二種是動態數據：以 HBase作爲存儲引擎，適用於大數據隨機讀寫場景。這類存儲的侷限性是批量讀取吞吐量遠不如 HDFS、不適用於批量數據分析的場景。

2.從上面分析可知，這兩種數據在存儲方式上完全不同，進而導致使用場景完全不同，但在真實的場景中，邊界可能沒有那麼清晰，面對既需要隨機讀寫，又需要批量分析的大數據場景，該如何選擇呢？

3.這個場景中，單種存儲引擎無法滿足業務需求，我們需要通過多種大數據組件組合來滿足這一需求，一個常見的方案是：
數據實時寫入 HBase，實時的數據更新也在 HBase 完成，爲了應對 OLAP 需求，我們定時（通常是 T+1 或者 T+H）將 HBase的 數據寫成靜態的文件（Parquet）
導入到 OLAP 引擎（HDFS）。這一架構能滿足既需要隨機讀寫，又可以支持 OLAP 分析的場景。
但他有如下缺點：
第一：架構複雜。從架構上看，數據在 HBase、消息隊列Kafka、HDFS 間流轉，涉及環節太多，運維成本很高。
並且每個環節需要保證高可用、維護多個副本、存儲空間浪費。最後數據在多個系統上，對數據安全策略、監控等都提出了挑戰。
第二：時效性低。數據從 HBase 導出成靜態文件是週期性的，一般這個週期是一天（或一小時），在時效性上不是很高。
第三：難以應對後續的更新。真實場景中，總會有數據是延遲到達的。如果這些數據之前已經從 HBase 導出到 HDFS，
新到的變更數據就難以處理了，一個方案是把新變更的數據和原有數據進行對比，把不同的數據重新進行更新操作，這時候代價就很大了。
假如說，我們想要sql實時對大量數據進行分析該怎麼辦？或者是我想讓數據存儲能夠支持Upsert（更新插入操作），又該怎麼辦？所以這就是kudu的優勢。
KUDU 的定位是 Fast Analytics on Fast Data，是一個既支持隨機讀寫、又支持 OLAP 分析的大數據存儲引擎。

4.KUDU在 HDFS 和 HBase 這兩個中平衡了隨機讀寫和批量分析的性能，既支持了SQL實時查詢，也支持了數據更新插入操作。
完美的和impala集成，統一了hdfs數據源和kudu數據源，從而使得開發人員能夠高效的進行數據分析。

KUDU常用指令

KUDU&Impala基本操作
kudu表分區

所謂列存儲、行存儲數據模式，在底層的存儲、DDL等操作上各有不同，不過API級別都提供差不多的功能：增刪改查，不同數據庫對不同操作的性能各有不同而已

**impala kudu 操作sql語句：**
// 所有數據庫
show databases；
// 表結構描述
DESCRIBE kudu_test_table;
// 查詢
SELECT current_database();
select * from kudu_test_table limit 10;
// 插入(xu指定主鍵)
insert into kudu_test_table values ("[email protected]","123456","no","65246241","1000");
insert into kudu_test_table () values ("[email protected]","123456","no","65246241","1000");
// 更新(需指定主鍵)
UPDATE kudu_test_table set linghit_id = "654321" where $mail= "[email protected]";
UPDATE kudu_test_table set linghit_id = "7654321" where linghit_id= "654321";
// 刪除行(需指定主鍵)
delete from linghit_bigdata_userinfo where user_center_id="[email protected]" and log_time=1584633600 and product_id="5648";
// 追加列，新增字段/列名
alter table kudu_test_table add columns(salary string,time_stamp string);
// 刪除
DROP TABLE kudu_test_table;
// 新增分區
與mysql類似的，kudu中range分區的表也是支持增加分區的，增加分區的語句爲：
alter table new_table add range partition 30<=values<40
EXAMPLE: KUDU修改分區，查看分區爲什麼只能在外部表上操作，外部表內部表的映射可以共享表結構嗎
ALTER TABLE linghit_bigdata_dwd.linghit_bigdata_userinfo_external ADD RANGE PARTITION unix_timestamp("2020-04-13") <= VALUES < unix_timestamp(date_add("2020-04-13", 3));
// 刪除分區
alter table new_table DROP RANGE PARTITION 30<=values<40 
// 查看分區
1. show partitions tablename(外部表);
2. alter table new_table add range partition 30<=values<40; // 再增加一次試試反饋

// 從Impala中創建KUDU中XX表的外部表
CREATE EXTERNAL TABLE kudu_test_table
STORED AS KUDU
TBLPROPERTIES (
  'kudu.master_addresses' = 'emr-header-1:7051,emr-header-2:7051,emr-worker-1:7051',
  'kudu.table_name' = 'java_example-1580975328237'
);
-- impala創建外部關聯表
CREATE EXTERNAL TABLE linghit_bigdata_userinfo_external
STORED AS KUDU
TBLPROPERTIES (
  'kudu.master_addresses' = '172.16.110.88:7051,172.16.110.87:7051,172.16.110.83:7051', 
  'kudu.table_name' = 'linghit_bigdata_userinfo'
);

// 從impala創建內部表
CREATE TABLE kudu_test_table_4
(
  id STRING,
  name STRING,
  PRIMARY KEY(id)
)
PARTITION BY HASH PARTITIONS 16
STORED AS KUDU
TBLPROPERTIES (
  'kudu.master_addresses' = '172.16.110.88:7051,172.16.110.87:7051,172.16.110.83:7051', 
);

• Kudu 分區
  kudu的分區方式
  kudu-impala分區表（hash和range分區）
  impala建Kudu表語句中的PARTITION BY的作用

----------------------------------------
基本常用操作：
	--描述表
	DESCRIBE tabel_name;
	--查看分區情況
	SHOW PARTITIONS table_name;
	--查看當前使用數據庫
	SELECT current_database();
	--查看建表語句
	SHOW CREATE TABLE table_name
-------------------------------------------
 
1.建表
	（1）hash分區
		--主鍵兩個字段，分區字段未指定 hash分區
		create table kudu_first_table(
		id int,
		name string,
		age int,
		gender string,
		primary key(id,name)
		) partition by hash partitions 4
		stored as kudu;
 
		--主鍵兩個字段，分區字段指定，hash分區
		create table specify_partition_column(
		id int,
		name string,
		age int,
		gender string,
		primary key(id,name)
		) partition by hash(id) partitions 3
		stored as kudu;
 
		--主鍵兩個字段，分區字段指定一個字段，hash分區
		create table specify_partition_one_column(
		id int,
		name string,
		age int,
		gender string,
		primary key(id)
		) partition by hash(id) partitions 3
		stored as kudu;
 
		**區別：未指定分區字段時，其分區字段默認是主鍵，若主鍵有兩個列則分區字段爲兩個，指定分區字段時，需要分區列是主鍵的子集；否則會報錯「 Only key columns can be used in PARTITION BY」
		**不指定分區：表依然會創建，但是隻有一個分區，會提示「Unpartitioned Kudu tables are inefficient for large data sizes.」
 
	（2）range分區：主要針對時間進行range分區
 
		CREATE TABLE cust_behavior (
		  _id BIGINT PRIMARY KEY,
		  salary STRING,
		  edu_level INT,
		  usergender STRING,
		  `group` STRING,
		  city STRING,
		  postcode STRING,
		  last_purchase_price FLOAT,
		  last_purchase_date BIGINT,
		  category STRING,
		  sku STRING,
		  rating INT,
		  fulfilled_date BIGINT
		)
		PARTITION BY RANGE (_id)
		(
		    PARTITION VALUES < 1439560049342,
		    PARTITION 1439560049342 <= VALUES < 1439566253755,
		    PARTITION 1439566253755 <= VALUES < 1439572458168,
		    PARTITION 1439572458168 <= VALUES < 1439578662581,
		    PARTITION 1439578662581 <= VALUES < 1439584866994,
		    PARTITION 1439584866994 <= VALUES < 1439591071407,
		    PARTITION 1439591071407 <= VALUES
		)
		STORED AS KUDU;
 
		**優勢：可以根據數據的具體情況建立分區，比如：建立2017年之前的分區，2017-2018,2018-2019，2019-2020,2020-2021，。。。
		**劣勢：如果使用單級range分區的話，容易產生數據熱點問題（可混合hash分區使用）、
		在range分區中，如果有不止一個字段作爲分區字段的話也可以，語法暫時不清楚
		如果插入一條主鍵的值不落在任何range區間時會插入失敗，並報錯
 
	（3）混合分區
		create table tw_details4(
		user_id string,
		event_date string,
		event string,
		properties string,
		customer_id int,
		project_id int,
		primary key(event_date,event,user_id)
		) partition by hash(user_id) partitions 3, range(event_date)(
		partition values < '2017-01-01',
		partition '2017-01-01' <= values < '2018-01-01',
		partition '2018-01-01' <= values < '2019-01-01',
		partition '2019-01-01' <= values < '2020-01-01',
		partition '2020-01-01' <= values < '2021-01-01'
		) stored as kudu;
 
		**優勢：可以根據時間進行檢索，來減少需要scan的tablet，插入的時候不會只有一個tabletserver產生熱點
 
	（4）CTAS方式創建表
		CREATE TABLE kudu_ti_event_fact_copy
			primary key(user_id,event_date)
			partition by hash(user_id) partitions 3
			stored as kudu
		as select user_id,event_date,properties
			from auto3.ti_event_fact;
 
2.創建數據庫
	impala創建數據庫與hive一樣，create database db_name,但是這個數據庫只是一個impala端的namespace，kudu官網中沒有提到數據庫的概念，猜測可能是沒有這個概念
	impala中創建表的時候比如在test數據庫中創建table_test對應在kudu中爲 test:table_test
 
3.插入數據
	(1)insert into table1 values(v1,v2,v3)
	(2)insert into table1 select v1,v2,v3 from table2;
	**（3）upsert into table1 values(v1,v2,v3) --根據主鍵判定，若已經存在則更新，若不存在則插入
 
4.更改column
	（1）update語法
		UPDATE kudu_first_table set age = 32 where id= 2;
		UPDATE kudu_first_table set age = 31 where gender= 'female';
		其中where條件後面的column不是主鍵也可以但是更改的範圍會擴大
		**主鍵中不支持更改，只能刪除後重新添加
 
	（2）upsert語法
		upsert into table1 values(v1,v2,v3)
		**需要更新所有字段
5.更改表
	（1）修改表名，修改的只是表在impala中的映射名
		alter table kudu_ti_event_fact_copy rename to kudu_ti_event_fact_copy_rename;
	（2）修改kudu存儲的表名，但是不會改變在impala端的映射表名，也就是在impala中依然訪問更改之前的表名
		ALTER TABLE kudu_ti_event_fact_copy_rename
		SET TBLPROPERTIES('kudu.table_name' = 'kudu_ti_event_fact_copy');
	（3）修改列屬性
		-- --**不支持---
	（4）添加列
		alter table kudu_ti_event_fact_copy_rename add columns(method string,time_stamp string);
	（5）刪除列
		ALTER table kudu_ti_event_fact_copy_rename drop column method;
	（6）刪除分區
		ALTER TABLE range_partition_table DROP RANGE PARTITION VALUES < '2017-01-01';
	（7）添加分區
		alter table range_partition_table add range partition values < '2017-01-01';

• Kudu 鏈接方式
  • Kudu Sink Connector：封裝好不會報錯，但操作（增刪改）失敗的一些可能原因是：1.kudu表建表的服務器位置和你用代碼連接的位置不一樣，導致看到的表信息不一樣 2. 操作必須帶有主鍵，主鍵的數據類型必須與建表指定的一致 3. kudu建表時如果存在分區，需要看清楚主鍵的上下限，在上下限中間取值，避免操作的時候出現主鍵錯誤 4. 使用Impala建表和java api建表表名會不一樣，impala建表表名會顯示impala:

常見錯誤

• kudu 插入報錯之主鍵不存在：
  Row error for primary key=“9”, tablet=null, server=xx, status=Not found: key not found
  這個報錯的意思是說沒有主鍵爲9的數據，因爲你使用的是update模式去更新數據，更新數據，那麼數據必須先存在。

• kudu 插入報錯之分區不存在：
  Row error for primary key=“156307740800000040\x00\x00\xDE\x93\xC8\x00X01”, tablet=null, server=null, status=Not found: ([0x00000003DE88AF00, 0x00000003DE99D280))
  相應的kudu分區不存在

KUDU容易出錯的三個地方：

1. tables忘記加上kudu表名(使用flink kudu sink connector的時候)
2. kudu字段的數據類型不匹配
3. kudu分區不存在
4. 更新、刪除數據行需要指定所有的主鍵，更新的話對應主鍵的數據必須存在

kudu常見錯誤整理

Flume - 數據採集

數據採集層
Flume 1.9.0 User Guide
Flume入門
Flume學習之路 （一）Flume的基礎介紹
flume是一個分佈式、可靠、和高可用的海量日誌採集、聚合和傳輸的系統。支持在日誌系統中定製各類數據發送方，用於收集數據;同時，Flume提供對數據進行簡單處理，並寫到各種數據接受方(比如文本、HDFS、Hbase等)的能力 。

/apache-flume-1.8.0-bin/conf/flume.conf
http source
flume的過濾器: KongKim-Flume.git 通過ip解析了城市之類的信息

1. file channel
2. memory channel2
   hdfs Sinks
   kafka sink2
   修改完 flume.conf 不用重啓,自己就輪訓了

Kafka - 消息系統

Apache Kafka教程 - W3Cschool
Kafka命令行消費、生產Demo
Flink從kafka中讀數據存入Mysql Sink：裏面含kafka生產者Java代碼，maven沒有導入kafka包，但是kafka producer可以導入org.apache.kafka.clients.producer.KafkaProducer;說明flink-connector-kafka包起作用了
Flink消費Kafka數據時指定offset的五種方式
kafka中文簡介
Kafka在Linux環境下搭建過程
Kafka查看topic、consumer group狀態命令
RabbitMQ消息隊列 簡介以及使用場景

在大數據中，使用了大量的數據。 關於數據，我們有兩個主要挑戰。第一個挑戰是如何收集大量的數據，第二個挑戰是分析收集的數據。 爲了克服這些挑戰，您必須需要一個消息系統。

Kafka專爲分佈式高吞吐量系統而設計。 Kafka往往工作得很好，作爲一個更傳統的消息代理的替代品。 與其他消息傳遞系統相比，Kafka具有更好的吞吐量，內置分區，複製和固有的容錯能力，這使得它非常適合大規模消息處理應用程序。

什麼是消息系統？
Apache Kafka是一個分佈式發佈 - 訂閱消息系統和一個強大的隊列，可以處理大量的數據，並使您能夠將消息從一個端點傳遞到另一個端點。 Kafka適合離線和在線消息消費。 Kafka消息保留在磁盤上，並在羣集內複製以防止數據丟失。 Kafka 構建在ZooKeeper同步服務之上。 它與Apache Storm和Spark非常好地集成，用於實時流式數據分析。

消息系統（生產者 - 消費者）：

1. 點對點消息系統 ：在點對點系統中，消息被保留在隊列中。 一個或多個消費者可以消耗隊列中的消息，但是特定消息只能由最多一個消費者消費。 一旦消費者讀取隊列中的消息，它就從該隊列中消失。該系統的典型示例是訂單處理系統，其中每個訂單將由一個訂單處理器處理，但多個訂單處理器也可以同時工作。
2. 發佈 - 訂閱消息系統：消息被保留在主題中。 與點對點系統不同，消費者可以訂閱一個或多個主題並使用該主題中的所有消息。 在發佈 - 訂閱系統中，消息生產者稱爲發佈者，消息使用者稱爲訂閱者。 一個現實生活的例子是Dish電視，它發佈不同的渠道，如運動，電影，音樂等，任何人都可以訂閱自己的頻道集，並獲得他們訂閱的頻道時可用。

好處
以下是Kafka的幾個好處 -

• 可靠性 - Kafka是分佈式，分區，複製和容錯的。
• 可擴展性 - Kafka消息傳遞系統輕鬆縮放，無需停機。
• 耐用性 - Kafka使用分佈式提交日誌，這意味着消息會盡可能快地保留在磁盤上，因此它是持久的。
• 性能 - Kafka對於發佈和訂閱消息都具有高吞吐量。 即使存儲了許多TB的消息，它也保持穩定的性能。
  Kafka非常快，並保證零停機和零數據丟失。

用例
Kafka可以在許多用例中使用。 其中一些列出如下 -

• 指標 - Kafka通常用於操作監控數據。 這涉及聚合來自分佈式應用程序的統計信息，以產生操作數據的集中饋送。
• 日誌聚合解決方案 - Kafka可用於跨組織從多個服務收集日誌，並使它們以標準格式提供給多個服務器。
• 流處理 - 流行的框架(如Storm和Spark Streaming)從主題中讀取數據，對其進行處理，並將處理後的數據寫入新主題，供用戶和應用程序使用。 Kafka的強耐久性在流處理的上下文中也非常有用。

需要Kafka
Kafka是一個統一的平臺，用於處理所有實時數據Feed。 Kafka支持低延遲消息傳遞，並在出現機器故障時提供對容錯的保證。 它具有處理大量不同消費者的能力。 Kafka非常快，執行2百萬寫/秒。 Kafka將所有數據保存到磁盤，這實質上意味着所有寫入都會進入操作系統(RAM)的頁面緩存。 這使得將數據從頁面緩存傳輸到網絡套接字非常有效。

基礎知識
消費者：（Consumer）：從消息隊列中請求消息的客戶端應用程序
生產者：（Producer） ：向broker發佈消息的應用程序
AMQP服務端（broker）：用來接收生產者發送的消息並將這些消息路由給服務器中的隊列，便於fafka將生產者發送的消息，動態的添加到磁盤並給每一條消息一個偏移量，所以對於kafka一個broker就是一個應用程序的實例
主題（Topic）：一個主題類似新聞中的體育、娛樂、教育等分類概念，在實際工程中通常一個業務一個主題
-分區（Partition）：一個Topic中的消息數據按照多個分區組織，分區是kafka消息隊列組織的最小單位，一個分區可以看作是一個FIFO（ First Input First Output的縮寫，先入先出隊列）的隊列
每一個分區都可以有多個副本，以防止數據的丟失
某一個分區中的數據如果需要更新，都必須通過該分區所有副本中的leader來更新
消費者可以分組，比如有兩個消費者組A和B，共同消費一個topic：order_info,A和B所消費的消息不會重複，比如 order_info 中有100個消息，每個消息有一個id,編號從0-99，那麼，如果A組消費0-49號，B組就消費50-99號.
同一個消費組的多個消費者相當於一個消費者去消費數據，提高了消費的效率。topic的分區，給消費順序帶來了一些麻煩，通過了解到kafka的底層原理後，在遇到問題時，就可能解釋並解決。

消費者在具體消費某個topic中的消息時，可以指定起始偏移量
kafka分區是提高kafka性能的關鍵所在，當你發現你的集羣性能不高時，常用手

作者：騎着大象去上班
鏈接：https://www.jianshu.com/p/bfbb8a5e2f63
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

Spark - 大數據計算引擎

Spark 是一個同時支持批處理和流計算的分佈式計算系統。Spark 的所有計算均構建於 RDD 之上，RDD 通過算子連接形成 DAG 的執行計劃，RDD 的確定性及不可變性是 Spark 實現故障恢復的基礎。Spark Streaming 的 D-Stream 本質上也是將輸入數據分成一個個 micro-batch 的 RDD。

基於內存的大數據計算框架，比依賴於HDFS讀取存儲的MR要快、方便的多，更具備實時性
Spark既有官方語言scala，也有java和python版本的api。

Spark入門基礎教程
Spark 教程
在linux上安裝spark詳細步驟
《Spark官方文檔》Spark操作指南

Spark on yarn模式
SparkOnYarn專題四–cluster模式和client模式資源分配的詳解
Spark中yarn模式兩種提交任務方式
spark中dag的介紹
Spark基礎 DAG
spark與hbase交互錯誤：org.apache.htrace
關於怎麼解決java.lang.NoClassDefFoundError錯誤
Spark SQL教程
Spark SQL
SparkConf 配置的用法
Idea 裏面創建Mavenproject 利用sparkSQL操作Hive
SparkSQL操作Hive Table - enableHiveSupport():.enableHiveSupport().getOrCreate();
Java接入Spark之創建RDD的兩種方式和操作RDD
spark-sql createOrReplaceTempView 和createGlobalTempView區別
SparkSQLDemo初嘗－－SparkSession鏈接數據庫
spark sql——5. spark sql操作mysql表
cdh5.13 spark連接hive數據源
spark動態資源（executor）分配

HDFS MR是批處理，Spark streaming和Flink是流處理。我理解是批處理是全量，流處理是無界數據分區進行處理，微批處理是分batch對流數據進行處理

流處理和批處理框架的異同：講述了流處理，微批處理的原理、區別；消息傳輸保障三種模式（at most once，at least once和exactly once）的原理

Spark 其他
Spark認識&環境搭建&運行第一個Spark程序
《Spark官方文檔》Spark操作指南

• 部署PySpark
  http://blog.csdn.net/hjxinkkl/article/details/57083549?winzoom=1
  http://blog.csdn.net/yiyouxian/article/details/51020334

• pyspark部署中相關錯誤
  http://makaidong.com/aiyuxi/348_1857825.html
  http://blog.csdn.net/pipisorry/article/details/52916307
  https://www.cnblogs.com/hark0623/p/4170172.html
  https://stackoverflow.com/questions/19620642/failed-to-locate-the-winutils-binary-in-the-hadoop-binary-path
  改了兩個地方：
  1.os.environ[‘JAVA_HOME’] = “D:\Java\jdk1.8.0_131” 在代碼中加入這句
  2.修改 D:\hadoop-2.7.4\libexec\hadoop-config.sh 162行
  增加 export JAVA_HOME = “D:\Java\jdk1.8.0_131”
  3.之後出現的錯誤
  Py4JNetworkError An error occurred while trying to connect to the Java server (127.0.0.1:51499)
  不影響使用

pyspark的使用和操作(基礎整理)

IDEA安裝Scala，版本對應
詳見有道雲筆記-MAC IDEA SPARK（SCALA）環境配置

Flink - 大數據計算引擎

統一批處理流處理——Flink批流一體實現原理
Flink,Storm,SparkStreaming性能對比
Flink與storm,spark的區別, 優勢, 劣勢.

這幾年大數據的飛速發展，出現了很多熱門的開源社區，其中著名的有 Hadoop、Storm，以及後來的 Spark，他們都有着各自專注的應用場景。Spark 掀開了內存計算的先河，也以內存爲賭注，贏得了內存計算的飛速發展。Spark 的火熱或多或少的掩蓋了其他分佈式計算的系統身影。就像 Flink，也就在這個時候默默的發展着。

大數據發展階段：第一階段-第四階段
首先第一代的計算引擎，無疑就是 Hadoop 承載的 MapReduce。這裏大家應該都不會對 MapReduce 陌生，它將計算分爲兩個階段，分別爲 Map 和 Reduce。對於上層應用來說，就不得不想方設法去拆分算法，甚至於不得不在上層應用實現多個 Job 的串聯，以完成一個完整的算法，例如迭代計算。

由於這樣的弊端，催生了支持 DAG 框架的產生。因此，支持 DAG 的框架被劃分爲第二代計算引擎。如 Tez 以及更上層的 Oozie。這裏我們不去細究各種 DAG 實現之間的區別，不過對於當時的 Tez 和 Oozie 來說，大多還是批處理的任務。

接下來就是以 Spark 爲代表的第三代的計算引擎。第三代計算引擎的特點主要是 Job 內部的 DAG 支持（不跨越 Job），以及強調的實時計算。在這裏，很多人也會認爲第三代計算引擎也能夠很好的運行批處理的 Job。

隨着第三代計算引擎的出現，促進了上層應用快速發展，例如各種迭代計算的性能以及對流計算和 SQL 等的支持。Flink 的誕生就被歸在了第四代。這應該主要表現在 Flink 對流計算的支持，以及更一步的實時性上面。當然 Flink 也可以支持 Batch 的任務，以及 DAG 的運算。

分佈式流處理是對無邊界數據集進行連續不斷的處理、聚合和分析。它跟MapReduce一樣是一種通用計算，但我們期望延遲在毫秒或者秒級別。這類系統一般採用有向無環圖（DAG）。

一個通俗易懂的概念: Apache Flink 是近年來越來越流行的一款開源大數據計算引擎，它同時支持了批處理和流處理.
這是對Flink最簡單的認識, 也最容易引起疑惑, 它和storm和spark的區別在哪裏? storm是基於流計算的, 但是也可以模擬批處理, spark streaming也可以進行微批處理, 雖說在性能延遲上處於亞秒級別, 但也不足以說明Flink崛起如此迅速(畢竟從spark遷移到Flink是要成本的).

網上最熱的兩個原因:

• Flink靈活的窗口
• Exactly once語義保證

這兩個原因可以大大的解放程序員, 加快編程效率, 把本來需要程序員花大力氣手動完成的工作交給框

Apache Flink擅長處理無界和有界數據集。精確控制時間和狀態使Flink的運行時能夠在無界流上運行任何類型的應用程序。有界流由算法和數據結構內部處理，這些算法和數據結構專門針對固定大小的數據集而設計，從而產生出色的性能。

1.什麼是 Window
在流處理應用中，數據是連續不斷的，因此我們不可能等到所有數據都到了纔開始處理。當然我們可以每來一個消息就處理一次，但是有時我們需要做一些聚合類的處理，例如：在過去的1分鐘內有多少用戶點擊了我們的網頁。在這種情況下，我們必須定義一個窗口，用來收集最近一分鐘內的數據，並對這個窗口內的數據進行計算。

窗口可以是時間驅動的(Time Window, 例如: 每30秒鐘), 也可以是數據驅動的(Count Window, 例如: 每一百個元素). 一種經典的窗口分類可以分成: 翻滾窗口(Tumbling Window, 無重疊), 滾動窗口(Sliding Window, 有重疊), 和會話窗口(Session Window，活動間隙).

我們舉個具體的場景來形象地理解不同窗口的概念. 假設, 淘寶網會記錄每個用戶每次購買的商品個數, 我們要做的是統計不同窗口中用戶購買商品的總數. 下圖給出了幾種經典的窗口切分概述圖:

大數據起源自批處理, spark最初的定位就是改進hadoop, 更快速的進行批處理. storm擅長的則是進行無狀態的流計算(在無狀態的流計算領域, 它的延遲是最小的), 而Flink則是storm的下一代解決方案(當然Flink的設計之初並不是改進storm), 能夠進行高吞吐,低延遲(毫秒級)的有狀態流計算.

Flink基本架構圖

Livy - 基於Apache Spark的REST服務

Livy：基於Apache Spark的REST服務
Spark之livy的安裝使用

EMR-3.20+, 自帶 livy 0.6.0

livy支持兩種兩種任務提交方案：
1、交互式：說白了，就是把原本在spark-shell裏面執行的語句，通過http請求發送到livy服務端，然後livy在服務端開啓spark-shell執行你傳過來的語句；
2、批處理式：說白了，幫你做spark-submit的工作，同樣通過http請求吧參數發到livy服務端。

使用REST接口調用Spark——Apache Livy使用筆記

Impala - SQL查詢引擎

impala教程
Impala和Hive的關係：寫的很好
Impala Shell 簡單命令
Impala Shell常用命令行選項與常用命令

什麼是Impala？
Impala是用於處理存儲在Hadoop集羣中的大量數據的MPP（大規模並行處理）SQL查詢引擎。 它是一個用C ++和Java編寫的開源軟件。 與其他Hadoop的SQL引擎相比，它提供了高性能和低延遲。

換句話說，Impala是性能最高的SQL引擎（提供類似RDBMS的體驗），它提供了訪問存儲在Hadoop分佈式文件系統中的數據的最快方法。

爲什麼選擇Impala？
Impala通過使用標準組件（如HDFS，HBase，Metastore，YARN和Sentry）將傳統分析數據庫的SQL支持和多用戶性能與Apache Hadoop的可擴展性和靈活性相結合。

• 使用Impala，與其他SQL引擎（如Hive）相比，用戶可以使用SQL查詢以更快的方式與HDFS或HBase進行通信。
• Impala可以讀取Hadoop使用的幾乎所有文件格式，如Parquet，Avro，RCFile。

與Apache Hive不同，Impala不基於MapReduce算法。 它實現了一個基於守護進程的分佈式架構，它負責在同一臺機器上運行的查詢執行的所有方面。

因此，它減少了使用MapReduce的延遲，這使Impala比Apache Hive快。Hive底層採用MR進行SQL操作。

Impala的優點

• 使用impala，您可以使用傳統的SQL知識以極快的速度處理存儲在HDFS中的數據。

• 由於在數據駐留（在Hadoop集羣上）時執行數據處理，因此在使用Impala時，不需要對存儲在Hadoop上的數據進行數據轉換和數據移動。

• 使用Impala，您可以訪問存儲在HDFS，HBase和Amazon s3中的數據，而無需瞭解Java（MapReduce作業）。您可以使用SQL查詢的基本概念訪問它們。

• 爲了在業務工具中寫入查詢，數據必須經歷複雜的提取 - 變換負載（ETL）週期。但是，使用Impala，此過程縮短了。加載和重組的耗時階段通過新技術克服，如探索性數據分析和數據發現，使過程更快。

• Impala正在率先使用Parquet文件格式，這是一種針對數據倉庫場景中典型的大規模查詢進行優化的柱狀存儲佈局。

Impala和關係數據庫

Impala，Hbase和Hive
Cloudera Impala使用與Hive相同的查詢語言，元數據和用戶界面，但在某些方面它與Hive和HBase不同。 下表介紹了HBase，Hive和Impala之間的比較分析。

在Impala中，您無法更新或刪除單個記錄。Impala不支持事務。Impala不支持索引。Impala存儲和管理大量數據(PB)。

Impala的缺點

• Impala不提供任何對序列化和反序列化的支持。
• Impala只能讀取文本文件，而不能讀取自定義二進制文件。
• 每當新的記錄/文件被添加到HDFS中的數據目錄時，該表需要被刷新。

使用
除了Impala shell之外，您還可以使用Hue瀏覽器與Impala進行通信。

Impala架構
impala與其存儲引擎解耦。 它有三個主要組件，即Impala daemon（Impalad），Impala Statestore和Impala元數據或metastore。
https://www.w3cschool.cn/impala/impala_architecture.html

Impala視圖
視圖僅僅是存儲在數據庫中具有關聯名稱的Impala查詢語言的語句。 它是以預定義的SQL查詢形式的表的組合。
視圖可以包含表的所有行或選定的行。 可以從一個或多個表創建視圖。 視圖允許用戶 -

• 以用戶或用戶類發現自然或直觀的方式結構化數據。
• 限制對數據的訪問，以便用戶可以看到和（有時）完全修改他們需要的內容，而不再更改。
• 彙總可用於生成報告的各種表中的數據。

視圖也可以理解成一張表，只是一張繪製了表格線和表頭的表。

常用命令

SELECT VERSION();

使用curl快速重啓impala
https://www.cnblogs.com/sdhzdtwhm/p/10253861.html

Parquet

數據格式
爲什麼我們選擇parquet
Parquet介紹及簡單使用
parquet常用操作
good - 深入分析 Parquet 列式存儲格式

Phoenix - HBase sql引擎

Sqoop

Apache Sqoop（TM）是一種用於在Hadoop和結構化數據存儲（如關係數據庫）之間高效傳輸批量數據的工具。
一個組織中有價值的數據都存儲在關係型數據庫系統等結構化存儲器中。Sqoop允許用戶將數據從結構化存儲器抽取到Hadoop中，用於進一步的處理。抽取出的數據可以被MapReduce程序使用，也可以被其他類似亍Hive的工具使用。一旦生成最終的分析結果，Sqoop便可以將這些結果導回數據存儲器，供其他客戶端使用。

關係型數據庫 < – > Hadoop

全量、增量導入導出

sqoop 導入導出數據命令參數詳解
Sqoop 常用命令及參數
Sqoop 複製mysql表結構建表、從mysql導入數據到hive
Sqoop 導入及導出表數據案例
sqoop導入數據到hive查詢全部爲null 、 sqoop導入數據到hive數據增多

target-dir導入到哪一個HDFS目錄
注意：指定的hdfs的目錄不能存在，因爲sqoop會將這個目錄作爲MapReduce的輸出目錄。
我認爲僅僅只是作爲mapreduce中間計算過程的臨時文件夾，執行完會自行刪除中間結果。hive表的位置取決於–hive-table參數
sqoop執行的時候會檢測對應的hive表，如果沒有就創建
CREATE TABLE IF NOT EXISTS linghit_bigdata_ods.u_visitor

  # Sqoop example
  jdbcurl="jdbc:mysql://$host:3306/$db_name?useUnicode=true&characterEncoding=utf8&tinyInt1isBit=false"  tinyInt1isBit禁止自動轉換&useUnicode/characterEncoding 編碼參數，解決中文亂碼問題
  sqoop import --connect "$jdbcurl" \
  --username $username \
  --password $password \
  --columns "user_id,account,email,phone,password,status,create_at,update_at" \
  --query "select * from u_visitor where create_at>='$day_init 00:00:00' and \$CONDITIONS" \ 儘量不要用*，寫出具體字段，因爲mysql端可能會不通知你的情況下增加字段
  --hive-table db.table_name \
  --hive-drop-import-delims \
  --split-by 'user_id' \
  --target-dir "/user/hive/warehouse/tmp/dataceter_u_account" \
  --delete-target-dir \
  --hive-partition-key row_date \  分區表，分區字段
  --hive-partition-value $day_init \
  --hive-overwrite \
  --null-string '\\N' \  string類型的字段，當Value是NULL，替換成指定的字符\N
  --null-non-string '\\N' \ 非string類型的字段，當Value是NULL，替換成指定的字符\N
  --fields-terminated-by "\t" \  hive表中字段分隔符
  --num-mappers 1 \
  --hive-import 

// LIMIT
–query “select id,lid,teacher_uid,user_id,server_id,server_name,amount,created_at,order_id from yi_live_server_pay where $CONDITIONS LIMIT 100”

–null-string ‘@@@’
–null-non-string ‘###’
備註:
–null-string含義是 string類型的字段，當Value是NULL，替換成指定的字符，該例子中爲@@@
–null-non-string 含義是非string類型的字段，當Value是NULL，替換成指定字符，該例子中爲###

1. sqoop導入數據到hive查詢全部爲null
   從postgresql或者mysql來的數據的分隔符則應該爲：’\0001’，需要在sqoop指令中進行指定–fields-terminated-by “\0001”

2. sqoop導入數據到hive數據增多
   導入的數據默認的列分隔符是’\001’，默認的行分隔符是’\n’。
   這樣問題就來了，如果導入的數據中有’\n’，hive會認爲一行已經結束，後面的數據被分割成下一行。這種情況下，導入之後hive中數據的行數就比原先數據庫中的多，而且會出現數據不一致的情況。
   簡單的解決辦法就是加上參數 –hive-drop-import-delims 來把導入數據中包含的hive默認的分隔符去掉。

3. 我們用sqoop，並且採用query的時候，我們最好使用雙引號，而且如果有where語句，必須加上“\CONDITIONS”，注意有“\”進行轉義。

--query "select * from u_product_relation where DATE_FORMAT(created_at,'%Y-%m-%d')='$day_init' and \$CONDITIONS" \

–connect 鏈接對應的數據庫
–query 去數據庫查需要的數據出來
如果沒有數據遷移到hive，可以先複製–query 中的mysql語句到mysql命令行試試是否有錯
https://blog.csdn.net/IKnowNothinglee/article/details/90640912

4. Error converting column: 2 to INT
   無所謂，僅僅只是在impala中解析hive表會出現這個警告，在hive中查詢則是正常的
   It doesn’t matter, just not parse in impala,the data is existed in hive table;
   Impala Can Not Parse “null” Values in Numeric Fields, Raises “Error converting column: TO INT (Data is: null)” on the BDA Instead (Doc ID 2154903.1)
   Ref
   but I find that the null values in the HDFS file are replaced by ‘N’ instead of ‘\N’ :
   Which results to unrecognized NULL values mostly for the STRING type (because for the INT type the ‘N’ is considered like NULL…).
   Ref

5. Sqoop創建的hive表部分字段的數據格式和mysql對不上
   遇到這種情況，我們可以採用自己先來建對應的hive表，再用sqoop來遷移。

如果mysql數據不大，只是用來測試的話，也可以先讓sqoop默認去建造hive表，然後用show create table tablename來查看建表語句
// 查看hive建表語句
show create table linghit_bigdata_ods.u_account;

爲了預防這種情況，我們在sqoop遷移完數據之後，最好和mysql的數據比較一下，作爲檢驗

6. sqoop tinyint變成了null
   只能將那個字段的數據格式進行轉化，
   https://www.cnblogs.com/guozhen/p/9836459.html
   https://blog.csdn.net/weixin_38750084/article/details/82873171

7. 查詢語句中出現sql關鍵字
   –columns指令出現了默認關鍵字的話，不需要轉義，它只對應hive表中對應的字段
   –query就要加上反引號，並且反引號需要用’'進行轉義
   –columns “id,name,describe,sort,created_at,updated_at,deleted_at”
   –query “select id,name,`describe`,`sort`,created_at,updated_at,deleted_at from groups WHERE $CONDITIONS” \

8. 出現hive表中只有一個字段有值，其他字段都爲NULL

• 檢查下hive表字段和mysql字段是否數量一致
• 試試–fields-terminated-by “\0001”

sqoop允許強轉的的數據格式

9. ERROR tool.ImportTool: Import failed: java.io.IOException: Generating splits for a textual index column allowed only in case of “-Dorg.apache.sqoop.splitter.allow_text_splitter=true” property passed as a parameter

中間如果註釋掉一行，就會報這個錯
 --target-dir "/user/hive/warehouse/tmp/" \
 # --delete-target-dir \
 --hive-partition-key row_date \
 --hive-partition-value $day_init \ 

Ref

10. tinyint(1) 數據格式自動變成Boolean 數據格式
    sqoop從mysql導入數據到hive時tinyint(1)格式自動變成Boolean解決方案
    在jdbc的連接後面加上：tinyInt1isBit=false
    –connect jdbc:mysql://192.168.9.80:3306/kgc_behivour_log?tinyInt1isBit=false

11. Hive數據類型
    Hive之數據類型

sqoop入門教程
sqoop client java api將mysql的數據導到hdfs
Sqoop之java API導入導出數據
Sqoop Java客戶端API與外部應用交互

Canal

基於數據庫增量日誌解析，提供增量數據訂閱&消費，目前主要支持了mysql
將mysql的數據與中間件的數據進行同步,Mysql -> Kafka
阿里開源Canal–①簡介
開源數據同步神器–canal

canal配置分爲兩部分：
　　① canal.properties (系統根配置文件)
　　② instance.properties (instance級別的配置文件，每個instance一份)，每個數據庫對應1個instance，如果需要同步多個數據庫，只需要在conf下創建多個destination目錄，創建多個instance.properties，並在每個instance.properties中配置需要的數據庫即可。

canal instance添加或修改properties配置文件，canal會自動掃描
但是canal.property不會，需要手動重啓

sh bin/startup.sh
sh bin/restart.sh
tailf logs/canal/canal.log

canal重啓文件不會丟失，接着之前mysql的binlog繼續往下走

canal重啓不會丟失數據的討論
https://github.com/alibaba/canal/issues/1078
https://github.com/alibaba/canal/issues/237
canal配置文件
數據同步canal服務端介紹
canal的配置詳解
Canal配置文件詳解

Knox

使用Apache Knox配置保護Spark/Hadoop
我們主要用Knox來保護Spark UI、HDFS UI、Yarn UI，以及thrift server。當然，Knox也不只是服務於Hadoop、Spark，對於Web化的應用，基本上都可以使用Knox做保護，例如用Knox做Tomcat代理
Hadoop生態圈-Knox網關的應用案例

Flume、ElasticSearch、Kibana

最全Flume、ElasticSearch、Kibana實現日誌實時展示
實時日誌收集-查詢-分析系統(Flume+ElasticSearch+Kibana)
Elasticsearch 權威指南（中文版）

Yarn、Pig、Storm、Zookeeper

廣證、仲奇沒有讓我看的技術點
Kibana：Kibana是從flume sink到的kafka端獲取數據
kibana ELK
YARN
Yarn資源調度工作原理
w3cschool的批處理入門:w3cschool的批處理入門教程，與shell編程是一樣的概念，與大數據裏的批處理不是一個概念

數倉設計思想/原則

數倉組成
ods、dwd、dws、ads

Other

yarn、npm比較
yarn詳細入門教程
YAML教程

SCALA筆記