介紹

如果您從大數(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ù)注意事項(xiàng)

（如果您有使用大數(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í)間可用于查詢(xún)的數(shù)據(jù)？您期望什么類(lèi)型的查詢(xún)？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ù)之旅。讓我們回顧其中的一些……

OLTP與OLAP

幾年前，企業(yè)曾經(jīng)使用關(guān)系數(shù)據(jù)庫(kù)支持在線(xiàn)應(yīng)用程序，該關(guān)系數(shù)據(jù)庫(kù)用于存儲(chǔ)用戶(hù)和其他結(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ù)變得昂貴且難以管理。此外，公司開(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ù)，然后直接查詢(xún)存儲(chǔ)的文件而無(wú)需 使用數(shù)據(jù)庫(kù)，但依賴(lài)于文件格式和外部架構(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ǎn)足其分析需求，但是如果您的公司沒(méi)有太多的信息渠道和/或您在云中運(yùn)行， 一個(gè)單一的大型數(shù)據(jù)庫(kù)足以簡(jiǎn)化您的架構(gòu)并大大降低成本。

Hadoop或非Hadoop

自2006年發(fā)布以來(lái)，Hadoop一直是大數(shù)據(jù)世界中的主要參考?；贛apReduce編程模型，它允許使用簡(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)行接收和查詢(xún)的新OLAP引擎已取代了Hadoop中一些最常見(jiàn)的查詢(xún)引擎。但是最大的影響是云提供商發(fā)布的無(wú)服務(wù)器分析解決方案數(shù)量增加，您可以在其中執(zhí)行任何大數(shù)據(jù)任務(wù)而無(wú)需管理任何基礎(chǔ)架構(gòu)。

考慮到Hadoop生態(tài)系統(tǒng)的規(guī)模和龐大的用戶(hù)群，這似乎還沒(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)行查詢(xún)。

ETL與ELT

根據(jù)您的用例，您可能需要在加載或讀取時(shí)轉(zhuǎn)換數(shù)據(jù)。ELT意味著您可以執(zhí)行將數(shù)據(jù)轉(zhuǎn)換和聚合為查詢(xún)一部分的查詢(xún)，這可以使用SQL進(jìn)行，您可以在其中應(yīng)用函數(shù)，過(guò)濾數(shù)據(jù)，重命名列，創(chuàng)建視圖等。BigData OLAP引擎可以實(shí)現(xiàn) 它提供了一種以ELT方式實(shí)時(shí)查詢(xún)和批量查詢(xún)的方法。另一種選擇是在負(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)換和聚合速度較慢，但提供了更大的靈活性。如果查詢(xú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ù)問(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)行查詢(xú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ù)雜的查詢(xún)來(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)看看基本要素是什么。

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

您需要的第一件事是一個(gè)存儲(chǔ)所有數(shù)據(jù)的地方。不幸的是，沒(méi)有一種產(chǎn)品可以滿(mǎ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)?，F(xiàn)在，越來(lái)越多的公司選擇大數(shù)據(jù)數(shù)據(jù)庫(kù)而不是數(shù)據(jù)湖來(lái)滿(mǎn)足其數(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ù)，可用于提?。ㄅR時(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ì)查詢(xún)建模。

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)樗鼈冃屎艿汀＿M(jìn)程嵌套JSON也非常占用CPU。通常，建議在攝取數(shù)據(jù)時(shí)將其放平。

· 性能：Avro和Parquet等某些格式的性能優(yōu)于其他JSON。即使在Avro和Parquet的不同用例之間，一個(gè)也會(huì)比其他更好。例如，由于Parquet是基于列的格式，因此使用SQL查詢(xún)數(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)并仍然查詢(xún)數(shù)據(jù)。諸如Delta Lake格式的工具甚至提供了更好的工具來(lái)處理模式中的更改。

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

如我們所見(jiàn)，CSV和JSON易于使用，易于閱讀和通用格式，但是缺乏其他格式的許多功能，因此它太慢而無(wú)法用于查詢(xún)數(shù)據(jù)湖。ORC和Parquet在Hadoop生態(tài)系統(tǒng)中被廣泛用于查詢(xún)數(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ǔ)，以供高度交互的面向用戶(hù)的應(yīng)用程序使用，其中延遲很重要（OLTP），您需要提前知道查詢(xún)。在這種情況下，請(qǐng)根據(jù)數(shù)據(jù)量使用Cassandra或其他數(shù)據(jù)庫(kù)。

· 您需要將處理后的數(shù)據(jù)提供給您的用戶(hù)群，一致性很重要，并且由于UI提供了高級(jí)查詢(xún)，因此您不預(yù)先知道查詢(xún)。在這種情況下，您需要一個(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í)查詢(xún)并創(chuàng)建報(bào)告。在這種情況下，您可以將數(shù)據(jù)以Parquet或ORC格式存儲(chǔ)在深度存儲(chǔ)文件系統(tǒng)中。

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

· 您需要執(zhí)行非常復(fù)雜的查詢(xún)，而這些查詢(xún)只需幾毫秒即可響應(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í)限制您的選擇。要問(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有很大不同。

監(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等開(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)。

預(yù)算

這是一個(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ù)攝取

第一步是獲取數(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)編排依賴(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)樗俣嚷?，容易出錯(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）。

為了最大程度地減少依賴(lài)性，如果源系統(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ù)總線(xiàn)使單個(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)行依賴(lài)性管理在基礎(chǔ)架構(gòu)中創(chuàng)建DAG。如果您沒(méi)有Kafka，并且想要一個(gè)更直觀(guān)的工作流程，則可以使用Apache Airflow來(lái)協(xié)調(diào)依賴(lài)關(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)。

下集見(jiàn)

猜你喜歡：

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

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

02_音樂(lè)數(shù)據(jù)中心項(xiàng)目_機(jī)器詳情信息統(tǒng)計(jì)_數(shù)據(jù)分層模型設(shè)計(jì)