工业大数据平台开发的亲身经历

背景

工业仪表仪器制造业转型，物联网起步。公司这边没有一开始就上什么分布式、大数据，估计是这个转型的阶段硬件业务都不稳定，更别说辅助的软件了。所以招人的时候就招了我一个一年经验的，对分布式和大数据这些都没接触过。

第一阶段 数据收集

硬件通过物联网技术上传数据到服务器，信息化系统做数据收集、展示。

后台用SSM框架搭建RESTful接口工程，提供增删改查功能接口，数据库用的mysql（起步阶段，硬件方面还属于未成形阶段，几乎没多少设备接入，数据量少），PC前端（JSP+AJAX+BootStrap），移动端（H5实现，包括微信公众号和企业微信等），这些难度都不高，毕业一年带了一个实习生就整完了，相对来说前端会麻烦点，毕竟前端是业余，H5这块网上找个UI框架做起来还是快，慢的在于微信接入，之前没做过，调研+服务器准备+域名准备+备案花了不少时间。

最重要的是物联网模块，设备上传的数据如何接收？这一块是我入职前就已经写好了，用的公司成形的技术（C#），因为之前没有JAVAWEB这块，都是C#做的PC程序，也就是“上位机”，这玩意是和微软挂钩的，所以服务器用的就是windows服务器，刚开始去的时候还有点不适应。

应该有不少公司会经历这个阶段吧？很多实力不够的公司估计这部分就找外包做了，毕竟靠谱的外包可以直接提供一整套大数据服务，自己搞嘛还是很有可能整不出来的。

第二阶段 业务接入

上一阶段基本能实现硬件数据上传，信息化提供查询与展示，当然因为是起步阶段，性能存储这些都是没考虑的，平台用户几乎都是公司内部的，以及少数客户领导关注了公众号，访问并发几乎为零，也就物联网这块有几台β测试机器连着。

这时候，第一批设备进入试生产，大概有个十几台设备出去了，这时候领导希望把一些流程业务移到信息化平台上来，比如仪表的运维工作，人员管理等，到这一阶段一个信息化平台就相对完整了。

相关技术：后台Activiti做流程管理，前端Echarts做各种图表展示。

第三阶段 存储优化

之后在一段时间内都在负责别的项目，平台这块就没管了，直到有一天发现有个页面响应特别慢，大概4S左右才能响应，于是开始查问题，最后发现是后台SQL查询十分慢，一看这个业务相关的表，惊了！！！！居然有500万+条记录，再加上自己写的sql也有问题，表设计也有问题，导致这张大表不仅需要join很多张表还要子查询才能查出我需要的数据（个人编程习惯，也不知道是好是坏，习惯一个SQL能查出来的绝不分开查），因此查询效率很低。

那为什么突然就这么多数据了呢？因为设备上传的数据有很多类型，其中有一种属于高频类数据，上传周期大概为1分钟左右，一台设备一天单凭此类型数据就1500条记录左右，几十台表一天大概6、7万条数据。

现在才是起步阶段，存储查询性能就已经遇到问题了，立马着手调研，最后决定采取分表分库来暂时解决此问题。

业务分库：物联网数据和业务数据分开。
分表策略：按日期分表，根据数据量计算，按几年内的业务发展速度推算可能接入的设备数，估算多久单表数据量会涨到千万级别（理论上说，单表数据量有个500万左右，就需要考虑分表，但是我们相关业务是可以牺牲效率的，且这些表也只涉及小部分业务。），最后定板分表时间区间为周，即每周数据存储到当周的表。

**经过分库分表后，可以控制单表数据量不会无限增加，且在一定范围内。**分库分区后，查询效率也快了不少，关于ShardingJDBC可以看我的另一篇文章。

相关技术栈：SSM + ShardingJDBC+多数据源。

第四阶段 可持续发展Hadoop

经过上阶段，平台在短时间内存储和查询都不太会有问题，但是面对后面大数据分析，大量设备接入还存在很多问题，例如：

1.后期大数据量的分析计算是否还是需要内存数据库来实现？
2.后期设备持续增加，单周数据量远超mysql单表容量怎么办？难道再细分分表区间吗？分到一天一张表？？，这样无疑会导致数据碎片化严重。
3.物联网模块是否需要重构，目前的架构可能只能支持几百台设备并发上传数据，后期如何扩展？

最后，Hadoop，就是它，我希望以Hadoop生态圈来改进平台，后面我会持续分享学习Hadoop的过程，希望能有大佬多多指导。