隔音窗怎么选,分享下我的经验

现在噪音真的是一个非常头疼的问题,家附近有高架、机场、工地之类的噪音源会对睡眠产生很大影响。很不巧,我家附近的一条路有大货车经过,巨大的噪音非常令人崩溃,还好通过安装隔音窗基本解决了问题,现在把相关经验记录下来供大家参考,也建议在买房前一定要关注噪音问题,事后补救是非常麻烦的🤣。 1.什么是隔音窗 现阶段流行的是断桥铝门窗+双层中空玻璃,对于一般家用场景是足够了,一旦噪音稍大可能就不太够用了,需要安装隔音窗来隔绝噪音。 隔音窗和普通窗户没有本质上的区别,通常通过升级玻璃、窗框、开扇来实现更好的隔音效果,后面会详细展开介绍。 2.隔音窗是否能解决问题 噪音是无孔不入的,隔绝噪音是个系统工程,隔音 […]

【OutOfMemory专题】3. Direct Memory泄漏如何排查

上两篇文章中分别介绍了Spark堆内和堆外内存溢出的排查案例,这次我们来看一个Flink任务的真实案例。 有一个线上任务,代码逻辑相对简单,从kafka读取数据,进行异步查询后落地数据到hdfs: 此任务启动后1-2天就会出现内存超出Yarn container限制而被终止的异常: 2024-05-06 00:16:36,280 INFO org.apache.flink.runtime.resourcemanager.active.ActiveResourceManager [] – Worker container_e10_1634010428940_125776_01_000003 is […]

【OutOfMemory专题】2. 限制Xmx还不够?

上一篇文章我们通过一个真实案例介绍了Spark任务堆内存溢出的排查思路和方法,接下来啃一个硬骨头:Container killed by YARN for exceeding physical memory limits。 如果你经常在Yarn集群执行Spark任务,一定会遇到这个异常,我们只知道Executor使用的内存超过了向Yarn申请的内存,但是具体原因如何排查呢?为什么-Xmx参数已经限制了堆内存大小,还是会溢出呢? 1.JVM内存构成 要解决这个问题,我们先要了解JVM的内存构成: Heap Space:也就是堆内存,大小由Xmx和Xms控制,由jvm负责进行垃圾回收,溢出时会产生 […]

Flink源码中奇怪的注解

Flink源码中经常会出现以下注解: @GuardedBy @ThreadSafe @Nullable @PublicEvolving …… 这些注解在Flink中的作用主要分为几大类: 代码静态检查: @GuardedBy 检查操作被注解的对象/方法前是否对指定锁对象进行加锁 @ThreadSafe 类是线程安全的 @Nullable 被标注对象可以为空 接口迭代状态&发版对比: @PublicEvolving 类/方法相对稳定,可以被外部调用,但接口/签名(返回类型+参数类型)可能会发生变化 @Public 类/方法相对稳定,只有跨大版本才可能进行修改 @Experimen […]

Flink Internals:job及其调度

这篇文章大致介绍Flink如何调度job以及JobManager是如何表示并追踪其状态的。 调度 Flink中的执行资源通过Task Slots来定义。每一个TaskManager拥有一个或多个task slots,每个slot可以执行并行任务中的一个pipeline。一个pipeline包含多个连续任务,例如第n个MapFunction和第n个ReduceFunction实例的组合。注意Flink经常并行执行连续任务:对于流处理程序十分常见,对于批处理程序也经常发生。 下图说明了这一点。设想一个程序有一个data source,一个MapFunction和一个ReduceFunction。S […]

在Flink中引入流式窗口

  数据分析领域正在见证许多用例从批处理到流处理的演变。尽管批处理可以被作为流处理的一个特殊例子,处理永不结束的流式数据通常需要转换思维方式且通常有自己的术语(例如“窗口”和“最少一次/只有一次”处理)。这对于新接触流处理的人来说可能会相当疑惑。Flink是一个可用于生产的流处理器,具有易于使用但有表现力的API来构建高级流式分析程序。Flink的API在数据流窗口的定义十分灵活,使其从其他开源流处理器中脱颖而出。   在这篇文章中,我们将讨论流式处理窗口的概念,展示Flink内置窗口并解释其对自定义窗口语义的支持。 什么是窗口,窗口有什么用? &ems […]

FLIP-27: 重构Source接口

动机 此FLIP旨在解决当前流式source接口(SourceFunction)的一些问题和短板,同时统一流批的source接口。我们要解决的缺点或要点: 当前批流的source实现是不同的。 “工作发现”(splits,partition等)和实际的数据“读取”混杂在SourceFunction接口和DataStream API中,导致注入Kafka和Kinesis这类source的实现十分复杂。 Partitions/shards/splits在接口中不明确。这使得实现一个source无关的特定方法十分困难,例如event-time对齐,per-partition watermarks,动 […]