博客断更了好久了，今天提笔分享一下将<code>Apache IoTDB</code>真正应用到生产环境当中的故事。如果你也正在研究或对相关技术感兴趣，欢迎一起讨论学习，联系方式见文章末尾。
四维智联是一家车联网服务提供商，主要就是传统Tsp、智能座舱、自动驾驶、导航等等，是
在<code>2020年3月</code>的时候，公司开展了针对一家大型车厂的用户驾驶行为数据分析的项目。因为篇幅的关系，后面会省略很多细节，有兴趣可以联系我或者以后有时间再单独写这块。
驾驶行为通常意义上是三急一超，即：急加速、急减速、急刹车、超速。我们在这个基础上完善了更多维的一个评价体系，如变道、操作舒适度、拥堵等等。将车主尽可能多的操作进行一个量化，得到一个分数值，基于分数再推荐用户进行更良好的操作行为建议。
1. 整体架构
抽象来看，数据有三个归属地：
<code>这里值得注意的一点是：无论哪一方，其实整体的服务器及数据都是在车厂内网及DC中的，只是逻辑隔离。</code>
是车厂数据中心，既数据的所有方，他为了保证车主数据的安全会采用<code>项目数据申请制</code>来发布数据。举例来讲：假如车相关数据总共有10项，如果<code>项目1</code>只用到了其中的3项(x,y,z)，那么车厂会把车中(x,y,z)这三项写到一个文件中同步发给<code>项目1</code>，这样做的目的尽可能的保证了<code>数据的隐私与安全</code>。
是数据计算方，数据使用Kafka的方式将数据中心加工好的数据同步过来，形式是<code>每车/每分钟</code>1个文件。数据在接收之后会按照业务的设计，进行数据分析及加工，加工完成后的结果数据会发送给下游的<code>数据使用方</code>。
数据使用方是依赖于分析完成的原子数据进行多样化展示给客户的一个项目方。这个就好比中国的路都是一样的，但是高德、百度、四维做出来的导航就是不一样的，那高德、百度，就相当于是数据的使用方。
2.数据接入
我们使用了<code>6台 * 4核16G</code>的Kafka机器作为支撑。
原始的<code>每车/每分</code>文件大小大概是<code>0.25M</code>左右
可以看到生产侧最大每秒产生<code>5230</code>个文件，也就是峰值<code>1.2G/s</code>的一个入数据速度，PS：如果是购买的公网带宽大家可以算一下成本。
根据平均值可以测算出，原始数据每天产生的数据量大概是：<code>758/s</code> * <code>3600</code> * <code>24</code> = <code>15.6T/天</code>。
当然这个截图时间比较久远了，我特意去线上看了一下最新的数据：每天产生的数据量大概是：<code>1.46K/s</code> * <code>3600</code> * <code>24</code> = <code>20.6T/天</code>。有兴趣的可以自己测算一下存储多副本、长时间总成本有多高。
3.数据处理
文件接收到之后，使用<code>Flink</code>进行原始文件解析、数据清洗、原始数据入库的工作，最开始选用<code>Hbase</code>作为原始数据存储的数据库。
数据入库完成之后在一定的时间里开始使用<code>spark</code>读取出来原始数据，开始进行业务的算法计算。
所以整体看来千斤重担就在<code>Hbase</code>上，他既要接受不断入数据的洗礼，又要接收来自<code>Spark</code>的读取。至少给我的感觉<code>hbase</code>对于我们这种小中型的公司是不适合的，一方面是维护成本奇高，要组织更专业的人来排查线上哪里出现了瓶颈，以及瓶颈怎么解决；还要经常性的巡视节点状况，随时出现了问题都要找很久。二是机器成本奇高，可能瓶颈就是我们机器节点太少了并且有一些资源混用，但是不可能无限制增加机器。
接下来介绍一下基本情况：
<code>Hbase</code>作为基础数据库在线上跑了大概一年时间，资源上使用了<code>20台 * 8核11G </code>的机器，数据基于<code>S3</code>，<code>WAL</code>日志基于固态磁盘，磁盘的<code>iops</code>调整到了<code>6000</code>，低峰时候凑凑合合支撑，高峰时候数据写入延迟严重，经常<code>ReginServer Error</code>，<code>拒绝写入</code>等等，而且采购的云厂商也不能给予很及时的技术支持，如果要这部分支持就必须花费更高的价格来购买高级服务。
这块的费用成本大概是：
上图是线上的服务监控，绿色代表消费速度，红色代表生产速度。可以明显看到，绿线一直是连续的，也就是还没有消费完一批数据，下一波数据就又来了。
综上，从成本、性能、易维护这三个方面我们必须要做出选择。
时序数据 & Apache IoTDB
在遇到这个入库问题之后我就在考虑，除了<code>Hbase</code>我们还有什么可以选择的吗？有没有运维更简单一些不用各种依赖的？
所以回归数据的本质来思考问题，数据特性到底是什么？我们到底需求是什么？
首先最原始的数据是按时间顺序产生的，他们有固定的周期，这本质上就是属于时序数据。数据在到达数据中心后，会产生乱序、丢帧或者其他问题，所以在这里我们需要清理、规整一次数据，做好数据质量，并且把乱序的数据排好序。
所以当时想莫不如自己做一个中间件完成排序和查询的功能，后来就开始调研相关的存储技术，机缘巧合下发现了<code>IoTDB</code>。当然也顺便学习了<code>TsFile、存储引擎、查询引擎</code>，经过一段时间的磨合时机成熟，准备上线。
当然上线的过程也不是一帆风顺的，毕竟车联网有一定的行业特点，但是经过<code>我们团队</code>和<code>IoTDB团队</code>共同的努力之下最终完成上线。这里细节的问题以及发现问题的过程就不在这篇文章中具体描述，有兴趣的可以加我好友或者后面文章继续写，这里列一下当时大的改进点：
支持设备模板，极大的节省了 IoTDB对内存的使用量。
重写了内存管理功能，使得运行过程中的性能更为稳定，功能更健壮。
增加了字符串池，减少了TsFileResource对于内存的占用。
重新设计了分布式下的连接管理，让运行更稳定。
还有一些bug fix。。。
以上这些<code>特性及bug fix</code>都包含在已经发布的<code>0.12.2</code>版本中，我已经替大家趟过坑，请放心使用。
最后说一下 <code>IoTDB & Hbase</code>对比：
机器资源
2021年
<col>
服务
类型
配置
数量
hadoop
机器
8vcpu, 32GiB mem
20
磁盘
机械
3
固态
(2T * 14) + (100G * 10)
IoTDB
8vcpu, 64GiB mem
500G * 6
2025年（测算）
41
(2T * 72) + (100G * 22)
11
500G * 11
性能监控
Hbase
消费速度几乎快了1倍，money减少了3-4倍，逢年过节再也见不到报警了。
写在最后
整个IoTDB的上线工作大约是在8月份完成，当时兴致勃勃想写篇文章分享整个过程，但是想想还是等线上稳定一段时间再写吧。
因为没有经过<code>10月1国庆节</code>洗礼的车联网技术，就像是没有经过双十一的电子商城是一样的。
整个架构跑到现在非常稳定，终于可以对外发布了。如果你也是车联网从业者、时序数据库爱好者、车厂从业人员，都欢迎添加好友一起学习交流。
祝玩儿的开心。
欢迎关注微信公众号：Apache IoTDB 在四维智联公司的应用