大数据分析的下一代架构--IOTA

IOTA是什么？你是否为下一代大数据架构作好准备？

通过这么多年的发展，已经从大数据1.0的BI/Datawarehouse时代，通过大数据2.0的Web/APP过渡，进入到了IOT的大数据3.0时代，而随之而来的是数据架构的变化。

▌Lambda架构

在过去Lambda数据架构成为每个公司大数据平台必备的架构，它解决了一个公司大数据批量离线处理和实时数据处理的需求。一个典型的Lambda架构以下：

数据从底层的数据源开始，通过各类各样的格式进入大数据平台，在大数据平台中通过Kafka、Flume等数据组件进行收集，而后分红两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark Streaming），去计算实时的一些指标；另外一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标须要隔日才能看见。

Lambda架构经历多年的发展，其优势是稳定，对于实时计算部分的计算成本可控，批量处理能够用晚上的时间来总体批量计算，这样把实时计算和离线计算高峰分开，这种架构支撑了数据行业的早期发展，可是它也有一些致命缺点，并在大数据3.0时代愈来愈不适应数据分析业务的需求。缺点以下：

● 实时与批量计算结果不一致引发的数据口径问题：由于批量和实时计算走的是两个计算框架和计算程序，算出的结果每每不一样，常常看到一个数字当天看是一个数据，次日看昨天的数据反而发生了变化。

● 批量计算在计算窗口内没法完成：在IOT时代，数据量级愈来愈大，常常发现夜间只有四、5个小时的时间窗口，已经没法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每一个大数据团队头疼的问题。

●数据源变化都要从新开发，开发周期长：每次数据源的格式变化，业务的逻辑变化都须要针对ETL和Streaming作开发修改，总体开发周期很长，业务反应不够迅速。

● 服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，形成数据急速膨胀，加大服务器存储压力。

▌Kappa架构

针对Lambda架构的须要维护两套程序等以上缺点，LinkedIn的Jay Kreps结合实际经验和我的体会提出了Kappa架构。Kappa架构的核心思想是经过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用同一套代码。此外Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算，而若是须要重复计算时，Kappa架构下能够启动不少个实例进行重复计算。

一个典型的Kappa架构以下图所示：

Kappa架构的核心思想，包括如下三点：

1.用Kafka或者相似MQ队列系统收集各类各样的数据，你须要几天的数据量就保存几天。

2.当须要全量从新计算时，从新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。

3.当新的实例作完后，中止老的流计算实例，并把老的一些结果删除。

Kappa架构的优势在于将实时和离线代码统一块儿来，方便维护并且统一了数据口径的问题。而Kappa的缺点也很明显：

● 流式处理对于历史数据的高吞吐量力不从心：全部的数据都经过流式计算，即使经过加大并发实例数亦很难适应IOT时代对数据查询响应的即时性要求。

● 开发周期长：此外Kappa架构下因为采集的数据格式的不统一，每次都须要开发不一样的Streaming程序，致使开发周期长。

● 服务器成本浪费：Kappa架构的核心原理依赖于外部高性能存储redis,hbase服务。可是这2种系统组件，又并不是设计来知足全量数据存储设计，对服务器成本严重浪费。

▌IOTA架构

而在IOT大潮下，智能手机、PC、智能硬件设备的计算能力愈来愈强，而业务需求要求数据实时响应需求能力也愈来愈强，过去传统的中心化、非实时化数据处理的思路已经不适应如今的大数据分析需求，我提出新一代的大数据IOTA架构来解决上述问题，总体思路是设定标准数据模型，经过边缘计算技术把全部的计算过程分散在数据产生、计算和查询过程中，以统一的数据模型贯穿始终，从而提升总体的预算效率，同时知足即时计算的须要，可使用各类Ad-hoc Query来查询底层数据：

IOTA总体技术结构分为几部分：

● Common Data Model：贯穿总体业务始终的数据模型，这个模型是整个业务的核心，要保持SDK、cache、历史数据、查询引擎保持一致。对于用户数据分析来说能够定义为“主-谓-宾”或者“对象-事件”这样的抽象模型来知足各类各样的查询。以你们熟悉的APP用户模型为例，用“主-谓-宾”模型描述就是“X用户 – 事件1 – A页面（2018/4/11 20:00） ”。固然，根据业务需求的不一样，也可使用“产品-事件”、“地点-时间”模型等等。模型自己也能够根据协议（例如 protobuf）来实现SDK端定义，中央存储的方式。此处核心是，从SDK到存储处处理是统一的一个Common Data Model。

● Edge SDKs & Edge Servers：这是数据的采集端，不只仅是过去的简单的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页面来说，没有计算工做量，只要求埋点格式便可。

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

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

● 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架构有各类各样的实现方法，为了验证IOTA架构，易观也自主设计并实现了“秒算”引擎，目前支持易观内部月活5.5亿设备端进行计算的同时，也基于“秒算”引擎研发出了能够独立部署在企业客户内，进行数字用户分析和营销的“易观方舟”，能够访问ark.analysys.cn进行体验。

在大数据3.0时代，Lambda大数据架构已经没法知足企业用户平常大数据分析和精益运营的须要，去ETL化的IOTA大数据架构才是将来。