介紹

如果您從大數(shù)據(jù)開始,，通常會(huì)被眾多工具,，框架和選項(xiàng)所困擾。 在本文中,，我將嘗試總結(jié)其成分和基本配方,，以幫助您開始大數(shù)據(jù)之旅。 我的目標(biāo)是對(duì)不同的工具進(jìn)行分類,，并試圖解釋每個(gè)工具的目的以及它如何適應(yīng)生態(tài)系統(tǒng),。

首先,，讓我們回顧一些注意事項(xiàng),，并檢查您是否確實(shí)遇到大數(shù)據(jù)問題。 我將重點(diǎn)介紹可以在本地部署的開源解決方案,。 云提供商為您的數(shù)據(jù)需求提供了幾種解決方案,，我將略微提及它們。 如果您在云中運(yùn)行,，則應(yīng)真正檢查可用的選項(xiàng),，并與開源解決方案進(jìn)行比較，以了解成本,，可操作性,，可管理性，監(jiān)控和上市時(shí)間,。

> Big Data Ecosystem

數(shù)據(jù)注意事項(xiàng)

（如果您有使用大數(shù)據(jù)的經(jīng)驗(yàn),，請(qǐng)?zhí)料乱徊糠帧?/p>

大數(shù)據(jù)非常復(fù)雜，除非絕對(duì)必要,，否則請(qǐng)不要參與其中,。 要獲得見解，請(qǐng)從小處著手,，也許使用Elastic Search和Prometheus / Grafana來開始收集信息并創(chuàng)建儀表板以獲取有關(guān)您的業(yè)務(wù)的信息,。 隨著數(shù)據(jù)的擴(kuò)展，這些工具可能不夠好或維護(hù)成本太高,。 這是您應(yīng)該開始考慮數(shù)據(jù)湖或數(shù)據(jù)倉(cāng)庫(kù)的時(shí)候,。 并改變主意，開始大膽思考,。

檢查數(shù)據(jù)量,，有多少以及需要存儲(chǔ)多長(zhǎng)時(shí)間。 檢查溫度！ 數(shù)據(jù),，它會(huì)隨著時(shí)間的流逝而失去價(jià)值,，那么您需要存儲(chǔ)多長(zhǎng)時(shí)間？ 您需要多少個(gè)存儲(chǔ)層（熱/熱/冷）,？ 您可以存檔或刪除數(shù)據(jù)嗎,？

您需要問自己的其他問題是：您存儲(chǔ)的數(shù)據(jù)類型是什么？ 您使用哪種格式,？ 您有任何法律義務(wù)嗎,？ 您需要多快提取數(shù)據(jù)？ 您需要多長(zhǎng)時(shí)間可用于查詢的數(shù)據(jù),？ 您期望什么類型的查詢,？ OLTP還是OLAP？ 您的基礎(chǔ)架構(gòu)有哪些限制,？ 您的數(shù)據(jù)是什么類型,？ 有關(guān)系嗎 圖形？ 文件,？ 您有要實(shí)施的架構(gòu)嗎,？

我可能會(huì)寫幾篇有關(guān)此的文章，理解此數(shù)據(jù),，設(shè)置邊界,，要求，義務(wù)等非常重要,，這樣才能使此配方生效,。

> 4Vs of Big Data

數(shù)據(jù)量是關(guān)鍵，如果每天要處理數(shù)十億個(gè)事件或海量數(shù)據(jù)集,，則需要將大數(shù)據(jù)原理應(yīng)用于管道,。 但是，沒有一個(gè)單一的邊界可以將'小'數(shù)據(jù)與'大'數(shù)據(jù)以及其他方面（例如速度,，團(tuán)隊(duì)組織,，公司規(guī)模，所需分析類型,，基礎(chǔ)架構(gòu)或業(yè)務(wù)目標(biāo)）區(qū)分開來 您的大數(shù)據(jù)之旅,。 讓我們回顧其中的一些……

OLTP與OLAP

幾年前，企業(yè)曾經(jīng)使用關(guān)系數(shù)據(jù)庫(kù)支持在線應(yīng)用程序,，該關(guān)系數(shù)據(jù)庫(kù)用于存儲(chǔ)用戶和其他結(jié)構(gòu)化數(shù)據(jù)（OLTP）,。 一夜之間，這些數(shù)據(jù)使用復(fù)雜的作業(yè)存檔到數(shù)據(jù)倉(cāng)庫(kù)中,，該倉(cāng)庫(kù)針對(duì)數(shù)據(jù)分析和商業(yè)智能（OLAP）進(jìn)行了優(yōu)化,。 歷史數(shù)據(jù)已復(fù)制到數(shù)據(jù)倉(cāng)庫(kù)中,，并用于生成用于制定業(yè)務(wù)決策的報(bào)告。

數(shù)據(jù)倉(cāng)庫(kù)與數(shù)據(jù)湖

隨著數(shù)據(jù)的增長(zhǎng),，數(shù)據(jù)倉(cāng)庫(kù)變得昂貴且難以管理,。 此外，公司開始存儲(chǔ)和處理非結(jié)構(gòu)化數(shù)據(jù),，例如圖像或日志,。 借助大數(shù)據(jù)，公司開始創(chuàng)建數(shù)據(jù)湖以集中其結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù),，從而創(chuàng)建一個(gè)包含所有數(shù)據(jù)的存儲(chǔ)庫(kù),。

簡(jiǎn)而言之，數(shù)據(jù)湖只是一組將數(shù)據(jù)存儲(chǔ)在HA文件系統(tǒng)中的計(jì)算機(jī)節(jié)點(diǎn),，以及一組用于處理數(shù)據(jù)并從中獲取見解的工具,。 基于Map Reduce，創(chuàng)建了龐大的工具生態(tài)系統(tǒng),，例如Spark,，可以使用更具成本效益的商品硬件處理任何類型的數(shù)據(jù)。其想法是,，您可以在廉價(jià)的硬件中處理和存儲(chǔ)數(shù)據(jù),，然后直接查詢存儲(chǔ)的文件而無需 使用數(shù)據(jù)庫(kù),，但依賴于文件格式和外部架構(gòu),，我們將在后面討論。 Hadoop使用HDFS文件系統(tǒng)以經(jīng)濟(jì)高效的方式存儲(chǔ)數(shù)據(jù),。

對(duì)于OLTP來說,，近年來，已經(jīng)轉(zhuǎn)向NoSQL,，它使用的數(shù)據(jù)庫(kù)可能會(huì)擴(kuò)展到SQL數(shù)據(jù)庫(kù)的局限性之外,，例如MongoDB或Cassandra。 但是,，最近的數(shù)據(jù)庫(kù)可以處理大量數(shù)據(jù),，并且可以用于OLTP和OLAP，并且以低成本進(jìn)行流處理和批處理,。 甚至YugaByteDB之類的事務(wù)數(shù)據(jù)庫(kù)也可以處理大量數(shù)據(jù),。 具有許多系統(tǒng)，應(yīng)用程序,，數(shù)據(jù)源和數(shù)據(jù)類型的大型組織將需要一個(gè)數(shù)據(jù)倉(cāng)庫(kù)和/或數(shù)據(jù)湖來滿足其分析需求,，但是如果您的公司沒有太多的信息渠道和/或您在云中運(yùn)行， 一個(gè)單一的大型數(shù)據(jù)庫(kù)足以簡(jiǎn)化您的架構(gòu)并大大降低成本,。

Hadoop或非Hadoop

自2006年發(fā)布以來,，Hadoop一直是大數(shù)據(jù)世界中的主要參考,。 基于MapReduce編程模型，它允許使用簡(jiǎn)單的編程模型來處理大量數(shù)據(jù),。 多年來,，該生態(tài)系統(tǒng)呈指數(shù)增長(zhǎng)，從而創(chuàng)建了一個(gè)可以處理任何用例的豐富生態(tài)系統(tǒng),。

最近,，人們對(duì)Hadoop生態(tài)系統(tǒng)提出了一些批評(píng)，并且很明顯,，在最近幾年中,，使用率一直在下降。 能夠使用自己的數(shù)據(jù)格式以超低延遲進(jìn)行接收和查詢的新OLAP引擎已取代了Hadoop中一些最常見的查詢引擎,。 但是最大的影響是云提供商發(fā)布的無服務(wù)器分析解決方案數(shù)量增加,，您可以在其中執(zhí)行任何大數(shù)據(jù)任務(wù)而無需管理任何基礎(chǔ)架構(gòu)。

> Simplified Hadoop Ecosystem

考慮到Hadoop生態(tài)系統(tǒng)的規(guī)模和龐大的用戶群,，這似乎還沒有死,，而且許多新的解決方案除了創(chuàng)建兼容的API和與Hadoop生態(tài)系統(tǒng)的集成外別無選擇。 盡管HDFS是生態(tài)系統(tǒng)的核心,，但由于云提供商已構(gòu)建了更便宜,，更好的深度存儲(chǔ)系統(tǒng)（例如S3或GCS），因此現(xiàn)在僅在本地使用,。 云提供商還提供開箱即用的托管Hadoop集群,。 看起來Hadoop仍然活躍并且活躍，但是您應(yīng)該記住,，在開始構(gòu)建Hadoop生態(tài)系統(tǒng)之前,，還有其他更新的選擇。 在本文中,，我將嘗試提及哪些工具是Hadoop生態(tài)系統(tǒng)的一部分,，哪些與之兼容，哪些不是Hadoop生態(tài)系統(tǒng)的一部分,。

批處理與流處理

根據(jù)對(duì)數(shù)據(jù)溫度的分析,，您需要確定是否需要實(shí)時(shí)流傳輸，批處理或在許多情況下都需要,。

在理想環(huán)境中,，您將實(shí)時(shí)地從實(shí)時(shí)數(shù)據(jù)中獲取所有見解，并執(zhí)行基于窗口的聚合,。 但是,，對(duì)于某些用例來說，這是不可能的,，而對(duì)于另一些用例,，則沒有成本效益,。 這就是為什么許多公司同時(shí)使用批處理和流處理的原因。 您應(yīng)該檢查您的業(yè)務(wù)需求,，并確定哪種方法更適合您,。 例如，如果只需要?jiǎng)?chuàng)建一些報(bào)告,，則批處理就足夠了,。 批處理更簡(jiǎn)單，更便宜,。

最新的處理引擎,，例如Apache Flink或Apache Beam，也稱為第四代大數(shù)據(jù)引擎,，為批處理和流數(shù)據(jù)提供統(tǒng)一的編程模型,，其中批處理只是每24小時(shí)進(jìn)行一次流處理。 這簡(jiǎn)化了編程模型,。

一種常見的模式是具有流數(shù)據(jù)以獲取時(shí)間緊迫的見解,，例如信用卡欺詐，以及用于報(bào)告和分析的批處理,。 較新的OLAP引擎允許以統(tǒng)一的方式進(jìn)行查詢,。

ETL與ELT

根據(jù)您的用例，您可能需要在加載或讀取時(shí)轉(zhuǎn)換數(shù)據(jù),。 ELT意味著您可以執(zhí)行將數(shù)據(jù)轉(zhuǎn)換和聚合為查詢一部分的查詢,，這可以使用SQL進(jìn)行，您可以在其中應(yīng)用函數(shù),，過濾數(shù)據(jù),，重命名列，創(chuàng)建視圖等,。BigData OLAP引擎可以實(shí)現(xiàn) 它提供了一種以ELT方式實(shí)時(shí)查詢和批量查詢的方法。 另一種選擇是在負(fù)載（ETL）上轉(zhuǎn)換數(shù)據(jù),，但請(qǐng)注意,，在處理過程中進(jìn)行聯(lián)接和聚合并不是一件容易的事。 通常,，數(shù)據(jù)倉(cāng)庫(kù)使用ETL,，因?yàn)樗鼈儍A向于要求使用固定的模式（星型或雪花型），而數(shù)據(jù)湖更靈活,，并且可以在讀取時(shí)執(zhí)行ELT和模式,。

每種方法都有其自身的優(yōu)點(diǎn)和缺點(diǎn)。 簡(jiǎn)而言之,，讀取時(shí)的轉(zhuǎn)換和聚合速度較慢,，但提供了更大的靈活性,。 如果查詢速度慢，則可能需要在處理階段進(jìn)行預(yù)加入或聚合,。 稍后討論的OLAP引擎可以在攝取期間執(zhí)行預(yù)聚合,。

團(tuán)隊(duì)結(jié)構(gòu)和方法

最后，您的公司政策,，組織,，方法論，基礎(chǔ)架構(gòu),，團(tuán)隊(duì)結(jié)構(gòu)和技能在您的大數(shù)據(jù)決策中起著重要作用,。 例如，您可能有一個(gè)數(shù)據(jù)問題,，需要您創(chuàng)建管道,，但不必處理大量數(shù)據(jù)，在這種情況下,，您可以編寫一個(gè)流應(yīng)用程序,，在該應(yīng)用程序中以 單一管道更容易； 但是如果您的公司已經(jīng)有一個(gè)數(shù)據(jù)湖,，則您可能希望使用現(xiàn)有的平臺(tái),，而這并不是您從頭開始構(gòu)建的。

另一個(gè)例子是ETL與ELT,。 開發(fā)人員傾向于構(gòu)建ETL系統(tǒng),，在該系統(tǒng)中，數(shù)據(jù)可以以簡(jiǎn)單的格式進(jìn)行查詢,，因此非技術(shù)人員可以構(gòu)建儀表板并獲得見解,。 但是，如果您有強(qiáng)大的數(shù)據(jù)分析人員團(tuán)隊(duì)和小型開發(fā)人員團(tuán)隊(duì),，則您可能更喜歡ELT方法,，使開發(fā)人員只專注于提取,； 數(shù)據(jù)分析師編寫復(fù)雜的查詢來轉(zhuǎn)換和聚合數(shù)據(jù),。 這表明在大數(shù)據(jù)旅程中考慮團(tuán)隊(duì)結(jié)構(gòu)和技能的重要性。

建議將一支具有不同技能和背景的多元化團(tuán)隊(duì)一起工作,，因?yàn)閿?shù)據(jù)是整個(gè)組織的跨職能部門,。 數(shù)據(jù)湖非常擅長(zhǎng)在保持?jǐn)?shù)據(jù)治理和安全性的同時(shí)實(shí)現(xiàn)輕松協(xié)作。

配料

在回顧了大數(shù)據(jù)世界的多個(gè)方面之后,，我們來看看基本要素是什么,。

數(shù)據(jù)存儲(chǔ)

您需要的第一件事是一個(gè)存儲(chǔ)所有數(shù)據(jù)的地方。 不幸的是,，沒有一種產(chǎn)品可以滿足您的需求,，這就是為什么您需要根據(jù)用例選擇合適的存儲(chǔ),。

對(duì)于實(shí)時(shí)數(shù)據(jù)攝取，通常使用附加日志來存儲(chǔ)實(shí)時(shí)事件,，最著名的引擎是Kafka,。 另一種選擇是Apache Pulsar。 兩者都提供流功能,，還可以存儲(chǔ)事件,。 這通常是熱數(shù)據(jù)的短期存儲(chǔ)（請(qǐng)記住數(shù)據(jù)溫度！）,，因?yàn)樗唤?jīng)濟(jì)高效,。 還有其他一些工具，例如用于存儲(chǔ)數(shù)據(jù)的Apache NiFi,，它們都有自己的存儲(chǔ)空間,。 最終，數(shù)據(jù)將從附加日志傳輸?shù)搅硪粋€(gè)存儲(chǔ),，該存儲(chǔ)可以是數(shù)據(jù)庫(kù)或文件系統(tǒng),。

海量數(shù)據(jù)庫(kù)

Hadoop HDFS是數(shù)據(jù)湖最常用的格式。 大型數(shù)據(jù)庫(kù)可以用作數(shù)據(jù)管道的后端,，而不是文件系統(tǒng),。 有關(guān)更多信息，請(qǐng)查看我先前在Massive Scale Databases上的文章,。 總之,，諸如Cassandra，YugaByteDB或BigTable之類的數(shù)據(jù)庫(kù)可以保存和處理大量數(shù)據(jù),，其速度比數(shù)據(jù)湖快得多,，但價(jià)格卻不便宜。 但是,，數(shù)據(jù)湖文件系統(tǒng)與數(shù)據(jù)庫(kù)之間的價(jià)格差距逐年縮小,。 在Hadoop / NoHadoop決策中，您需要考慮這一點(diǎn),。 現(xiàn)在,，越來越多的公司選擇大數(shù)據(jù)數(shù)據(jù)庫(kù)而不是數(shù)據(jù)湖來滿足其數(shù)據(jù)需求，而僅將深存儲(chǔ)文件系統(tǒng)用于歸檔,。

總結(jié)要考慮的Hadoop生態(tài)系統(tǒng)之外的數(shù)據(jù)庫(kù)和存儲(chǔ)選項(xiàng)是：

· Cassandra：NoSQL數(shù)據(jù)庫(kù)，可以存儲(chǔ)大量數(shù)據(jù),，提供最終的一致性和許多配置選項(xiàng),。 非常適合OLTP，但可用于帶有預(yù)先計(jì)算的聚合的OLAP（不靈活）,。 一個(gè)替代方案是ScyllaDB,，對(duì)于OLAP（高級(jí)調(diào)度程序）而言,，它更快，更好,。

· YugaByteDB：大規(guī)模關(guān)系數(shù)據(jù)庫(kù),，可以處理全球事務(wù)。 關(guān)系數(shù)據(jù)的最佳選擇,。

· MongoDB：強(qiáng)大的基于文檔的NoSQL數(shù)據(jù)庫(kù),，可用于提取（臨時(shí)存儲(chǔ)）或用作儀表板的快速數(shù)據(jù)層

· InfluxDB用于時(shí)間序列數(shù)據(jù),。

· Prometheus用于監(jiān)視數(shù)據(jù),。

· ElasticSearch：分布式倒排索引，可以存儲(chǔ)大量數(shù)據(jù),。 有時(shí),，ElasticSearch被許多人忽略或僅用于日志存儲(chǔ)，它可用于各種用例,，包括OLAP分析,，機(jī)器學(xué)習(xí)，日志存儲(chǔ),，非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)等等,。 絕對(duì)是您在大數(shù)據(jù)生態(tài)系統(tǒng)中擁有的工具。

記住SQL和NoSQL之間的區(qū)別,，在NoSQL世界中,，您不對(duì)數(shù)據(jù)建模，而是對(duì)查詢建模,。

Hadoop數(shù)據(jù)庫(kù)

HBase是Hadoop生態(tài)系統(tǒng)中最受歡迎的數(shù)據(jù)庫(kù),。 它可以以列格式保存大量數(shù)據(jù)。 它基于BigTable,。

文件系統(tǒng)（深度存儲(chǔ)）

對(duì)于數(shù)據(jù)湖,，在Hadoop生態(tài)系統(tǒng)中，使用HDFS文件系統(tǒng),。 但是,，大多數(shù)云提供商已將其替換為他們自己的深度存儲(chǔ)系統(tǒng)，例如S3或GCS,。

這些文件系統(tǒng)或深度存儲(chǔ)系統(tǒng)比數(shù)據(jù)庫(kù)便宜,，但僅提供基本存儲(chǔ)，不提供強(qiáng)大的ACID保證,。

您將需要根據(jù)您的需求和預(yù)算為您的用例選擇合適的存儲(chǔ),。 例如，如果您的預(yù)算允許，則可以使用數(shù)據(jù)庫(kù)進(jìn)行攝取,，然后轉(zhuǎn)換數(shù)據(jù)后,，將其存儲(chǔ)在數(shù)據(jù)湖中以進(jìn)行OLAP分析。 或者,，您可以將所有內(nèi)容存儲(chǔ)在深度存儲(chǔ)中,，但將一小部分熱數(shù)據(jù)存儲(chǔ)在關(guān)系數(shù)據(jù)庫(kù)等快速存儲(chǔ)系統(tǒng)中。

文件格式

如果使用HDFS,，另一個(gè)重要的決定是將使用哪種格式存儲(chǔ)文件,。 請(qǐng)注意，深度存儲(chǔ)系統(tǒng)將數(shù)據(jù)存儲(chǔ)為文件,，并且不同的文件格式和壓縮算法為某些用例提供了好處,。 如何在數(shù)據(jù)湖中存儲(chǔ)數(shù)據(jù)至關(guān)重要，您需要考慮格式,，壓縮方式,，尤其是如何對(duì)數(shù)據(jù)進(jìn)行分區(qū)。

最常見的格式是CSV,，JSON,，AVRO，協(xié)議緩沖區(qū),，Parquet和ORC,。

> Comparison between file formats

選擇格式時(shí)應(yīng)考慮以下幾點(diǎn)：

· 數(shù)據(jù)的結(jié)構(gòu)：某些格式接受JSON，Avro或Parquet等嵌套數(shù)據(jù),，而其他格式則不接受,。 即使這樣做，也可能不會(huì)對(duì)其進(jìn)行高度優(yōu)化,。 Avro是嵌套數(shù)據(jù)的最有效格式,，我建議不要使用Parquet嵌套類型，因?yàn)樗鼈冃屎艿汀?進(jìn)程嵌套JSON也非常占用CPU,。 通常,，建議在攝取數(shù)據(jù)時(shí)將其放平。

· 性能：Avro和Parquet等某些格式的性能優(yōu)于其他JSON,。 即使在Avro和Parquet的不同用例之間,，一個(gè)也會(huì)比其他更好。 例如,，由于Parquet是基于列的格式,，因此使用SQL查詢數(shù)據(jù)湖非常有用，而Avro更適合ETL行級(jí)轉(zhuǎn)換,。

· 易于閱讀：考慮是否需要人們閱讀數(shù)據(jù),。 JSON或CSV是文本格式，并且易于閱讀,，而功能更強(qiáng)的格式例如鑲木地板或Avro是二進(jìn)制,。

· 壓縮：某些格式比其他格式提供更高的壓縮率。

· 模式演變：在數(shù)據(jù)湖中添加或刪除字段要比在數(shù)據(jù)庫(kù)中復(fù)雜得多,。 諸如Avro或Parquet之類的某些格式提供了某種程度的架構(gòu)演變,，使您可以更改數(shù)據(jù)架構(gòu)并仍然查詢數(shù)據(jù)。 諸如Delta Lake格式的工具甚至提供了更好的工具來處理模式中的更改,。

· 兼容性：JSON或CSV被廣泛采用并與幾乎所有工具兼容,，而性能更高的選項(xiàng)具有較少的集成點(diǎn)。

如我們所見,，CSV和JSON易于使用,，易于閱讀和通用格式，但是缺乏其他格式的許多功能,，因此它太慢而無法用于查詢數(shù)據(jù)湖,。 ORC和Parquet在Hadoop生態(tài)系統(tǒng)中被廣泛用于查詢數(shù)據(jù)，而Avro還在Hadoop之外使用,，尤其是與Kafka一起用于提取時(shí),，對(duì)于行級(jí)ETL處理非常有用。 面向行的格式比面向列的格式具有更好的模式演變功能,，這使它們成為數(shù)據(jù)提取的理想選擇,。

最后，您還需要考慮文件大小和CPU成本之間的權(quán)衡,，如何壓縮文件中的數(shù)據(jù),。 某些壓縮算法速度更快，但文件大小更大,；另一些壓縮算法速度較慢,，但壓縮率更高。 有關(guān)更多詳細(xì)信息,，請(qǐng)查看本文,。

> Compression options

我建議使用快照來流式傳輸數(shù)據(jù)，因?yàn)樗恍枰嗟腃PU能力,。 對(duì)于批處理,，bzip2是一個(gè)不錯(cuò)的選擇。

同樣,，您需要查看我們之前提到的注意事項(xiàng),，并根據(jù)我們查看的所有方面進(jìn)行決策。 讓我們以一些用例為例：

用例

· 您需要在某處提取實(shí)時(shí)數(shù)據(jù)和存儲(chǔ),，以作為ETL管道的一部分進(jìn)行進(jìn)一步處理,。 如果性能很重要并且預(yù)算不是問題，則可以使用Cassandra。 標(biāo)準(zhǔn)方法是使用優(yōu)化格式（如AVRO）將其存儲(chǔ)在HDFS中,。

· 您需要在某個(gè)地方處理數(shù)據(jù)和存儲(chǔ),，以供高度交互的面向用戶的應(yīng)用程序使用，其中延遲很重要（OLTP）,，您需要提前知道查詢,。 在這種情況下，請(qǐng)根據(jù)數(shù)據(jù)量使用Cassandra或其他數(shù)據(jù)庫(kù),。

· 您需要將處理后的數(shù)據(jù)提供給您的用戶群,，一致性很重要，并且由于UI提供了高級(jí)查詢,，因此您不預(yù)先知道查詢,。 在這種情況下，您需要一個(gè)關(guān)系SQL數(shù)據(jù)庫(kù),，根據(jù)您的情況,，像MySQL這樣的經(jīng)典SQL數(shù)據(jù)庫(kù)就足夠了，或者您可能需要使用YugaByteDB或其他關(guān)系大規(guī)模數(shù)據(jù)庫(kù),。

· 您需要為內(nèi)部團(tuán)隊(duì)存儲(chǔ)處理后的數(shù)據(jù)以進(jìn)行OLAP分析,，以便他們可以運(yùn)行臨時(shí)查詢并創(chuàng)建報(bào)告。 在這種情況下,，您可以將數(shù)據(jù)以Parquet或ORC格式存儲(chǔ)在深度存儲(chǔ)文件系統(tǒng)中,。

· 您需要使用SQL來運(yùn)行歷史數(shù)據(jù)的臨時(shí)查詢，但是您還需要儀表板,，這些儀表板需要在不到一秒鐘的時(shí)間內(nèi)做出響應(yīng),。 在這種情況下，您需要一種混合方法,，在該方法中,，將數(shù)據(jù)的子集存儲(chǔ)在快速存儲(chǔ)中（例如MySQL數(shù)據(jù)庫(kù)），并將歷史數(shù)據(jù)以Parquet格式存儲(chǔ)在數(shù)據(jù)湖中,。 然后,，使用查詢引擎使用SQL跨不同的數(shù)據(jù)源進(jìn)行查詢。

· 您需要執(zhí)行非常復(fù)雜的查詢,，而這些查詢只需幾毫秒即可響應(yīng),，還可能需要在讀取時(shí)執(zhí)行聚合。 在這種情況下,，請(qǐng)使用ElasticSearch存儲(chǔ)數(shù)據(jù)或某些較新的OLAP系統(tǒng)（如Apache Pinot）,，稍后我們將對(duì)其進(jìn)行討論。

· 您需要搜索非結(jié)構(gòu)化文本,。 在這種情況下,，請(qǐng)使用ElasticSearch,。

基礎(chǔ)設(shè)施

當(dāng)前的基礎(chǔ)架構(gòu)會(huì)在決定使用哪些工具時(shí)限制您的選擇。 要問的第一個(gè)問題是：云計(jì)算與本地部署,。 云提供商提供了許多選擇和靈活性,。 此外，它們?yōu)槟拇髷?shù)據(jù)需求提供了無服務(wù)器解決方案,，更易于管理和監(jiān)控,。 無疑，云是存放大數(shù)據(jù)的地方,。 即使對(duì)于Hadoop生態(tài)系統(tǒng)，云提供商也提供托管群集和比本地存儲(chǔ)便宜的存儲(chǔ),。 查看我有關(guān)云解決方案的其他文章,。

如果您在場(chǎng)所中運(yùn)行，則應(yīng)考慮以下事項(xiàng)：

· 我在哪里運(yùn)行工作負(fù)載,？ 毫無疑問,，Kubernetes或Apache Mesos提供了一個(gè)統(tǒng)一的編排框架，以統(tǒng)一的方式運(yùn)行您的應(yīng)用程序,。 無論使用哪種框架,，部署，監(jiān)視和警報(bào)方面都是相同的,。 相反,，如果您使用裸機(jī)運(yùn)行，則需要考慮和管理部署的所有交叉方面,。 在這種情況下,，托管集群和工具將比庫(kù)和框架更適合。

· 我擁有哪種類型的硬件,？ 如果您具有帶有快速SSD和高端服務(wù)器的專用硬件,，則可以部署Cassandra等大型數(shù)據(jù)庫(kù)并獲得出色的性能。 如果您僅擁有商品硬件,，那么Hadoop生態(tài)系統(tǒng)將是一個(gè)更好的選擇,。 理想情況下，您希望針對(duì)不同的工作負(fù)載使用多種類型的服務(wù)器,。 Cassandra的要求與HDFS有很大不同,。

監(jiān)控和警報(bào)

下一個(gè)要素對(duì)于數(shù)據(jù)管道的成功至關(guān)重要。 在大數(shù)據(jù)世界中,，您需要有關(guān)流程和數(shù)據(jù)的不斷反饋,。 您需要收集指標(biāo)，收集日志,，監(jiān)視系統(tǒng),，創(chuàng)建警報(bào),，儀表板等等。

使用Prometheus和Grafana等開源工具進(jìn)行監(jiān)視和警報(bào),。 使用日志聚合技術(shù)來收集日志并將其存儲(chǔ)在諸如ElasticSearch之類的地方,。

> Grafana Monitoring

利用云提供商的功能進(jìn)行監(jiān)視和警報(bào)（如果可能）。 根據(jù)您的平臺(tái),，您將使用不同的工具集,。 對(duì)于無云服務(wù)器平臺(tái)，您將依靠您的云提供商工具和最佳實(shí)踐,。 對(duì)于Kubernetes,，您將使用開源監(jiān)控器解決方案或企業(yè)集成。 我真的推薦這個(gè)網(wǎng)站,，在這里您可以瀏覽和檢查不同的解決方案,，并構(gòu)建自己的APM解決方案。

大數(shù)據(jù)世界中要考慮的另一件事是可審計(jì)性和問責(zé)制,。 由于法規(guī)不同,，您可能需要跟蹤數(shù)據(jù)，捕獲和記錄數(shù)據(jù)流經(jīng)管道時(shí)的所有更改,。 這稱為數(shù)據(jù)來源或血統(tǒng),。 諸如Apache Atlas之類的工具用于控制，記錄和管理您的數(shù)據(jù),。 其他工具如Apache NiFi也支持開箱即用的數(shù)據(jù)沿襲,。 有關(guān)實(shí)時(shí)跟蹤，請(qǐng)檢查'打開遙測(cè)'或' Jaeger',。 還有很多云服務(wù),，例如Datadog。

對(duì)于Hadoop,，使用Ganglia,。

安全

Apache Ranger為您的Hadoop平臺(tái)提供了統(tǒng)一的安全監(jiān)控框架。 提供集中的安全性管理,，以在中央U(xiǎn)I中管理所有與安全性相關(guān)的任務(wù),。 它使用不同的方法提供授權(quán)，并在整個(gè)Hadoop平臺(tái)上提供全面的可審核性,。

人

您的團(tuán)隊(duì)是成功的關(guān)鍵,。 大數(shù)據(jù)工程師可能很難找到。 投資于培訓(xùn),，技能提升,，研討會(huì)。 刪除孤島和繁文tape節(jié),，簡(jiǎn)化迭代過程,，并使用域驅(qū)動(dòng)設(shè)計(jì)來設(shè)置團(tuán)隊(duì)邊界和職責(zé),。

對(duì)于大數(shù)據(jù)，您將分為兩大類：

· 數(shù)據(jù)工程師進(jìn)行攝取,，豐富和轉(zhuǎn)換,。 這些工程師具有強(qiáng)大的開發(fā)和運(yùn)營(yíng)背景，并負(fù)責(zé)創(chuàng)建數(shù)據(jù)管道,。 開發(fā)人員,，管理員，DevOps專家等將屬于此類別,。

· 數(shù)據(jù)科學(xué)家：他們可以是BI專家,，數(shù)據(jù)分析師等，負(fù)責(zé)生成報(bào)告,，儀表板和收集見解,。 這些人專注于OLAP并具有深刻的業(yè)務(wù)理解，收集了將用于制定關(guān)鍵業(yè)務(wù)決策的數(shù)據(jù),。 SQL和可視化方面很強(qiáng)，但是軟件開發(fā)方面很弱,。 機(jī)器學(xué)習(xí)專家也可能屬于此類,。

預(yù)算

這是一個(gè)重要的考慮因素，您需要金錢來購(gòu)買所有其他成分,，并且這是有限的資源,。 如果您有無限的資金，則可以部署海量的數(shù)據(jù)庫(kù)并將其用于大數(shù)據(jù)需求而不會(huì)帶來很多麻煩,，但這會(huì)花費(fèi)您很多錢,。 因此，本文中提到的每種技術(shù)都需要具備使用,，部署和維護(hù)技術(shù)的人員,。 有些技術(shù)比其他技術(shù)更復(fù)雜，因此您需要考慮到這一點(diǎn),。

食譜

現(xiàn)在我們已經(jīng)掌握了食材,，讓我們來烹飪我們的大數(shù)據(jù)食譜。 簡(jiǎn)而言之,，該過程很簡(jiǎn)單,； 您需要從不同來源獲取數(shù)據(jù)，對(duì)其進(jìn)行充實(shí),，將其存儲(chǔ)在某個(gè)位置,，存儲(chǔ)元數(shù)據(jù)（模式），對(duì)其進(jìn)行清理,，對(duì)其進(jìn)行規(guī)范化,，對(duì)其進(jìn)行處理,，隔離不良數(shù)據(jù)，以最佳方式聚合數(shù)據(jù)并將其最終存儲(chǔ)在某個(gè)位置以供下游系統(tǒng)使用 ,。

讓我們更詳細(xì)地了解每個(gè)步驟…

數(shù)據(jù)攝取

第一步是獲取數(shù)據(jù),，此階段的目標(biāo)是獲取所需的所有數(shù)據(jù)并將其以原始格式存儲(chǔ)在單個(gè)存儲(chǔ)庫(kù)中。 它通常由將其數(shù)據(jù)推送到Kafka或數(shù)據(jù)存儲(chǔ)中的其他團(tuán)隊(duì)擁有,。

對(duì)于沒有大量數(shù)據(jù)的簡(jiǎn)單管道,，您可以構(gòu)建一個(gè)簡(jiǎn)單的微服務(wù)工作流，該工作流可以在單個(gè)管道中攝取,，豐富和轉(zhuǎn)換數(shù)據(jù)（注入 轉(zhuǎn)換）,，您可以使用Apache Airflow之類的工具來編排依賴性。 但是,，對(duì)于大數(shù)據(jù),，建議您將攝取與處理分開，可以并行運(yùn)行的海量處理引擎對(duì)于處理阻塞調(diào)用,，重試,，背壓等效果不佳。因此,，建議在保存所有數(shù)據(jù)之前 您開始處理它,。 作為調(diào)用的一部分，您應(yīng)該通過調(diào)用其他系統(tǒng)來確保您的數(shù)據(jù)豐富,，以確保所有數(shù)據(jù)（包括參考數(shù)據(jù)）在處理之前都已落入湖泊中,。

有兩種攝取方式：

· 拉取：從數(shù)據(jù)庫(kù),，文件系統(tǒng),，隊(duì)列或API等地方提取數(shù)據(jù)

· 推送：應(yīng)用程序也可以將數(shù)據(jù)推送到您的湖泊中，但始終建議在兩者之間使用一個(gè)消息傳遞平臺(tái),，例如Kafka,。 常見的模式是變更數(shù)據(jù)捕獲（CDC），它使我們能夠?qū)?shù)據(jù)從數(shù)據(jù)庫(kù)和其他系統(tǒng)實(shí)時(shí)移入湖泊,。

正如我們已經(jīng)提到的,，使用Kafka或Pulsar作為數(shù)據(jù)攝取的中介是極為常見的，以實(shí)現(xiàn)持久性,，背壓,，并行化和攝取的監(jiān)控。然后,，使用Kafka Connect將數(shù)據(jù)保存到您的數(shù)據(jù)湖中,。這個(gè)想法是您的OLTP系統(tǒng)將事件發(fā)布到Kafka，然后將其吸收到您的湖泊中,。避免直接通過API批量提取數(shù)據(jù),；您可能會(huì)調(diào)用HTTP端點(diǎn)進(jìn)行數(shù)據(jù)充實(shí),，但請(qǐng)記住，從API提取數(shù)據(jù)在大數(shù)據(jù)世界中并不是一個(gè)好主意,，因?yàn)樗俣嚷?，容易出錯(cuò)（網(wǎng)絡(luò)問題，延遲等）,，并且可能導(dǎo)致源系統(tǒng)崩潰,。盡管API非常適合在OLTP世界中設(shè)置域邊界，但這些邊界是由大數(shù)據(jù)世界中Kafka中的數(shù)據(jù)存儲(chǔ)（批次）或主題（實(shí)時(shí)）來設(shè)置的,。當(dāng)然,，它總是取決于數(shù)據(jù)的大小，但是如果可能,，如果沒有其他選擇,，請(qǐng)嘗試使用Kafka或Pulsar。以流式方式從API中提取少量數(shù)據(jù),，而不是批量提取,。對(duì)于數(shù)據(jù)庫(kù)，請(qǐng)使用Debezium等工具將數(shù)據(jù)流式傳輸?shù)終afka（CDC）,。

為了最大程度地減少依賴性,，如果源系統(tǒng)將數(shù)據(jù)推送到Kafka而不是您的團(tuán)隊(duì)提取數(shù)據(jù)，則總是比較容易,，因?yàn)槟鷮⑴c其他源系統(tǒng)緊密耦合。 如果無法做到這一點(diǎn),，并且您仍然需要掌握攝取過程,，那么我們可以考慮兩種主要的攝取類別：

· Un Managed Solutions：這些是您開發(fā)的應(yīng)用程序，用于將數(shù)據(jù)提取到數(shù)據(jù)湖中,；您可以在任何地方運(yùn)行它們,。從沒有現(xiàn)成解決方案的API或其他I / O阻止系統(tǒng)中提取數(shù)據(jù)時(shí)，或者在不使用Hadoop生態(tài)系統(tǒng)時(shí),，這非常常見,。這個(gè)想法是使用流媒體庫(kù)從不同的主題，端點(diǎn),，隊(duì)列或文件系統(tǒng)中攝取數(shù)據(jù),。因?yàn)槟陂_發(fā)應(yīng)用程序，所以您具有完全的靈活性,。大多數(shù)庫(kù)提供重試,，背壓，監(jiān)視,，批處理等等,。這是您自己的代碼方法,，因此您將需要其他工具來進(jìn)行編排和部署。您可以獲得更多的控制權(quán)和更好的性能,，但需要付出更多的努力,。您可以使用服務(wù)總線使單個(gè)整體或微服務(wù)進(jìn)行通信，或者使用外部工具進(jìn)行協(xié)調(diào),。一些可用的庫(kù)是Apache Camel或Akka生態(tài)系統(tǒng)（Akka HTTP Akka流 Akka集群 Akka Persistence Alpakka）,。您可以將其部署為整體或微服務(wù)，具體取決于接收管道的復(fù)雜程度,。如果您使用Kafka或Pulsar,，則可以將它們用作獲取編排工具來獲取數(shù)據(jù)并豐富數(shù)據(jù)。每個(gè)階段都將數(shù)據(jù)移動(dòng)到一個(gè)新主題,，通過使用主題進(jìn)行依賴性管理在基礎(chǔ)架構(gòu)中創(chuàng)建DAG,。如果您沒有Kafka，并且想要一個(gè)更直觀的工作流程,，則可以使用Apache Airflow來協(xié)調(diào)依賴關(guān)系并運(yùn)行DAG,。這個(gè)想法是要提供一系列服務(wù)來攝取和豐富日期，然后將其存儲(chǔ)在某個(gè)地方,。完成每個(gè)步驟后,，將執(zhí)行下一個(gè)步驟并由Airflow進(jìn)行協(xié)調(diào)。最后,，數(shù)據(jù)存儲(chǔ)在某種存儲(chǔ)中,。

· 托管解決方案：在這種情況下，您可以使用部署在群集中并用于提取的工具,。 這在Hadoop生態(tài)系統(tǒng)中很常見,，在該生態(tài)系統(tǒng)中，您擁有諸如Sqoop之類的工具來從OLTP數(shù)據(jù)庫(kù)中獲取數(shù)據(jù),，而Flume則具有從流媒體中獲取數(shù)據(jù)的能力,。 這些工具提供監(jiān)視，重試,，增量負(fù)載,，壓縮等功能。

Apache NiFi

NiFi是其中很難分類的工具之一,。 它本身就是野獸,。 它可以用于攝取，編排甚至簡(jiǎn)單的轉(zhuǎn)換,。 因此,，從理論上講，它可以解決簡(jiǎn)單的大數(shù)據(jù)問題。 這是一個(gè)托管解決方案,。 它具有可視界面,，您可以在其中拖放組件并使用它們來攝取和豐富數(shù)據(jù)。 它具有300多個(gè)內(nèi)置處理器,，可以執(zhí)行許多任務(wù),，您可以通過實(shí)現(xiàn)自己的處理器來擴(kuò)展它。

> NiFi workflow

它具有自己的體系結(jié)構(gòu),，因此它不使用任何數(shù)據(jù)庫(kù)HDFS,，但已與Hadoop生態(tài)系統(tǒng)中的許多工具集成。 您可以調(diào)用API,，并與Kafka,，F(xiàn)TP，許多文件系統(tǒng)和云存儲(chǔ)集成,。 您可以管理執(zhí)行路由,，過濾和基本ETL的數(shù)據(jù)流。 對(duì)于某些用例,，您可能只需要NiFi,。

但是，由于節(jié)點(diǎn)間的通信,，群集中的10個(gè)以上節(jié)點(diǎn)效率低下,，因此NiFi無法擴(kuò)展到某個(gè)特定點(diǎn)。 它傾向于在垂直方向更好地?cái)U(kuò)展,，但是您可以達(dá)到其極限,，尤其是對(duì)于復(fù)雜的ETL。 但是,，您可以將其與Spark等工具集成以處理數(shù)據(jù),。 NiFi是吸收和豐富數(shù)據(jù)的絕佳工具。

諸如Druid或Pinot之類的現(xiàn)代OLAP引擎還提供了自動(dòng)提取批處理和流數(shù)據(jù)的功能,，我們將在另一部分中討論它們。

您也可以在提取過程中進(jìn)行一些初始驗(yàn)證和數(shù)據(jù)清理,，只要它們不是昂貴的計(jì)算或不跨越有限的上下文,，請(qǐng)記住，空字段可能與您無關(guān),，但對(duì)另一個(gè)團(tuán)隊(duì)很重要,。

最后一步是確定數(shù)據(jù)的放置位置，我們已經(jīng)討論過了,。 您可以使用數(shù)據(jù)庫(kù)或深度存儲(chǔ)系統(tǒng),。 對(duì)于數(shù)據(jù)湖，通常將其存儲(chǔ)在HDFS中，其格式取決于下一步,；請(qǐng)參見下一步,。 如果您打算執(zhí)行行級(jí)操作，Avro是一個(gè)不錯(cuò)的選擇,。 Avro還使用外部注冊(cè)表支持架構(gòu)演變,，這將使您可以相對(duì)輕松地更改所攝取數(shù)據(jù)的架構(gòu)。

元數(shù)據(jù)

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

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

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

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

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

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

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

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

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

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

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

· 重命名字段

· …

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

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

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

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

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

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

處理框架

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

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

· Apache Flink：第一個(gè)統(tǒng)一批處理和流傳輸?shù)囊妫饕P(guān)注流傳輸,。 它可以用作像Kafka這樣的微服務(wù)的主干,。 它可以作為Hadoop集群的一部分在YARN上運(yùn)行，但自成立以來,，它還針對(duì)其他平臺(tái)（如Kubernetes或Mesos）進(jìn)行了優(yōu)化,。 它非常快,，并提供實(shí)時(shí)流傳輸,，使其成為比Spark在低延遲流處理（尤其是有狀態(tài)流）方面更好的選擇。 它還具有用于SQL,，機(jī)器學(xué)習(xí)等的庫(kù),。

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

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

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

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

編排

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

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

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

一些選項(xiàng)是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Apache Griffin Processes

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

> Great expectations UI

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

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

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

· 數(shù)據(jù)倉(cāng)庫(kù)與數(shù)據(jù)湖

· Hadoop與獨(dú)立

· OLAP與OLTP

· 查詢引擎與OLAP引擎

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

處理引擎

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

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支持基于實(shí)現(xiàn)SQL標(biāo)準(zhǔn)的Apache Calcite,。 它還通過HiveCatalog與Hive集成。 例如，用戶可以使用HiveCatalog將其Kafka或ElasticSearch表存儲(chǔ)在Hive Metastore中,，并稍后在SQL查詢中重新使用它們,。

查詢引擎

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

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

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

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

> Drill model

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

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

HBase在設(shè)計(jì)上具有非常有限的ACID屬性,，因?yàn)樗前幢壤龜U(kuò)展的,，并且不提供現(xiàn)成的ACID功能，但是可以用于某些OLTP場(chǎng)景,。

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

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

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

分布式搜索索引

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

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

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

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

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

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

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

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

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

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

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

OLAP引擎

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

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

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

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

> Druid architecture

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

> Apache Pinot

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

> ClickHouse

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

最后,，Greenplum是另一個(gè)更專注于AI的OLAP引擎,。

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

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

結(jié)論

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

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

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

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

如有任何疑問或需要任何建議,，請(qǐng)隨時(shí)與我們聯(lián)系。

希望您喜歡這篇文章,。 隨時(shí)發(fā)表評(píng)論或分享這篇文章,。 跟我來以后的帖子。

(本文翻譯自Javier Ramos的文章《Big Data Pipeline Recipe》,，參考：https:///big-data-pipeline-recipe-c416c1782908)