介紹

如果您從大數據開始，通常會被眾多工具，框架和選項所困擾。 在本文中，我將嘗試總結其成分和基本配方，以幫助您開始大數據之旅。 我的目標是對不同的工具進行分類，并試圖解釋每個工具的目的以及它如何適應生態系統。

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

> Big Data Ecosystem

 

數據注意事項

（如果您有使用大數據的經驗，請跳至下一部分……）

大數據非常復雜，除非絕對必要，否則請不要參與其中。 要獲得見解，請從小處著手，也許使用Elastic Search和Prometheus / Grafana來開始收集信息并創建儀表板以獲取有關您的業務的信息。 隨著數據的擴展，這些工具可能不夠好或維護成本太高。 這是您應該開始考慮數據湖或數據倉庫的時候。 并改變主意，開始大膽思考。

檢查數據量，有多少以及需要存儲多長時間。 檢查溫度！ 數據，它會隨著時間的流逝而失去價值，那么您需要存儲多長時間？ 您需要多少個存儲層（熱/熱/冷）？ 您可以存檔或刪除數據嗎？

您需要問自己的其他問題是：您存儲的數據類型是什么？ 您使用哪種格式？ 您有任何法律義務嗎？ 您需要多快提取數據？ 您需要多長時間可用于查詢的數據？ 您期望什么類型的查詢？ OLTP還是OLAP？ 您的基礎架構有哪些限制？ 您的數據是什么類型？ 有關系嗎 圖形？ 文件？ 您有要實施的架構嗎？

我可能會寫幾篇有關此的文章，理解此數據，設置邊界，要求，義務等非常重要，這樣才能使此配方生效。

> 4Vs of Big Data

 

數據量是關鍵，如果每天要處理數十億個事件或海量數據集，則需要將大數據原理應用于管道。 但是，沒有一個單一的邊界可以將"小"數據與"大"數據以及其他方面（例如速度，團隊組織，公司規模，所需分析類型，基礎架構或業務目標）區分開來 您的大數據之旅。 讓我們回顧其中的一些……

OLTP與OLAP

幾年前，企業曾經使用關系數據庫支持在線應用程序，該關系數據庫用于存儲用戶和其他結構化數據（OLTP）。 一夜之間，這些數據使用復雜的作業存檔到數據倉庫中，該倉庫針對數據分析和商業智能（OLAP）進行了優化。 歷史數據已復制到數據倉庫中，并用于生成用于制定業務決策的報告。

數據倉庫與數據湖

隨著數據的增長，數據倉庫變得昂貴且難以管理。 此外，公司開始存儲和處理非結構化數據，例如圖像或日志。 借助大數據，公司開始創建數據湖以集中其結構化和非結構化數據，從而創建一個包含所有數據的存儲庫。

 

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

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

Hadoop或非Hadoop

自2006年發布以來，Hadoop一直是大數據世界中的主要參考。 基于MapReduce編程模型，它允許使用簡單的編程模型來處理大量數據。 多年來，該生態系統呈指數增長，從而創建了一個可以處理任何用例的豐富生態系統。

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

> Simplified Hadoop Ecosystem

 

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

批處理與流處理

根據對數據溫度的分析，您需要確定是否需要實時流傳輸，批處理或在許多情況下都需要。

在理想環境中，您將實時地從實時數據中獲取所有見解，并執行基于窗口的聚合。 但是，對于某些用例來說，這是不可能的，而對于另一些用例，則沒有成本效益。 這就是為什么許多公司同時使用批處理和流處理的原因。 您應該檢查您的業務需求，并確定哪種方法更適合您。 例如，如果只需要創建一些報告，則批處理就足夠了。 批處理更簡單，更便宜。

 

最新的處理引擎，例如Apache Flink或Apache Beam，也稱為第四代大數據引擎，為批處理和流數據提供統一的編程模型，其中批處理只是每24小時進行一次流處理。 這簡化了編程模型。

一種常見的模式是具有流數據以獲取時間緊迫的見解，例如信用卡欺詐，以及用于報告和分析的批處理。 較新的OLAP引擎允許以統一的方式進行查詢。

ETL與ELT

根據您的用例，您可能需要在加載或讀取時轉換數據。 ELT意味著您可以執行將數據轉換和聚合為查詢一部分的查詢，這可以使用SQL進行，您可以在其中應用函數，過濾數據，重命名列，創建視圖等。BigData OLAP引擎可以實現 它提供了一種以ELT方式實時查詢和批量查詢的方法。 另一種選擇是在負載（ETL）上轉換數據，但請注意，在處理過程中進行聯接和聚合并不是一件容易的事。 通常，數據倉庫使用ETL，因為它們傾向于要求使用固定的模式（星型或雪花型），而數據湖更靈活，并且可以在讀取時執行ELT和模式。

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

團隊結構和方法

最后，您的公司政策，組織，方法論，基礎架構，團隊結構和技能在您的大數據決策中起著重要作用。 例如，您可能有一個數據問題，需要您創建管道，但不必處理大量數據，在這種情況下，您可以編寫一個流應用程序，在該應用程序中以 單一管道更容易； 但是如果您的公司已經有一個數據湖，則您可能希望使用現有的平臺，而這并不是您從頭開始構建的。

另一個例子是ETL與ELT。 開發人員傾向于構建ETL系統，在該系統中，數據可以以簡單的格式進行查詢，因此非技術人員可以構建儀表板并獲得見解。 但是，如果您有強大的數據分析人員團隊和小型開發人員團隊，則您可能更喜歡ELT方法，使開發人員只專注于提取； 數據分析師編寫復雜的查詢來轉換和聚合數據。 這表明在大數據旅程中考慮團隊結構和技能的重要性。

建議將一支具有不同技能和背景的多元化團隊一起工作，因為數據是整個組織的跨職能部門。 數據湖非常擅長在保持數據治理和安全性的同時實現輕松協作。

配料

在回顧了大數據世界的多個方面之后，我們來看看基本要素是什么。

數據存儲

您需要的第一件事是一個存儲所有數據的地方。 不幸的是，沒有一種產品可以滿足您的需求，這就是為什么您需要根據用例選擇合適的存儲。

對于實時數據攝取，通常使用附加日志來存儲實時事件，最著名的引擎是Kafka。 另一種選擇是Apache Pulsar。 兩者都提供流功能，還可以存儲事件。 這通常是熱數據的短期存儲（請記住數據溫度！），因為它不經濟高效。 還有其他一些工具，例如用于存儲數據的Apache NiFi，它們都有自己的存儲空間。 最終，數據將從附加日志傳輸到另一個存儲，該存儲可以是數據庫或文件系統。

海量數據庫

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

總結要考慮的Hadoop生態系統之外的數據庫和存儲選項是：

· Cassandra：NoSQL數據庫，可以存儲大量數據，提供最終的一致性和許多配置選項。 非常適合OLTP，但可用于帶有預先計算的聚合的OLAP（不靈活）。 一個替代方案是ScyllaDB，對于OLAP（高級調度程序）而言，它更快，更好。

· YugaByteDB：大規模關系數據庫，可以處理全球事務。 關系數據的最佳選擇。

· MongoDB：強大的基于文檔的NoSQL數據庫，可用于提取（臨時存儲）或用作儀表板的快速數據層

· InfluxDB用于時間序列數據。

· Prometheus用于監視數據。

· ElasticSearch：分布式倒排索引，可以存儲大量數據。 有時，ElasticSearch被許多人忽略或僅用于日志存儲，它可用于各種用例，包括OLAP分析，機器學習，日志存儲，非結構化數據存儲等等。 絕對是您在大數據生態系統中擁有的工具。

記住SQL和NoSQL之間的區別，在NoSQL世界中，您不對數據建模，而是對查詢建模。

Hadoop數據庫

HBase是Hadoop生態系統中最受歡迎的數據庫。 它可以以列格式保存大量數據。 它基于BigTable。

文件系統（深度存儲）

對于數據湖，在Hadoop生態系統中，使用HDFS文件系統。 但是，大多數云提供商已將其替換為他們自己的深度存儲系統，例如S3或GCS。

這些文件系統或深度存儲系統比數據庫便宜，但僅提供基本存儲，不提供強大的ACID保證。

您將需要根據您的需求和預算為您的用例選擇合適的存儲。 例如，如果您的預算允許，則可以使用數據庫進行攝取，然后轉換數據后，將其存儲在數據湖中以進行OLAP分析。 或者，您可以將所有內容存儲在深度存儲中，但將一小部分熱數據存儲在關系數據庫等快速存儲系統中。

文件格式

如果使用HDFS，另一個重要的決定是將使用哪種格式存儲文件。 請注意，深度存儲系統將數據存儲為文件，并且不同的文件格式和壓縮算法為某些用例提供了好處。 如何在數據湖中存儲數據至關重要，您需要考慮格式，壓縮方式，尤其是如何對數據進行分區。

最常見的格式是CSV，JSON，AVRO，協議緩沖區，Parquet和ORC。

> Comparison between file formats

 

選擇格式時應考慮以下幾點：

· 數據的結構：某些格式接受JSON，Avro或Parquet等嵌套數據，而其他格式則不接受。 即使這樣做，也可能不會對其進行高度優化。 Avro是嵌套數據的最有效格式，我建議不要使用Parquet嵌套類型，因為它們效率很低。 進程嵌套JSON也非常占用CPU。 通常，建議在攝取數據時將其放平。

· 性能：Avro和Parquet等某些格式的性能優于其他JSON。 即使在Avro和Parquet的不同用例之間，一個也會比其他更好。 例如，由于Parquet是基于列的格式，因此使用SQL查詢數據湖非常有用，而Avro更適合ETL行級轉換。

· 易于閱讀：考慮是否需要人們閱讀數據。 JSON或CSV是文本格式，并且易于閱讀，而功能更強的格式例如鑲木地板或Avro是二進制。

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

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

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

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

最后，您還需要考慮文件大小和CPU成本之間的權衡，如何壓縮文件中的數據。 某些壓縮算法速度更快，但文件大小更大；另一些壓縮算法速度較慢，但壓縮率更高。 有關更多詳細信息，請查看本文。

> Compression options

 

我建議使用快照來流式傳輸數據，因為它不需要太多的CPU能力。 對于批處理，bzip2是一個不錯的選擇。

同樣，您需要查看我們之前提到的注意事項，并根據我們查看的所有方面進行決策。 讓我們以一些用例為例：

用例

· 您需要在某處提取實時數據和存儲，以作為ETL管道的一部分進行進一步處理。 如果性能很重要并且預算不是問題，則可以使用Cassandra。 標準方法是使用優化格式（如AVRO）將其存儲在HDFS中。

· 您需要在某個地方處理數據和存儲，以供高度交互的面向用戶的應用程序使用，其中延遲很重要（OLTP），您需要提前知道查詢。 在這種情況下，請根據數據量使用Cassandra或其他數據庫。

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

· 您需要為內部團隊存儲處理后的數據以進行OLAP分析，以便他們可以運行臨時查詢并創建報告。 在這種情況下，您可以將數據以Parquet或ORC格式存儲在深度存儲文件系統中。

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

· 您需要執行非常復雜的查詢，而這些查詢只需幾毫秒即可響應，還可能需要在讀取時執行聚合。 在這種情況下，請使用ElasticSearch存儲數據或某些較新的OLAP系統（如Apache Pinot），稍后我們將對其進行討論。

· 您需要搜索非結構化文本。 在這種情況下，請使用ElasticSearch。

基礎設施

當前的基礎架構會在決定使用哪些工具時限制您的選擇。 要問的第一個問題是：云計算與本地部署。 云提供商提供了許多選擇和靈活性。 此外，它們為您的大數據需求提供了無服務器解決方案，更易于管理和監控。 無疑，云是存放大數據的地方。 即使對于Hadoop生態系統，云提供商也提供托管群集和比本地存儲便宜的存儲。 查看我有關云解決方案的其他文章。

如果您在場所中運行，則應考慮以下事項：

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

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

監控和警報

下一個要素對于數據管道的成功至關重要。 在大數據世界中，您需要有關流程和數據的不斷反饋。 您需要收集指標，收集日志，監視系統，創建警報，儀表板等等。

使用Prometheus和Grafana等開源工具進行監視和警報。 使用日志聚合技術來收集日志并將其存儲在諸如ElasticSearch之類的地方。

> Grafana Monitoring

 

利用云提供商的功能進行監視和警報（如果可能）。 根據您的平臺，您將使用不同的工具集。 對于無云服務器平臺，您將依靠您的云提供商工具和最佳實踐。 對于Kubernetes，您將使用開源監控器解決方案或企業集成。 我真的推薦這個網站，在這里您可以瀏覽和檢查不同的解決方案，并構建自己的APM解決方案。

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

對于Hadoop，使用Ganglia。

安全

Apache Ranger為您的Hadoop平臺提供了統一的安全監控框架。 提供集中的安全性管理，以在中央UI中管理所有與安全性相關的任務。 它使用不同的方法提供授權，并在整個Hadoop平臺上提供全面的可審核性。

人

您的團隊是成功的關鍵。 大數據工程師可能很難找到。 投資于培訓，技能提升，研討會。 刪除孤島和繁文tape節，簡化迭代過程，并使用域驅動設計來設置團隊邊界和職責。

對于大數據，您將分為兩大類：

· 數據工程師進行攝取，豐富和轉換。 這些工程師具有強大的開發和運營背景，并負責創建數據管道。 開發人員，管理員，DevOps專家等將屬于此類別。

· 數據科學家：他們可以是BI專家，數據分析師等，負責生成報告，儀表板和收集見解。 這些人專注于OLAP并具有深刻的業務理解，收集了將用于制定關鍵業務決策的數據。 SQL和可視化方面很強，但是軟件開發方面很弱。 機器學習專家也可能屬于此類。

預算

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

食譜

現在我們已經掌握了食材，讓我們來烹飪我們的大數據食譜。 簡而言之，該過程很簡單； 您需要從不同來源獲取數據，對其進行充實，將其存儲在某個位置，存儲元數據（模式），對其進行清理，對其進行規范化，對其進行處理，隔離不良數據，以最佳方式聚合數據并將其最終存儲在某個位置以供下游系統使用 。

讓我們更詳細地了解每個步驟…

數據攝取

第一步是獲取數據，此階段的目標是獲取所需的所有數據并將其以原始格式存儲在單個存儲庫中。 它通常由將其數據推送到Kafka或數據存儲中的其他團隊擁有。

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

有兩種攝取方式：

· 拉取：從數據庫，文件系統，隊列或API等地方提取數據

· 推送：應用程序也可以將數據推送到您的湖泊中，但始終建議在兩者之間使用一個消息傳遞平臺，例如Kafka。 常見的模式是變更數據捕獲（CDC），它使我們能夠將數據從數據庫和其他系統實時移入湖泊。

正如我們已經提到的，使用Kafka或Pulsar作為數據攝取的中介是極為常見的，以實現持久性，背壓，并行化和攝取的監控。然后，使用Kafka Connect將數據保存到您的數據湖中。這個想法是您的OLTP系統將事件發布到Kafka，然后將其吸收到您的湖泊中。避免直接通過API批量提取數據；您可能會調用HTTP端點進行數據充實，但請記住，從API提取數據在大數據世界中并不是一個好主意，因為它速度慢，容易出錯（網絡問題，延遲等），并且可能導致源系統崩潰。盡管API非常適合在OLTP世界中設置域邊界，但這些邊界是由大數據世界中Kafka中的數據存儲（批次）或主題（實時）來設置的。當然，它總是取決于數據的大小，但是如果可能，如果沒有其他選擇，請嘗試使用Kafka或Pulsar。以流式方式從API中提取少量數據，而不是批量提取。對于數據庫，請使用Debezium等工具將數據流式傳輸到Kafka（CDC）。

為了最大程度地減少依賴性，如果源系統將數據推送到Kafka而不是您的團隊提取數據，則總是比較容易，因為您將與其他源系統緊密耦合。 如果無法做到這一點，并且您仍然需要掌握攝取過程，那么我們可以考慮兩種主要的攝取類別：

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

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

Apache NiFi

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

> NiFi workflow

 

它具有自己的體系結構，因此它不使用任何數據庫HDFS，但已與Hadoop生態系統中的許多工具集成。 您可以調用API，并與Kafka，FTP，許多文件系統和云存儲集成。 您可以管理執行路由，過濾和基本ETL的數據流。 對于某些用例，您可能只需要NiFi。

但是，由于節點間的通信，群集中的10個以上節點效率低下，因此NiFi無法擴展到某個特定點。 它傾向于在垂直方向更好地擴展，但是您可以達到其極限，尤其是對于復雜的ETL。 但是，您可以將其與Spark等工具集成以處理數據。 NiFi是吸收和豐富數據的絕佳工具。

諸如Druid或Pinot之類的現代OLAP引擎還提供了自動提取批處理和流數據的功能，我們將在另一部分中討論它們。

您也可以在提取過程中進行一些初始驗證和數據清理，只要它們不是昂貴的計算或不跨越有限的上下文，請記住，空字段可能與您無關，但對另一個團隊很重要。

最后一步是確定數據的放置位置，我們已經討論過了。 您可以使用數據庫或深度存儲系統。 對于數據湖，通常將其存儲在HDFS中，其格式取決于下一步；請參見下一步。 如果您打算執行行級操作，Avro是一個不錯的選擇。 Avro還使用外部注冊表支持架構演變，這將使您可以相對輕松地更改所攝取數據的架構。

元數據

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

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

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

 

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

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

數據處理

此階段的目標是使用單個架構清理，規范化，處理和保存數據。 最終結果是具有良好定義的架構的可信數據集。

通常，您需要執行某種處理，例如：

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

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

· 值的標準化和標準化

· 重命名字段

· …

請記住，目標是創建一個可信的數據集，以后可用于下游系統。 這是數據工程師的關鍵角色。 這可以以流或批處理的方式完成。

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

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

· 可信階段：數據經過驗證，清理，規范化并轉換為Hive中存儲的通用模式。 目標是創建數據所有者理解的受信任的通用數據集。 通常，將創建一個數據規范，數據工程師的職責是應用轉換以匹配該規范。 最終結果是以Parquet格式設置的數據集，可以輕松查詢該數據集。 選擇正確的分區并優化數據以執行內部查詢至關重要。 您可能希望在此階段部分地預先計算一些聚合，以提高查詢性能。

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

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

處理框架

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

· Apache Spark：這是最著名的批處理框架。 它是Hadoop生態系統的一部分，是一個托管集群，可提供令人難以置信的并行性，監控和出色的UI。 它還支持流處理（結構流）。 基本上，Spark在內存中運行MapReduce作業，其性能是常規MapReduce性能的100倍。 它與Hive集成在一起以支持SQL，并可用于創建Hive表，視圖或查詢數據。 它具有很多集成，支持多種格式，并且擁有龐大的社區。 所有云提供商都支持它。 它可以作為Hadoop集群的一部分在YARN上運行，也可以在Kubernetes和其他平臺上運行。 它具有許多針對特定用例（例如SQL或機器學習）的庫。

 

· Apache Flink：第一個統一批處理和流傳輸的引擎，但主要關注流傳輸。 它可以用作像Kafka這樣的微服務的主干。 它可以作為Hadoop集群的一部分在YARN上運行，但自成立以來，它還針對其他平臺（如Kubernetes或Mesos）進行了優化。 它非常快，并提供實時流傳輸，使其成為比Spark在低延遲流處理（尤其是有狀態流）方面更好的選擇。 它還具有用于SQL，機器學習等的庫。

 

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

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

 

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

 

在此處理階段結束時，您已經烹飪了數據，現在可以使用了！但是，為了烹飪，廚師必須與團隊合作…

編排

數據管道編排是一個交叉過程，它管理所有其他任務之間的依賴關系。 如果使用流處理，則需要編排每個流應用程序的依賴關系，而對于批處理，則需要安排和編排作業。

任務和應用程序可能會失敗，因此您需要一種以統一的方式計劃，重新計劃，重放，監視，重試和調試整個數據管道的方法。

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

一些選項是：

· Apache Oozie：Oozie是Hadoop的調度程序，作業創建為DAG，并且可以由時間或數據可用性觸發。 它與Sqoop等提取工具和Spark等處理框架集成在一起。

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

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

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

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

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

數據質量

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

該領域存在兩個常見問題：

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

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

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

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

一些關注數據質量的工具是：

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

> Apache Griffin Processes

 

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

> Great expectations UI

 

數據查詢

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

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

· 數據倉庫與數據湖

· Hadoop與獨立

· OLAP與OLTP

· 查詢引擎與OLAP引擎

我們還應該考慮具有查詢功能的處理引擎。

處理引擎

我們在上一節中描述的大多數引擎都可以連接到元數據服務器，例如Hive并運行查詢，創建視圖等。這是創建精細報表層的常見用例。

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

 

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

查詢引擎

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

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

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

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

> Drill model

 

OLTP數據庫

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

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

Apache Phoenix建立在HBase之上，并提供了一種在Hadoop生態系統中執行OTLP查詢的方法。 Apache Phoenix與其他Hadoop產品（例如Spark，Hive，Pig，Flume和Map Reduce）完全集成。 它還可以存儲元數據，并支持通過DDL命令創建表和版本化的增量更改。 它非常快，比使用Drill或其他查詢引擎要快。

您可以使用Hadoop生態系統以外的任何大規模數據庫，例如Cassandra，YugaByteDB，SyllaDB for OTLP。

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

分布式搜索索引

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

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

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

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

它也可以用于分析。 您可以導出數據，對其進行索引，然后使用Kibana對其進行查詢，創建儀表板，報告等等，還可以添加直方圖，復雜的聚合甚至在數據之上運行機器學習算法。 彈性生態系統非常龐大，值得探索。

 

OLAP數據庫

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

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

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

 

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

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

 

OLAP引擎

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

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

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

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

> Druid architecture

 

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

> Apache Pinot

 

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

> ClickHouse

 

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

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

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

 

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

結論

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

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

由于對您控制范圍之外的系統的依賴性，數據提取至關重要且復雜。 嘗試管理那些依賴關系并創建可靠的數據流以正確提取數據。 如果可能，請其他團隊負責數據提取。 請記住添加指標，日志和跟蹤以跟蹤數據。 啟用架構演變，并確保已在平臺中設置適當的安全性。

使用正確的工具完成工作，不要花費太多。 諸如Cassandra，Druid或ElasticSearch之類的工具是令人贊嘆的技術，但需要大量知識才能正確使用和管理。 如果只需要對臨時查詢和報告進行OLAP批處理分析，請使用Hive或Tajo。 如果需要更好的性能，請添加Kylin。 如果還需要與其他數據源聯接，請添加查詢引擎，例如Drill或Presto。 此外，如果您需要實時查詢批次，請使用ClickHouse，Druid或Pinot。

如有任何疑問或需要任何建議，請隨時與我們聯系。

希望您喜歡這篇文章。 隨時發表評論或分享這篇文章。 跟我來以后的帖子。

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