JP2022508354A - Stream processing method for multi-center data co-computing based on Spark - Google Patents

Stream processing method for multi-center data co-computing based on Spark Download PDF

Info

Publication number
JP2022508354A
JP2022508354A JP2021533418A JP2021533418A JP2022508354A JP 2022508354 A JP2022508354 A JP 2022508354A JP 2021533418 A JP2021533418 A JP 2021533418A JP 2021533418 A JP2021533418 A JP 2021533418A JP 2022508354 A JP2022508354 A JP 2022508354A
Authority
JP
Japan
Prior art keywords
computing
task
client
resource
request
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.)
Granted
Application number
JP2021533418A
Other languages
Japanese (ja)
Other versions
JP6990802B1 (en
Inventor
▲勁▼松 李
▲潤▼▲澤▼ 李
遥 ▲陸▼
▲ユー▼ 王
英浩 ▲趙▼
Original Assignee
之江実験室
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 之江実験室 filed Critical 之江実験室
Application granted granted Critical
Publication of JP6990802B1 publication Critical patent/JP6990802B1/en
Publication of JP2022508354A publication Critical patent/JP2022508354A/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5018—Thread allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)

Abstract

【課題】本発明は、Ｓｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法を提供する。【解決手段】複数のクライアントは、ユーザーによるコンピューティングタスク要求を生成してコンピューティング端末に送信し、コンピューティング端末は、要求を解析し、コンピューティング命令を生成して実行する。本発明は、マルチセンターのデータコンピューティングの要求及び操作の、ストリーム処理コンピューティングを実行することにより、プログラム実行性能及びリソース割り当て効率を改善する。リソース管理ログとＲＥＳＴＦｕｌを設定し、マルチセンターからのＳｐａｒｋ要求タスクに占められ、要求されるメモリー及びスレッドリソースを正確に制御し記録する。マクシミン規準のポリシーを用いて、ストリームコンピューティングにおける各テップのリソース割り当てを実行する。本発明は、マルチセンターのデータ協調コンピューティングにおける数多くのスレッドによって引き起こされるブロッキング遅延という問題を解決して、単一のユーザーの待ち時間を減らし、リソース割り当ての柔軟性及び公平性を改善する。【選択図】図１PROBLEM TO BE SOLVED: To provide a stream processing method for multi-center data co-computing based on Spark. A plurality of clients generate a computing task request by a user and send it to a computing terminal, and the computing terminal analyzes the request, generates a computing instruction, and executes the request. The present invention improves program execution performance and resource allocation efficiency by performing stream processing computing of multi-center data computing requirements and operations. The resource management log and RESTFul are set, and the memory and thread resources requested are accurately controlled and recorded, which are occupied by the Spark request task from the multi-center. Perform resource allocation for each step in stream computing using the policies of the Maximin standard. The present invention solves the problem of blocking delays caused by numerous threads in multicenter data co-computing, reduces latency for a single user, and improves resource allocation flexibility and fairness. [Selection diagram] Fig. 1

Description

本発明は、ストリーム処理の技術分野に関し、特に、Ｓｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法に関する。 The present invention relates to the technical field of stream processing, and more particularly to a stream processing method of multi-center data co-computing based on Spark.

ストリーム処理技術（Ｓｔｒｅａｍ Ｐｒｏｃｅｓｓｉｎｇ）は、コンピュータプログラミングのパラダイムであり、データストリームプログラミングやインタラクティブプログラミングとも呼ばれ、コンピューティングアプリケーションを、限られた並行処理モデルでより効率的に使用できるようにする技術である。このタイプの技術的なアプリケーションは、例えばグラフィックスプロセッシングユニット（Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、ＧＰＵ）又は現場でプログラム可能なゲートアレイ（Ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ、ＦＰＧＡ）などの様々な計算ユニットに存在することが可能であり、しかも、メモリの割り当て、同期及びユニット間のコミュニケーションを明示的に管理しない。Ｓｐａｒｋ ｓｔｒｅａｍｉｎｇは、ＳｐａｒｋのコアＡＰＩの拡張の一つであり、それがリアルタイムストリーミングデータの処理に対して、拡張性、高いスループット、フォールト・トレラントなどの特性を有している。提供される主なインタフェースは、コンテキストの作成Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ、ストリーム開始ｓｔａｒｔ、ストリーム終了ｓｔｏｐ、キャッシュｃａｃｈｅ、Ｃｈｅｃｋ ｐｏｉｎｔｉｎｇなどである。 Stream processing, also known as data stream programming or interactive programming, is a computer programming paradigm that enables computing applications to be used more efficiently with a limited concurrency model. .. This type of technical application can reside in various computing units such as graphics processing units (GPUs) or field programmable gate arrays (Field-programmable Gate Arrays, FPGAs). Moreover, it does not explicitly manage memory allocation, synchronization, and communication between units. Spark streaming is one of Spark's core API extensions, which have characteristics such as scalability, high throughput, and fault tolerance for the processing of real-time streaming data. The main interfaces provided are Streaming Context, stream start start, stream end stop, cache cache, Checkpointing, etc.

マルチセンターのデータ協調コンピューティングは、ビッグデータの背景に現れている応用シナリオであり、マルチパーティデータセンターは、より使用しやすく強力なデータ処理プラットフォームのリソースを個々の単一のユーザーに提供するために、データリソースとデータ処理の要求を統括する必要がある。個々の単一のユーザーは、自分のデータリソースと複数のデータリソースとを統合して集中的に解析することを選択してもよいし、複数の種類の演算要求を選択して、マルチセンター背景で並行コンピューティングを行ってもよい。 Multi-center data co-computing is an application scenario that emerges behind big data, as multi-party data centers provide the resources of a more user-friendly and powerful data processing platform to a single user. In addition, it is necessary to control data resources and data processing requirements. An individual single user may choose to integrate their data resources with multiple data resources for intensive analysis, or select multiple types of compute requests to create a multi-center background. You may perform concurrent computing with.

従来のマルチセンターにおける協調分析プラットフォームは、実質的な単一センターであることが多く、つまり、マルチパーティデータベースを同一箇所のデータノードにキャッシュし、さらに様々な分析要求を一つずつ処理し、実際にすべての並行を一つのストリームにデフォルトして行うことに等価であり、このような形態により、数多くのスレッドによって引き起こされるブロッキング遅延をもたらし、各パッチのキューにおける待ち時間が延長され、新たなユーザーからのコンピューティング要求が即時のフィードバックと満足を得ることが困難であり、データリアルタイム性も保持しにくい。 Traditional multi-center collaborative analysis platforms are often essentially a single center, that is, the multi-party database is cached in the same data node, and various analysis requests are processed one by one. Equivalent to defaulting all parallels to one stream, such a form results in blocking delays caused by many threads, increases latency in the queue for each patch, and new users. It is difficult to obtain immediate feedback and satisfaction from computing requests from, and it is also difficult to maintain data real-time performance.

本発明は、従来技術における欠陥に対して、Ｓｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法を提供することを目的とする。本発明は、リソース管理ログ及びＳｐａｒｋのストリームコンピューティングにより、マルチセンターのデータ協調コンピューティングへのストリーム処理を実現し、ストリーム処理のリソース割り当ての利点及びマルチセンター化のヘテロジニアスコンピューティング要求を結合し、マルチセンターの協調コンピューティングのリソース割り当ての公平性及びデータ分析効率を向上させ、コンピューティングキュータスクの待ち時間を短縮する。 It is an object of the present invention to provide a stream processing method for multi-center data co-computing based on Spark for defects in the prior art. The present invention realizes stream processing to multi-center data co-computing by resource management log and Spark stream computing, and combines the advantages of stream processing resource allocation with multi-centered heterogeneous computing requirements. Improves the fairness of resource allocation and data analysis efficiency of multi-center co-computing, and reduces the latency of computing queue tasks.

本発明の目的は、以下のような技術手段により実現される。
Ｓｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法であって、
当該方法は、マルチセンターのデータ協調コンピューティングシステムで実施されるものであり、前記マルチセンターのデータ協調コンピューティングシステムは、複数のクライアント及び一つのコンピューティング端末を含み、前記クライアントは、ユーザーによるコンピューティングタスク要求を生成してコンピューティング端末に送信するためのものであり、前記コンピューティング端末は、要求を解析して、コンピューティング命令を生成して実行するためのものであり、
当該方法は、
クライアント及びコンピューティング端末にＲＥＳＴＦｕｌサービスを構築し、コンピューティングタスクキューを

Figure 2022508354000002
とし、ＬがコンピューティングタスクキューＱの長さであり、いずれか一つのクライアントｃｋがコンピューティング端末に一つの新たなコンピューティングタスク要求ｔｋを送信し、当該要求には、コンピューティングのスレッドリソース要求ｎｔｋ、メモリーをコンピューティングする要求ｎｍｋ、このタスクに対応するコンピューティングすべきデータＤｋを含む、ステップ（１）と、
コンピューティング端末は、クライアントｃｋから送信されたコンピューティングタスク要求を解析して、
Figure 2022508354000003
を取得する、ステップ（２）と、
コンピューティング端末は、
Figure 2022508354000004
を一つのエレメントとして、コンピューティングタスクキューＱに挿入してから、Ｓｃｈｅｄｕｌｉｎｇ計算を始め、Ｓｃｈｅｄｕｌｉｎｇ計算では、タスクキューＱにおける各エレメントのコンピューティング要求の値をクライアントを単位とするマクシミン規準に従って最適化し、各エレメントのｎｔｋ及びｎｍｋを更新する、ステップ（３）と、
キュー
Figure 2022508354000005
の長さ
Figure 2022508354000006
をコンピューティングし、Ｌを循環境界条件として、Ｓｐａｒｋ．Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ（Ｓｐａｒｋ．Ｓｔｒｅａｍｉｎｇ ＣｏｎｔｅｘｔがＳｐａｒｋフレームワークにおけるストリーム処理タスクの作成命令インタフェースである）により、
Figure 2022508354000007
個のストリームを作成し、Ｓｐａｒｋ．Ｃｏｎｆ（Ｓｐａｒｋ．ＣｏｎｆがＳｐａｒｋフレームワークにおけるストリーム処理タスクの配置命令インタフェースである）により、各ストリームに割り当てられたリソースを宣言し、Ｓｐａｒｋに実際のストリームタスクを順次送信することについて、データＤｋをロードし、データをコンピューティングタスクｔｋを実行し、割り当てられたスレッドリソースがｎｔｋとなり、メモリーリソースがｎｍｋとなり、ただし、Ｄｋには、中間結果及びコンピューティングタスクメタデータが存在すれば、直接にそれに対応するステップからタスクをコンピューティングし始め、
ストリーム１：データＤ１をロードし、データに対してコンピューティングタスクｔ１を実行し、割り当てられたスレッドリソースがｎｔ１となり、メモリーリソースがｎｍ１となり、
ストリーム２：データＤ2をロードし、データに対してコンピューティングタスクｔ２を実行し、割り当てられたスレッドリソースがｎｔ２となり、メモリーリソースがｎｍ２となり、
…
ストリームＬ：データＤＬをロードし、データに対してコンピューティングタスクｔＬを実行し、割り当てられたスレッドリソースがｎｔＬとなり、メモリーリソースがｎｍＬとなるステップ（４）と、
ストリーム処理されているタスク
Figure 2022508354000008
について、Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．Ｃｈｅｃｋ Ｐｏｉｎｔｉｎｇ（Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．Ｃｈｅｃｋ ＰｏｉｎｔｉｎｇがＳｐａｒｋフレームワークにおけるストリーム処理タスクのデータ持続化命令インタフェースである）により、ストリーム処理過程におけるＨＤＦＳへのデータの読み取り、データの前処理キャッシュ、コンピューティング、戻りという四つのステップにおいて、データストリームを持続化させる操作を実行し、中間結果及びコンピューティングタスクメタデータをＤlに記憶し、同時に、キューの更新状況を監視し、キューの更新を監視した場合、Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．ｓｔｏｐ（Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．ｓｔｏｐがＳｐａｒｋフレームワークにおけるストリーム処理タスクの中止命令インタフェースである）により、当該ストリームを停止させ、ステップ（４）に戻り、ストリーム処理過程におけるコンピューティングタスクが完了した場合に、当該ストリーム処理タスクに対応するクライアントにタスク処理結果を返し、タスクをキューＱから取り出す、ステップ（５）とを含む、Ｓｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法。 The object of the present invention is realized by the following technical means.
A stream processing method for multi-center data co-computing based on Spark.
The method is carried out in a multi-center data co-computing system, wherein the multi-center data co-computing system includes a plurality of clients and one computing terminal, wherein the clients are computing by a user. It is for generating an ing task request and sending it to a computing terminal, and the computing terminal is for analyzing a request to generate and execute a computing instruction.
The method is
Build RESTFul services on clients and computing terminals and create computing task queues
Figure 2022508354000002
L is the length of the computing task queue Q, and any one of the client c k sends one new computing task request t k to the computing terminal, and the request is sent to the computing thread. Step (1), which includes a resource request nt k , a memory computing request nm k , and a computeable data D k corresponding to this task.
The computing terminal analyzes the computing task request sent from the client ck , and the computing terminal analyzes the computing task request.
Figure 2022508354000003
To get step (2) and
Computing terminals
Figure 2022508354000004
Is inserted into the computing task queue Q as one element, and then the Scheduling calculation is started. In the Scheduling calculation, the value of the computing request of each element in the task queue Q is optimized according to the Maximin standard for each client. Step (3), which updates nt k and nm k of each element,
queue
Figure 2022508354000005
Length of
Figure 2022508354000006
With L as the circular boundary condition, Spark. By Streaming Context (Spark. Streaming Context is an instruction interface for creating stream processing tasks in the Spark framework).
Figure 2022508354000007
Create individual streams and use Spark. Data Dk for declaring the resources assigned to each stream by Conf ( Spark.Conf is the placement instruction interface for stream processing tasks in the Spark framework) and sequentially sending the actual stream tasks to Spark. Load and execute the computing task tk, the allocated thread resource is nt k , the memory resource is nm k , but if D k has intermediate results and computing task metadata. , Start computing the task directly from the corresponding step,
Stream 1: Load data D 1 , perform computing task t 1 on the data, the allocated thread resource becomes nt 1 , the memory resource becomes nm 1 and so on.
Stream 2: Load data D 2 , perform computing task t 2 on the data, the allocated thread resource becomes nt 2 , the memory resource becomes nm 2 .
…
Stream L : Load the data DL, execute the computing task t L on the data, the allocated thread resource becomes nt L , and the memory resource becomes nm L (4).
Tasks being streamed
Figure 2022508354000008
About, Streaming Context. Check Pointing (Streaming Context. Check Pointing is the data sustaining instruction interface for stream processing tasks in the Spark framework) allows the data to be read into HDFS during the stream processing process, data preprocessing cache, computing, and return. In one step, if you perform an operation to sustain the data stream, store the intermediate results and computing task metadata in D l , and at the same time monitor the queue update status and monitor the queue update, Streaming Context. .. When the stream is stopped by stop (Streaming Context.stop is the stop instruction interface of the stream processing task in the Spark framework), the process returns to step (4), and the computing task in the stream processing process is completed. A stream processing method for multi-center data co-computing based on Spark, including step (5) of returning a task processing result to a client corresponding to a stream processing task and retrieving the task from queue Q.

さらに、前記ステップ（３）において、クライアントに基づくＳｃｈｅｄｕｌｉｎｇ計算の流れは、以下の通りであり、
ステップ（３．１）：キュー

Figure 2022508354000009
であり、ＬがコンピューティングキューＱの長さであることについて、クライアントに複数の記録が存在している場合に、まず、クライアントに従って加算し、クライアントを単位とする新たなキュー
Figure 2022508354000010
を取得し、ＬｍｉｄがＱｍｉｄ長さであり、ｓｊが各クライアントによって送信されたタスク総数であり、ｎｔｊ mid、ｎｍｊ midがそれぞれクライアントｃｊによって要求されたスレッドリソース総数及びメモリーリソース総数であり、
ステップ（３．２）：スレッドリソースについて、以下のように最適化割り当ての流れを実行しており、
ステップ（３．２．１）：すべてのクライアントのスレッドリソース要求総数キュー
Figure 2022508354000011
について、サイズに従ってソートして
Figure 2022508354000012
及び添え字マッピングM=
Figure 2022508354000013
を取得し、コンピューティングセンターのコンピューティングリソースプールの総スレッドリソースをＮＴとすると、予めｎｔｊ midに与えられるリソースが
Figure 2022508354000014
となり、
ステップ（３．２．２）：
Figure 2022508354000015
が存在している場合に、この集合が
Figure 2022508354000016
とし、ステップ（３．２．３）に移行し、それ以外の場合は、最終的なスレッドリソース割り当てポリシー
Figure 2022508354000017
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するスレッドリソース割り当てポリシー
Figure 2022508354000018
を取得し、ステップ（３．２．４）に移行し、
ステップ（３．２．３）：再割り当てする必要があるスレッドリソースが
Figure 2022508354000019
であり、ただし、
Figure 2022508354000020
がＪのエレメントの数であり、ステップ（３．２．２）に戻り、
ステップ（３．２．４）：同じクライアントに割り当てられたスレッドリソースを、当該クライアントと対応するすべてのタスクに均一に割り当て、同じｃｊにタスク
Figure 2022508354000021
を対応させ、ただし、
Figure 2022508354000022
がユーザーｃｊが実際に提出した一つのタスクｔｚに割り当てられたスレッドリソースであり、ｎｔｊ ｍｉｄがステップ（３．２．２）で得られた当該ユーザーに割り当てられたすべてのスレッドリソースであり、ｓｊがユーザーｃｊによって送信されたタスクの総数であり、
ステップ（３．３）：メモリーリソースについて、以下のように最適化割り当ての流れを実行しており、
ステップ（３．３．１）：すべてのクライアントのメモリーリソース要求総数キュー
Figure 2022508354000023
について、サイズに従ってソートして、
Figure 2022508354000024
及び添え字マッピングM=
Figure 2022508354000025
を取得し、コンピューティングセンターのコンピューティングリソースプールの総メモリーリソースをＮＭとすると、予めｎｍｊ midに与えられるリソースが
Figure 2022508354000026
となり、
ステップ（３．３．２）：
Figure 2022508354000027
が存在している場合に、この集合を
Figure 2022508354000028
として、ステップ（３．２．３）に移行し、それ以外の場合は、最終的なメモリーリソース割り当てポリシー
Figure 2022508354000029
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するメモリーリソース割り当てポリシー
Figure 2022508354000030
を取得し、ステップ（３．２．４）に移行し、
ステップ（３．３．３）：再割り当てする必要があるメモリーリソースが
Figure 2022508354000031
であり、ただし、
Figure 2022508354000032
がＪのエレメントの数であり、ステップ（３．３．２）に戻り、
ステップ（３．３．４）：同じクライアントに割り当てられたメモリーリソースを当該クライアントと対応するすべてのタスクに均一に割り当て、同一ｃｊにタスク
Figure 2022508354000033
，
Figure 2022508354000034
を対応させ、ただし、
Figure 2022508354000035
がユーザーｃｊが実際に提出した一つのタスクｔｚに割り当てられたメモリーリソースであり、ｎｍｊ midがステップ（３．２．２）で得られた当該ユーザーに割り当てられたすべてのメモリーリソースであり、ｓｊがユーザーｃｊによって送信されたタスクの総数であり、
ステップ（３．４）：ステップ（３．２）及びステップ（３．３）で得られた［ｎｔｋ］及び［ｎｍｋ］から、
Figure 2022508354000036
］を再構成する。 Further, in the step (3), the flow of Scheduling calculation based on the client is as follows.
Step (3.1): Queue
Figure 2022508354000009
If there are multiple records in the client regarding that L is the length of the computing queue Q, first, the queue is added according to the client, and a new queue in the client unit.
Figure 2022508354000010
Is obtained, L mid is the Q mid length, s j is the total number of tasks sent by each client, and nt j mid and nm j mid are the total number of thread resources and memory resources requested by the client c j , respectively. Is the total number
Step (3.2): For thread resources, the flow of optimization allocation is executed as follows.
Step (3.2.1): Total number of thread resource requests queue for all clients
Figure 2022508354000011
Sort by size
Figure 2022508354000012
And subscript mapping M =
Figure 2022508354000013
And if the total thread resource of the computing resource pool of the computing center is NT, the resource given to nt j mid in advance is
Figure 2022508354000014
And
Step (3.2.2):
Figure 2022508354000015
If is present, then this set
Figure 2022508354000016
And move to step (3.2.3), otherwise the final thread resource allocation policy
Figure 2022508354000017
Thread resource allocation policy corresponding to the order to return before sorting by subscript mapping
Figure 2022508354000018
Is obtained, and the process proceeds to step (3.2.4).
Step (3.2.3): Thread resource that needs to be reassigned
Figure 2022508354000019
However,
Figure 2022508354000020
Is the number of elements of J, returning to step (3.2.2),
Step (3.2.4): Thread resources assigned to the same client are evenly allocated to all tasks corresponding to the client, and tasks are assigned to the same cj .
Figure 2022508354000021
However,
Figure 2022508354000022
Is the thread resource assigned to one task t z actually submitted by the user c j , and nt j mid is all the thread resources assigned to the user obtained in step (3.2.2). Yes, s j is the total number of tasks sent by user c j ,
Step (3.3): For memory resources, the flow of optimization allocation is executed as follows.
Step (3.3.1): Total memory resource request queue for all clients
Figure 2022508354000023
Sort by size,
Figure 2022508354000024
And subscript mapping M =
Figure 2022508354000025
And if the total memory resource of the computing resource pool of the computing center is NM, the resource given to nm j mid in advance is
Figure 2022508354000026
And
Step (3.3.2):
Figure 2022508354000027
If is present, then this set
Figure 2022508354000028
As a result, move to step (3.2.3), otherwise the final memory resource allocation policy.
Figure 2022508354000029
And by subscript mapping, the memory resource allocation policy corresponding to the order to return before sorting
Figure 2022508354000030
Is obtained, and the process proceeds to step (3.2.4).
Step (3.3.3): Memory resources that need to be reallocated
Figure 2022508354000031
However,
Figure 2022508354000032
Is the number of elements of J, returning to step (3.3.2),
Step (3.3.4): Allocate memory resources allocated to the same client evenly to all tasks corresponding to the client, and tasks to the same cj .
Figure 2022508354000033
， ，
Figure 2022508354000034
However,
Figure 2022508354000035
Is the memory resource allocated to one task t z actually submitted by user c j , and nm j mid is all memory resources allocated to that user obtained in step (3.2.2). Yes, s j is the total number of tasks sent by user c j ,
Step (3.4): From [nt k ] and [nm k ] obtained in step (3.2) and step (3.3).
Figure 2022508354000036
] Is reconstructed.

本発明による有益な効果は、以下の通りである。
本発明は、マルチセンターのデータコンピューティングの要求及び操作の、ストリーム処理コンピューティングを実行することにより、プログラム実行性能及びリソース割り当て効率を改善する。リソース管理ログとＲＥＳＴＦｕｌを設定し、マルチセンターからのＳｐａｒｋ要求タスクに占められ、要求されるメモリー及びスレッドリソースを正確に制御し記録する。マクシミン規準のポリシーを用いて、ストリームコンピューティングにおける各テップのリソース割り当てを実行する。本発明は、マルチセンターのデータ協調コンピューティングにおける数多くのスレッドによって引き起こされるブロッキング遅延という問題を解決して、単一のユーザーの待ち時間を減らし、リソース割り当ての柔軟性及び公平性を改善する。 The beneficial effects of the present invention are as follows.
The present invention improves program execution performance and resource allocation efficiency by performing stream processing computing of multi-center data computing requirements and operations. The resource management log and RESTFul are set, and the memory and thread resources requested are accurately controlled and recorded, which are occupied by the Spark request task from the multi-center. Perform resource allocation for each step in stream computing using the policies of the Maximin standard. The present invention solves the problem of blocking delays caused by numerous threads in multicenter data co-computing, reduces latency for a single user, and improves resource allocation flexibility and fairness.

本発明に係るセンター協調コンピューティングのストリーム処理方法のフローチャートである。It is a flowchart of the stream processing method of the center cooperative computing which concerns on this invention.

以下に、図面及び具体的な実施例を参照しつつ、本発明をより詳しく説明する。
図１に示すように、本発明は、Ｓｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法を提供しており、当該方法は、マルチセンターのデータ協調コンピューティングシステムで実施されるものであり、前記マルチセンターのデータ協調コンピューティングシステムは、複数のクライアント及び一つのコンピューティング端末を含み、前記クライアントは、ユーザーによるコンピューティングタスク要求を生成してコンピューティング端末に送信するためのものであり、前記コンピューティング端末は、要求を解析して、コンピューティング命令を生成して実行するためのものであり、
当該方法は、
クライアント及びコンピューティング端末にＲＥＳＴＦｕｌサービスを構築し、コンピューティングタスクキューを

Figure 2022508354000037
とし、ＬがコンピューティングタスクキューＱの長さであり、いずれか一つのクライアントｃｋがコンピューティング端末に一つの新たなコンピューティングタスク要求ｔｋを送信し、当該要求には、コンピューティングのスレッドリソース要求ｎｔｋ、メモリーをコンピューティングする要求ｎｍｋ、このタスクに対応するコンピューティングすべきデータＤｋを含む、ステップ（１）と、
コンピューティング端末は、クライアントｃｋから送信されたコンピューティングタスク要求を解析して、
Figure 2022508354000038
を取得する、ステップ（２）と、
コンピューティング端末は、
Figure 2022508354000039
を一つのエレメントとして、コンピューティングタスクキューＱに挿入してから、Ｓｃｈｅｄｕｌｉｎｇ計算を始め、Ｓｃｈｅｄｕｌｉｎｇ計算では、タスクキューＱにおける各エレメントのコンピューティング要求の値をクライアントを単位とするマクシミン規準に従って最適化し、各エレメントのｎｔｋ及びｎｍｋを更新する、ステップ（３）と、
キュー
Figure 2022508354000040
の長さ
Figure 2022508354000041
をコンピューティングし、Ｌを循環境界条件として、Ｓｐａｒｋ．Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ（Ｓｐａｒｋ．Ｓｔｒｅａｍｉｎｇ ＣｏｎｔｅｘｔがＳｐａｒｋフレームワークにおけるストリーム処理タスクの作成命令インタフェースである）により、
Figure 2022508354000042
個のストリームを作成し、Ｓｐａｒｋ．Ｃｏｎｆ（Ｓｐａｒｋ．ＣｏｎｆがＳｐａｒｋフレームワークにおけるストリーム処理タスクの配置命令インタフェースである）により、各ストリームに割り当てられたリソースを宣言し、Ｓｐａｒｋに実際のストリームタスクを順次送信することについて、データＤｋをロードし、データをコンピューティングタスクｔｋを実行し、割り当てられたスレッドリソースがｎｔｋとなり、メモリーリソースがｎｍｋとなり、ただし、Ｄｋには、中間結果及びコンピューティングタスクメタデータが存在すれば、直接にそれに対応するステップからタスクをコンピューティングし始め、
ストリーム１：データＤ１をロードし、データに対してコンピューティングタスクｔ１を実行し、割り当てられたスレッドリソースがｎｔ１となり、メモリーリソースがｎｍ１となり、
ストリーム２：データＤ2をロードし、データに対してコンピューティングタスクｔ２を実行し、割り当てられたスレッドリソースがｎｔ２となり、メモリーリソースがｎｍ２となり、
…
ストリームＬ：データＤＬをロードし、データに対してコンピューティングタスクｔＬを実行し、割り当てられたスレッドリソースがｎｔＬとなり、メモリーリソースがｎｍＬとなるステップ（４）と、
ストリーム処理されているタスク
Figure 2022508354000043
について、Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．Ｃｈｅｃｋ Ｐｏｉｎｔｉｎｇ（Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．Ｃｈｅｃｋ ＰｏｉｎｔｉｎｇがＳｐａｒｋフレームワークにおけるストリーム処理タスクのデータ持続化命令インタフェースである）により、ストリーム処理過程におけるＨＤＦＳへのデータの読み取り、データの前処理キャッシュ、コンピューティング、戻りという四つのステップにおいて、データストリームを持続化させる操作を実行し、中間結果及びコンピューティングタスクメタデータをＤlに記憶し、同時に、キューの更新状況を監視し、キューの更新を監視した場合、Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．ｓｔｏｐ（Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．ｓｔｏｐがＳｐａｒｋフレームワークにおけるストリーム処理タスクの中止命令インタフェースである）により、当該ストリームを停止させ、ステップ（４）に戻り、ストリーム処理過程におけるコンピューティングタスクが完了した場合に、当該ストリーム処理タスクに対応するクライアントにタスク処理結果を返し、タスクをキューＱから取り出す、ステップ（５）とを含む。 Hereinafter, the present invention will be described in more detail with reference to the drawings and specific examples.
As shown in FIG. 1, the present invention provides a stream processing method for multi-center data co-computing based on Spark, which method is implemented in a multi-center data co-computing system. The multi-center data co-computing system includes a plurality of clients and one computing terminal, the client for generating a computing task request by a user and transmitting it to the computing terminal. The computing terminal is for analyzing a request, generating a computing instruction, and executing the computing instruction.
The method is
Build RESTFul services on clients and computing terminals and create computing task queues
Figure 2022508354000037
L is the length of the computing task queue Q, and any one of the client c k sends one new computing task request t k to the computing terminal, and the request is sent to the computing thread. Step (1), which includes a resource request nt k , a memory computing request nm k , and a computeable data D k corresponding to this task.
The computing terminal analyzes the computing task request sent from the client ck , and the computing terminal analyzes the computing task request.
Figure 2022508354000038
To get step (2) and
Computing terminals
Figure 2022508354000039
Is inserted into the computing task queue Q as one element, and then the Scheduling calculation is started. In the Scheduling calculation, the value of the computing request of each element in the task queue Q is optimized according to the Maximin standard for each client. Step (3), which updates nt k and nm k of each element,
queue
Figure 2022508354000040
Length of
Figure 2022508354000041
With L as the circular boundary condition, Spark. By Streaming Context (Spark. Streaming Context is an instruction interface for creating stream processing tasks in the Spark framework).
Figure 2022508354000042
Create individual streams and use Spark. Data Dk for declaring the resources assigned to each stream by Conf ( Spark.Conf is the placement instruction interface for stream processing tasks in the Spark framework) and sequentially sending the actual stream tasks to Spark. Load and execute the computing task tk, the allocated thread resource is nt k , the memory resource is nm k , but if D k has intermediate results and computing task metadata. , Start computing the task directly from the corresponding step,
Stream 1: Load data D 1 , perform computing task t 1 on the data, the allocated thread resource becomes nt 1 , the memory resource becomes nm 1 and so on.
Stream 2: Load data D 2 , perform computing task t 2 on the data, the allocated thread resource becomes nt 2 , the memory resource becomes nm 2 .
…
Stream L : Load the data DL, execute the computing task t L on the data, the allocated thread resource becomes nt L , and the memory resource becomes nm L (4).
Tasks being streamed
Figure 2022508354000043
About, Streaming Context. Check Pointing (Streaming Context. Check Pointing is the data sustaining instruction interface for stream processing tasks in the Spark framework) allows the data to be read into HDFS during the stream processing process, data preprocessing cache, computing, and return. In one step, if you perform an operation to sustain the data stream, store the intermediate results and computing task metadata in D l , and at the same time monitor the queue update status and monitor the queue update, Streaming Context. .. When the stream is stopped by stop (Streaming Context.stop is the stop instruction interface of the stream processing task in the Spark framework), the process returns to step (4), and the computing task in the stream processing process is completed. This includes step (5) of returning the task processing result to the client corresponding to the stream processing task and retrieving the task from the queue Q.

さらに、前記ステップ（３）において、クライアントに基づくＳｃｈｅｄｕｌｉｎｇ計算流れは、以下の通りである。
ステップ（３．１）：キュー

Figure 2022508354000044
であり、ＬがコンピューティングキューＱの長さであることについて、クライアントに複数の記録が存在している場合に、まず、クライアントに従って加算し、クライアントを単位とする新たなキュー
Figure 2022508354000045
を取得し、ＬｍｉｄがＱｍｉｄ長さであり、ｓｊが各クライアントによって送信されたタスク総数であり、ｎｔｊ mid、ｎｍｊ midがそれぞれクライアントｃｊによって要求されたスレッドリソース総数及びメモリーリソース総数であり、
ステップ（３．２）：スレッドリソースについて、以下のように最適化割り当ての流れを実行しており、
ステップ（３．２．１）：すべてのクライアントのスレッドリソース要求総数キュー
Figure 2022508354000046
について、サイズに従ってソートして
Figure 2022508354000047
及び添え字マッピングM=
Figure 2022508354000048
を取得し、コンピューティングセンターのコンピューティングリソースプールの総スレッドリソースをＮＴとすると、予めｎｔｊ midに与えられるリソースが
Figure 2022508354000049
となり、
ステップ（３．２．２）：
Figure 2022508354000050
が存在している場合に、この集合が
Figure 2022508354000051
とし、ステップ（３．２．３）に移行し、それ以外の場合は、最終的なスレッドリソース割り当てポリシー
Figure 2022508354000052
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するスレッドリソース割り当てポリシー
Figure 2022508354000053
を取得し、ステップ（３．２．４）に移行し、
ステップ（３．２．３）：再割り当てする必要があるスレッドリソースが
Figure 2022508354000054
であり、ただし、
Figure 2022508354000055
がＪのエレメントの数であり、ステップ（３．２．２）に戻り、
ステップ（３．２．４）：同じクライアントに割り当てられたスレッドリソースを、当該クライアントと対応するすべてのタスクに均一に割り当て、同じｃｊにタスク
Figure 2022508354000056
を対応させ、ただし、
Figure 2022508354000057
がユーザーｃｊが実際に提出した一つのタスクｔｚに割り当てられたスレッドリソースであり、ｎｔｊ ｍｉｄがステップ（３．２．２）で得られた当該ユーザーに割り当てられたすべてのスレッドリソースであり、ｓｊがユーザーｃｊによって送信されたタスクの総数であり、
ステップ（３．３）：メモリーリソースについて、以下のように最適化割り当ての流れを実行しており、
ステップ（３．３．１）：すべてのクライアントのメモリーリソース要求総数キュー
Figure 2022508354000058
について、サイズに従ってソートして、
Figure 2022508354000059
及び添え字マッピングM=
Figure 2022508354000060
を取得し、コンピューティングセンターのコンピューティングリソースプールの総メモリーリソースをＮＭとすると、予めｎｍｊ midに与えられるリソースが
Figure 2022508354000061
となり、
ステップ（３．３．２）：
Figure 2022508354000062
が存在している場合に、この集合を
Figure 2022508354000063
として、ステップ（３．２．３）に移行し、それ以外の場合は、最終的なメモリーリソース割り当てポリシー
Figure 2022508354000064
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するメモリーリソース割り当てポリシー
Figure 2022508354000065
を取得し、ステップ（３．２．４）に移行し、
ステップ（３．３．３）：再割り当てする必要があるメモリーリソースが
Figure 2022508354000066
であり、ただし、
Figure 2022508354000067
がＪのエレメントの数であり、ステップ（３．３．２）に戻り、
ステップ（３．３．４）：同じクライアントに割り当てられたメモリーリソースを当該クライアントと対応するすべてのタスクに均一に割り当て、同一ｃｊにタスク
Figure 2022508354000068
，
Figure 2022508354000069
を対応させ、ただし、
Figure 2022508354000070
がユーザーｃｊが実際に提出した一つのタスクｔｚに割り当てられたメモリーリソースであり、ｎｍｊ midがステップ（３．２．２）で得られた当該ユーザーに割り当てられたすべてのメモリーリソースであり、ｓｊがユーザーｃｊによって送信されたタスクの総数であり、
ステップ（３．４）：ステップ（３．２）及びステップ（３．３）で得られた［ｎｔｋ］及び［ｎｍｋ］から、
Figure 2022508354000071
］を再構成する。 Further, in the step (3), the Scheduling calculation flow based on the client is as follows.
Step (3.1): Queue
Figure 2022508354000044
If there are multiple records in the client regarding that L is the length of the computing queue Q, first, the queue is added according to the client, and a new queue in the client unit.
Figure 2022508354000045
Is obtained, L mid is the Q mid length, s j is the total number of tasks sent by each client, and nt j mid and nm j mid are the total number of thread resources and memory resources requested by the client c j , respectively. Is the total number
Step (3.2): For thread resources, the flow of optimization allocation is executed as follows.
Step (3.2.1): Total number of thread resource requests queue for all clients
Figure 2022508354000046
Sort by size
Figure 2022508354000047
And subscript mapping M =
Figure 2022508354000048
And if the total thread resource of the computing resource pool of the computing center is NT, the resource given to nt j mid in advance is
Figure 2022508354000049
And
Step (3.2.2):
Figure 2022508354000050
If is present, then this set
Figure 2022508354000051
And move to step (3.2.3), otherwise the final thread resource allocation policy
Figure 2022508354000052
Thread resource allocation policy corresponding to the order to return before sorting by subscript mapping
Figure 2022508354000053
Is obtained, and the process proceeds to step (3.2.4).
Step (3.2.3): Thread resource that needs to be reassigned
Figure 2022508354000054
However,
Figure 2022508354000055
Is the number of elements of J, returning to step (3.2.2),
Step (3.2.4): Thread resources assigned to the same client are evenly allocated to all tasks corresponding to the client, and tasks are assigned to the same cj .
Figure 2022508354000056
However,
Figure 2022508354000057
Is the thread resource assigned to one task t z actually submitted by the user c j , and nt j mid is all the thread resources assigned to the user obtained in step (3.2.2). Yes, s j is the total number of tasks sent by user c j ,
Step (3.3): For memory resources, the flow of optimization allocation is executed as follows.
Step (3.3.1): Total memory resource request queue for all clients
Figure 2022508354000058
Sort by size,
Figure 2022508354000059
And subscript mapping M =
Figure 2022508354000060
And if the total memory resource of the computing resource pool of the computing center is NM, the resource given to nm j mid in advance is
Figure 2022508354000061
And
Step (3.3.2):
Figure 2022508354000062
If is present, then this set
Figure 2022508354000063
As a result, move to step (3.2.3), otherwise the final memory resource allocation policy.
Figure 2022508354000064
And by subscript mapping, the memory resource allocation policy corresponding to the order to return before sorting
Figure 2022508354000065
Is obtained, and the process proceeds to step (3.2.4).
Step (3.3.3): Memory resources that need to be reallocated
Figure 2022508354000066
However,
Figure 2022508354000067
Is the number of elements of J, returning to step (3.3.2),
Step (3.3.4): Allocate memory resources allocated to the same client evenly to all tasks corresponding to the client, and tasks to the same cj .
Figure 2022508354000068
， ，
Figure 2022508354000069
However,
Figure 2022508354000070
Is the memory resource allocated to one task t z actually submitted by user c j , and nm j mid is all memory resources allocated to that user obtained in step (3.2.2). Yes, s j is the total number of tasks sent by user c j ,
Step (3.4): From [nt k ] and [nm k ] obtained in step (3.2) and step (3.3).
Figure 2022508354000071
] Is reconstructed.

以下に、本発明に係るＳｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法を、マルチセンターの医学データ協調コンピューティングプラットフォーム上に適用する一つの具体的な実施例を示し、当該実施例は、具体的に、以下のステップを含む。
ステップ（１）：クライアント（三つの病院）及びコンピューティング端末（データセンター）に、ＲＥＳＴＦｕｌサービスを構築し、コンピューティングタスクキューを、以下の式とする。

Figure 2022508354000072
Ｌ＝３であり、三番目の病院“hospital3”は、コンピューティング端末に一つの新たなコンピューティングタスク要求“task4”を送信し、当該要求には、コンピューティングのスレッドリソース要求１６、コンピューティングメモリーの要求１６、そのタスクに対応するコンピューティングすべきデータ“path4”を含む。
ステップ（２）：コンピューティング端末は、クライアントｃｉから送信されたコンピューティングタスク要求を解析して、
Figure 2022508354000073
を取得する。
ステップ（３）：コンピューティング端末は、
Figure 2022508354000074
を一つのエレメントとして、コンピューティングタスクキュー
Figure 2022508354000075
に挿入する。
Figure 2022508354000076
 その後に、Ｓｃｈｅｄｕｌｉｎｇ計算を始め、Ｓｃｈｅｄｕｌｉｎｇ計算では、タスクキューＱにおける各エレメントのコンピューティング要求の値をクライアントを単位とするマクシミン規準に従って最適化し、各エレメントのｎｔｋ及びｎｍｋを更新し、キューＱの値が次の式になり、
Figure 2022508354000077
 ただし、Ｓｃｈｅｄｕｌｉｎｇ計算の流れは、以下の通りである。
ステップ（３．１）：次のキューについて
Figure 2022508354000078
 ＬがコンピューティングキューＱの長さであり、Ｌ＝４であり、クライアント“hospital2”には複数の記録が存在している場合に、まず、クライアントに従って加算し、次の式を取得し、
Figure 2022508354000079
 ＬｍｉｄがＱｍｉｄ長さであり、Ｌｍｉｄ＝３である。
ステップ（３．２）：スレッドリソースについて、次のように最適化割り当ての流れを実行しており、
ステップ（３．２．１）：すべてのクライアントのスレッドリソース要求総数キュー[8,12,16]について、サイズに従ってソートして、[8,12,16]及び添え字マッピングM=[1,2,3]を取得し、コンピューティングセンターのコンピューティングリソースプールの総スレッドリソースをＮＴ＝３２とすると、予め[8,12,16]に与えられるリソースが[10,10,12]となる。
ステップ（３．２．２）：
Figure 2022508354000080
が存在している場合に、この集合を
Figure 2022508354000081
とし、ステップ（３．２．３）に移行する。
ステップ（３．２．３）：再割り当てする必要があるスレッドリソースが
Figure 2022508354000082
であり、ただし、
Figure 2022508354000083
がＪのエレメントの数であり、
Figure 2022508354000084
であり、ステップ（３．２．２）に戻る。
ステップ（３．２．２）：
Figure 2022508354000085
が存在していない場合、最終的なスレッドリソース割り当てポリシー
Figure 2022508354000086
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するメモリーリソース割り当てポリシー
Figure 2022508354000087
を取得し、ステップ（３．２．４）に移行する。
ステップ（３．２．４）：同一“hospital2”にタスク
Figure 2022508354000088
を対応させる。
ステップ（３．３）：メモリーリソースについて、以下のように、最適化割り当ての流れを実行しており、
ステップ（３．３．１）：すべてのクライアントのメモリーリソース要求総数キュー
Figure 2022508354000089
について、サイズに従ってソートして、
Figure 2022508354000090
及び添え字マッピングM=
Figure 2022508354000091
を取得し、コンピューティングセンターのコンピューティングリソースプールの総メモリーリソースを
Figure 2022508354000092
、予め
Figure 2022508354000093
に与えられるリソースが
Figure 2022508354000094
となる。
ステップ（３．３．２）：
Figure 2022508354000095
が存在している場合、この集合を、
Figure 2022508354000096
とし、ステップ（３．３．３）に移行する。
ステップ（３．３．３）：再割り当てする必要があるメモリーリソースが
Figure 2022508354000097
，
Figure 2022508354000098
であり、ただし、
Figure 2022508354000099
がＪのエレメントの数であり、ステップ（３．３．２）に戻る。
ステップ（３．３．２）：
Figure 2022508354000100
が存在していない場合、最終的なスレッドリソース割り当てポリシー
Figure 2022508354000101
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するメモリーリソース割り当てポリシー
Figure 2022508354000102
を取得し、ステップ（３．３．４）に移行する。
ステップ（３．３．４）：同一の“hospital2”にタスク
Figure 2022508354000103
，
Figure 2022508354000104
を対応させる。
ステップ（３．４）：ステップ（３．２）及びステップ（３．３）で得られた［ｎｔｋ］及び［ｎｍｋ］から、次の式を再構成する。
Figure 2022508354000105
 ステップ（４）：コンピューティングキューＱの長さをコンピューティングし、
Figure 2022508354000106
であり、４を循環境界条件として、Ｓｐａｒｋ．Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ（Ｓｐａｒｋ．Ｓｔｒｅａｍｉｎｇ ＣｏｎｔｅｘｔがＳｐａｒｋフレームワークにおけるストリーム処理タスクの作成命令インタフェースである）により、４個のストリームを作成し、Ｓｐａｒｋ．Ｃｏｎｆ（Ｓｐａｒｋ．ＣｏｎｆがＳｐａｒｋフレームワークにおけるストリーム処理タスクの配置命令インタフェースである）により、各ストリームに割り当てられたリソースを宣言し、Ｓｐａｒｋに実際のストリームタスクを順次送信することについて、
ストリーム１：データ“path1”をロードし、データに対してコンピューティングタスク“task1”を実行し、割り当てられたスレッドリソースが９となり、メモリーリソースが４となる。
ストリーム２：データ“path2”をロードし、データに対してコンピューティングタスク“task2”を実行し、割り当てられたスレッドリソースが９となり、メモリーリソースが９となる。
ストリーム３：データ“path3”をロードし、データにコンピューティングタス“task3”を実行し、割り当てられたスレッドリソースが４となり、メモリーリソースが９となる。
ストリーム４：データ“path4”をロードし、データにコンピューティングタスク“task4”を実行し、割り当てられたスレッドリソースが１０となり、メモリーリソースが１０となる。
ただし、ストリーム１、ストリーム２、ストリーム３を検査すると、中間結果及びコンピューティングタスクメタデータが存在している場合に、直接に、それに対応するステップからタスクをコンピューティングし始める。
（５）：ストリーム処理されているタスクについて、
Figure 2022508354000107
 Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．Ｃｈｅｃｋ Ｐｏｉｎｔｉｎｇ（Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．Ｃｈｅｃｋ ＰｏｉｎｔｉｎｇがＳｐａｒｋフレームワークにおけるストリーム処理タスクのデータ持続化命令インタフェースである）により、ストリーム処理過程におけるＨＤＦＳへのデータの読み取り、データの前処理キャッシュ、コンピューティング、戻りという四つのステップにおいて、データストリームを持続化させる操作を実行し、中間結果及びコンピューティングタスクメタデータをｐａｔｈ１、ｐａｔｈ２、ｐａｔｈ３、ｐａｔｈ４に記憶し、同時に、キューの更新状況を監視し、キューの更新を監視した場合に、Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．ｓｔｏｐ（Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．ｓｔｏｐがＳｐａｒｋフレームワークにおけるストリーム処理タスクの中止命令インタフェースである）により、当該ストリームを停止させ、ステップ（４）に戻り、ストリーム処理におけるコンピューティングタスクが完了した場合に、当該ストリーム処理タスクに対応するクライアントに、タスク処理結果を返し、タスクをキューＱから取り出す。 The following shows one specific example of applying the stream processing method of multi-center data co-computing based on Spark according to the present invention on a multi-center medical data co-computing platform. , Specifically, including the following steps.
Step (1): Build a RESTFul service on a client (three hospitals) and a computing terminal (data center), and use the following formula for the computing task queue.
Figure 2022508354000072
 L = 3, and the third hospital "hospital3" sends one new computing task request "task4" to the computing terminal, and the request is sent to the computing thread resource request 16 and the computing memory. Request 16, the data "path4" to be computed corresponding to the task is included.
Step (2): The computing terminal analyzes the computing task request sent from the client ci , and then
Figure 2022508354000073
To get.
Step (3): The computing terminal
Figure 2022508354000074
As one element, the computing task queue
Figure 2022508354000075
Insert in.
Figure 2022508354000076
 After that, the Scheduling calculation is started, and in the Scheduling calculation, the value of the computing request of each element in the task queue Q is optimized according to the maximin standard for each client, and the nt k and nm k of each element are updated to the queue Q. The value of becomes the following formula,
Figure 2022508354000077
 However, the flow of Scheduling calculation is as follows.
Step (3.1): About the next queue
Figure 2022508354000078
 When L is the length of the computing queue Q, L = 4, and there are multiple records in the client "hospital2", first, the addition is performed according to the client, and the following equation is obtained.
Figure 2022508354000079
 L mid is the Q mid length, and L mid = 3.
Step (3.2): For thread resources, the flow of optimization allocation is executed as follows.
Step (3.2.1): Total number of thread resource requests for all clients [8,12,16] sorted by size [8,12,16] and subscript mapping M = [1,2] If, 3] is acquired and the total thread resource of the computing resource pool of the computing center is NT = 32, the resource given to [8,12,16] in advance becomes [10,10,12].
Step (3.2.2):
Figure 2022508354000080
If is present, then this set
Figure 2022508354000081
Then, the process proceeds to step (3.2.3).
Step (3.2.3): Thread resource that needs to be reassigned
Figure 2022508354000082
However,
Figure 2022508354000083
Is the number of elements of J,
Figure 2022508354000084
Then, the process returns to step (3.2.2).
Step (3.2.2):
Figure 2022508354000085
If does not exist, the final thread resource allocation policy
Figure 2022508354000086
And by subscript mapping, the memory resource allocation policy corresponding to the order to return before sorting
Figure 2022508354000087
Is acquired, and the process proceeds to step (3.2.4).
Step (3.2.4): Task on the same "hospital2"
Figure 2022508354000088
To correspond.
Step (3.3): For the memory resource, the flow of optimization allocation is executed as follows.
Step (3.3.1): Total memory resource request queue for all clients
Figure 2022508354000089
Sort by size,
Figure 2022508354000090
And subscript mapping M =
Figure 2022508354000091
And get the total memory resources of the compute resource pool in the compute center
Figure 2022508354000092
, In advance
Figure 2022508354000093
The resources given to
Figure 2022508354000094
Will be.
Step (3.3.2):
Figure 2022508354000095
If exists, this set,
Figure 2022508354000096
Then, the process proceeds to step (3.3.3).
Step (3.3.3): Memory resources that need to be reallocated
Figure 2022508354000097
， ，
Figure 2022508354000098
However,
Figure 2022508354000099
Is the number of elements of J, and returns to step (3.3.2).
Step (3.3.2):
Figure 2022508354000100
If does not exist, the final thread resource allocation policy
Figure 2022508354000101
And by subscript mapping, the memory resource allocation policy corresponding to the order to return before sorting
Figure 2022508354000102
Is acquired, and the process proceeds to step (3.3.4).
Step (3.3.4): Task on the same “hospital2”
Figure 2022508354000103
， ，
Figure 2022508354000104
To correspond.
Step (3.4): From the [nt k ] and [nm k ] obtained in step (3.2) and step (3.3), the following equation is reconstructed.
Figure 2022508354000105
 Step (4): Compute the length of the compute queue Q,
Figure 2022508354000106
With 4 as the circulation boundary condition, Spark. Four streams are created by the Streaming Context (Spark. Streaming Context is an instruction interface for creating a stream processing task in the Spark framework), and Spark. Conf (Spark.Conf is the placement instruction interface for stream processing tasks in the Spark framework) declares the resources assigned to each stream and sequentially sends the actual stream tasks to Spark.
Stream 1: Load the data "path1", execute the computing task "task1" on the data, the allocated thread resource becomes 9, and the memory resource becomes 4.
Stream 2: The data “path2” is loaded, the computing task “task2” is executed on the data, the allocated thread resource becomes 9, and the memory resource becomes 9.
Stream 3: The data “path3” is loaded, the computing task “task3” is executed on the data, the allocated thread resource becomes 4, and the memory resource becomes 9.
Stream 4: Load the data "path4", execute the computing task "task4" on the data, the allocated thread resource becomes 10, and the memory resource becomes 10.
However, when the stream 1, stream 2, and stream 3 are inspected, if intermediate results and computing task metadata are present, the task is directly started to be computed from the corresponding step.
(5): For tasks that are being streamed
Figure 2022508354000107
 Streaming Context. Check Pointing (Streaming Context. Check Pointing is the data sustaining instruction interface for stream processing tasks in the Spark framework) allows the data to be read into HDFS during the stream processing process, data preprocessing cache, computing, and return. In one step, perform operations to sustain the data stream, store intermediate results and computing task metadata in path1, path2, path3, path4, and at the same time monitor queue updates and monitor queue updates. If you do, Streaming Context. When the stream is stopped by stop (Streaming Context.stop is the stop instruction interface of the stream processing task in the Spark framework), the process returns to step (4), and the computing task in the stream processing is completed, the stream is concerned. The task processing result is returned to the client corresponding to the processing task, and the task is fetched from the queue Q.

以上は、本発明の実施例に過ぎず、本発明の保護範囲を限定するものではない。本発明の趣旨及び原則を逸脱しない限り創造的労働を経ずに行われたいかなる修正、均等置換や改良などは、いずれも本発明の保護範囲に含まれる。
The above is only an embodiment of the present invention and does not limit the scope of protection of the present invention. Any modifications, even substitutions or improvements made without creative labor, as long as they do not deviate from the spirit and principles of the invention, are all within the scope of the invention.

Claims (2)

Ｓｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法であって、
当該方法は、マルチセンターのデータ協調コンピューティングシステムで実施されるものであり、前記マルチセンターのデータ協調コンピューティングシステムは、複数のクライアント及び一つのコンピューティング端末を含み、前記クライアントは、ユーザーによるコンピューティングタスク要求を生成してコンピューティング端末に送信するためのものであり、前記コンピューティング端末は、要求を解析して、コンピューティング命令を生成して実行するためのものであり、
当該方法は、
クライアント及びコンピューティング端末にＲＥＳＴＦｕｌサービスを構築し、コンピューティングタスクキューを
Figure 2022508354000108
とし、ＬがコンピューティングタスクキューＱの長さであり、いずれか一つのクライアントｃｋがコンピューティング端末に一つの新たなコンピューティングタスク要求ｔｋを送信し、当該要求には、コンピューティングのスレッドリソース要求ｎｔｋ、メモリーをコンピューティングする要求ｎｍｋ、このタスクに対応するコンピューティングすべきデータＤｋを含む、ステップ（１）と、
コンピューティング端末は、クライアントｃｋから送信されたコンピューティングタスク要求を解析して、
Figure 2022508354000109
を取得する、ステップ（２）と、
コンピューティング端末は、
Figure 2022508354000110
を一つのエレメントとして、コンピューティングタスクキューＱに挿入してから、Ｓｃｈｅｄｕｌｉｎｇ計算を始め、Ｓｃｈｅｄｕｌｉｎｇ計算では、タスクキューＱにおける各エレメントのコンピューティング要求の値をクライアントを単位とするマクシミン規準に従って最適化し、各エレメントのｎｔｋ及びｎｍｋを更新する、ステップ（３）と、
キューＱの長さ
Figure 2022508354000111
をコンピューティングし、Ｌを循環境界条件として、Ｓｐａｒｋ．Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔにより、Ｌ個のストリームを作成し、Ｓｐａｒｋ．Ｃｏｎｆにより各ストリームに割り当てられたリソースを宣言し、Ｓｐａｒｋに実際のストリームタスクｋを順次送信することについて、データＤｋをロードし、コンピューティングタスクｔｋを実行し、コンピューティングのスレッドリソース要求ｎｔｋが満たされるスレッド数を割り当て、コンピューティングメモリーが満たされる要求ｎｍｋを割り当て、ただし、Ｄｋに中間結果及びコンピューティングタスクメタデータが存在すれば、直接に、それに対応するステップからタスクをコンピューティングし始める、ステップ（４）と、
ストリーム処理されているタスク
Figure 2022508354000112
について、Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．Ｃｈｅｃｋ Ｐｏｉｎｔｉｎｇにより、ストリーム処理過程におけるＨＤＦＳへのデータの読み取り、データの前処理キャッシュ、コンピューティング、戻りという四つのステップにおいて、データストリームを持続化させる操作を実行し、中間結果及びコンピューティングタスクメタデータをＤlに記憶し、同時に、キューの更新状況を監視し、キューの更新を監視した場合、Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｅｘｔ．ｓｔｏｐにより、当該ストリームを停止させ、ステップ（４）に戻り、ストリーム処理過程におけるコンピューティングタスクが完了した場合に、当該ストリーム処理タスクに対応するクライアントにタスク処理結果を返し、タスクをキューＱから取り出す、ステップ（５）と、を含むことを特徴とするＳｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法。 A stream processing method for multi-center data co-computing based on Spark.
The method is carried out in a multi-center data co-computing system, wherein the multi-center data co-computing system includes a plurality of clients and one computing terminal, wherein the clients are computing by a user. It is for generating an ing task request and sending it to a computing terminal, and the computing terminal is for analyzing a request to generate and execute a computing instruction.
The method is
Build RESTFul services on clients and computing terminals and create computing task queues
Figure 2022508354000108
L is the length of the computing task queue Q, and any one of the client c k sends one new computing task request t k to the computing terminal, and the request is sent to the computing thread. Step (1), which includes a resource request nt k , a memory computing request nm k , and a computeable data D k corresponding to this task.
The computing terminal analyzes the computing task request sent from the client ck , and the computing terminal analyzes the computing task request.
Figure 2022508354000109
To get step (2) and
Computing terminals
Figure 2022508354000110
Is inserted into the computing task queue Q as one element, and then the Scheduling calculation is started. In the Scheduling calculation, the value of the computing request of each element in the task queue Q is optimized according to the Maximin standard for each client. Step (3), which updates nt k and nm k of each element,
Cue Q length
Figure 2022508354000111
With L as the circular boundary condition, Spark. By Streaming Context, L streams were created, and Spark. For declaring the resources allocated to each stream by Conf and sequentially sending the actual stream task k to Spark, load the data Dk , execute the computing task tk, and request the computing thread resource nt. Allocate the number of threads that satisfy k , allocate the required nm k that compute memory is satisfied, but if D k has intermediate results and compute task metadata, compute the task directly from the corresponding step. Start ing, step (4),
Tasks being streamed
Figure 2022508354000112
About, Streaming Context. Check Pointing performs operations to sustain the data stream in four steps: reading the data to the HDFS during the stream processing process, preprocessing data cache, computing, and returning, with intermediate results and computing task metadata. Is stored in D l , and at the same time, the update status of the queue is monitored, and when the update of the queue is monitored, Streaming Context. By stop, the stream is stopped, the process returns to step (4), and when the computing task in the stream processing process is completed, the task processing result is returned to the client corresponding to the stream processing task, and the task is fetched from the queue Q. , Step (5), and a Spark-based multicenter data co-computing stream processing method comprising. 前記ステップ（３）において、クライアントに基づくＳｃｈｅｄｕｌｉｎｇ計算の流れは、以下の通りであり、
ステップ（３．１）：キュー
Figure 2022508354000113
であり、ＬがコンピューティングキューＱの長さであることについて、クライアントに複数の記録が存在している場合に、まず、クライアントに従って加算し、クライアントを単位とする新たなキュー
Figure 2022508354000114
を取得し、ＬｍｉｄがＱｍｉｄ長さであり、ｓｊが各クライアントによって送信されたタスク総数であり、ｎｔｊ mid、ｎｍｊ midがそれぞれクライアントｃｊによって要求されたスレッドリソース総数及びメモリーリソース総数であり、
ステップ（３．２）：スレッドリソースについて、以下のように最適化割り当ての流れを実行しており、
ステップ（３．２．１）：すべてのクライアントのスレッドリソース要求総数キュー
Figure 2022508354000115
について、サイズに従ってソートして
Figure 2022508354000116
及び添え字マッピングM=
Figure 2022508354000117
を取得し、コンピューティングセンターのコンピューティングリソースプールの総スレッドリソースをＮＴとすると、予めｎｔｊ midに与えられるリソースが
Figure 2022508354000118
となり、
ステップ（３．２．２）：
Figure 2022508354000119
が存在している場合に、この集合が
Figure 2022508354000120
とし、ステップ（３．２．３）に移行し、それ以外の場合は、最終的なスレッドリソース割り当てポリシー
Figure 2022508354000121
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するスレッドリソース割り当てポリシー
Figure 2022508354000122
を取得し、ステップ（３．２．４）に移行し、
ステップ（３．２．３）：再割り当てする必要があるスレッドリソースが
Figure 2022508354000123
であり、ただし、
Figure 2022508354000124
がＪのエレメントの数であり、ステップ（３．２．２）に戻り、
ステップ（３．２．４）：同じクライアントに割り当てられたスレッドリソースを、当該クライアントと対応するすべてのタスクに均一に割り当て、同じｃｊにタスク
Figure 2022508354000125
を対応させ、ただし、
Figure 2022508354000126
がユーザーｃｊが実際に提出した一つのタスクｔｚに割り当てられたスレッドリソースであり、ｎｔｊ ｍｉｄがステップ（３．２．２）で得られた当該ユーザーに割り当てられたすべてのスレッドリソースであり、ｓｊがユーザーｃｊによって送信されたタスクの総数であり、
ステップ（３．３）：メモリーリソースについて、以下のように最適化割り当ての流れを実行しており、
ステップ（３．３．１）：すべてのクライアントのメモリーリソース要求総数キュー
Figure 2022508354000127
について、サイズに従ってソートして、
Figure 2022508354000128
及び添え字マッピングM=
Figure 2022508354000129
を取得し、コンピューティングセンターのコンピューティングリソースプールの総メモリーリソースをＮＭとすると、予めｎｍｊ midに与えられるリソースが
Figure 2022508354000130
となり、
ステップ（３．３．２）：
Figure 2022508354000131
が存在している場合に、この集合を
Figure 2022508354000132
として、ステップ（３．２．３）に移行し、それ以外の場合は、最終的なメモリーリソース割り当てポリシー
Figure 2022508354000133
を出力し、添え字マッピングにより、ソートする前に戻す順序に対応するメモリーリソース割り当てポリシー
Figure 2022508354000134
を取得し、ステップ（３．２．４）に移行し、
ステップ（３．３．３）：再割り当てする必要があるメモリーリソースが
Figure 2022508354000135
であり、ただし、
Figure 2022508354000136
がＪのエレメントの数であり、ステップ（３．３．２）に戻り、
ステップ（３．３．４）：同じクライアントに割り当てられたメモリーリソースを当該クライアントと対応するすべてのタスクに均一に割り当て、同一ｃｊにタスク
Figure 2022508354000137
，
Figure 2022508354000138
を対応させ、ただし、
Figure 2022508354000139
がユーザーｃｊが実際に提出した一つのタスクｔｚに割り当てられたメモリーリソースであり、ｎｍｊ midがステップ（３．２．２）で得られた当該ユーザーに割り当てられたすべてのメモリーリソースであり、ｓｊがユーザーｃｊによって送信されたタスクの総数であり、
ステップ（３．４）：ステップ（３．２）及びステップ（３．３）で得られた［ｎｔｋ］及び［ｎｍｋ］から、
Figure 2022508354000140
］を再構成することを特徴とする請求項１に記載のＳｐａｒｋに基づくマルチセンターのデータ協調コンピューティングのストリーム処理方法。
In step (3), the flow of Scheduling calculation based on the client is as follows.
Step (3.1): Queue
Figure 2022508354000113
If there are multiple records in the client regarding that L is the length of the computing queue Q, first, the queue is added according to the client, and a new queue in the client unit.
Figure 2022508354000114
Is obtained, L mid is the Q mid length, s j is the total number of tasks sent by each client, and nt j mid and nm j mid are the total number of thread resources and memory resources requested by the client c j , respectively. Is the total number
Step (3.2): For thread resources, the flow of optimization allocation is executed as follows.
Step (3.2.1): Total number of thread resource requests queue for all clients
Figure 2022508354000115
Sort by size
Figure 2022508354000116
And subscript mapping M =
Figure 2022508354000117
And if the total thread resource of the computing resource pool of the computing center is NT, the resource given to nt j mid in advance is
Figure 2022508354000118
And
Step (3.2.2):
Figure 2022508354000119
If is present, then this set
Figure 2022508354000120
And move to step (3.2.3), otherwise the final thread resource allocation policy
Figure 2022508354000121
Thread resource allocation policy corresponding to the order to return before sorting by subscript mapping
Figure 2022508354000122
Is obtained, and the process proceeds to step (3.2.4).
Step (3.2.3): Thread resource that needs to be reassigned
Figure 2022508354000123
However,
Figure 2022508354000124
Is the number of elements of J, returning to step (3.2.2),
Step (3.2.4): Thread resources assigned to the same client are evenly allocated to all tasks corresponding to the client, and tasks are assigned to the same cj .
Figure 2022508354000125
However,
Figure 2022508354000126
Is the thread resource assigned to one task t z actually submitted by the user c j , and nt j mid is all the thread resources assigned to the user obtained in step (3.2.2). Yes, s j is the total number of tasks sent by user c j ,
Step (3.3): For memory resources, the flow of optimization allocation is executed as follows.
Step (3.3.1): Total memory resource request queue for all clients
Figure 2022508354000127
Sort by size,
Figure 2022508354000128
And subscript mapping M =
Figure 2022508354000129
And if the total memory resource of the computing resource pool of the computing center is NM, the resource given to nm j mid in advance is
Figure 2022508354000130
And
Step (3.3.2):
Figure 2022508354000131
If is present, then this set
Figure 2022508354000132
As a result, move to step (3.2.3), otherwise the final memory resource allocation policy.
Figure 2022508354000133
And by subscript mapping, the memory resource allocation policy corresponding to the order to return before sorting
Figure 2022508354000134
Is obtained, and the process proceeds to step (3.2.4).
Step (3.3.3): Memory resources that need to be reallocated
Figure 2022508354000135
However,
Figure 2022508354000136
Is the number of elements of J, returning to step (3.3.2),
Step (3.3.4): Allocate memory resources allocated to the same client evenly to all tasks corresponding to the client, and tasks to the same cj .
Figure 2022508354000137
， ，
Figure 2022508354000138
However,
Figure 2022508354000139
Is the memory resource allocated to one task t z actually submitted by user c j , and nm j mid is all memory resources allocated to that user obtained in step (3.2.2). Yes, s j is the total number of tasks sent by user c j ,
Step (3.4): From [nt k ] and [nm k ] obtained in step (3.2) and step (3.3).
Figure 2022508354000140
] The stream processing method of the multi-center data co-computing based on Spark according to claim 1.
JP2021533418A 2019-07-12 2020-04-07 Stream processing method for multi-center data co-computing based on Spark Active JP6990802B1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201910629253.8 2019-07-12
CN201910629253.8A CN110347489B (en) 2019-07-12 2019-07-12 Multi-center data collaborative computing stream processing method based on Spark
PCT/CN2020/083593 WO2020233262A1 (en) 2019-07-12 2020-04-07 Spark-based multi-center data collaborative computing stream processing method

Publications (2)

Publication Number Publication Date
JP6990802B1 JP6990802B1 (en) 2022-01-12
JP2022508354A true JP2022508354A (en) 2022-01-19

Family

ID=68176115

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021533418A Active JP6990802B1 (en) 2019-07-12 2020-04-07 Stream processing method for multi-center data co-computing based on Spark

Country Status (3)

Country Link
JP (1) JP6990802B1 (en)
CN (1) CN110347489B (en)
WO (1) WO2020233262A1 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110347489B (en) * 2019-07-12 2021-08-03 之江实验室 Multi-center data collaborative computing stream processing method based on Spark
CN110955526B (en) * 2019-12-16 2022-10-21 湖南大学 Method and system for realizing multi-GPU scheduling in distributed heterogeneous environment
CN115081936B (en) * 2022-07-21 2022-11-18 之江实验室 Method and device for scheduling observation tasks of multiple remote sensing satellites under emergency condition
CN115242877B (en) * 2022-09-21 2023-01-24 之江实验室 Spark collaborative computing and operating method and device for multiple K8s clusters
US11954525B1 (en) 2022-09-21 2024-04-09 Zhejiang Lab Method and apparatus of executing collaborative job for spark faced to multiple K8s clusters

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101009642A (en) * 2006-12-31 2007-08-01 华为技术有限公司 A resource allocation method and device based on the task packet
US20160335135A1 (en) * 2015-05-14 2016-11-17 Tmaxsoft. Co., Ltd. Method for minimizing lock contention among threads when tasks are distributed in multithreaded system and appratus using the same
US20170060641A1 (en) * 2015-08-28 2017-03-02 Vmware, Inc. Pluggable Engine for Application Specific Schedule Control
CN107870763A (en) * 2017-11-27 2018-04-03 深圳市华成峰科技有限公司 For creating the method and its device of the real-time sorting system of mass data

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105335376B (en) * 2014-06-23 2018-12-07 华为技术有限公司 A kind of method for stream processing, apparatus and system
US9575749B1 (en) * 2015-12-17 2017-02-21 Kersplody Corporation Method and apparatus for execution of distributed workflow processes
CN105930373A (en) * 2016-04-13 2016-09-07 北京思特奇信息技术股份有限公司 Spark streaming based big data stream processing method and system
US10554577B2 (en) * 2017-03-14 2020-02-04 International Business Machines Corporation Adaptive resource scheduling for data stream processing
CN107193652B (en) * 2017-04-27 2019-11-12 华中科技大学 The flexible resource dispatching method and system of flow data processing system in container cloud environment
CN107291843A (en) * 2017-06-01 2017-10-24 南京邮电大学 Hierarchical clustering improved method based on Distributed Computing Platform
CN108037998B (en) * 2017-12-01 2019-05-24 北京工业大学 A kind of data receiving channel dynamic allocation method towards Spark Streaming platform
CN108804211A (en) * 2018-04-27 2018-11-13 西安华为技术有限公司 Thread scheduling method, device, electronic equipment and storage medium
CN109684078A (en) * 2018-12-05 2019-04-26 苏州思必驰信息科技有限公司 Resource dynamic distributing method and system for spark streaming
CN110347489B (en) * 2019-07-12 2021-08-03 之江实验室 Multi-center data collaborative computing stream processing method based on Spark

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101009642A (en) * 2006-12-31 2007-08-01 华为技术有限公司 A resource allocation method and device based on the task packet
US20160335135A1 (en) * 2015-05-14 2016-11-17 Tmaxsoft. Co., Ltd. Method for minimizing lock contention among threads when tasks are distributed in multithreaded system and appratus using the same
US20170060641A1 (en) * 2015-08-28 2017-03-02 Vmware, Inc. Pluggable Engine for Application Specific Schedule Control
CN107870763A (en) * 2017-11-27 2018-04-03 深圳市华成峰科技有限公司 For creating the method and its device of the real-time sorting system of mass data

Also Published As

Publication number Publication date
JP6990802B1 (en) 2022-01-12
WO2020233262A1 (en) 2020-11-26
CN110347489B (en) 2021-08-03
CN110347489A (en) 2019-10-18

Similar Documents

Publication Publication Date Title
JP6990802B1 (en) Stream processing method for multi-center data co-computing based on Spark
Le et al. Allox: compute allocation in hybrid clusters
US11294726B2 (en) Systems, methods, and apparatuses for implementing a scalable scheduler with heterogeneous resource allocation of large competing workloads types using QoS
EP3425502B1 (en) Task scheduling method and device
Shi et al. MDP and machine learning-based cost-optimization of dynamic resource allocation for network function virtualization
JP6165777B2 (en) Computing system, computer storage memory, and computer-implemented method for automatic scaling
US9389995B2 (en) Optimization of Map-Reduce shuffle performance through snuffler I/O pipeline actions and planning
JP3944154B2 (en) Method and system for dynamically adjusting a thread pool in a multi-threaded server
US8935404B2 (en) Saving program execution state
JP6254949B2 (en) Pricing resources in virtual machine pools
US9710253B2 (en) Managing a software-patch submission queue
US20140379722A1 (en) System and method to maximize server resource utilization and performance of metadata operations
Tumanov et al. alsched: Algebraic scheduling of mixed workloads in heterogeneous clouds
Chard et al. Cost-aware cloud provisioning
US20200174844A1 (en) System and method for resource partitioning in distributed computing
US11146654B2 (en) Multitier cache framework
US11182217B2 (en) Multilayered resource scheduling
Huang et al. Achieving load balance for parallel data access on distributed file systems
CA2758732A1 (en) Server architecture for multi-core systems
Jonathan et al. Awan: Locality-aware resource manager for geo-distributed data-intensive applications
Shin et al. Data jockey: Automatic data management for HPC multi-tiered storage systems
Sreedhar et al. A survey on big data management and job scheduling
Ivanov et al. Improving efficiency of analysis jobs in CMS
Jordan et al. Wrangler's user environment: A software framework for management of data-intensive computing system
Samuel et al. Scheduling diverse high performance computing systems with the goal of maximizing utilization

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210610

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20210624

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20211112

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211206

R150 Certificate of patent or registration of utility model

Ref document number: 6990802

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150