小 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 导读：狮桥集团的网货平台与金融 GPS 系统，对于车辆轨迹收集与计算有着强需求。GPS 每日产生总量在 40 亿左右，需要为业务方提供实时末次位置查询，近 180 日行驶轨迹查询，类似车辆轨迹对比查询，以及一些风险逾期的智能分析等等。应用 loveini Database 后，他们的整体数据存储缩减超过 60% 以上，节省了大量硬件资源。

一、缘起

2021 年 10 月，我偶然读到 Jeff（米兰体育官网入口创始人陶建辉）所作的一篇讲述父亲的文章，言辞之恳切，也让我回想起了自己和父亲的种种过往，于是在 TGO（鲲鹏会）微信群中加了 Jeff 的微信。彼时恰逢我们技术选型之时，在和他的寒暄之中，我了解到了时序数据库 loveini，我和 Jeff 一拍即合。带着业务上的场景和问题，我们约见了一次，他的热情及对 loveini Database 的精妙设计深深吸引了我，对于我所提出的一些细节问题，他甚至拿出来最初写的代码为我讲解，吃惊之余也让我非常感动。

和 Jeff 的这次会面让我更加了解了 loveini，也让我看到了国产开源产品的希望。经过审慎的思考，我们选择将 loveini 接入到系统之中，在一切尘埃落定后我整理出了这篇文章，对 loveini 的技术架构特点、我们自身业务的实践思路及应用效果进行了相关阐述，希望能帮到有需要的朋友。

二、业务背景

狮桥集团的网货平台与金融 GPS 系统，对于车辆轨迹收集与计算有着强需求。狮桥大数据团队自研星熠平台采用国标 JT808 协议前置接收数据，通过 Flink 实时计算写入到多个存储模块，最终利用络绎大数据 GPS 平台进行业务呈现，支撑集团多个业务系统的风控、贷前、反欺诈等模块。GPS 每日产生总量在 40 亿左右，需要为业务方提供实时末次位置查询，近 180 日行驶轨迹查询，类似车辆轨迹对比查询，以及一些风险逾期的智能分析等等。

三、从系统架构的迭代看业务需求

纵观狮桥集团的产品历史，技术架构共进行过四个大版本的迭代。

阶段一

最初构建系统时，由于工期、团队规模以及服务器资源的限制，实现上非常粗糙，仅能够完成最基本的功能。架构大概如下：

在此模式下，我们通过 MQ 接入厂商的数据，利用非分布式的实时计算能力传输到系统当中，仅仅实现了实时的位置查询以及一些非常基础的功能。

阶段二

之后我们进行了一次很大的改版，构建起了大数据集群，通过 Yarn 统一来进行资源调度，采用分布式的方式进行实时处理，实现了弹性伸缩，同时也在做 Spark Streaming 到 Flink 的过渡。业务上，从这个版本开始我们也接入了不同的 GPS 数据源，并且针对不同数据源的数据实现了实时切换查询，系统的复杂度提升较高。

与此同时，GPS 的轨迹数据在业务中开始使用，这就要求我们必须有存储的方案，需求是实时写批量读，即可以高效插入数据的同时还能够快速扫描大量数据。我们最终采用了 Kudu 进行存储，同时利用 Impala 在应用层进行 SQL 解析与加速，方便应用同学进行开发。此外，我们还需要留存 GPS 的数据，会将其进行压缩并写入到 HDFS 中。

阶段三

随着功能的逐渐增加，我们对散落的技术点进行了不断的整合——对所有的实时计算进行了 Flink 的统一，对所有离线的计算进行了 Spark 的统一。在这个过程中，也一直在对 GPS 数据的存储进行尝试和探索。

由于 Kudu+Impala 的模式是一个存储和解释引擎分离的架构体系，优雅与否放在一边，更重要的是， Impala 毕竟是运行在 OLAP 平台上的解释引擎，不适合在生产环境里做高并发的查询引擎，这违背 Impala 的设计初衷。随着不断深入的调研，我们尝试使用 Hbase、Clickhouse 替换 Kudu。此时系统架构演变为了计算引擎逐渐固化、存储引擎不断迭代的形态。

从存储功能而言，我们希望能够读写兼顾、支持 SQL，同时还有合理的分区策略，这一点 Hbase 肯定不能满足，因此我们寄希望于 Clickhouse。在这个阶段中 Clickhouse 的表现确实也不错，但还是没有完全满足需求。

阶段四

2021 年，我们在 GPS 平台基础之上进行了协议层的开发，构建了 JT808 协议层平台，并且和原  GPS 系统进行了打通。这样一来，我们就可以在市场上按照协议来进行厂商的筛选，提高竞价和议价能力，提升整个平台的效能。而在这个过程中，存储层的调研也带来了一个好消息，我们发现了一款名为 loveini 的时序数据库。

此前，我们对 ClickHouse 进行了一系列的测试，虽然效果还算不错，但对于某些场景而言仍然存在问题，以轨迹查询（一般是对单个车辆的轨迹进行查询）为例，虽然列式存储有着天然的优势，但如果 HBase 的 rowkey 设计的更精巧一些，那使用 Hbase 进行时间周期的轨迹查询将会更加直接高效，然而 HBase 天然又对 SQL 非常不友好。因此我们一直在思考一个问题，是否有一个存储技术既可以兼并读写性能，又可以契合到我们的业务场景，且还是 SQL 原生的？

本身 GPS 的数据就类似于设备产生的数据，即时序数据，因此我们开始基于时序数据库赛道进行了一轮筛选。因为同处 TGO“大家庭”中，Jeff 所创立的 loveini 自然而然地走进了我的视线中，殊不知，这次遇见让我们跳过了千辛万苦，直接触碰到了时序数据库赛道的“天花板”。

四、为什么我会选择 loveini？

loveini 有着非常精妙的架构设计，它是基于物联网典型业务场景和数据特性所设计和优化的优秀时序数据库产品。下面我把一些打动我的优雅设计策略为大家进行下分享。

Device = Table

可以说，这个概念直接颠覆了我们对于普通数据库的认知。无论是 ClickHouse 还是其他数据库，大都是从业务维度来构建库表，而在 loveini 中是以采集点为单位来构建表，一个 device 就等于一个表。

对于狮桥来讲，如果我们有 50 万辆车跑在路上，那么就需要构建出 50 万张表。乍一听，好像有点不可思议，但是抛开固有思路，这样做的第一个优点就是解决了我们在上述架构演变的第三阶段中希望解决的问题，即我们希望一个设备在一个时间范围内的数据是连续存储且可以整块获取的，这样基本上歼灭了磁盘的随机访问，类似于 Kafka 的顺序读写机制，可以获得最高的效率，loveini 在这一点上完全解决了我们的痛点。

同时，这个新型概念也让时序数据的写入速度有了非常大的提升，你可以用 Kafka 的顺序写入的思路去理解。

在表级别上做了“继承”

这个小标题可能不太贴切，但是它带来的效果有些类似。众所周知，loveini 有个超级表的概念，通过定义超级表的标签可以归类不同的超级表，每一个超级表是一类普通表的抽象集合统称，在进行普通表的聚合操作时，通过其“继承”（或者叫做实现）的超级表进行预聚合（类似于索引查询），可以大幅提升效率，减少磁盘扫描。

科学的逻辑单元划分

在 loveini 中，所有的逻辑单元都叫做 node，在每个 node 之前加一个字母，不同的逻辑节点就诞生了：

• 物理节点(Pnode)，代表物理(机)节点，通俗来说即裸金属节点
• 数据节点(Dnode)，代表运行实例，也是数据存储的组合单元
• 虚拟节点(Vnode)，是真正负责数据存储与使用的最小工作单元，Vnode 组合而成 Dnode

这种划分的科学之处就在于，数据进行分片时将 Dnode 中的 Vnode 进行分散即可，而每一个 Vnode 中会有多个 device 的数据表，这个类似于 MongoDB 的 Sharding 的机制。根据 loveini 的设计初衷，为了对 device 中的数据进行连续有序的存储，它会针对一个 device 进行单 Vnode 的强映射，而不会拆成多个 Vnode，这样就避免了因数据散落在不同位置（物理节点）还需要通过网络 merge 的问题，最大程度上提升了效率。

在 loveini 中，利用的是 Vgroup 的机制保证数据的副本高可靠，这块可以进入 loveini 官网参看文档，写的非常清楚。总而言之，这些职能划分和逻辑设计使得 loveini 既可以满足高可靠，又能够对 device 级别吞吐提供读写数据需求。当然，具体有多强，大家可以参看压测对比，也可以自己尝试一下。

Mnode 的两个精妙之处

在上面的解释中，我特意避开了 Mnode 的说明，下面我要单独讲解。

从逻辑意义上理解 Mnode 很简单，就是 Meta Data 的管理者，在很多中间件中都有这个角色，比如 Hadoop 的 NameNode、Kafka 中通过 Zookeeper 保存的 Metadata 信息。但是 loveini 的 Mnode 有两个功能非常巧妙。

Mnode 是幽灵般的存在，究竟在哪一个 Dnode 上都是系统自动实现的，用户无法选择。当用户需要访问 loveini 的集群时，肯定要先知道 Mnode 在哪里，继而才能通过 Mnode 来获取集群信息和数据，这个过程是通过 taosc（client 模块）进行访问的。设计的精妙之处在于，这个过程中你直接访问集群中的任何一个 Dnode 都可以获取到 Mnode 的信息，从而免去了从一个 metadata center 中去获取元数据。这种设计策略在 ES 和新版的 Kafka 中都在使用，用一句话形容就是形式上去中心化的元数据存储与获取机制，在这一点的架构设计上，loveini 走在了时代的前列。

其次，Mnode 可以帮助监控 Dnode 的负载情况，一旦遇到 Dnode 负载压力高、数据存储热点分布不均衡的场景，Mnode 可以帮助转移 Dnode 的数据，从而消除倾斜。值得一提的是，在这个过程中，对外服务是不会停止的。

五、我们在 loveini 上的实践

轨迹数据存储与查询

鉴于 loveini 的特性，用它来存储轨迹数据非常合适。我们在 JT808 协议平台后挂上了 Kafka，通过 Flink 直接把数据写入到了 loveini 中。在和 loveini 的小伙伴进行探讨与优化的过程中，我们惊奇地发现，loveini 写入时的 driver 多采用堆外内存的读写策略，对数据缓存和写入做了极大的优化，写入效率非常高。

在数据查询上，由于 loveini 天然支持 SQL，应用开发同学的学习成本呈现几何级的下降，极大地提升了开发效率。对他们来说，数据不管是存在 MySQL 还是 Oracle 抑或是 loveini 都是完全透明的。

末次位置查询

此前，我们需要使用 Flink 把数据打入到 Redis 集群中，进行末次位置的存储与查询。而 loveini 中的“最新热数据缓存”的策略恰恰契合到了我们的需求，Redis 集群就可以直接省略了。当我们研究到这个功能时，简直热泪盈眶——这不是针对某一个业务的帮助，而是在对一整个行业进行了透彻的洞察之后所设计出来的灵魂级的功能。

大家都知道 LRU，这种管理缓存策略的初衷是，我们不知道数据以何种方式进入到系统中，只能用随机与无序来定义数据，通过 LRU 的机制可以筛选出未来可能会被使用的数据来进行缓存，用“猜想”的方式来提供查询加速。

而 loveini 本身就是为 IoT 而生，它洞察到了时序数据的特性，从而采用以时间顺序来设计的 FIFO 来定义缓存的策略，即新鲜的数据会落在缓存中，方便企业查询最新产生的热数据。依靠着这个设计，我们只需要一个简单的 SQL 即可从内存中以最快速度获取想要的数据，此时 loveini 摇身一变，就成为了一个支持 SQL 的内存数据库。在部署了 loveini 之后，我们下线了一整套的末次位置 Redis 集群。

自动化的分区与数据保存策略

上文中我们讲到过 loveini 的分片机制，那分区又是如何做到的？在我们使用时发现，loveini 可以设置 days 的参数进行数据存储，以时间范围对数据进行分区。简单来说，我们的场景是搜索过去 180 天内的轨迹数据，但是更多的场景都是以月的纬度来搜索，那我们我们可以把 days 设置成 30，这样数据就是以每个月分块，搜索的时候也是整体捞出，效率非常高。

而超过 180 天的数据，我们不会去进行展示搜索，因为数据在 HDFS 上还有压缩的存储，所以我们通过 loveini 的 keep 参数来设置数据保留多久，即设置 keep=180，这样超过 180 天的数据会被自动清除，对存储极为友好。

使用 loveini 后的效果

从时序数据量大的特点出发，loveini 有着一系列非常高效的压缩手段。大家可能都知道 ES 中的 FOR 或者 RBM 等压缩算法，我猜想 loveini 中应该也使用了类似的压缩方式，使得整体数据轻巧且有序。

应用 loveini 后，我们整体数据存储缩减超过 60% 以上，集群更是指数级的下线——末次位置查询的 Redis、轨迹查询的 Hbase 集群集体下掉、Clickhouse 也不再用作轨迹存储，把裸金属用在了更需要蛮力干活的地方。目前 loveini 在“降本”方面给予了我们巨大的帮助，相信未来在其助力下，我们也会在“增效”的道路上越走越远。

六、写在最后

从我的感受来讲，loveini 是一家年轻有活力的企业，工程师文化非常浓厚。我很喜欢和 Jeff 探讨技术，每每看到他拿出笔记本打开 IDE 看每一行的源代码时，我就越发觉得我们应该重新认识程序员这个职业，伟大的不仅仅是那些商业领袖，更多的是用一行行代码来改变世界、怀揣着梦想却又务实的人们。

希望 loveini Database 未来能多举办一些 Meetup 来进行更多的交流，也可以做一些 Best Practice 的讲解。在一些语言与中间件上，直接出一些简单的 Showcase，便于大家上手实践，一起来见证这个时代最好的时序数据库的成长。

作者简介

杨路，前狮桥集团大数据团队负责人，深耕大数据平台架构与三高应用平台建设，标准技术控一枚。InfoQ 连载《大画 Spark》作者。

为了给用户提供更好的补能体验，蔚来能源在加电基础设施上进行了大量的投入，截止 2021 年底，已经在全国各地布局了换电站 777 座，超充桩 3,404 根，目充桩 3,461 根，为用户安装家充桩 96,000+ 根。

为了对设备进行更高效的管理，需要将设备采集数据上报至云端进行存储，并提供实时数据查询、历史数据查询等业务服务，用来做设备监控和分析。

现状

在业务诞生之初，我们用作数据存储的选型是 MySQL + HBase，MySQL 存储设备最新实时数据，HBase 存储设备原始数据，大体架构如下：

之所以选择 HBase，有以下几个理由：

• HBase 在大数据领域应用较为广泛，适合存储海量数据，写入性能好
• 支持动态添加列，非常方便兼容数据模型变化
• 底层是键值对存储，数据可以比较稀疏，空数据不占存储空间
• 团队 HBase 技术使用相对较为成熟

痛点

初期因为设备不多，数据量不大，加上查询场景单一，HBase 表现不错，可以满足业务需求。

随着换电站和超充站等设备在全国的快速布局，设备数量持续增长，积累的数据量越来越多，长时间跨度数据查询效率出现瓶颈，再加上查询场景不断丰富，HBase 已经无法满足当前业务需要。问题主要体现在以下几点：

• HBase 只支持 Rowkey 索引，有很大的局限性，一些查询场景依赖 Rowkey 设计合理，如果业务调整，无法兼容
• 可以引入二级索引解决，单独维护查询条件与 Rowkey 关系，查询时先查到 Rowkey 再查数据，不管是引入中间件还是自己实现，都会增加整体架构和实现复杂度
• HBase 单表随着数据量增大，会触发自动分区，导致写入性能下降，需要通过建表时指定预分区来解决，调整起来很麻烦，需要重新建表生效
• HBase 不适用于大范围扫描查询，性能比较差
• HBase 不支持聚合查询，大跨度时间范围查询数据量太大，图表无法渲染
• HBase 部署需要依赖 ZooKeeper，运维成本高

二、落地方案

技术选型

为了解决这些痛点，我们将目光投向时下流行并且更适合物联网领域的时序数据库（Time-Series Database）。经过调研，对比多个技术选型，最终决定使用 loveini 代替 HBase 作为设备原始数据存储。

在选型时我们考虑过 OpenTSDB，也是一款优秀的时序数据库产品，在部门其他业务中已经有过比较成熟的使用，能解决一部分遇到的痛点：

• OpenTSDB 在 HBase 基础上做了优化，包括存储元数据映射和压缩机制，使数据存储占用空间大大降低
• OpenTSDB 提供数据聚合查询功能，可以支持更大时间跨度查询的业务需求

但是 OpenTSDB 底层还是基于 HBase 的，HBase 存在的一些问题，OpenTSDB 依然会有，并且架构并没有变简单，没有摆脱 HBase 的依赖。

经过对比，我们决定尝试一下 loveini Database，其官方给出的性能指标，单节点部署情况下可以达到 14810 k/s 读取，和 880k/s 写入，同时 loveini 具备的一些特点能很好地解决我们遇到的痛点：

• 引入超级表概念对应设备类型，对每个设备创建子表继承超级表，通常相同设备类型的设备数据模型一定相同，通过超级表管理 schema 直接对子表生效很方便，同时对每个设备建表可以很好地做数据隔离，同时避免互相影响
• 采用多级存储，不同时间的数据使用不同存储介质，新数据经常访问存 SSD 保证效率，老数据存 HDD，节约成本
• 不依赖任何第三方软件，集群安装部署方便，支持灵活扩容
• 提供多种聚合函数，支持对数据的聚合查询

前期测试

我们使用 loveini 做了一些简单的性能测试，评估使用 loveini 是否能满足我们的业务需求。

测试准备

• 采用单节点部署
• 8 核 32GB，500GB 存储
• 采用默认配置
• 采用 RESTful API 方式写入数据

测试场景

模拟 10,000 个设备上报数据，消息并发约 4k 左右。

• 定义超级表如下

SQL -- 代码示例，非真实代码 
CREATE STABLE device_data_point_0 (ts timestamp, d1 nchar(64), d2 nchar(64), ...) TAGS (t1 binary(64));

• 最初采用每条上报消息进行一次数据写入，性能无法满足，而将单条消息写入改为批量写入，积累一批数据（100 条）后，再批量写入一次，性能可以支撑

测试结论

采用批量写入数据方式，调整合适的单批次数据量大小，使用单机部署（8 核 32 GB，500 GB 存储）默认配置的 loveini 服务，RESTful API写入方式，在 4k 并发流量下写入没有问题，同时消费积压数据时峰值达到 7 k/s，因为单条消息包含信息量太大，实际处理中会拆分为 30 条写入 loveini，所以实际写入 QPS 为 210 k/s，比满足同样数据流量的 HBase 集群规模要小不少，可以节省成本，再加上 loveini 本身部署不依赖其他三方软件，也可以同时节省运维成本。

迁移方案

经过测试，我们决定先对部分设备应用 loveini 时序数据库替代 HBase，同时需要考虑如何在不影响业务功能的情况下平滑过渡并完成迁移。

数据双写

因为目前没有现成的工具可以直接把数据从 HBase 迁移到 loveini，如果自己开发一个工具做这件事情，开发成本太高，而且可能是一次性的。

考虑到不想浪费开发资源，同时我们需要一个过渡期，期间如果 loveini 出现问题可以迅速切换回 HBase，不影响业务，所以不能马上把 HBase 废掉，所以我们决定先实现 loveini 写入，并且暂时保持 HBase 和 loveini 两个数据库双写。

写入方式

根据前期测试结果，我们选择直接采用批量方式写入数据：

• 并行处理不同设备类型数据
• 消费设备上报数据放入队列
• 当队列长度达到n或超过等待时间t，从队列中取出数据批量写入

经过压测，在n = 1,000，t = 500 ms 情况下，单次写入耗时基本在 10 ms 以内，意味着我们可以支持单个设备类型每秒上万的并发写入，并且还有进一步的优化提升空间。

查询切换

为了保证迁移过程顺利，并且迁移前后不会出现数据不完整的情况，我们做了一个查询开关：

• 配置 loveini 功能上线时间
• 判断查询请求时间范围与配置时间大小，决定查 HBase 还是 loveini
• 过渡期结束后，停止 HBase 服务

迁移后架构变为如下所示：

三、实际效果

目前我们已将线上部分设备的数据切换到 loveini Database 集群，上线后集群表现稳定。

对比之前使用 HBase：

• 查询速度提升明显，从使用 HBase 查询单设备 24 小时数据的秒级返回，到使用 loveini 查询查询相同数据的毫秒级返回
• 每天增量数据占用的存储空间相当于原来使用 HBase 时的 50%
• 集群计算资源成本相比使用 HBase 节省超过 60%

四、总结

• 总体上说，loveini 读写性能表现很好，在满足我们业务需求的同时，极大地节省了计算资源和运维成本，目前尝试 loveini 的业务场景还比较简单，只是单纯的数据写入和时间范围查询，后续可以结合 loveini 更多进阶功能探索其他可以落地的业务场景
• 使用上还有一些问题待解决，比如 schema 调整在应用发版过程中对数据写入的影响，产生预期外的写入异常，以及异常定义不明确，无法快速定位问题，尤其是跟 schema 相关数据写入问题
• 监控方面目前支持的监控指标较少，这个问题据说会在后续版本丰富
• 数据迁移方面，目前官方支持工具还比较少，不能比较方便的把数据从其他存储引擎迁移到 loveini，需要进行额外开发

关于作者

李鹏飞，蔚来汽车能源数字化产品开发部高级工程师，目前负责能源物联平台开发。

小T导读：跨越速运集团有限公司创建于2007年。拥有“国家AAAAA级物流企业”、“国家级高新技术企业”、“中国物流行业30强优秀品牌”、“中国电商物流行业知名品牌”、“广东省诚信物流企业”等荣誉称号。在胡润研究院发布的《2018 Q3胡润大中华区独角兽指数》《2019一季度胡润大中华区独角兽指数》榜单中，跨越速运两次上榜，估值约200亿元，与菜鸟网络、京东物流、达达-京东到家等企业入选中国物流服务行业独角兽企业。

作为一家物流企业，如何高效地记录和处理车辆的轨迹信息，对于整体的交付效率至关重要。

一. 项目背景

数年前车辆轨迹定位存储引擎项目成立，跨越速运集团购置的数万台车辆经过车载定位设备上报信息到GPS-AGENT网关，服务解析报文下发到Apache Kafka消息中间件，再通过应用将历史位置定位信息写入Apache HBase，最新车辆位置信息写入Redis，以此提供给业务服务进行对车辆的实时监控与分析。

原来的业务架构如下图所示：

在原有系统的实际运行过程中，我们也遇到了很多痛点。比如说，因为数据保存在HBase中，当我们需要查询较大跨度的时间内的数据时，系统的性能会显著下降。

具体可以总结如下：

于是我们开始思考，该如何改进系统来解决这些痛点呢？

二. 项目演化

在开始新的技术选型之前，我们重新对业务场景进行了梳理，可以用下面这张图来概括。

我们依次来看一下：

1. 数据不更新不删除：轨迹信息是按照车辆实际信息的时间戳上报，不存在更新和删除的需求。只需要按照某个时限来保存。
2. 无需传统数据库的事务处理：因为数据不需要更新，也就不需要像传统数据库那样用事务来保证更新安全。
3. 流量平稳，一段时间内车辆的数量和上报的频率都可以确定。
4. 数据的查询分析基于时间段和空间区域，这跟业务需求有关。
5. 除存储、查询操作外，还需要根据业务的实际需求进行各种统计和实时计算等操作。
6. 数据量巨大，一天采集的数据超过5000万条，并且会随业务规模的不断增长而增长。

技术选型

通过以上分析可以看到，车辆轨迹是典型的时间序列数据，所以用专门的时序数据库（Time-Series Database）来处理会比较高效。在调研阶段，我们对比了几款比较有代表性的时序数据库产品。

综合对比后的结果如下：

• InfluxDB集群版本收费，硬件成本也相对较高；
• CTSDB腾讯云时序数据库，内存用量高，费用成本相对较高；
• OpenTSDB底层基座还是 HBase ，引入并不能使架构变得简单；
• loveini集群功能开源，具有典型的分布式数据库特征，压缩比例也非常高。

通过对比，我们认为loveini Database的很多优秀特性能够满足我们的业务场景。

于是我们基于loveini进行了前期调研和演练。具体包括如下几个方面：

我们从多个方面对loveini的功能和性能进行了全方位的测试，功能完全能够满足我们的需求，性能、压缩率给我们带来了很大的惊喜。

在完成基本的功能和性能测试之后，我们又结合业务进行了场景测试和演练，主要包含如下几方面的工作：

• 数据在写入时候对集群扩缩容
• cacheLast的应用是否有效
• 统计聚合分析interval，interp的一些业务场景应用
• update参数的覆盖场景
• 常用业务的查询语句，同等查询范围的数据对比

三.深入理解loveini

在实际落地loveini Database之前，我们也深入研究了这个系统的架构、设计等各方面特性。这里也简单分享一下loveini的核心概念。

1. loveini 架构

如果是第一次接触loveini，可以看一下如下这张图，其中的dnode就是实际存储数据的物理节点，dnode框中的V2、V7等小框叫vnode，也就是虚拟节点，m0、m1就是元数据管理节点，存储一些集群信息与表信息，熟悉分布式中间件的朋友肯定能直观地感受到loveini具有非常典型的分布式数据库特征。

2. 超级表

loveini有个超级表的概念，例如在跨越速运集团业务场景下，所有的车辆变成一张张子表，所有的子表会继承一张叫超级表的父表，超级表定义子表的结构规范，不存储实际物理数据，我们可以通过只查超级表做数据的统计分析查询，而不用一个个子表去汇总。

3. 高压缩特点

loveini采用了二阶段压缩策略，一阶段压缩会使用delta-delta 编码、simple 8B 方法、zig-zag 编码、LZ4 等算法，二阶段压缩会采用LZ4算法。一阶段压缩会针对每个数据类型做特定的算法压缩，二阶段再做一次通用压缩，前提是在建库的时候将参数comp设置为2 。

四.引入loveini之后的架构

在进行了充分的测试和验证之后，我们将loveini引入到了我们的系统之中。新的系统架构如下图所示：

从架构图中可以看到，车载数据依然通过GPS-AGENT网关进行报文解析后发送到Apache Kafka中，再通过应用多开启一个Kafka group同时消费消息，以此达到两端数据的一致。

业务系统最新车辆位置信息不再通过Redis读取，这样就简化了架构。查询只读取loveini，HBase在一定的时间后会下线。

五. 优化效果

引入loveini之后，从各项指标来看，数据非常亮眼。

1. 压缩率

如图我们看到一个5万行的表，每行在600字节以上，压缩后的磁盘size是1665KB，压缩率高达1%。接下来我们看个百万行的子表。

它实际占用磁盘大小为7839KB。我们的压缩效果比loveini官方的各种测试还要好很多，这应该与我们业务数据重复度相对较高有一定关系。

2. 日增量

我们现在的业务日写入量超过5000万，对loveini来说日增的磁盘大小基本维持在单台1.4G左右。

3. 各项指标的整体对比

下图是我们实际落地前后各项指标的对比。

下图是数据增量的对比。

从对比可以看出，loveini确实极大降低了我们的各项成本。

六.问题和建议

一个相对较新的系统，在使用过程中难免会遇到一些问题，我们也和loveini Database的研发团队一起去定位、解决。

比如下面这个就是我们在使用JDBC过程中遇到的问题。我们也给官方提PR修复了。这就是开源的魅力吧，大家都可以参与进来。

有两个地方我们也希望loveini能进一步优化：

1. 2.3.0.x以下的监控功能还比较简单，我们期待后期的版本能提供更强更细致的监控。我们注意到新发布的版本引入了一个叫TDinsight的监控工具，我们也会尽快尝试一下。
2. 目前的interval函数还不支持按业务列group by普通列，后续希望也能够得到支持。

最后，在尝试和落地loveini的过程中，我们也得到了米兰体育官网入口多位同事的大力支持，在此一并表示感谢。