spark的優化
1. 開發調優：
1) 避免創建重複的RDD
2) 儘可能複用同一個RDD
3) 對多次使用的RDD進行持久化
4) 儘量避免使用shuffle類算子
5) 使用map-side 的預聚合的shuffle
6) 使用高性能的算子
7) 廣播大變量
8) 使用Kryo優化序列化性能
9) 優化數據結構
2. 資源調優
1) 資源參數調優
Num-executors
excutor-memory
executor-cores
Driver-memory
Spark.default.parallelsm
spark.storage.memoryFraction
spark.shuffle.memoryFraction
3. 數據傾斜調優
1) Hive ETL 預處理
2) 過濾少數導致傾斜的Key
3) 提高shuffle操作的並行度
4) 兩階段的聚合（局部聚合+全局聚合）
5) 將 reduce join轉爲 map join
6) 採樣傾斜Key 並拆分join操作
7) 使用隨機前綴和擴容RDD進行join
8) 多種方案組合使用
4. Shuffle調優
Spark.shuffle.file.buffer
spark.reducer.maxSizeInFlight
spark.shuffle.io.maxRetries
spark.shuffle.io.retryWait
spark.shuffle.memoryFraction
spark.shuffle.manager
spark中的partition，task，stage等關係
1. 在HDFS上存儲的文件File一般有多個塊，成爲block。大小一般128M
2. Task 與 partition是對等的。 一個partition 對應（=） 一個task。輸入的文件被劃分成多個partition進行計算。
3. 一個executor有幾個core，則有幾個task被並行執行。一個core在一個時間內只能執行一個task任務。
4. 一個物理節點可以有多個worker；一個worker可以開啓多個 executor。
5. Task被執行的併發度 = Executor數目 * 每個Executor核數。
6. stage 是以 shuffle爲界限劃分。一次shuffle是一次stage，所以stage次數 = shuffle次數 + 1。
7. 一個job 由多組task組成，每組任務被稱爲一個stage
Spark stream 的batch duration，window duration， slide duration
1. Batch Duration： 批處理間隔， 是指Spark streaming以多少時間間隔爲單位提交任務邏輯
2. Window Duration：當前一個窗口處理數據的時間跨度。控制每次計算最近的多少個批次的數據。
3. Slide window：控制着計算的頻率。用來控制對新的 DStream 進行計算的間隔。
Sql 中的幾種join 操作含義
1. Inner join: 如果表中有至少一個匹配，則返回行 -- 並集返回
2. Left join: 即使右表中沒有匹配，也從左表返回所有的行 -- 左側全返回，右側不存在用null代替
3. RIGHT JOIN: 即使左表中沒有匹配，也從右表返回所有的行 -- 右側全返回，左側不存在用null代替
4. FULL JOIN: 只要其中一個表中存在匹配，就返回行 -- 左右都返回，不匹配用null表示。
Kafka關於數據流，手動處理offset的問題來處理數據流的問題
1. 有且僅有一次：基於數據庫事務將offset保存到第三方數據庫，可以實現有且僅有一次。
2. 至少一次：業務處理完成後，再將offset異步提交到kafka上。
3. 至多一次：在業務處理之前，先將offset提交到kafka上。
Kafka Producer 三種發送消息的方式
1. Fire-and-forget --- 此方法用來發送消息到broker，不關注消息是否成功到達。大部分情況下，消息會成功到達broker，
因爲kafka是高可用的，producer會自動重試發送。但是，還是會有消息丟失的情況；
2. Synchronous Send(同步發送) --- 發送一個消息，send()方法返回一個Future對象，使用此對象的get()阻塞方法可以查看send()方法是否執行成功。
3. Asynchronous Send(異步發送) --- 以回調函數的形式調用send()方法，當收到broker的響應，會觸發回調函數執行(Callback)。
Kafka acks參數的含義
acks=0：Producer不會等待broker的回覆，Producer會假定消息已成功發送，立即返回。因此可以使用此設置來實現非常高的吞吐量。
acks=1：當leader副本收到消息時，Producer將從Broker接收到成功響應。acks=1時的吞吐量，取決於消息是同步發送還是異步發送。
acks=all/-1：一旦所有處於同步狀態的副本收到消息，producer將收到來自broker的成功響應，此種情況，消息延遲會更高。
Kafka key的作用
可以用於存儲消息的額外信息
用來決定消息將被寫到哪個topic分區中
kafka相關術語
Broker ： 一臺kafka服務器就是一個broker。一個集羣由多個broker組成。一個broker可以容納多個topic。
Topic ： 一類消息，可以包括多個partition。
Producer ： 消息生產者，就是向kafka broker推送消息的客戶端。
Consumer ： 消息消費者，向kafka broker拉取消息的客戶端
Consumer Group （CG）： 一組 Consumer 組成的，用來消費 一個 Topic 上不同的 partition。
Partition：爲了實現擴展性，一個非常大的topic可以分佈到多個broker（即服務器）上，一個topic可以分爲多個partition，每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。 kafka只保證按一個partition中的順序將消息發給consumer，不保證一個topic的整體（多個partition間）的順序。
Offset：每個partition都由一系列有序的、不可變的消息組成，這些消息被連續的追加到partition中。partition中的每個消息都有一個連續的序列號叫做offset,用於partition唯一標識一條消息。
Kafka 常見動態參數配置
unclean.leader.election.enable：不嚴格的leader選舉，有助於集羣健壯，但是存在數據丟失風險。
min.insync.replicas：如果同步狀態的副本小於該值，服務器將不再接受request.required.acks爲-1或all的寫入請求。
max.message.bytes：單條消息的最大長度。如果修改了該值，那麼replica.fetch.max.bytes和消費者的fetch.message.max.bytes也要跟着修改。
cleanup.policy：生命週期終結數據的處理，默認刪除。
flush.messages：強制刷新寫入的最大緩存消息數。
flush.ms：強制刷新寫入的最大等待時長。
Kafka的負載均衡的實現
由於Leader的主要角色是執行分區的所有讀和寫請求的任務，而Follower則是被動地複製Leader。因此，當Leader失敗的時候，一個Follower接管了Leader的角色。整個過程確保了服務器的負載平衡。
Replicas和ISR的作用是什麼
在創建Topic時，可以指定分區的副本Replicas個數。用於保證消息不丟失。Replica的個數需要小於等於Broker的個數，所有Partition的Replica默認情況會均勻分佈到Broker上。
ISR是指處於同步狀態的副本，是一組同步到leader的消息副本。用於保證消息的一致性。
消息傳遞方法有哪些類型?
隊列:在這種方法中，一組用戶可以從服務器順序讀取消息。
（傳統的隊列系統——它通常在處理完成後從隊列的末尾刪除消息。
Apache Kafka——但是在Kafka中，消息在被處理後仍然存在。這意味着kafka中的信息不會在消費者收到時被刪除。）
發佈-訂閱:消息是向所有消費者廣播的。
Kafka調優
Kafka調優可以從三方面考慮：
Kafka Producer調優(消息壓縮、批次大小、同步或異步發送)，結合Producer配置項一起學習。
Kafka Brokers 調優（設置合適的topic partition個數和副本個數，一般情況下，分區個數和副本個數與kafka集羣節點個數相同。同時要考慮消費者的個數以及物理磁盤個數。）
Kafka Consumers調優(爲消費組中增加消費者，但是不能大於分區數。選擇合適的消費語義。)
HBase組件概念
Regionserver： 是存儲Hbase的數據的單位
Hmaster： 進行負載均衡的功能, 決定 region 放在哪裏.
HRegion：存放hbase中數據的一個概念，可以簡單的理解爲表，存放一張表中的一部分數據。
HFile： 在hdfs上存放數據之前的一個物理結構，用於接收從客戶端提交過來的數據。
Hbase表設計關鍵點
1. RowKey長度原則：最大長度爲64KB，實際應用中一般爲10~100bytes，一般設計成定長。建議是越短越好
2. RowKey散列原則：數據存儲是按照rowkey字符串的字典順序，rowkey過於連續會造成存儲熱點，需要離散存儲，就需要把rowkey打散。可以通過對rowkey做reverse操作。
3. RowKey唯一原則：必須在設計上保證其唯一性。
CAP是啥
一致性：所有節點在同一時間數據相同
可用性：有請求有響應，但是不保障每次請求獲取的數據正確
分區容錯性：系統在任意時刻的數據丟失不能影響整個分佈式系統的繼續運作。
犧牲一致性保證可用性。
HBASE 讀流程
1. 首先從 zk 中找到 meta 表 region 的位置, 然後從 meta 表中獲取用戶表的region信息
2. 根據 namespace, 表名和 rowkey 在 meta 表中找到對應的 region 信息, 找到對應的regionserver.
3. 定位 region
4. 從 Memstore 找到數據, 如果沒有, 再到 storefile 上讀取 (爲了讀取的效率)
HABSE 寫流程
1. 通過 zookeeper 找到 meata表的region
2. 根據相關信息找到 regionserver
3. 把數據分別寫到 HLog 和 memstore 中.
HBase 避免熱點問題
某一段時間內，Hbase讀寫集中在少部分Region上，負載明顯過大，其他RegionServer閒置，叫做熱點現象．
方案：RowKey設計，預分區，列簇設計，索引表
HBase 性能調優
預分區：對應數據需要寫到對應的region中，這個也解決了數據傾斜
Rowkey優化：（QA：Hbase表設計關鍵點）
Column優化：列族的名稱和列的描述名字要短，同一張的ColumnFamilly不要超過3個
Schema優化：寬表和高表（業務場景平衡）事務性、查詢性能 、損耗資源等等
Storm處理三種消息的處理模式
at most once：若不實現ack和fail方法，無論後續處理結果如何，消息只會發送一次，必定不能滿足高準確性；
at least once：若實現了ack和fail方法，只有調用了ack方法纔會任務處理成功，否則會重試。可能會出現消息重複，在併發場景下重複又意味着可能出現亂序；
exactly once：trident每個micro batch作爲整體只成功處理一次，但也是無法保證消息真的只正確的處理一次，比如數據已經處理完畢並持久化，但向數據源ack時失敗，就可能會有重試。
SparkSQL程序執行過程
1、 先寫Dataset API SQL代碼
2、 如果代碼沒有編譯錯誤，Spark會將代碼轉換爲邏輯計劃
3、 Spark會將邏輯計劃轉換爲物理計劃，會對代碼進行優化(catalyst優化器)
4、 Spark會執行物理計劃( RDD )
MapReduce 的操作
Map 任務執行結果輸出寫入到本地操盤，而不是HDFS。因爲：一旦任務完成，映射輸出可以扔掉了。所以，複製並將其存儲在HDFS變得大材小用。
HDFS：一次寫入，多次讀取。
storm 的Executor 與Task的關係
1. setNumWorker(2) => setBolt(**,**,4) => setNumberTask(8);
2: 兩個work進程；4：四個Executor線程，8個Task。
2. 一個Executork可以有多個或等於Task，一個Task對應一個topology。
3. Work屬於進程級別；Executork是線程級別；task是topology級別。
4. Work孵化出Executork進程，一個work可以對應多個Executork。
4. Executork，task是可以動態調節的。
5. Executor的數目 = 組件數 + 隱含的ACK數量。
RDD （Resilient Distributed Dataset）的特點
內存計算、 延遲計算、 容錯性、 不可變性、 分區、 持久化、 數據本地性
Spark 分區
1. 在集羣環境中，讀取本地文件/HDFS數據，spark的partition由數據的block個數決定，最小爲2
2. 每個partition會運行一個task來處理其中的數據元素
3. Partition（分區）亦是並行度，所有work執行的一次執行task的數量
如果spark-default.conf或SparkConf中設置了spark.default.parallelism參數值，
那麼spark.default.parallelism=設置值。
如果未設置，在yarn與standalone模式中：spark.default.parallelism = max（所有executor使用的core總數， 2）。
即可以RDD的分區數：sc.defaultParallelism = spark.default.parallelism
Spark.default.parallelism 屬性值設置爲： 單個work節點計算線程 * work節點個數 * 3
Spark 分區的選擇
分區太少： 1. 減少併發性;
2. 數據傾斜和不恰當的資源利用
分區太多： 1. 任務調度可能比實際執行時間花費更多的時間
RDD 分區數的選擇： 可用core數量（單個work節點core線程個數 * work節點個數）的2-3倍。
單個分區的數據量大小最終取決於執行程序的可用內存。
Tips：WebUI上查看任務執行，至少需要100+ ms時間。如果所用時間少於100ms，那麼應用程序可能會花更多的時間來調度任務。此時就要減少partition的數量。
Spark 應用程序的調度
Driver會向master申請資源，master收到請求之後，會向worker進行資源調度，啓動Executor，然後，Executor向Driver進行註冊。此時Spark 應用程序就會知道哪些worker上面的executor已經就緒。
接着開始執行spark任務：遇到action操作創建一個job—提交給DAGScheduler, DAGScheduler會把job分爲多個stages（shuffle：最後一個stage裏面的task叫ResultTask，前面stage裏面的task叫shuffleMapTask。），爲每個stage創建一個taskset集合，集合中的task計算邏輯完全相同，只是處理的數據不同。然後DAGScheduler會把taskset交給TaskScheduler，TaskScheduler會把taskset裏面的task發送給Executor。Executor接收到task，會啓動一個線程池TaskRunner,在裏面運行task。
實例化SparkContext是在Driver端完成的，後續的代碼操作都是在work端進行完成的。
文件收集框架Flume
實時收集數據，經常與storm/spark集成進行使用
Flume只有一個角色的節點Agent，其三大組件爲：
收集collecting source
聚合aggregating channel
移動moving sink
Event是Flume數據傳輸的基本單元，Flume以event 的形式將數據從源頭傳送到最終的目的
Flume提供了三種方式處理此種錯誤
End-to-end:收到數據agent首先會把數據寫到磁盤，等待傳輸成功後再刪除，如果傳輸失敗，再次發送
Store on failure：若接收方crash，再把數據寫到本地，等待對方恢復之後繼續發送
Besteffort：等待數據發送到接收方之後，不會進行確認
HDFS分佈式文件系統對數據 寫入過程
1. DFSClient發消息給NameNode，表示將數據文件(需要計算的文件)寫入
2. NameNode發消息給DFSClient，讓DFSClient寫到DataNodeA、B和D，並直接聯繫DataNodeB
3. DFSClient發消息給DataNodeB，讓它保存一份數據文件. (同機架或不同機架)
4. DataNodeB在保存數據文件時,並將數據文件發送個DataNodeA和DataNodeD,進行備份
6. DataNodeB發確認消息給DFSClient與NameNode，表示寫入完成
HDFS分佈式文件系統對數據 讀取過程
1. DFSClient詢問NameNode應該從哪裏讀取文件.
2. NameNode發送 “數據塊”的信息給DFSClient。
3. DFSClient檢查數據塊信息，聯繫相關的DataNode，請求數據塊
4. DataNode返回文件內容給DFSClient，然後關閉連接，完成讀操作
yarn 主要組件
ResourceManager： 主節點，處理客戶端的請求、調度應用管理者、集羣整體資源分配
NodeManager：從節點，單節點的資源管理、處理主節點/應用管理者的命令
ApplicationMaster： 應用管理者，數據切分、應用程序資源的申請,分配資源給內部任務任務監控與容錯
Container： 容器，任務運行環境的抽象, 封裝了任務所需的所有資源、資源隔離的效果
yarn 的業務流程
1.客戶端向ResourceManager提交一個作業，ResourceManager則會爲這個作業分配一個Container.
2.所以ResourceManager會與NodeManager進行通信，要求這個NodeManager啓動一個Container.
3.而這個Container是用來啓動ApplicationMaster的，ApplicationMaster啓動完之後會與ResourceManager進行一個註冊.
4.這時候客戶端就可以通過ResourceManager查詢作業的運行情況了.
5.然後ApplicationMaster還會到ResourceManager上申請作業所需要的資源，申請到以後就會到對應的
NodeManager之上運行客戶端所提交的作業.
6.最後NodeManager就會把task運行在啓動的Container裏
Hive 表分類
內部表：刪除內部表會直接刪除元數據 (metadata) 及存儲文件數據
外部表：被 external 修飾的表，刪除外部表僅僅刪除元數據, 文件不會被刪除
分區表：把數據分類放在不同的目錄下面, 加快查詢速度
SQL 的執行順序
第一步：執行FROM
第二步：WHERE條件過濾
第三步：GROUP BY分組
第四步：執行SELECT投影列
第五步：HAVING條件過濾
第六步：執行ORDER BY 排序
Hive中出現數據傾斜如何處理
1. 調節參數（在map中會做部分聚集操作 hive.map.aggr=true）
2. SQL 語句調節
3. 表的設計
Hive 調優
表拆分、MR優化配置、並行計算、JVM重用、本地計算、推測執行
HBase，Redis, MongDB 的應用場景
MongoDB是高性能、無模式的文檔型數據庫，支持二級索引，非常適合文檔化格式的存儲及查詢。MongoDB的官方定位是通用數據庫，確實和MySQL有些像，現在也很流行，但它還是有事務、join等短板，在事務、複雜查詢應用下無法取代關係型數據庫。
Redis是內存型Key/Value系統，讀寫性能非常好，支持操作原子性，很適合用來做高速緩存。
HBase存儲容量大，一個表可以容納上億行、上百萬列，可應對超大數據量要求擴展簡單的需求。Hadoop的無縫集成，讓HBase的數據可靠性和海量數據分析性能（MapReduce）值得期待。
Redis 主從同步步驟
1. slave 服務器連接 master 服務器, 併發送 psync 同步碼.
2. master 服務器收到 psync 同步碼, 執行 bgsave 生成snapshot(內存中,rdb), 並在緩存區記錄從當前開始執行的所有寫命令.
3. master 服務器在 bgsave 命令執行完成後, 將 snapshot 發送到 slave 服務器, slave 載入快照.
4. slave 服務器收到快照, 載入到內存中. 將自己的數據庫狀態更新至主服務器執行 BGSAVE 命令時的數據庫狀態. (rdb屬於內存性的文件, 所以每次都會丟棄舊 rdb)
5. master 服務器發送完成 snapshot 後, 向 slave 服務器發送緩存區的寫命令.(注意時間點)
6. salve 服務器執行這些寫命令，將自己的數據庫狀態更新至主服務器數據庫當前所處的狀態。
Redis 單線程模型每秒萬級別處理能力的原因
1. 純內存訪問。數據存放在內存中，內存的響應時間大約是100納秒，這是 Redis 每秒萬億級別訪問的重要基礎。
2. 非阻塞 I/O，Redis 採用 epoll 做爲 I/O 多路複用技術的實現，再加上 Redis 自身的事件處理模型將 epoll 中的連接，讀寫，關閉都轉換爲了時間，不在 I/O 上浪費過多的時間。
3. 單線程避免了線程切換和競態產生的消耗。
4. Redis 採用單線程模型，每條命令執行如果佔用大量時間，會造成其他線程阻塞，對於 Redis 這種高性能服務是致命的，所以 Redis 是面向高速執行的數據庫。
分佈式鎖機制: 悲觀鎖, 樂觀鎖
|
悲觀鎖 |
樂觀鎖 |
|
悲觀鎖採用相對保守的策略，在資源爭用比較嚴重的時候比較合適。悲觀鎖在事務開始之前就去嘗試獲得寫權限，事務結束後釋放鎖；也就是說對於同一行記錄，只有一個寫事務可以並行（加鎖，只有我能操作）. |
樂觀鎖是在提交事務之前，大家可以各自修改數據，但是在提交事務的時候，如果發現在這個過程中，數據發生了改變，那麼直接拒絕此次事務提交。（允許大家都操作，只是在提交事務中檢測）樂觀鎖適合在資源爭用不激烈的時候使用。 |
|
當前只能有寫權限的用戶可以操作, 而其他用戶此時被拒絕. 如 synchronized (不允許寫, 更不會執行) |
當前所有用戶都可以操作, 但是在提交時會被拒絕. 如watch - multi - exec (允許寫, 但不一定可以執行.) |
MongoDB的分片
分片（sharding）是指將數據庫拆分，將其分散在不同的機器上的過程。將數據分散到不同的機器上，不需要功能強大的服務器就可以存儲更多的數據和處理更大的負載。基本思想就是將集合切成小塊，這些塊分散到若干片裏，每個片只負責總數據的一部分，最後通過一個均衡器來對各個分片進行均衡（數據遷移）。 通過一個名爲mongos的路由進程進行操作，mongos知道數據和片的對應關係（通過配置服務器）。大部分使用場景都是解決磁盤空間的問題，對於寫入有可能會變差（+++裏面的說明+++），查詢則儘量避免跨分片查詢。使用分片的時機：
1. 機器的磁盤不夠用了。使用分片解決磁盤空間的問題。
2. 單個mongod已經不能滿足寫數據的性能要求。通過分片讓寫壓力分散到各個分片上面，使用分片服務器自身的資源。
3. 想把大量數據放到內存裏提高性能。和上面一樣，通過分片使用分片服務器自身的資源。