元數(shù)據(jù)

存儲數(shù)據(jù)后，下一步是保存其元數(shù)據(jù)（有關(guān)數(shù)據(jù)本身的信息）。最常見的元數(shù)據(jù)是架構(gòu)。通過使用外部元數(shù)據(jù)存儲庫，數(shù)據(jù)湖或數(shù)據(jù)管道中的不同工具可以查詢它以推斷數(shù)據(jù)模式。

如果將Avro用作原始數(shù)據(jù)，則外部注冊表是一個不錯的選擇。這樣，您就可以輕松地將處理過程中的提取分離。

數(shù)據(jù)一旦被攝取，為了由OLAP引擎查詢，通常會使用SQL DDL。Hadoop生態(tài)系統(tǒng)中最常用的數(shù)據(jù)湖/數(shù)據(jù)倉庫工具是Apache Hive，它提供了元數(shù)據(jù)存儲，因此您可以像定義了架構(gòu)的數(shù)據(jù)倉庫一樣使用數(shù)據(jù)湖。您可以在Hive上運行SQL查詢，并連接許多其他工具（例如Spark）以使用Spark SQL運行SQL查詢。Hive是Hadoop生態(tài)系統(tǒng)內(nèi)部的重要工具，可為您的分析查詢提供集中的元數(shù)據(jù)庫。其他工具如Apache Tajo都建立在Hive之上，以在您的數(shù)據(jù)湖中提供數(shù)據(jù)倉庫功能。

Apache Impala是Hadoop的本地分析數(shù)據(jù)庫，它提供元數(shù)據(jù)存儲，您仍然可以使用Hcatalog連接到Hive以獲取元數(shù)據(jù)。

Apache Phoenix還有一個metastore，可以與Hive一起使用。Phoenix致力于OLTP，從而啟用對事務(wù)具有ACID屬性的查詢。它具有靈活性，并通過利用HBase作為其后備存儲來提供NoSQL世界中的讀取模式架構(gòu)功能。Apache Druid或Pinot還提供元數(shù)據(jù)存儲。

數(shù)據(jù)處理

此階段的目標(biāo)是使用單個架構(gòu)清理，規(guī)范化，處理和保存數(shù)據(jù)。最終結(jié)果是具有良好定義的架構(gòu)的可信數(shù)據(jù)集。

通常，您需要執(zhí)行某種處理，例如：

· 驗證：通過將數(shù)據(jù)存儲在單獨的存儲中來驗證數(shù)據(jù)并隔離不良數(shù)據(jù)。根據(jù)數(shù)據(jù)質(zhì)量要求，在達到特定閾值時發(fā)送警報。

· 整理和清理：清理數(shù)據(jù)并將其存儲為另一種格式，以便進一步處理，例如，用Avro替換低效的JSON。

· 值的標(biāo)準(zhǔn)化和標(biāo)準(zhǔn)化

· 重命名字段

· …

請記住，目標(biāo)是創(chuàng)建一個可信的數(shù)據(jù)集，以后可用于下游系統(tǒng)。這是數(shù)據(jù)工程師的關(guān)鍵角色。這可以以流或批處理的方式完成。

在批處理的情況下，流水線處理可以分為三個階段：

· 預(yù)處理階段：如果原始數(shù)據(jù)不干凈或格式不正確，則需要對其進行預(yù)處理。此階段包括一些基本驗證，但目標(biāo)是準(zhǔn)備要在下一步進行有效處理的數(shù)據(jù)。在此階段，您應(yīng)該嘗試展平數(shù)據(jù)并將其保存為二進制格式（例如Avro）。這將加快進一步處理的速度。這個想法是，下一階段將執(zhí)行行級操作，并且嵌套查詢非常昂貴，因此現(xiàn)在對數(shù)據(jù)進行平整將提高下一階段的性能。

· 可信階段：數(shù)據(jù)經(jīng)過驗證，清理，規(guī)范化并轉(zhuǎn)換為Hive中存儲的通用模式。目標(biāo)是創(chuàng)建數(shù)據(jù)所有者理解的受信任的通用數(shù)據(jù)集。通常，將創(chuàng)建一個數(shù)據(jù)規(guī)范，數(shù)據(jù)工程師的職責(zé)是應(yīng)用轉(zhuǎn)換以匹配該規(guī)范。最終結(jié)果是以Parquet格式設(shè)置的數(shù)據(jù)集，可以輕松查詢該數(shù)據(jù)集。選擇正確的分區(qū)并優(yōu)化數(shù)據(jù)以執(zhí)行內(nèi)部查詢至關(guān)重要。您可能希望在此階段部分地預(yù)先計算一些聚合，以提高查詢性能。

· 報告階段：此步驟是可選的，但通常是必需的。不幸的是，當(dāng)使用數(shù)據(jù)湖時，單個模式不能滿足所有用例。這是數(shù)據(jù)倉庫和數(shù)據(jù)湖之間的區(qū)別。查詢HDFS的效率不如數(shù)據(jù)庫或數(shù)據(jù)倉庫，因此需要進一步的優(yōu)化。在此階段，您可能需要對數(shù)據(jù)進行規(guī)范化處理，以使用不同的分區(qū)存儲數(shù)據(jù)，以便不同的涉眾可以更有效地查詢數(shù)據(jù)。這個想法是創(chuàng)建針對不同下游系統(tǒng)（數(shù)據(jù)集市）優(yōu)化的不同視圖。在此階段，如果您不使用OLAP引擎，則還可以計算聚合（請參閱下一節(jié)）。受信任的階段對誰將查詢數(shù)據(jù)一無所知，該階段為使用者優(yōu)化了數(shù)據(jù)。如果客戶端是高度交互的，則您可能希望在此階段引入快速存儲層，例如用于快速查詢的關(guān)系數(shù)據(jù)庫。或者，您可以使用OLAP引擎，我們將在后面討論。

對于流來說，邏輯是相同的，但是它將以流的方式在定義的DAG中運行。Spark允許您將流與歷史數(shù)據(jù)一起加入，但存在一些限制。稍后我們將討論OLAP引擎，該引擎更適合于將實時數(shù)據(jù)與歷史數(shù)據(jù)合并。

處理框架

可用于處理的一些工具是：

· Apache Spark：這是最著名的批處理框架。它是Hadoop生態(tài)系統(tǒng)的一部分，是一個托管集群，可提供令人難以置信的并行性，監(jiān)控和出色的UI。它還支持流處理（結(jié)構(gòu)流）?；旧?，Spark在內(nèi)存中運行MapReduce作業(yè)，其性能是常規(guī)MapReduce性能的100倍。它與Hive集成在一起以支持SQL，并可用于創(chuàng)建Hive表，視圖或查詢數(shù)據(jù)。它具有很多集成，支持多種格式，并且擁有龐大的社區(qū)。所有云提供商都支持它。它可以作為Hadoop集群的一部分在YARN上運行，也可以在Kubernetes和其他平臺上運行。它具有許多針對特定用例（例如SQL或機器學(xué)習(xí)）的庫。

· Apache Flink：第一個統(tǒng)一批處理和流傳輸?shù)囊?，但主要關(guān)注流傳輸。?它可以用作像Kafka這樣的微服務(wù)的主干。?它可以作為Hadoop集群的一部分在YARN上運行，但自成立以來，它還針對其他平臺（如Kubernetes或Mesos）進行了優(yōu)化。?它非?？欤⑻峁崟r流傳輸，使其成為比Spark在低延遲流處理（尤其是有狀態(tài)流）方面更好的選擇。?它還具有用于SQL，機器學(xué)習(xí)等的庫。

· Apache Storm：Apache Storm是一個免費的開源分布式實時計算系統(tǒng)，它專注于流傳輸，是Hadoop生態(tài)系統(tǒng)的托管解決方案部分。它具有可擴展性，容錯性，可確保您的數(shù)據(jù)將得到處理，并且易于設(shè)置和操作。

· Apache Samza：另一個出色的有狀態(tài)流處理引擎。Samza允許您構(gòu)建有狀態(tài)的應(yīng)用程序，以從多個來源（包括Apache Kafka）實時處理數(shù)據(jù)。在YARN之上運行的Hadoop生態(tài)系統(tǒng)的托管解決方案部分。

·?Apache Beam：Apache Beam本身不是引擎，而是將所有其他引擎結(jié)合在一起的統(tǒng)一編程模型的規(guī)范。它提供了可以與不同語言一起使用的編程模型，因此開發(fā)人員在處理大數(shù)據(jù)管道時不必學(xué)習(xí)新的語言。然后，它為可在云或本地運行的處理步驟插入了不同的后端。Beam支持前面提到的所有引擎，您可以在它們之間輕松切換并在任何平臺上運行它們：云，YARN，Mesos，Kubernetes。如果您要開始一個新項目，我真的建議您從Beam開始，以確保您的數(shù)據(jù)管道可以用于將來。

在此處理階段結(jié)束時，您已經(jīng)烹飪了數(shù)據(jù)，現(xiàn)在可以使用了！但是，為了烹飪，廚師必須與團隊合作…

編排

數(shù)據(jù)管道編排是一個交叉過程，它管理所有其他任務(wù)之間的依賴關(guān)系。如果使用流處理，則需要編排每個流應(yīng)用程序的依賴關(guān)系，而對于批處理，則需要安排和編排作業(yè)。

任務(wù)和應(yīng)用程序可能會失敗，因此您需要一種以統(tǒng)一的方式計劃，重新計劃，重放，監(jiān)視，重試和調(diào)試整個數(shù)據(jù)管道的方法。

諸如Dagster或Prefect之類的較新框架添加了更多功能，并允許您跟蹤向管道添加語義的數(shù)據(jù)資產(chǎn)。

一些選項是：

· Apache Oozie：Oozie是Hadoop的調(diào)度程序，作業(yè)創(chuàng)建為DAG，并且可以由時間或數(shù)據(jù)可用性觸發(fā)。它與Sqoop等提取工具和Spark等處理框架集成在一起。

· Apache Airflow：Airflow是一個平臺，可用于計劃，運行和監(jiān)視工作流程。使用DAG創(chuàng)建復(fù)雜的工作流程。圖中的每個節(jié)點都是一個任務(wù)，邊定義了任務(wù)之間的依存關(guān)系。Airflow Scheduler在遵循您描述的指定依賴項的同時，在一組工作線程上執(zhí)行您的任務(wù)。它為您生成DAG，以最大程度地提高并行度。DAG是用Python編寫的，因此您可以在本地運行它們，對其進行單元測試并將其與開發(fā)工作流程集成。它還支持SLA和警報。Luigi是具有類似功能的Airflow的替代產(chǎn)品，但Airflow具有更多功能，并且比Luigi具有更好的擴展性。

· Dagster‘s 機器學(xué)習(xí)，分析和ETL的新型協(xié)調(diào)器。主要區(qū)別在于您可以跟蹤數(shù)據(jù)的輸入和輸出，類似于Apache NiFi創(chuàng)建數(shù)據(jù)流解決方案。您還可以在任務(wù)中實現(xiàn)其他值。它還可以并行運行多個作業(yè)，易于添加參數(shù)，易于測試，提供簡單的版本控制等等。它仍然有些不成熟，由于需要跟蹤數(shù)據(jù)，因此可能難以擴展，這是NiFi面臨的一個問題。

· Prefect與Dagster相似，提供本地測試，版本控制，參數(shù)管理等等。Prefect之所以與眾不同，是為了克服Airflow執(zhí)行引擎的局限性，例如改進的計劃程序，參數(shù)化的工作流，動態(tài)工作流，版本控制和改進的測試。它具有一個核心的開源工作流管理系統(tǒng)以及一個完全不需要設(shè)置的云產(chǎn)品。

· Apache NiFi：NiFi還可以安排作業(yè)，監(jiān)視，路由數(shù)據(jù)，警報等等。它專注于數(shù)據(jù)流，但您也可以處理批處理。它在Hadoop外部運行，但可以觸發(fā)Spark作業(yè)并連接到HDFS / S3。

簡而言之，如果您的需求只是編排不需要共享數(shù)據(jù)的獨立任務(wù)，請使用Airflow或Ozzie。對于需要數(shù)據(jù)沿襲和跟蹤的數(shù)據(jù)流應(yīng)用程序，對于非開發(fā)人員請使用NiFi，對于開發(fā)人員請使用Dagster或Prefect。

數(shù)據(jù)質(zhì)量

大數(shù)據(jù)中經(jīng)常忽略的一個重要方面是數(shù)據(jù)質(zhì)量和保證。由于數(shù)據(jù)質(zhì)量問題，公司每年都會損失大量資金。問題在于，這仍然是數(shù)據(jù)科學(xué)領(lǐng)域中一個不成熟的領(lǐng)域，開發(fā)人員已經(jīng)在這一領(lǐng)域工作了數(shù)十年，他們擁有出色的測試框架和方法，例如BDD或TDD，但是您如何測試管道？

該領(lǐng)域存在兩個常見問題：

· 誤解的要求：轉(zhuǎn)換和編排邏輯經(jīng)常會變得非常復(fù)雜。業(yè)務(wù)分析師可以使用他們的領(lǐng)域語言來編寫需求，開發(fā)人員通常會犯錯，并計劃，開發(fā)，測試和部署技術(shù)上正確但有錯誤需求的解決方案。這些類型的錯誤非常昂貴。

· 數(shù)據(jù)驗證：管道測試與代碼完全不同。開發(fā)軟件時，您要測試功能，這是確定性的黑盒測試。對于給定的輸入，您始終會獲得相同的輸出。對于數(shù)據(jù)資產(chǎn)，測試更加復(fù)雜：您需要聲明數(shù)據(jù)類型，值，約束等等。此外，您需要應(yīng)用聚合來驗證數(shù)據(jù)集，以確保行數(shù)或列數(shù)正確。例如，很難檢測是否有一天您的數(shù)據(jù)量下降了10％，或者某些值是否正確填充。

公司在數(shù)據(jù)質(zhì)量和測試方面仍處于起步階段，這造成了巨大的技術(shù)負(fù)擔(dān)。我真的建議查看這篇文章以獲取更多信息。

為了緩解這些問題，請嘗試遵循DDD原則，并確保設(shè)置了邊界并使用了通用語言。使用支持?jǐn)?shù)據(jù)譜系的框架，例如NiFi或Dagster。

一些關(guān)注數(shù)據(jù)質(zhì)量的工具是：

·?Apache Griffin：此工具是Hadoop生態(tài)系統(tǒng)的一部分，它提供了一個統(tǒng)一的過程，可以從不同角度衡量數(shù)據(jù)質(zhì)量，從而幫助您構(gòu)建可信任的數(shù)據(jù)資產(chǎn)。它提供了一個DSL，可用于為數(shù)據(jù)創(chuàng)建斷言并將其驗證為管道的一部分。它與Spark集成在一起。您可以為數(shù)據(jù)集添加規(guī)則和斷言，然后將驗證作為Spark作業(yè)運行。Griffin的問題在于DSL可能變得難以管理（JSON），并且非技術(shù)人員難以解釋，這意味著它無法解決被誤解的需求問題。

> Apache Griffin Processes

·?Great Expectations?：這是一個用Python編寫的更新工具，專注于數(shù)據(jù)質(zhì)量，管道測試和質(zhì)量保證。它可以輕松地與Airflow或其他編排工具集成，并提供自動數(shù)據(jù)驗證。使該工具與眾不同的是事實，它是人類可讀的，并且可由數(shù)據(jù)分析師，BA和開發(fā)人員使用。它提供了直觀的UI，還提供了完全自動化的功能，因此您可以將驗證作為生產(chǎn)管道的一部分運行，并在漂亮的UI中查看結(jié)果。非技術(shù)人員可以使用筆記本編寫斷言，這些筆記本提供開發(fā)人員可以輕松理解，轉(zhuǎn)換為代碼并用于測試的文檔和正式要求。BA或測試人員編寫數(shù)據(jù)斷言（期望），然后將其轉(zhuǎn)換為UI中的人類可讀測試，以便每個人都可以看到并驗證它們。它還可以進行數(shù)據(jù)分析以為您生成一些斷言。它可以直接連接到本地或云中的數(shù)據(jù)庫或文件系統(tǒng)。它非常易于使用和管理?？梢詫⑵谕堤峤坏皆创a存儲庫，然后將其集成到管道中。偉大的期望為涉及數(shù)據(jù)質(zhì)量的所有各方創(chuàng)建了一種通用的語言和框架，從而非常容易地以最小的努力來自動化和測試管道。

> Great expectations UI

數(shù)據(jù)查詢

現(xiàn)在，您已經(jīng)掌握了烹調(diào)方法，現(xiàn)在該從該方法中獲得最大價值了。至此，您已經(jīng)使用一些深層存儲（如HDFS）以可查詢的格式（例如Parquet或OLAP數(shù)據(jù)庫）將數(shù)據(jù)存儲在數(shù)據(jù)湖中。

有多種工具可用于查詢數(shù)據(jù)，每種工具都有其優(yōu)點和缺點。它們中的大多數(shù)都集中在OLAP上，但是也很少針對OLTP進行過優(yōu)化。有些使用標(biāo)準(zhǔn)格式，僅專注于運行查詢，而另一些使用自己的格式/存儲將處理推送到源，以提高性能。有些使用星型或雪花模式針對數(shù)據(jù)倉庫進行了優(yōu)化，而另一些則更為靈活。總結(jié)這些是不同的注意事項：

· 數(shù)據(jù)倉庫與數(shù)據(jù)湖

· Hadoop與獨立

· OLAP與OLTP

· 查詢引擎與OLAP引擎

我們還應(yīng)該考慮具有查詢功能的處理引擎。

處理引擎

我們在上一節(jié)中描述的大多數(shù)引擎都可以連接到元數(shù)據(jù)服務(wù)器，例如Hive并運行查詢，創(chuàng)建視圖等。這是創(chuàng)建精細(xì)報表層的常見用例。

Spark SQL提供了一種將SQL查詢與Spark程序無縫混合的方法，因此您可以將DataFrame API與SQL混合。它具有Hive集成和通過JDBC或ODBC的標(biāo)準(zhǔn)連接；因此您可以通過Spark將Tableau，Looker或任何BI工具連接到數(shù)據(jù)。

Apache Flink還提供SQL API。?Flink的SQL支持基于實現(xiàn)SQL標(biāo)準(zhǔn)的Apache Calcite。?它還通過HiveCatalog與Hive集成。?例如，用戶可以使用HiveCatalog將其Kafka或ElasticSearch表存儲在Hive Metastore中，并稍后在SQL查詢中重新使用它們。

查詢引擎

這類工具專注于以統(tǒng)一的方式查詢不同的數(shù)據(jù)源和格式。這個想法是使用SQL查詢來查詢您的數(shù)據(jù)湖，就像它是一個關(guān)系數(shù)據(jù)庫一樣，盡管它有一些限制。其中一些工具還可以查詢NoSQL數(shù)據(jù)庫等等。這些工具為外部工具（如Tableau或Looker）提供JDBC接口，以安全方式連接到您的數(shù)據(jù)湖。查詢引擎是最慢的選擇，但提供最大的靈活性。

· Apache Pig：它是與Hive一起使用的最早的查詢語言之一。它有自己的語言，不同于SQL。Pig程序的顯著特性是它們的結(jié)構(gòu)適合于實質(zhì)性的并行化，從而使它們能夠處理非常大的數(shù)據(jù)集。現(xiàn)在，它越來越傾向于使用基于SQL的新引擎。

· Presto：由Facebook發(fā)布為開源，它是一個開源的分布式SQL查詢引擎，用于對各種規(guī)模的數(shù)據(jù)源運行交互式分析查詢。Presto允許查詢數(shù)據(jù)所在的位置，包括Hive，Cassandra，關(guān)系數(shù)據(jù)庫和文件系統(tǒng)。它可以在幾秒鐘內(nèi)對大型數(shù)據(jù)集執(zhí)行查詢。它獨立于Hadoop，但與大多數(shù)工具集成在一起，尤其是Hive以運行SQL查詢。

· Apache Drill：為Hadoop，NoSQL甚至云存儲提供無模式的SQL查詢引擎。它獨立于Hadoop，但與Hive等生態(tài)系統(tǒng)工具集成了許多功能。單個查詢可以聯(lián)接來自多個數(shù)據(jù)存儲的數(shù)據(jù)，從而執(zhí)行特定于每個數(shù)據(jù)存儲的優(yōu)化。即使分析人員在后臺讀取文件，它也非常擅長讓分析人員將任何數(shù)據(jù)視為表。Drill支持完全標(biāo)準(zhǔn)的SQL。商業(yè)用戶，分析師和數(shù)據(jù)科學(xué)家可以使用標(biāo)準(zhǔn)的BI /分析工具（例如Tableau，Qlik和Excel）來利用Drill的JDBC和ODBC驅(qū)動程序與非關(guān)系數(shù)據(jù)存儲進行交互。此外，開發(fā)人員可以在其自定義應(yīng)用程序中利用Drill的簡單REST API來創(chuàng)建精美的可視化效果。

> Drill model

OLTP數(shù)據(jù)庫

盡管Hadoop已針對OLAP進行了優(yōu)化，但是如果您要為交互式應(yīng)用程序執(zhí)行OLTP查詢，仍然有一些選擇。

HBase在設(shè)計上具有非常有限的ACID屬性，因為它是按比例擴展的，并且不提供現(xiàn)成的ACID功能，但是可以用于某些OLTP場景。

Apache Phoenix建立在HBase之上，并提供了一種在Hadoop生態(tài)系統(tǒng)中執(zhí)行OTLP查詢的方法。Apache Phoenix與其他Hadoop產(chǎn)品（例如Spark，Hive，Pig，F(xiàn)lume和Map Reduce）完全集成。它還可以存儲元數(shù)據(jù)，并支持通過DDL命令創(chuàng)建表和版本化的增量更改。它非?？?，比使用Drill或其他查詢引擎要快。

您可以使用Hadoop生態(tài)系統(tǒng)以外的任何大規(guī)模數(shù)據(jù)庫，例如Cassandra，YugaByteDB，SyllaDB for OTLP。

最后，在任何類型的快速數(shù)據(jù)庫（例如MongoDB或MySQL）中擁有數(shù)據(jù)的子集（通常是最新數(shù)據(jù)）是很常見的。上面提到的查詢引擎可以在單個查詢中在慢速和快速數(shù)據(jù)存儲之間加入數(shù)據(jù)。

分布式搜索索引

這些工具提供了一種存儲和搜索非結(jié)構(gòu)化文本數(shù)據(jù)的方法，并且由于它們需要特殊的結(jié)構(gòu)來存儲數(shù)據(jù)，因此它們位于Hadoop生態(tài)系統(tǒng)之外。這個想法是使用倒排索引來執(zhí)行快速查找。除了文本搜索外，該技術(shù)還可以用于各種用例，例如存儲日志，事件等。有兩個主要選項：

· Solr：這是一個基于Apache Lucene的流行，快速，開放源代碼的企業(yè)搜索平臺。Solr是可靠的，可伸縮的和容錯的，提供分布式索引，復(fù)制和負(fù)載平衡查詢，自動故障轉(zhuǎn)移和恢復(fù)，集中式配置等。它非常適合文本搜索，但與ElasticSearch相比，它的用例有限。

· ElasticSearch：它也是一種非常流行的分布式索引，但是已經(jīng)發(fā)展成為自己的生態(tài)系統(tǒng)，涵蓋了許多用例，例如APM，搜索，文本存儲，分析，儀表板，機器學(xué)習(xí)等。它絕對是一種非常有用的工具，可用于DevOps或數(shù)據(jù)管道，因為它用途廣泛。它還可以存儲和搜索視頻和圖像。

ElasticSearch可用作數(shù)據(jù)湖的快速存儲層，以提供高級搜索功能。如果將數(shù)據(jù)存儲在鍵值型海量數(shù)據(jù)庫中，例如HBase或Cassandra，由于缺少聯(lián)接，它們提供的搜索功能非常有限；您可以將ElasticSearch放在前面以執(zhí)行查詢，返回ID，然后對數(shù)據(jù)庫進行快速查找。

它也可以用于分析。您可以導(dǎo)出數(shù)據(jù)，對其進行索引，然后使用Kibana對其進行查詢，創(chuàng)建儀表板，報告等等，還可以添加直方圖，復(fù)雜的聚合甚至在數(shù)據(jù)之上運行機器學(xué)習(xí)算法。彈性生態(tài)系統(tǒng)非常龐大，值得探索。

OLAP數(shù)據(jù)庫

在此類別中，我們有數(shù)據(jù)庫，該數(shù)據(jù)庫還可以提供用于模式和查詢功能的元數(shù)據(jù)存儲。與查詢引擎相比，這些工具還提供存儲，并且在數(shù)據(jù)倉庫的情況下可以強制執(zhí)行某些架構(gòu)（星型架構(gòu)）。這些工具使用SQL語法，Spark和其他框架可以與它們進行交互。

· Apache Hive：我們已經(jīng)討論過Hive作為Spark和其他工具的中央模式存儲庫，以便它們可以使用SQL，但是Hive也可以存儲數(shù)據(jù)，因此您可以將其用作數(shù)據(jù)倉庫。它可以訪問HDFS或HBase。查詢Hive時，它會利用Apache Tez，Apache Spark或MapReduce，而Tez或Spark的速度要快得多。它還具有一種稱為HPL-SQL的過程語言。

· Apache Impala：這是Hadoop的本地分析數(shù)據(jù)庫，您可以使用它來存儲數(shù)據(jù)并以有效的方式查詢它。它可以使用Hcatalog連接到Hive獲取元數(shù)據(jù)。Impala為Hadoop上的BI /分析查詢提供了低延遲和高并發(fā)性（不是由批處理框架（如Apache Hive）提供的）。即使在多租戶環(huán)境中，Impala也會線性擴展，從而比Hive更好地替代查詢。Impala與本機Hadoop安全性和Kerberos集成在一起以進行身份驗證，因此您可以安全地管理數(shù)據(jù)訪問。它使用HBase和HDFS進行數(shù)據(jù)存儲。

· Apache Tajo：這是Hadoop的另一個數(shù)據(jù)倉庫。Tajo專為針對HDFS和其他數(shù)據(jù)源上存儲的大數(shù)據(jù)集的低延遲和可擴展的即席查詢，在線聚合和ETL而設(shè)計。它與Hive Metastore集成在一起以訪問通用模式。它具有許多查詢優(yōu)化功能，具有可伸縮性，容錯能力，并提供JDBC接口。

· Apache Kylin：Apache Kylin是更新的分布式分析數(shù)據(jù)倉庫。Kylin的運行速度非?？?，因此對于儀表盤或交互式報表等性能很重要的用例，它可以用于補充Hive等其他一些數(shù)據(jù)庫，它可能是最好的OLAP數(shù)據(jù)倉庫，但使用起來比較困難。問題在于，由于維數(shù)高，您需要更多的存儲空間。這個想法是，如果查詢引擎或Hive不夠快，您可以在Kylin中創(chuàng)建一個"多維數(shù)據(jù)集"，這是針對OLAP優(yōu)化的多維表，具有可從儀表板或交互式報表中查詢的預(yù)先計算的值。它可以直接從Spark生成多維數(shù)據(jù)集，甚至可以從Kafka實時生成多維數(shù)據(jù)集。

OLAP引擎

在此類別中，我包括較新的引擎，這些引擎是對以前的OLAP數(shù)據(jù)庫的改進，這些數(shù)據(jù)庫提供了創(chuàng)建多合一分析平臺的更多功能。實際上，它們是前兩種類別的混合，為您的OLAP數(shù)據(jù)庫添加了索引。它們位于Hadoop平臺之外，但緊密集成。在這種情況下，您通常會跳過處理階段并直接使用這些工具進行提取。

他們試圖解決以統(tǒng)一的方式查詢實時和歷史數(shù)據(jù)的問題，以便您可以在查詢到實時數(shù)據(jù)以及低延遲的歷史數(shù)據(jù)后立即立即查詢實時數(shù)據(jù)，從而構(gòu)建交互式應(yīng)用程序和儀表板。這些工具在許多情況下允許以ELT方式進行幾乎沒有任何轉(zhuǎn)換的原始數(shù)據(jù)查詢，但性能卻優(yōu)于常規(guī)OLAP數(shù)據(jù)庫。

它們的共同點是它們提供了數(shù)據(jù)的統(tǒng)一視圖，實時和批處理數(shù)據(jù)的接收，分布式索引，其自身的數(shù)據(jù)格式，SQL支持，JDBC接口，熱冷數(shù)據(jù)支持，多種集成和元數(shù)據(jù)存儲。

· Apache Druid：這是最著名的實時OLAP引擎。它專注于時間序列數(shù)據(jù)，但可用于任何類型的數(shù)據(jù)。它使用自己的列式格式，可以大量壓縮數(shù)據(jù)，并且具有很多內(nèi)置的優(yōu)化功能，例如倒排索引，文本編碼，自動數(shù)據(jù)匯總等等。使用具有極低延遲的Tranquility或Kafka實時攝取數(shù)據(jù)，數(shù)據(jù)以針對寫入而優(yōu)化的行格式保存在內(nèi)存中，但是一旦到達，就可以像以前攝取的數(shù)據(jù)一樣查詢。后臺任務(wù)，負(fù)責(zé)將數(shù)據(jù)異步移動到深度存儲系統(tǒng)（例如HDFS）。當(dāng)數(shù)據(jù)移至深層存儲時，它將轉(zhuǎn)換為較小的塊，這些塊按時間段進行了劃分，這些段針對低延遲查詢進行了高度優(yōu)化。每個段都有一個時間戳和幾個維，您可以使用它們過濾和執(zhí)行聚合。和指標(biāo)是預(yù)先計算的匯總。對于批量提取，它將數(shù)據(jù)直接保存到細(xì)分中。它支持推拉式攝取。它與Hive，Spark甚至NiFi集成在一起。它可以使用Hive Metastore，并且支持Hive SQL查詢，然后將其轉(zhuǎn)換為Druid使用的JSON查詢。Hive集成支持JDBC，因此您可以連接任何BI工具。它還有自己的元數(shù)據(jù)存儲，通常是MySQL。它可以吸收大量數(shù)據(jù)并很好地擴展。主要問題是它具有許多組件，并且難以管理和部署。

> Druid architecture

· Apache Pinot：這是LinkedIn開源的Druid的更新替代品。與Druid相比，由于Startree索引提供了部分預(yù)先計算，因此它提供了更低的延遲，因此它可用于面向用戶的應(yīng)用程序（用于獲取LinkedIn提要）。它使用排序索引而不是倒排索引，索引速度更快。它具有可擴展的插件架構(gòu)，并且具有許多集成，但不支持Hive。它還統(tǒng)一了批處理和實時功能，提供快速接收，智能索引并將數(shù)據(jù)分段存儲。與Druid相比，它更容易部署且速度更快，但目前還不成熟。

> Apache Pinot

ClickHouse：用C ++編寫，此引擎為OLAP查詢（尤其是聚合）提供了令人難以置信的性能。它看起來像一個關(guān)系數(shù)據(jù)庫，因此您可以非常輕松地對數(shù)據(jù)建模。它非常容易設(shè)置，并且具有許多集成。

> ClickHouse

查看這篇文章，其中詳細(xì)比較了3個引擎。同樣，從小處著手并在做出決定之前了解您的數(shù)據(jù)，這些新引擎功能強大，但難以使用。如果您可以等待幾個小時，則使用批處理和Hive或Tajo等數(shù)據(jù)庫；然后使用Kylin加快OLAP查詢的速度，使其更具交互性。如果這還不夠，并且您需要更低的延遲和實時數(shù)據(jù)，請考慮使用OLAP引擎。德魯伊更適合實時分析。麒麟更專注于OLAP案件。Druid與Kafka的實時流媒體集成良好。Kylin分批從Hive或Kafka獲取數(shù)據(jù)；盡管計劃在不久的將來進行實時攝取。

最后，Greenplum是另一個更專注于AI的OLAP引擎。

> Presto/Drill provide more flexibility, Kylin great latency, Druid and Pinot, the best of both worl

最后，對于可視化，您可以使用多種商業(yè)工具，例如Qlik，Looker或Tableau。對于開源，請檢查SuperSet，這是一個了不起的工具，它支持我們提到的所有工具，具有出色的編輯器，而且速度非?？?。Metabase或Falcon是其他不錯的選擇。

結(jié)論

我們討論了很多數(shù)據(jù)：不同的形狀，格式，如何處理，存儲以及更多內(nèi)容。切記：了解您的數(shù)據(jù)和業(yè)務(wù)模型。使用迭代過程，慢慢開始構(gòu)建您的大數(shù)據(jù)平臺；不是通過引入新框架而是通過提出正確的問題并尋找可以為您提供正確答案的最佳工具。

查看數(shù)據(jù)的不同注意事項，根據(jù)數(shù)據(jù)模型（SQL），查詢（NoSQL），基礎(chǔ)結(jié)構(gòu)和預(yù)算選擇合適的存儲。請記住與您的云提供商合作并評估云產(chǎn)品的大數(shù)據(jù)（購買與構(gòu)建）。從無服務(wù)器分析流水線開始，然后隨著成本的增加而逐漸過渡到開源解決方案，這是很常見的。

由于對您控制范圍之外的系統(tǒng)的依賴性，數(shù)據(jù)提取至關(guān)重要且復(fù)雜。嘗試管理那些依賴關(guān)系并創(chuàng)建可靠的數(shù)據(jù)流以正確提取數(shù)據(jù)。如果可能，請其他團隊負(fù)責(zé)數(shù)據(jù)提取。請記住添加指標(biāo)，日志和跟蹤以跟蹤數(shù)據(jù)。啟用架構(gòu)演變，并確保已在平臺中設(shè)置適當(dāng)?shù)陌踩浴?/p>

使用正確的工具完成工作，不要花費太多。諸如Cassandra，Druid或ElasticSearch之類的工具是令人贊嘆的技術(shù)，但需要大量知識才能正確使用和管理。如果只需要對臨時查詢和報告進行OLAP批處理分析，請使用Hive或Tajo。如果需要更好的性能，請?zhí)砑覭ylin。如果還需要與其他數(shù)據(jù)源聯(lián)接，請?zhí)砑硬樵円?，例如Drill或Presto。此外，如果您需要實時查詢批次，請使用ClickHouse，Druid或Pinot。

詳情請關(guān)注上篇內(nèi)容

領(lǐng)取更多大數(shù)據(jù)免費資料QQ群：1127558097

猜你喜歡：

帶你了解，什么是大數(shù)據(jù)！（上）

大數(shù)據(jù)的下一站是什么？

大數(shù)據(jù)時代的數(shù)據(jù)價值與發(fā)展趨勢