1。为什么要学习Flink？随着大数据时代的普及，数据仓库从业者也必须跟上时代的发展，学习很多大数据组件。离线数仓我们可以使用Hive或者ODPS等云服务。传统数据仓库转型大数据数据仓库，依靠熟悉的SQL实战技能和数据仓库方法论等丰富的理论知识，想必你不会遇到太大的阻力。一方面，随着数据应用的深入发展，对时效性的要求越来越高。另一方面，大数据技术栈从Storm到SparkStreaming到FlinkAPI再到FlinkSQL。到目前为止，实时计算在吞吐量、易用性和稳定性方面已经非常成熟。应用的真实需求和实时计算的成熟（尤其是近两年Flink的大力推广和迭代）让实时数仓和批流融合的概念成为热门话题，但是转型从离线数仓到实时数仓，需要考虑的学习困难的因素有很多。1.1什么是Flink在Flink之前，传统的批处理方式和早期的流处理框架也有其自身的局限性，难以满足在延迟、吞吐量、容错性和便利性等方面日益严苛的要求。在这种情况下，Flink以其独特的天然流计算特性和更先进的架构设计，大大改善了以往流处理框架存在的问题。Flink是德国多所大学发起的学术项目。后来不断壮大，2014年底成为Apache顶级项目，2017年美团就已经在用了，直到2019年初，在阿里的大力推动下，Flink在国内起步。人气，而且版本迭代很快，两年半时间从1.7迭代到1.14。Flink目前主要用于流处理。批处理被认为是流的特例。最终目标是批流一体化，完成SQL化。国内越来越多的公司开始使用Flink进行实时数据处理。其中，阿里巴巴率先在全集团推广使用Flink技术，如融合FlinkSQL与Hive生态、拥抱AI等；腾讯、百度、字节跳动、滴滴、华为等众多互联网公司也将Flink作为未来技术的重要起点。未来3到5年，Flink必将发展成为企业内部主流的数据处理框架，成为开发者进军大厂的“敲门砖”。1.2Flink可以用实时数据做双十一电商促销的计算。管理者需要以秒级响应时间查看实时销售业绩、库存信息、与竞品对比结果，为决策赢得更多时间。股票交易需要以毫秒级的速度响应新信息。风险控制应迅速处理每一笔欺诈交易，以减少不必要的损失。网络运营商需要以极快的速度发现网络和数据中心故障等。实时数仓和ETL离线数仓计算和数据的实时性较差。在很多场景下，数据本身的价值会随着时间的流逝而逐渐减弱，所以数据产生后必须尽快到达用户手中，构建实时数仓的需求也应运而生时代需要。实时数仓的构建是“数据智能BI”不可或缺的一环，也是大规模数据应用中不可避免的挑战。Flink在实时数仓和实时ETL方面有着天然的优势：状态管理，大量的聚合计算在实时数仓中进行，都需要状态的访问和管理，而Flink支持强大的状态管理。丰富的API，Flink提供了极为丰富的多层次API，包括StreamAPI、TableAPI和FlinkSQL。生态完备，实时数仓用途广泛，Flink支持多种存储（HDFS、ES等）。批流融合，Flink一直在统一流计算和批计算的API。实时数据同步CDCFlinkSQLCDC可以直接从MySQL、PostgreSQL等数据库读取数据，并实时写入sink组件。并且整个过程对源数据库没有任何影响。8月份，FlinkCDC2.0也已经正式发布。本次核心改进和增强包括：并发读取，全量数据读取性能可横向扩展；全程无锁，线上业务无锁风险；断点续支持全阶段checkpoint。事件驱动的应用程序CEP事件驱动的应用程序是有状态的应用程序，它从一个或多个事件流中提取数据并触发计算、状态更新或其他基于传入事件的外部操作。常见的应用场景如下：反欺诈异常检测基于规则的报警业务流程监控（社交网络）Web应用机器学习和图计算Flink的野心不亚于Spark。作为统一的一站式大数据计算引擎，这两部分虽然还没有真正发力，但让我们拭目以待。2.坎坷的学习之路2.1理论知识学习与动手实践第一次接触Flink是在2019年初，当时Flink的使用仅限于各个互联网公司。系列在线课程。当时网上的资源非常少，Flink的问题还很多。我也是硬着头皮在听到1.5节后落后了。不过当时还是很欣慰的，按照1.3手册下载了源码并编译成功（当时还是1.7版本）。虽然花了好几天时间，但我对小白的发展还是很满意的。为什么我落后了，因为纯理论知识真的很难看懂，记不住，于是在网上找了一些实用的视频，跟着代码看了一两周，比如PV/UV，e-commerce订单金额计算，Spark/Flink两个版本同时实现。但是感觉更像是一个Demo，因为实际工作环境中面临的问题比这些更复杂。最后放弃了，因为工作中没有实时计算的场景。2.2尝试使用Flink解决公司的实时同步问题现在，我们公司刚好有实时计算的需求。很简单，就是将业务系统中的十几个表实时同步到新数据库中，供数据分析团队使用。之前用的是阿里云服务DTS，直接把Mysql实时同步到ODPS，但是DTS同步到ODPS后，数据源删除或更新时，会新增一条数据，使用起来很麻烦.需要抓取最新的数据，判断数据是否被删除，同时要定期对数据进行去重，保存最后一条数据，节省ODPS查询成本（ODPS是按数据量多少收费的）查询数据）。生产环境涉及的实际问题，视频课程，网络文章永远不会告诉你（可能我没发现）。比如实时更新/删除问题，数据质量监控问题，Kafka故障恢复和重启时偏移读取位置问题，顺序消费问题，流中的一条数据与业务数据库表中历史数据的join问题，等等，十几个表数据混在一起，如何实现不同表结构和列内容的程序代码？想到这些，我实在是无从下手。之前学习的很多理论知识，还有网上的各种分享，都不能解决我的问题。没有别的办法，只能硬着头皮上。方案一：Flink读取Kafkadatasink到Hbase。Hbase自动处理更新问题，删除插入速度也很快。可以一个一个写。经过两周的忙碌，终于把代码全部写完，通过了线上试运行。我也把数据分析组用到的其他数据导入到Hbase中，然后建了一个Phoenix。最好开发一套提交SQL的网页。但是很快问题就来了：稳定运行一个多星期后，Hbase服务器的磁盘满了，发现存储开销是正常预期的很多倍，相比ODPS不划算.方案二：Flink读取Kafkadatasink到ODPS。经咨询，ODPS的更新删除功能是今年3月份才上线的，目前还在测试阶段。当然不能在生产中使用，所以只能和DTS一样，数据源的删除和更新要标记一条新的数据。然后我开始在方案一的基础上修改代码，但是一个一个插入的性能太慢了，后来费了好大劲才改成批量插入。方案三：Flink读取Kafkadatasink到ClickHouse。这时候其他几个问题基本都解决了，但是之前的逻辑还是保持和业务系统表一样的表结构，下沉到目标数据库。至此，我对实时ETL有了一些体会。刚开始遇到的很多问题都解决了，但是还有一个棘手的问题需要解决：流中的一条业务数据进来之后，后面一定是全量的历史维度数据。如何实现加入？由于数据量有点大，可以考虑将维表实时写入Redis或者Hbase。遇到业务表，可以根据主键实时查询。哈哈，至此基本满足需求，接下来就是性能优化了，不过Flink还有其他的选择，比如FlinkCDC和FlinkSQL。最后给大家分享几张WebUI的截图：
