难得的清闲，却接了个2个小时的电话，朋友在一直抱怨自己的技术团队没有上进心，招聘来的技术总经理又不管落地的事，安慰了半天，又帮着看看哪位总经理写的规划，其实人家总经理做的是总体的战略规划，而且内容很详尽还有很多应对风险的预警措施，其实站在技术管理者的角度已经非常好了，可我这朋友可能在传统行业呆惯了，不太理解技术本质的含义是什么。嘴上喊着要数字化转型，等到落实的时候就不敢动弹了；批评完他，也想想自己，才面试完，人家让评论一下自己，说一下自己的优点，我就说了四个字：“果敢、认知”，一个是形容词，果断+勇敢（实际上勇敢真的是勇敢的进，勇敢的退）而认知更是我职业生涯中一直要提升的，永无止境。
Limitless.png
但是还得帮他把个技术问题解决一下，他们公司做GPS的，现在在做应用，实时传来的GPS数据越来越多，分析起来越来越麻烦，以前一直在Storm但是最近经常报错。特别是看了Log，发现Spout的消息队列过大,bolt处理不过来,产生大量堆积。其实我也没有特别好的方案，只是建议他们重新做些优化，Storm是个不错的实时数据处理框架，但随着流式计算的深入人心，加上他们业务上一些反欺诈场景的需要，我还是建议他们用Flink。关于什么是有状态，什么是无状态，请对比Http协议的解释以及幂等的概念。
Flink Vs. Storm
上面只是做个基础的概念上的对比，按照朋友家的业务场景，大概画了画
Suggested Architecture.png
逻辑特别简单，数据经过Kafka，Flink直接构建FlinkKafkaConsumerxxx（xxx是数字不知道人家用啥版本），然后Flink Redis sink把数据放在实时的Redis里面。这里提一下，Redis Geo的确很方便，https://blog.csdn.net/zhangcc233/article/details/95809006 csdn上面有篇文章介绍的很详细，代码我也跑过，没问题。只所以把Redis用上，还是因为有些电子围栏的功能需要实时报警，所以还是需要的，而且Spark在读取Redis的数据上也是很方便的：
val posSeq = Seq(Pos("120.032", "83.25"), Pos("155.11", "52.19"))
val df = spark.createDataFrame(posSeq)
df.write
.format("org.apache.spark.sql.redis")
.option("table", "geoAll")
.option("key.column", "pos")
.mode(SaveMode.Overwrite)
.save()
val sf = spark.read
.format("org.apache.spark.sql.redis")
.option("table", "geoAll")
.option("key.column", "pos")
.load()
sf.show(false)
由于场景的需要，很多车辆行驶的数据需要回溯，Redis也不太可能一直保存着所有的数据，这时候历史的数据就都进入到了HBase里面。HBase的结构决定了它更适合做历史数据，只所以没用Hive，也是因为数据结构非常简单，只是量大，不排除有些修正的工作，Hive 又不支持Update，同时动不动就得MR Job一下，所以没必要。况且Hive还是设计的比较复杂的，如下图就是既没有索引，插入延迟还高，却高可靠，可扩展性极强的Hive
Hive Work.png
当然，由于HBase，Hive都不支持事务，所以这里也不讨论事务。
HBase的结构：每张表都通过行键按照一定的范围被分割成多个子表（HRegion），默认一个HRegion超过256M就要被分割成两个，由HRegionServer管理，管理哪些HRegion由HMaster分配。HRegionServer存取一个子表时，会创建一个HRegion对象，然后对表的每个列族(Column Family)创建一个Store实例，每个Store都会有0个或多个StoreFile与之对应，每个StoreFile都会对应一个HFile， HFile就是实际的存储文件。
HFile.png
。其实做技术就是别嫌麻烦，该做的没做肯定以后会吃亏，这不就是老外说的 Technical Debt么。给朋友的建议基本就这些了，剩下的就靠他们自己实现了，这里面还有极多的细节，就比如Kafka的设置，这两天就见过有人把Kafka配崩了的，producer的ack设置成了-1，这表明kafaka要等所有的ISR中的node都确认才能发吓一跳，而且Kafka自己的Consumer是非线程安全的，而且Kafka配置的Partition不是越多越好，正常的要根据Topic做些测试才能定，我等懒人一般就把Partition设置称为Broker数量的3倍。再比如Redis自己的Failover机制，还是建议RDB来进行全面恢复，AOF的方式做部分补全，也就是常说的RDB+AOF；Spark中的大量推荐ReduceByKey的方法rather than GroupByKey来避免Shuffle等等，太多了。开发还好，再怎么说都是在做Config，用API，一进入到生产环境就千奇百怪了。
网友评论