非傳統數據存儲的數據工程師指南

數據工程

隨著大數據和數據科學的興起，許多工程角色正在受到挑戰和擴展。 一個新時代的角色是數據工程。

最初，數據工程的目的是加載外部數據源和設計數據庫（設計和開髮用於收集、操作、存儲和分析數據的管道）。

從那以後，它已經發展到支持大數據的數量和復雜性。 因此，數據工程現在包含了廣泛的技能，從網絡爬取、數據清理、分佈式計算以及數據存儲和檢索。

對於數據工程和數據工程師來說，數據存儲和檢索是管道的關鍵組成部分，以及如何使用和分析數據。

最近，出現了許多新的和不同的數據存儲技術。 但是，哪一個最適合併具有最適合數據工程的特性？

大多數工程師都熟悉 SQL 數據庫，例如 PostgreSQL、MSSQL 和 MySQL，這些數據庫以關係數據表的形式結構化，並具有面向行的存儲。

鑑於這些數據庫無處不在，我們今天不討論它們。 相反，我們探索了三種類型的替代數據存儲，它們越來越受歡迎，並引入了不同的數據處理方法。

在數據工程的上下文中，這些技術是搜索引擎、文檔存儲和列式存儲。

• 搜索引擎擅長文本查詢。 與 SQL 數據庫中的文本匹配（例如LIKE ）相比，搜索引擎提供了更高的查詢能力和更好的開箱即用性能。
• 文檔存儲提供比傳統數據庫更好的數據模式適應性。 通過將數據存儲為單個文檔對象，通常表示為 JSON，它們不需要模式預定義。
• 列式存儲專門用於單列查詢和值聚合。 SQL 操作（例如SUM和AVG ）在列存儲中要快得多，因為同一列的數據在硬盤驅動器上存儲得更近。

在本文中，我們將探討所有三種技術：作為搜索引擎的 Elasticsearch、作為文檔存儲的 MongoDB，以及作為列式存儲的 Amazon Redshift。

通過了解替代數據存儲，我們可以為每種情況選擇最合適的一種。

為了比較這些技術，我們將研究它們如何索引、分片和聚合數據。

每種數據索引策略都改進了某些查詢，同時阻礙了其他查詢。

了解最常使用哪些查詢可以影響採用哪個數據存儲。

分片是一種數據庫將其數據分成塊的方法，它決定了基礎架構將如何隨著更多數據的攝取而增長。

選擇與我們的增長計劃和預算相匹配的公司至關重要，這適用於任何數據科學公司，無論規模大小。

最後，這些技術各自聚合其數據的方式非常不同。

當我們處理千兆字節和千兆字節的數據時，錯誤的聚合策略會限制我們可以生成的報告的類型和性能。

作為數據工程師，我們在評估不同的數據存儲時必須考慮所有三個方面。

競爭者

搜索引擎：彈性搜索

Elasticsearch 因其可擴展性和易於集成性而迅速在同行中廣受歡迎。 它建立在 Apache Lucene 之上，提供了強大的、開箱即用的文本搜索和索引功能。 除了傳統的搜索引擎任務、文本搜索和精確值查詢之外，Elasticsearch 還提供分層聚合功能。

文檔存儲：MongoDB

在這一點上，MongoDB 可以被認為是首選的 NoSQL 數據庫。 它的易用性和靈活性很快贏得了它的歡迎。 MongoDB 支持豐富且適應性強的查詢，以挖掘複雜的文檔。 經常查詢的字段可以通過索引來加速，當聚合大量數據時，MongoDB 提供了多級管道。

列式存儲：Amazon Redshift

隨著 NoSQL 的普及，列式數據庫也引起了人們的關注，尤其是在數據分析方面。 通過將數據存儲在列中而不是通常的行中，可以直接從磁盤執行聚合操作，從而大大提高性能。 幾年前，亞馬遜為一家名為 Redshift 的柱狀商店推出了託管服務。

索引

Elasticsearch 的索引能力

在許多方面，搜索引擎是專門用於索引文本的數據存儲。

雖然其他數據存儲基於字段的確切值創建索引，但搜索引擎允許僅使用（通常是文本）字段的片段進行檢索。

默認情況下，此檢索是通過分析器對每個字段自動完成的。

分析器是一個模塊，它通過評估字段值並將它們分解為更小的值來創建多個索引鍵。

例如，一個基本的分析器可能會將“the quick brown fox jumped over the lazy dog”檢查成諸如“the”、“quick”、“brown”、“fox”等單詞。

此方法使用戶可以通過在結果中搜索片段來查找數據，按與相同文檔數據匹配的片段數量進行排序。

更複雜的分析器可以利用編輯距離、n-gram 和停用詞過濾來構建全面的檢索索引。

MongoDB的索引能力

作為通用數據存儲，MongoDB 在索引數據方面具有很大的靈活性。

與 Elasticsearch 不同的是，它默認只索引_id字段，我們需要手動為經常查詢的字段創建索引。

與 Elasticsearch 相比，MongoDB 的文本分析器沒有那麼強大。 但它確實為索引方法提供了很大的靈活性，從用於優化查詢的複合和地理空間到用於減少存儲的 TTL 和稀疏。

Redshift 的索引能力

與 Elasticsearch、MongoDB 甚至包括 PostgreSQL 在內的傳統數據庫不同，Amazon Redshift 不支持索引方法。

相反，它通過在磁盤上保持一致的排序來減少查詢時間。

作為用戶，我們可以將一組有序的列值配置為表排序鍵。 在磁盤上對數據進行排序後，如果其值超出查詢範圍，Redshift 可以在檢索期間跳過整個塊，從而大大提高性能。

分片

Elasticsearch 的分片能力

Elasticsearch 建立在 Lucene 之上，可水平擴展並為生產做好準備。

擴展是通過創建多個 Lucene 實例（分片）並將它們分佈在集群內的多個節點（服務器）上來完成的。

默認情況下，每個文檔都通過其_id字段路由到其各自的分片。

在檢索過程中，主節點向每個分片發送查詢的副本，然後最終匯總和排列它們以供輸出。

MongoDB的分片能力

在 MongoDB 集群中，存在三種類型的服務器：路由器、配置和分片。

通過擴展路由器，服務器可以接受更多請求，但繁重的工作發生在分片服務器上。

與 Elasticsearch 一樣，MongoDB 文檔（默認情況下）通過_id路由到它們各自的分片。 在查詢時，配置服務器通知路由器，路由器將查詢分片，然後路由器服務器分發查詢並聚合結果。

Redshift 的分片能力

一個 Amazon Redshift 集群由一個領導節點和多個計算節點組成。

領導節點處理查詢的編譯和分發以及中間結果的聚合。

與 MongoDB 的路由器服務器不同，領導節點是一致的，不能橫向擴展。

雖然這會造成瓶頸，但它也允許有效緩存流行查詢的已編譯執行計劃。

聚合

Elasticsearch 的聚合能力

Elasticsearch 中的文檔可以按精確、範圍甚至時間和地理位置值進行分類。

這些桶可以通過嵌套聚合進一步分組為更精細的粒度。

可以為每一層計算指標，包括平均值和標準差，從而提供在單個查詢中計算分析層次結構的能力。

作為基於文檔的存儲，它確實受到文檔內字段比較的限制。

例如，雖然它擅長過濾字段關注者是否大於 10，但我們無法檢查關注者是否大於關注的另一個字段。

作為替代方案，我們可以將腳本作為自定義謂詞注入。 此功能非常適合一次性分析，但在生產中性能會受到影響。

MongoDB的聚合能力

聚合管道功能強大且快速。

顧名思義，它以分階段的方式對返回的數據進行操作。

每個步驟都可以過濾、聚合和轉換文檔，引入新的指標，或者展開以前聚合的組。

因為這些操作是分階段完成的，並且通過確保將文檔和字段減少到僅過濾，可以最小化內存成本。 與 Elasticsearch 甚至 Redshift 相比，Aggregation Pipeline 是一種查看數據的極其靈活的方式。

儘管具有適應性，但 MongoDB 與 Elasticsearch 一樣缺乏文檔內字段比較。

此外，一些操作，包括$group ，需要將結果傳遞給主節點。

因此，它們不利用分佈式計算。

那些不熟悉分階段流水線計算的人會發現某些任務不直觀。 例如，對數組字段中元素的數量求和需要兩個步驟：首先是$unwind ，然後是$group操作。

Redshift 的聚合能力

Amazon Redshift 的優勢不容小覷。

Amazon Redshift 快速解決了在分析移動流量時在 MongoDB 上聚合緩慢的問題。

支持 SQL，傳統數據庫工程師可以輕鬆地將他們的查詢遷移到 Redshift。

除了入門時間，SQL 是一種經過驗證、可擴展且功能強大的查詢語言，可輕鬆支持文檔內/行內字段比較。 Amazon Redshift 通過編譯和緩存在計算節點上執行的流行查詢進一步提高了性能。

作為關係數據庫，Amazon Redshift 不具備 MongoDB 和 Elasticsearch 所具有的架構靈活性。 針對讀取操作進行了優化，它在更新和刪除期間會受到性能影響。

為了保持最佳讀取時間，必須對行進行排序，從而增加額外的操作工作量。

為那些有 PB 級問題的人量身定做，它並不便宜，而且可能不值得投資，除非其他數據庫存在擴展問題。

挑選獲勝者

在本文中，我們在數據工程的背景下研究了三種不同的技術——Elasticsearch、MongoDB 和 Amazon Redshift。 但是，沒有明顯的贏家，因為這些技術中的每一項都是其存儲類型類別的領先者。

對於數據工程，根據用例，某些選項比其他選項更好。

• MongoDB是一個很棒的入門數據庫。 當數據模式仍有待確定時，它提供了我們想要的靈活性。 也就是說，MongoDB 的性能並不優於其他數據庫擅長的特定用例。
• 雖然Elasticsearch提供了與 MongoDB 類似的流動模式，但它針對多個索引和文本查詢進行了優化，但以犧牲寫入性能和存儲大小為代價。 因此，當我們發現自己在 MongoDB 中維護大量索引時，我們應該考慮遷移到 Elasticsearch。
• Redshift需要預定義的數據模式，並且缺乏 MongoDB 提供的適應性。 作為回報，它在僅涉及單個（或幾個）列的查詢方面優於其他數據庫。 在預算允許的情況下，當其他人無法處理數據量時，Amazon Redshift 是一個很好的秘密武器。