返回
环保机械设备首页
会员登陆

基于Hadoop的卡口(hadoop接口)

投稿用户

更新时间:2025-11-09

180

内容摘要:基于Hadoop的卡口(hadoop接口)引言随着太原经济快速发展,机动车保有量增长迅猛,道路交通拥堵、交通肇事现象越来越严重。为此,太原交警建设了大量卡口、电子警察、事件监测等交通监控设备,这些设备24h不间断捕获过车数据和图像数据,产生了海量历史记录。在此情况下,如何利用先进的技术手段,对交通监控设备采集的海量数据进

引言

随着太原经济快速发展,机动车保有量增长迅猛,道路交通拥堵、交通肇事现象越来越严重。为此,太原交警建设了大量卡口、电子警察、事件监测等交通监控设备,这些设备24h不间断捕获过车数据和图像数据,产生了海量历史记录。在此情况下,如何利用先进的技术手段,对交通监控设备采集的海量数据进行深度挖掘分析成为迫切需要解决的问题。

基于Hadoop的卡口(hadoop接口)

基于Hadoop的卡口(hadoop接口)

目前国内现有大数据分析系统处于结构化数据处理模式架构体系,无法对城市道路交通整体状况、出行规律进行大粒度、长周期的数据分析,同时现有系统在对具有逻辑关联的海量多源异构数据处理存储效率方面存在不足,不能满足持续增长的交管数据规模以及对数据深度挖掘、数据碰撞和应用的需求。面对海量信息洪流以及对数据深度挖掘迫切需求,采用大数据技术解决数据管理和应用问题已是迫在眉睫。

1关键性技术研究

1.1结构化与非结构化相结合数据的实时存储、实时分析

卡口数据是典型的结构化和非结构化相结合的数据。其中过车记录是结构化数据,过车图片是非结构化数据。两类数据不仅需要实时存储,还需要进行实时分析。

根据KUDU+HBASsMoB存储特性可以很好地解决这个问题。KUDU+HBASsMoB解决方案如图1所示。

接收程序把数据(例如卡口过车记录)写到KUDU,Impala/Spark可以实时对数据进行查询分析。过车图片按HBASs的大对象存储(MoB)格式进行存储。该格式特别适合存储单个数十千至数十兆的非结构化文档,即使对于十亿级别的MoB文档数据表仍能做到毫秒级增删改查操作,同时支持所有HBASs原生特性,与上层HBASs应用100%兼容。

1.2前后端多环节多网络环境下如何保障数据不丢不重

以最复杂的核心业务数据,卡口数据的传输为例进行说明,卡口数据从卡口客户端传输到大数据平台中的KUDU和HBASs存储需要经过4个环节:

(1)从卡口客户端传输过车记录和过车图片到卡口高效接入与转发程序:

(2)卡口高效接入与转发程序传输过车记录和过车图片到消息服务器kafka:

(3)消息服务器kafka传输过车记录到分布式关系型存储KUDU:

(4)消息服务器kafka传输过车图片到分布式列式存储HBASs。

由于网络中断、程序异常在上述1到4的任何一个环节都会存在数据丢失的可能。而卡口数据在业务上要求不能丢失和重复,因此该问题成为一个关键性技术问题。

通过引入多级缓存和各环节之间确认机制,保障数据不丢不重的解决方案如图2所示。

(1)首先对每类数据的每个数据产生唯一的数据指纹作为幂等性确认的唯一标识。该标识符根据毫秒级时间戳加数据特征码自动生成,在传输过程中一直保持不变,作为数据唯一性确认的标识。(2)传输中间环境基于内存处理,同时以文件系统做内容缓存,防止数据丢失。在卡口高效接入与转发程序与kafka这两个中间环境,数据内存留一份,同时文件系统数据缓存一份。缓存直到数据确认收到后才会删除。(3)4个环节每个环节之间进行确认。1)从卡口客户端到卡口高效接入与转发程序之间做双向确认,只有卡口高效接入与转发程序确认收到数据后卡口客户端才会删除数据,否则会保留数据,继续重发。2)卡口高效接入与转发程序到消息服务器kafka之间做双向确认,只有kafka确认收到数据后,卡口高效接入与转发程序才会删除数据否则会保留数据,继续重发。3)消息服务器kafka传输过车记录到分布式关系型存储KUDU,传输过车图片到分布式列式存储HBASEkafka会与KUDU和HBASE之间做双向确认,只有KUDU和HBASE确认都收到数据后kafka才会删除数据否则会保留数据,继续重发。

通过上述机制,可以保证整个数据传输过程数据不丢、不重。

2基于Hadoop的大数据中间件平台架构设计

大数据平台由分布式资源管理框架实时调度资源、管理计算分析集群,为各个租户以及各个应用提供资源调度管理以及高效的分析挖掘能力。

2.1数据采集

主要完成数据的统一采集和处理。针对多样化数据进行采集和清洗兼容各类数据源(结构化/半结构化/非结构化)、接口方式(FTP/数据库/消息队列)和采集频率(批量/流式)的需求可对数据采集频率、处理流程做配置化管理。

2.2数据存储

数据存储应当按照数据的颗粒细度以及数据分析应用的不同需要,将数据分为ODS层、轻度汇总、中度汇总层、高度汇总层。ODS和轻度汇总层放置于HDFS中需要检索查询的明细记录存储在HBASE中,经过HIVE处理后的汇总数据可通过Sqoop写入外部数据库或者通过Impala提供相应的实时查询。2.3数据处理组件

数据处理提供不同层面的大数据并行处理能力充分利用x86框架廉价的计算和存储能力实现分布式计算和存储管控,并向上提供各类分析、查询、处理能力。

2.4系统管理

实现整体体系的系统安全、系统任务、系统权限等管理功能,同时结合LDAP与Kerberos提供完备的权限管理控制。

3海量大数据分析研判平台框架设计

海量大数据分析研判平台框架设计如图3所示。

3.1数据源

从对接系统中接入如下数据:(1)基础数据。车辆监管清单、卡口点位表、道路信息表、城区信息表和街道信息表。(2)业务数据。卡口数据、百度路况数据和l22事故数据。

3.2大数据硬件

支持大数据中间件和应用软件运行的硬件环境,包括PC服务器、网络设备和存储。

3.3大数据中间件

在大数据硬件环境上部署Hadoop大数据中间件软件为应用提供数据存储和分析支撑。

3.4数据接入层

支持多协议、多路由适配,接入各类数据源,并发送到统一的消息服务器kafka中,为后续的数据存储和分析应用提供数据。接入内容包括车辆监管清单、卡口点位表、道路信息表、城区信息表、街道信息表、卡口数据、百度路况和122事故数据等。

3.5数据存储层

实现数据的海量和高效存储提供对外数据服务其中过车记录存储至KUDU,过车图片存储至HBASE,满足高效写入、检索、读取需求。

3.6数据分析层

实现数据的深度挖掘和图像二次识别分析支撑,提供流式分析平台,实现即时、实时和离线分析,并可以通过数据湖对所有异构数据源的统一访问和处理。

3.7服务层

提供数据虚拟引擎,支持对异构数据库(oracle/hbase/kudu/es/mysql/mongodb/hdfs等)的统一管理和数据接口提供。该引擎为服务层的数据服务和大数据交互式查询提供统一数据查询统计支持。其中数据服务包括卡口数据服务、过车图片数据服务、货车闯禁行数据服务、不系安全带数据访问服务、开车打手机数据访问服务、黄标车违法数据访问服务和单双号限行数据访问服务:大数据交互式查询包括HDFS访问、HIVE查询和其他支持。

3.8应用展示层

实现业务应用和可视化展示,包括大数据流式计算分析结果展示(车辆、路况、流量、OD和违法)和综合信息大屏展示。

3.9管理层

实现基础管理功能支撑,包括系统管理、系统对接、监控和配置。

3.10用户终端

使用PC终端和展示大屏。

4结语

本文在太原市现有数据挖掘的基础上,提出搭建Hadoop大数据中间件平台,并在此基础上对卡口、百度路况等海量数据进行了实时高效接入、分布式存储、多维度挖掘分析和可视化直观展示,满足持续增长的交管数据规模以及对数据深度挖掘、数据碰撞和应用的需求最终实现资源集成、数据集成、业务集成、控制集成和展现集成。

标签:卡口,接口,hadoop,Hadoop,基于
本文网址:https://m.huanbaojx.cn/gfcl/19398.html

免责声明:
本站部份内容系网友自发上传与转载,不代表本网赞同其观点;
如涉及内容、版权等问题,请在及时联系我们,我们将在核实后第一时间删除内容!

上一篇:空气调节器(空气调节器和空调区别)

下一篇:AT1121辐射测量仪应用(at1121辐射检测仪)

相关阅读

相关产品