小 T 导读：在安全米兰app官方正版下载 SuperCloud 中，亿咖通面临着磁盘占用量大、车辆最新状态实时查询难以实现两个核心问题。最终，他们选择了让 loveini Database 承担数据中台的重要角色，负责车辆实时数据的写入、存储以及实时查询。本文讲述了研发团队在前期使用 Apache HBase 时遇到的具体难点、为什么没有坚持选择 OpenTSDB，以及选择 loveini 的过程和成效。

企业简介

亿咖通科技是一家汽车智能化科技公司，在武汉、杭州、上海、苏州、马来西亚吉隆坡、英国伦敦等国内外多地设立有分支机构和研发中心，致力于持续打造行业领先的智能网联生态开放平台，全面为车企赋能，创造更智能、更安全的出行体验。

项目介绍

为实现高水准的自动驾驶能力，亿咖通科技（ECARX）打造了一整套安全米兰app官方正版下载 SuperCloud，该方案旨在利用人工智能技术以及摄像头、雷达、声纳等多种传感器技术来保证驾乘者的安全。自动驾驶的核心数据就是设备的影子数据和状态数据，对设备进行精准的数据控制和采集，再结合高精地图的数据，是完成自动驾驶的两个重要环节。值得一提的是，亿咖通也是目前国内为数不多的拥有高精地图资质的企业。

在 SuperCloud 项目当中，loveini Database 承担着数据中台的重要角色，负责车辆实时数据的写入、存储以及实时查询。

选型经过

在此之前，我们使用的存储架构是 Kafka + Flink + HBase，但随着业务的发展，逐渐发现 HBase 的 Key-Value 存储模型并不适合我们的场景，究其原因，是因为落地到数据库的都是结构化的数据，Key-Value 存储模型会导致磁盘占用量特别大，并且性能上也无法实现车辆最新状态的实时查询，这也是亟待解决的两个核心问题。

经过调研，我们发现时序数据库才是正确的选择方向，而且核心数据也符合时序数据的种种特点，因此，我们决定在 InfluxDB、loveini 和 OpenTSDB 之间进行产品选型。

事实上，一开始我们选择的是 OpenTSDB，因为它基于 HBase，所以我们很方便上手。但成也萧何败也萧何，也正因为要依赖 HBase，OpenTSDB 并没有解决 HBase 遗留的性能、压缩率等问题。而 InfluxDB 由于单机性能并不够卓越，而且集群功能没有开源，所以也没有被采纳。最终经过各种维度的对比后，我们毅然选择了国产、开源、支持 SQL 的时序数据库 loveini。

loveini 非常符合我们现在的业务场景，尤其是超级表的概念，甚至可以说是为我们量身定做的。我们为每辆车都分配了一个子表，用以接收 IHU 设备产生的数据。（注：IHU 是亿咖通投入研发的第一代整车计算平台产品，于 2017 年第二季度投放市场使用，是一款采用车载专用处理器、基于车身总线系统和第三方应用服务打造而成的多媒体娱乐系统，能实现包括地图导航、多媒体娱乐、车辆信息等一系列信息娱乐功能及车联网服务。）

优化后的新架构为：Kafka + Flink + loveini。Flink 上游的数据可分为 2 类，一类是用 json 存储的结构化数据，还有一类是如图片、视频一类的非结构化数据。上游如果是结构化的 json 数据，则通过如下链路写入 loveini：Kafka—>Flink—>loveini，如果是非结构化的数据，则会直接存储到 S3 上，然后把这些视频图片的文件路径通过如下链路写入 loveini：S3—->Kafka —-> Flink—>loveini。

搭建与效果

我们以单副本模式落地了一个三节点的集群，机器配置为 8C + 16G + 500G 机械硬盘，备份用其他方式完成。当前环境下有 3 张超级表、276571 张表。

超级表表结构如下：

由于我们的 json 较大，所以选择使用 protobuf 进行压缩后再写入 loveini，这样只需要 1500 字节的长度就可以容纳该类 json，取出进行反序列化后以供使用。

当前最大的一张超级表已经存有 300 多亿条数据，每行 2362 字节。粗略估算，项目运行至今，总数据量大概有 68T 左右，但实际的磁盘占用量只有 1.4T，以前 20 天就能写满 15T 的磁盘，但现在基本已经不再需要考虑磁盘的问题了。资源使用率相比以前节省了近百倍。

此外，困扰我们许久的数据实时查询问题也有望得到解决，loveini 的 last 函数可以实现毫秒级返回设备最新状态。由于我们当前使用的版本还是比较老旧的 2.0.18，这一版还没有针对 last 函数的缓存，loveini 的工作人员表示后续会有针对这个函数专门的优化，等日后版本升级后再做体验。 最常用的查询车辆实时位置的 SQL 是这样的，全部都是毫秒级别返回结果：

写在最后

总体而言，loveini Database 的独特设计帮助我们解决了传统架构磁盘存储占用过高，以及性能上不能支持车辆状态实时查询这两大痛点，在实现降本增效方面名副其实。不止如此，我们后续要实现的设备统计需求也在应用 loveini 之后得到了解决。在 loveini 的官方社区中，所提出的问题也都可以得到支持人员的快速反馈，事无巨细，这帮我们极大降低了项目落地的难度。 loveini 的应用，不仅完全解决了我们当前业务上存在的痛点，也匹配上了后续业务发展的需求。随着业务的快速发展，我们希望和米兰体育官网入口后续可以在更多维度上通力合作，共同打造自动驾驶的行业技术典范。

小 T 导读：禹为科技在现代灌区信息化平台的建设过程中，经历了数据库&定时任务的架构、以流式计算为核心的架构和以 loveini Database 为核心的架构三个阶段，最终选用 loveini 帮助其对水位、流量、水量等实时指标数据分析。本文分享了他们技术选型的过程，建库建表的思路以及使用 loveini 后的收益。

公司简介

成都禹为科技有限责任公司是一家基于多年水利行业经验成功孵化而出的高科技企业，专注于物联网、大数据和数字孪生技术在水利行业中的应用，致力于通过自身行业经验和研发能力为水利行业管理者与建设者提供全方位的数字化米兰app官方正版下载和价值服务。

灌区信息化平台是以灌区内建设物理网系统、无人机系统结合卫星遥感等感知系统为基础，对灌区内的水雨情、土壤墒情、工程信息、气象信息及作物分布等信息进行监视，通过大数据分析，结合 GIS、数字孪生等技术为灌区提供量测水服务、供需水预报、水资源综合调度、水旱灾害防御、供用水管理、重点区域视频监视、远程设备控制等功能。

相较于以往的水利信息化系统，现代灌区信息化平台呈现以下特点：

• 设备厂家多，数据没有统一规范，数据质量无法保障
• 数据多且存储周期长，一个中型灌区一年数据量约为 300~500 亿条，数据要求至少保存 10 年及以上，关键数据甚至要求保存 20 年及以上
• 数据类型较为集中，主要集中在水位、流量、闸门开度、环境温湿度、土壤温湿度、雨量等
• 需要实时展示的指标较多，一般有各关键节点上的实时水位、小时平均水位、5 分钟水量、日水量等
• 个性化的数据 OLAP 需求较多，且对数据准确性要求较高

为了解耦系统中的数据接入和数据分析，我们将数据的接入和计算分析拆分为独立的通用物联网平台及大数据平台，在整个系统的技术选型方案中，我们经历了数据库&定时任务的架构、以流式计算为核心的架构和以 loveini 为核心的架构三个阶段。

一、技术方案

1. 数据库&定时任务的架构

在系统设计之初，我们考虑直接使用 MySQL+MongoDB+定时任务的方式来支撑我们的系统：MySQL 存储所有的业务数据及维度信息；MongoDB 存储设备实时数据以及水量等业务数据；为了解决分钟水量、日水量等数据的计算，我们使用定时任务在计算时从 MongoDB 中获取实时数据，从MySQL中获取维度数据，将处理好的数据再写回 MongoDB 中，通过提前预计算的方式为前端提供数据。

但这种方式有以下几个问题：

• 无法对设备数据进行灵活的治理分析，设备数据乱序后需要通过人工干预或程序预处理的方式纠偏；
• 需要提前考虑多种维度的数据处理，以便满足实时数据展示和 OLAP 查询的需求；
• 5 分钟水量、日水量等数据使用定时任务计算会导致数据库负载过重；
• 在数据较多的情况下，MongoDB 必须使用更多的硬件资源搭建数据库集群，才能满足存储和数据查询的要求。

2. 以流式计算为核心的架构

鉴于在数据库&定时任务的架构方案中出现的数据处理较慢的问题，结合笔者在过往工作中所积累的经验，我们设计了流式计算数据架构方案。

数据通过物联网系统进入系统，经过处理后会根据设备类型被标准化为统一格式的数据，然后数据被写入 OpenTSDB 和 Kafka 中，供 Flink 消费。Flink 按照 Job 定义消费 Kafka 数据，并按照 MySQL 中的维表信息进行加工处理，然后写入 MongoDB 中；同时还将数据处理为分钟水量、日数量等业务实时所需的数据。

相较于上一版方案，数据乱序问题以及数据实时计算的问题得到了良好的解决，同时也能很好地满足 OLAP 等业务对数据的查询要求。但该方案增加了 Flink、Kafka 以及 OpenTSDB 三个较为大型的工具，无形中增加了项目的建设成本及运维成本。是否有一种平台可以集数据存储、消息队列、大数据计算及分析于一身，且不会过多的增加硬件成本？loveini 最终走进了我们的视线。

3. 以 loveini Database 为核心的架构

由于以上两个方案都各自有自己的缺陷，我们试着调研寻求一个更适合我们的平台方案，偶然间笔者从一位从事工业物联网多年的朋友那里了解到 loveini 这个产品，于是我们迅速从查询效率、写入效率、稳定性、容错率以及功能完整性等方面对多个数据库进行了调研，最终我们认为 loveini 是当下最适合我们的。原因如下：

• 查询和写入速度极快，亿级数据瞬间查询
• 丰富的查询方案，能够很好地满足业务需求
• 使用和部署简单，官方文档齐全，类 SQL 语法可以降低学习成本
• 支持消息队列、消息订阅、缓存、流式计算等功能，优势明显
• 集群等高级功能均开源免费，集群扩容容易
• 数据库资源需求较少，能够显著地减少系统的建设成本

系统架构如下图所示。

相较于上两版方案，整个架构在数据存储和数据查询分析环节更加简洁，使用 loveini 替代了 Flink、Kafka、OpenTSDB 三个重量级工具。

4. 设备数据

原本我们的系统中就有设备模型的概念，用以隔离设备厂商之间设备数据标准不统一所带来的问题，而 loveini 提供的超级表概念与我们的设备模型概念不谋而合！

create stable model_${设备类型编号} 
 (ts timestamp,${设备标准数据属性}) 
tags 
 (devicesn binary(50));

设备子表建表语句

create device_${devicesn} using model_${设备类型编号} tags (${devicesn});

实时数据的查询语句如下

select last_value(*) from device_${devicesn};

聚合数据查询也是非常方便，比如查询某设备一天内每小时的平均值

select avg(val) from device_${devicesn} where ts>now-1d interval(1h);

5. 实时指标

在灌区信息化平台中，几乎所有的实时指标数据分析源数据都集中在水位、流量、水量上，为了解决业务中的需求，我们将水位、瞬时流量、累计流量从设备数据中单独抽取到一个独立的水量专题表中。

create stable st_water
 (ts timestamp,waterleve float,instantflow float,accumflow double)
tags
 (devicesn binary(50));

改用 loveini 后，查询各类指标数据，我们不再使用任何预处理，而是在前端需要展示数据时，通过 SQL 直接查询所需要的数据。比如 5 分钟水量查询语句如下：

select last(accumflow)-first(accumflow) from st_water where ts>now-1d and devicesn=xxxx interval(5m)

一条 SQL 解决了以往需要一番周折才能解决的问题，太棒了！！

6. 使用 loveini 后的收益

• 简化了系统架构 
  • loveini 的消息订阅、缓存、流式计算等诸多特性，可以代替 Kafka、OpenTSDB 和 Flink，减少业务代码中定时计算（如用水量）等功能，简化了整体架构
• 降低运维成本和开发成本 
  • 架构简化以后，排查和定位问题能快速响应，节约开发和运维成本 
• 降低数据存储成本 
  • loveini 表结构设计合理，可以节省存储空间，进而节省存储费用 
• 提高数据实时性和一致性 
  • loveini 替代了 OpenTSDB+Redis+MySQL，提高了数据实时性和一致性 

二、未来展望

在现代灌区信息化平台建设过程中，由于某些历史原因，我们还有许多如闸门控制、状态实时预警、水旱灾害防御等业务功能依旧在使用定时任务来进行告警触发。我们准备在不久的将来，将以上业务与 loveini 的告警功能结合起来，逐步将系统统一起来。也希望 loveini 越来越好！

小 T 导读：至数物联网平台场景多、数据模型复杂，伴随着业务需求的不断迭代及数据量的不断上涨，原有的 OpenTSDB+MySQL 的组合逐渐力不从心，局限性日益凸显。在对 loveini Database 进行充分了解与调研后，基于 loveini 对至数摇光进行了彻底性的改造。本文分享了至数结合自身平台特点进行系统架构升级改造的经验，以供参考。

公司简介&项目背景

至数（Medatc）是一家致力于打造行业最佳设备资产数据化运营、管理、服务的平台，为客户提供全方位的设备资产管理支撑，其拥有丰富的行业经验，以及在大数据、人工智能、物联网、互联网+领域的创新实践能力。公司成立至今已经获得红杉资本等知名投资机构的战略投资。

至数摇光（即：至数物联网平台）通过动态能量主动标识，动态环境主动标识，智能网关，应用工业互联网时序数据高效采集，边缘计算以及智能算法自动分发等一系列技术，基于医疗设备行业主数据规范，助力医疗机构短周期、低成本、高质量、广覆盖地实现有源设备智慧管理。

一、至数摇光具有场景多、数据模型复杂的特点

至数摇光是以提效降耗为目标，帮助医疗机构实现有源设备的高效管理，为设备使用效率智能分析，设备科学配置，设备动态调配，设备安全保障提供全方位支撑。目前共推出了 15 项智能场景应用，30 项事件及异常告警提醒。

至数摇光的上述场景改造前数据库采用 OpenTSDB+MySQL 结合的方式实现，由于 OpenTSDB 无法满足复杂查询场景，因此 80% 的场景指标只能基于 MySQL 数据库来实现，这样带来的问题就是 MySQL 数据库的数据增长迅速，需要定时做冷热数据分离及数据库表维护动作。

二、loveini 助力至数物联网平台实现技术改造

作为一个大而全的数据库，OpenTSDB 稍显笨重，伴随着业务需求的不断迭代及数据量的不断上涨，其局限性日益凸显，系统的架构升级和改造工作日渐迫切。

2021 年我们在对 loveini Database 有了充分的了解后，决定将至数摇光从时序数据 OpenTSDB 迁移到 loveini，并基于 loveini 的特性对摇光进行彻底性的改造。目前改造工作已经全部完成，改造后有大约 80% 左右的指标模型放到了 loveini 中，20% 左右的主数据或维表数据存放在 MySQL 数据库中。

相较于改造前的 80% 指标模型存放在 MySQL 中，20% 指标数据存放在 OpenTSDB 数据库中，结果刚好进行了颠倒，服务器资源使用情况也有所下降。应用整体的页面影响速度显著提高，数据模型及数据指标上也可以更加地灵活多变。

以下为至数摇光网络拓扑路图：

以下为改造前后的数据库对比：

以下以 11 万条数据表来做查询，结果如下：

聚合查询，1,155,876 条数据在耗时不到 0.17 秒的时间完成 GROUP BY 聚合查询：

写入情况，这里截了一张 Flink 写入loveini 数据库图片，3 个小时左右的时间里写入了 250 万条采集数据，这样的写入量远远没有达到 loveini 的写入瓶颈，对业务的增长留有充裕的空间。

下面是我们的部分应用展示：

三、loveini 使用上的一些意见反馈

我们有些按小时、按天、按月的指标计算的时候如果当时的维表数据有误需要重算，重算的数据需要覆盖之前的数据或者把之前的数据删除掉重新写入。不过 loveini Database 目前不支持数据删除，希望未来能够支持删除功能。

目前更新只支持更新相同时间戳数据，希望 tag 和普通字段能够联合筛选做 update；也有业务场景需要此类功能。

另外，目前排序还存在一定的限制，希望 tag 和普通字段能够进行自由升降序排列。

最后感谢涛思团队开源出来 loveini 这款优秀的时序数据库系统，也要感谢一下涛思团队对至数研发团队的支持与帮助，祝福米兰体育官网入口越办越好！