openGemini 在重庆市机动车大数据应用项目中的实践

重庆全市的机动车都安装了电子车牌，在全市的道路、桥梁、商圈、旅游景点、车库等关键点安装了RFID读取设备，约2万个点，可以无感获取经过车辆的信息，同时，在全市安装了1万多个抓拍设备，可以抓取经过车辆的车牌。

重庆全市每天在途车辆约350万辆，每天RFID数据约5000万条，抓拍数据约1200万条，高清照片约1200万张。

应用可以根据RFID设备编码和时间查询经过某道路的全部车辆，也可以根据车牌号和时间查询经过哪些道路。

初期的技术架构中，数据采集集群采集外场设备的数据，把照片推给文件集群，把RFID数据和抓拍数据推送到Kafka集群，实时业务处理集群消费Kafka集群的数据，处理如实时定位、电子围栏等实时处理业务，将处理结果推送给服务集群。同时，Kafka集群的数据消费后，写入了ElasticSearch集群，作为计算集群的基础数据，计算结果推送给服务集群。

项目改造原因：

（1） 国产化数据库要求。

（2） ElasticSearch的检索速度有限，限制了计算集群的性能，在访问人数比较多的情况下，大家普遍感觉整个系统响应比较慢，体验不好。

（3） 照片数量大，采用的文件系统SeaweedFS存储不及时，造成网关堵塞。

技术改造有如下几点：

（1） 将原来的ElasticSearch改造为openGemini + starrocks架构

我们项目是典型的时序高基数场景，其中仅车牌这一字段的基数就高达千万级别。此外，还有大约2万台RFID设备，使得整个时间线的数据规模达到了千亿级别。尽管openGemini v1.0版本在处理高基数问题上的能力有限，但其读写性能显著优于ElasticSearch。因此，我们对业务进行了深入分析，希望可以找到一个折中的方案。

我们发现大多数查询需求集中在最近一个月的数据上，而超过一个月的数据查询相对较少。在一个月的时间内，并非所有车辆都会上路行驶，而且行驶的车辆也不会经过所有安装了RFID设备的道路。实际上，大多数车辆的日常行驶路线是相对固定的，因此通过合理的TAG字段设置，可以把时间线控制在千万级到亿级，这个规模对openGemini来说是完全没有问题的。

最终，我们采取的技术方案是充分发挥openGemini在高速写入方面的优势，同时合理利用starrocks出色的检索能力。数据首先被消费并写入openGemini，该系统仅保留最近40天的数据，超出此时间范围的数据将自动被删除。每个月的第一天凌晨，我们会将openGemini中的数据迁移到Starrocks。计算集群如果是使用本月的数据，就从openGemini提取，如果使用历史数据，就从Starrocks提取。

Starrocks源于百度Palo，和Doris同源，检索性能非常优异，经过测试，在6亿条记录、多条件查询的场景下，检索性能Starrocks比ElasticSearch约快10倍，但是长时间数据持续大量写入，会造成Starrocks的不稳定。

（2） 将文件集群改造为文件集群 + openGemini架构

将原来的SeaweedFS系统替换成自己开发的socketServer文件系统后，接收和存储的速度得到了快速提升，满足了业务需求，但没有了集群能力，为了方便记录照片是存放到哪台服务器，采用了openGemini，openGemini数据保存期为3年。当前端访问了某条过车记录时，获取记录的关键词，利用这个关键词从openGemini里查询到照片的存放位置，以服务的方式提供给前台页面。

本项目利用了openGemini的几个特点：

（1） 高速的写入性能。

（2） 检索性能好：支持的时间线数量大，满足了特殊业务的需求。有了时间线的支撑，检索性能就得到了保障。

（3） 维护简单：不需要对过期数据进行人工处理。

（4） 部署简单：仅进行简单配置即可部署。

（5） 二次开发简单。

本文主要分享了我在项目中如何使用openGemini，并有效规避了时序高基数问题，使得项目顺利交付。作为一个在大数据领域摸爬滚打多年的老兵，我希望这些经验能为其他读者提供一些有价值的参考，也为社区的发展贡献自己的绵薄之力，并期待社区的未来更加繁荣。

作者 | 大数据道哥

排版 | openGemini