常见的Hadoop大数据架构介绍常见的Hadoop大数据架构介绍

1. 概述随着互联网的快速普及，全球数据呈现出快速增长、海量集聚的特点。运用大数据技术对这些数据进行分析，使得人们的生产生活方式都发生了许多变化。数据分析虽然隐藏在业务系统背后，但是其在大数据技术体系中具有非常重要的作用，数据分析的结果对公司决策、业务发展、企业战略定位有着举足轻重的作用。随着大数据技术的发展，数据挖掘、数据分析与数据探索等关注度越来越高，但是在Hadoop、Spark、Storm等大数据应用与分析平台之前，数据分析工作已经经历了比较长时间的发展和变化，尤其是以商业智能（BI：Business Intelligence，以下简称为BI系统）系统为主的数据分析，已经具备非常成熟和稳定的解决方案和业务生态系统，常用的BI系统有Microsoft PowerBI、Oracle BI、Informatica、Pentaho BI Server、FineBI等，对于BI系统来说，大概的架构图如下：

文章图片
传统数据仓库架构可以看到在BI系统里面，核心的模块是Cube模块，Cube模块在BI系统中是一个更高层的业务模型抽象，在Cube之上可以进行多种操作，例如上钻（Drill UP）、下钻（Drill Down）、切片（Sharding）等操作。大部分商业智能（BI）系统都基于关系型数据库（如Oracle、DB2、MySQL、SQLServer等），关系型数据库使用SQL语句进行操作，但是SQL在多维操作和分析的表示能力上相对较弱，所以Cube有自己独有的查询语言MDX(Multi Dimensional Expressions: 多维表达式)，MDX表达式具有更强的多维表现能力，所以以Cube为核心的分析系统基本占据着数据统计分析的半壁江山，大多数的数据库服务厂商直接提供了BI套装软件服务，轻易便可搭建出一套OLAP（Online Analysis Processing，联机分析处理）分析系统。不过BI的问题也随着时间的推移逐渐显露出来：

BI系统更多的以分析业务数据产生的密度高、价值高的结构化数据为主，对于非结构化和半结构化数据的处理能力非常有限，例如图片、文本、文件、音频和视频。
由于数据仓库为结构化存储，在数据从其他系统进入数据仓库这个东西，我们通常叫做ETL过程，ETL动作和业务进行了强绑定，通常需要一个专门的ETL团队去和业务做衔接，决定如何进行数据的清洗和转换。
随着异构数据源的增加，例如如果存在视频，文本，图片等数据源，要解析数据内容进入数据仓库，则需要非常复杂等ETL程序，从而导致ETL变得过于庞大和臃肿。
当数据量过大的时候，性能会成为瓶颈，在TB/PB级别的数据量上表现出明显的吃力。
受制于数据库的设计范式等的规则约束，传统关系型数据库主要用于解决数据冗余的问题，是为了保障数据的一致性，但对于数据仓库来说，我们并不需要保障数据的一致性，原则上来说数据仓库的原始数据都是只读的，所以关系型数据库的这些约束反而会成为影响性能的因素。
ETL操作需要对数据进行预先假设和处理，导致机器学习部分获取到的数据为假设后的数据，因此机器学习的效果不太理想，学习结果偏离实际的应用情况。如果需要使用数据仓库对异常数据进行挖掘，则在数据未经ETL操作前就需要明确定义待提取的特征数据，否则无法结构化入库，然而大多数情况是需要基于异构数据才能提取出特征。

在上述所陈述的问题下，以Hadoop体系为首的大数据技术平台逐渐表现出其在数据挖掘、数据分析和数据存储方面的优越性，围绕Hadoop体系的大数据生态系统也在不断的扩大，对于Hadoop系统来说，从根本上解决了传统数据仓库的性能瓶颈的问题，但是也给企业带来一定的困惑：

从传统的数据仓库架构升级到大数据架构，由于数据存储架构、数据分析架构、数据应用架构等结构的异同，决定了应用之间的过渡需要一个演进过程，数据仓库可以做为数据源到大数据体系中的分布式系统中做计算，分布式系统作为数据仓库的计算引擎为数据分析提供计算，分布式系统将聚合数据/计算结果导出到数据仓库中。
大数据体系下的分布式存储强调数据的只读性而忽略了数据的可写性，所以类似于Hive、HDFS、HBASE这些存储方式都不支持更新操作，如HDFS的写操作不支持并行写操作，这些特性导致其具有一定的局限性。

基于大数据架构的数据分析平台侧重于从以下几个维度去解决传统数据仓库做数据分析面临的瓶颈：

分布式存储：所谓的分布式存储，指的是将一个大的文件拆成N个小文件，并将小文件存储在不同的存储单元中，因此这就涉及到文件的副本、分区、分片以及管理等操作，分布式存储主要优化的动作都在文件的分布式管理上。
分布式计算：分布式计算的核心思想是让多个计算节点并行计算，从而提高数据计算的效率，分布式计算强调数据的本地性，即计算的数据来自于本地存储的数据，尽可能的减少数据的传输，减少网络带宽资源的消耗，例如Spark通过RDD的形式来表现数据的计算逻辑，可以在RDD上做一系列的优化，以此来减少数据的传输。
检索和存储的结合：在早期的大数据应用组件中，存储和计算组件相对比较单一，但如今更多的应用方向是在数据存储上提供更多的应用功能，让查询和计算更加便捷、高效，对于计算来说高效不外乎就是数据检索效率高、读取速度快，所以目前的数据存储不单单的存储数据内容，同时会添加很多元数据信息，例如索引信息。
数据路由：分区分库分表等分布式存储操作之后，记录这些结构信息，并做高可用管理，提供给应用程序的是路由功能。使得应用系统进来的查询请求得以分配到合理的数据节点上计算。

2. 常见的大数据架构总的来说，目前围绕Hadoop体系的大数据架构大概有以下几种：

文章图片
常见的大数据架构下面将对这五种常见的大数据架构进行介绍。
传统大数据架构

文章图片
传统架构我们之所以称之为传统大数据架构，是因为其目标定位是为了解决传统BI所存在的问题，简单来说，基本的数据分析业务没有发生任何本质上的变化，但是因为数据量越来越大、性能越来越低等问题导致BI系统无法正常使用，因此需要进行升级改造，那么传统的大数据架构便是为了解决这些问题（大数据量存储、提高应用系统等）。可以看到，其依然保留了ETL（抽取、转换、加载）的动作，将数据经过ETL数据采集操作进入数据存储。

优点：简单、易懂，对于BI系统来说，基本思想没有发生变化，变化的仅仅是技术选型，用大数据架构替换掉BI的组件。
缺点：对于大数据来说，没有BI下如此完备的Cube架构，虽然目前有kylin，但是kylin的局限性非常明显，远远没有BI下的Cube的灵活度和稳定度，因此对业务支撑的灵活度不够，所以对于存在大量报表，或者复杂的钻取的场景，需要太多的手工定制化，同时该架构依旧以批处理为主，缺乏实时的支撑。
适用场景：数据分析需求依旧以BI场景为主，但是因为数据量、性能等问题无法满足日常使用。

流式架构

文章图片
流式架构在传统大数据架构的基础上，流式架构非常激进，直接取消了批处理操作，数据全程以数据流的方式进行处理，所以在数据接入端没有了ETL操作，转而替换为数据通道（Data Channel）。经过流处理加工后的数据，通过消息中间件（如Kafka）以消息的形式直接推送给了消费者。虽然有一个存储部分，但是该存储更多的以窗口的形式进行存储，所以该存储并非发生在数据湖，而是在外围系统。

优点：没有臃肿的ETL过程，数据的实效性非常高。
缺点：对于流式架构来说，不存在批处理，因此对于数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。
适用场景：预警，监控，对数据有有效期要求的情况。

Lambda架构

文章图片
Lambda架构 Lambda架构算是大数据系统里面举足轻重的架构，大多数架构基本都是Lambda架构或者基于其变种的架构。Lambda的数据通道分为两条分支：实时流和离线。实时流依照流式架构，保障了其实时性，而离线则以批处理方式为主，保障了最终一致性。什么意思呢？流式通道处理为保障实效性更多的以增量计算为主辅助参考，而批处理层则对数据进行全量运算，保障其最终的一致性，因此Lambda最外层有一个实时层和离线层合并的动作，此动作是Lambda里非常重要的一个动作，大概的合并思路如下：

文章图片
层次合并思路

优点：既有实时又有离线，对于数据分析场景涵盖的非常到位。
缺点：离线层和实时流虽然面临的场景不相同，但是其内部处理的逻辑却是相同，因此有大量荣誉和重复的模块存在。
适用场景：同时存在实时和离线需求的情况。

Kappa架构

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

优点：Kappa架构解决了Lambda架构里面的冗余部分，以数据可重播的超凡脱俗的思想进行了设计，整个架构非常简洁。
缺点：虽然Kappa架构看起来简洁，但是施难度相对较高，尤其是对于数据重播部分。
适用场景：和Lambda类似，改架构是针对Lambda的优化。

Unifield架构

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