FlinkSQL實踐 時態表 版本表

在flinksql關聯時，必然會涉及到維表，維表又可能是不斷變化的（aka 時態表 或 版本表）。

版本表: 如果時態表中的記錄可以追蹤和並訪問它的歷史版本，這種表我們稱之為版本表，來自資料庫的 changelog 可以定義成版本表。

普通表: 如果時態表中的記錄僅僅可以追蹤並和它的最新版本，這種表我們稱之為普通表，來自資料庫 或 hbase 的表可以定義成普通表。

未實戰測試

2.2 a compacted kafka topic

將某乙個主題設定為compacted topic

bin/kafka-topics.sh --alter --topic my_topic_name --zookeeper my_zookeeper:2181 --config cleanup.policy=compact

tableenv.executesql(

"create table dim_source (" +
"               id string," +
"               name string," +
"               update_time timestamp(3) metadata from 'timestamp' virtual, " +
"               watermark for update_time as update_time, " +
"               primary key (id) not enforced" +
") with (" +
" 'connector' = 'upsert-kafka'," +
" 'topic' = 'flinksqldim'," +
" 'properties.bootstrap.servers' = 'ip:port'," +
" 'properties.group.id' = 'flinksqldim'," +
" 'key.format' = 'json'," +
" 'value.format' = 'json')"
);

// 建立訊息

// datetimeformatter dtf = datetimeformatter.ofpattern("yyyy-mm-dd hh:mm:ss.nnnnnnnnn");
for (int i = 1; i < 5; i++)

kafka支援的metadata型別

3.2key.format

必須指定key.format，可以不指定'scan.startup.mode' = 'earliest-offset'

flink-1.12 - 之flink sql 與 kafka connector實踐

flink動態表和時態表總結

基於 flink sql 的實時資料打寬的三種方式

將某乙個主題設定為compacted topic

kafka支援的metadata型別

版本管理 GitFlow 實踐

迴圈下面3個步驟，直到完成feature git add git commit m newfeature git push origin newfeature git pull origin develop git checkout develop git merge no ff newfeatur...

版本控制的極佳實踐

本文是www.git tower.com總結的使用git的最佳實踐，其中的大部分實踐具有普適性，可用其他版本控制工具svn，cvs等。原文 best practice of version control in git 每次提交的應該是一系列有關聯的變化。例如，修復了兩個不同的bug應該分別提交兩次...

MySQL各版本公升級最佳實踐

一 公升級前注意事項在開始之前，你要意識到這是乙個很慎重的操作，將一步跨過乙個重要的mysql版本。也就是說，這是有風險的。用二進位制檔案公升級是不建議的，而且這樣直接跨越乙個重要版本也是不安全的，所以你絕不能這樣5.0 5.5,5.1 5.6,或者5.0 5.6做。有乙個問題是，mysql版本不是...