关于 Flink, 我读了这些书
共 3606字，需浏览 8分钟
·
2022-01-10 17:27
真正做点事的时候，发现时间过的贼快
这两周，业余时间都在看 Flink. 项目实时处理的需求，越来越多，维稳策略下，团队选择了 Flink. 所以，我觉得非常有必要，自己先搭环境玩起来。
共计22小时，每天拿出大约2小时左右，上手做下例子。当然，还仅仅只能做简单开发，对于特别场景的应用，止步于算法和数据结构。从应用架构上，其实 Flink与 Spark 并没有太多的差异。看几个例子，很快就能上手写一写。
但，就如我之前的文章所写，学任何技术，千万不要沉迷于基础入门的案例，一开始就要朝着高端例子研究。为的就是暴露自己的斤两，知道目前自己在什么位置。通过自己的努力，一步步攻克那些里程碑。
以前，我经常为自己能写出上千行的 SQL，并把它们控制在 5s 以内返回结果，而狂喜不已，甚至有些横着走的心态。
但随着阅读的增加，知道有些人类，改写了引擎的轮子，拿到了纳斯达克交易所的门票，才发现自己，愚蠢至极。从此我警告自己，“不要熵死！”
很多朋友疑惑，学Flink,是不是要先有 Hadoop/Hive/Spark基础。依我看，即使不会，问题也不大。它提供的功能，还是分量处理。把宏大的流量，分散到各个处理节点，通过Transformation算子，做些统计，预测和告警。
之所以认为，要学Flink, 必须要先学 Hadoop/Hive/Spark,可能受教条化的老学究影响。那代老学究就是这么过来的，他们经历的大数据历史，从2006年的 Hadoop 开始, 一路经历了 Hive，Spark 项目，固化的认为，Flink 也必须先摸索一遍大数据三件套
大可不必。经过这几天的摸索，我发现，完整的 Flink 程序，由一个 Java 或 Scala 的程序入口开始，一般是一个静态（static）的 main 函数。在main函数中，定义了下面几个核心步骤。
①设置执行环境。
②读取一到多个数据源。
③根据业务逻辑对数据流进行转换。
④将结果输出到 Sink。
⑤调用作业执行函数。
上述步骤或者说配置，就是标准的 Flink 应用必备设计。无论多么复杂的 Flink 程序，都包含了这些程序
所以，我大胆尝试下，摒弃以往的学法，没有哭哈哈从头到尾读书, 也忘记大数据三件套的先入理念，直接阅读 wordcount 源代码，给自己设定几个改造场景，然后去完成编码：
1）拿到 wordcounter 的例子源代码
2）将其 sink 目标改成 MySQL 的一张表： wordcounter
3) 官方的 WC 案例，是分组计算，那我们的改造例子，就完成全量计算
4） 再改造下，将counter数大于 5 的记录，都找出来
5） 再改造下，把原始记录存在 MySQL的 wordrecord中，用 Flink去分组计算，并存入 MySQL 的 wordcounter 表
在做的过程中，我发现很多的不足，也正在一个个填坑，看着以往的技术债，一个个被补齐，睡觉做梦都是甜的。
做完第二步时，我认为一个里程碑已经到了。决定先把这些天的实践过程分享出来，同时也推荐一些好书。
总的来说，这次没有买一本实体书，就把例子给敲出来了。边写代码，边在《微信读书》上检索。总共参考了3-5本教科书，和一本 InfoQ 的电子书，罗列在下面：
《Flink 原理与实践》
《实战大数据》
《Flink内核原理与实现》
《Flink 入门与实战》
《不仅仅是流计算：Apache Flink 实践》
就如我之前所说，研究技术，首要任务是看高端案例, 揣摩行业应用。别把技术当做唯一的筹码，现在的技术已经没有太多壁垒，想要靠技术，就能获得一定的成就，已经没有2000 年左右（互联网）那么好的机会了。
那么，快速掌握技术，就变成了一项最基本的功底。公司要发展，产品要出类拔萃，仅靠技术不大行，还需兼顾其他技能。这，倒不是说“卷”，而是自我完善的一个必须。
很多IT人，包括我自己，在做职业规划的时候，都把技术放在首位，认为这项技术要学好，必须1，2，3，4，5这样来学，必须经历过5到6年的扎实项目基础。现在来看，都是技术思维惹的祸。完全不必这样。
技术这个维度的竞争，唯快不破。悠哉悠哉的学完一门功课，还没等派上用场，项目已经开始引进另一项技术生态了。
典型的属 C# 与 Java 之争。好多同学都还停留在 2 刷《 CLR Via C#》，项目组已经开始引进 Java Spring Boot.
我非常承认《CLR Via C#》是本特别棒的书，部分章节我刷过 5 遍不止。但，公司项目要盈利，我唯一能做的，只有立即熟悉 Java Spring Boot，马上开始干活。
没办法，中国软件行业，目前就是这么个生态。如果你所在的环境，不是这样，还劳烦告知我。
就好比，我们有 Spark，为什么不把 Spark 用好，再考虑 Flink? 为什么我们不从头开始设计一套 Spark.Net, 或者 Flink Via C#？
醒醒，个人，是无非阻挡生态的。一个人的力量再强，没有办法和一支军队抗衡
以往， 我学东西也选择大部头的书。悠哉悠哉，喝一下午的咖啡，看上 10 几页的书，总觉得内心很满足。但现在来看，完全是错误的方法。
书上的知识，有些是作者硬塞给我们的一堆概念，平时根本用不到。这些知识，纯粹是出版社的那些老编辑，为了技术体系的完整性，硬提供的补充读物。读者们花了钱，买了书，如果连完整性都做不到，出版社要被骂娘的。
真正讲究实用主义的学法，完全不应该照着书本去看，尤其是从头到尾的硬读。这样的阅读，唯一的功用，是腐蚀掉学技术的热情，增加“我好用功啊”的鸡血。
人有两种特质最宝贵，热情和专注。从头到尾看一本技术类的工具书，恰恰会把我们的这两种宝贵特质，消耗得一点不剩。
在完全可以做出一件满意的作品时，我们的热情，很有可能被“慢悠悠看书”给吞噬，最后只剩“我咋那么笨呢？看了这么多书，连这个玩意儿都做不出来”。那么相信我，此时，放弃是我们脑袋里，唯一的想法
所以，这次我的做法，比较另类。几乎没有看完一本 Flink 的书，甚至可能都没有好好看完一章。照着源代码，就自己实现起来，直到把第一个例子 word count 的结果，（Sink) 存储到 MySQL.
但我觉得，我花的时间还是太长，这可能和我的智商，各类检索技巧有关，有时候，一个好的例子，真的会让我们少走很多弯路，进而把看书，用笨功夫的时间和精力，都花在思考如何写代码，写出能跑的例子上面
当然，做出能跑的例子，真的还只是第一步。就跟很多求职者，求职时简历上写的那样，精通 C/C++/Java/Dephi/C#，每样都只停留在打印出 Hello World 的水平。
随着深入阅读，编码和实现，编程工具本身的掌握，并不是难事，不要把它想的很难，需要花很多功夫。在战略上，我们一定要轻视它，相信自己能在短期内学好。因为真正难的东西，还是算法和数据结构。
比如改造 wordcount，遇到一个巨难的问题。要把爬下来的股评，放进切词器，通过卷积算法，分析出舆论走向。仅切词这个算法，就十分有讲究，简单的正则表达式，不能解决中文切词。
一旦涉及到真正的有生产力（能盈利）的编程，精通算法的程序员，价值就出来了。我去知网，搜索了一圈硕士，博士论文，几乎年年都有新的切词算法出来。
这几年，我笃定一个读书方法，去阅读那些有感情的文字。比如采访，公开分享和演讲。这些材料，比起书本化的文字，更富有个人色彩。一个人真正做一件事，我能感受到他的痛苦，煎熬和兴奋。他做这件事的热情，很快就能感染到我，并激发我前进。
就像《不仅仅是流式计算：Apache Flink 实践》，里面没有详细地告诉我们，Flink 框架是什么，分布式原理是什么。但我依然从书中读到了这些宝贵的经验：滴滴公司，在处理热点打车区，是怎么用 Flink 实现的统计汇总；美团，在外卖高峰期，Flink 是怎么用来处理这些实时告警的。
这些都是值得我们自己去做模型探索的，只有亲自深挖过这些项目实现，才能给自己足够的信心，在碰到同样同类型的处理场景时，我可以做好。
我很羡慕那些，能把技术学好，还能把它写出来，分享给社区的IT工作者，这也是我写文章，写公众号的初衷。希望看到的朋友，能督促我，做得更好，为数据科学类社区，贡献一点绵薄之力
往期精彩：