随笔 - 244, 文章 - 0, 评论 - 53
  博客园  :: 首页  :: 联系 :: 管理

四:大数据架构回顾-IOTA架构

Posted on 2020-11-08 16:00  天戈朱  阅读(215)  评论(0编辑  收藏

   IOTA大数据架构一种基于AI生态下的全新的数据架构模式,2018年,易观首次提出这一概念。IOTA的整体思路是设定标准数据模型,通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中,以统一的数据模型贯穿始终,从而提高整体的计算效率,同时满足计算的需要,可以使用各种Ad-hoc Query来查询底层数据。

  IOT大潮下,智能手机、PC、智能硬件设备的计算能力越来越强,业务要求数据有实时的响应能力,Lambda架构已经不能适应当今大数据分析时代的需求。IOTA架构如下图:

IOTA架构 --- 数据流转过程示例

Common Data Model


  • 贯穿整体业务始终的数据模型,这个模型是整个业务的核心,要保持SDK、cache、历史数据、查询引擎保持一致。
  • 对于用户数据分析来讲可以定义为“主-谓-宾”或者“对象-事件”这样的抽象模型来满足各种各样的查询。

用户行为“主-谓-宾”模型示例:

  • 智能手表:X用户 – 进行了 – 游泳运动
  • 视频APP:X用户 – 播放 – 影片
  • 电商网站:X用户 – 购买 – 手机( 2018/12/11 18:00:00 , IP , GPS)

用户行为“对象-事件”模型

  • 事件(Event):主要是描述用户做了什么事情,记录用户触发的行为,例如注册、登录、支付事件等等
  • 事件属性: 更精准的描述用户行为,例如事件发生的位置、方式和内容
  • 每一条event数据对应用户的一次行为信息, 例如浏览、登录、搜索事件等等

   --- 当然,根据业务需求的不同,也可以使用“产品-事件”、“地点-时间”模型等等。模型本身也可以根据协议(例如 protobuf)来实现SDK端定义,中央存储的方式。此处核心是,从SDK到存储到处理是统一的一个Common Data Model。

Edge SDK


  •  这是数据的采集端,不仅仅是过去的简单的SDK,在复杂的计算情况下,会赋予SDK更复杂的计算,在设备端就转化为形成统一的数据模型来进行传送。

  示例:

  • 智能Wi-Fi采集的数据:从AC端就变为 “ X用户的MAC 地址 - 出现 -  A楼层(2018/4/11 18:00)” 这种主-谓-宾结构
  • 摄像头: 会通过Edge AI Server,转化成为 “ X的Face特征 -  进入 -  A火车站(2018/4/11 20:00)”
  • APP/页面:“ X用户 – 事件1 – A页面(2018/4/11 20:00) ” ,对于APP和H5页面来讲,没有计算工作量,只要求埋点格式即可。
  •  

一个稳定的数据采集端需要有如下功能,存储、回数、控制、保护:

  • 存储:数据存储,校验当前存储数据合法性,及防止数据被第三方篡改
  • 回数:数据上报,加密上报数据,防止被第三方截取,保证不受 HOOK 等影响,防止 DNS 污染等。
  • 控制:控制发送策略,可以指定 3G / 4G / wifi 环境上传,可以调整上报时间频次、本地数据缓存规则全部可动态调整
  • 保护:有自保护机制。不要影响用户的正常使用,减少因逆向导致的数据异常

显而易见,普通的采集端都具有这些功能。作为 IOTA 架构下的采集端进行了哪些优化呢?如下:

  • 统一模型:在 IOTA 架构下从数据采集到数据接收以及数据处理都是用一套数据模型。
  • 聚合:同样的数据进行边缘聚合计算,如某些用户访问路径可以直接由采集端来完成,生成对应类似漏斗的事件。一般这个计算是服务器下发策略来动态控制的,当然也可以随时做出调整,值得注意的是这是不可以逆的运算,并且这种模式只适用于适合间隔发送模式的数据
  • 校验:数据的完整和有效性可以放到采集端处理,确保 SDK 给 server 的数据不是被修改的,产生的数据是合理的,这就要求采集端加入防作弊的功能。这是一个成熟产品长期需要投入的项目,大部分公司的风控做的也有一部分这样的工作。
  • 实时:数据实时上报给服务器,这样才能让用户感觉到零延迟,实时计算。如12306购票,要立即的进行查看结果,不能等得到次日才看到结果。同样的带来另一个问题,
  • 高可控:高可控是对数据采集最基础,也是最重要的一个要求。不然面对攻击,服务器无法实时监控,动态调整,立即处理,可能会导致服务器的短时间无法正常工作(如数据处理延迟,严重的乃至宕机)

Real Time Data


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

Historical Data


  • 历史数据沉浸区,这部分是保存了大量的历史数据,为了实现Ad-hoc查询,将自动建立相关索引提高整体历史数据查询效率,从而实现秒级复杂查询百亿条数据的反馈。例如可以使用HDFS存储历史数据,此处的数据模型依然SDK端数据模型是保持一致的Common Data Model。
  • 当buffer区的数据量达到一定规模时,调度会启动DumpMR(Spark、MR任务)会将缓冲区数据flush到HDFS中去,因为还要支持数据的实时查询,我们采用R/W表切换方案,即一直写入一张表直到阈值,就写入新表,老表开始转为ORC格式。

HDFS高效存储:

  • 按天分区
  • 基于用户ID,事件时间排序
  • 冷热分层
  • Orc存储
  • BloomFilter 
  • 稀疏索引
  • Snappy压缩

小文件问题:

  • 不按事件分区
  • MergerMR定时合并小文件

Dumper


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

Query Engine


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

Realtime model feedback


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

IOTA架构主要特点


  • 去ETL化:ETL和相关开发一直是大数据处理的痛点,IOTA架构通过Common Data Model的设计,专注在某一个具体领域的数据计算,从而可以从SDK端开始计算,中央端只做采集、建立索引和查询,提高整体数据分析的效率。
  • Ad-hoc即时查询:鉴于整体的计算流程机制,在手机端、智能IOT事件发生之时,就可以直接传送到云端进入real time data区,可以被前端的Query Engine来查询。此时用户可以使用各种各样的查询,直接查到前几秒发生的事件,而不用在等待ETL或者Streaming的数据研发和处理。
  • 边缘计算(Edge-Computing):将过去统一到中央进行整体计算,分散到数据产生、存储和查询端,数据产生既符合Common Data Model。同时,也给与Realtime model feedback,让客户端传送数据的同时马上进行反馈,而不需要所有事件都要到中央端处理之后再进行下发。

架构示例 


IOTA vs Lambda


IOTA vs Kappa


 

参考资料