前言

　　数据分析工作虽然隐藏在业务系统背后，但是具有非常重要的作用，数据分析的结果对决策、业务发展有着举足轻重的作用。随着大数据技术的发展，数据挖掘、数据探索等专有名词曝光度越来越高，但是在类似于Hadoop系列的大数据分析系统大行其道之前，数据分析工作已经经历了长足的发展，尤其是以BI系统为主的数据分析，已经有了非常成熟和稳定的技术方案和生态系统，对于BI系统来说，大概的架构图如下：
image.png

1. 传统大数据架构

点击查看【processon】
之所以叫传统大数据架构，是因为其定位是为了解决传统**BI**的问题，简单来说，数据分析的业务没有发生任何变化，但是因为数据量、性能等问题导致系统无法正常使用，需要进行升级改造，那么此类架构便是为了解决这个问题。可以看到，其依然保留了ETL的动作，将数据经过ETL动作进入数据存储。

2. 流式架构

点击查看【processon】
流式架构在大数据中应用十分广泛，在传统大数据架构的基础上，流式架构非常激进，直接取消了批处理操作，数据全程以数据流的方式进行处理，所以在数据接入端没有了ETL操作，转而替换为数据通道。而流式架构的优点十分明显，流式架构的优点就是没有十分麻烦的ETL过程，数据的实效性非常高。当然，流式架构的缺点也是十分明显的，那就是对于流式架构来说，不存在批处理，因此对于数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。经过流处理加工后的数据，通过消息中间件以消息的形式直接推送给了消费者。虽然有一个存储部分，但是该存储更多的以窗口的形式进行存储，所以该存储并非发生在数据湖，而是在外围系统。正因为如此，流式架构的适用场景就是预警，监控，对数据有有效期要求的情况。这些就是流式架构的主要内容。

3. Lambda架构

Lambda用两套系统，同时保证低延迟和结果准确。这种架构虽然综合了流处理和批处理，支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求。
点击查看【processon】
Lambda架构通过分解的三层架构来解决该问题：Batch Layer，Speed Layer和Serving Layer。
🍀 大数据架构演进 - 图2
在过去Lambda数据架构成为每一个公司大数据平台必备的架构，它解决了一个公司大数据批量离线处理和实时数据处理的需求。一个典型的Lambda架构如下：

1.webp
Lambda架构算是大数据系统里面举足轻重的架构，大多数架构基本都是Lambda架构或者基于其变种的架构。Lambda的数据通道分为两条分支：实时流和离线。实时流依照流式架构，保障了其实时性，而离线则以批处理方式为主，保障了最终一致性。
数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如：Storm、Flink或者Spark Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。

4. Kappa架构

点击查看【processon】
Kappa架构在Lambda 的基础上进行了优化，将实时和流部分进行了合并，将数据通道以消息队列进行替代。因此对于Kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可。
2.webp

5. Unifield架构

以上的种种架构都围绕海量数据处理为主，Unifield架构则更激进，将机器学习和数据处理揉为一体，从核心上来说，Unifield依旧以Lambda为主，不过对其进行了改造，在流处理层新增了机器学习层。可以看到数据在经过数据通道进入数据湖后，新增了模型训练部分，并且将其在流式层进行使用。同时流式层不单使用模型，也包含着对模型的持续训练。
点击查看【processon】

6. IOTA架构

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

大数据架构对比分析

架构 优点 缺点 适用场景
传统大数据架构 简单，易懂，对于BI系统来说，基本思想没有发生变化，变化的仅仅是技术选型，用大数据架构替换掉BI的组件。 对于大数据来说，没有BI下如此完备的Cube架构，虽然目前有kylin，但是kylin的局限性非常明显，远远没有BI下的Cube的灵活度和稳定度，因此对业务支撑的灵活度不够，所以对于存在大量报表，或者复杂的钻取的场景，需要太多的手工定制化，同时该架构依旧以批处理为主，缺乏实时的支撑。 数据分析需求依旧以BI场景为主，但是因为数据量、性能等问题无法满足日常使用。
流式架构 没有臃肿的ETL过程，数据的实效性非常高。 对于流式架构来说，不存在批处理，因此对于数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。 预警，监控，对数据有有效期要求的情况。
Lambda架构 既有实时又有离线，对于数据分析场景涵盖的非常到位。 离线层和实时流虽然面临的场景不相同，但是其内部处理的逻辑却是相同，因此有大量荣誉和重复的模块存在。 同时存在实时和离线需求的情况。
Kappa架构 Kappa架构解决了Lambda架构里面的冗余部分，以数据可重播的超凡脱俗的思想进行了设计，整个架构非常简洁。 虽然Kappa架构看起来简洁，但是施难度相对较高，尤其是对于数据重播部分。 和Lambda类似，改架构是针对Lambda的优化。
Unifield架构 Unifield架构提供了一套数据分析和机器学习结合的架构方案，非常好的解决了机器学习如何与数据平台进行结合的问题。 Unifield架构实施复杂度更高，对于机器学习架构来说，从软件包到硬件部署都和数据分析平台有着非常大的差别，因此在实施过程中的难度系数更高。 有着大量数据需要分析，同时对机器学习方便又有着非常大的需求或者有规划。
IOTA架构 去ETL化、支持Ad-hoc即时查询和边缘计算。 代码漏洞较多，通过收费方式向社区提供漏洞修复代码。 IOTA用于物联网设备，实现万物互联、系统自治。

参考

博客园：收集各大互联网公司大数据平台架构
https://www.cnblogs.com/swordfall/p/11198015.html
51CTO：Lambda架构已死，基于IOTA模型的“秒算平台”架构实践
https://developer.51cto.com/art/201902/592298.htm