基于Hadoop的分布式存储计算框架，我于2016年便借助51cto徐培成老师的培训接触，老实讲只学到了些皮毛，倒是借助徐老师的Java基础提升了自己对面向对象编程的理解。进入2019年，由于公司业务的需要，规划建设农业物联网平台，解决数万个传感器数据存储、查询分析的需求。从当前的数据量看，其实也并不算大，大约千万条的级别，但考虑之后的扩展性及全省推广之后的大数据量接入，决定走分布式框架。于是首选HBase+Kafka，实时计算部分由于之前已有c#的代理服务，故不作变动，计划后期修改为storm或者spark streaming。通过Hbase随机读写、高I/O的特性，记录物联网设备实时采集数据，完事转存到hive中进行离线分析。一开始这样的考虑还是很靠谱的，也行得通，技术上也都验证通过。但在hbase表结构设计上遇到问题，对于将rdbms思想深入骨髓的我们，对hbase列族、基于主键查询的概念十分不适应。导致第一版设计的时候，将设备ID作为主键，通过cell版本号（即时间戳）区分采集的数据，后来发现版本号乃是预设，非无限拓展。后阴差阳错的将cell版本数量拓展到5000，以满足一个月左右的数据存储，同时编写定时任务，每日0点定时同步至hive结构化表格。

按说第一版的这个设计也是站得住脚的，也是从传统编程模式走出来的我们，最容易理解的一种方式，直到遇到kudu，便深陷其中。

kudu这只螺旋角的羚羊，即有hbase的随机读写、高i/o的特性，又具备结构化（默认为支持impalaSQL，就当成结构化，非ACID和事务概念）的特点，同时还有多列主键等，简直完美契合我们的需求。

——未完待续

2020年6月18日补充

过去大约一年多时间，我也已经回到熟悉的岗位三个月，期间公司的物联网平台几乎与我离开时无异，只不过简化了许多之前的设计。表现在去掉了用起来很简单，但运维起来复杂的Kafka，去掉了功能强大，但实际用不太到的kudu。基本上也就是跟大数据绝缘了。到这里，物联网平台真正剩下的也就只剩下通信协议。

经过我与公司.net开发的同事商议（他负责与设备通信，转发到物联网平台），考虑到通信效率和物联网协议的特点（二进制数据流、高效率、低延迟、并发大），基于TCP协议实现物联网平台私有协议。

这个时候摆在我面前的就有很多选择，第一个就是之前用过的netty，然后就是spring全家桶里的RScoket以及jdk原生socket。经过知乎以及微信公众号上的资料查询，我觉得冒险采用vert.x开发相关的组件。考虑vert.x主要基于以下几方面考虑：第一，这个框架之前没有接触过，但具备异步特质，且性能优异；第二，较为简单易用的api，尤其是创建tcp服务及监听上；第三，具备全面的组件支持，不管是微服务还是异步编程还是jdbc等等；最后，比较容易嵌入到spring框架中使用，也可以单独使用。缺点则是国内应用的案例极少，且没有太多的资料，需要翻阅英文文档或者原生API。

未完待续—–