CN114281508A - 一种数据批流融合离线计算方法 - Google Patents
一种数据批流融合离线计算方法 Download PDFInfo
- Publication number
- CN114281508A CN114281508A CN202111640119.1A CN202111640119A CN114281508A CN 114281508 A CN114281508 A CN 114281508A CN 202111640119 A CN202111640119 A CN 202111640119A CN 114281508 A CN114281508 A CN 114281508A
- Authority
- CN
- China
- Prior art keywords
- data
- batch
- processing
- scheduling
- nodes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供了一种数据批流融合离线计算方法，所述计算方法包括以下步骤：S1：调度策略及容错→S2：批处理模型平台通过一个底层引擎同时支持流处理和批处理→S4：基于MapReduce编程模型设计，基于MapReduce编程模型，MapReduce提供数据划分和计算任务调度功能。本发明通过统一的批流融合机制充分挖掘流式引擎的性能优势，并通过动态调整执行计划的方式来改善引擎的易用性，具备流计算的低延迟和批计算的高吞吐高稳定性，提供统一编程接口开发两种场景的应用并保证它们的底层执行逻辑是一致的，解决复杂组件重复开发、上下游反压、数据压缩、内存零拷贝等问题，从而能够大大减少开发和维护的成本。
Description
技术领域
本发明涉及分布式数据处理技术领域，尤其涉及一种数据批流融合离线计算方法。
背景技术
过去的十年是企业的IT系统经历了数据量高速膨胀的时期，这些海量的、分散在不同角落的异构离线数据导致了数据资源利用的复杂性和管理的高难度；
目前数据处理调度模式是申请到一个作业所需要的全部资源，然后同时调度这个作业的全部任务，所有的任务之间采取流水线的方式进行通信，批作业也可以采取这种方式，并且在性能上也会有很大的提升；
现有技术存在以下不足：现有的数据处理调度模式在资源分配的时机和粒度上都有一定的差异，导致了调度架构上无法完全统一，需要开发人员维护两套逻辑，且目前调度方式的物理执行计划是静态的，而静态生成物理执行计划存在调优人力成本高、资源利用率低等问题。
发明内容
本发明针对现有技术的不足，提供了一种数据批流融合离线计算方法。
本发明通过以下技术手段实现解决上述技术问题的：一种数据批流融合离线计算方法，所述计算方法包括以下步骤：
S1：调度策略及容错
批流融合作业在任务调度上的不同，故处理作业的多个任务并不需要同时在线，可以根据依赖关系先调度一批任务，等它们结束后再运行另一批；
优选的，批处理通常依赖中间结果的持久化来减小需要重算的任务范围，因此引入了可插拔的Shuffle Service来提供Suffle数据的持久化以支持细粒度的容错恢复。
S2：计算模型及算法
批流融合处理还有个特点是不需要在计算时输出中间结果，只要在结束时输出最终结果，这很大程度上避免了处理多个中间结果的复杂性。
S3：批处理模型
优选的，平台通过一个底层引擎同时支持流处理和批处理，在流处理引擎之上，具有以下机制：
(1)检查点机制和状态机制：用于实现容错、有状态的处理；
(2)水印机制：用于实现事件时钟；
(3)窗口和触发器：用于限制计算范围，并定义呈现结果的时间。
S4：基于MapReduce编程模型设计
本方法的技术原理是基于MapReduce编程模型，MapReduce提供数据划分和计算任务调度功能；
其中，
优选的，数据划分：系统自动将一个作业待处理的大数据划分为很多个数据块，每个数据块对应一个计算任务，并自动调度计算节点来处理相应的数据块；
优选的，计算任务调度：负责分配和调度计算节点(Map节点或Reduce节点)，同时负责监控这些节点的执行状态，并负责Map节点执行的同步控制。
优选的，批处理模型在同一个流处理引擎之上，还存在另一套机制，用于实现高效的批处理：
(1)用于调度和恢复的回溯法；
(2)用于散列和排序的特殊内存数据结构：可以在需要时，将一部分数据从内存溢出到硬盘上；
(3)优化器：尽可能地缩短生成结果的时间。
优选的，数据/代码互定位：为了减少数据通信，一个基本原则是本地化数据处理，即一个计算节点尽可能处理其本地磁盘上所分布存储的数据，这实现了代码向数据的迁移；
优选的，当无法进行这种本地化数据处理时，再寻找其他可用节点并将数据从网络上传送给该节点(数据向代码迁移)，但将尽可能从数据所在的本地机架上寻找可用节点以减少通信延迟。
优选的，系统优化：为了减少数据通信开销，中间结果数据进入Reduce节点前会进行一定的合并处理，一个Reduce节点所处理的数据可能会来自多个Map节点，为了避免Reduce计算阶段发生数据相关性，Map节点输出的中间结果需使用一定的策略进行适当的划分处理，保证相关性数据发送到同一个Reduce节点，此外，系统还进行一些计算性能优化处理，如对最慢的计算任务采用多备份执行、选最快完成者作为结果。
优选的，出错检测和恢复：以低端商用服务器构成的大规模MapReduce计算集群中，节点硬件(主机、磁盘、内存等)出错和软件出错是常态，因此MapReduce需要能检测并隔离出错节点，并调度分配新的节点接管出错节点的计算任务；
优选的，同时，系统还将维护数据存储的可靠性，用多备份冗余存储机制提高数据存储的可靠性，并能及时检测和恢复出错的数据。
优选的，通过对数据批流融合的研究，我们对MapReduce、Tez、Spark和Flink在执行纯批处理任务时的性能进行比较，测试的批处理任务是TeraSort和分布式散列连接。
优选的，TeraSort测试：即测量为1TB数据排序所用的时间，TeraSort本质上是分布式排序问题，它由以下几个阶段组成：
(1)读取阶段：从HDFS文件中读取数据分区；
(2)本地排序阶段：对上述分区进行部分排序；
(3)混洗阶段：将数据按照key重新分布到处理节点上；
(4)终排序阶段：生成排序输出；
(5)写入阶段：将排序后的分区写入HDFS文件；
优选的，数据批流融合方法的排序时间比其他所有系统都少，MapReduce用了2157秒，Tez用了1887秒，Spark用了2171秒，Flink则只用了1480秒；
优选的，对一个大数据集(240GB)和一个小数据集(256MB)之间的分布式散列连接；
优选的，结果显示，数据批流融合方法仍然是速度最快的，它所用的时间分别是Tez和Spark的1/2和1/4。
本发明的有益效果：
本发明通过统一的批流融合机制充分挖掘流式引擎的性能优势，并通过动态调整执行计划的方式来改善引擎的易用性，提高系统的资源利用率的管理需求，具备流计算的低延迟和批计算的高吞吐高稳定性，提供统一编程接口开发两种场景的应用并保证它们的底层执行逻辑是一致的，解决复杂组件重复开发、上下游反压、数据压缩、内存零拷贝等问题，从而能够大大减少开发和维护的成本。
附图说明
图1为本发明的批流融合作业示意图；
图2为本发明流处理引擎的结构示意图；
图3为本发明的TeraSort测试示意图；
图4为本发明的数据处理时间对比示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
需要说明的是，当元件被称为“固定于”另一个元件，它可以直接在另一个元件上或者也可以存在居中的元件。当一个元件被认为是“连接”另一个元件，它可以是直接连接到另一个元件或者可能同时存在居中元件。
现有的数据处理调度模式存在下面的缺点：
1、架构不一致、维护成本高
现有的数据处理调度模式在资源分配的时机和粒度上都有一定的差异，导致了调度架构上无法完全统一，需要开发人员维护两套逻辑；
例如，流的调度模式，其资源分配的粒度是整个物理执行计划的全部任务；批的调度模式，资源分配的粒度是单个任务，当调度程序拿到一个资源的时候，就需要根据作业类型走两套不同的处理逻辑。
2、性能
传统的批调度方式，虽然容错代价比较小，但是引入了大量的磁盘I/O，并且性能也不是最佳，无法发挥出流式引擎的优势；
实际上在资源相对充足的场景下，可以采取“流”的调度方式来运行批量作业，从而避免额外的磁盘I/O，提高作业的执行效率。尤其是在夜间，流作业可以释放出一定资源，这就为批作业按照“流”的方式运行提供了可能。
3、自适应
目前调度方式的物理执行计划是静态的，而静态生成物理执行计划存在调优人力成本高、资源利用率低等问题；
本发明目的是通过引入批流融合离线计算的方法，不管是流作业还是批作业，都是按照管道区域粒度来申请资源和调度任务，从而实现Meta管理、数据传输、服务部署，提供了架构层面的支持，从而避免对复杂组件的重复开发、解决上下游反压、数据压缩、内存零拷贝等问题，大大减少了开发和维护的成本，具体方案如下：
实施例1
请参阅图1所示，本实施例所述一种数据批流融合离线计算方法，具备流计算的低延迟和批计算的高吞吐高稳定性，提供统一编程接口开发两种场景的应用并保证它们的底层执行逻辑是一致的，解决复杂组件重复开发、上下游反压、数据压缩、内存零拷贝等问题，从而能够大大减少开发和维护的成本；
请参阅图1所示，所述计算方法包括以下步骤：
S1：调度策略及容错
批流融合作业在任务调度上的不同，故处理作业的多个任务并不需要同时在线，可以根据依赖关系先调度一批任务，等它们结束后再运行另一批；
批处理通常依赖中间结果的持久化来减小需要重算的任务范围，因此引入了可插拔的Shuffle Service来提供Suffle数据的持久化以支持细粒度的容错恢复。
S2：计算模型及算法
批流融合处理还有个特点是不需要在计算时输出中间结果，只要在结束时输出最终结果，这很大程度上避免了处理多个中间结果的复杂性。
S3：批处理模型
请参阅图2所示，平台通过一个底层引擎同时支持流处理和批处理，在流处理引擎之上，具有以下机制：
(1)检查点机制和状态机制：用于实现容错、有状态的处理；
(2)水印机制：用于实现事件时钟；
(3)窗口和触发器：用于限制计算范围，并定义呈现结果的时间。
S4：基于MapReduce编程模型设计
本方法的技术原理是基于MapReduce编程模型，MapReduce提供数据划分和计算任务调度功能；
其中，
数据划分：系统自动将一个作业待处理的大数据划分为很多个数据块，每个数据块对应一个计算任务，并自动调度计算节点来处理相应的数据块；
计算任务调度：负责分配和调度计算节点(Map节点或Reduce节点)，同时负责监控这些节点的执行状态，并负责Map节点执行的同步控制。
实施例2
实施例2与实施例1的区别在于，批处理模型在同一个流处理引擎之上，还存在另一套机制，用于实现高效的批处理：
(1)用于调度和恢复的回溯法；
(2)用于散列和排序的特殊内存数据结构：可以在需要时，将一部分数据从内存溢出到硬盘上；
(3)优化器：尽可能地缩短生成结果的时间。
实施例3
数据/代码互定位：为了减少数据通信，一个基本原则是本地化数据处理，即一个计算节点尽可能处理其本地磁盘上所分布存储的数据，这实现了代码向数据的迁移；
当无法进行这种本地化数据处理时，再寻找其他可用节点并将数据从网络上传送给该节点(数据向代码迁移)，但将尽可能从数据所在的本地机架上寻找可用节点以减少通信延迟。
实施例4
系统优化：为了减少数据通信开销，中间结果数据进入Reduce节点前会进行一定的合并处理，一个Reduce节点所处理的数据可能会来自多个Map节点，为了避免Reduce计算阶段发生数据相关性，Map节点输出的中间结果需使用一定的策略进行适当的划分处理，保证相关性数据发送到同一个Reduce节点，此外，系统还进行一些计算性能优化处理，如对最慢的计算任务采用多备份执行、选最快完成者作为结果。
实施例5
出错检测和恢复：以低端商用服务器构成的大规模MapReduce计算集群中，节点硬件(主机、磁盘、内存等)出错和软件出错是常态，因此MapReduce需要能检测并隔离出错节点，并调度分配新的节点接管出错节点的计算任务；
同时，系统还将维护数据存储的可靠性，用多备份冗余存储机制提高数据存储的可靠性，并能及时检测和恢复出错的数据。
实施例6
在本实施例中，通过对数据批流融合的研究，我们对MapReduce、Tez、Spark和Flink在执行纯批处理任务时的性能进行比较，测试的批处理任务是TeraSort和分布式散列连接。
TeraSort测试：即测量为1TB数据排序所用的时间，TeraSort本质上是分布式排序问题，它由以下几个阶段组成：
(1)读取阶段：从HDFS文件中读取数据分区；
(2)本地排序阶段：对上述分区进行部分排序；
(3)混洗阶段：将数据按照key重新分布到处理节点上；
(4)终排序阶段：生成排序输出；
(5)写入阶段：将排序后的分区写入HDFS文件；
请参阅图3所示，数据批流融合方法的排序时间比其他所有系统都少，MapReduce用了2157秒，Tez用了1887秒，Spark用了2171秒，Flink则只用了1480秒；
对一个大数据集(240GB)和一个小数据集(256MB)之间的分布式散列连接；
请参阅图4所示，结果显示，数据批流融合方法仍然是速度最快的，它所用的时间分别是Tez和Spark的1/2和1/4。
需要说明的是，在本文中，如若存在第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (8)
1.一种数据批流融合离线计算方法，其特征在于：所述计算方法包括以下步骤：
S1：调度策略及容错
根据多个任务的依赖关系先调度一批任务，结束后再运行另一批；
S2：批处理模型
平台通过一个底层引擎同时支持流处理和批处理，在流处理引擎之上，具有以下机制：
(1)检查点机制和状态机制：用于实现容错、有状态的处理；
(2)水印机制：用于实现事件时钟；
(3)窗口和触发器：用于限制计算范围，并定义呈现结果的时间；
S3：基于MapReduce编程模型设计
基于MapReduce编程模型，MapReduce提供数据划分和计算任务调度功能。
2.根据权利要求1所述的一种数据批流融合离线计算方法，其特征在于：所述步骤S1中，批流融合作业在任务调度上的不同，故处理作业的多个任务不需要同时在线。
3.根据权利要求2所述的一种数据批流融合离线计算方法，其特征在于：所述步骤S1中，批处理通常依赖中间结果的持久化来减小需要重算的任务范围，引入可插拔的ShuffleService来提供Suffle数据的持久化以支持细粒度的容错恢复。
4.根据权利要求3所述的一种数据批流融合离线计算方法，其特征在于：所述步骤S2中，批处理模型在同一个流处理引擎之上，还存在另一套机制：
(1)用于调度和恢复的回溯法；
(2)用于散列和排序的特殊内存数据结构：将一部分数据从内存溢出到硬盘上；
(3)优化器：缩短生成结果的时间。
5.根据权利要求4所述的一种数据批流融合离线计算方法，其特征在于：所述步骤S3中，数据划分：系统自动将一个作业待处理的大数据划分为很多个数据块，每个数据块对应一个计算任务，并自动调度计算节点来处理相应的数据块。
6.根据权利要求5所述的一种数据批流融合离线计算方法，其特征在于：所述步骤S3中，计算任务调度：负责分配和调度计算节点(Map节点或Reduce节点)，同时负责监控这些节点的执行状态，并负责Map节点执行的同步控制。
7.根据权利要求1-6任一项所述的一种数据批流融合离线计算方法，其特征在于：测试的批处理任务包括TeraSort和分布式散列连接。
8.根据权利要求7所述的一种数据批流融合离线计算方法，其特征在于：所述TeraSort测试：测量为1TB数据排序所用的时间，由以下几个阶段组成：
(1)读取阶段：从HDFS文件中读取数据分区；
(2)本地排序阶段：对上述分区进行部分排序；
(3)混洗阶段：将数据按照key重新分布到处理节点上；
(4)终排序阶段：生成排序输出；
(5)写入阶段：将排序后的分区写入HDFS文件。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111640119.1A CN114281508A (zh) | 2021-12-29 | 2021-12-29 | 一种数据批流融合离线计算方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111640119.1A CN114281508A (zh) | 2021-12-29 | 2021-12-29 | 一种数据批流融合离线计算方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114281508A true CN114281508A (zh) | 2022-04-05 |
Family
ID=80878005
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111640119.1A Pending CN114281508A (zh) | 2021-12-29 | 2021-12-29 | 一种数据批流融合离线计算方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114281508A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115509721A (zh) * | 2022-10-27 | 2022-12-23 | 中国兵器工业计算机应用技术研究所 | 一种数据处理任务协同控制调度方法及系统 |
| CN116841753A (zh) * | 2023-08-31 | 2023-10-03 | 杭州迅杭科技有限公司 | 一种流处理和批处理的切换方法及切换装置 |
-
2021
- 2021-12-29 CN CN202111640119.1A patent/CN114281508A/zh active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115509721A (zh) * | 2022-10-27 | 2022-12-23 | 中国兵器工业计算机应用技术研究所 | 一种数据处理任务协同控制调度方法及系统 |
| CN116841753A (zh) * | 2023-08-31 | 2023-10-03 | 杭州迅杭科技有限公司 | 一种流处理和批处理的切换方法及切换装置 |
| CN116841753B (zh) * | 2023-08-31 | 2023-11-17 | 杭州迅杭科技有限公司 | 一种流处理和批处理的切换方法及切换装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Athlur et al. | Varuna: scalable, low-cost training of massive deep learning models | |
| US7870424B2 (en) | Parallel computer system | |
| US8244671B2 (en) | Replica placement and repair strategies in multinode storage systems | |
| Wang et al. | Replication-based fault-tolerance for large-scale graph processing | |
| US20170093755A1 (en) | Distributed stream-based database triggers | |
| CN114281508A (zh) | 一种数据批流融合离线计算方法 | |
| Mei et al. | Fault-tolerant dynamic rescheduling for heterogeneous computing systems | |
| CN110190991B (zh) | 一种多应用场景下的分布式流处理系统的容错方法 | |
| Zhao et al. | Sdpaxos: Building efficient semi-decentralized geo-replicated state machines | |
| Liu et al. | Optimizing shuffle in wide-area data analytics | |
| Liu et al. | Mctar: A multi-trigger checkpointing tactic for fast task recovery in mapreduce | |
| US10824641B1 (en) | Deterministic query-based replication | |
| CN107992354B (zh) | 用于降低内存负载的方法以及装置 | |
| US11533391B2 (en) | State replication, allocation and failover in stream processing | |
| Chen et al. | Replication-based fault-tolerance for large-scale graph processing | |
| Marcotte et al. | Multiple fault-tolerance mechanisms in cloud systems: A systematic review | |
| CN111290767B (zh) | 具有业务快速恢复功能的容器组更新方法及系统 | |
| CN111078119A (zh) | 一种数据重建方法、系统、装置及计算机可读存储介质 | |
| CN116302574B (zh) | 一种基于MapReduce的并发处理方法 | |
| US11461131B2 (en) | Hosting virtual machines on a secondary storage system | |
| CN111400098B (zh) | 一种副本管理方法、装置、电子设备及存储介质 | |
| Malhotra et al. | A review of fault tolerant scheduling in multicore systems | |
| Amoon | A DEVELOPMENT OF FAULT-TOLERANT AND SCHEDULING SYSTEM FOR GRID COMPUTING. | |
| Yassir et al. | Analyzing fault tolerance mechanism of Hadoop Mapreduce under different type of failures | |
| Qiu et al. | An efficient fault-tolerant scheduling algorithm for periodic real-time tasks in heterogeneous platforms |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |