如果您從大數(shù)據(jù)開(kāi)始，通常會(huì)被眾多工具，框架和選項(xiàng)所困擾。 在本文中，我將嘗試總結(jié)其成分和基本配方，以幫助您開(kāi)始大數(shù)據(jù)之旅。 我的目標(biāo)是對(duì)不同的工具進(jìn)行分類(lèi)，并試圖解釋每個(gè)工具的目的以及它如何適應(yīng)生態(tài)系統(tǒng)。
首先，讓我們回顧一些注意事項(xiàng)，并檢查您是否確實(shí)遇到大數(shù)據(jù)問(wèn)題。 我將重點(diǎn)介紹可以在本地部署的開(kāi)源解決方案。 云提供商為您的數(shù)據(jù)需求提供了幾種解決方案，我將略微提及它們。 如果您在云中運(yùn)行，則應(yīng)真正檢查可用的選項(xiàng)，并與開(kāi)源解決方案進(jìn)行比較，以了解成本，可操作性，可管理性，監(jiān)控和上市時(shí)間。
> Big Data Ecosystem
（如果您有使用大數(shù)據(jù)的經(jīng)驗(yàn)，請(qǐng)?zhí)料乱徊糠帧?/p>
大數(shù)據(jù)非常復(fù)雜，除非絕對(duì)必要，否則請(qǐng)不要參與其中。 要獲得見(jiàn)解，請(qǐng)從小處著手，也許使用Elastic Search和Prometheus / Grafana來(lái)開(kāi)始收集信息并創(chuàng)建儀表板以獲取有關(guān)您的業(yè)務(wù)的信息。 隨著數(shù)據(jù)的擴(kuò)展，這些工具可能不夠好或維護(hù)成本太高。 這是您應(yīng)該開(kāi)始考慮數(shù)據(jù)湖或數(shù)據(jù)倉(cāng)庫(kù)的時(shí)候。 并改變主意，開(kāi)始大膽思考。
檢查數(shù)據(jù)量，有多少以及需要存儲(chǔ)多長(zhǎng)時(shí)間。 檢查溫度！ 數(shù)據(jù)，它會(huì)隨著時(shí)間的流逝而失去價(jià)值，那么您需要存儲(chǔ)多長(zhǎng)時(shí)間？ 您需要多少個(gè)存儲(chǔ)層（熱/熱/冷）？ 您可以存檔或刪除數(shù)據(jù)嗎？
您需要問(wèn)自己的其他問(wèn)題是：您存儲(chǔ)的數(shù)據(jù)類(lèi)型是什么？ 您使用哪種格式？ 您有任何法律義務(wù)嗎？ 您需要多快提取數(shù)據(jù)？ 您需要多長(zhǎng)時(shí)間可用于查詢的數(shù)據(jù)？ 您期望什么類(lèi)型的查詢？ OLTP還是OLAP？ 您的基礎(chǔ)架構(gòu)有哪些限制？ 您的數(shù)據(jù)是什么類(lèi)型？ 有關(guān)系嗎 圖形？ 文件？ 您有要實(shí)施的架構(gòu)嗎？
我可能會(huì)寫(xiě)幾篇有關(guān)此的文章，理解此數(shù)據(jù)，設(shè)置邊界，要求，義務(wù)等非常重要，這樣才能使此配方生效。
> 4Vs of Big Data
數(shù)據(jù)量是關(guān)鍵，如果每天要處理數(shù)十億個(gè)事件或海量數(shù)據(jù)集，則需要將大數(shù)據(jù)原理應(yīng)用于管道。 但是，沒(méi)有一個(gè)單一的邊界可以將'小'數(shù)據(jù)與'大'數(shù)據(jù)以及其他方面（例如速度，團(tuán)隊(duì)組織，公司規(guī)模，所需分析類(lèi)型，基礎(chǔ)架構(gòu)或業(yè)務(wù)目標(biāo)）區(qū)分開(kāi)來(lái) 您的大數(shù)據(jù)之旅。 讓我們回顧其中的一些……
幾年前，企業(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ù)的增長(zhǎng)，數(shù)據(jù)倉(cāng)庫(kù)變得昂貴且難以管理。 此外，公司開(kāi)始存儲(chǔ)和處理非結(jié)構(gòu)化數(shù)據(jù)，例如圖像或日志。 借助大數(shù)據(jù)，公司開(kāi)始創(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ù)并從中獲取見(jiàn)解的工具。 基于Map Reduce，創(chuàng)建了龐大的工具生態(tài)系統(tǒng)，例如Spark，可以使用更具成本效益的商品硬件處理任何類(lèi)型的數(shù)據(jù)。其想法是，您可以在廉價(jià)的硬件中處理和存儲(chǔ)數(shù)據(jù)，然后直接查詢存儲(chǔ)的文件而無(wú)需 使用數(shù)據(jù)庫(kù)，但依賴于文件格式和外部架構(gòu)，我們將在后面討論。 Hadoop使用HDFS文件系統(tǒng)以經(jīng)濟(jì)高效的方式存儲(chǔ)數(shù)據(jù)。
對(duì)于OLTP來(lái)說(shuō)，近年來(lái)，已經(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之類(lèi)的事務(wù)數(shù)據(jù)庫(kù)也可以處理大量數(shù)據(jù)。 具有許多系統(tǒng)，應(yīng)用程序，數(shù)據(jù)源和數(shù)據(jù)類(lèi)型的大型組織將需要一個(gè)數(shù)據(jù)倉(cāng)庫(kù)和/或數(shù)據(jù)湖來(lái)滿足其分析需求，但是如果您的公司沒(méi)有太多的信息渠道和/或您在云中運(yùn)行， 一個(gè)單一的大型數(shù)據(jù)庫(kù)足以簡(jiǎn)化您的架構(gòu)并大大降低成本。
自2006年發(fā)布以來(lái)，Hadoop一直是大數(shù)據(jù)世界中的主要參考。 基于MapReduce編程模型，它允許使用簡(jiǎn)單的編程模型來(lái)處理大量數(shù)據(jù)。 多年來(lái)，該生態(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中一些最常見(jiàn)的查詢引擎。 但是最大的影響是云提供商發(fā)布的無(wú)服務(wù)器分析解決方案數(shù)量增加，您可以在其中執(zhí)行任何大數(shù)據(jù)任務(wù)而無(wú)需管理任何基礎(chǔ)架構(gòu)。
> Simplified Hadoop Ecosystem
考慮到Hadoop生態(tài)系統(tǒng)的規(guī)模和龐大的用戶群，這似乎還沒(méi)有死，而且許多新的解決方案除了創(chuàng)建兼容的API和與Hadoop生態(tài)系統(tǒng)的集成外別無(wú)選擇。 盡管HDFS是生態(tài)系統(tǒng)的核心，但由于云提供商已構(gòu)建了更便宜，更好的深度存儲(chǔ)系統(tǒng)（例如S3或GCS），因此現(xiàn)在僅在本地使用。 云提供商還提供開(kāi)箱即用的托管Hadoop集群。 看起來(lái)Hadoop仍然活躍并且活躍，但是您應(yīng)該記住，在開(kāi)始構(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ù)中獲取所有見(jiàn)解，并執(zhí)行基于窗口的聚合。 但是，對(duì)于某些用例來(lái)說(shuō)，這是不可能的，而對(duì)于另一些用例，則沒(méi)有成本效益。 這就是為什么許多公司同時(shí)使用批處理和流處理的原因。 您應(yīng)該檢查您的業(yè)務(wù)需求，并確定哪種方法更適合您。 例如，如果只需要?jiǎng)?chuàng)建一些報(bào)告，則批處理就足夠了。 批處理更簡(jiǎn)單，更便宜。
最新的處理引擎，例如Apache Flink或Apache Beam，也稱(chēng)為第四代大數(shù)據(jù)引擎，為批處理和流數(shù)據(jù)提供統(tǒng)一的編程模型，其中批處理只是每24小時(shí)進(jìn)行一次流處理。 這簡(jiǎn)化了編程模型。
一種常見(jiàn)的模式是具有流數(shù)據(jù)以獲取時(shí)間緊迫的見(jiàn)解，例如信用卡欺詐，以及用于報(bào)告和分析的批處理。 較新的OLAP引擎允許以統(tǒng)一的方式進(jìn)行查詢。
根據(jù)您的用例，您可能需要在加載或讀取時(shí)轉(zhuǎn)換數(shù)據(jù)。 ELT意味著您可以執(zhí)行將數(shù)據(jù)轉(zhuǎn)換和聚合為查詢一部分的查詢，這可以使用SQL進(jìn)行，您可以在其中應(yīng)用函數(shù)，過(guò)濾數(shù)據(jù)，重命名列，創(chuàng)建視圖等。BigData OLAP引擎可以實(shí)現(xiàn) 它提供了一種以ELT方式實(shí)時(shí)查詢和批量查詢的方法。 另一種選擇是在負(fù)載（ETL）上轉(zhuǎn)換數(shù)據(jù)，但請(qǐng)注意，在處理過(guò)程中進(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ù)聚合。
最后，您的公司政策，組織，方法論，基礎(chǔ)架構(gòu)，團(tuán)隊(duì)結(jié)構(gòu)和技能在您的大數(shù)據(jù)決策中起著重要作用。 例如，您可能有一個(gè)數(shù)據(jù)問(wèn)題，需要您創(chuàng)建管道，但不必處理大量數(shù)據(jù)，在這種情況下，您可以編寫(xiě)一個(gè)流應(yīng)用程序，在該應(yīng)用程序中以 單一管道更容易； 但是如果您的公司已經(jīng)有一個(gè)數(shù)據(jù)湖，則您可能希望使用現(xiàn)有的平臺(tái)，而這并不是您從頭開(kāi)始構(gòu)建的。
另一個(gè)例子是ETL與ELT。 開(kāi)發(fā)人員傾向于構(gòu)建ETL系統(tǒng)，在該系統(tǒng)中，數(shù)據(jù)可以以簡(jiǎn)單的格式進(jìn)行查詢，因此非技術(shù)人員可以構(gòu)建儀表板并獲得見(jiàn)解。 但是，如果您有強(qiáng)大的數(shù)據(jù)分析人員團(tuán)隊(duì)和小型開(kāi)發(fā)人員團(tuán)隊(duì)，則您可能更喜歡ELT方法，使開(kāi)發(fā)人員只專(zhuān)注于提?。?數(shù)據(jù)分析師編寫(xiě)復(fù)雜的查詢來(lái)轉(zhuǎn)換和聚合數(shù)據(jù)。 這表明在大數(shù)據(jù)旅程中考慮團(tuán)隊(duì)結(jié)構(gòu)和技能的重要性。
建議將一支具有不同技能和背景的多元化團(tuán)隊(duì)一起工作，因?yàn)閿?shù)據(jù)是整個(gè)組織的跨職能部門(mén)。 數(shù)據(jù)湖非常擅長(zhǎng)在保持?jǐn)?shù)據(jù)治理和安全性的同時(shí)實(shí)現(xiàn)輕松協(xié)作。
在回顧了大數(shù)據(jù)世界的多個(gè)方面之后，我們來(lái)看看基本要素是什么。
您需要的第一件事是一個(gè)存儲(chǔ)所有數(shù)據(jù)的地方。 不幸的是，沒(méi)有一種產(chǎn)品可以滿足您的需求，這就是為什么您需要根據(jù)用例選擇合適的存儲(chǔ)。
對(duì)于實(shí)時(shí)數(shù)據(jù)攝取，通常使用附加日志來(lái)存儲(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之類(lèi)的數(shù)據(jù)庫(kù)可以保存和處理大量數(shù)據(jù)，其速度比數(shù)據(jù)湖快得多，但價(jià)格卻不便宜。 但是，數(shù)據(jù)湖文件系統(tǒng)與數(shù)據(jù)庫(kù)之間的價(jià)格差距逐年縮小。 在Hadoop / NoHadoop決策中，您需要考慮這一點(diǎn)。 現(xiàn)在，越來(lái)越多的公司選擇大數(shù)據(jù)數(shù)據(jù)庫(kù)而不是數(shù)據(jù)湖來(lái)滿足其數(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ū)。
最常見(jiàn)的格式是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嵌套類(lèi)型，因?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之類(lèi)的某些格式提供了某種程度的架構(gòu)演變，使您可以更改數(shù)據(jù)架構(gòu)并仍然查詢數(shù)據(jù)。 諸如Delta Lake格式的工具甚至提供了更好的工具來(lái)處理模式中的更改。
· 兼容性：JSON或CSV被廣泛采用并與幾乎所有工具兼容，而性能更高的選項(xiàng)具有較少的集成點(diǎn)。
如我們所見(jiàn)，CSV和JSON易于使用，易于閱讀和通用格式，但是缺乏其他格式的許多功能，因此它太慢而無(wú)法用于查詢數(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
我建議使用快照來(lái)流式傳輸數(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ù)算不是問(wèn)題，則可以使用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來(lái)運(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。
當(dāng)前的基礎(chǔ)架構(gòu)會(huì)在決定使用哪些工具時(shí)限制您的選擇。 要問(wèn)的第一個(gè)問(wèn)題是：云計(jì)算與本地部署。 云提供商提供了許多選擇和靈活性。 此外，它們?yōu)槟拇髷?shù)據(jù)需求提供了無(wú)服務(wù)器解決方案，更易于管理和監(jiān)控。 無(wú)疑，云是存放大數(shù)據(jù)的地方。 即使對(duì)于Hadoop生態(tài)系統(tǒng)，云提供商也提供托管群集和比本地存儲(chǔ)便宜的存儲(chǔ)。 查看我有關(guān)云解決方案的其他文章。
如果您在場(chǎng)所中運(yùn)行，則應(yīng)考慮以下事項(xiàng)：
· 我在哪里運(yùn)行工作負(fù)載？ 毫無(wú)疑問(wèn)，Kubernetes或Apache Mesos提供了一個(gè)統(tǒng)一的編排框架，以統(tǒng)一的方式運(yùn)行您的應(yīng)用程序。 無(wú)論使用哪種框架，部署，監(jiān)視和警報(bào)方面都是相同的。 相反，如果您使用裸機(jī)運(yùn)行，則需要考慮和管理部署的所有交叉方面。 在這種情況下，托管集群和工具將比庫(kù)和框架更適合。
· 我擁有哪種類(lèi)型的硬件？ 如果您具有帶有快速SSD和高端服務(wù)器的專(zhuān)用硬件，則可以部署Cassandra等大型數(shù)據(jù)庫(kù)并獲得出色的性能。 如果您僅擁有商品硬件，那么Hadoop生態(tài)系統(tǒng)將是一個(gè)更好的選擇。 理想情況下，您希望針對(duì)不同的工作負(fù)載使用多種類(lèi)型的服務(wù)器。 Cassandra的要求與HDFS有很大不同。
下一個(gè)要素對(duì)于數(shù)據(jù)管道的成功至關(guān)重要。 在大數(shù)據(jù)世界中，您需要有關(guān)流程和數(shù)據(jù)的不斷反饋。 您需要收集指標(biāo)，收集日志，監(jiān)視系統(tǒng)，創(chuàng)建警報(bào)，儀表板等等。
使用Prometheus和Grafana等開(kāi)源工具進(jìn)行監(jiān)視和警報(bào)。 使用日志聚合技術(shù)來(lái)收集日志并將其存儲(chǔ)在諸如ElasticSearch之類(lèi)的地方。
> Grafana Monitoring
利用云提供商的功能進(jìn)行監(jiān)視和警報(bào)（如果可能）。 根據(jù)您的平臺(tái)，您將使用不同的工具集。 對(duì)于無(wú)云服務(wù)器平臺(tái)，您將依靠您的云提供商工具和最佳實(shí)踐。 對(duì)于Kubernetes，您將使用開(kāi)源監(jiān)控器解決方案或企業(yè)集成。 我真的推薦這個(gè)網(wǎng)站，在這里您可以瀏覽和檢查不同的解決方案，并構(gòu)建自己的APM解決方案。
大數(shù)據(jù)世界中要考慮的另一件事是可審計(jì)性和問(wèn)責(zé)制。 由于法規(guī)不同，您可能需要跟蹤數(shù)據(jù)，捕獲和記錄數(shù)據(jù)流經(jīng)管道時(shí)的所有更改。 這稱(chēng)為數(shù)據(jù)來(lái)源或血統(tǒng)。 諸如Apache Atlas之類(lèi)的工具用于控制，記錄和管理您的數(shù)據(jù)。 其他工具如Apache NiFi也支持開(kāi)箱即用的數(shù)據(jù)沿襲。 有關(guān)實(shí)時(shí)跟蹤，請(qǐng)檢查'打開(kāi)遙測(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)化迭代過(guò)程，并使用域驅(qū)動(dòng)設(shè)計(jì)來(lái)設(shè)置團(tuán)隊(duì)邊界和職責(zé)。
對(duì)于大數(shù)據(jù)，您將分為兩大類(lèi)：
· 數(shù)據(jù)工程師進(jìn)行攝取，豐富和轉(zhuǎn)換。 這些工程師具有強(qiáng)大的開(kāi)發(fā)和運(yùn)營(yíng)背景，并負(fù)責(zé)創(chuàng)建數(shù)據(jù)管道。 開(kāi)發(fā)人員，管理員，DevOps專(zhuān)家等將屬于此類(lèi)別。
· 數(shù)據(jù)科學(xué)家：他們可以是BI專(zhuān)家，數(shù)據(jù)分析師等，負(fù)責(zé)生成報(bào)告，儀表板和收集見(jiàn)解。 這些人專(zhuān)注于OLAP并具有深刻的業(yè)務(wù)理解，收集了將用于制定關(guān)鍵業(yè)務(wù)決策的數(shù)據(jù)。 SQL和可視化方面很強(qiáng)，但是軟件開(kāi)發(fā)方面很弱。 機(jī)器學(xué)習(xí)專(zhuān)家也可能屬于此類(lèi)。
這是一個(gè)重要的考慮因素，您需要金錢(qián)來(lái)購(gòu)買(mǎi)所有其他成分，并且這是有限的資源。 如果您有無(wú)限的資金，則可以部署海量的數(shù)據(jù)庫(kù)并將其用于大數(shù)據(jù)需求而不會(huì)帶來(lái)很多麻煩，但這會(huì)花費(fèi)您很多錢(qián)。 因此，本文中提到的每種技術(shù)都需要具備使用，部署和維護(hù)技術(shù)的人員。 有些技術(shù)比其他技術(shù)更復(fù)雜，因此您需要考慮到這一點(diǎn)。
現(xiàn)在我們已經(jīng)掌握了食材，讓我們來(lái)烹飪我們的大數(shù)據(jù)食譜。 簡(jiǎn)而言之，該過(guò)程很簡(jiǎn)單； 您需要從不同來(lái)源獲取數(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ù)，此階段的目標(biāo)是獲取所需的所有數(shù)據(jù)并將其以原始格式存儲(chǔ)在單個(gè)存儲(chǔ)庫(kù)中。 它通常由將其數(shù)據(jù)推送到Kafka或數(shù)據(jù)存儲(chǔ)中的其他團(tuán)隊(duì)擁有。
對(duì)于沒(méi)有大量數(shù)據(jù)的簡(jiǎn)單管道，您可以構(gòu)建一個(gè)簡(jiǎn)單的微服務(wù)工作流，該工作流可以在單個(gè)管道中攝取，豐富和轉(zhuǎn)換數(shù)據(jù)（注入 轉(zhuǎn)換），您可以使用Apache Airflow之類(lèi)的工具來(lái)編排依賴性。 但是，對(duì)于大數(shù)據(jù)，建議您將攝取與處理分開(kāi)，可以并行運(yùn)行的海量處理引擎對(duì)于處理阻塞調(diào)用，重試，背壓等效果不佳。因此，建議在保存所有數(shù)據(jù)之前 您開(kāi)始處理它。 作為調(diào)用的一部分，您應(yīng)該通過(guò)調(diào)用其他系統(tǒng)來(lái)確保您的數(shù)據(jù)豐富，以確保所有數(shù)據(jù)（包括參考數(shù)據(jù)）在處理之前都已落入湖泊中。
有兩種攝取方式：
· 拉?。簭臄?shù)據(jù)庫(kù)，文件系統(tǒng)，隊(duì)列或API等地方提取數(shù)據(jù)
· 推送：應(yīng)用程序也可以將數(shù)據(jù)推送到您的湖泊中，但始終建議在兩者之間使用一個(gè)消息傳遞平臺(tái)，例如Kafka。 常見(jiàn)的模式是變更數(shù)據(jù)捕獲（CDC），它使我們能夠?qū)?shù)據(jù)從數(shù)據(jù)庫(kù)和其他系統(tǒng)實(shí)時(shí)移入湖泊。
正如我們已經(jīng)提到的，使用Kafka或Pulsar作為數(shù)據(jù)攝取的中介是極為常見(jiàn)的，以實(shí)現(xiàn)持久性，背壓，并行化和攝取的監(jiān)控。然后，使用Kafka Connect將數(shù)據(jù)保存到您的數(shù)據(jù)湖中。這個(gè)想法是您的OLTP系統(tǒng)將事件發(fā)布到Kafka，然后將其吸收到您的湖泊中。避免直接通過(guò)API批量提取數(shù)據(jù)；您可能會(huì)調(diào)用HTTP端點(diǎn)進(jìn)行數(shù)據(jù)充實(shí)，但請(qǐng)記住，從API提取數(shù)據(jù)在大數(shù)據(jù)世界中并不是一個(gè)好主意，因?yàn)樗俣嚷菀壮鲥e(cuò)（網(wǎng)絡(luò)問(wèn)題，延遲等），并且可能導(dǎo)致源系統(tǒng)崩潰。盡管API非常適合在OLTP世界中設(shè)置域邊界，但這些邊界是由大數(shù)據(jù)世界中Kafka中的數(shù)據(jù)存儲(chǔ)（批次）或主題（實(shí)時(shí)）來(lái)設(shè)置的。當(dāng)然，它總是取決于數(shù)據(jù)的大小，但是如果可能，如果沒(méi)有其他選擇，請(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)緊密耦合。 如果無(wú)法做到這一點(diǎn)，并且您仍然需要掌握攝取過(guò)程，那么我們可以考慮兩種主要的攝取類(lèi)別：
· Un Managed Solutions：這些是您開(kāi)發(fā)的應(yīng)用程序，用于將數(shù)據(jù)提取到數(shù)據(jù)湖中；您可以在任何地方運(yùn)行它們。從沒(méi)有現(xiàn)成解決方案的API或其他I / O阻止系統(tǒng)中提取數(shù)據(jù)時(shí)，或者在不使用Hadoop生態(tài)系統(tǒng)時(shí)，這非常常見(jiàn)。這個(gè)想法是使用流媒體庫(kù)從不同的主題，端點(diǎn)，隊(duì)列或文件系統(tǒng)中攝取數(shù)據(jù)。因?yàn)槟陂_(kāi)發(fā)應(yīng)用程序，所以您具有完全的靈活性。大多數(shù)庫(kù)提供重試，背壓，監(jiān)視，批處理等等。這是您自己的代碼方法，因此您將需要其他工具來(lái)進(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，則可以將它們用作獲取編排工具來(lái)獲取數(shù)據(jù)并豐富數(shù)據(jù)。每個(gè)階段都將數(shù)據(jù)移動(dòng)到一個(gè)新主題，通過(guò)使用主題進(jìn)行依賴性管理在基礎(chǔ)架構(gòu)中創(chuàng)建DAG。如果您沒(méi)有Kafka，并且想要一個(gè)更直觀的工作流程，則可以使用Apache Airflow來(lái)協(xié)調(diào)依賴關(guān)系并運(yùn)行DAG。這個(gè)想法是要提供一系列服務(wù)來(lái)攝取和豐富日期，然后將其存儲(chǔ)在某個(gè)地方。完成每個(gè)步驟后，將執(zhí)行下一個(gè)步驟并由Airflow進(jìn)行協(xié)調(diào)。最后，數(shù)據(jù)存儲(chǔ)在某種存儲(chǔ)中。
· 托管解決方案：在這種情況下，您可以使用部署在群集中并用于提取的工具。 這在Hadoop生態(tài)系統(tǒng)中很常見(jiàn)，在該生態(tài)系統(tǒng)中，您擁有諸如Sqoop之類(lèi)的工具來(lái)從OLTP數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)，而Flume則具有從流媒體中獲取數(shù)據(jù)的能力。 這些工具提供監(jiān)視，重試，增量負(fù)載，壓縮等功能。
Apache NiFi
NiFi是其中很難分類(lèi)的工具之一。 它本身就是野獸。 它可以用于攝取，編排甚至簡(jiǎn)單的轉(zhuǎn)換。 因此，從理論上講，它可以解決簡(jiǎn)單的大數(shù)據(jù)問(wèn)題。 這是一個(gè)托管解決方案。 它具有可視界面，您可以在其中拖放組件并使用它們來(lái)攝取和豐富數(shù)據(jù)。 它具有300多個(gè)內(nèi)置處理器，可以執(zhí)行許多任務(wù)，您可以通過(guò)實(shí)現(xiàn)自己的處理器來(lái)擴(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í)行路由，過(guò)濾和基本ETL的數(shù)據(jù)流。 對(duì)于某些用例，您可能只需要NiFi。
但是，由于節(jié)點(diǎn)間的通信，群集中的10個(gè)以上節(jié)點(diǎn)效率低下，因此NiFi無(wú)法擴(kuò)展到某個(gè)特定點(diǎn)。 它傾向于在垂直方向更好地?cái)U(kuò)展，但是您可以達(dá)到其極限，尤其是對(duì)于復(fù)雜的ETL。 但是，您可以將其與Spark等工具集成以處理數(shù)據(jù)。 NiFi是吸收和豐富數(shù)據(jù)的絕佳工具。
諸如Druid或Pinot之類(lèi)的現(xiàn)代OLAP引擎還提供了自動(dòng)提取批處理和流數(shù)據(jù)的功能，我們將在另一部分中討論它們。
您也可以在提取過(guò)程中進(jìn)行一些初始驗(yàn)證和數(shù)據(jù)清理，只要它們不是昂貴的計(jì)算或不跨越有限的上下文，請(qǐng)記住，空字段可能與您無(wú)關(guān)，但對(duì)另一個(gè)團(tuán)隊(duì)很重要。
最后一步是確定數(shù)據(jù)的放置位置，我們已經(jīng)討論過(guò)了。 您可以使用數(shù)據(jù)庫(kù)或深度存儲(chǔ)系統(tǒng)。 對(duì)于數(shù)據(jù)湖，通常將其存儲(chǔ)在HDFS中，其格式取決于下一步；請(qǐng)參見(jiàn)下一步。 如果您打算執(zhí)行行級(jí)操作，Avro是一個(gè)不錯(cuò)的選擇。 Avro還使用外部注冊(cè)表支持架構(gòu)演變，這將使您可以相對(duì)輕松地更改所攝取數(shù)據(jù)的架構(gòu)。
存儲(chǔ)數(shù)據(jù)后，下一步是保存其元數(shù)據(jù)（有關(guān)數(shù)據(jù)本身的信息）。 最常見(jiàn)的元數(shù)據(jù)是架構(gòu)。 通過(guò)使用外部元數(shù)據(jù)存儲(chǔ)庫(kù)，數(shù)據(jù)湖或數(shù)據(jù)管道中的不同工具可以查詢它以推斷數(shù)據(jù)模式。
如果將Avro用作原始數(shù)據(jù)，則外部注冊(cè)表是一個(gè)不錯(cuò)的選擇。 這樣，您就可以輕松地將處理過(guò)程中的提取分離。
數(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屬性的查詢。 它具有靈活性，并通過(guò)利用HBase作為其后備存儲(chǔ)來(lái)提供NoSQL世界中的讀取模式架構(gòu)功能。 Apache Druid或Pinot還提供元數(shù)據(jù)存儲(chǔ)。
此階段的目標(biāo)是使用單個(gè)架構(gòu)清理，規(guī)范化，處理和保存數(shù)據(jù)。 最終結(jié)果是具有良好定義的架構(gòu)的可信數(shù)據(jù)集。
通常，您需要執(zhí)行某種處理，例如：
· 驗(yàn)證：通過(guò)將數(shù)據(jù)存儲(chǔ)在單獨(dú)的存儲(chǔ)中來(lái)驗(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)過(guò)驗(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ì)誰(shuí)將查詢數(shù)據(jù)一無(wú)所知，該階段為使用者優(yōu)化了數(shù)據(jù)。如果客戶端是高度交互的，則您可能希望在此階段引入快速存儲(chǔ)層，例如用于快速查詢的關(guān)系數(shù)據(jù)庫(kù)?；蛘撸梢允褂肙LAP引擎，我們將在后面討論。
對(duì)于流來(lái)說(shuō)，邏輯是相同的，但是它將以流的方式在定義的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ù)囊?，但主要關(guān)注流傳輸。 它可以用作像Kafka這樣的微服務(wù)的主干。 它可以作為Hadoop集群的一部分在YARN上運(yùn)行，但自成立以來(lái)，它還針對(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)的開(kāi)源分布式實(shí)時(shí)計(jì)算系統(tǒng)，它專(zhuān)注于流傳輸，是Hadoop生態(tài)系統(tǒng)的托管解決方案部分。 它具有可擴(kuò)展性，容錯(cuò)性，可確保您的數(shù)據(jù)將得到處理，并且易于設(shè)置和操作。
· Apache Samza：另一個(gè)出色的有狀態(tài)流處理引擎。 Samza允許您構(gòu)建有狀態(tài)的應(yīng)用程序，以從多個(gè)來(lái)源（包括Apache Kafka）實(shí)時(shí)處理數(shù)據(jù)。 在YARN之上運(yùn)行的Hadoop生態(tài)系統(tǒng)的托管解決方案部分。
· Apache Beam：Apache Beam本身不是引擎，而是將所有其他引擎結(jié)合在一起的統(tǒng)一編程模型的規(guī)范。 它提供了可以與不同語(yǔ)言一起使用的編程模型，因此開(kāi)發(fā)人員在處理大數(shù)據(jù)管道時(shí)不必學(xué)習(xí)新的語(yǔ)言。 然后，它為可在云或本地運(yùn)行的處理步驟插入了不同的后端。 Beam支持前面提到的所有引擎，您可以在它們之間輕松切換并在任何平臺(tái)上運(yùn)行它們：云，YARN，Mesos，Kubernetes。 如果您要開(kāi)始一個(gè)新項(xiàng)目，我真的建議您從Beam開(kāi)始，以確保您的數(shù)據(jù)管道可以用于將來(lái)。
在此處理階段結(jié)束時(shí)，您已經(jīng)烹飪了數(shù)據(jù)，現(xiàn)在可以使用了！但是，為了烹飪，廚師必須與團(tuán)隊(duì)合作…
數(shù)據(jù)管道編排是一個(gè)交叉過(guò)程，它管理所有其他任務(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之類(lèi)的較新框架添加了更多功能，并允許您跟蹤向管道添加語(yǔ)義的數(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編寫(xiě)的，因此您可以在本地運(yùn)行它們，對(duì)其進(jìn)行單元測(cè)試并將其與開(kāi)發(fā)工作流程集成。 它還支持SLA和警報(bào)。 Luigi是具有類(lèi)似功能的Airflow的替代產(chǎn)品，但Airflow具有更多功能，并且比Luigi具有更好的擴(kuò)展性。
· Dagster‘s 機(jī)器學(xué)習(xí)，分析和ETL的新型協(xié)調(diào)器。 主要區(qū)別在于您可以跟蹤數(shù)據(jù)的輸入和輸出，類(lèi)似于Apache NiFi創(chuàng)建數(shù)據(jù)流解決方案。 您還可以在任務(wù)中實(shí)現(xiàn)其他值。 它還可以并行運(yùn)行多個(gè)作業(yè)，易于添加參數(shù)，易于測(cè)試，提供簡(jiǎn)單的版本控制等等。 它仍然有些不成熟，由于需要跟蹤數(shù)據(jù)，因此可能難以擴(kuò)展，這是NiFi面臨的一個(gè)問(wèn)題。
· Prefect與Dagster相似，提供本地測(cè)試，版本控制，參數(shù)管理等等。 Prefect之所以與眾不同，是為了克服Airflow執(zhí)行引擎的局限性，例如改進(jìn)的計(jì)劃程序，參數(shù)化的工作流，動(dòng)態(tài)工作流，版本控制和改進(jìn)的測(cè)試。 它具有一個(gè)核心的開(kāi)源工作流管理系統(tǒng)以及一個(gè)完全不需要設(shè)置的云產(chǎn)品。
· Apache NiFi：NiFi還可以安排作業(yè)，監(jiān)視，路由數(shù)據(jù)，警報(bào)等等。 它專(zhuān)注于數(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ì)于非開(kāi)發(fā)人員請(qǐng)使用NiFi，對(duì)于開(kāi)發(fā)人員請(qǐng)使用Dagster或Prefect。
大數(shù)據(jù)中經(jīng)常忽略的一個(gè)重要方面是數(shù)據(jù)質(zhì)量和保證。 由于數(shù)據(jù)質(zhì)量問(wèn)題，公司每年都會(huì)損失大量資金。 問(wèn)題在于，這仍然是數(shù)據(jù)科學(xué)領(lǐng)域中一個(gè)不成熟的領(lǐng)域，開(kāi)發(fā)人員已經(jīng)在這一領(lǐng)域工作了數(shù)十年，他們擁有出色的測(cè)試框架和方法，例如BDD或TDD，但是您如何測(cè)試管道？
該領(lǐng)域存在兩個(gè)常見(jiàn)問(wèn)題：
· 誤解的要求：轉(zhuǎn)換和編排邏輯經(jīng)常會(huì)變得非常復(fù)雜。 業(yè)務(wù)分析師可以使用他們的領(lǐng)域語(yǔ)言來(lái)編寫(xiě)需求，開(kāi)發(fā)人員通常會(huì)犯錯(cuò)，并計(jì)劃，開(kāi)發(fā)，測(cè)試和部署技術(shù)上正確但有錯(cuò)誤需求的解決方案。 這些類(lèi)型的錯(cuò)誤非常昂貴。
· 數(shù)據(jù)驗(yàn)證：管道測(cè)試與代碼完全不同。 開(kāi)發(fā)軟件時(shí)，您要測(cè)試功能，這是確定性的黑盒測(cè)試。 對(duì)于給定的輸入，您始終會(huì)獲得相同的輸出。 對(duì)于數(shù)據(jù)資產(chǎn)，測(cè)試更加復(fù)雜：您需要聲明數(shù)據(jù)類(lèi)型，值，約束等等。 此外，您需要應(yīng)用聚合來(lái)驗(yàn)證數(shù)據(jù)集，以確保行數(shù)或列數(shù)正確。 例如，很難檢測(cè)是否有一天您的數(shù)據(jù)量下降了10％，或者某些值是否正確填充。
公司在數(shù)據(jù)質(zhì)量和測(cè)試方面仍處于起步階段，這造成了巨大的技術(shù)負(fù)擔(dān)。 我真的建議查看這篇文章以獲取更多信息。
為了緩解這些問(wèn)題，請(qǐng)嘗試遵循DDD原則，并確保設(shè)置了邊界并使用了通用語(yǔ)言。 使用支持?jǐn)?shù)據(jù)譜系的框架，例如NiFi或Dagster。
一些關(guān)注數(shù)據(jù)質(zhì)量的工具是：
· Apache Griffin：此工具是Hadoop生態(tài)系統(tǒng)的一部分，它提供了一個(gè)統(tǒng)一的過(guò)程，可以從不同角度衡量數(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的問(wèn)題在于DSL可能變得難以管理（JSON），并且非技術(shù)人員難以解釋?zhuān)@意味著它無(wú)法解決被誤解的需求問(wèn)題。
> Apache Griffin Processes
· Great Expectations ：這是一個(gè)用Python編寫(xiě)的更新工具，專(zhuān)注于數(shù)據(jù)質(zhì)量，管道測(cè)試和質(zhì)量保證。它可以輕松地與Airflow或其他編排工具集成，并提供自動(dòng)數(shù)據(jù)驗(yàn)證。使該工具與眾不同的是事實(shí)，它是人類(lèi)可讀的，并且可由數(shù)據(jù)分析師，BA和開(kāi)發(fā)人員使用。它提供了直觀的UI，還提供了完全自動(dòng)化的功能，因此您可以將驗(yàn)證作為生產(chǎn)管道的一部分運(yùn)行，并在漂亮的UI中查看結(jié)果。非技術(shù)人員可以使用筆記本編寫(xiě)斷言，這些筆記本提供開(kāi)發(fā)人員可以輕松理解，轉(zhuǎn)換為代碼并用于測(cè)試的文檔和正式要求。 BA或測(cè)試人員編寫(xiě)數(shù)據(jù)斷言（期望），然后將其轉(zhuǎn)換為UI中的人類(lèi)可讀測(cè)試，以便每個(gè)人都可以看到并驗(yàn)證它們。它還可以進(jìn)行數(shù)據(jù)分析以為您生成一些斷言。它可以直接連接到本地或云中的數(shù)據(jù)庫(kù)或文件系統(tǒng)。它非常易于使用和管理?？梢詫⑵谕堤峤坏皆创a存儲(chǔ)庫(kù)，然后將其集成到管道中。偉大的期望為涉及數(shù)據(jù)質(zhì)量的所有各方創(chuàng)建了一種通用的語(yǔ)言和框架，從而非常容易地以最小的努力來(lái)自動(dòng)化和測(cè)試管道。
> Great expectations UI
現(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)行過(guò)優(yōu)化。 有些使用標(biāo)準(zhǔn)格式，僅專(zhuā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)表層的常見(jiàn)用例。
Spark SQL提供了一種將SQL查詢與Spark程序無(wú)縫混合的方法，因此您可以將DataFrame API與SQL混合。 它具有Hive集成和通過(guò)JDBC或ODBC的標(biāo)準(zhǔn)連接； 因此您可以通過(guò)Spark將Tableau，Looker或任何BI工具連接到數(shù)據(jù)。
Apache Flink還提供SQL API。 Flink的SQL支持基于實(shí)現(xiàn)SQL標(biāo)準(zhǔn)的Apache Calcite。 它還通過(guò)HiveCatalog與Hive集成。 例如，用戶可以使用HiveCatalog將其Kafka或ElasticSearch表存儲(chǔ)在Hive Metastore中，并稍后在SQL查詢中重新使用它們。
這類(lèi)工具專(zhuān)注于以統(tǒng)一的方式查詢不同的數(shù)據(jù)源和格式。 這個(gè)想法是使用SQL查詢來(lái)查詢您的數(shù)據(jù)湖，就像它是一個(gè)關(guān)系數(shù)據(jù)庫(kù)一樣，盡管它有一些限制。 其中一些工具還可以查詢NoSQL數(shù)據(jù)庫(kù)等等。 這些工具為外部工具（如Tableau或Looker）提供JDBC接口，以安全方式連接到您的數(shù)據(jù)湖。 查詢引擎是最慢的選擇，但提供最大的靈活性。
· Apache Pig：它是與Hive一起使用的最早的查詢語(yǔ)言之一。 它有自己的語(yǔ)言，不同于SQL。 Pig程序的顯著特性是它們的結(jié)構(gòu)適合于實(shí)質(zhì)性的并行化，從而使它們能夠處理非常大的數(shù)據(jù)集。 現(xiàn)在，它越來(lái)越傾向于使用基于SQL的新引擎。
· Presto：由Facebook發(fā)布為開(kāi)源，它是一個(gè)開(kāi)源的分布式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ǔ)提供無(wú)模式的SQL查詢引擎。 它獨(dú)立于Hadoop，但與Hive等生態(tài)系統(tǒng)工具集成了許多功能。 單個(gè)查詢可以聯(lián)接來(lái)自多個(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）來(lái)利用Drill的JDBC和ODBC驅(qū)動(dòng)程序與非關(guān)系數(shù)據(jù)存儲(chǔ)進(jìn)行交互。 此外，開(kāi)發(fā)人員可以在其自定義應(yīng)用程序中利用Drill的簡(jiǎn)單REST API來(lái)創(chuàng)建精美的可視化效果。
> Drill model
盡管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ù)，并支持通過(guò)DDL命令創(chuàng)建表和版本化的增量更改。 它非?？?，比使用Drill或其他查詢引擎要快。
您可以使用Hadoop生態(tài)系統(tǒng)以外的任何大規(guī)模數(shù)據(jù)庫(kù)，例如Cassandra，YugaByteDB，SyllaDB for OTLP。
最后，在任何類(lèi)型的快速數(shù)據(jù)庫(kù)（例如MongoDB或MySQL）中擁有數(shù)據(jù)的子集（通常是最新數(shù)據(jù)）是很常見(jiàn)的。 上面提到的查詢引擎可以在單個(gè)查詢中在慢速和快速數(shù)據(jù)存儲(chǔ)之間加入數(shù)據(jù)。
這些工具提供了一種存儲(chǔ)和搜索非結(jié)構(gòu)化文本數(shù)據(jù)的方法，并且由于它們需要特殊的結(jié)構(gòu)來(lái)存儲(chǔ)數(shù)據(jù)，因此它們位于Hadoop生態(tài)系統(tǒng)之外。 這個(gè)想法是使用倒排索引來(lái)執(zhí)行快速查找。 除了文本搜索外，該技術(shù)還可以用于各種用例，例如存儲(chǔ)日志，事件等。有兩個(gè)主要選項(xiàng)：
· Solr：這是一個(gè)基于Apache Lucene的流行，快速，開(kāi)放源代碼的企業(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)非常龐大，值得探索。
在此類(lèi)別中，我們有數(shù)據(jù)庫(kù)，該數(shù)據(jù)庫(kù)還可以提供用于模式和查詢功能的元數(shù)據(jù)存儲(chǔ)。 與查詢引擎相比，這些工具還提供存儲(chǔ)，并且在數(shù)據(jù)倉(cāng)庫(kù)的情況下可以強(qiáng)制執(zhí)行某些架構(gòu)（星型架構(gòu)）。 這些工具使用SQL語(yǔ)法，Spark和其他框架可以與它們進(jìn)行交互。
· Apache Hive：我們已經(jīng)討論過(guò)Hive作為Spark和其他工具的中央模式存儲(chǔ)庫(kù)，以便它們可以使用SQL，但是Hive也可以存儲(chǔ)數(shù)據(jù)，因此您可以將其用作數(shù)據(jù)倉(cāng)庫(kù)。 它可以訪問(wèn)HDFS或HBase。 查詢Hive時(shí)，它會(huì)利用Apache Tez，Apache Spark或MapReduce，而Tez或Spark的速度要快得多。 它還具有一種稱(chēng)為HPL-SQL的過(guò)程語(yǔ)言。
· Apache Impala：這是Hadoop的本地分析數(shù)據(jù)庫(kù)，您可以使用它來(lái)存儲(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ù)訪問(wèn)。 它使用HBase和HDFS進(jìn)行數(shù)據(jù)存儲(chǔ)。
· Apache Tajo：這是Hadoop的另一個(gè)數(shù)據(jù)倉(cāng)庫(kù)。 Tajo專(zhuān)為針對(duì)HDFS和其他數(shù)據(jù)源上存儲(chǔ)的大數(shù)據(jù)集的低延遲和可擴(kuò)展的即席查詢，在線聚合和ETL而設(shè)計(jì)。 它與Hive Metastore集成在一起以訪問(wèn)通用模式。 它具有許多查詢優(yōu)化功能，具有可伸縮性，容錯(cuò)能力，并提供JDBC接口。
· Apache Kylin：Apache Kylin是更新的分布式分析數(shù)據(jù)倉(cāng)庫(kù)。 Kylin的運(yùn)行速度非?？?，因此對(duì)于儀表盤(pán)或交互式報(bào)表等性能很重要的用例，它可以用于補(bǔ)充Hive等其他一些數(shù)據(jù)庫(kù)，它可能是最好的OLAP數(shù)據(jù)倉(cāng)庫(kù)，但使用起來(lái)比較困難。 問(wèn)題在于，由于維數(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ù)集。
在此類(lèi)別中，我包括較新的引擎，這些引擎是對(duì)以前的OLAP數(shù)據(jù)庫(kù)的改進(jìn)，這些數(shù)據(jù)庫(kù)提供了創(chuàng)建多合一分析平臺(tái)的更多功能。 實(shí)際上，它們是前兩種類(lèi)別的混合，為您的OLAP數(shù)據(jù)庫(kù)添加了索引。 它們位于Hadoop平臺(tái)之外，但緊密集成。 在這種情況下，您通常會(huì)跳過(guò)處理階段并直接使用這些工具進(jìn)行提取。
他們?cè)噲D解決以統(tǒng)一的方式查詢實(shí)時(shí)和歷史數(shù)據(jù)的問(wèn)題，以便您可以在查詢到實(shí)時(shí)數(shù)據(jù)以及低延遲的歷史數(shù)據(jù)后立即立即查詢實(shí)時(shí)數(shù)據(jù)，從而構(gòu)建交互式應(yīng)用程序和儀表板。 這些工具在許多情況下允許以ELT方式進(jìn)行幾乎沒(méi)有任何轉(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引擎。它專(zhuān)注于時(shí)間序列數(shù)據(jù)，但可用于任何類(lèi)型的數(shù)據(jù)。它使用自己的列式格式，可以大量壓縮數(shù)據(jù)，并且具有很多內(nèi)置的優(yōu)化功能，例如倒排索引，文本編碼，自動(dòng)數(shù)據(jù)匯總等等。使用具有極低延遲的Tranquility或Kafka實(shí)時(shí)攝取數(shù)據(jù)，數(shù)據(jù)以針對(duì)寫(xiě)入而優(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è)維，您可以使用它們過(guò)濾和執(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ò)展。主要問(wèn)題是它具有許多組件，并且難以管理和部署。
> Druid architecture
· Apache Pinot：這是LinkedIn開(kāi)源的Druid的更新替代品。 與Druid相比，由于Startree索引提供了部分預(yù)先計(jì)算，因此它提供了更低的延遲，因此它可用于面向用戶的應(yīng)用程序（用于獲取LinkedIn提要）。 它使用排序索引而不是倒排索引，索引速度更快。 它具有可擴(kuò)展的插件架構(gòu)，并且具有許多集成，但不支持Hive。 它還統(tǒng)一了批處理和實(shí)時(shí)功能，提供快速接收，智能索引并將數(shù)據(jù)分段存儲(chǔ)。 與Druid相比，它更容易部署且速度更快，但目前還不成熟。
> Apache Pinot
· ClickHouse：用C 編寫(xiě)，此引擎為OLAP查詢（尤其是聚合）提供了令人難以置信的性能。 它看起來(lái)像一個(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í)分析。 麒麟更專(zhuān)注于OLAP案件。 Druid與Kafka的實(shí)時(shí)流媒體集成良好。 Kylin分批從Hive或Kafka獲取數(shù)據(jù)； 盡管計(jì)劃在不久的將來(lái)進(jìn)行實(shí)時(shí)攝取。
最后，Greenplum是另一個(gè)更專(zhuān)注于AI的OLAP引擎。
> Presto/Drill provide more flexibility, Kylin great latency, Druid and Pinot, the best of both worl
最后，對(duì)于可視化，您可以使用多種商業(yè)工具，例如Qlik，Looker或Tableau。 對(duì)于開(kāi)源，請(qǐng)檢查SuperSet，這是一個(gè)了不起的工具，它支持我們提到的所有工具，具有出色的編輯器，而且速度非?？?。 Metabase或Falcon是其他不錯(cuò)的選擇。
我們討論了很多數(shù)據(jù)：不同的形狀，格式，如何處理，存儲(chǔ)以及更多內(nèi)容。 切記：了解您的數(shù)據(jù)和業(yè)務(wù)模型。 使用迭代過(guò)程，慢慢開(kāi)始構(gòu)建您的大數(shù)據(jù)平臺(tái)； 不是通過(guò)引入新框架而是通過(guò)提出正確的問(wèn)題并尋找可以為您提供正確答案的最佳工具。
查看數(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)買(mǎi)與構(gòu)建）。 從無(wú)服務(wù)器分析流水線開(kāi)始，然后隨著成本的增加而逐漸過(guò)渡到開(kāi)源解決方案，這是很常見(jiàn)的。
由于對(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之類(lèi)的工具是令人贊嘆的技術(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。
如有任何疑問(wèn)或需要任何建議，請(qǐng)隨時(shí)與我們聯(lián)系。
希望您喜歡這篇文章。 隨時(shí)發(fā)表評(píng)論或分享這篇文章。 跟我來(lái)以后的帖子。
(本文翻譯自Javier Ramos的文章《Big Data Pipeline Recipe》，參考：https://itnext.io/big-data-pipeline-recipe-c416c1782908)
聯(lián)系客服
