传统的数据处理流程(离线计算),先收集数据,然后将数据存储到数据库中。当需要某些数据时,通过对数据库中的数据做操作得到所需要的数据,再进行其他相关的处理。这样的处理流程会造成结果数据密集,结果数据密集则数据反馈不及时。
在数字孪生的应用场景中,需要实时数据做决策,而传统的数据处理并不能很好地解决问题,这就引出了一种新的数据实时计算,针对海量数据进行实时计算,无论是在数据采集还是数据处理中都可以达到秒级别的处理要求。
一. 实时计算架构
实时计算具有三个特征:
- 无限数据:无限数据指的是一种不断增长的,基本上无限的数据集。这些通常被称为“流数据”,而与之相对的是有限的数据集。
- 无界数据处理:一种持续的数据处理模式,能够通过处理引擎重复的去处理上面的无限数据,是能够突破有限数据处理引擎的瓶颈的。
- 低延迟:延迟是多少并没有明确的定义。但我们都知道数据的价值将随着时间的流逝降低,时效性将是需要持续解决的问题。
现在大数据应用比较火爆的领域,比如推荐系统在实践之初受技术所限,可能要一分钟,一小时,甚至更久对用户进行推荐,这远远不能满足需要,为了更快的完成对数据的处理,而不是进行离线的批处理,在传统大数据离线数仓的基础上,逐渐对数据的实时性提出了更高的要求。
于是随之诞生了大数据实时数仓,并且衍生出了两种技术架构Lambda和Kappa。
1.1 Lambda架构
数据从底层的数据源开始,经过Kafka、Flume等数据组件进行收集,然后分成两条线进行计算:
- 一条线是进入流式计算平台(例如 Storm、Flink或者SparkStreaming),去计算实时的一些指标;
- 另一条线进入批量数据处理离线计算平台(例如Mapeduce、Hive,Spark SQL),去计算T+1的相关业务指标,这些指标需要隔日才能看见。
在 Lambda 架构中,每层都有自己所肩负的任务。
- 批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图:
批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的,能够修复任何错误,然后更新现有的数据视图。输出通常存储在只读数据库中,更新则完全取代现有的预先计算好的视图。
- 流处理层会实时处理新来的大数据:
流处理层通过提供最新数据的实时视图来最小化延迟。流处理层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整,但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后,在速度层的数据就可以被替代掉了。
Lambda架构的缺点
- 使用两套大数据处理引擎:维护两个复杂的分布式系统,成本非常高。比如加工逻辑Double,开发运维也会Double,资源同样会变成两个资源链路。
- 批量计算在计算窗口内无法完成:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
- 数据源变化都要重新开发,开发周期长:每次数据源的格式变化,业务的逻辑变化都需要针对ETL和Streaming做开发修改,整体开发周期很长,业务反应不够迅速。
1.2 Kappa架构
Kafka的创始人Jay Kreps认为在很多场景下,维护一套Lambda架构的大数据处理平台耗时耗力,于是提出在某些场景下,没有必要维护一个批处理层,直接使用一个流处理层即可满足需求,即下图所示的Kappa架构:
这种架构只关注流式计算,数据以流的方式被采集过来,实时计算引擎将计算结果放入数据服务层以供查询。可以认为Kappa架构是Lambda架构的一个简化版本,只是去除掉了Lambda架构中的离线批处理部分;
Kappa架构相对更简单,实时性更好,所需的计算资源远小于Lambda架构,随着实时处理的需求在不断增长,更多的企业开始使用Kappa架构。
Kappa架构的缺点
- 部分业务实时与离线分析应用本身口径有差异:在准确性、扩展性和容错性上,流处理层无法完全取代批处理层,只能给用户提供一个近似结果
- 适用场景通用性不强:对于一些比较复杂的场景,批处理与流处理产生不同的结果(使用不同的机器学习模型,专家系统,或者实时计算难以处理的复杂计算)
- 大数据量的回溯成本高,生产压力大
Lambda和kappa架构都有各自的适用领域;例如流处理与批处理分析流程比较统一,且允许一定的容错,用Kappa比较合适,少量关键指标(例如交易金额、业绩统计等)使用Lambda架构进行批量计算,增加一次校对过程。
二. 业界常见的实时数据仓库实现方案
介绍实时数仓前,先回顾下离线数仓的分层架构,这将对我们后面理解实时数仓架构设计具有很大帮助。
数仓一般分为:ODS层、DWD层、DWS层和ADS层。
1)ODS层:ODS是数据接入层,所有进入数据的数据首先会接入ODS层。一般来说ODS层的数据是多复杂多样的。从数据粒度上看ODS层是粒度最细的数据层。
2)DWD层:为数据仓库层,数据明细层的数据应是经过ODS清洗,转后的一致的、准确的、干净的数据。DWD层数据粒度通常和ODS的粒度相同,不同的是该层的数据质量更高,字段更全面等。在数据明细层会保存BI系统中所有的历史数据,例如保存近10年来的数据。
3)DWS层:数据汇总层,该层数据是面向主题来组织数据的,通常是星形或雪花结构的数据。从数据粒度来说,这层的数据是轻度汇总级的数据,已经不存在明细数据了。
4)ADS层:数据应用层,它是完全为了满足具体的分析需求而构建的数据,也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。其汇总的目标主要是按照应用需求进行的。
数仓分层的总体思路是用空间换时间,其目的是通过数仓分层,使得数仓能够更好地应对需求的变更,和提高数据的稳定性。
1)用空间换时间:通过大量的预处理来提升应用系统的用户体验(效率),因此数据仓库会存在大量冗余的数据。
2)能更好地应对需求的变更:如果不分层的话,如果源业务系统的业务规则发生变化,将会影响整个数据清洗过程,工作量巨大。
3)提高数据处理过程的稳定性:通过数据分层管理可以简化数据清洗的过程,因为把原来一步的工作分到了多个步骤去完成,相当于把一个复杂的工作拆成了多个简单的工作,每一层的处理逻辑都相对简单和容易理解。
这样比较容易保证每一个步骤的正确性,当数据发生错误的时候,往往只需要局部调整某个步骤即可。
目前老的项目大部分还在使用的标准分层体现+流计算+批量计算(lambda)的方案。标准分层体系+流计算+数据湖的设计是演进的趋势。
2.1 基于Kappa架构
将多源数据(用户日志,系统日志,BinLog日志)实时地发送到Kafka。
然后通过Flink集群,按照不同的业务构建不同的流式计算任务,对数据进行数据分析和处理,并将计算结果输出到MySQL/ElasticSearch/HBase/Druid/KUDU等对应的数据源中,最终提供应用进行数据查询或者多维分析。
其优缺点见1.2节。
2.2 基于标准分层 + 流计算
在传统数仓的分层标准上构建实时数仓,将数据分为ODS、DWD、DWS、ADS层。首先将各种来源的数据接入ODS贴源数据层,再对ODS层的数据使用Flink的实时计算进行过滤、清洗、转化、关联等操作,形成针对不同业务主题的DWD数据明细层,并将数据发送到Kafka集群。
之后在DWD基础上,再使用Flink实时计算进行轻度的汇总操作,形成一定程度上方便查询的DWS轻度汇总层。最后再面向业务需求,在DWS层基础上进一步对数据进行组织进入ADS数据应用层,业务在数据应用层的基础上支持用户画像、用户报表等业务场景。
优点:
- 各层数据职责清晰
缺点
- 多个Flink集群维护起来复杂
- 运算负载较高
- 不支持upsert(update or insert)操作
- Schema维护麻烦
2.3 基于标准分层体现 + 流计算 + 批量计算
为了解决方案2不支持upsert和schema维护复杂等问题。有在方案2的基础上加入基于HDFS加 Spark离线的方案。也就是离线数仓和实时数仓并行流转的方案。
2.4 基于标准分层体系 + 流计算 + 数据湖
为了解决数据质量管理和upset 问题。出现了流批一体架构,这种架构基于数据湖三剑客 Delta Lake / Hudi / Iceberg 实现 + Spark 实现。
以Iceberg为例介绍下这种方案的架构。Iceberg具有以下优点:
1、同时支持流式写入和增量拉取。
2、解决小文件多的问题。数据湖实现了相关合并小文件的接口,Spark / Flink上层引擎可以周期性地调用接口进行小文件合并。
3、支持批量以及流式的 Upsert(Delete) 功能。批量Upsert / Delete功能主要用于离线数据修正。流式upsert场景前面介绍了,主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的,而离线数仓做更新的话需要全量数据覆盖,这也是离线数仓做不到实时的关键原因之一,数据湖是需要解决掉这个问题的。
4、ceberg 还支持比较完整的OLAP生态。比如支持Hive / Spark / Presto / Impala 等 OLAP 查询引擎,提供高效的多维聚合查询性能。
从下图可以看到这方案和前面的方案2很相似,只是在数据存储层将Kafka换为了Iceberg。
特点:
1、在编程上将流计算和批计算统一到同一个SQL引擎上,基于同一个Flink SQL既可以进行流计算,也可以进行批计算。
2、将流计算和批计算的存储进行了统一,也就是统一到Iceberg/HDFS上,这样数据的血缘关系的和数据质量体系的建立也变得简单了。
3、由于存储层统一,数据的Schema也自然统一起来了,这样相对流批单独两条计算逻辑来说,处理逻辑和元数据管理的逻辑都得到了统一。
4、数据中间的各层(ODS、DWD、DWS、ADS)数据,都支持OLAP的实时查询。
2.5 基于全场景MPP(Massively Parallel Processing)数据库实现
前面的四种方案,是基于数仓方案的优化。方案比较复杂。
以Doris(StartRocks)和ClickHouse为代表的全场景MPP数据库,既能满足海量数据的存储,也能实现快速分析。比较适合多维度数据的自助分析。
1、基于Doris或者ClickHouse构建实时数仓。来看下具体的实现方式:将数据源上的实时数据直接写入消息服务。
2、对于数据源为离线文件的情况有两种处理方式,一种是将文件转为流式数据写入Kafka,另外一种情况是直接将文件通过SQL导入ClickHouse集群。
3、ClickHouse接入Kafka消息并将数据写入对应的原始表,基于原始表可以构建物化视图、Project等实现数据聚合和统计分析。
4、应用服务基于ClickHouse数据对外提供BI、统计报表、告警规则等服务。
三. 相关工具
3.1 数据储存
MPPDB、HDFS与传统数据库技术对比与适用场景
MPPDB与HDFS都是将运算分布到节点中独立运算后进行结果合并(分布式计算),但由于依据的理论和采用的技术路线不同而有各自的优缺点和适用范围。两种技术以及传统数据库技术的对比如下:
综合而言,Hadoop HDFS和MPP两种技术的特定和适用场景为:
- Hadoop HDFS在处理非结构化和半结构化数据上具备优势,尤其适合海量数据批处理等应用要求。
- MPP适合替代现有关系数据机构下的大数据处理,具有较高的效率。
MPP适合多维度数据自助分析、数据集市等;Hadoop HDFS适合海量数据存储查询、批量数据ETL、非机构化数据分析(日志分析、文本分析)等。
大数据分析一般是基于历史海量数据,多维度分析,我们不能直接在原始的业务数据库上直接操作,因为分析的一些复杂SQL查询会明显的影响业务数据库的效率,导致业务系统不可用。所以通常通过数据库采集系统直接与企业业务后台数据库服务器结合,在业务不那么繁忙的凌晨,抽取我们想要的数据,最后有大数据处理系统对这些数据进行清洗、组合进行数据分析。
毋庸置疑,HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
HDFS(Hadoop分布式文件系统)的设计目标是管理数以千计的服务器、数以万计的磁盘,将大规模的服务器计算资源当作一个单一存储系统进行管理,对应用程序提供数以PB计的存储容量,让应用程序像使用普通文件系统一样存储大规模的文件数据。其具有以下特点:
- 文件数据以数据块的方式进行切分,数据块可以存储在集群任意DataNode服务器上,所以HDFS存储的文件可以非常大,一个文件理论上可以占据整个HDFS服务器集群上的所有磁盘,实现了大容量存储。
- HDFS一般的访问模式是通过MapReduce程序在计算时读取,MapReduce对输入数据进行分片读取,通常一个分片就是一个数据块,每个数据块分配一个计算进程,这样就可以同时启动很多进程对一个HDFS文件的多个数据块进行并发访问,从而实现数据的高速访问。关于MapReduce的具体处理过程,我们会在专栏后面详细讨论。
- DataNode存储的数据块会进行复制,使每个数据块在集群里有多个备份,保证了数据的可靠性,并通过一系列的故障容错手段实现HDFS系统中主要组件的高可用,进而保证数据和整个系统的高可用。
3.2 数据采集
多源异构数据采集的大数据技术栈,目前广泛的是 Sqoop、Datax。
- DataX
阿里巴巴开源的一个异构数据源离线同步工具,致力于实现包括关系型数据库(MySQL、Oracle 等)、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能。DataX 在设计之初就将同步理念抽象成框架+插件的形式.框架负责内部的序列化传输,缓冲,并发,转换等而核心技术问题,数据的采集(Reader)和落地(Writer)完全交给插件执行。
- Read 数据采集模块,负责采集数据源的数据,将数据发送至 FrameWork。
- Writer 数据写入模块,负责不断的向 FrameWork 取数据,并将数据写入目的端。
- FrameWork 用于连接 reader 和 write,作为两者的数据传输通道,处理缓冲,流控,并发,转换等核心技术问题。
- Sqoop
- Apache开源软件:Sqoop是一款开源的工具,主要用于在 Hadoop、Hive 与传统的数据库(MySql)间进行数据的传递,可以将一个关系型数据库中的数据导进到 Hadoop 的 HDFS 中,也可以将 HDFS 的数据导进到关系型数据库中。
- Sqoop 工具接收到客户端的 shell 命令或者 Java api 命令后,通过 Sqoop 中的任务翻译器将命令转换为对应的 MapReduce 任务,而后将关系型数据库和 Hadoop 中的数据进行相互转移,进而完成数据的拷贝。
小结
- Sqoop依赖于Hadoop生态对HDFS、Hive支持友善,在处理数仓大表的速度相对较快,但不具备统计和校验能力。
- DataX无法分布式部署,可以在传输过程中进行过滤,并且可以统计传输数据的信息,因此在业务场景复杂(表结构变更)更适用,同时对于不同的数据源支持更好。
- 且DataX的开源版本目前只支持单机部署,需要依赖调度系统实现多客户端,同时不支持自动创建表和分区。
3.3 批处理计算
- MapReduce(Hadoop)
MapReduce就是指我们常说的Hadoop MapReduce,它是一个批处理计算引擎。每个MapReduce任务都包含两个过程:Map过程和Reduce过程。
- - Map阶段:多台机器同时读取一个文件的各个部分,分别统计词频,产生多个Map集合;
- - Reduce阶段:接收所对应的Map集合结果,将相同键的集合汇总,进而得到整个文件的词频结果;
MapReduce的缺点是每个map阶段结束时,都需要将中间结果写到磁盘,reduce阶段继续从磁盘读取数据进行下一步的处理。这个过程会产生大量的数据I/O,导致处理效率比较低。
- Spark
与Hadoop MapReduce不同的是,Spark是基于内存的批处理计算引擎。SparkSpark及其组件已经形成了一个大数据生态,Spark基于这个引擎,提供了很多的高级应用模块解决不同场景中的业务需求。Spark分为Spark Core、SparkSQL、SparkStreaming、GraphX以及MLLib等,SparkCore为Spark的核心和基础,提供基本的批处理功能,其他的每个组件专注于不同的处理任务。
3.4 流数据计算
- Apache Spark Streaming
Apache Spark Streaming即Apache公司免费、开源的实时计算框架。它主要是把输入的数据按时间进行切分,并对切分的数据块进行并行计算处理,处理的速度可以达到秒级别。Netflix公司通过Kaka和SparkStreaming构建了实时引擎,对每天从各种数据源接收到的数十亿数据进行分析,从而完成电影的推荐功能。
- Apache Storm
Apache Storm即Twitter公司免费、开源贡献给Apache的一个分布式实时计算系统。它可以简单、高效、可靠地实时处理海量数据,处理数据的速度达到毫秒级别,并可将处理后的结果数据保存到持久化介质中(如数据库、HDFS)。阿里巴巴公司的Jstorm,就是参考ApacheStorn开发的实时计算框架,可以说是Stom的增强版本,在网络IO、线程模型、资源调度、可用性及稳定性上都做了极大的改进供很多企业使用。
- Apache Flink
Apache Flink即Apache公司开源的计算框架。它不仅可以支持离线处理,还可以支持实时处理。由于离线处理和实时处理所提供的SLA(服务等级协议)是完全不相同的,所以离线处理一般需要支持低延迟的保证,而实时处理则需要支持高吞吐、高效率的处理。
- Yahoo! S4(Simple Scalable Streaming System)
Yahoo! S4即Yahoo公司开源的实时计算平台,通用的、分布式的、可扩展的,并且还具有容错和可插拔能力,供开发者轻松地处理源源不断产生的数据。
3.5 图计算
图计算主要将客观世界中事物间关系完整地刻画、计算和分析的一门技术。它可以用于银行对于不良贷款的预测,也可以用于网站大数据分析推荐等功能。图算法有很多种,每一种算法都有其实际的应用场景。常见的图算法有PageRank、最短路径、社群发现等算法。
图计算有两种模型的计算框架:
- 一种是基于同步的BSP模型(Bulk Synchronous Parallel Computing Model,整体同步并行计算模型)的GraphX和Giraph,优势在于可以提升数据处理的吞吐量和规模,但在速度会稍逊一筹。
- 另一种是基于MPI模型的异步图计算模型GraphLab。GraphLab主要面向机器学习/数据挖掘问题:针对很多这类算法需要在稀疏数据上进行迭代式计算的特点,通过多种级别的一致性来保证算法的收敛效率。
文章评论