-----------更新说明----------
突然就想水一篇博客，刚好说明一下这段时间基本没有更新的问题。
简单介绍下我的职业生涯，大家有留意的话，可以在博客园上看到，我的博客是从2015年11月开始的，公众号则是去年才有的。
我15年毕业，就职某外企Java开发，17年进入某曾经很知名的公司做大数据离线（抬高一点，还负责离线报表的前后端/数据库/接口等），18年底以外包的身份进入某互联网大厂，专职做实时数据开发，也就是在这段时间，我了解Flink，并决定之后的职业生涯中，专注于Flink 开发。这段时间换了个新公司，做大数据开发，实时离线都有的。（不得不说，外包绝对是我职业生涯中最大的污点）
所以，这段时间更新断了的原因就是，换了个工作，没时间写。之前的博客很多都是自己开发的时候，遇到个值得一写的内容，然后蕴酿一下，抽点时间摸个鱼就水了一篇。刚到新的岗位，还很多不懂的内容，加上比较忙，基本没有酝酿博客内容，所以也就没得写了（太懒了）。
下面是一些扯淡的内容
大概是19年初开始接触Flink，那时候项目有些拓展的思路，随后我调研并编写了HDP的安装简介，搭建了Flink的开发测试环境，从此开始学习Flink。其实我比较愚笨，虽然经常会在群里扯淡，但是从来不敢说自己是大佬，就目前来说，我只是比新人多看了几遍官网的文档，多写了几个Demo。
我对Flink 特别有信心，甚至经常对朋友说：“如果那天不能做Flink 开发了，就回去种地”。😄😄😄
基本上所有业余时间的学习内容，都是Flink和相关的东西，今后主要也是做这个方面的工作，工作稳定之后，博客还是要继续写的，开源项目sqlSubmit 也会继续更新，这也是学习总结的过程。
祝大家端午节安康
-------------------------
最近有个失败的经历，有个处理批处理的工作，需要对全量的历史数据进行处理，用Spark做的。我觉得用Flink 的 Batch也能做这个事情，就用Flink Batch也做了个版本的，结果当然是失败了。
需求如下：
对用户生命周期的全量数据进行处理，按用户和指定维度输出用户不同时期的特征数据，用作过滤模型的基础数据
全量数据在10T左右，存在30个HBase 表中（测试环境 2.6T，7个表），需要按一定的规则读取，然后对每个用户的数据进行排序/合并/计算/输出。
拿到需求的时候，Spark的同学，以用户做分区，依次分别计算所有用户的数据（分别是指，一次只算一个用户的数据，算完了，再算下一个用户的数据，当然Spark是分布式的，所以任务也是并行的）。
我是觉得这个方案有很大的缺陷，我们有几百万的用户数据，那就需要访问HBase几百万次，再加上30个分表，就读取数据，就会花很多时间了。
所以我用Flink Batch 开发了个版本，直接load所有表的数据上来，然后用用户号分区计算用户数据。这样就只需要访问HBase 30次，一次拿全部数据，然后再计算，至少在访问HBase 这一项上，已经节省了很多时间。
程序开发完，在测试环境跑的时候，就失败了，没有计算出结果（当然不是算不出来，而是我觉得时间太长，完全不能接受）。
遇到的问题：
1. 全量数据太多，读取太慢。测试环境2.6T的数据，我从来没有全部读取上来过，优化过后的程序，跑得最好的一次，一小时读取了100G的数据，就这样也需要至少26小时才能把全部数据读取上来。放弃
2. Flink Batch 的时候，经常遇到没见过的问题（之前都是Stream 的任务），很常见的就是 akk timeout，可能还是数据太多，导致任务异常。
3. taskmanager经常被kill掉，没有 OOM 日志，完全不知道原因
经过一周多的调试运行，最后还是放弃了这个版本，在流程上优化了方案，用Stream实现了一版，测试的效果看起来还不错。
放弃的主要原因：
1. HBase读取数据太慢了
2. Flink Batch 处理问题不少，甚至我怀疑，全部数据顺利读取上来，后面做分组/排序合并也会出问题（又没有那个美国时间去慢慢处理）
3. 还有就是Spark的同学早就开发完了，并且在线上开始跑全量数据了，虽然很慢（最后应该是耗时100小时才跑完，吐血）
事实上，我觉得一个任务需要超过10小时才能计算完成，就是一个完全不能接受的事情（可能是因为我一直做实时，数据基本在分钟级内完成，Flink的都是秒级的。好像之前项目中也有一次，需要对全量数据做处理，用 Spark 一次加载所有数据上来，但是失败了，跑不起来，所以选择按用户分区，一个一个计算的方式）。
之前有过一次需要计算全量数据的经历，那次还是从备份服务器上拉取的压缩格式的历史数据，也有几个T大小，用Hive也只花了2天的时间（当然这个数据是从本地解压，直接上传到HDFS上，不需要从HBase读）。
这个任务当然还有很大的优化空间，比如直接去读HFile，或者提前把数据从HBase读上来，放到HDFS（下次应该会这么做了），用MapReduce 也不可能花超过10小时（我觉得啊）。
说下Stream版本的任务
Stream 版本的任务开发就比较简单了，主要用Stream 的方式获取数据，处理代码直接从之前的copy过来，改吧改吧。这个需求可以用Stream来做，主要是计算一个用户的数据的时候，只需要他自己的数据，还有就是HBase的主键也是以用户号+时间，所以可以一次读取一个用户的全部数据，处理完成后，再读下一个人的（Spark版本基本也是这样）。
Stream 版本从Kafka 读取 用户号，分区，process 中直接去读取 HBase 中的数据，处理完后，输出结果。
用Kafka 做source，而不是自定义一个Source，还是Kafka 比较熟，方便好用
keyBy是为了分区，也为了分区负载均衡，方便提高并行度，直接用用户号 hash
process 就是主要的处理逻辑了
open 中直接 创建了 所有 HTable，process 中直接用
process 中 ，构造scan 的 startRow/endRow，直接 循环所有 HTable，依次读取当前用户的全部数据，处理完成后输出，再来下一个用户。
优化的 Stream 版本，在测试环境，最快1小时就处理了全部的用户数据（我做的版本只处理了一个类型的用户，占总数的30%，这种方式处理，也不需要读取全部数据，只需要30%的数据）
比较遗憾的是，Stream 版本没有在生产环境跑过一次全量的数据，只是以比较小的并行度跑了一段时间，看了下效率。
跑了的几百个用户数据中，最大的一个，从HBase 读取了 488W 条数据，数据读取时间 52 s，处理时间：15 s
从效率上来看和Spark的差不多，都是用的HBase API 读数据，所以读取时间没什么差别，处理上，过程和结果都是一样的，只是我是自己写的处理流程，Spark则借助了框架，开发简单一点，但是效率略低，不过差别不大，毕竟处理时间就那么几秒。
-----------------------
半夜醒来，水一篇，现在7点，回老家的我，已经吃完了早饭了，回去睡觉😪了
特意背了电脑回来，希望这两天还有思路
祝好
欢迎关注Flink菜鸟公众号，会不定期更新Flink（开发技术）相关的推文
