本文于12.8首发于公众号“狗哥琐话”。系是B站视频的文字稿。有兴趣的同学可以看B站的视频，搜索“抽象狗哥”。11月29号和30号，Flink Forward Asia 在上海举行。这篇文章给大家搞个省流版，聊聊有什么值得关注的点。Flink近2年的一个大动作就是把Flink的场景从流式计算到流式湖仓，主要是依托于Apache Paimon来建设的。流式...

在去年8月份的时候，我写了一篇文章来宣传自己撸VSCode插件，见历史博客：《想在DataGrip里写SQL般丝滑的写FlinkSQL？安装它就完事儿了》。

《 Microkernel Goes General: Performance and Compatibility in the HongMeng Production Microkernel》论文中提到的一些性能优化的思路和方法是很有学习价值的，结合论文里提到的点，我做了个视频。为了方便大家观看，我梳理了这个文字版本。

前阵子团队里出了个大故障，本质是因为其他语言实现的client有问题，非常频繁的请求大量元数据，而Kafka服务端这边也没有做什么限制，导致Kafka Broker宕了。

版本日期备注 1.02024.8.5文章首发1.0.12024.8.14SF忘记发了，补发本文的的源码分析全部基于TiDB6.5来做分析。前言前阵子在看TiKV统计信息收集实现的时候，看到了Coprocessor有两个版本的实现：激起了我的好奇，所以有了这篇文章。正文在这里先科普一下：TiKV上的Coprocessor 主要是负责是执行物理算子，为 SQL 计算出中...

前阵子团队里有人提到了类似的问题，我自己先是顺手找了一圈，结果只找到了：[链接]。这个框架是基于xorm做的加强，但是在2020年就不维护了。显得很奇怪，明明是唯一一个支持了XML配置SQL的库，后面竟然凉了。

笔者的主力语言是Java，近三年Kotlin、Groovy、Go、TypeScript写得比较多。早年间还写过一些Python和JavaScript。总得来说落地在生产中的语言都是应用级语言，对于系统编程级语言接触不多。但这不妨碍我写下这么一篇笔记，说不定也有一些常年在应用层的同学想领略一下Rust的风采呢。

需求分析是工程师的必备技能之一。我们常说一些架构师多少多少牛逼，系统设计的多好多好——而系统设计的底座正是需求分析。基于详细的需求分析底座加上已知的业界理论上限，才能让我们更好得去设计好一个系统。

一般的数据湖都会设计成开放通用的，即不和特定的存储、计算引擎（比如Spark和Flink）绑定。所以数据湖的定位是在计算引擎之下，又在存储之上，将其称之为table format。

SELECT id, name FROM person WHERE age >= 18 or height > 180 limit 100;：从条件上看，我们看到条件其实是二选一的： age >= 18 or height > 180。基于这种情况，我们肯定会去选择有索引的数据，如果都有索引or都没有，那么肯定选择扫描行数最少的数据。如果有一些算子在里面的话，则额外需要考虑数据的...

TiDB是个非常好用的开源数据库系统。我在生产中一直有接触到TiDB，也是踩了一些坑，故而陆陆续续读了很多关于它的文档，慢慢被这个系统的设计吸引到，因此我决定深入它的内核去读源码，并将一些有意思的设计剖出来聊聊。所以有了今天这篇引子。

今年的A股异常惨烈，Q1润了一下，剩余的日子都在吃好果子。我今年的收益率是-1.7%。对比其他的宽指今年沪深300 -11.3%，中证500 -7.4%，中证2000 +0.1%，恒生-13.82%，几乎是跑赢了大多数指数，因此我给自己打到80分，今年我的仓位总体控制较好，而随着目前A股的性价比越来越高，我开始大量买入。我坚信从A股现在的情况...

在几个月前，我在公司内部推广了我写的FlinkSQL插件，收到了较好的反馈。具体介绍可以见我之前写的博客——《想在DataGrip里写SQL般丝滑的写FlinkSQL？安装它就完事儿了》。

开发VS Code，可以选择使用TypeScript or JavaScript。虽然没学过TypeScript，但是我还是选择了它。我想起大学工作室的时候，身边有小伙伴就特别喜欢JavaScript这种写起来很快的语言，但是我却更喜欢Java这种语言。因为有些时候我根本不知道JavaScript里的一些变量的值到底是什么。

“FlinkSQL对于大数据开发者们来说是一个很常见的API，它的存在巨幅提升了开发效率，使开发者不用再面向底层细节，可以更加专注于自己的业务。”我在刚开始写FlinkSQL时，留下了这样的印象。

版本日期备注1.02023.5.15文章首发1.12023.5.28增加代码示例1.22023.5.30改善内容1.32023.11.15增加元编程部分的讨论本文首发于泊浮目的掘金:[链接]0. 概要最近因为业务需要在学Go语言，虽然之前也用过别的语言，但主力语言一直是Java。在这里也想主要想用Java做对比，写几篇笔记。这篇主要是讲语言本身及较为表面的一些...

在前面的系列文章中，我提到了相关的理论，实操，以及一段工作经历。在这篇文章中，我会用我自己和团队的经历来作为例子，诠释面向价值编程，并通过两个例子说明高ROI工程的打造过程。

又是一年，感觉这一年有许多知识输入了自己的大脑，看了眼自己年初给自己定的目标，还是差了许多——距离四级工程师仍有一段距离。不过我的身边已经有了两个可以参考的人，一个是生活圈里的，一个是共事的同事——我们从事的方向也一致，我可以很明显看到自己与他们的差距——有了具体的方向，我便可以在这条路上走更少的弯路。

12.18 我自己症状出现：早上起来发现咽喉有点疼，期间无任何症状。到了晚上8点左右开始发热，意识到不对。睡前开始腰部、大腿部分疼痛，明显畏寒。

17年刚加入ZStack时，ZStack正在经历从能用到好用的阶段。这个阶段会有更多的需求，对质量的要求也会更高。举个例子，toB的产品如果在一个行业里拓展开，一般都会想办法拿下龙头企业。大家都是这么想的，你会面临更多的竞争对手。抛去其他层面，单从技术层面来说，技术人员不仅需要提供相应的功能满足客户需求，还需要考...

从2021年，各个大厂的反内卷，再到2022年的裁员，大多数人都意识到互联网行业进入了寒冬。其实并非这个行业如此，其他的行业也正在严寒中苟活。宏观原因其实显然易见，但这并非本文讨论的主题。在这里，更想和大家讨论的是如何在这个冬天苟活下来。

最近接了几个项目，代码质量参差不齐。本想按照以往的实践建议每个patch都做review，但往往dead line当头。我会想，我如果对这次patch做了review、以及长期做review能给业务带来什么价值。接着本文，我还想讨论其他技巧在coding中也能够明显带来价值。

前阵子在B站刷到了周志明博士的视频，主题是云原生时代下java，主要内容是云原生时代下的挑战与Java社区的对策。这个视频我在两年前看到过，当时也是印象深刻。现在笔者也是想和大家一起看看相关项目的推进以及一些细节。这篇笔记会大量参考视频中提到的内容，如果读者看过相关视频，可以跳过这篇笔记。

由于早期的流处理框架并不支持Exactly Once，导致流处理的数据并不精准。在这个基础上，一旦数据出现问题，则要导致大量的数据重放——这是因为事件往往是有时序要求的。因此，Lambda往往会通过流处理框架获取不是特别精准的结果，同时也会定时运行批处理程序，来获取更精准的结果——当更精准的结果出来时，我们就不需要前...

前阵子在生产上碰到了一个诡异现象：全量作业无法正常进行，日志中充斥着java.util.concurrent.TimeoutException: Heartbeat of TaskManager with id container xxxx(HOSTNAME:PORT) timed out的报错。

将Flink应用至生产已有一段时间，刚上生产的时候有幸排查过因数据倾斜引起的Checkpoint超时问题——当时简单的了解了相关机制，最近正好在读Flink源码，不如趁这个机会搞清楚。

前阵子组里的小伙伴问我“为什么Flink从我们的代码到真正可执行的状态，要经过这么多个graph转换？这样做有什么好处嘛？”我早期看到这里的设计时的确有过相同的疑惑，当时由于手里还在看别的东西，查阅过一些资料后就翻页了。如今又碰到了这样的问题，不妨就在这篇文章中好好搞清楚。

写这篇文章前，我翻看了一下去年的总结。发现“人终将一死”这个想法在那时便植入我的脑海里。每当早上醒来，睁眼看到太阳升起，我便会想到这个事——这倒不会让我产生负能量，我只是会想这辈子能做些什么，变成什么样的人。这意味着我很难在一些简单的事中获得满足或沉溺于一些唾手可得的欲望之中。

在最初接触到Flink时，是来自于业界里一些头部玩家的分享——大家会用其来处理海量数据。在这种场景下，如何避免JVM GC带来StopTheWorld带来的副作用这样的问题一直盘绕在我心头。直到用了Flink以后，阅读了相关的源码（以1.14.0为基准），终于有了一些答案。在这篇文章里也是会分享给大家。

最近负责了产品中一部分的监控事宜。我想到时序数据库的对于RT和IOPS的要求应该很高，因此想看看它内部是怎么实现的——会不会和我认识的Kafka、HBase很像。

前阵子笔者涉及了些许监控相关的开发工作，在开发过程中也碰到过些许问题，便翻读了Flink相关部分的代码，在读代码的过程中发现了一些好的设计，因此也是写成文章整理上来。

之前的DDD文章——谈谈代码：降低复杂度，从放弃三层架构到DDD入门，通篇下来像 是简单的讲了一些概念，然后快速的实战一下——很多同学反馈感觉就是入门了，但没有完全入门，因此我们再加一篇。

但这有一个问题，需要分配端口。之前我们团队用了很多麻烦的实现：分布式锁、多份状态存储等...但仍然避免不了端口泄漏、浪费的问题（拓扑高可用机制会导致它在不同的机器间偏移，那么之前分配的某机器端口就无用了）。尽管我们也可以去监控拓扑的生命周期，但这绝非易事——在较大的场景中，k级的拓扑是很正常的，然而要...

本文首发于泊浮目的简书:[链接]版本日期备注1.02021.8.1文章首发1.12021.8.3改进部分描述1.前言最近我发现团队某项目的复杂度越来越高（典型的三层架构），具体表现为：代码可读性较差：各个服务之间调用复杂，流程不清晰修改某服务业务代码导致大量无关服务的测试用例失败，单个功能开发者很难迅速定位相关问题测试用例...