大數據是收集、組織和處理大容量數據集並從中獲得洞察力所需的非傳統策略和技術的總稱。盡管處理數據所需的計算能力或存儲容量早已超過了壹臺計算機的上限，但這種類型計算的普遍性、規模和價值只是在最近幾年才經歷了大規模的擴張。
本文將介紹大數據系統的壹個基本組件:處理框架。處理框架負責計算系統中的數據，例如處理從非易失性存儲中讀取的數據或處理剛剛攝入系統中的數據。數據的計算是指從大量單個數據點中提取信息和觀點的過程。
這些框架描述如下:
僅批處理框架:
Apache Hadoop
僅流處理框架:
阿帕奇風暴
阿帕奇薩姆紮
*混合框架:
阿帕奇火花
阿帕奇弗林克
什麽是大數據處理框架？
處理框架和處理引擎負責計算數據系統中的數據。“引擎”和“框架”的區別雖然沒有權威的定義，但很多時候，前者可以定義為實際負責處理數據操作的組件，後者可以定義為承擔類似功能的壹系列組件。
比如Apache Hadoop可以看作是壹個以MapReduce為默認處理引擎的處理框架。引擎和框架通常可以互換使用，也可以同時使用。例如，另壹個框架Apache Spark可以整合Hadoop並取代MapReduce。組件之間的互操作性是大數據系統如此靈活的原因之壹。
雖然在生命周期的這個階段負責處理數據的系統通常非常復雜，但從廣義上來說，它們的目標是非常壹致的:通過對數據執行操作來提高理解能力，揭示數據中包含的模式，並獲得對復雜交互的洞察力。
為了簡化對這些組件的討論，我們將根據不同處理框架的設計意圖所處理的數據的狀態對它們進行分類。有些系統可以以批處理方式處理數據，有些系統可以以流方式處理連續流入系統的數據。此外，有些系統可以同時處理兩種類型的數據。
在介紹不同實現的指標和結論之前，有必要簡單介紹壹下不同處理類型的概念。
批處理系統
批處理在大數據領域有著悠久的歷史。批處理主要對大型靜態數據集進行操作，並在計算過程完成後返回結果。
批處理模式下使用的數據集通常滿足以下特征…
有界:壹個批處理數據集代表壹個有限的數據集。
持久性:數據通常總是存儲在某種持久存儲位置。
海量:批處理操作通常是處理超大數據集的唯壹方法。
批處理非常適合需要訪問完整記錄集的計算作業。例如，在計算總數和平均值時，必須將數據集視為壹個整體，而不是多個記錄的集合。這些操作要求數據在計算過程中保持自己的狀態。
需要處理大量數據的任務通常最好通過批處理操作來處理。無論是直接從持久存儲設備處理數據集，還是先加載到內存中，批處理系統在設計過程中都充分考慮了數據量，能夠提供足夠的處理資源。批處理因其在處理大量持久數據方面的優異性能，常被用於分析歷史數據。
處理大量的數據需要大量的時間，所以批處理不適合處理時間要求高的場合。
Apache Hadoop
Apache Hadoop是壹個專門用於批處理的處理框架。Hadoop是第壹個在開源社區獲得極大關註的大數據框架。Hadoop基於Google發表的大量關於海量數據處理的論文和經驗，重新實現了相關的算法和組件棧，使得大規模批處理技術更容易使用。
新版本的Hadoop包含多個組件，即多個層，它們可以壹起用於處理批量數據:
HDFS: HDFS是壹個分布式文件系統層，它可以協調集群節點之間的存儲和復制。HDFS保證數據在不可避免的節點失效後仍然可以使用，可以作為數據源，可以用來存儲中間狀態的處理結果，可以存儲計算的最終結果。
Yarn: Yarn是另壹個資源協商器的縮寫，可以充當Hadoop堆棧的集群協調組件。該組件負責協調和管理底層資源的運行以及調度作業。通過充當集群資源的接口，YARN使用戶能夠以叠代的方式在Hadoop集群中運行比過去更多類型的工作負載。
MapReduce: MapReduce是Hadoop的原生批處理引擎。
成批處理方式
Hadoop的處理功能來自MapReduce引擎。mapreduce的處理技術滿足了使用鍵值對的Map、shuffle和reduce算法的要求。基本處理過程包括:
從HDFS文件系統讀取數據集
將數據集分成小塊，並將它們分發到所有可用的節點。
計算每個節點上的數據子集(計算的中間結果將在HDFS重寫)。
中間結果的重新分配和按關鍵字分組
通過匯總和合並每個節點的計算結果來降低每個鍵的值。
將計算的最終結果重新寫入HDFS。
優點和局限性
由於這種方式非常依賴持久存儲，每個任務需要多次進行讀寫操作，所以速度比較慢。但另壹方面，由於磁盤空間通常是服務器上最豐富的資源，這意味著MapReduce可以處理非常海量的數據集。這也意味著，與其他類似技術相比，Hadoop的MapReduce通常可以運行在廉價的硬件上，因為它不需要將所有東西都存儲在內存中。MapReduce具有極高的擴展潛力，在生產環境中已經有了數萬個節點的應用。
MapReduce的學習曲線很陡。雖然Hadoop生態系統的其他外圍技術可以大大降低這個問題的影響，但是在通過Hadoop集群快速實現壹些應用的時候，還是需要註意這個問題。
圍繞Hadoop已經形成了壹個龐大的生態系統，Hadoop集群本身也經常作為其他軟件的組件。通過與Hadoop集成，許多其他處理框架和引擎也可以使用HDFS和YARN Explorer。
摘要
Apache Hadoop及其MapReduce處理引擎提供了壹套經過時間考驗的批處理模型，最適合處理時間要求不高的超大規模數據集。壹個全功能的Hadoop集群可以通過非常低成本的組件來構建，這使得這種廉價而高效的處理技術可以靈活地應用於許多情況。與其他框架和引擎的兼容性和集成使Hadoop成為使用不同技術的各種工作負載處理平臺的底層基礎。
流處理系統
流處理系統將隨時計算進入系統的數據。與批處理模式相比，這是壹種完全不同的處理方式。流處理方法不需要對整個數據集執行操作，而是對通過系統傳輸的每個數據項執行操作。
流處理中的數據集是“無邊界的”，這有幾個重要影響:
壹個完整的數據集只能代表目前為止進入系統的數據總量。
工作數據集可能更相關，並且在特定時間只能表示單個數據項。
處理是基於事件的，除非顯式停止，否則沒有“結束”。處理結果立即可用，並將隨著新數據的到來而更新。
流處理系統幾乎可以處理無限量的數據，但同時只能處理壹片(實流處理)或少量(微批處理)數據，不同記錄之間只維持壹個最小狀態。盡管大多數系統都提供了維護某些狀態的方法，但流處理主要是針對副作用較少的功能性處理進行優化的。
功能操作主要集中在具有有限狀態或副作用的離散步驟上。對相同的數據執行相同的操作會產生相同的結果或壹些其他因素，這非常適合流處理，因為不同項的狀態通常是壹些困難、限制和某些情況下不必要的結果的組合。因此，盡管壹些類型的狀態管理通常是可行的，但是這些框架在沒有狀態管理機制的情況下通常更簡單和更有效。
這種處理非常適合某些類型的工作負載。具有接近實時處理要求的任務非常適合使用流處理模式。分析、服務器或應用程序錯誤日誌以及其他基於時間的指標是最合適的類型，因為響應這些領域的數據變化對於業務功能來說極其重要。流處理適用於處理必須響應變化或峰值並關註壹段時間內變化趨勢的數據。
阿帕奇風暴
Apache Storm是壹個註重極低延遲的流處理框架，可能是需要近實時處理的工作負載的最佳選擇。這項技術可以處理非常大量的數據，並提供比其他解決方案延遲更低的結果。
流處理模式
Storm的流處理可以在框架中安排DAG(有向無環圖)命名拓撲。這些拓撲描述了當數據段進入系統時，需要對每個傳入數據段執行的不同轉換或步驟。
拓撲包括:
Stream:普通數據流，是會持續到達系統的無邊界數據。
Spout:位於拓撲邊緣的數據流的來源，如API或query，從中可以生成要處理的數據。
Bolt: Bolt表示需要消費流數據、對其應用操作並以流的形式輸出結果的處理步驟。Bolt需要與每個噴口建立連接，然後相互連接，形成所有必要的處理。在拓撲的末端，最終的Bolt輸出可以用作其他互連系統的輸入。
Storm背後的思想是使用上述組件定義大量小型離散操作，然後將多個組件組合成所需的拓撲。默認情況下，Storm提供了“至少壹次”的處理保證，這意味著每條消息至少可以處理壹次，但在某些情況下，如果失敗，可能會處理多次。Storm無法確保消息可以按特定順序處理。
為了實現嚴格的壹次性處理，即有狀態處理，可以使用壹種叫做Trident的抽象。嚴格來說，不使用三叉戟的風暴通常可以稱為核心風暴。Trident會很大程度上影響Storm的處理能力，增加延遲，提供處理的狀態，使用微批處理模式代替逐項的純流處理模式。
為了避免這些問題，壹般建議Storm用戶盡量使用Core Storm。但是，還需要註意的是，Trident對內容嚴格的壹次性處理保證在某些情況下也是有用的，比如當系統無法智能處理重復消息時。如果妳需要維護項目之間的狀態，比如統計壹個小時內有多少用戶點擊了壹個鏈接，Trident將是妳唯壹的選擇。雖然不能充分發揮框架的固有優勢，但三叉戟提高了風暴的靈活性。
三叉戟拓撲包括:
流批量:這是指流數據的微批量，可以通過分塊提供批量語義。
操作:指可以對數據執行的批處理過程。
優點和局限性
目前，Storm可能是近實時處理領域的最佳解決方案。這項技術可以以非常低的延遲處理數據，並可用於希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，比如需要將處理結果直接提供給訪問者打開的網站頁面，那麽Storm會是壹個不錯的選擇。
暴風和三叉戟的合作，讓用戶可以用微批量代替純流處理。雖然用戶可以獲得更多的靈活性來創建滿足需求的工具，但同時，這種做法會削弱這種技術相對於其他解決方案的最大優勢。話雖如此，多壹個流處理方法總是好的。
核心風暴不能保證消息的處理順序。Core Storm為消息提供了“至少壹次”的處理保證，這意味著每條消息都可以被處理，但也可能被復制。Trident提供了嚴格的壹次性處理保證，可以提供不同批次之間的順序處理，但無法實現壹個批次內的順序處理。
在互操作性方面，Storm可以與Hadoop的YARN資源管理器集成，因此可以輕松集成到現有的Hadoop部署中。除了支持大多數處理框架，Storm還可以支持多種語言，為用戶提供更多拓撲定義的選擇。
摘要
Storm可能是最適合高延遲要求的純流工作負載的技術。這項技術可以確保每個消息都得到處理，並且可以用於許多編程語言。因為Storm不能批處理，如果需要這些能力，可能需要使用其他軟件。如果對嚴格的壹次性待遇保障有很高的要求，這個時候可以考慮三叉戟。然而，在這種情況下，其他流處理框架可能更合適。
阿帕奇薩姆紮
Apache Samza是壹個流處理框架，與Apache Kafka消息傳遞系統緊密結合。雖然Kafka可以用在很多流處理系統中，但是根據設計，Samza可以充分發揮Kafka獨特的架構優勢和保障。這項技術可以通過Kafka提供容錯、緩沖和狀態存儲。
Samza可以使用YARN作為資源管理器。這意味著默認情況下需要Hadoop集群(至少是HDFS和YARN)，但也意味著Samza可以直接使用YARN豐富的內置函數。
流處理模式
Samza依靠卡夫卡的語義來定義如何處理流。Kafka在處理數據時涉及到以下概念:
主題:每壹個進入Kafka系統的數據流都可以稱為壹個主題。主題基本上是由消費者可以訂閱的相關信息組成的數據流。
分區:為了將壹個主題傳播到多個節點，Kafka會將傳入的消息分成多個分區。分區將基於密鑰，這可以確保包含相同密鑰的每個消息都可以被劃分到相同的分區中。可以保證分區的順序。
代理:構成Kafka集群的每個節點也稱為代理。
生產者:任何向Kafka主題寫入數據的組件都可以稱為生產者。生產者可以提供將主題劃分為分區所需的鍵。
消費者:任何從Kafka讀取主題的組件都可以稱為消費者。消費者需要負責維護關於其分支機構的信息，以便他們可以知道失敗後處理了哪些記錄。
由於卡夫卡相當於壹個永恒的日誌，Samza也需要處理壹個永恒的數據流。這意味著任何轉換創建的新數據流都可以被其他組件使用，而不會影響原始數據流。
優點和局限性
乍壹看，Samza對Kafka查詢系統的依賴似乎是壹種限制，但它也可以為系統提供壹些獨特的保障和功能，這是其他流處理系統所不具備的。
例如，Kafka已經提供了可以以低延遲方式訪問的數據存儲的副本，並且它還可以為每個數據分區提供非常易用和低成本的多訂戶模型。所有輸出，包括中間狀態的結果，都可以寫入Kafka，並且可以由下遊步驟獨立使用。
這種對卡夫卡的密切依賴在很多方面類似於MapReduce引擎對HDFS的依賴。雖然批處理中每個計算之間對HDFS的依賴導致了壹些嚴重的性能問題，但它也避免了流處理遇到的許多其他問題。
Samza和Kafka之間的密切關系使得處理步驟本身非常松散地耦合。您可以在輸出的任何步驟中添加任意數量的訂閱者，而無需事先協調，這對於擁有需要訪問相似數據的多個團隊的組織非常有用。多個團隊都可以訂閱進入系統的數據主題，也可以訂閱其他團隊經過壹些數據處理後創建的主題。所有這些都不會給數據庫等負載密集型基礎設施帶來額外的壓力。
直接寫入卡夫卡也可以避免背壓的問題。背壓是指由於峰值負載，數據流入速度超過組件的實時處理能力，可能導致處理工作停止，並可能丟失數據的情況。根據設計，Kafka可以長期保存數據，這意味著組件可以在方便的時候繼續處理，可以直接重啟，而不用擔心任何後果。
Samza可以使用本地鍵值存儲實現的容錯檢查點系統來存儲數據。通過這種方式，Samza可以獲得“至少壹次”的交付保證，但面對數據多次交付導致的失敗，這種技術無法提供匯總狀態的準確恢復(如計數)。
與Storm和其他系統提供的原語相比，Samza提供的高級抽象在許多方面都更容易使用。目前Samza只支持JVM語言，也就是說在語言支持上不如Storm靈活。
摘要
在Hadoop和Kafka已經可用或易於實施的環境中，Apache Samza是流式工作負載的良好選擇。Samza本身非常適合擁有多個團隊的組織，這些團隊需要在不同的處理階段使用(但不壹定相互密切協調)多個數據流。Samza可以大大簡化許多流處理任務，並實現低延遲性能。如果部署需求與當前系統不兼容，可能不適合使用，但如果要求極低延遲處理或者對嚴格的壹次性處理語義要求較高，仍然適合考慮。
混合處理系統:批處理和流處理
壹些處理框架可以處理批處理和流處理工作負載。這些框架可以用相同或相關的組件和API處理兩種類型的數據，從而簡化不同的處理需求。
可以看到，這個特性主要是由Spark和Flink實現的，下面將介紹這兩個框架。實現這壹功能的關鍵是如何將兩種不同的處理方式統壹起來，對固定和不固定數據集之間的關系應該做什麽樣的假設。
盡管專註於某種處理類型的項目將更好地滿足特定用例的需求，但混合框架旨在為數據處理提供壹個通用的解決方案。該框架不僅可以提供處理數據所需的方法，還提供了自己的集成項、庫和工具，可以勝任圖形分析、機器學習和交互式查詢等各種任務。
阿帕奇火花
Apache Spark是具有流處理能力的下壹代批處理框架。基於與Hadoop的MapReduce引擎相同原理開發的Spark，主要是通過完善的內存計算和處理優化機制來加快批量工作負載的運行速度。
Spark可以作為獨立集群部署(在相應存儲層的配合下)，也可以與Hadoop集成，替代MapReduce引擎。
成批處理方式
與MapReduce不同，Spark的數據處理都是在內存中完成的，只需要在壹開始將數據讀入內存並永久存儲最終結果時，與存儲層進行交互。所有中間狀態的處理結果都存儲在存儲器中。
雖然內存中的處理方式可以大大提升性能，但是Spark在處理磁盤相關任務時的速度也有了很大的提升，因為它可以通過提前分析整個任務集來實現更完美的整體優化。正因如此，Spark可以創建壹個有向無環圖(DAG)來表示所有需要執行的操作、需要操作的數據以及操作和數據之間的關系，這樣處理器就可以更加智能地協調任務。
為了在內存中實現批量計算，Spark將使用壹種稱為彈性分布式數據集(Resilient Distributed Dataset，RDD)的模型來處理數據。這是壹個永恒的結構，表示壹個數據集，只存在於內存中。在RDD上執行的操作可以生成新的RDD。每個RDD都可以通過血統追溯到父RDD，並最終追溯到磁盤上的數據。Spark可以通過RDD實現容錯，無需將每次操作的結果寫回磁盤。
流處理模式
流處理能力是通過火花流實現的。Spark本身主要是為批量處理工作量而設計的。為了彌補引擎設計和流處理工作負載特征之間的差異，Spark實現了壹個叫做微批處理的概念)。在具體策略上，該技術可以將數據流視為壹系列非常小的“批處理”，可以通過批處理引擎的原生語義進行處理。
Spark Streaming以亞秒級增量緩沖流，然後這些緩沖作為小規模固定數據集進行批量處理。這種方法的實際效果非常好，但是與真實的流處理框架相比，在性能上還是有壹些不足。
優點和局限性
使用Spark而不是Hadoop MapReduce的主要原因是速度。借助內存計算策略和先進的DAG調度機制，Spark可以更快的速度處理相同的數據集。
Spark的另壹個重要優勢在於它的多樣性。該產品可以作為獨立的集群部署，也可以與現有的Hadoop集群集成。該產品可以運行批處理和流處理，壹個集群可以處理不同類型的任務。
除了引擎本身的能力，圍繞Spark建立了包含各種庫的生態系統，可以為機器學習、交互查詢等任務提供更好的支持。與MapReduce相比，Spark任務“眾所周知”，易於編寫，因此可以大大提高生產率。
流處理系統采用批處理方式，進入系統的數據需要緩沖。緩沖機制使這種技術能夠處理非常大量的輸入數據，並提高整體吞吐量，但等待緩沖區變空也會導致延遲增加。這意味著Spark流可能不適合具有高延遲要求的工作負載。
因為內存通常比磁盤空間更昂貴，所以Spark比基於磁盤的系統成本更高。但是，處理速度的提高意味著任務可以更快地完成，這通常可以在需要按小時支付資源的環境中抵消增加的成本。
Spark內存計算設計的另壹個後果是，如果部署在* * *共享集群中，可能會遇到資源不足的問題。與HadoopMapReduce相比，Spark消耗的資源更多，可能會影響同時需要使用集群的其他任務。本質上，Spark不適合與Hadoop stack的其他組件存儲在壹起。
摘要
Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力提供了無與倫比的速度優勢，但代價是更高的內存消耗。對於重視吞吐量而非延遲的工作負載，Spark流更適合作為流解決方案。
阿帕奇弗林克
Apache Flink是壹個流處理框架，可以處理批處理任務。這種技術可以將批處理數據視為具有有限邊界的數據流，從而可以將批處理任務視為流處理的子集。對所有處理任務采用流處理優先的方法將會產生壹系列有趣的副作用。
這種先流處理的方法也稱為Kappa架構，與更廣為人知的Lambda架構形成對比(在Lambda架構中，批處理作為主要處理方法，stream作為補充，並提供早期未精煉的結果)。Kappa架構會將所有東西進行流處理，以簡化模型，這只有在流處理引擎最近成熟之後才可行。
流處理模型
Flink的流處理模型在處理傳入數據時，將每個項目都視為壹個真實的數據流。Flink提供的數據流API可以用來處理無窮無盡的數據流。Flink可以壹起使用的基本組件包括:
流是指在系統中循環的永恒的、無限的數據集。
運算符是指針的功能，對壹個數據流執行運算，生成其他數據流。
源是指數據流進入系統的入口點。
Sink是指數據流離開Flink系統後進入的位置，可以是數據庫，也可以是連接其他系統的連接器。
為了在計算過程中遇到問題後恢復，流式任務將在預定的時間點創建快照。為了實現狀態存儲，Flink可以與各種狀態後端系統壹起使用，這取決於所需實現的復雜程度和持久性級別。
此外，Flink的流處理能力還可以理解“事件時間”的概念，事件時間是指事件實際發生的時間，這個函數也可以處理會話。這意味著可以以某種有趣的方式確保執行順序和分組。
批量模型
Flink的批處理模型在很大程度上只是對流處理模型的擴展。此時，模型不再從持久流中讀取數據，而是以流的形式從持久存儲中讀取有界數據集。Flink將為這些處理模型使用完全相同的運行時。
Flink可以在壹定程度上優化批處理工作量。例如，因為批處理操作可以由持久存儲支持，所以Flink不能創建批處理工作負載的快照。數據仍然可以恢復，但是正常的處理操作可以更快地執行。
另壹個優化是分解批處理任務，以便在需要時可以調用不同的階段和組件。這樣，Flink可以更好地與集群的其他用戶壹起存儲。通過提前分析任務，Flink可以查看所有需要執行的操作，數據集的大小，以及下遊需要執行的操作步驟，從而實現進壹步的優化。
優點和局限性
Flink是目前處理框架領域的獨特技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理采用的微批處理架構使其不適合許多用例。Flink流處理首先可以提供低延遲、高吞吐量和幾乎逐項的處理能力。
Flink的許多組件都是自我管理的。盡管這種做法很少見，但出於性能原因，這種技術可以自己管理內存，而不依賴於本機Java垃圾收集機制。與Spark不同，Flink在待處理數據的特性發生變化後，不需要手動優化和調整，技術也可以自行處理數據分區和自動緩存。
Flink會以多種方式分工，優化任務。這種分析在某種程度上類似於SQL查詢規劃器對關系數據庫的優化，可以為具體任務確定最高效的實現方法。該技術還支持多階段並行執行，可以將阻塞任務的數據聚集在壹起。對於叠代任務，出於性能考慮，Flink會嘗試在存儲數據的節點上執行相應的計算任務。此外，還可以進行“增量叠代”，或者只叠代數據發生變化的部分。
在用戶工具方面，Flink提供了基於Web的調度視圖，可以輕松管理任務和查看系統狀態。用戶還可以查看提交任務的優化方案，從而了解任務最終是如何在集群中實現的。對於分析任務，Flink除了支持內存計算之外，還提供了類似SQL的查詢、圖形處理和機器學習庫。
Flink與其他組件配合良好。如果配合Hadoop stack使用，這種技術可以很好地融入整個環境，任何時候都只占用必要的資源。這種技術可以很容易地與紗、HDFS和卡夫卡結合起來。在兼容包的幫助下，Flink還可以運行為其他處理框架編寫的任務，比如Hadoop和Storm。
目前來看，Flink最大的局限之壹就是它還是壹個非常“年輕”的項目。該項目在真實環境中的大規模部署並不像其他處理框架那樣普遍，也沒有深入研究Flink在可伸縮能力上的局限性。隨著快速的開發周期和兼容包的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署。
摘要
Flink提供低延遲的流處理，同時支持傳統的批處理任務。Flink可能最適合具有極高流要求和少量批處理任務的組織。該技術兼容原生Storm和Hadoop程序，可以在YARN管理的集群上運行，因此可以很容易地進行評測。快速的開發工作使其值得關註。
結論
大數據系統可以使用多種處理技術。
對於只需要批量處理的工作負載，如果不是時間敏感型的，實現成本比其他解決方案更低的Hadoop會是壹個不錯的選擇。
對於只需要流處理的工作負載，Storm可以支持更廣泛的語言，實現極低延遲的處理，但默認配置可能會產生重復的結果，無法保證順序。Samza與YARN和Kafka的緊密集成可以提供更大的靈活性，更容易的多團隊使用，以及更簡單的復制和狀態管理。
對於混合工作負載，Spark可以提供高速批處理和微批處理。這項技術的支持更加完善，有各種集成庫和工具，可以實現靈活集成。Flink提供了真正的流處理和批處理功能。通過深度優化，它可以運行為其他平臺編寫的任務，並提供低延遲處理，但其實際應用仍為時尚早。
最合適的解決方案主要取決於要處理的數據的狀態、對處理所需時間的需求以及期望的結果。具體來說，使用全功能解決方案還是主要專註於某個項目的解決方案，需要仔細權衡。隨著它的成熟和被廣泛接受，在評估任何新興的創新解決方案時，需要考慮類似的問題。