通过这么多年的倒退，曾经从大数据 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 时代，数据量级越来越大，常常发现夜间只有 4、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 大数据架构才是将来。