Flink大數據常見(jiàn)問(wèn)題總結。

今天同事找我幫忙看一個(gè)Flink的問(wèn)題，現象是前幾天還能提交的客戶(hù)端，就在今天突然提交不了作業(yè)了，報錯提示大概如下（公司的東西涉密）， Caused by: org.apache.flink.api.common.InvalidProgramException: The LocalStreamEnvironment cannot be used when submitting a program through a client, or running in a TestEnvironment context. at org.apache.flink.streaming.api.environment.LocalStreamEnvironment.(LocalStreamEnvironment.java:68) at org.apache.flink.streaming.api.environment.LocalStreamEnvironment.(LocalStreamEnvironment.java:58) at org.apache.flink.streaming.api.env....

底層原理簡(jiǎn)介 LState:存儲左邊數據流中的數據。 RState：存儲右邊數據流中的數據。 當左邊數據流數據到達的時(shí)候會(huì )保存到LState，并且到RState中進(jìn)行Join。將Join生成的結果數據發(fā)送到下游。 右邊數據流中數據到達的時(shí)候，會(huì )保存到RState當中，并且到LState中進(jìn)行Join，然后將Join之嚄胡的結果數據發(fā)送到下游。 為了保障左右兩邊流中需要Join的數據出現在相同節點(diǎn)，Flink SQL會(huì )利用Join中的on的關(guān)聯(lián)條件進(jìn)行分區，把相同關(guān)聯(lián)條件 的數據分發(fā)到同一個(gè)分區里面。 普通雙流Join 現有訂單表A和支付表B進(jìn)行關(guān)聯(lián)得到匯總表C。訂單表和支付表初始數據如下： 表A：訂單表數據 order_id timestamp 1001 2023-02-04 10:00:00 1002 2023-01-04 10:01:02 表B：支付表數據 order_id pay_money order_id pay_money 1001 80 1002 100 inner join 當A表中每一條數據到達時(shí)，都會(huì )和B表中....

設置空閑狀態(tài)保留時(shí)間 不設置空閑狀態(tài)保留時(shí)間會(huì )導致?tīng)顟B(tài)爆炸。 FlinkSQL 的 regular join inner 、 left 、 right ），左右表的數據都會(huì )一直保存在狀態(tài)里，不會(huì )清理！要么設置 TTL ，要么使用 Flink SQL 的 interval join 。 使用 Top N 語(yǔ)法進(jìn)行去重，重復數據的出現一般都位于特定區間內（例如一小時(shí)或一天內），過(guò)了這段時(shí)間之后，對應的 狀態(tài)就不再需要了。 Flink SQL可以指定空閑狀態(tài)（即未更新的狀態(tài)）被保留的最小時(shí)間 當狀態(tài)中某個(gè) key對應的 狀態(tài)未更新的時(shí)間達到閾值時(shí)， 該條狀態(tài)被自動(dòng)清理。 API 設置： tableEnv.getConfig().setIdleStateRetention(Duration.ofHours(1)); 配置參數設置： Configuration configuration = tableEnv.getConfig().getConfiguration(); configuration.setString("table.exec.state.ttl", " 1 h" ); ....

數據傾斜原理 數據傾斜就是數據的分布嚴重不均，流入部分算子的數據明顯多余其他算子，造成這部分算子壓力過(guò)大。 影響 單點(diǎn)問(wèn)題 數據集中在某些分區上（Subtask），導致數據嚴重不平衡。 GC 頻繁 過(guò)多的數據集中在某些 JVM（TaskManager），使得JVM 的內存資源短缺，導致頻繁 GC。 吞吐下降、延遲增大 數據單點(diǎn)和頻繁 GC 導致吞吐下降、延遲增大。 系統崩潰 嚴重情況下，過(guò)長(cháng)的 GC 導致 TaskManager 失聯(lián)，系統崩潰。 Flink數據傾斜問(wèn)題定位 定位反壓 定位反壓有2種方式：Flink Web UI 自帶的反壓監控（直接方式）、Flink Task Metrics（間接方式）。通過(guò)監控反壓的信息 ，可以獲取到數據處理瓶頸的 Subtask。 確定數據傾斜 Flink Web UI 自帶Subtask 接收和發(fā)送的數據量。當 Subtasks 之間處理的數據量有較大的差距，則該 Subtask 出現數據傾斜。 Flink 如何處理常見(jiàn)數據傾斜 數據源 source 消費不均勻 解決思路：通過(guò)調整并發(fā)度，解決數據源消費不均勻或者數據源反壓的情況。 例如kaf....

簡(jiǎn)介 反壓（backpressure）是實(shí)時(shí)計算應用開(kāi)發(fā)中，特別是流式計算中，十分常見(jiàn)的問(wèn)題。反壓意味著(zhù)數據管道中某個(gè)節點(diǎn)成為 瓶頸，處理速率跟不上上游發(fā)送數據的速率，而需要對上游進(jìn)行限速。由于實(shí)時(shí)計算應用通常使用消息隊列來(lái)進(jìn)行生產(chǎn)端和 消費端的解耦，消費端數據源是 pull-based 的，所以反壓通常是從某個(gè)節點(diǎn)傳導至數據源并降低數據源（比如 Kafka consumer）的攝入速率。 簡(jiǎn)單來(lái)說(shuō)，Flink 拓撲中每個(gè)節點(diǎn)（Task）間的數據都以阻塞隊列的方式傳輸，下游來(lái)不及消費導致隊列被占滿(mǎn)后，上游的 生產(chǎn)也會(huì )被阻塞，最終導致數據源的攝入被阻塞。 TCP-based 反壓的弊端 單個(gè)Task導致的反壓，會(huì )阻斷整個(gè)TM-TM之間的socket，連checkpoint barries也無(wú)法發(fā)出。 反壓傳播路徑長(cháng)，導致生效時(shí)延較大。 Credit-based 反壓 反壓過(guò)程簡(jiǎn)介 如圖所示在 Flink 層面實(shí)現反壓機制，就是每一次 ResultSubPartition 向 InputChannel 發(fā)送消息的時(shí)候都會(huì )發(fā)送一個(gè) backlog size 告訴下游準備發(fā)送多少消息，下....

RocksDB 介紹 RocksDB 是嵌入式的 Key-Value 數據庫，在 Flink 中被用作 RocksDBStateBackend 的底層存儲。如下圖所示，RocksDB 持久化的 SST文件在本地文件系統上通過(guò)多個(gè)層級進(jìn)行組織，不同層級之間會(huì )通過(guò)異步Compaction 合并重復、過(guò)期和已刪除的數據。在 RocksDB 的寫(xiě)入過(guò)程中，數據經(jīng)過(guò)序列化后寫(xiě)入到WriteBuffer，WriteBuffer 寫(xiě)滿(mǎn)后轉換為 Immutable Memtable 結構，再通過(guò) RocksDB 的flush 線(xiàn)程從內存 flush 到磁盤(pán)上；讀取過(guò)程中，會(huì )先嘗試從 WriteBuffer 和 Immutable Memtable 中讀取數據，如果沒(méi)有找到，則會(huì )查詢(xún) Block Cache，如果內存中都沒(méi)有的話(huà)，則會(huì )按層級查找底層的 SST 文件，并將返回的結果所在的 Data Block 加載到 BlockCache，返回給上層應用。 RocksDBKeyedStateBackend增量快照介紹 這里介紹一下大家在大狀態(tài)場(chǎng)景下經(jīng)常需要調優(yōu)的 RocksDBKeyedStateBac....

redis一款高并發(fā)的內存K-V數據庫，提供了好多命令，但是其中有部分對于生產(chǎn)環(huán)境來(lái)說(shuō)比較危險，需要禁用掉。高危命令有：keys、flushdb、flushall、config、debug、eval、script、evalsha、shutdown

已經(jīng)安裝openssl，編譯redis還是提示找不到<openssl/ssl.h>

Redis被經(jīng)常用來(lái)實(shí)現分布式鎖，本文主要講述redis如何實(shí)現一個(gè)分布式鎖的demo。