marui156的专栏

Iceberg 社区基本盘还是在离线处理，它在国外的应用场景主要是离线取代 Hive，它也有强力的竞争对手 Delta，很难调整架构去适配 CDC 流更新。同时，Iceberg 扩展性强，对其它计算引擎也暴露的比较多的优化空间，但是这也导致后续的发展难以迅速，涉及到众多已经对接好的引擎。这并没有什么错，后面也证明了 Iceberg 主打离线数据湖和扩展性是有很大的优势，得到了众多国外厂商的支持。

Flink 社区希望能够将 Flink 的 Streaming 实时计算能力和 Lakehouse 新架构优势进一步结合，推出新一代的 Streaming Lakehouse 技术，促进数据在数据湖上真正实时流动起来，并为用户提供实时离线一体化的开发体验。Flink 社区内部孵化了 Flink Table Store （简称 FTS ）子项目，一个真正面向 Streaming 以及 Realtime的数据湖存储项目。

Apache Hudi是一个Data Lakes的开源方案，Hudi是Hadoop Upserts Delete and Incremental的简写，它是由Uber开发并开源的Data Lakes解决方案。Hudi能够基于HDFS之上管理大型分析数据集，可以对数据进行插入、更新、增量消费等操作，主要目的是高效减少摄取过程中的数据延迟。官方对 Hudi 的定义如下：Apache Hudi将核心仓库和数据库功能直接引入数据湖。

Apache Iceberg 是由 Netflix 开发开源的，其于2018年11月16日进入 Apache 孵化器，是 Netflix 公司数据仓库基础。Apache Iceberg设计初衷是为了解决Hive离线数仓计算慢的问题，经过多年迭代已经发展成为构建数据湖服务的表格式标准。Iceberg 本质上是一种专为海量分析设计的表格式标准，可为主流计算引擎如 Presto、Spark 等提供高性能的读写和元数据管理能力。

起初，业界数据处理首选方式是数仓架构。通常数据处理的流程是把一些业务数据库，通过ETL的方式加载到Data Warehouse中，再在前端接入一些报表或者BI的工具去展示。数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。

早期系统采用关系型数据库来存放管理数据，但是随着大数据技术的兴起，人们对于多方面数据进行分析的需求愈加强烈，这就要求建立一个能够面向分析、集成保存大量历史数据的新型管理机制，这一机制就是数据仓库。数据仓库通常存储来自不同源的数据，集成源数据以提供统一的视图。这些资源可以包括事务系统、应用程序日志文件、关系数据库等等。

数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。可扩展是指规模的可扩展和能力的可扩展，即数据湖不但要能够随着数据量的增大，提供“足够”的存储和计算能力；还需要根据需要不断提供新的数据处理模式，例如可能一开始业务只需要批处理能力，但随着业务的发展，可能需要交互式的即席分析能力；

Watermark是Apache Flink提出的一种用来解决乱序、延迟数据等情况的解决方案。它是建立在事件时间上的一个概念，用来刻画数据流的完整性。如果按照处理时间来衡量事件，一切都是有序的、完美的，自然而然也就不需要Watermark了。换句话说事件时间带来了乱序的问题，而Watermark就是用来解决乱序问题。所谓的乱序，其实就是有事件延迟了，对于延迟的元素，我们不可能无限期的等下去，必须要有一种机制来保证一个特定的时间后，必须触发Window进行计算。

官方定义：当前计算流程需要依赖到之前计算的结果，那么之前计算的结果就是状态。这句话还是挺好理解的，状态不只存在于Flink，也存在生活的方方面面，比如看到一个认识的人，如果识别认识呢？就是眼睛看到这个人的样子，再和大脑记忆中的人做对比，就知道认识这个人，其中大脑记忆中的人就是存储在状态中。状态又分为无状态和有状态。

Flink 通过 Task Slots 来定义执行资源。每个 TaskManager 有一到多个 task slot，每个 task slot 可以运行一条由多个并行 task 组成的流水线。这样一条流水线由多个连续的 task 组成，比如并行度为 n 的 MapFunction 和 并行度为 n 的 ReduceFunction。

Flink 的回撤流是指在 Flink 的流处理算法中，撤回已经发送到下游节点的数据。这是因为在实际应用场景中，有些错误数据可能会发送到下游节点，因此需要回撤流以保证数据的准确性。回撤流可以理解为流式场景下对数据进行更新，这里的更新数据并不是将发往下游的历史数据进行更改，要知道，已经发往下游的消息是追不回来的。

例如：select CURRENT_DATE;返回 2021-10-08例如：select CURRENT_TIME;返回 09:25:28.137例如：select CURRENT_TIMESTAMP;返回 2021-10-08T09:23:15.180 --注意和时区有关系例如：select LOCALTIMESTAMP;返回 2021-10-08T17:19:47.787例如：select LOCALTIME；返回 17:22:16.212。

可根据使用的版本查找，该链接为1.12版本。

滚动窗口有固定的尺寸，窗口间的元素无重复示例：每10分钟将10分钟内的金额汇总计算。

时态表是一个随时间演变的表，在Flink中也称为动态表。时态表中的行与一个或多个时态周期相关联，并且所有Flink表都是时态的（动态的）。时态表包含一个或多个版本化的表快照，它可以是跟踪更改的更改历史表（例如数据库更改日志，包含所有快照），也可以是具体化更改的维表（例如包含最新快照的数据库表）。时态表可以分为和。时态join类型。

区间是双流join的优化，基于处理时间或事件时间，在一定时间区间内数据，相同的key进行join（支持 Batch\Streaming）。Interval Join 可以让一条流去 Join 另一条流中前后一段时间内的数据。对于stream查询，时间区间oin只支持有时间属性的 append-only表。由于时间属性是准单调递增的，Flink可以从其状态中删除旧值，而不会影响结果的正确性。优点：由于给定了关联的区间，因此只需要保留很少的状态，内存压力较小。

双流join是最通用的联接类型（支持 Batch\Streaming），其中任何新记录或联接两侧的更改都是可见的，并影响整体的Join结果。适用场景：因为资源问题 Regular Join 通常是不可持续的，一般只用做有界数据流的 Join。

自定义表值聚合函数（UDTAGG）可以把一个表（一行或者多行，每行有一列或者多列）聚合成另一张表，结果中可以有多行多列。理解：假设有一个饮料的表，这个表有 3 列，分别是 id、name 和 price，一共有 5 行。假设你需要找到价格最高的两个饮料，类似于 top2() 表值聚合函数。你需要遍历所有 5 行数据，结果是有 2 行数据的一个表。

用户定义的表函数将零个，一个或多个标量值作为输入参数。返回任意数量的行作为输出，返回的行可以包含一个或多个列。与标量函数区别：相同：都是将零个、一个或多个标量值作为输入参数差异：标量函数返回单个值作为输出，表值函数返回任意数量的行作为输出。

聚合函数：将一个表的一个或多个行并且具有一个或多个属性聚合为标量值。聚合函数理解：假设一个关于饮料的表。表里面有三个字段，分别是 id、name、price，表里有 5 行数据。假设你需要找到所有饮料里最贵的饮料的价格，即执行一个 max() 聚合。你需要遍历所有 5 行数据，而结果就只有一个数值。