Hi 欢迎来到易观方舟
有问题就找小舟助手
联系我们 周一至周五 10:00 - 18:00

产品咨询:4006 - 010 - 231 转 1

商务合作:4006 - 010 - 231 转 2

咨询与帮助

易观方舟带你了解IOTA整体技术结构知识

在IOT大潮下,智能手机、PC、智能硬件设备的计算能力越来越强,而业务需求要求数据实时响应需求能力也越来越强,过去传统的中心化、非实时化数据处理的思路已经不适应现在的大数据分析需求,我提出新一代的大数据IOTA架构来解决上述问题,整体思路是设定标准数据模型。IOTA整体技术结构分为几部分:

 

Common Data Model:贯穿整体业务始终的数据模型,这个模型是整个业务的核心,要保持SDK、cache、历史数据、查询引擎保持一致。对于用户数据分析来讲可以定义为“主-谓-宾”或者“对象-事件”这样的抽象模型来满足各种各样的查询。以大家熟悉的APP用户模型为例,用“主-谓-宾”模型描述就是“X用户–事件1–A页面(20184112000)”。当然,根据业务需求的不同,也可以使用“产品-事件”、“地点-时间”模型等等。模型本身也可以根据协议(例如protobuf)来实现SDK端定义,中央存储的方式。此处核心是,从SDK到存储到处理是统一的一个Common Data Model。

 

Edge SDKs & Edge Servers:这是数据的采集端,不仅仅是过去的简单的SDK,在复杂的计算情况下,会赋予SDK更复杂的计算,在设备端就转化为形成统一的数据模型来进行传送。例如对于智能Wi-Fi采集的数据,从AC端就变为“X用户的MAC地址-出现-A楼层(20184111800)”这种主-谓-宾结构,对于摄像头会通过EdgeAIServer,转化成为“X的Face特征-进入-A火车站(20184112000)”。也可以是上面提到的简单的APP或者页面级别的“X用户–事件1–A页面(20184112000)”,对于APP和H5页面来讲,没有计算工作量,只要求埋点格式即可。

 

Real Time Data:实时数据缓存区,这部分是为了达到实时计算的目的,海量数据接收不可能海量实时入历史数据库,那样会出现建立索引延迟、历史数据碎片文件等问题。因此,有一个实时数据缓存区来存储最近几分钟或者几秒钟的数据。这块可以使用Kudu或者Hbase等组件来实现。这部分数据会通过Dumper来合并到历史数据当中。此处的数据模型和SDK端数据模型是保持一致的,都是CommonDataModel,例如“主-谓-宾”模型。

 

Historical Data:历史数据沉浸区,这部分是保存了大量的历史数据,为了实现Ad-hoc查询,将自动建立相关索引提高整体历史数据查询效率,从而实现秒级复杂查询百亿条数据的反馈。例如可以使用HDFS存储历史数据,此处的数据模型依然SDK端数据模型是保持一致的CommonDataModel。

 

Dumper:Dumper的主要工作就是把最近几秒或者几分钟的实时数据,根据汇聚规则、建立索引,存储到历史存储结构当中,可以使用mapreduce、C、Scala来撰写,把相关的数据从RealtimeData区写入HistoricalData区。

 

QueryEngine:查询引擎,提供统一的对外查询接口和协议(例如SQLJDBC),把RealtimeData和HistoricalData合并到一起查询,从而实现对于数据实时的Ad-hoc查询。例如常见的计算引擎可以使用presto、impala、clickhouse等。

 

Realtimemodelfeedback:通过Edgecomputing技术,在边缘端有更多的交互可以做,可以通过在RealtimeData去设定规则来对EdgeSDK端进行控制,例如,数据上传的频次降低、语音控制的迅速反馈,某些条件和规则的触发等等。简单的事件处理,将通过本地的IOT端完成,例如,嫌疑犯的识别现在已经有很多摄像头本身带有此功能。

 

在大数据3.0时代,去ETL化的IOTA大数据架构才是未来。

相关推荐:

体验文中提到的功能

立即免费体验Demo

百闻不如一见

现在来体验方舟如何帮你挖掘商机、增长业绩

体验Demo