tyrantlucifer

ff2c4537276fa5cbd14f53c68cacf7a78e0a3cfb1b59ec5dd13d56c6df145edd656a86b2159d6ed9f3215cd5e195f3f0ec1f732fe4ed6af770ccdd0ddc5be6d3953f7e0a769ca9384846433d04df9f972441743cc8bb1862fd377607242be323c47cab365dfe21526e5d0d10dc2930208f1340f148964ab174ed0821147e520f20e7668e7b43aa210398c76cccde88e405b18c7dbf6a6bd19a20dcd7a1fd063b5010831465a1ec9320b813d90bd4ba7fdeb1349b5b03630402242b508f619f57bcfae173e2370fa54941a13410334d9253d334ca60dfdfea8db504d56b0977c6fa73bf9ddac9ec166c4751ee09671026ab4e5889c9b65928e ...

Fluss - 面向分析的实时流存储初探 前言 在11月29日的FFA 2024上，阿里巴巴Flink团队在直播中正式开源了Fluss项目（https://github.com/alibaba/fluss) 开源过程中也出现了非常欢乐的小插曲，在访问Github的过程中遭到了神秘力量的阻拦，啼笑皆非过后，神秘的Fluss正式和大众亮相，在笔者写下这篇文章的时候，该项目的Star数量已经接近500，笔者作为大数据从业者以及开源爱好者也在下班后第一时间按照官网的quick-start教程快速体验了一把Fluss。本篇文章旨在对Fluss做一个简单的了解（通过官网）和案例展示，笔者水平有限，如有谬误，欢迎各位读者给予宝贵的建议和指正，接下来请跟随笔者的脚步，一点点揭开Fluss神秘的面纱。 Fluss - 奔腾不息的河流 Fluss 项目是由阿里云智能 Flink 团队研发的一款面向流分析的下一代流存储，旨在解决流存储在分析方面长期存在的挑战。Fluss 的项目定位是为 Apache Flink 提供实时流存储底座，进一步提升 Flink 实时流计算的能力。因此，Fluss 的名字源自“F ...

ff2c4537276fa5cbd14f53c68cacf7a7043312d650a54bcb4d9b6c04ab627072d19e477a89787ef209328e23a6a75f18b76fa71e325ad4b34643eea329415dd4089258f9425d628075dcbb98de3ea40f15c8ac64573aae12fae639b4439d5a49f2a28921b152e4528d0b6e0e3b97dcdc939fe64d4b8e4e7ae658584597d70051dd69266df0b08e64ae4529e882cf5cf51d7eb1727d52540b21e30269eeae59a2eb0ccdf0724d2ca0300c8c8fc3325df67801d1e8af811047e50ef59dfcfd4b5c82ebd26fb31978687efac9b31336de4c22e382479794aeade2e1cc7c6758081c36b72ea6bf26eae9dbffa41c85af7ab6220bcf1f960362759 ...

今天，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采用基于水印的方法，可以将直接从表中选择的行与事务日志事件同时处理，以捕获完整状态。我们的解决方案可以在处理选择操作时，让日志事件继续进行而不会陷入停滞。选择操作可以在任何时候对所有表、特定表或表的特定主键进行 ...

ff2c4537276fa5cbd14f53c68cacf7a752c4b918212cd985e32b2680c9dc2c55295822a6e21278908d40279f69161a56937eebb7b4e41af64001b6732365e036fa4e6b536ca9fd00925abca31c7614ed72339d0e5ec4fdd6a1671e9e596a07ca7c432d6d634fda2a60439e1dfda01ba932776d93b75cfa33eb27f001be60543fb539177db980e47ce9deec12137ec97828325403cf83965b37e007ee6288c9ac03106df657aaaf9954d9eee6a07b602553a0320425ed016e5c4aacddb078f00aa1c0970b451fcd2329620136e22fae0fcedc41d6ad905b0ed3267ae667de9a1e36cd73a0256ded3ef8aeaa7a80b94be5599946caff4bc6c5c ...

前言 近期，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进行笔记输出和知识沉淀。 笔记保存 在进行完笔记的技术选型之后 ...