本發(fā)明涉及數(shù)據(jù)處理領(lǐng)域，尤其涉及一種基于HDFS系統(tǒng)的文件合并方法及裝置。

背景技術(shù)：

HDFS(Hadoop分布式文件系統(tǒng))為用于存儲大數(shù)據(jù)的文件存儲系統(tǒng)。SPARK集群由一個NameNode(名字服務(wù)節(jié)點)和若干個DataNode(數(shù)據(jù)存儲節(jié)點)組成。其中，NameNode提供元數(shù)據(jù)服務(wù)，管理Block的分配，維護整個文件系統(tǒng)的目錄樹結(jié)構(gòu)；DataNode則部署在SPARK集群中的其他服務(wù)器上，提供真正的數(shù)據(jù)存儲服務(wù)。由于每個小文件都要在DataNode中占獨立的數(shù)據(jù)塊，因此，當海量的流式數(shù)據(jù)以小文件的形式存儲到SPARK集群中時，將浪費大量的存儲空間，且NameNode中也將存儲這些流式數(shù)據(jù)的相關(guān)信息，增大了查詢壓力。

為解決上述問題，現(xiàn)階段的操作為，從默認數(shù)據(jù)塊中讀取前一天存儲的文件，合并讀取的文件，將合并后的文件存儲到臨時數(shù)據(jù)塊，再從臨時區(qū)塊讀取合并后的文件，將合并后的文件回寫到默認數(shù)據(jù)塊中，與此同時覆蓋原來存儲的文件。

綜上所述，根據(jù)現(xiàn)階段的操作可知，對存儲的所有數(shù)據(jù)至少要進行五步操作，流程由于對大量的小文件數(shù)據(jù)進行讀寫，將給HDFS系統(tǒng)造成很大的壓力較為繁瑣，而且若回寫時出現(xiàn)故障，可能將導致存儲的文件丟失，容錯性較差。

技術(shù)實現(xiàn)要素：

本發(fā)明實施例提供了一種基于HDFS系統(tǒng)的文件合并方法及裝置，通過更新映射關(guān)系的方式，而非將合并后文件回寫到原集合中，從而省去了回寫步驟，精簡了合并流程，提高合并的效率；由于本申請保留有待合并文件和合并后文件，也提升了系統(tǒng)的容錯性。

本發(fā)明實施例提供的一種基于HDFS系統(tǒng)的文件合并方法，包括：

根據(jù)預設(shè)的生成待合并文件的時間區(qū)間，以及所述時間區(qū)間與包括所述待合并文件的待合并集合的映射關(guān)系，確定所述待合并集合；

合并確定的待合并集合中的待合并文件，并將生成的合并后文件存儲至合并后集合中；

將所述映射關(guān)系更新為所述時間區(qū)間與所述合并后集合的映射關(guān)系。

本發(fā)明實施例中，通過更新映射關(guān)系的方式，而非將合并后文件回寫到原集合中，從而省去了回寫步驟，精簡了合并流程，提高了合并效率；而且，本申請保留有待合并文件和合并后文件，提升了系統(tǒng)的容錯性。

較佳地，該方法還包括：

若所述待合并文件中小文件的占比不小于預設(shè)占比門限值，或者所述待合并文件中小文件的數(shù)量不小于預設(shè)數(shù)量門限值，或者所述映射關(guān)系中的文件集合為所述待合并集合，則對所述待合并文件進行合并操作；其中，所述小文件為所占空間小于預設(shè)門限值的文件，其中，所述預設(shè)門限值為根據(jù)所述數(shù)據(jù)存儲節(jié)點的大小確定的。

本發(fā)明實施例中，通過比較小文件的占比或者數(shù)量，或者通過映射關(guān)系中的文件集合是否為待合并集合的方式，來確定是否需要對待合并文件進行合并操作，盡可能最大化利用Spark集群的計算核資源，提升合并效率。

較佳地，該方法還包括：

合并確定的待合并集合中的待合并文件，包括：

根據(jù)Spark集群的計算核的數(shù)目，確定讀取所述待合并文件的分區(qū)的個數(shù)；

根據(jù)確定的分區(qū)的個數(shù)，對所述待合并文件進行讀取；

分別針對每一分區(qū)中的待合并文件執(zhí)行并發(fā)合并操作。

本發(fā)明實施例中，根據(jù)Spark集群的計算核的數(shù)量，確定讀取待合并文件的分區(qū)的個數(shù)，并調(diào)用Repartition函數(shù)對所述待合并文件進行讀取，調(diào)用Executor函數(shù)對每一分區(qū)中待合并文件執(zhí)行合并操作，從而實現(xiàn)每一計算核至少對應(yīng)一個分區(qū)，即通過多個進程同時對待合并文件讀取與合并，提升讀取與合并效率，提高了Spark集群的計算資源的利用率。

較佳地，所述時間區(qū)間為以小時為單位劃分得到的。

本發(fā)明實施例中，將存儲映射關(guān)系的HIVE表(基于Hadoop的數(shù)據(jù)倉庫工具)的分區(qū)細化到以小時為單位，從而解決了現(xiàn)有技術(shù)中以天為單位進行分區(qū)導致的合并文件延遲的問題。

較佳地，該方法還包括：

檢測所述映射關(guān)系是否為所述時間區(qū)間與所述合并后集合的映射關(guān)系；若是，則刪除所述待合并文件。

本發(fā)明實施例中，通過刪除待合并集合的數(shù)據(jù)文件，釋放存儲空間，使得HDFS系統(tǒng)的存儲利用率最大化。

本發(fā)明實施例提供的一種基于HDFS系統(tǒng)的文件合并裝置，包括：

讀取模塊，用于根據(jù)預設(shè)的生成待合并文件的時間區(qū)間，以及所述時間區(qū)間與包括所述待合并文件的待合并集合的映射關(guān)系，確定所述待合并集合；

合并模塊，用于合并確定的待合并集合中的待合并文件，并將生成的合并后文件存儲至合并后集合中；

更新模塊，用于將所述映射關(guān)系更新為所述時間區(qū)間與所述合并后集合的映射關(guān)系。

本發(fā)明實施例中，通過更新映射關(guān)系的方式，而非將合并后文件回寫到原集合中，從而省去了回寫步驟，精簡了合并流程，提高了合并效率；而且，本申請保留有待合并文件和合并后文件，提升了系統(tǒng)的容錯性。

較佳地，所述合并模塊還用于：

若所述待合并文件中小文件的占比不小于預設(shè)占比門限值，或者所述待合并文件中小文件的數(shù)量不小于預設(shè)數(shù)量門限值，或者所述映射關(guān)系中的文件集合為所述待合并集合，則對所述待合并文件進行合并操作；其中，所述小文件為所占空間小于預設(shè)門限值的文件，其中，所述預設(shè)門限值為根據(jù)所述數(shù)據(jù)存儲節(jié)點的大小確定的。

本發(fā)明實施例中，通過比較小文件的占比或者數(shù)量，或者通過映射關(guān)系中的文件集合是否為待合并集合的方式，來確定是否需要對待合并文件進行合并操作，盡可能最大化利用Spark集群的計算核資源，提升合并效率。

較佳地，所述合并模塊還用于：

確定讀取所述待合并文件的分區(qū)的個數(shù)，其中，所述分區(qū)的個數(shù)為根據(jù)Spark集群的計算核的數(shù)目確定的；

根據(jù)確定的分區(qū)的個數(shù)，對所述待合并文件進行讀取；

分別針對每一分區(qū)中的待合并文件執(zhí)行并發(fā)合并操作。

本發(fā)明實施例中，根據(jù)Spark集群的計算核的數(shù)量，確定讀取待合并文件的分區(qū)的個數(shù)，并調(diào)用Repartition函數(shù)對所述待合并文件進行讀取，調(diào)用Executor函數(shù)對每一分區(qū)中待合并文件執(zhí)行合并操作，從而實現(xiàn)每一計算核至少對應(yīng)一個分區(qū)，即通過多個進程同時對待合并文件讀取與合并，提升讀取與合并效率，提高了Spark集群的計算資源的利用率。

較佳地，所述時間區(qū)間為以小時為單位劃分得到的。

本發(fā)明實施例中，將存儲映射關(guān)系的HIVE表(基于Hadoop的數(shù)據(jù)倉庫工具)的分區(qū)細化到以小時為單位，從而解決了現(xiàn)有技術(shù)中以天為單位進行分區(qū)導致的合并文件延遲的問題。

較佳地，所述更新模塊還用于：

檢測所述映射關(guān)系是否為所述時間區(qū)間與所述合并后集合的映射關(guān)系；若是，則刪除所述待合并文件。

本發(fā)明實施例中，通過刪除待合并集合的數(shù)據(jù)文件，釋放存儲空間，使得HDFS系統(tǒng)的存儲利用率最大化。

本發(fā)明實施例通過更新映射關(guān)系中所述時間區(qū)間對應(yīng)的集合，而非將合并后文件回寫到原集合中，從而省去了回寫步驟，精簡了合并流程，提高了合并效率；由于保留有待合并文件和合并后文件，也提升了系統(tǒng)的容錯性；根據(jù)Spark集群的計算核的數(shù)量，確定讀取待合并文件的分區(qū)的個數(shù)，并調(diào)用Repartition函數(shù)對所述待合并文件進行讀取，調(diào)用Executor函數(shù)對每一分區(qū)中待合并文件執(zhí)行合并操作，從而實現(xiàn)每一計算核至少對應(yīng)一個分區(qū)，即通過多個進程同時對待合并文件讀取與合并，提升讀取與合并效率，提高了Spark集群的計算資源的利用率。

附圖說明

圖1為本發(fā)明實施例一提供的一種基于HDFS系統(tǒng)的文件合并方法的流程示意圖；

圖2為本發(fā)明實施例二提供的一種基于HDFS系統(tǒng)的文件合并方法的流程示意圖；

圖3為本發(fā)明實施例三提供的一種基于HDFS系統(tǒng)的文件合并方法的流程示意圖；

圖4為本發(fā)明實施例四提供的一種基于HDFS系統(tǒng)的文件合并方法的流程示意圖；

圖5為本發(fā)明實施例五提供的一種基于HDFS系統(tǒng)的文件合并方法的流程示意圖；

圖6為本發(fā)明實施例六提供的一種基于HDFS系統(tǒng)的文件合并裝置的結(jié)構(gòu)示意圖。

具體實施方式

本發(fā)明實施例提供了一種基于HDFS系統(tǒng)的文件合并方法及裝置，省去了回寫步驟，精簡了合并流程，提高合并的效率，也提升了系統(tǒng)的容錯性。

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

實施例一：

參見圖1，本發(fā)明實施例一提供了一種基于HDFS系統(tǒng)的文件合并方法，該方法包括：

S101、根據(jù)預設(shè)的生成待合并文件的時間區(qū)間，以及所述時間區(qū)間與包括所述待合并文件的待合并集合的映射關(guān)系，確定所述待合并集合；

S102、合并確定的待合并集合中的待合并文件，并將生成的合并后文件存儲至合并后集合中；

S103、將所述映射關(guān)系更新為所述時間區(qū)間與所述合并后集合的映射關(guān)系。

具體地，所述時間區(qū)間可以以小時為單位劃分，即該時間區(qū)間為每小時一時間區(qū)間；當然所述時間區(qū)間也可以以分鐘為單位劃分，此處不過多限定；此外，所述時間區(qū)間并非一定要以一小時為一時間區(qū)間進行劃分，也可以多小時為一時間區(qū)間劃分，再或者可以以前五個小時為一時間區(qū)間，后十九小時中每一小時為一時間區(qū)間劃分。通過該技術(shù)特征，進一步的降低文件合并的延遲。

也就是，步驟S101具體可為，若時間區(qū)間以每一小時一區(qū)間進行劃分，當凌晨兩點時，HDFS系統(tǒng)已成功存儲了凌晨一點到凌晨兩點的文件，此時，實時的讀取存儲的凌晨一點到凌晨兩點的文件。

或者，步驟S101具體包括：

所述預設(shè)的生成待合并文件的時間區(qū)間為，當前時間或者用戶設(shè)定的讀取待合并文件的時間。例如，用戶輸入某一歷史時間區(qū)間，確定在輸入的歷史時間區(qū)間生成的待合并文件所屬的待合并集合。

實施例二：

參見圖2，步驟S102具體包括：

S201、確定的待合并文件是否符合預設(shè)的合并條件；

S202、若符合預設(shè)的合并條件，則對符合預設(shè)的合并條件的文件進行合并操作，并將合并后的文件存儲至合并后集合中。

其中，預設(shè)的合并條件包括如下任一條即可：

若所述待合并文件中小文件的占比不小于預設(shè)占比門限值，或者所述待合并文件中小文件的數(shù)量不小于預設(shè)數(shù)量門限值，或者所述映射關(guān)系中的文件集合為所述待合并集合。

其中，所述小文件為所占空間小于預設(shè)門限值的文件，其中，所述預設(shè)門限值為根據(jù)所述數(shù)據(jù)存儲節(jié)點的大小確定的。

本發(fā)明實施例二中，通過對小文件的占比和\或數(shù)量進行比較，或者通過映射關(guān)系中的文件集合為待合并集合的方式，來確定是否需要對待合并文件進行合并操作，盡可能最大化利用Spark集群的計算核資源，提升合并效率。

實施例三：

參見圖3，在步驟S102之前，該方法還包括：

S301、根據(jù)Spark集群的計算核的數(shù)目，確定讀取待合并文件的分區(qū)的個數(shù)。

S302、根據(jù)確定的分區(qū)的個數(shù)，通過多個分區(qū)函數(shù)對待合并文件進行多線程并發(fā)讀取。

S303、通過執(zhí)行和函數(shù)(Executor)針對每一分區(qū)中的待合并文件執(zhí)行并發(fā)合并操作。

其中，所述分區(qū)函數(shù)可為：

dataframe.repartition(n).write().mode(SaveMode.Overwrite).parquet(merge_path)

其中，dataframe為數(shù)據(jù)結(jié)構(gòu)，表示已經(jīng)讀入的小文件數(shù)據(jù)的整體集合；repartition(n)為分區(qū)函數(shù)；n為待合并分區(qū)的個數(shù)或者為待合并文件的通道個數(shù)；write().mode(SaveMode.Overwrite)為覆寫模式的寫入函數(shù)；mode(SaveMode.Overwrite)為指定寫入的模式為覆寫模式；parquet(merge_path)為合并后文件的寫入路徑與文件格式；parquet(merge_path)為列式存儲。

其中，步驟S301具體為：

確定讀取待合并文件的分區(qū)的個數(shù)為Spark集群的計算核的數(shù)目，或者為Spark集群的計算核的數(shù)目的倍數(shù)。通過該技術(shù)特征，保證了每一計算核均分配到合并待合并文件的任務(wù)，提高利用Spark集群的效率，也提升了SPARK集群的可擴展性。

本發(fā)明實施例中，放棄使用SparkSQL的HQL方案，而是直接使用Dataframe的Repartition方案，避免了通過Spark中的Limit函數(shù)單點讀寫數(shù)據(jù)的速率瓶頸，即當使用Spark時只能使用一個計算核Executor，只能單進程的執(zhí)行讀取和合并操作，在本申請的方案中，針對每一RDD(Resilient Distributed Datasets，彈性分布式數(shù)據(jù)集)分區(qū)，均調(diào)用一Repartition函數(shù)對待合并文件進行讀取，并通過調(diào)用計算核Executor函數(shù)對每一RDD分區(qū)中讀取的待合并文件執(zhí)行合并操作，從而實現(xiàn)對待合并文件多個進程的讀取與合并，提升了Spark集群的計算資源的利用率，縮短了合并時間。

實施例四：

參見圖4，在步驟S103之后，該方法還包括：

S401、檢測所述映射關(guān)系是否為所述時間區(qū)間與所述合并后集合的映射關(guān)系；

S402、若是，則刪除所述待合并文件。

本發(fā)明實施例中，為避免機器故障導致的合并后文件丟失，在將待合并文件執(zhí)行合并操作之后，并未立即刪除待合并文件，即保留了待合并文件，一旦合并后文件出現(xiàn)問題可通過查找待合并集合中的文件，從而保證HDFS系統(tǒng)的容錯性。

其中，該方法還包括：

按照預設(shè)周期，執(zhí)行步驟S401。

本發(fā)明實施例中，按照預設(shè)周期檢測所述映射關(guān)系是否為所述時間區(qū)間與所述合并后集合的映射關(guān)系，若是，則刪除待合并文件，否則保留待合并文件，從而釋放部分存儲空間，提高存儲空間的利用率，提升數(shù)據(jù)的控制力。

實施例五：

為便于理解，下面將結(jié)合圖5進一步對本發(fā)明實施例五進行解釋。

S501、通過Spark Streaming的方式將輸入的文件寫入到預設(shè)的待合并集合的子待合并集合中；其中，待合并集合中的文件為以小時為單位進行劃分的，即零點到一點接收到的文件存儲到第一子待合并集合中；一點到兩點接收到的文件存儲到第二子待合并集合中；兩點到三點接收到的文件存儲到第三子待合并集合中；三點到四點接收到的文件存儲到第四子待合并集合中等，直到第二十三點到第二十四點接收到的文件存儲到第二十四子待合并集合中。

S502、當一點半時，根據(jù)確定的讀取待合并文件的RDD分區(qū)的個數(shù)，通過多個分區(qū)函數(shù)Repartition(n)從待合并集合的第一子待合并集合中對待合并文件進行n線程并發(fā)讀取待合并文件；其中，RDD分區(qū)的個數(shù)是根據(jù)Spark集群的計算核Executor的數(shù)目確定的；n為正整數(shù)。

S503、利用計算和Executor函數(shù)針對每一分區(qū)中的待合并文件執(zhí)行并發(fā)合并操作，并將合并后的文件存儲至第一子合并后集合中；其中，所述合并后集合的子集合與待合并集合的子集合為一一對應(yīng)的關(guān)系。

S504、將HIVE的Metastore元數(shù)據(jù)信息(RDBMS數(shù)據(jù)庫)中零點到一點的時間區(qū)間與第一子待合并集合的映射關(guān)系，更新為該時間區(qū)間與第一子合并后集合的映射關(guān)系；

S505、當兩點半時，再次執(zhí)行步驟S502，從第二子待合并集合中讀取待合并文件，并將合并后的文件存儲至第二子合并后集合中，依次類推。

本發(fā)明實施例中，當讀取緩存預設(shè)時間區(qū)間的待合并文件后，執(zhí)行合并操作，合并操作結(jié)束意味著合并后集合生成，此時待合并文件和合并后文件共存，從而實現(xiàn)用戶場景的切換；通過改變HIVE的Metastore的元數(shù)據(jù)信息，切換讀寫文件的路徑，在切換之后，新的文件將寫入合并后集合，直到檢測到合并后集合中確定的待合并文件符合預設(shè)的合并條件，將執(zhí)行步驟S202。由于本發(fā)明為在合并文件后立即修改HIVE的Metastore的元數(shù)據(jù)信息，從而實現(xiàn)用戶查詢HIVE系統(tǒng)中數(shù)據(jù)時感知不到變化，保證查詢性能最大化；此外，取消了將合并后文件回寫到待合并集合的步驟，進一步縮短了合并文件的時間，減少了回寫的計算資源的消耗。

為保證本發(fā)明的實用性，通過本發(fā)明實施例五提供的方案對17千萬條數(shù)據(jù)以及533個文件進行合并，合并時間為12分鐘；而通過現(xiàn)有技術(shù)的合并時間為55分鐘，因此，本發(fā)明實施例提供的方案縮短了80％的合并時間，有效的提升了合并的效率。

實施例六：

參見圖6，本發(fā)明實施例六提供了一種基于HDFS系統(tǒng)的文件合并裝置，該裝置包括：

讀取模塊601，用于根據(jù)預設(shè)的生成待合并文件的時間區(qū)間，以及所述時間區(qū)間與包括所述待合并文件的待合并集合的映射關(guān)系，確定所述待合并集合；

合并模塊602，用于合并確定的待合并集合中的待合并文件，并將生成的合并后文件存儲至合并后集合中；

更新模塊603，用于將所述映射關(guān)系更新為所述時間區(qū)間與所述合并后集合的映射關(guān)系。

具體地，所述合并模塊602還用于：

若所述待合并文件中小文件的占比不小于預設(shè)占比門限值，或者所述待合并文件中小文件的數(shù)量不小于預設(shè)數(shù)量門限值，或者所述映射關(guān)系中的文件集合為所述待合并集合，則對所述待合并文件進行合并操作；其中，所述小文件為所占空間小于預設(shè)門限值的文件，其中，所述預設(shè)門限值為根據(jù)所述數(shù)據(jù)存儲節(jié)點的大小確定的。

具體地，所述合并模塊602還用于：

確定讀取所述待合并文件的分區(qū)的個數(shù)，其中，所述分區(qū)的個數(shù)為根據(jù)Spark集群的計算核的數(shù)目確定的；

根據(jù)確定的分區(qū)的個數(shù)，對所述待合并文件進行讀?。?/p>

分別針對每一分區(qū)中的待合并文件執(zhí)行并發(fā)合并操作。

具體地，所述時間區(qū)間為以小時為單位劃分得到的。

具體地，所述更新模塊603還用于：

檢測所述映射關(guān)系是否為所述時間區(qū)間與所述合并后集合的映射關(guān)系；若是，則刪除所述待合并文件。

具體地，本發(fā)明實施例中所述讀取模塊601、合并模塊602以及更新模塊603可由處理器實現(xiàn)。

綜上所述，本發(fā)明實施例提供了一種基于HDFS系統(tǒng)的文件合并方法及裝置，通過更新映射關(guān)系中所述時間區(qū)間對應(yīng)的集合，而非將合并后文件回寫到原集合中，從而省去了回寫步驟，精簡了合并流程，提高合并的效率；根據(jù)Spark集群的計算核的數(shù)量，確定讀取待合并文件的分區(qū)的個數(shù)，并調(diào)用Repartition函數(shù)對所述待合并文件進行讀取，調(diào)用Executor函數(shù)對每一分區(qū)中待合并文件執(zhí)行合并操作，從而實現(xiàn)每一計算核至少對應(yīng)一個分區(qū)，即通過多個進程同時對待合并文件讀取與合并，提升讀取與合并效率，提高了Spark集群的計算資源的利用率；本申請通過保留待合并文件和合并后文件，從而提升了系統(tǒng)的容錯性、健壯性和穩(wěn)定性。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計算機程序產(chǎn)品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器和光學存儲器等)上實施的計算機程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備(系統(tǒng))、和計算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計算機或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。