在 Hadoop 系列框架还没出现之前，数据分析工作已经经历漫长的发展，其中以 BI 系统为主的数据分析，已经有非常成熟和稳定的技术解决方案和生态系统，BI 系统的架构图如下：
BI 又叫商业智能，其包括与传统业务系统的区别在于：业务系统更注重于事务型的数据处理，用来支撑企业的各业务线；而 BI 是将企业中所有数据汇聚成数据仓库（DW）并对其进行分析型操作，其中 Cube 是 BI 的核心模块。Cube 是一额更高层的业务抽象模型，在 Cube 上可以进行上钻、下钻、切片等操作、
BI 系统都是基于关系型数据库，关系型数据库使用 SQL 语句进行操作，但是 SQL 在多维操作相对较弱，所以 Cube 有自己独有的查询语言多维查询语言 —— MDX
大多数的数据库服务厂商都提供 BI 服务，轻易便可搭建出一套 OLAP 分析系统
OLTP 联机事务处理，表现为企业中的应用系统如 OA、CRM、ERP、财务软件等供各部门使用
OLAP 联机分析处理，也叫决策支持系统 DSS，通常进行使用者是企业高管或部门管理者
但是随着互联网发展，BI 系统也暴露除了一些缺点:
BI 系统多以分析业务数据产生结构化数据为主，对于非结构化和半结构化数据处理乏力。例如图片、文本、音频的存储、分析。
随着异构数据源增加，要解析数据内容进入数据仓库，则需要非常复杂的 ETL 程序，从而导致 ETL 变得过于庞大和容易出错，需要大量人力进行维护
随着数据的增长，性能会成为瓶颈，在 TB/PB 级别的数据处理上表现的尤为乏力
数据仓库的原始数据都是只读的用来分析，不存实务操作者导致传统的范式约束大大影响了性能
由于 BI 的一系列问题，在以 Hadoop 生态圈的大数据分析平台逐渐表现出其优异性，围绕 Hadoop 体系的生态圈也不断变大，对于 Hadoop 系统来说，从根本上解决了传统数据仓库瓶颈的问题
随着大数据平台的不断发展，现在主要对数据的处理时效进行区分为
针对于 T+1 数据的离线处理架构，其主要应用框架由 Hadoop、Hive、Sqoop 等组成
针对实时数据的流式处理架构，其主要由 Spark、Flink、Flume、Kafka 等组成
Lambda 架构
“我们正在从 IT 时代走向 DT 时代 (数据时代)。IT 和 DT 之间，不仅仅是技术的变革，更是思想意识的变革，IT 主要是为自我服务，用来更好地自我控制和管理，DT 则是激活生产力，让别人活得比你好”
Hadoop 作为解决对大数据量低成本规模化的处理的解决方案被广泛应用
但是 MapReduce 或者 Hive 很难做到低延迟，用 Storm 开发的实时流处理技术可以帮助解决延迟性的问题，但它并不完美
Storm 不支持 exactly-once 语义，因此不能保证状态数据的正确性
Storm 不支持基于事件时间的处理
后来出现了一种混合分析的方法，它将上述两个方案结合起来，既保证低延迟，又保障正确性 ——Lambda
Lambda 架构是由 Storm 的作者 Nathan Marz 提出的一个实时大数据处理框架
Marz 在 Twitter 工作期间开发了著名的实时大数据处理框架 Storm，Lambda 架构是其根据多年进行分布式大数据系统的经验总结提炼而成
Lambda 的目标:
- 高容错、低延时、可扩展
Lambda 特性
整合离线计算和实时计算
读写分离和复杂性隔离
可集成 Hadoop，Kafka，Storm，Spark，HBase 等
Marz 认为大数据系统应具有以下的关键特性（Lambda 架构的关键特性）：
Robust and fault-tolerant（容错性和鲁棒性）：让系统从错误中快速恢复
Low latency reads and updates（低延时）：响应是低延时
Scalable（横向扩容）：通过增加机器的个数来提高系统的性能
General（通用性）：支持多领域的数据分析（金融、社交、电子商务等）
Extensible（可扩展）：以最小的开发代价来增加新功能
Allows ad hoc queries（方便查询）：即时查询，快速简便的进行查询
Debuggable（易调试）：快速定位错误
Lambda 架构通过分解的三层架构来解决问题
Batch Layer
Speed Layer
Serving Layer
Batch Layer
理想状态下，任何数据查询都可以从表达式 Query= function (all data) 获得，但是若数据达到相当大的一个级别（例如 PB），且还需要支持实时查询时，就需要耗费非常庞大的资源
可以将数据提前进行计算处理成为 Batch View，这样当需要执行查询时，可以从 Batch View 中读取结果。这样一个预先运算好的 View 是可以建立索引的，因而可以支持随机读取
Batch Layer 总结为：
Batch View = function(all data)
Query = function(BatchView)
Speed Layer
Batch Layer 的离线处理可以很好的满足大多数应用场景，但有很多场景的数据是不断实时生成，并且需要实时查询处理。Speed Layer 正是用来处理增量的实时数据并生成 Realtime View
Speed Layer 处理的数据是最近的增量数据流，Batch Layer 处理的是全体数据集
Speed Layer 为了效率，接收到新数据时不断更新 Realtime View，而 Batch Layer 根据全体离线数据集直接得到 Batch View
Speed Layer 是一种增量计算，所以延迟小
Speed Layer 总结为：
- RealtimeView＝function(RealtimeView，new data)
Batch Layer 和 Speed Layer 优点：
容错性：Speed Layer 中处理的数据也不断写入 Batch Layer，当 Batch Layer 中重新计算的数据集包含 Speed Layer 处理的数据集后，当前的 Realtime View 就可以丢弃，这也就意味着 Speed Layer 处理中引入的错误，在 Batch Layer 重新计算时都可以得到修正。这点也可以看成是 CAP 理论中的最终一致性（Eventual Consistency）的体现
复杂性隔离：Batch Layer 处理的是离线数据，可以很好的掌控。Speed Layer 采用增量算法处理实时数据，复杂性比 Batch Layer 要高很多。通过分开 Batch Layer 和 Speed Layer，把复杂性隔离到 Speed Layer，可以很好的提高整个系统的鲁棒性和可靠性
Query = function( Batch View , Realtime View )
Realtime View = function( Realtime View , new data )
Batch View = function( all data )
Serving Layer
用于响应用户的查询请求，合并 Batch View 和 Realtime View 中的结果数据集到最终的数据集
Kappa 架构
Lambda 架构有时会出现批量数据和实时数据结果对不上的问题
LinkedIn 的 Jay Kreps 提出了一个新的架构：KAPPA
它的理念是：鉴于大家认为批量数据和实时数据对不上是个问题，它直接去掉了批量数据；而直接通过队列（Kafka），放入实时数据之中。
例如：将所有的数据直接放到原来的 Kafka 中，然后通过 Kafka 的 Streaming，去直接面向查询
该架构也存在着一些问题：
不能及时查询和训练。例如：我们的分析师想通过一条 SQL 语句，来查询前五秒的状态数据。这对于 KAPPA 架构是很难去实现的
面对各种需求，它同样也逃不过每次需要重新做一次 Data Streaming。也就是说，它无法实现 Ad—hoc 查询，我们必需针对某个需求事先准备好，才能进行数据分析
新数据源的结构问题。例如：要新增一台智能硬件设备，我们就要重新开发一遍它对应的适配格式、负责采集的 SDK、以及 SDK 的接收端等，即整体都要重复开发一遍
IOTA 架构
IOTA 架构整体思路
设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的预算效率，同时满足即时计算的需要，可以使用各种 Ad-hoc Query 来查询底层数据
- Common Data Model（核心）：从数据收集到数据存储和处理使用统一的数据模型
“主 - 谓 - 宾”、“对象 - 事件”、“产品 - 事件”、“地点 - 时间” 模型等等
例，“X 用户 – 事件 1 – A 页面（2018/4/11 20:00）
SDKs：数据的采集端，不仅仅是过去的简单的 SDK，在复杂的计算情况下，会赋予 SDK 更复杂的计算，在设备端就转化为形成统一的数据模型来进行传送
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 端进行控制
