在數(shù)據(jù)管道中，數(shù)據(jù)通常經(jīng)歷兩個(gè)階段：數(shù)據(jù)處理和數(shù)據(jù)訪問。 對于任何類型的數(shù)據(jù)，當(dāng)它進(jìn)入組織時(shí)（大多數(shù)情況下有多個(gè)數(shù)據(jù)源），很可能是不干凈的，或者是其格式可能不被最終的內(nèi)部或外部業(yè)務(wù)用戶直接報(bào)告或分析的格式。 組織。 因此，首先需要進(jìn)行數(shù)據(jù)處理，通常包括數(shù)據(jù)清理，標(biāo)準(zhǔn)化，轉(zhuǎn)換和聚合。 然后，最終數(shù)據(jù)將顯示在數(shù)據(jù)訪問層中-隨時(shí)可以報(bào)告并用于所有方面的分析。 數(shù)據(jù)處理有時(shí)也稱為數(shù)據(jù)準(zhǔn)備，數(shù)據(jù)集成或ETL。 其中，ETL可能是最受歡迎的名稱。
數(shù)據(jù)處理和數(shù)據(jù)訪問具有不同的目標(biāo)，因此已通過不同的技術(shù)實(shí)現(xiàn)。 大數(shù)據(jù)的數(shù)據(jù)處理從一開始就強(qiáng)調(diào)"擴(kuò)展"，這意味著每當(dāng)數(shù)據(jù)量增加時(shí)，給定可用硬件，處理時(shí)間仍應(yīng)在預(yù)期范圍內(nèi)。 整個(gè)數(shù)據(jù)處理時(shí)間范圍從幾分鐘到幾小時(shí)到幾天不等，具體取決于數(shù)據(jù)量和處理邏輯的復(fù)雜性。 另一方面，數(shù)據(jù)訪問強(qiáng)調(diào)的是"快速"響應(yīng)時(shí)間，以秒為單位。 在較高的水平上，數(shù)據(jù)處理的可擴(kuò)展性主要是通過并行處理來實(shí)現(xiàn)的，而快速的數(shù)據(jù)訪問則是基于訪問模式以及服務(wù)器上可用內(nèi)存的增加，通過優(yōu)化數(shù)據(jù)結(jié)構(gòu)來實(shí)現(xiàn)的。
數(shù)據(jù)處理
為了清理，標(biāo)準(zhǔn)化和轉(zhuǎn)換來自不同來源的數(shù)據(jù)，數(shù)據(jù)處理需要觸摸即將到來的數(shù)據(jù)中的每條記錄。 記錄清潔并定稿后，就可以完成工作。 這從根本上不同于數(shù)據(jù)訪問-數(shù)據(jù)訪問導(dǎo)致不同用戶和/或應(yīng)用程序重復(fù)檢索和訪問相同信息。 當(dāng)數(shù)據(jù)量較小時(shí)，與數(shù)據(jù)訪問相比，數(shù)據(jù)處理的速度面臨的挑戰(zhàn)要小，因此通常發(fā)生在最終數(shù)據(jù)所在的同一數(shù)據(jù)庫內(nèi)。 隨著數(shù)據(jù)量的增長，人們發(fā)現(xiàn)必須在數(shù)據(jù)庫之外進(jìn)行數(shù)據(jù)處理，以繞開數(shù)據(jù)庫系統(tǒng)造成的所有開銷和限制，而數(shù)據(jù)庫系統(tǒng)顯然并不是最初設(shè)計(jì)用于大數(shù)據(jù)處理的。 那時(shí)是ETL，然后Hadoop開始分別在數(shù)據(jù)倉庫和大數(shù)據(jù)時(shí)代發(fā)揮關(guān)鍵作用。
大數(shù)據(jù)處理的挑戰(zhàn)在于，要處理的數(shù)據(jù)量始終處于硬盤可以容納的水平，但遠(yuǎn)遠(yuǎn)超過給定時(shí)間可用的計(jì)算內(nèi)存量。 高效數(shù)據(jù)處理的基本方式是將數(shù)據(jù)分解成較小的部分并并行處理。 換句話說，可伸縮性是通過首先在編程中啟用并行處理來實(shí)現(xiàn)的，這樣，當(dāng)數(shù)據(jù)量增加時(shí)，并行進(jìn)程的數(shù)量將增加，而每個(gè)進(jìn)程繼續(xù)處理與以前相似的數(shù)據(jù)量； 第二，隨著并行進(jìn)程數(shù)量的增加，添加更多具有更多處理器，內(nèi)存和磁盤的服務(wù)器。
大數(shù)據(jù)的并行處理首先是通過數(shù)據(jù)庫系統(tǒng)和ETL工具中的數(shù)據(jù)分區(qū)技術(shù)實(shí)現(xiàn)的。 將數(shù)據(jù)集進(jìn)行邏輯分區(qū)后，可以并行處理每個(gè)分區(qū)。 Hadoop HDFS（高度分布式文件系統(tǒng)）以最可擴(kuò)展的方式適應(yīng)了相同的原理。 HDFS的作用是將數(shù)據(jù)劃分為具有恒定大小的每個(gè)數(shù)據(jù)塊的數(shù)據(jù)塊。 然后將這些塊分配到不同的服務(wù)器節(jié)點(diǎn)，并由元數(shù)據(jù)存儲將其記錄在所謂的"名稱"節(jié)點(diǎn)中。 當(dāng)數(shù)據(jù)進(jìn)程開始時(shí)，進(jìn)程數(shù)由每個(gè)服務(wù)器節(jié)點(diǎn)上的數(shù)據(jù)塊數(shù)和可用資源（例如，處理器和內(nèi)存）確定。 這意味著只要您有來自多個(gè)服務(wù)器的足夠的處理器和內(nèi)存，HDFS就可以進(jìn)行大規(guī)模并行處理。
目前，Spark已成為內(nèi)存中進(jìn)行大規(guī)模數(shù)據(jù)處理的最受歡迎的快速引擎之一。是否有意義？盡管內(nèi)存確實(shí)變得更便宜了，但它仍然比硬盤驅(qū)動器貴。在大數(shù)據(jù)空間中，要處理的大數(shù)據(jù)量始終遠(yuǎn)遠(yuǎn)大于可用的內(nèi)存量。那么Spark如何解決呢？首先，Spark利用具有多個(gè)數(shù)據(jù)節(jié)點(diǎn)的分布式環(huán)境中的內(nèi)存總量。但是，如果有任何組織嘗試將大數(shù)據(jù)放入Spark群集中，則內(nèi)存量仍然不夠，而且可能會非常昂貴。讓我們考慮一下Spark適用于哪種類型的處理。數(shù)據(jù)處理總是從將數(shù)據(jù)從磁盤讀取到內(nèi)存開始，最后將結(jié)果寫入磁盤。如果每個(gè)記錄在寫入磁盤之前只需要處理一次（典型的批處理就是這種情況），那么與Hadoop相比，Spark將不會產(chǎn)生優(yōu)勢。另一方面，Spark可以將數(shù)據(jù)保存在內(nèi)存中以進(jìn)行數(shù)據(jù)轉(zhuǎn)換的多個(gè)步驟，而Hadoop無法。這意味著當(dāng)多次重復(fù)處理同一數(shù)據(jù)時(shí)，Spark提供了優(yōu)勢，這正是分析和機(jī)器學(xué)習(xí)所需要的?，F(xiàn)在考慮以下問題：由于可能同時(shí)運(yùn)行數(shù)十個(gè)或數(shù)百個(gè)此類分析流程，如何以具有成本效益的方式擴(kuò)展處理規(guī)模？顯然，僅僅依靠內(nèi)存中的處理是無法完全解決的，大數(shù)據(jù)的分布式存儲（例如Hadoop）仍然是補(bǔ)充Spark計(jì)算的大數(shù)據(jù)解決方案中必不可少的部分。
數(shù)據(jù)處理領(lǐng)域的另一個(gè)熱門話題是流處理。 它在降低處理速度方面具有巨大優(yōu)勢，因?yàn)樵诮o定的時(shí)間點(diǎn)，只要數(shù)據(jù)到達(dá)，它只需要處理少量數(shù)據(jù)即可。 但是，它在兩個(gè)方面不像批處理那樣通用：第一是輸入數(shù)據(jù)需要進(jìn)入"流"模式，第二是仍然需要處理需要跨時(shí)間段聚合的某些處理邏輯 之后分批。
最后，云解決方案提供了機(jī)會，可以根據(jù)數(shù)據(jù)量（從而根據(jù)并行進(jìn)程的數(shù)量）以更動態(tài)的方式擴(kuò)展分布式處理系統(tǒng)。 在企業(yè)內(nèi)部很難做到這一點(diǎn)，因?yàn)樾枰?jì)劃，預(yù)算和購買新服務(wù)器。 如果不能很好地規(guī)劃容量，則大數(shù)據(jù)處理可能會受到硬件數(shù)量的限制，或者額外購買會導(dǎo)致資源浪費(fèi)而無法使用。 云上的處理獲得了基礎(chǔ)架構(gòu)彈性的巨大優(yōu)勢，它可以提供更多保證，從而以更具成本效益的方式實(shí)現(xiàn)最佳規(guī)模。
與數(shù)據(jù)處理相比，數(shù)據(jù)訪問具有非常不同的特征，包括：
· 數(shù)據(jù)結(jié)構(gòu)高度取決于應(yīng)用程序或用戶如何檢索數(shù)據(jù)
· 數(shù)據(jù)檢索模式需要很好地理解，因?yàn)橐恍?shù)據(jù)可以被大量的用戶或應(yīng)用程序重復(fù)檢索。
· 每次應(yīng)檢索的數(shù)據(jù)量應(yīng)有針對性，因此應(yīng)僅包含一部分可用數(shù)據(jù)。
根據(jù)上述原則，在過去的20年中，有幾個(gè)里程碑反映了如何訪問不斷增長的數(shù)據(jù)量，同時(shí)仍在數(shù)秒內(nèi)返回請求的數(shù)據(jù)：
· 數(shù)據(jù)倉庫：避免表聯(lián)接，這在數(shù)據(jù)量很大時(shí)可能非常昂貴。 這里出現(xiàn)"事實(shí)表"的概念，其中所有列都放在一起，而沒有關(guān)系數(shù)據(jù)庫中的數(shù)據(jù)庫規(guī)范化原則。
· 列存儲：每列都被存儲和索引，因此分別訪問。 當(dāng)一行有很多列，而查詢一次只檢索很少的列時(shí)，這比常規(guī)關(guān)系數(shù)據(jù)庫的基于行的訪問提供了更快的響應(yīng)時(shí)間。
· NoSQL數(shù)據(jù)庫：消除了聯(lián)接和關(guān)系結(jié)構(gòu)，并針對更快速的數(shù)據(jù)檢索量身定制。
· 內(nèi)存數(shù)據(jù)庫：通過將整個(gè)數(shù)據(jù)庫或整個(gè)表保存在內(nèi)存中來提供快速的性能。
下表列出了每種數(shù)據(jù)庫類型的一些受歡迎的示例，但并非旨在提供完整列表。 請注意，一個(gè)數(shù)據(jù)庫可能結(jié)合了不止一種技術(shù)。 例如，Redis以及內(nèi)存中都是NoSQL數(shù)據(jù)庫。 此外，從數(shù)據(jù)倉庫和列存儲的數(shù)據(jù)檢索利用并行流程在適用時(shí)檢索數(shù)據(jù)。 由于可以根據(jù)用戶和/或應(yīng)用程序的數(shù)據(jù)內(nèi)容，數(shù)據(jù)結(jié)構(gòu)和檢索模式，選擇不同類型的數(shù)據(jù)庫，因此數(shù)據(jù)訪問是組織需要快速且不斷發(fā)展的領(lǐng)域。 同時(shí)出于不同目的同時(shí)擁有不同類型的數(shù)據(jù)庫或工具也應(yīng)該很常見。
如我們所見，數(shù)據(jù)處理和數(shù)據(jù)訪問之間的一個(gè)很大區(qū)別是，數(shù)據(jù)訪問最終來自客戶和企業(yè)的需求，而選擇正確的技術(shù)將推動未來新產(chǎn)品的開發(fā)并增強(qiáng)用戶體驗(yàn)。另一方面，數(shù)據(jù)處理是公司的核心資產(chǎn)，規(guī)模處理和產(chǎn)生高質(zhì)量數(shù)據(jù)是公司隨數(shù)據(jù)增長的基本推動力。隨著數(shù)據(jù)量的增長，許多公司會經(jīng)歷其數(shù)據(jù)處理系統(tǒng)的跟蹤問題，并且從頭開始重建數(shù)據(jù)處理平臺的成本很高。并行數(shù)據(jù)處理和可伸縮性的原理需要從一開始就仔細(xì)考慮和設(shè)計(jì)。數(shù)據(jù)處理還與數(shù)據(jù)管理和數(shù)據(jù)集成緊密結(jié)合，這三個(gè)要素對于任何數(shù)據(jù)密集型組織的成功都是至關(guān)重要的。此外，每個(gè)組織現(xiàn)在都面臨著來自開源社區(qū)和第三方供應(yīng)商的眾多大數(shù)據(jù)解決方案選擇。清楚地了解數(shù)據(jù)處理和數(shù)據(jù)訪問之間的差異，可以使IT和業(yè)務(wù)領(lǐng)導(dǎo)者不僅可以構(gòu)建可靠的數(shù)據(jù)體系結(jié)構(gòu)，還可以做出正確的決定，以穩(wěn)定的速度對其進(jìn)行擴(kuò)展和現(xiàn)代化。
