做网站一般多钱软文营销的案例
 | 博主历时三年精心创作的《大数据平台架构与原型实现：数据中台建设实战》一书现已由知名IT图书品牌电子工业出版社博文视点出版发行，点击《重磅推荐：建大数据平台太难了！给我发个工程原型吧！》了解图书详情，京东购书链接：https://item.jd.com/12677623.html，扫描左侧二维码进入京东手机购书页面。 |
根据 [ 官方文档 ] 所述，在 Flink 中，时态表和动态表是一个概念，只是强调的侧重点不同。Flink 流上的表都是动态的，也就是一直在变化，所以被称为动态表，因为动态表都会随时间发生变化，所以也被叫作了 “时态表”。而根据能否 trace (追踪) 一张时态表的变化历史，时态表会细分成：版本表 和 普通表 两种，区别就是：版本表可以追溯历史，而普通表只保存当前最新状态的数据。
Flink 官方文档中说：定义了主键约束和事件时间属性（通过 WATERMARK 关键字标识）的表就是版本表，并且举例说：数据库的 changelog 数据（CDC数据）就可以定义成版本表。这里不要产生错误的理解，不是说只有数据库的 changelog 数据才支持定义成版本表，而是说数据库的 changelog 型数据是版本表的一种典型数据，因为它必定包含记录的主键和一个标记操作执行的时间戳。
以下是援引自官方文档中的一张版本表的定义：
-- 定义一张版本表
-- 只有同时定义了主键和事件时间字段的表才是一张版本表
-- 通过 CDC 技术从数据库采集的 changelog 数据是构成版本表的数据“典型”数据
-- 但并不是说：版本表的数据一定是 changelog 型的数据，只要满足有主键和事件时间字段数据，就可以定义为版本表
CREATE TABLE product_changelog (product_id STRING,product_name STRING,product_price DECIMAL(10, 4),update_time TIMESTAMP(3) METADATA FROM 'value.source.timestamp' VIRTUAL,PRIMARY KEY(product_id) NOT ENFORCED, -- 版本表特征(1) 定义主键WATERMARK FOR update_time AS update_time -- 版本表特征(2) 定义事件时间字段（通过 watermark 定义事件时间）
) WITH ('connector' = 'kafka','topic' = 'products','scan.startup.mode' = 'earliest-offset','properties.bootstrap.servers' = 'localhost:9092','value.format' = 'debezium-json'
);
实际上，Flink 的版本表条件和定义一张 Hudi 表所必须指定的两项配置：hoodie.datasource.write.recordkey.field 和 precombine.field 在性质上是一样的：如果你想区别同一条记录的不同版本，就得需要同时指定记录的唯一标识（即主键）和当出现相同主键记录时的版本号（即记录的时间戳），本质上，这是保证记录版本可回溯的两个必要条件，所以才会有 Flink 版本表与 Hudi 表之间的这种“神似”状况。
以下是对四个概念的梳理：
时态表 <=> 动态表├── 版本表：可追溯历史版本，只有定义了：主键和事件时间属性（通过 watermark 定义） 的表才可以成为一张版本表，│ 反过来说：数据本身必须包含主键字段和一个标记记录生成或更新的时间戳字段才能被定义成 Flink 上的版本表。│ 由于版本表有这两项约束条件，能构成版本表的数据往往是 changelog 型数据，典型代表是数据库的 CDC 数据；└── 普通表：只保存当前最新状态数据，就是只能拿到当前最新快照
普通表并不会特别拿来强调，只是用于和版本表这个概念做对比的，真正被特别拿来强调的是版本表，而经常与版本表放在一起提及的就是“Temporal Join“，“Temporal Join“ 其实特指与版本表的 Join。目前在官方文档的多处描述中可以判断的是：但凡提及 时态表 / Temporal Table 或 Temporal 这个关键词时，通常谈论的是都是 版本表，所以，我们可以在沟通和描述中使用“时态表”这个称谓指代“版本表”这个概念，但要清楚两者之间的关系，以及在必要的时候能区分对方想要表达的具体是哪一种就可以了。应该是 Flink 在历史上似乎没有对这些概念进行明确的区分，或者中途引入的概念有一些冲突，各种混用导致了概念上的一些轻微的混淆。