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
参考资料