Flink,Spark,Storm,Hadoop大數(shù)據(jù)框架比較
點擊上方“IT那活兒”，關(guān)注后了解更多精彩內(nèi)容?。。?/span>
大數(shù)據(jù)分析作為一種用于分析大量按需數(shù)據(jù)的工具，越來越受到人們的歡迎。四個最常見的大數(shù)據(jù)處理框架包括Apache Hadoop，Apache Spark，Apache Storm和Apache Flink。雖然這四個都支持大數(shù)據(jù)處理，但是這些框架的用法和支持該用法的基礎(chǔ)體系結(jié)構(gòu)不同。許多研究已經(jīng)投入了時間和精力來通過評估已定義的關(guān)鍵績效指標（KPI）來比較這些大數(shù)據(jù)框架。本文通過確定一組通用的關(guān)鍵性能指標來總結(jié)這些早期工作，這些關(guān)鍵性能指標包括處理時間，CPU消耗，延遲，吞吐量，執(zhí)行時間，可持續(xù)的輸入速率，任務(wù)性能，可伸縮性和容錯能力，并比較這四個大數(shù)據(jù)通過文獻綜述了解這些KPI的框架。與Apache Hadoop和Apache Storm框架相比，在非實時數(shù)據(jù)中Spark為多個KPI（包括處理時間，CPU消耗，延遲，執(zhí)行時間，任務(wù)性能和可伸縮性）的贏家。在流處理中Flink與Apache Spark和Apache Storm框架相比，F(xiàn)link在處理時間，CPU消耗，延遲，吞吐量，執(zhí)行時間，任務(wù)性能，可伸縮性和容錯能力方面最適合流處理。本文分為以下幾部分：下一部分將解釋大數(shù)據(jù)的主要特征，稱為大數(shù)據(jù)的維度。接下來是對一些大數(shù)據(jù)框架的討論。Hadoop，Spark，Storm和Flink。它們的類別將作為框架和所得結(jié)果之間的比較研究而呈現(xiàn)。之后，我們給出一些結(jié)論。
當我們在上一階段定義了大數(shù)據(jù)的含義時，現(xiàn)在說明其特征非常重要。它由通用的大數(shù)據(jù)需求（volume（容量）, variety (多樣性) , and velocity (速度)）組成，這些需求統(tǒng)稱為3維。最近，大數(shù)據(jù)的特性從3維演變?yōu)?維度，增加了value (價值), veracity (準確性), 和variability (可變性) 的特征。圖1 中顯示了6維的大數(shù)據(jù)。
圖1
譯者注：Volume（指數(shù)據(jù)量大）、Velocity（指數(shù)據(jù)量增加速度快）、Variety（指數(shù)據(jù)種類多樣）、Value（指數(shù)據(jù)價值密度）、Veracity（指數(shù)據(jù)真實性）、 variability（指數(shù)據(jù)源穩(wěn)定性）。A. Volume（容量）
Volume 是指數(shù)據(jù)的數(shù)量或大小。大數(shù)據(jù)的大小約為TB，PB（PB），Zettabyte（ZB）和Exabyte（EB）。Facebook，YouTube，Google和NASA等組織擁有大量數(shù)據(jù)，這給存儲，檢索，分析和處理這些數(shù)據(jù)帶來了新的挑戰(zhàn)。大數(shù)據(jù)而非傳統(tǒng)存儲的使用改變了我們傳輸數(shù)據(jù)和使用數(shù)據(jù)的方式。B. Variety (多樣性)
多樣性是指正在生成的不同類型的數(shù)據(jù)。可以使用不同的維度來衡量類型（例如結(jié)構(gòu)，使我們能夠區(qū)別結(jié)構(gòu)化，半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，或批處理與流處理的處理量）C. Variability (可變性)
可變性是指不穩(wěn)定，難以處理且難以管理的數(shù)據(jù)。解釋可變數(shù)據(jù)對研究人員來說是一個重大問題。譯者注：指數(shù)據(jù)源不穩(wěn)定D. Velocity (速度)
是指大數(shù)據(jù)以多快的速度生成，以便進行操縱，交換，存儲和分析。由于涉及的高成本，速度對數(shù)據(jù)科學(xué)家提出了新的研究挑戰(zhàn)。當用戶需要檢索或處理數(shù)據(jù)并且處理速度不夠快時，數(shù)據(jù)就被遺忘了。E. Veracity (準確性)
準確性是指正在處理的數(shù)據(jù)的質(zhì)量。數(shù)據(jù)源的準確性還取決于分析數(shù)據(jù)準確性。F. Value (價值)
價值是指數(shù)據(jù)帶來的目的或業(yè)務(wù)成果，以促進決策過程。
本文比較的四個框架在它們支持的功能和底層體系結(jié)構(gòu)方面彼此不同，同時將支持大數(shù)據(jù)處理的主要目的保留在其核心。本節(jié)概述了這四個大數(shù)據(jù)處理框架的體系結(jié)構(gòu)。
A. Hadoop
在2008年，Doug Cutting和Mike Cafarella將Apache Hadoop定義為一個開源框架，該框架通過一組稱為群集或節(jié)點的主機（硬件層）收集和處理分布式數(shù)據(jù)。它提供的是分發(fā)服務(wù)機器，而不是一項服務(wù)。因此，它們可以通過使用群集或節(jié)點并行工作。 圖2 說明了Hadoop框架的三個主要層。第一個是用于收集數(shù)據(jù)的數(shù)據(jù)存儲層，其中包含Hadoop分布式文件系統(tǒng)（HDFS）。第二層是YARN基礎(chǔ)結(jié)構(gòu)，它提供用于作業(yè)調(diào)度的算術(shù)資源，例如CPU和內(nèi)存。第三個是MapReduce，它用于與其他進程一起處理數(shù)據(jù)（軟件層）。圖2
Fig. 2. Hadoop Architecture Adapted 許多公司，企業(yè)和組織使用Apache Hadoop的主要原因有兩個。首先，進行學(xué)術(shù)或科學(xué)研究。其次，進行分析以滿足客戶的需求并幫助組織做出正確的決定。例如，當組織需要知道客戶需要哪種產(chǎn)品時。然后，它可以產(chǎn)生大量所需的產(chǎn)品，這是Apache Hadoop的幾種應(yīng)用程序之一。B. Spark
Apache Spark是在加州大學(xué)伯克利分校建立的開源框架。它在2013年成為Apache項目，通過大規(guī)模數(shù)據(jù)處理提供更快的服務(wù)。Spark框架對Hadoop而言就像MapReduce對數(shù)據(jù)處理和HDFS一樣。此外，Spark具有數(shù)據(jù)共享功能，稱為彈性分布式數(shù)據(jù)集（RDD）和有向無環(huán)圖（DAG）。圖3表示Spark架構(gòu)，它非常容易且快速地選擇大量數(shù)據(jù)處理。Spark主要由五層組成。第一層包括數(shù)據(jù)存儲系統(tǒng)，例如HDFS和HBASE。第二層是資源管理；例如YARN和Mesos。第三個是Spark核心引擎。第四個是一個庫，由SQL，流處理，用于機器學(xué)習(xí)的MLlib，Spark R和用于圖形處理的GraphX組成。最后一層是應(yīng)用程序接口，例如Java或Scala。通常，Spark提供了一種大型數(shù)據(jù)處理框架，供銀行，電信公司，游戲公司，政府以及Apple，Yahoo和Facebook等公司使用。圖3
Fig. 3. Spark Architecture Adapted C. Storm
Storm引擎是一個開放源代碼框架，旨在實時處理流數(shù)據(jù)。它是用Clojure語言編寫的。圖4顯示Storm可以在任何程序語言和任何應(yīng)用程序開發(fā)平臺上使用。因此，它保證了數(shù)據(jù)不會丟失。圖5說明了兩種類型的節(jié)點：第一種是主節(jié)點，第二種是工作節(jié)點。主節(jié)點用于監(jiān)視故障，承擔(dān)分布式節(jié)點的責(zé)任并為每臺計算機指定每個任務(wù)。所有這些任務(wù)統(tǒng)稱為Nimbus，類似于Hadoop的Job-Tracker。工作節(jié)點稱為主管。當Nimbus為它分配特定的進程時，它將起作用。因此，拓撲的每個子過程都可與許多分布式計算機一起使用。Zookeeper扮演Nimbus與主管之間的協(xié)調(diào)員。更重要的是，如果任何集群出現(xiàn)故障，它將把任務(wù)重新分配給另一個任務(wù)。因此，從節(jié)點控制自己任務(wù)的執(zhí)行。圖4
Fig. 4. Storm Architecture圖5
D. Flink
Apache Flink 是由三所德國大學(xué)于2010年創(chuàng)建的開源框架，已被有效地用于實時和批處理模式下的數(shù)據(jù)處理。它使用內(nèi)存中處理技術(shù)，并提供了許多用于查詢的API，例如流處理API（數(shù)據(jù)流），批處理API（數(shù)據(jù)集）和表API。它還具有機器學(xué)習(xí)（ML）和圖形處理（Gelly）庫。圖6展示了Flink的體系結(jié)構(gòu)。在基礎(chǔ)層中，存儲層可以從多個目標（例如HDFS，本地文件等）讀取和寫入數(shù)據(jù)。然后，部署和資源管理層包含用于管理計劃任務(wù)，監(jiān)視作業(yè)和管理資源的群集管理器。該層還包含執(zhí)行程序的環(huán)境，即集群或云環(huán)境。同時，它還支持單個Java虛擬機的本地部署。此外，它還具有用于實時處理的分布式流數(shù)據(jù)流引擎的內(nèi)核層。此外，應(yīng)用程序還具有用于兩個過程的接口層：批處理和流傳輸。上層是一個使用Java或Scala編程語言編寫程序的庫。然后在Flink優(yōu)化器的幫助下將其提交給編譯器進行轉(zhuǎn)換，以提高其性能。圖6
Fig. 6. Flink Architecture Adapted
我們研究中的每個大數(shù)據(jù)框架都支持一組功能，這些功能也可以用作關(guān)鍵績效指標。在本節(jié)中，我們將介紹通過文獻綜述確定的一組通用功能，并比較這些功能中的四個框架。
A. Scalability(可伸縮性)
可伸縮性是系統(tǒng)響應(yīng)不斷增加的負載量的能力。它有兩種類型：（縱向）擴展和（橫向）擴展。向上擴展用于升級硬件配置，而向外擴展用于添加額外的硬件。我們研究中的所有四個框架都是水平可擴展的。這意味著我們可以根據(jù)需要在集群中添加許多節(jié)點。B. Message Delivery Guarantees(消息傳遞保證)
失敗時將使用消息傳遞保證。根據(jù)上面提到的四個框架，它可以分為兩種類型：exactly once(恰好一次)和atleast-once(至少一次)。exactly once(恰好一次)傳遞意味著該消息將不會重復(fù)，也不會丟失，并且將精確地傳遞給收件人一次。另一方面，atleast-once(至少一次)傳遞意味著有很多傳遞消息的嘗試，并且這些嘗試中的至少一個成功。此外，該消息可以重復(fù)而不會丟失。C. Computation Mode(計算模式)
計算模式可以是內(nèi)存中計算，也可以是更傳統(tǒng)的模式，在該模式下，計算結(jié)果將寫回到磁盤上。內(nèi)存中計算速度更快，但存在潛在的缺點，即在關(guān)閉計算機的情況下丟失內(nèi)容。D. Auto-Scaling(自動擴展)
自動擴展是指根據(jù)情況自動擴展或縮減云服務(wù)。E. Iterative Computation(迭代計算)
迭代計算是指迭代方法的實現(xiàn)，該迭代方法在沒有實際解的情況下或在實際解的成本過高的情況下估計近似解。表I對大數(shù)據(jù)框架某些特征進行了匯總：表I：
本節(jié)介紹現(xiàn)有文獻，比較上述四個大數(shù)據(jù)處理框架。通過文獻，我們確定了九種不同的關(guān)鍵性能指標，即處理時間，CPU消耗，延遲，吞吐量，執(zhí)行時間，可持續(xù)的輸入速率，任務(wù)性能，可伸縮性和容錯能力。
A. Processing Time (處理時間)
許多現(xiàn)有研究已通過處理時間評估了大數(shù)據(jù)框架的性能。進行了一項采用該措施作為關(guān)鍵績效指標的工作。這項研究使用了個性化的監(jiān)視工具來監(jiān)視資源使用情況，并使用Python腳本來檢測計算機的狀態(tài)。在批處理模式實驗中，研究人員包含了100億條推文的數(shù)據(jù)集，而在流模式實驗中，他們收集了10億條推文。在批處理模式下，他們評估了數(shù)據(jù)大小和使用的群集對處理時間的影響。關(guān)于數(shù)據(jù)大小，研究發(fā)現(xiàn)Spark的速度比Hadoop和Flink的速度快，而Flink的速度最慢。他們還注意到，僅當數(shù)據(jù)集較?。ㄐ∮? GB）時，F(xiàn)link才比Hadoop更快。實際上，與避免輸入/輸出操作的Spark相比，Hadoop通過訪問HDFS來傳輸數(shù)據(jù)。因此，在這種情況下，處理時間受到輸入/輸出操作量的影響，因此，當處理大量數(shù)據(jù)時，處理時間增加。另一方面，關(guān)于所用集群的大小，該研究表明，Hadoop和Flink比Spark需要更長的時間，因為Spark中作業(yè)的執(zhí)行受處理器數(shù)量和對Linux的讀寫操作量的影響RAM，而不是磁盤使用，例如Hadoop。在流模式實驗中，研究人員通過評估窗口時間對已處理事件數(shù)的影響來研究處理速率。他們證明，在每條消息發(fā)送100 KB的推文的情況下，F(xiàn)link和Storm具有最好的處理速度，優(yōu)于Spark。這是因為這些框架為窗口時間使用了不同的值。Flink和Storm使用毫秒，而Spark使用秒。另一方面，在每條消息發(fā)送五個500KB的tweet時，F(xiàn)link的工作效率比Storm和Spark高。此外，在進行的一項研究中，作者根據(jù)亞馬遜網(wǎng)站上的電子商務(wù)數(shù)據(jù)評估了Flink和Spark的性能。他們使用的數(shù)據(jù)集為JSON格式。每條記錄具有固定數(shù)量的字段，一條記錄的平均大小為3000字節(jié)。他們發(fā)現(xiàn)使用Flink處理數(shù)據(jù)的平均時間為240.3秒，而Spark則為60.4秒。因此，Spark的性能比Flink更好，約為179.5％。B. CPU Consumption(CPU消耗)
許多人已經(jīng)使用CPU消耗來評估大數(shù)據(jù)框架的性能。在進行的一項研究中，發(fā)現(xiàn)在批處理模式下，F(xiàn)link使用的資源少于Hadoop和Spark。這是因為與Spark和Hadoop相比，F(xiàn)link會部分利用磁盤和內(nèi)存資源。此外，基于流模式，研究發(fā)現(xiàn)Flink在CPU消耗方面低于Spark和Storm，因為與Storm相比，F(xiàn)link主要用于處理大型消息。Spark每秒收集一次事件，然后執(zhí)行任務(wù)。因此，將處理多個消息，結(jié)果導(dǎo)致CPU使用率高。研究中，使用Yahoo流基準測試（YSB）和三個數(shù)據(jù)流框架-Spark，Storm和Flink-進行實驗。實驗發(fā)現(xiàn)，與其他框架相比，Storm具有最高的CPU資源使用率。此外，進行的一項研究發(fā)現(xiàn)，Apache Spark達到大約100％的CPU利用率，而Apache Flink使用更少的CPU資源執(zhí)行相同的負載。C. Latency(延遲)
延遲是評估大數(shù)據(jù)框架性能的另一重要性能指標。例如，使用來自監(jiān)視攝像機的數(shù)據(jù)集，其中包括1595個不同人的3425個視頻，使用RAM3S框架比較了Spark，Storm和Flink的性能。研究人員在本地環(huán)境以及Google Cloud平臺上實施了他們的實驗。當本地集群和云的節(jié)點數(shù)量變化時，Apache Storm達到了最低的延遲，并且與Flink延遲非常相似。但是，由于其微批處理設(shè)計，Spark獲得了最高的延遲。此外，進行的一項研究發(fā)現(xiàn)，只有在可以接受高延遲的情況下，Spark才能勝過Flink。另外，使用RAM3S框架比較Storm，Spark和Flink中大量多媒體流的實時分析。他們使用了YouTube面孔數(shù)據(jù)集（YTFD），其中包括來自1595個不同人群的3425個視頻和不同的視頻分辨率，其中480360最常見，總共621、126幀，平均連接的人臉最少每個視頻181.3幀。他們證明，Storm和Flink的效果比Spark稍好。另一項研究基于兩組數(shù)據(jù)集（即3000個良性和500個異常）比較了Spark和Storm。第一個數(shù)據(jù)集來自VMware中的Spark集群（D1），第二個數(shù)據(jù)集來自Yahoo Cloud Serving Benchmark（YCSB），可預(yù)測異常（D2）。作者完成了在不同VM和單個VM中測試數(shù)據(jù)的工作。他們發(fā)現(xiàn)，在所有情況下，Spark的平均延遲都小于Storm。D. Throughput(吞吐量)
吞吐量是已用于評估大數(shù)據(jù)框架性能的另一種度量。例如，發(fā)現(xiàn)Spark的吞吐量要比Storm和Flink低，然而，研究人員證明，當Spark的批處理間隔較長時，吞吐量會更高。此外，在使用云環(huán)境的情況下，Storm和Flink的效果略好于Spark，而沒有考慮構(gòu)建D-stream所需的時間。E. Execution Time (執(zhí)行時間)
使用執(zhí)行時間來評估和比較Hadoop，Spark和Flink框架的性能。他們使用大數(shù)據(jù)評估工具（BDEv）在DAS-4上進行了實驗，以自動化框架的配置。實驗指出，將Spark和Flink替換為Hadoop，當使用49個節(jié)點時，平均執(zhí)行時間分別減少77％和70％。工作中，研究人員使用開源數(shù)據(jù)集評估了SparkCount和Hadoop在WordCount和Logistic回歸程序方面的性能，該數(shù)據(jù)集包括各種公司的破產(chǎn)預(yù)測。他們的結(jié)果表明，Spark中WordCount程序的執(zhí)行時間少于Hadoop。此外，在Spark中執(zhí)行邏輯回歸程序的時間少于Hadoop。例如，如果迭代次數(shù)為100，則Spark中的執(zhí)行時間為3.452秒；對于Hadoop，為9.383秒。因此，Spark在WordCount和Logistic回歸方面均勝過Hadoop。原因之一是，在Spark的內(nèi)存存儲中使用緩存使過程更快。此外基于WordCount程序使用Spark和MapReduce框架對性能進行了測量，該框架運行在安裝在Ubuntu機器上的單節(jié)點Hadoop（HDFS）上。他們使用了大文本文件形式的數(shù)據(jù)集，其中包含客戶對多種產(chǎn)品的評論和反饋，并將該文件分配為不同的大小。與MapReduce編程框架相比，Spark的執(zhí)行速度大約是三到四倍。比較使用Karamel（Web應(yīng)用程序）的Spark和Flink框架，以便評估系統(tǒng)級別和應(yīng)用程序級別的性能。使用了TeraSort應(yīng)用程序生成并使用HDFS存儲的數(shù)據(jù)，以及各種輸入級別（200GB，400GB和600GB）。研究人員發(fā)現(xiàn)Flink減少了執(zhí)行時間，比Terasort應(yīng)用程序的Spark快1.5倍。F. Sustainable Input Rate(可持續(xù)的輸入速率)
使用可持續(xù)輸入率作為比較大數(shù)據(jù)框架的績效指標。當本地集群和云的計算節(jié)點數(shù)量發(fā)生變化時，將使用此度量。Storm在兩種情況下（本地和云）都優(yōu)于Flink和Spark。此結(jié)果是由于Storm使用的最簡單的一次語義(atleast-once 至少一次），而在Flink中，是exactly once(恰好一次)。另外，Storm的拓撲是由程序員定義的，而在Flink中，它是由優(yōu)化器定義的。這導(dǎo)致Flink的效率降低。另一方面，Spark并非主要設(shè)計為流引擎。因此，這也是輸入速率較低的原因之一。G. Task Performance (任務(wù)性能)
研究比較大數(shù)據(jù)框架在許多給定任務(wù)上的性能，這些任務(wù)包括WordCount，k-means，PageRank，Grep，TeraSort和connected components。研究發(fā)現(xiàn)，與Flink和Hadoop相比，Spark在WordCount和k-means方面表現(xiàn)最佳，而Flink對于PageRank則取得了更好的結(jié)果。另一方面，F(xiàn)link和Spark在Grep，TeraSort和connected components上均取得了相同的結(jié)果，并且在這些方面均勝過Hadoop。導(dǎo)致WordCount結(jié)果的一種解釋是，求每個單詞出現(xiàn)的次數(shù)和，Spark使用reduceByKey（）函數(shù)與flink中優(yōu)化程度較低的groupBy（）。sum（）函數(shù)的Flink相比，所以WordCount性能測試中Spark超越Flink。在Grep中，Spark和Flink的性能要優(yōu)于Hadoop，因為Hadoop使用一個MapReduce搜索模式，然后使用另一個對結(jié)果進行排序。這導(dǎo)致大量的內(nèi)存復(fù)制和寫入HDFS。在PageRank中，F(xiàn)link獲得了最佳性能，因為它使用的增量迭代僅處理尚未達到最終值的元素。H. Scalability(可伸縮性)
在衡量可擴展性方面，將運營商的執(zhí)行計劃（端到端執(zhí)行時間）與資源使用和參數(shù)配置聯(lián)系在一起，以衡量Spark和Flink的性能。結(jié)果表明，Spark比Flink快大約1.7倍，特別是在大型圖數(shù)據(jù)處理中。相比之下，在具有大型數(shù)據(jù)集和固定節(jié)點的情況下，F(xiàn)link更好，其性能比Spark高出10％。I. Fault Tolerance(容錯)
關(guān)于容錯度量， 進行的研究指出，F(xiàn)link具有比Storm和Spark框架更高的容錯能力。總體而言，這里回顧的所有研究都表明，與Hadoop和Flink相比，Spark在processing time(處理時間)方面是最快的。同樣在延遲方面，Spark也是最低的。此外，與Hadoop和Flink相比，Spark在Throughput(吞吐量)和execution time(執(zhí)行時間)方面是最好的。同樣在WordCount和k-means方面，它比Flink和Hadoop更好。此外，在Grep，TeraSort和Connected Components方面，它比Hadoop也更好。此外，就可伸縮性而言，與Flink相比，Spark在大型圖計算的情況下更好。與Storm和Spark相比，F(xiàn)link在processing time(處理時間)方面效率更高。另外，在使用云環(huán)境的情況下，它在Throughput(吞吐量)方面更有效，而無需考慮構(gòu)建d-stream的時間。除此之外，僅在使用Karamel和TeraSort應(yīng)用程序的情況下，與Spark相比，execution time(執(zhí)行時間)更短。此外，就PageRank而言，與Spark和Hadoop相比，它是最好的。此外，就Grep，TeraSort和Connected Components而言，它比Hadoop更好。就可伸縮性而言，只有在數(shù)據(jù)集很大且節(jié)點數(shù)量固定的情況下，與Spark相比才是最好的。同樣，在容錯方面，它比Storm和Spark好。Storm在CPU利用率方面與Spark，F(xiàn)link和Hadoop框架相比性能最佳。此外，與Spark和Flink相比，它具有最低的延遲。另外，僅在使用云環(huán)境的情況下，它才具有最佳吞吐量，而無需考慮構(gòu)建d-stream所需的時間。而且，與Flink和Spark相比，它具有更好的可持續(xù)輸入速率。表II四個大數(shù)據(jù)框架比較的文獻綜述。表II：
這項研究的結(jié)果表明，與其他框架相比，F(xiàn)link表現(xiàn)最佳，因為它在八項指標中均達到了最佳性能。Spark在六個方面優(yōu)于其他框架，Storm在四個方面優(yōu)于其他框架。因此，公司，研究人員以及對該領(lǐng)域感興趣的個人的用戶可以根據(jù)他們希望使用的關(guān)鍵績效指標來選擇合適的框架，以便分析數(shù)據(jù)并獲得有效的結(jié)果。最后，他們將獲得高性能的計算（HPC）。
將來，通過在四個框架的性能中考慮這些度量，可以以任何對獲得HPC影響不大的度量來增強每個框架的機會。因此，我們希望看到其中一些框架有所增強，同時還包括能夠提供高性能的其他框架。
更多精彩干貨分享
點擊下方名片關(guān)注
IT那活兒
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/129749.html
