看过许多分享为什么我还是不懂 Flink？-为什么使用flink

[[432373]]

一、为什么要学习 Flink

随着大数据时代深入普及，数据仓库从业者也必须得跟上时代发展，去学习很多大数据组件，离线数仓我们可以使用 Hive 或者 ODPS 等云服务。传统数仓转型大数据数仓，凭借熟悉的 SQL 实践技能和丰富的数仓方法论等理论知识，想必大家不会遇到太大阻力。

一方面随着数据应用的深入发展，对于时效性的要求越来越高。另一方面大数据技术栈从 Storm 到 Spark Streaming 再到 Flink API 再到 Flink SQL。目前为止，实时计算在吞吐、易用性、稳定性方面已经非常成熟了。

应用上的真实需求伴随实时计算的成熟(特别是这两年 Flink 的大力推广和迭代)，使得实时数仓和批流一体概念成为热点话题，但是离线数仓向实时数仓的转变需要考虑的因素很多，学习起来困难重重。

1.1 Flink 是什么

在 Flink 之前，传统的批处理方式和早期的流式处理框架也有自身的局限性，难以满足延迟、吞吐、容错、便捷性等方面日益苛刻的要求。在这种形势下，Flink 以其独特的天然流式计算特性和更为先进的架构设计，极大地改善了以前的流式处理框架所存在的问题。

Flink 是德国几所大学发起的的学术项目，后来不断发展壮大，并于 2014 年末成为 Apache 顶级项目，美团在 2017 年已经在使用了，直到 2019 年初随着阿里的大力推广，Flink 在国内开始普及，并且版本迭代非常之快，两年半时间已经从 1.7 迭代到 1.14 了。

Flink 目前主要应用在流处理，批处理被认为是流的特例，最终目标是批流一体、完全 SQL 化。

越来越多的国内公司开始用 Flink 来做实时数据处理，其中阿里巴巴率先将 Flink 技术在全集团推广使用，比如 Flink SQL 与 Hive 生态的集成、拥抱 AI 等;腾讯、百度、字节跳动、滴滴、华为等众多互联网公司也已经将 Flink 作为未来技术重要的发力点。在未来 3 ~ 5 年，Flink 必将发展成为企业内部主流的数据处理框架，成为开发者进入大厂的“敲门砖”。

1.2 Flink 能做什么

实时数据计算

双十一电商大促销，管理者要以秒级的响应时间查看实时销售业绩、库存信息以及与竞品的对比结果，以争取更多的决策时间。

股票交易要以毫秒级的速度来对新信息做出响应。

风险控制要对每一份欺诈交易迅速做出处理，以减少不必要的损失。

网络运营商要以极快速度发现网络和数据中心的故障等等。

实时数据仓库和 ETL

离线数据仓库的计算和数据的实时性均较差。在许多场景下，数据本身的价值随着时间的流逝会逐步减弱，因此数据发生后必须尽快的达到用户的手中，实时数仓的构建需求也应运而生。

实时数据仓库的建设是“数据智能 BI”必不可少的一环，也是大规模数据应用中必然面临的挑战。

Flink 在实时数仓和实时 ETL 中有天然的优势：

状态管理，实时数仓里面会进行很多的聚合计算，这些都需要对于状态进行访问和管理，Flink 支持强大的状态管理。
丰富的 API，Flink 提供极为丰富的多层次 API，包括 Stream API、Table API 及 Flink SQL。
生态完善，实时数仓的用途广泛，Flink 支持多种存储(HDFS、ES 等)。
批流一体，Flink 已经在将流计算和批计算的 API 进行统一。

实时数据同步 CDC

Flink SQL CDC 可以从 MySQL、PostgreSQL 等数据库直接读取数据，实时写入到 sink 组件。并且整个过程对源端数据库是没有影响的。

8月份，Flink CDC 2.0 也已经正式发布，此次的核心改进和提升包括：

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

事件驱动型应用 CEP

事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。

常见的应用场景如下：

反欺诈
异常检测
基于规则的报警
业务流程监控
(社交网络)Web 应用
机器学习与图计算

Flink 的野心一点都不比 Spark 小。做为一个统一的一站式大数据计算引擎，虽然这两块目前还没有真正发力，让我们拭目以待吧。

二、坎坷的学习之路

2.1 理论知识学习与动手实操

第一次接触 Flink 还是 2019 年初，那时候 Flink 的使用还仅限于各个互联网大厂，阿里收购 Flink 背后的公司后开始大力宣传，组织了系列性的在线课程，那时候网上的资源还好很少，Flink 的问题还很多。我也只是硬着头皮听到了 1.5 节就掉队了。但当时很欣慰的是我竟然照着 1.3 的手册下载了源码并且编译成功了(那时候还是 1.7 版本)，虽然花费了好几天的时间，但对于开发小白来说已经很满意了。

我为什么会掉队呢，因为纯理论的知识理解起来真的很费劲，而且也记不住，所以就在网上找了些实战视频跟着敲了一两周的代码，比如 PV/UV、电商订单金额计算，并且同时实现了 Spark/Flink 两个版本。但感觉这些更像是个 Demo，因为实际工作环境要面对的问题可要比这些要复杂。最终由于工作中没有实时计算场景也就放弃了。

2.2 试图用 Flink 解决公司实时同步问题

如今，我们公司刚好有了实时计算的需求，很简单，就是要把业务系统的十几张表实时同步到新的数据库中，供数据分析团队使用。之前用的是阿里云服务 DTS，直接 Mysql 实时同步到 ODPS ，但 DTS 同步到 ODPS，数据源的删除更新都会新增一条数据，使用起来会麻烦些需要取最新一条数据同时还要判断该条数据是否已经删除，同时数据还得定期去重保留最后一条用来节省 ODPS 查询成本(ODPS 是按照查询数据量收费的)。

生产环境涉及到的实际问题，视频课程、网上文章永远不会告诉你的(也可能我没找到)。比如实时更新/删除问题、数据质量监控问题、故障恢复重启时候 Kafka offset 读取位置问题、顺序消费问题、流里一条数据跟业务库表历史数据 join 问题等等，还有十几张表数据混在一起表结构、列内容都不一样程序代码又该如何实现呢?

想到这些感觉真的无从下手，之前学的很多理论知识，还有网上的各种分享，这都无法解决我的问题。

没办法，只能硬着头皮上。

方案一：Flink 读取 Kafka 数据 sink 到 Hbase。

Hbase 自动处理更新问题，删除插入速度也很快，可以一条一条写入，忙活了两周终于写完全部代码并测试通过上线试运行了。

我把数据分析团队用到的其他数据也都导入到了 Hbase，再搭建个 Phoenix，最好再开发一套提交 SQL 的 Web 页面就好了。

但很快问题来了：稳定运行一周多后，Hbase 服务器磁盘满了，经查发现存储开销是正常预期的好多倍，相比 ODPS 这样成本就太不划算了。

方案二：Flink 读取 Kafka 数据 sink 到 ODPS。

经咨询 ODPS 的更新删除功能今年三月份才上线，而且处于测试阶段，生产当然不能用，所以只能跟 DTS 一样，数据源的删除更新都新增一条数据做好标记就好。

然后就开始在方案一基础上修改代码了，但一条一条插入性能太慢，后来又费老大劲改用批量插入。

方案三：Flink 读取 Kafka 数据 sink 到 ClickHouse。

这时候其他几个问题基本都已解决，但之前的逻辑还都保持跟业务系统表一样的表结构sink到目标数据库。

走到这一步，我也算是有些实时 ETL 经验了，一开始遇到的很多问题也都解决掉了，但还有一个棘手的问题亟待解决：流里一条业务数据过来后要跟全量历史维度数据 join ，这该如何实现?