- **Generic CLI 模式**
標準的Flink任務提交指令碼（Generic CLI 模式），從1.11開始，增加了通用客戶端模式，引數使用-D <property>指定
```bash
bin/flink run \
-t yarn-per-job \
-d \
-p 5 \ 指定並行度
-Dyarn.application.queue=test \ 指定yarn佇列
-Djobmanager.memory.process.size=1024mb \ 指定JM的總程式大小
-Dtaskmanager.memory.process.size=1024mb \ 指定每個TM的總程式大小
-Dtaskmanager.numberOfTaskSlots=2 \ 指定每個TM的slot數
-c com.app.LogBaseApp \
/opt/module/gmall-flink/demo-1.0-SNAPSHOT-jar-with-dependencies.jar
```

- **記憶體設定**
```bash
bin/flink run \
-t yarn-per-job \
-d \
-p 5 \ 指定並行度
-Dyarn.application.queue=test \ 指定yarn佇列
-Djobmanager.memory.process.size=2048mb \ JM2~4G足夠
-Dtaskmanager.memory.process.size=6144mb \ 單個TM2~8G足夠
-Dtaskmanager.numberOfTaskSlots=2 \ 與容器核數1core：1slot或1core：2slot
-c com.app.LogBaseApp \
/opt/module/gmall-flink/demo-1.0-SNAPSHOT-jar-with-dependencies.jar
```

- **並行度設定**
**最優並行度計算：**
進行壓測。任務並行度給10以下，測試單個並行度的處理上限。然後 總QPS/單並行度的處理能力 = 並行度；
最好根據高峰期的QPS壓測，並行度*1.2倍，富餘一些資源。
**Source 端並行度的配置：**
資料來源端是 Kafka，Source的並行度設定為Kafka對應Topic的分割槽數。
如果已經等於 Kafka 的分割槽數，消費速度仍跟不上資料生產速度，考慮下Kafka 要擴大分割槽，同時調大並行度等於分割槽數。
Flink 的一個並行度可以處理一至多個分割槽的資料，如果並行度多於 Kafka 的分割槽數，那麼就會造成有的並行度空閒，浪費資源。
**Transform端並行度的配置：**
Keyby之前的運算元：
一般不做太重的操作，比如map、filter、flatmap等處理較快的運算元，並行度可以和source保持一致。
Keyby之後的運算元（KeyGroup 最小值為128）：
併發較大，建議設定並行度為 2 的整數次冪，例如：128、256、512；
小併發任務的並行度不一定需要設定成 2 的整數次冪；
大併發任務沒有 KeyBy，並行度也無需設定為 2 的整數次冪；
**Sink 端並行度的配置：**
如果Sink端是Kafka，可以設為Kafka對應Topic的分割槽數。
如果在 Flink Sink 這端的資料量過大的話，且 Sink 處並行度也設定的很大，但下游的服務完全撐不住這麼大的併發寫入，可能會造成下游服務直接被寫掛，所以最終還是要在 Sink 處的並行度做一定的權衡。

- **RocksDB大狀態調優**
RocksDB 是基於 LSM Tree 實現的（類似HBase），寫資料都是先快取到記憶體中，所以RocksDB 的寫請求效率比較高。
RocksDB 使用記憶體結合磁碟的方式來儲存資料，每次獲取資料時，先從記憶體中 blockcache 中查詢，如果記憶體中沒有再去磁碟中查詢。最佳化後差不多單並行度 TPS 5000 record/s，效能瓶頸主要在於 RocksDB 對磁碟的讀請求，所以當處理效能不夠時，僅需要橫向擴充套件並行度即可提高整個Job 的吞吐量。
**設定本地 RocksDB 多目錄：**
flink-conf.yaml 中配置：
```bash
state.backend.rocksdb.localdir: /data1/flink/rocksdb,/data2/flink/rocksdb,/data3/flink/rocksdb
```
注意：不要配置單塊磁碟的多個目錄，務必將目錄配置到多塊不同的磁碟上，讓多塊磁碟來分擔壓力。
如果每個伺服器上有一兩塊 SSD，強烈建議將 RocksDB 的本地磁碟目錄配置到 SSD 的目錄下，從 HDD 改為 SSD 對於效能的提升可能比配置 10 個最佳化引數更有效。
**state.backend.incremental：**
開啟增量檢查點，預設false，改為true。
**state.backend.rocksdb.predefined-options：**
NING_DISK_OPTIMIZED_HIGH_MEM設定為機械硬碟+記憶體模式，
有條件上SSD，指定為FLASH_SSD_OPTIMIZED
**state.backend.rocksdb.block.cache-size:**
RocksDB 共享一個 block cache，讀資料時記憶體的 cache 大小，該引數越大讀資料時快取命中率越高，預設大小為 8 MB，建議設定到 64 ~ 256 MB。
**state.backend.rocksdb.thread.num:**
用於後臺 flush 和合並 sst 檔案的執行緒數，預設為 1，建議調大，機械硬碟使用者可以改為 4 等更大的值。
**state.backend.rocksdb.writebuffer.size: **
RocksDB 中，每個 State 使用一個 Column Family，每個 Column Family 使用獨佔的 write buffer，建議調大，例如：32M
**state.backend.rocksdb.writebuffer.count:**
每個 Column Family 對應的 writebuffer 數目，預設值是 2，對於機械磁碟來說，如果記憶體⾜夠大，可以調大到 5 左右
**state.backend.rocksdb.writebuffer.number-to-merge: **
將資料從 writebuffer 中 flush 到磁碟時，需要合併的 writebuffer 數量，預設值為 1，可以調成3。
**state.backend.local-recovery: **
rocksdb獨有；
設定本地恢復，當 Flink 任務失敗時，可以基於本地的狀態資訊進行恢復任務，可能不需要從 hdfs 拉取資料。

- **Checkpoint設定**
一般我們的 Checkpoint 時間間隔可以設定為分鐘級別，例如 1 分鐘、3 分鐘。
對於狀態很大的任務每次 Checkpoint 訪問 HDFS 比較耗時，可以設定為 5~10 分鐘一次Checkpoint，並且調大兩次 Checkpoint 之間的暫停間隔，例如設定兩次Checkpoint 之間至少暫停 4或8 分鐘。
如果 Checkpoint 語義配置為 EXACTLY_ONCE，那麼在 Checkpoint 過程中還會存在 barrier 對齊的過程，可以透過 Flink Web UI 的 Checkpoint 選項卡來檢視 Checkpoint 過程中各階段的耗時情況，從而確定到底是哪個階段導致 Checkpoint 時間過長然後針對性的解決問題。
RocksDB相關引數在1.3中已說明，可以在flink-conf.yaml指定，也可以在Job的程式碼中呼叫API單獨指定。
```java
 // 使⽤ RocksDBStateBackend 做為狀態後端，並開啟增量 Checkpoint
 RocksDBStateBackend rocksDBStateBackend = new RocksDBStateBackend("hdfs://hadoop102:8020/flink/checkpoints", true);
 env.setStateBackend(rocksDBStateBackend);

// 開啟Checkpoint，間隔為 3 分鐘
 env.enableCheckpointing(TimeUnit.MINUTES.toMillis(3));
 // 配置 Checkpoint
 CheckpointConfig checkpointConf = env.getCheckpointConfig();
 checkpointConf.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)
 // 最小間隔 4分鐘
 checkpointConf.setMinPauseBetweenCheckpoints(TimeUnit.MINUTES.toMillis(4))
 // 超時時間 10分鐘
 checkpointConf.setCheckpointTimeout(TimeUnit.MINUTES.toMillis(10));
 // 儲存checkpoint
 checkpointConf.enableExternalizedCheckpoints(
CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
```

- **Flink ParameterTool 讀取配置**
ParameterTool 是可序列化的，所以你可以將它當作引數進行傳遞給運算元的自定義函式類。
**讀取執行引數：**
Flink的提交指令碼新增執行引數，格式：
--引數名 引數值
-引數名 引數值
程式碼裡獲取引數值：
```java
        ParameterTool parameterTool = ParameterTool.fromArgs(args);
        String myJobname = parameterTool.get("jobname");  //引數名對應
        env.execute(myJobname);
```
**讀取系統屬性：**
```java
ParameterTool parameterTool = ParameterTool.fromSystemProperties();
System.out.println(parameterTool.toMap().toString());
```
**讀取配置檔案：**
使用ParameterTool.fromPropertiesFile("/application.properties") 讀取 properties 配置檔案。
**註冊全域性引數：**
```java
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.getConfig().setGlobalJobParameters(ParameterTool.fromArgs(args));
env.addSource(new RichSourceFunction() { 
@Override 
public void run(SourceContext sourceContext) throws Exception {
 while (true) { 
	ParameterTool parameterTool = (ParameterTool)getRuntimeContext().getExecutionConfig().getGlobalJobParameters();
   }
  } 
  @Override 
  public void cancel() {
  }
})
```</property>

Flink - 資源配置調優

相關文章