u011624157的专栏

技术方案模板

04.如何搭建优惠券服务

实时的join分类最直观的想法，无界变有界：Window Join原理利用 Flink 时间窗口机制只考虑在同一个时间窗口内的数据进行关联存在的问题1.窗口边界上的数据关联失败， 比如：10:59 的曝光，11:01 的点击，互相关联不上2.时效性差，窗口结束才触发计算和下发准确性优先：Interval Join原理利用 Flink 的 Watermark 机制，当前侧的点，关联对侧的时间区间存在的问题1.时效性较差，Outer 补 null 的数据要等区间结束才下发

Spark基本概念在讲解Spark作业memory使用前，确保理解以下Spark 基本概念：Application： 基于Spark的用户程序，包含了一个driver program 和 集群中多个的executorDriver：运行Application的main()函数并且创建SparkContext，通常用SparkContext代表Driver ProgramExecutor： 是为某Application运行在worker node上的一个进程，该进程负责运行Task，并且负责将数据存在

join条件不等值时

上篇介绍了常见的算子，本文介绍另外一个重要的算子：Async I/O，即异步IO。它是流中频繁访问外部数据的利器，特别是当访问比较耗时的时候。产生背景先考虑一个实际中挺常见的场景：一个流处理程序中对于每个事件都要查一次外部的维表（比如HBase，这里暂不考虑缓存机制）做关联，那在Flink中如何实现呢？典型的做法就是增加一个map/flatmap，在里面做一下查询关联。这样功能没问题，但这个查询很容易会变成系统的瓶颈，特别是当外部查询比较耗时的时候。好在Flink里面有一个异步IO算子，可以很好的解决这

了解LoadingCache的工作原理需要着重理解,load方法中是调用二级存储的，返回值会被自动加载到LoadingCache.build( new CacheLoader<Integer, String>() { @Override public String load(Integer key) throws Exception

1、这个TM 内存都写成256 倍数吧 ，写成12384 ，yarn按 12544分配内存，中间差得这160m，flink用不上，再乘2000个tm，一共300G内存浪费掉了

Apache Hudi(简称Hudi)是Uber创建的一个数据湖框架。2019年1月，Hudi加入Apache孵化器进行孵化，并于2020年5月晋升为Apache顶级项目。它是最流行的数据湖框架之一。1. hudi与spark解耦自诞生以来，Hudi一直使用Spark作为其数据处理引擎。如果用户想要使用Hudi作为他们的数据湖框架，他们必须将Spark引入到他们的平台技术栈中。几年前，使用Spark作为大数据处理引擎可以说是非常普遍甚至是自然的。因为Spark既可以执行批处理，也可以使用微批处理来模拟流

Hudi中的每条记录都由主键唯一标识，主键是记录所属的一对记录键和分区路径。使用主键，Hudi可以允许快速更新和删除记录。应该明智地选择分区方案，因为它可能是摄取和查询延迟的决定因素。一般来说，Hudi支持分区索引和全局索引。对于具有分区索引(这是最常用的)的数据集，每条记录都由一对记录键和分区路径唯一标识。但对于具有全局索引的数据集，每条记录仅由记录键惟一标识。分区之间不会有任何重复的记录键。键生成器Hudi提供了几个开箱即用的主键生成器，用户可以根据自己的需要使用它们，同时还提供了一个可插拔的实现

Insufficient number of network buffers报错日志&截图问题原因解决方案方案一：通过任务拓扑计算所需network buffer大小：方案二：根据经验直接调整flink-conf.yaml文件中的taskmanager.memory.network.fraction参数报错日志&截图问题原因task在申请MemorySegment时获取不到所需的数量，抛出IOException，detail message为Insufficient number o

火焰图是一个可视化的，有效地表示如下问题的答案，如:哪些方法目前正在消耗CPU资源?一种方法的消费与其他方法相比如何?堆栈上的哪一系列调用导致执行一个特定的方法?火焰图是通过多次采样stack trace来生成的。每个方法调用都由一个条形图表示，条形图的长度与它在样本中出现的次数成正比。从Flink 1.13开始，Flink本身就支持Flame Graphs。为了生成一个火焰图，导航到一个正在运行的作业的作业图，选择一个感兴趣的operator，在菜单中右键单击火焰图选项卡:任何测量过

akka.pattern.AskTimeoutException

概览离线批处理中两个表做关联很简单，把两个表的数据根据关联条件做shuffle，然后做匹配就可以了，但是实时的两个流做关联就比较复杂，需要考虑的问题有：两个流是无限的，其中一个流来一条新数据，去另一个流做关联时，怎么确定关联的范围？如果关联范围确定了，那么左右两个流的数据怎么存放？如果使用缓存，那么缓存的清理策略是什么？接下来分析flink提供的集中流关联的方式，找到以上两个问题的答案JoinedStreams & CoGroupedStreams...

manifest文件怎么追踪datafile和deletefilemanifest 文件的两种格式1：snap-{snapshot_id}-随机产出的字符串.avro （manifest list文件）2：{随机字符串}-m{0或1}.avro（存放datafile、deletefile具体路径的文件）manifest 文件的两种格式manifest是avro格式的文件，根据其命名和功能可以分为两种：1：snap-{snapshot_id}-随机产出的字符串.avro （manifest list文件

interval join实现解析概览怎么管理左右缓存interval join的实现主要依靠IntervalJoinOperator，下面详细分析IntervalJoinOperator代码概览IntervalJoinOperator可以通过使用可配置的下界和上界，精确地发出(T1, T2)其中T2.ts∈(T1.ts +下界，T1.ts + upperBound]。下界和上界都可以配置为包含或排他。元素一旦连接起来，就会传递给用户定义的ProcessJoinFunction。这个实现的基本思想

本节详细介绍Iceberg如何进行行级删除。v1中不支持行级删除。行级删除文件是有效的Iceberg数据文件:文件必须使用有效的Iceberg格式、schema和column projecttion。建议使用表的默认文件格式写入删除文件。行级删除文件由manifest文件（清单）跟踪。删除文件使用一组相互独立的清单，但清单的schema是相同的。position delete（位置删除）和equality delete（相等删除）都允许用delete对已删除的行值进行编码。这可用于重建表的更改流。r

Table Metadata表元数据存储为JSON。每个表元数据更改都会创建一个由原子操作提交的新表元数据文件。此操作用于确保表元数据的新版本替换它所基于的版本。这将生成表版本的线性历史记录，并确保并发写操作不会丢失。用于提交元数据的原子操作取决于如何跟踪表，该规范没有对其进行标准化。Table Metadata Fields表元数据由以下字段组成:v1v2字段描述requiredrequiredformat-version格式的整数版本号。目前，它总是1。如果表的版

flink流批一体概念与配置什么时候可以/应该使用批处理执行模式?配置批处理执行模式流批执行模式的区别任务调度和网络Shuffle流执行模式批量执行模式状态后端/状态处理顺序事件时间/水印处理时间故障恢复需要注意的点检查点编写自定义操作符什么时候可以/应该使用批处理执行模式?BATCH执行模式只能用于有界的数据源。有界性是数据源的一个属性，它告诉我们来自该数据源的所有输入在执行之前是否已知，或者是否会无限期地出现新数据。反过来，如果一个作业的所有源都是有界的，那么它就是有界的，否则就是无界的。另一方面

基于kafka的实时数仓可以达到秒级别延迟（多层，如果是单层可达到ms级别延迟），但是kafka的成本太高，如果要做到近实时的数仓，可用iceberg+hdfs替代kafka。以上这段是很多公司用iceberg替换kafka的原因，通过下面两个问题问清楚成本高在哪Q1:存放同样大小1pb的数据，kafka成本为什么比hdfs高？A1:kafka是按消息队列设计的，为了满足低延迟，而采用了pagecache层（非常激进的使用内存，因为一旦读数据miss cache，会产生磁盘读操作，这种情况下.

SLA（Service-Level Agreement），也就是服务等级协议，指的是系统服务提供者（Provider）对客户（Customer）的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。在开发设计系统服务的时候，无论面对的客户是公司外部的个人、商业用户，还是公司内的不同业务部门，我们都应该对自己所设计的系统服务有一个定义好的 SLA。因为 SLA 是一种服务承诺，所以指标可以多种多样。常见的SLA 指标如：可用性、准确性、系统容量和延迟。实时计算最常用的SLA指标是延迟，即统计

hudi介绍数据湖产生背景数据湖产生背景数据湖的产出原因是数据处理架构的升级，最初版本的lambda架构，在Processor上是两套结构（stream processor和batch processor），数据服务层自然也就分为两套（实时对应speed serving，离线对应batch serving）,如下图在引入kappa架构之后，processor只剩下stream processor，数据服务层却难有一个框架来进行统一,如下图kappa架构下对数据服务层的要求如下：从功能特点上

流处理框架概览storm(record ack容错)微批处理 (Trident, Spark Streaming)flink(分布式一致性快照容错)storm(record ack容错)虽然流处理多年来一直广泛应用于金融等行业，但它最近正成为更广泛的用例的数据基础设施的一部分。开源框架的可用性推动了这种采用。也许开源世界中第一个广泛使用的大规模流处理框架是Apache Storm。Storm使用一种上游备份和记录确认机制来保证消息在失败后被重新处理。需要注意的是，Storm并不保证状态的一致性，任何可变

对比项目spark streamingflink处理模式微批处理，需要设置批的大小流处理，每一条数据都会触发计算时间语义spark streaming 仅支持处理时间(structured streaming支持处理时间和事件时间，同时有watermark处理延迟数据)支持三种时间（处理时间、注入时间、事件时间）准确性保证恰好一次恰好一次...

首先来看一段代码class CorrectionProcessWindowFunc(val allowLateTime: Int) extends ProcessWindowFunction[OnlineRecognitionData, (String, Long, Int), String, TimeWindow] { private final val mapStateWindowDesc = new MapStateDescriptor[String, PidNode]("window-sta

基于metric监控反压反压影响定位反压节点反压监控面板Task Metrics反压影响反压除了会导致数据产出变慢，还会影响到两项指标: checkpoint 时长和 state 大小前者是因为 checkpoint barrier 是不会越过普通数据的，数据处理被阻塞也会导致 checkpoint barrier 流经整个数据管道的时长变长，因而 checkpoint 总体时间（End to End Duration）变长。后者是因为为保证 EOS（Exactly-Once-Semantics，

flink如何做join概览flink join的两个阶段ship strategy(分发)local strategy(本地处理)flink怎么选择join策略？如果数据量过大，怎么避免分发（pre partition、类似spark bucket）概览在单节点小数据量的场景下，最简单的join方式是nested-loop join，该join会产生笛卡尔积，复杂度为o(n2)，显然不适合大数据量join。在分布式系统上的join通常被分为两步：1、各节点上的数据重分区，具有相同key的数据放到

flink背压处理基本原理重要代码分析基本原理流处理框架需要考虑的一个重要问题是协调上下游算子处理速率的问题。比如A->B的一个处理链，B处理速率变慢时，A需要及时作出响应（减慢发送或停发），否则会耗尽内存导致任务崩溃。那flink是如何处理背压的呢？flink处理反压可以分为两种情况：A、A->B重要代码分析...

实时数仓-维度表相关处理概览背景&需求解决方案方案选择概览维度表维护是实时数仓搭建的重要一环，接下来说一下实际工作中维度表维护的思路背景&需求问题1公司内Flink job大概有200个，每个job需要关联3到5张维度表。现有的维度表关联是用mysql source，每个维表需要维护一个链接，非常占用mysql的链接资源问题2基于mysql source的查询是周期性进行的，实际生产中是1h查询一次，此间维度表变化无法及时追踪解决方案plan A开启一个Flink

时态表 Join 意味着对任意表（左输入/探针侧）去关联一个时态表（右输入/构建侧）的版本，时态表可以是一张跟踪所有变更记录的表（例如数据库表的 changelog，包含多个表快照），也可以是物化所有变更之后的表（例如数据库表，只有最新表快照）。怎样将changelog转换为快照？...

flink kafka upsert实现代码解析概览代码分析UpsertKafkaDynamicTableFactory（工厂类）KafkaDynamicSource（product类）FlinkKafkaConsumer(FlinkKafkaProducer)（connector）Q&A概览本文结合源码分析Kafka upsert的实现根据flink官方文档提供的DDL SQL解析流程图，实现自定义TableSource(or TableSink)需要做的事有三个：1、定义可解析catal

自定义table source&sink概览完整的栗子定义TableSourceFactorySocketDynamicTableFactory概览在大多数情况下，开发者不需要从头开始创建新的connector，而是想要略微修改现有的connector或hook。 在少数情况下，开发者想创建专门的连接器。本节针对两种用例都提供帮助。 它说明了表connector的一般体系结构，从API中的声明到将在集群上执行的运行时代码。从SQL到可运行的代码转换分为三个阶段metadata此阶段DD

hive catalog在flink中的应用概览怎样使用HiveCatalog二级目录三级目录概览多年来，Hive Metastore已发展成为Hadoop生态系统的元数据中心。对于同时部署了Hive和Flink的用户，HiveCatalog使他们能够使用Hive Metastore管理Flink的元数据。对于仅部署Flink的用户，HiveCatalog是Flink开箱即用的唯一持久目录。 如果没有持久性目录，使用Flink SQL CREATE DDL的用户必须在每个会话中重复创建像Kafka表这

{“name”:“com.aibee.di.util.Slf4jReporter”,“time”:1609340833346,“date”:“2020-12-30 23:07:13,346”,“level”:“INFO”,“app_id”:“application_1591709976733_1205380”,“thread”:“Flink-MetricRegistry-thread-1”,“message”:{“messageContent”:100,“messageTitle”:“b.

概览JobManager协调每个Flink部署。 它负责调度和资源管理。默认情况下，每个Flink集群只有一个JobManager实例。 这很容易出现单点故障（SPOF）：如果JobManager崩溃，则无法提交任何新程序，并且正在运行的程序也会失败。使用JobManager高可用性，您可以从JobManager故障中恢复，从而消除SPOF。 您可以为独立群集和YARN群集配置高可用性。在链接: Flink Wiki中的JobManager高可用性中查看更多HA实现细节。独立群集高可用性独立集群的J

想研究MapState的底层存储原理，但是点开MapState代码发现put,get没有预期的操作数组或链表等底层存储结构的动作，因为MapState是一个接口，所以使用idea来看一下其实现类的关系图MapState的实现类有如下三个：ImmutableMapState：只读的mapstate，可以调用其get、contain 等方法，调用put、remove方法时会报错UserFacingMapState：mapstate的包装类，可以妥当的将empty state展示为一个empty map

FlinkKafkaConsumer是怎么提交offset的FlinkKafkaConsumer提交offset的模式有以下三种public enum OffsetCommitMode { /** Completely disable offset committing. */ DISABLED, /** Commit offsets back to Kafka only when checkpoints are completed. */ ON_CHECKPOINTS, /** C.

首先抛出一个问题：kafka topic下有3个partition，下游consumer为flink job，flink job的并行度为4，如下图那么window operator的watermark是否会一直很小，导致窗口迟迟不触发计算理清这个问题需要看flink对watermark的处理，StatusWatermarkValve类嵌入了Watermark和StreamStatus两种元素怎么发送到下游到逻辑，KafkaConsumer长时间不接收数据，怎么切换StreamStatus

背景现有业务需要在同一个页面展示全天人次和分时人次，全天和分时对应两个任务，消费同一个topic，两者都使用ContinuousEventTimeTrigger，每隔30s trigger window的计算，两任务operator的背压都是0，那么现在问题来了，如果两个任务间隔10s先后启动，那么之后这两个任务的trigger的时间点是相同的吗？个人误解误认为任务触发的时间为任务启动时间+n*trigger interval，即任务的触发时间和任务的启动时间有关，如下图源码正解Reduci