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 的设计方案,核心要解决上述的三个问题:
并且最终在性能上达到了数倍的提升。
在整个2.0设计方案过程中,其实就是我们解决一个问题或者业务场景设计方案的过程,这个思路是大家写在技术方案或者简历项目描述中的内容,这也是大家最关心的部分。你需要突出的是基于什么样的业务场景解决了什么问题。
针对当前的一些现状,社区的Maintainer也在思考在FlinkCDC的不足,思考CDC乃至数据集成领域面临的技术挑战:
最终,面向数据集成用户、面向端到端实时数据集成的框架FlinkCDC 3.0应运而生。
这是未来发展/迭代的方向,也就是未来你在你的简历/总结文档中面试官问到的一些开放性问题的思考方式。
类似开放性的问题在很多比较高阶的面试中经常遇到,这个思路现在你学会了吧?
如果这个文章对你有帮助,不要忘记 「在看」 「点赞」 「收藏」 三连啊喂!