tyrantlucifer

2023年最后一天，例行打开电脑，我写下了这篇年终总结，今年的主题曲是买辣椒也用劵的不寻常夏日。 临近年末，有很多话想说，却又不知从何说起，不知不觉时钟再次拨转到了12月31日，意味着一年的时间即将结束，从生理上年龄再次增加了一岁，距离奔三越来越近，内心中的情绪难以名状，不知用语言如何形容。 2023年对于我个人而言是整体还算比较顺利的一年，也是收获果实的一年，在这一年里完成了几件大事，各方面都有不同程度的进步，当然也并不都是一帆风顺，但人生嘛，总会起起落落，降低内心预期，踏实过好每一天会让自己更幸福。情感方面依旧是没有任何起色，长期不谈恋爱已经忘记了谈恋爱的感觉，甚至会后怕开始一段新的感情，一旦选择开始，就会意味着要思考未来的规划、发展，结婚生子对我来讲说远不远，但扪心自问，我还没有准备好要接受这个现实，身边的同学陆陆续续都已经走入婚姻的殿堂，甚至有些人宝宝快要出生，来自于现实的压力无形的笼罩在我心头，这种矛盾的情绪始终让我自己无法做出正确的选择，也无法调整好正常的心态，那我只能逃避，过一天算一天。 刚开年的1月份还是日常的吃吃喝喝，享受生活： 木屋烧烤 海底捞 凑凑 ...

今天，SeaTunnel毕业了，成为真正的Apache Top Level Project，我也终于实现了去年许下的愿望，成为一名TLP的PMC，有很多话想说，但也不知道从何说起。 2022年2月11日我第一次参与开源的经历[1]至今还历历在目，跟所有第一次贡献Apache项目的同学一样，我怀揣着激动且忐忑的心情，迫切的希望将自己的pr合并到主分支，但由于是第一次，没有任何经验，踩了很多坑，走了很多弯路，经过社区大佬的指引，review了很多轮次之后，我的pr终于如愿以偿被merge，当看到pr状态从绿色的open转变为紫色的merged时，内心的愉悦是难以言表的，这次的经历对我来说，不光对我带来了精神上的振奋，更重要的是为我打开了走向Apache开源的大门。 做开源是我一直以来的夙愿，我很喜欢coding，也很享受整个coding的过程，以及享受解决一个个难题带来的多巴胺分泌的精神愉悦，开源可以获得其他人的认可，我其实是一个自我认可程度蛮低的人，由于种种变故，从小有一个好成绩的我没能上一个好大学，没有一个好的学历一直是我心头的难言之隐，我希望在其他方面弥补，可总是于事无补，做开源可能 ...

原文地址：DBLog: A Watermark Based Change-Data-Capture Framework 摘要 应用程序通常会使用多个异构数据库，每个数据库都用于服务于特定的需求，例如存储数据的规范形式或提供高级搜索功能。因此，对于应用程序而言，将多个数据库保持同步是非常重要的。我们发现了一系列尝试解决此问题的不同方式，例如双写和分布式事务。然而，这些方法在可行性、稳健性和维护性方面存在局限性。最近出现的一种替代方法是利用变更数据捕获（CDC）框架，从数据库的事务日志中捕获变更的行，并以低延迟将它们传递到下游系统。为了解决数据同步的问题，还需要复制数据库的完整状态，而事务日志通常不包含完整的变更历史记录。同时，某些应用场景要求事务日志事件的高可用性，以使数据库尽可能地保持同步。 为了解决上述问题，我们开发了一种用于数据库的新型CDC框架——DBLog。DBLog采用基于水印的方法，可以将直接从表中选择的行与事务日志事件同时处理，以捕获完整状态。我们的解决方案可以在处理选择操作时，让日志事件继续进行而不会陷入停滞。选择操作可以在任何时候对所有表、特定表或表的特定主键进行 ...

2022年最后一天，例行打开电脑，耳机里播放着蔡健雅的Letting go，我写下了这篇年终总结。 2022年，对于全世界而言，同样是被疫情肆虐的一年，对于中国而言，2022年是结束了三年疫情防控的转折点，没有了核酸检测，没有商场扫码，也没有了居家隔离，突然政策的放开让所有人都没有做好准备，而作为第一波中招的我也是经历了很难受很痛苦的抗疫时期，至今为止，办公室里还充斥着此起彼伏的咳嗽声，很不幸我也是其中的一员，疫情后时代的到来给整个国家带来了新的机遇，也带来了更多的挑战，2023年新冠病毒将彻底改名，退出历史舞台，这种感觉难以名状。 2022年对于我自身而言，是一个蜕变和成长的年头，技术方面我有了些长足的进步，在情感方面我也摆脱了前任对于我自身的束缚，过去2年半时间里我一直活在对于上段感情的愧疚之中无法抽身，每每想起过去的种种，我会很难过，每个人可能青春中都有各种各样的遗憾，无法弥补也无法回退，唯有随着时间长河的向前流动才能因为时间的流逝而慢慢消散，从各个渠道得知她过的很好，也证实了当时的观点：没有我她也能过得很好，而我没了她过的只能说一般，用行动证明了这个致命真理，两个人从相交线变成 ...

前言 近期，Apache SeaTunnel经过几个月的迭代和架构升级，终于迎来的v2的第一个正式版本2.3.0，我也有幸作为本次的Release Manager，体验了一把从0到1的Apache发版流程，不得不说Apache基金会在项目的版本管理这块有着完善的规范和严谨的流程，整个发版过程周期很长，其中也踩了不少的坑，俗话说好记性不如烂笔头，所以笔者写了一篇文章来记录整个过程（以Apache SeaTunnel为例），希望这篇文章能够让小白快速入门Apache项目版本管理和发布。 Tips: Release Manager需要有Apache LDAP账号，也就意味着你需要首先成为项目的Committer才有资格 环境准备 GIT 用于clone项目源代码到本地 GPG 用于生成数字签名，为你的每一次操作留下痕迹 SHASUM 用于为文件生成签名 SVN 用于拉取Apache Release SVN仓库 MAVEN 用于编译项目 物料准备 配置GPG KEY 新建key 1gpg --gen-key 123456789101112131415161718192021 ...

关于我 我是tyrantlucifer，目前是Apache SeaTunnel社区的PPMC & Committer，在一家不知名公司任职大数据开发工程师，工作方向主要聚焦于数据集成领域的探索和实践，平时也会用诸如Spark、Flink这样的分布式计算引擎做一些业务数据处理的工作，我是一名纯粹的开源爱好者，喜好用爱发电，热爱写代码，今天很高兴能够再次受到社区邀请，在这里讲述我与Apache SeaTunnel的故事。 初识WaterDrop 熟悉SeaTunnel的老朋友们应该会知道，其实SeaTunnel没进孵化器之前就是市面上开源许久的WaterDrop，在SeaTunnel进孵化器的前期，我有幸因为工作缘故，接触到了WaterDrop，由此开启了我与SeaTunnel的不解情缘。 当时我在公司内部负责维护公司自己的数据集成引擎，但由于技术选型和当前业务的不匹配，导致数据传输效率过慢，引擎已经满足不了离线需求的日益增长，为了解决这个痛点，我去调研了WaterDrop，并被它的设计思路和架构深深吸引，并将它成功集成到了公司的数据集成引擎之上。 参与SeaTunnel贡献 在我 ...

核心概念 整个SeaTunnel设计的核心是利用设计模式中的控制翻转或者叫依赖注入，主要概括为以下两点： 上层不依赖底层，两者都依赖抽象 流程代码与业务逻辑应该分离 对于整个数据处理过程，大致可以分为以下几个流程：输入 -> 转换 -> 输出，对于更复杂的数据处理，实质上也是这几种行为的组合： 内核原理 SeaTunnel将数据处理的各种行为抽象成Plugin，并使用SPI技术进行动态注册，设计思路保证了框架的灵活扩展，在以上理论基础上，数据的转换与处理还需要做统一的抽象，譬如比较有名异构数据源同步工具DataX，也同样对数据单条记录做了统一抽象。 在SeaTunnel V1架构体系中，由于背靠Spark和Flink两大分布式计算框架，框架已经为我们做好了数据源抽象的工作，Flink的DataStream、Spark的DataFrame已经是对接入数据源的高度抽象，在此基础上我们只需要在插件中处理这些数据抽象即可，同时借助于Flink和Spark提供的SQL接口，还可以将每一次处理完的数据注册成表，方便用SQL进行处理，减少代码的开发量。 实际上SeaTunnel最 ...

前言 作为一名技术工作者，持续的学习和记录是延续职业生涯的必备技能，有效的记录在网络浏览过程中获取到的知识点和定期的自我总结是提升自我的最佳途径，从接触计算机学习以来，我的笔记工作流随着知识面的扩张不断更改，到现在趋于稳定且效率还不错，所以想借此机会分享给大家，希望我走过的弯路能够减少大家的学习成本。 如何记录 对于技术的沉淀与文档记录，在我看来更多的是需要条理清晰，排版明确，不拖泥带水，也不要过多冗余，文档要有层次，最好要图文并茂。 基于这些特点，首先第一个想到是老牌文档Word，但Word虽好，也有很致命的缺点，那就是排版困难，不宜保存留档，严重依赖微软全家桶或wps全家桶，各个设备浏览不是很方便，可能我为了去排版一篇笔记要花半个小时，效率及其低下；随着知识面的不断增长，我接触到了Markdown，这种简单清晰明了的语法能够快速排版，笔者只需要专注于内容的输出，不需要花过多的时间在排版上，大大提升了生产力。 实际上Markdown这种语法在市场上也颇受技术工作者们的喜爱，目前95%以上的技术从业者都会使用Markdown进行笔记输出和知识沉淀。 笔记保存 在进行完笔记的技术选型之后 ...

前言 书接上回，继续来聊一聊DataX源码，在上篇文章中我们已经对于DataX的调度流程进行了细致的剖析，这篇文章我们将更深层次的研究DataX在数据传输与交换方面的细节。 简单回顾 上文提到，DataX核心运行子单位是TaskExecutor，一个TaskExecutor中会拥有两个线程，分别是WriterThread和ReaderThread，这两个线程承担着整个数据传输的重任，所以今天整篇文章的重点将围绕这两个线程展开，如果读者阅读至此觉得概念晦涩难懂，请移步我之前的两篇文章去先了解一下整个DataX的原理和架构： DataX整体架构 DataX调度流程 线程的创建 来到TaskGroupContainer源码中，找到TaskExecutor新建WriterThread和ReaderThread的地方： 1234567891011// 生成WriterThreadwriterRunner = (WriterRunner) generateRunner(PluginType.WRITER);this.writerThread = new Thread(writerRunner, ...

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253/************************************************************************** File Name: quickSort.c* Author: TyrantLucifer* E-mail: TyrantLucifer@gmail.com* Blog: https://tyrantlucifer.com* Created Time: Sun 10 Apr 2022 02:29:02 PM CST ************************************************************************/#include <stdio.h>void printArray(int array[], int length) { for (int i = 0; ...