FlinkCDC发展历程和简历中项目描述的思路

Hi，大家好，今天的天气依然很冷。冻成狗了呀！

前两天，FlinkCDC 3.0版本发布。Flink CDC的定位也发生了变化，从捕获数据变更的Flink数据源正式迈向为以Flink为基础的端到端流式ELT数据集成框架。

这些不是我们今天的重点。

今天简单说一下在整个框架发展过程中给我们学习进阶/写简历面试/项目总结上的一些启示。

这也是我经常被问到的问题，我应该怎么去描述和总结过去我做过的项目？

下面这些思路可以完美应用在简历、项目总结、项目描述上。🤔️

背景

最初CDC诞生也是基于现实的需要，也就是：传统的基于 CDC 的 ETL 分析中，数据采集工具是必须的，国外用户常用 Debezium，国内用户常用阿里开源的 Canal，采集工具负责采集数据库的增量数据，一些采集工具也支持同步全量数据。采集到的数据一般输出到消息中间件如 Kafka，然后 Flink 计算引擎再去消费这一部分数据写入到目的端，目的端可以是各种 DB，数据湖，实时数仓和离线数仓。

那么是否可以使用 Flink CDC 去替换上图中虚线框内的采集组件和消息队列，从而简化分析链路，降低维护成本。同时更少的组件也意味着数据时效性能够进一步提高。

答案是可以的，于是就有了我们基于 Flink CDC 的 ETL 分析流程。

上面这些其实就是我们在做一个项目总结，或者简历中的项目描述，或者新技能学习过程中的「背景部分」。通常，这部分是要让你的受众快速了解你在做的项目/事情的背景是什么。

背景又分为两部分。 第一部分是技术类的，你做过的项目要解决什么技术痛点/技术难点。 第二部分是业务类的，可以是因为某个业务场景或者业务需求。

背景就对应目标🎯，从引入背景到目标，中间就是我们要讲的第二部分：技术方案。

技术方案和最终效果

在最初的设计中，Flink CDC暴露了一些痛点。

正是因为这些痛点，确立了2.0 的设计方案，核心要解决上述的三个问题：

• 并发读取，全量数据的读取性能可以水平扩展
• 全程无锁，不对线上业务产生锁的风险
• 断点续传，支持全量阶段的 checkpoint

并且最终在性能上达到了数倍的提升。

在整个2.0设计方案过程中，其实就是我们解决一个问题或者业务场景设计方案的过程，这个思路是大家写在技术方案或者简历项目描述中的内容，这也是大家最关心的部分。你需要突出的是基于什么样的业务场景解决了什么问题。

未来发展

针对当前的一些现状，社区的Maintainer也在思考在FlinkCDC的不足，思考CDC乃至数据集成领域面临的技术挑战：

• 历史数据规模大：数据库的历史数据规模大，100T+ 规模很常见
• 增量数据实时性要求高：数据库的增量数据业务价值高，且价值随时间递减，需要实时处理
• 数据的保序性：CDC 数据的加工结果通常需要强一致性语义，需要处理工具支持全局保序
• 表结构动态变化：增量数据随时间增长，数据对应的表结构会不断演进

最终，面向数据集成用户、面向端到端实时数据集成的框架FlinkCDC 3.0应运而生。

这是未来发展/迭代的方向，也就是未来你在你的简历/总结文档中面试官问到的一些开放性问题的思考方式。

类似开放性的问题在很多比较高阶的面试中经常遇到，这个思路现在你学会了吧？

如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！