第一代：离线统计分析技术架构
简介
这代架构定位是为了解决传统 BI 的问题
数据分析的业务没有发生任何变化，但是因为数据量、性能等问题导致系统无法正常使用，需要进行升级改造，此类架构便是为了解决这个问题。
架构图
分支主题
分层说明
应用数据层(ADS)
存放数据产品个性化的统计指标数据，主要面向前端展示
汇总数据层(DWS)
又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表采用更多的宽表化手段，构建公共指标数据层
轻度汇总层(DWM)
是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据)
明细数据层(DWD)
采用维度退化的方法，将维度退化到实时表中，减少事实表和维度表的关联，提高明细表偶读易用性
操作数据层(ODS)
存储所有基础数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后(诸如去噪、去重、字段重命名等)，装入本层
预处理层(STAGING)
存储每天的增量数据，表和ods层表一直
维表层(DIM)
高基数维度数据
一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别
低基数维度数据
一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万
优点
简单易懂，对BI系统基本思想没变，变得仅仅是技术选型，用大数据架构替换掉BI组件
缺点
对大数据来说，没有BI下完备的CUBE架构，虽有kylin，但较局限，故对业务支持灵活度不够，对存在大量报表或复杂的场景，需要太多的手工定制化，同时该架构依旧以批处理为主，缺乏实时的支撑
适用场景
数据分析需求依旧以BI场景为主，但是因为数据量性能问题无法满足日常使用
第二代：流式架构
简介
流式的应用场景非常广泛， 比如搜索、推荐、信息流等都是在线化的，对数据实时性的要求变更高，自然计算与使用是同步进行的
随着业务的复杂化，数据的处理逻辑更加复杂，比如各种维度交叉、关联、聚类，以及需要更多算法或机器学习
与第一代的大数据处理框架相比，去掉了原有的 ETL 过程，数据流过数据通道时得到处理，处理结果通过消息的方式推送数据消费者
流式计算框架舍弃了大数据离线批量处理模式，只有很少的数据存储，所以数据保存周期非常短。如果有历史数据场景或很复杂历史数据参与计算的场景，实现起来难度就比较大
缺点
不存在批处理，因此对数据的重播和历史统计无法很好的支撑，对于离线分析进支撑窗口之内的分析
应用场景
事件流、持续计算。事件流，就是业务相对固定，只是数据在业务的规则下不断的变化。
持续计算，适合购物网站等场景
预警、监控、对数据有实时性要求的场景
第三代：Lambda 大数据架构
简介
Lambda 架构是由 Twitter 工程师南森·马茨（Nathan Marz）提出的，是一种经典的、实施广泛的技术架构。后来出现的其他大数据处理架构也是 Lambda 架构的优化或升级版
Lambda 架构的两条数据链路
批量离线处理流在构建时大部分还是采用一些经典的大数据统计分析方法论，在保证数据一致性、完整性的同时还会对数据按照不同应用场景进行分层。
实时流式处理主要是增量计算，也会跑一些机器学习模型等。为了保证数据的一致性， 实时流处理结果与批量处理结果会有一个合并动作
Lambda 架构主要的组成
批处理层 (Bathchlayer) ：
Lambda 架构核心层之一，批处理接收过来的数据，并保存到相应的数据模型中，这一层的数据主题、模型设计的方法论是继承面向统计分析离线大数据中的。而且一般都会按照比较经典的 ODS、DWD、DWB、ST/ADM 的层次结构来划分。
流式处理层 (Speed Layer) ：
Lambda 另一个核心层，为了解决比如各场景下数据需要一边计算一边应用以及各种维度交叉、关联的事件流与持续计算的问题，计算结果在最后与批处理层的结果做合并。
服务层 ( Serving layer) ：
这是 Lambda 架构的最后一层，服务层的职责是获取批处理和流处理的结果，向用户提供统一查询视图服务。
优点
既有实时又有离线，对数据分析场景涵盖的非常到位
缺点
1、数据口径不一致问题
因为离线和实时计算走的是两个完全不同的代码，算出来的结果往往不同，可能会当天看到一个结果数据，第二天发现数据变成了
2、T+1离线严重超时
像新浪微博这种体量的公司，每天有400TB+的数据写入大数据平台，而且数据在不断地增加。我们经常会发现在夜间3-4个小时内，离线程序执行不完，不能保证数据在上班之前准时生成。尤其是在夜间发生故障之后，白天的数据产出时间更加难以把控。
3、需要维护两套代码
每次数据源有变化，或者业务方有新的需求。都要修改两次业务逻辑代码，既要修改离线的ETL任务，又要修改流式任务，开发周期很长（工作量是双倍），人力成本比较大。
第四代：Kappa 大数据架构
简介
解决在 Lamadba 架构下需要维护两套的代码的问题
Kappa 架构核心是通过改进流式计算架构的计算、存储部分来解决全量的问题，使得实时计算、批处理可以共用一套代码
Kappa 架构认为对于历史数据的重复计算几率是很小的，即使需要，可以通过启用不同的实例的方式来做重复计算
核心思想
用 Kafka 或者类似 MQ 队列系统收集各种各样的数据，需要几天的数据量就保存几天。
当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
当新的实例做完后，停止老的流计算实例，并把一些老的结果删除。
优点
解决了lambda架构的冗余部分，以数据可重播的超凡脱俗的死刑进行了设计，整个架构非常简洁
缺点
Lambda 架构需要维护两套跑在批处理和实时流上的代码，两个结果还需要做 merge， Kappa 架构下只维护一套代码，在需要时候才跑全量数据。
Kappa 架构下可以同时启动很多实例来做重复计算，有利于算法模型调整优化与结果对比，Lamabda 架构下，代码调整比较复杂。所以 kappa 架构下，技术人员只需要维护一个框架就可以，成本很小。
kappa 每次接入新的数据类型格式是需要定制开发接入程序，接入周期会变长。
Kappa 这种架构过度依赖于 Redis、Hbase 服务，两种存储结构又不是满足全量数据存储的，用来做全量存储会显得浪费资源。
第五代：Unified 大数据架构
简介
以上的这些架构都围绕大数据处理为主，Unifield 架构则更激进，将机器学习和数据处理整合为一体
Unifield 在 Lambda 基础上进行升级，在流处理层新增了机器学习层
数据经过数据通道进入数据湖，新增了模型训练部分，并且将其在流式层进行使用，同时流式层不单使用模型，也包含着对模型的持续训练
优点
提供一套数据分析和机器学习结合的机构方案，非常好的解决了机器学习如何与数据平台进行结合的问题
缺点
实施复杂度更高，对于机器学习架构来说，从软件包到硬件部署都和数据分析平台有非常大的差别，实施难度系数更高
使用场景
有着大量数据需要分析，同时对机器学习方便又有非常大的需求或者规划
第六代：IOTA 架构
简介
这个概念由易观于 2018 年首次提出，IOTA 大数据架构是一种基于 AI 生态下的、全新的数据架构模式
IOTA 的整体思路是设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的计算效率，同时满足计算的需要，可以使用各种 Ad-hoc Query 来查询底层数据
特点
去 ETL 化：
ETL 和相关开发一直是大数据处理的痛点，IOTA 架构通过 Common Data Model 的设计，专注在某一个具体领域的数据计算，从而可以从 SDK 端开始计算，中央端只做采集、建立索引和查询，提高整体数据分析的效率。
Ad-hoc 即时查询:
鉴于整体的计算流程机制，在手机端、智能 IOT 事件发生之时，就可以直接传送到云端进入 real time data 区，可以被前端的 Query Engine 来查询。此时用户可以使用各种各样的查询，直接查到前几秒发生的事件，而不用在等待 ETL 或者 Streaming 的数据研发和处理。
边缘计算：
将过去统一到中央进行整体计算，分散到数据产生、存储和查询端，数据产生既符合 Common Data Model。同时，也给与 Realtime model feedback，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。
优点
去ETL话、支持ad-hoc即时查询和边缘计算
缺点
代码漏洞较多，通过收费方式向社区提供漏洞修复代码
