抱歉,您的浏览器无法访问本站

本页面需要浏览器支持(启用)JavaScript


了解详情 >

在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端进行控制

留言区