同僚によると、ディメンション テーブル キャッシュでは、指定した期間内にキャッシュ項目が読み取られない場合はリサイクルされ、読み取られると ttl 時間が延長されるとのことです。関連するディメンション テーブル データが変更されると、最新のディメンション データを取得できなくなるため、キャッシュをオフにする必要があります。
flink 1.16 より前では、キャッシュは次のように作成されていました。
CacheBuilder.newBuilder() .expireAfterWrite(cacheExpireMs, TimeUnit.MILLISECONDS) .maximumSize(cacheMaxSize) .build()
flink1.16 以降、キャッシュにはユーザーが次のように設定できるパラメータが追加されました。
CacheBuilder<Object, Object> guavaCacheBuilder = CacheBuilder.newBuilder();
if (expireAfterAccessDuration != null) {
guavaCacheBuilder.expireAfterAccess(expireAfterAccessDuration);
}
if (expireAfterWriteDuration != null) {
guavaCacheBuilder.expireAfterWrite(expireAfterWriteDuration);
}
if (maximumSize != null) {
guavaCacheBuilder.maximumSize(maximumSize);
}
if (ticker != null) {
guavaCacheBuilder.ticker(ticker);
}
guavaCache = guavaCacheBuilder.build();
expireAfterAccess: キャッシュ項目は、指定された期間内に読み書きされなかった場合にリサイクルされます。
expireAfterWrite: 指定された期間内にキャッシュ項目が更新されない場合、キャッシュ項目はリサイクルされます。
RefreshAfterWrite: キャッシュ項目の最後の更新操作からどれくらいの時間が経過してからキャッシュ項目が更新されるか。
コラムの本来の意図:
- リアルタイム データ ウェアハウスを迅速に構築し、オフライン データ ウェアハウスのレイヤーを調整したい場合は、Flink SQL が最初の選択肢です。データストリーム コードと比較して、Flink SQL はリアルタイム データ ウェアハウス構築の実装時間を 10 時間大幅に短縮できます。回。
- 著者は大昌市のリアルタイム データ ウェアハウス チームに所属しており、現在 3,000 以上のリアルタイム タスクを実行しています。リアルタイム クラスター サイズは 20,000 CU、クラスター チェックポイントのピークは 5 TB、シングルタスクの最大 QPS ピークは 50 W です。 。
- このコラムでは、著者がリアルタイム データ ウェアハウスの構築中に遭遇した詳細を共有し、誰もがリアルタイム データ ウェアハウスを迅速に構築できるようにします。
著者情報:
- 1.書籍「Flink のコア設計と実践原則の詳細な理解」の著者
- 2. GitHub の人気プロジェクトfink-boot (800+) 開発者、flink と Spring のエコロジー統合に専念