一 為什么要使用流數(shù)據(jù)架構(gòu)

流處理最初是一種“特定群體”技術(shù)。但隨著 SaaS、物聯(lián)網(wǎng)和機器學(xué)習(xí)的快速發(fā)展，各行各業(yè)的組織現(xiàn)在都在試行或全面實施流分析。很難找到一家沒有應(yīng)用程序、在線廣告、電子商務(wù)網(wǎng)站或物聯(lián)網(wǎng)產(chǎn)品的現(xiàn)代公司。這些數(shù)字資產(chǎn)中的每一個都會創(chuàng)建實時事件數(shù)據(jù)流。人們越來越渴望整合流式數(shù)據(jù)基礎(chǔ)架構(gòu)，從而使復(fù)雜、強大和實時的分析成為可能。

傳統(tǒng)的批處理架構(gòu)可以滿足較小規(guī)模的需求。但流媒體資源——傳感器、服務(wù)器和安全日志、實時廣告、來自應(yīng)用程序和網(wǎng)站的點擊流數(shù)據(jù)等等——每秒可以生成多達 1 Gb 的事件。流式數(shù)據(jù)架構(gòu)在生成數(shù)據(jù)時使用這些數(shù)據(jù)，并準(zhǔn)備好進行分析?？紤]到數(shù)據(jù)流的獨特特征，后者尤其重要——通常是非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)，在進行任何認真的分析之前必須對其進行處理、解析和結(jié)構(gòu)化。

流式架構(gòu)提供了批處理管道無法提供的多項優(yōu)勢：

• 以原生形式處理永無止境的事件流，避免批處理事件的開銷和延遲。 
• 實時或近實時處理最新的數(shù)據(jù)分析和洞察力——例如，顯示機器性能的儀表板，或微目標(biāo)廣告或即時服務(wù)，或檢測欺詐或網(wǎng)絡(luò)安全漏洞。
• 檢測時間序列數(shù)據(jù)中的模式， 例如突出顯示網(wǎng)站流量數(shù)據(jù)的趨勢。這很難用傳統(tǒng)的批處理來完成，因為連續(xù)的時間相鄰事件可以跨多個批次中斷。

構(gòu)建流媒體架構(gòu)是一項復(fù)雜的挑戰(zhàn)，最好根據(jù)用例使用額外的軟件組件來解決——因此需要“構(gòu)建”一個通用解決方案，以處理大多數(shù)（如果不是全部）設(shè)想的用例。

二 流式架構(gòu)的組件

流數(shù)據(jù)架構(gòu)是一個軟件組件框架，用于從多個來源攝取和處理大量原始數(shù)據(jù)流。 

從廣義上講，它由四個部分組成：

1. 流處理器或消息代理，用于收集數(shù)據(jù)并重新分發(fā)它
2. 數(shù)據(jù)轉(zhuǎn)換工具（ETL、ELT 等），為查詢準(zhǔn)備好數(shù)據(jù)
3. 查詢引擎，提取商業(yè)價值
4. 大量流數(shù)據(jù)的經(jīng)濟高效存儲——文件存儲和對象存儲

下面我們回顧一下每種組件類型在流式架構(gòu)中的位置和方式。

流處理器/消息代理 

流處理器從其來源收集數(shù)據(jù)，將其轉(zhuǎn)換為標(biāo)準(zhǔn)消息格式，然后連續(xù)流式傳輸以供其他組件使用。（此類組件可以是存儲組件，例如數(shù)據(jù)湖、ETL 工具或其他類型的組件。）流處理器具有高容量（>1 Gb/秒），但不執(zhí)行其他數(shù)據(jù)轉(zhuǎn)換或任務(wù)調(diào)度。

作為數(shù)據(jù)管道的流處理器

例子：

• Apache Kafka
• Amazon Kinesis Data Streams
• Azure Event Hub
• Google Cloud PubSub

流處理工具

在消息代理存儲數(shù)據(jù)后，您必須聚合、轉(zhuǎn)換和構(gòu)建數(shù)據(jù)以使其可以查詢。您可以通過 ETL 執(zhí)行此操作，在其中您在暫存區(qū)域或流工具中準(zhǔn)備數(shù)據(jù)，然后再將其移動到查詢位置，或者通過 ELT，在同一位置轉(zhuǎn)換和查詢數(shù)據(jù)。此類轉(zhuǎn)換包括規(guī)范化；將相關(guān)字段映射到列；加入來自多個來源的數(shù)據(jù)；文件壓縮；分區(qū)；基于時間的聚合；等等。

例子：

• Apache Spark Streaming (SQL querying possible, mostly via complex Java or Scala)
• Amazon Web Services – Kinesis
• Google Cloud – Dataflow
• Microsoft Azure – Stream Analytics
• Apache Flink
• Upsolver

請注意，根據(jù)您的需求和您創(chuàng)建的架構(gòu)，數(shù)據(jù)轉(zhuǎn)換可能會直接發(fā)生在數(shù)據(jù)流入和存儲在數(shù)據(jù)湖或其他存儲庫之前，或者在數(shù)據(jù)被攝取和存儲之后。

查詢引擎

數(shù)據(jù)現(xiàn)在已準(zhǔn)備好進行分析。工具和技術(shù)差異很大，具體取決于用例。 

示例（并非詳盡無遺）：

• 查詢引擎——Athena、Presto、Hive、Redshift Spectrum
• 文本搜索引擎——Elasticsearch、OpenSearch、Solr、Kusto
• 云數(shù)據(jù)倉庫——AWS Redshift、Snowflake、Google BigQuery、Synapse Analytics (Azure)
• NOSQL 存儲 – Cassandra、Amazon DynamoDB、CosmosDB、Google BigTable
• 圖形分析——Neo4j、Amazon Neptune
• 關(guān)系數(shù)據(jù)庫——RDS、SingleStore、CockroachDB
• 實時數(shù)據(jù)庫——Imply、Clickhouse
• TSDB——InfluxDB，AWS TimeSeries

流式數(shù)據(jù)存儲

由于事件流的龐大數(shù)量和多結(jié)構(gòu)性質(zhì)，組織通常將其流事件數(shù)據(jù)存儲在云對象存儲中以用作數(shù)據(jù)湖。它們提供了一種經(jīng)濟高效且持久的方法來存儲大量事件數(shù)據(jù)。它們是一個靈活的集成點，因此流媒體生態(tài)系統(tǒng)之外的工具可以訪問流媒體數(shù)據(jù)。

例子：

• 亞馬遜 S3
• 微軟 Azure 存儲
• 谷歌云存儲

三 流式架構(gòu)最佳實踐

在構(gòu)建流架構(gòu)時，請牢記這些技術(shù)：

• 部署讀取模式模型
• 分離實時和歷史數(shù)據(jù)
• 維護所有傳入事件的不可變?nèi)罩?/li>
• 分層數(shù)據(jù)湖
• 保持架構(gòu)開放
• 優(yōu)化查詢性能

部署讀取模式模型

應(yīng)該了解正在攝取的數(shù)據(jù)——每個數(shù)據(jù)源的架構(gòu)、稀疏填充的字段、數(shù)據(jù)基數(shù)等。在讀取時獲得這種可見性而不是在寫入時嘗試推斷它可以省去很多麻煩，因為隨著架構(gòu)變化的發(fā)生（意外的新的、刪除的和更改的字段），可以基于最準(zhǔn)確和可用的數(shù)據(jù)構(gòu)建 ETL 管道。

 將用于實時分析的數(shù)據(jù)與歷史數(shù)據(jù)分開

優(yōu)化用于實時或近實時分析的數(shù)據(jù)以確?？焖僮x取。以原始形式保留歷史數(shù)據(jù)以供臨時查詢使用，用于：

• “回放”過去的事態(tài)
• 錯誤恢復(fù)
• 追蹤數(shù)據(jù)沿襲
• 探索性分析

維護所有傳入事件的不可變?nèi)罩?/h4>

在這里，實質(zhì)上是在存儲整個事件轉(zhuǎn)換鏈，而不僅僅是轉(zhuǎn)換的最終（或最近）結(jié)果。通過這種方式，可以將任何事件恢復(fù)到某個時間點的狀態(tài)。這種“事件溯源”方法有很多好處： 

• 使數(shù)據(jù)團隊能夠追溯驗證他們的假設(shè)
• 使運營團隊能夠跟蹤已處理數(shù)據(jù)的問題并快速修復(fù)它們
• 在發(fā)生故障或數(shù)據(jù)損壞的情況下提高容錯能力；可以通過將整個事件序列應(yīng)用于損壞的實體來恢復(fù)數(shù)據(jù)的當(dāng)前狀態(tài)。

為了降低成本，將日志存儲在對象存儲中。當(dāng)收到分析師或研究人員的請求時，創(chuàng)建一個 ETL 作業(yè)以將數(shù)據(jù)從不可變?nèi)罩玖魇絺鬏數(shù)椒治銎脚_，并從那里回放。 

根據(jù)用戶的技能對數(shù)據(jù)湖進行分層

在數(shù)據(jù)湖中存儲多個數(shù)據(jù)副本，以服務(wù)于范圍廣泛的消費者。理想的數(shù)據(jù)管道讓這些消費者中的每一個都能使用他們已知的工具訪問他們想要的數(shù)據(jù)——例如，完整（或接近完整）的數(shù)據(jù)科學(xué)家或機器學(xué)習(xí)算法的原始數(shù)據(jù)，或者聚合的、更薄的和結(jié)構(gòu)化的版本BI 分析師可以使用它來快速創(chuàng)建報告。可以自動化提取原始數(shù)據(jù)的 ETL 管道，并根據(jù)用例執(zhí)行相關(guān)轉(zhuǎn)換。然后，可以避免依賴數(shù)據(jù)提供者（DevOps、數(shù)據(jù)工程）手動工作的瓶頸，例如為每個新請求編寫 Apache Spark 等 ETL 框架。

針對不同用戶組配置的云數(shù)據(jù)湖

保持架構(gòu)開放

鑒于分析行業(yè)的快速變化，保持對“面向未來”的架構(gòu)的開放性至關(guān)重要。避免供應(yīng)商鎖定或過度依賴單一工具或數(shù)據(jù)庫。當(dāng)可以通過廣泛的服務(wù)使用各種工具提供無處不在的數(shù)據(jù)訪問時，將獲得最大的價值。

要創(chuàng)建一個開放式架構(gòu)：

• 以開放的列式文件格式（例如 Avro 和 Parquet）存儲數(shù)據(jù)，這些格式是標(biāo)準(zhǔn)的、眾所周知的并得到廣泛支持（與為特定數(shù)據(jù)庫構(gòu)建的專有文件格式（例如Databricks Delta Lake ）相反），這也提高了查詢性能。
• 將原始歷史數(shù)據(jù)保留在廉價的對象存儲中，例如 Amazon S3。無論使用什么平臺來管理數(shù)據(jù)湖和運行 ETL，保障數(shù)據(jù)始終可用。
• 使用支持良好的中央元數(shù)據(jù)存儲庫，例如 AWS Glue 或 Hive 元存儲?？梢栽谝粋€位置集中管理所有元數(shù)據(jù)，在此過程中降低基礎(chǔ)架構(gòu)、IT 資源和工程時間方面的運營成本。

優(yōu)化查詢性能

以下最佳實踐可提高大多數(shù)業(yè)務(wù)案例的查詢性能：

• 適當(dāng)?shù)胤謪^(qū)數(shù)據(jù)以供您使用
• 轉(zhuǎn)換為高效的列式文件格式
• 經(jīng)常壓縮（合并）小文件

分區(qū)數(shù)據(jù)

如何對數(shù)據(jù)進行分區(qū)對查詢成本和速度有重大影響。查詢運行更高效、成本更低，因為適當(dāng)?shù)姆謪^(qū)限制了Amazon Athena 等查詢引擎為回答特定分析問題而必須掃描的數(shù)據(jù)量。

數(shù)據(jù)通常按時間戳進行分區(qū)。但是，根據(jù)查詢，數(shù)據(jù)可能會被其他字段分區(qū)，例如地理或與記錄時間戳不同的基于時間的字段。如果可能，根據(jù)可能運行的查詢類型和分析系統(tǒng)的建議來配置分區(qū)的大小。例如，如果大部分查詢都需要過去 12 小時的數(shù)據(jù)，考慮按小時而不是按天進行分區(qū)，以減少要掃描的數(shù)據(jù)量。

轉(zhuǎn)換為高效的列式文件格式

另一種減少掃描數(shù)據(jù)量的方法。將計劃用于分析的數(shù)據(jù)存儲在列式文件格式中，例如 Apache Parquet 或 ORC。使用列式格式，可以僅查詢所需的列，從而減少所需的計算量，從而加快查詢速度并降低成本。

經(jīng)常壓縮以解決“小文件問題”

數(shù)據(jù)流每天定期產(chǎn)生數(shù)百萬個小事件文件。小文件提供更新鮮的數(shù)據(jù)，但如果直接查詢這些小文件，隨著時間的推移會降低性能。將小文件合并為大小合適的文件的過程稱為壓縮。

權(quán)衡數(shù)據(jù)流通的價值與高性能的價值，并根據(jù)需要盡可能頻繁地壓縮文件，以使數(shù)據(jù)保持最佳文件大小。 

三 工具比較：流處理/事件流工具

到目前為止，最常見的事件流工具是 Amazon Kinesis 和 Apache Kafka。

亞馬遜Kinesis

Amazon Kinesis 是一種發(fā)布-訂閱 (pub-sub) 消息傳遞解決方案。它是 AWS 云中的一項托管服務(wù)；配置有限，無法在本地運行 Kinesis。

• 設(shè)置/配置：AWS 代表管理流式傳輸數(shù)據(jù)所需的基礎(chǔ)設(shè)施、存儲、網(wǎng)絡(luò)和配置。AWS 還處理硬件、軟件和其他數(shù)據(jù)流服務(wù)的配置、部署和持續(xù)維護。
• 成本：沒有前期設(shè)置成本。收費取決于：

• 所需吞吐量所需的分片（分區(qū)）數(shù)量 每個分片本質(zhì)上是一個包含數(shù)據(jù)子集的單獨流；Kinesis 每個流有多個分片）。
• 生產(chǎn)者傳輸?shù)綌?shù)據(jù)流的數(shù)據(jù)量，因此對于大量數(shù)據(jù)，成本可能很高。

• 用于：鑒于 Amazon 的高可用性承諾，如果沒有用于 24/7 監(jiān)控、警報和 DevOps 團隊從故障中恢復(fù)的資源，Kinesis 可能是一個不錯的選擇。

阿帕奇Kafka

Apache Kafka 是一個開源的 pub-sub 系統(tǒng)，已經(jīng)發(fā)展成為一個成熟的水平可擴展和容錯系統(tǒng)，用于高吞吐量數(shù)據(jù)重放和流。

• 設(shè)置/配置：優(yōu)化 Apache Kafka 的吞吐量和延遲需要同時調(diào)整生產(chǎn)者和消費者。服務(wù)器端配置——例如，復(fù)制因子和分區(qū)數(shù)——對于通過并行性實現(xiàn)最佳性能也至關(guān)重要。為了獲得高可用性，必須將 Kafka 配置為盡快從故障中恢復(fù)。

• 在 Kafka 中構(gòu)建 ETL 管道存在挑戰(zhàn)；除了數(shù)據(jù)轉(zhuǎn)換的基本任務(wù)外，還必須考慮事件流數(shù)據(jù)的獨特特征。

• 成本：Kafka 需要自己的集群。設(shè)置 Kafka 集群需要學(xué)習(xí)和分布式系統(tǒng)工程實踐以及集群管理、供應(yīng)、自動縮放、負載平衡、配置管理和重要的 DevOps 參與的能力。還需要大量節(jié)點（代理）、復(fù)制和分區(qū)以實現(xiàn)系統(tǒng)的容錯和高可用性。 
• 用于：實時數(shù)據(jù)處理；應(yīng)用程序活動跟蹤；日志記錄和/或監(jiān)控系統(tǒng)。

托管Kafka服務(wù)

Confluent KSQL和Amazon MSK（Kafka 托管流）都提供部署在云中的離散托管 Kafka 服務(wù)。 他們的目標(biāo)是利用 Kafka 的靈活性和近乎無處不在的特性，同時管理其內(nèi)在的大部分復(fù)雜性。   

Confluent Cloud是 Kafka 的完全托管云服務(wù)，可加速事件驅(qū)動服務(wù)和實時應(yīng)用程序的開發(fā)，而無需您管理 Kafka 集群。 

• 設(shè)置/配置：需要 Java 運行時環(huán)境和訪問 Kafka 集群以實時讀取和寫入數(shù)據(jù)。集群可以在本地或云端。需要為 ksqlDB 服務(wù)器和查詢設(shè)置配置參數(shù)，以及底層 Kafka 流和 Kafka 客戶端（生產(chǎn)者和消費者）。
• 成本：多種定價模型：每 Gb（數(shù)據(jù)輸入、數(shù)據(jù)輸出、數(shù)據(jù)存儲）；每小時計算；每小時分區(qū)。
• 用于：用于在云中托管 Kafka。也可用作消息代理，促進企業(yè)級系統(tǒng)之間的通信，并將每個系統(tǒng)生成的數(shù)據(jù)集成到中央位置，例如 Amazon S3。

Amazon MSK是一項完全托管的服務(wù)，可簡化使用 Apache Kafka 管理消息隊列和處理流數(shù)據(jù)的生產(chǎn)應(yīng)用程序的構(gòu)建和運行。  

• 設(shè)置/配置：MSK 簡化了設(shè)置和維護。設(shè)置和配置基于 Apache Kafka 的部署最佳實踐。自動配置并運行您的 Apache Kafka 集群。 
• 成本：基于使用情況。需要為代理實例的運行時間、每月使用的存儲空間以及集群內(nèi)外數(shù)據(jù)的標(biāo)準(zhǔn)數(shù)據(jù)傳輸費用付費。
• 用于：維護和擴展 Kafka 集群，啟用由完全托管服務(wù)支持的端到端攝取管道。還用作不同微服務(wù)之間的實時消息代理。

四 工具比較：批處理和實時 ETL 工具

在此類別中，可以選擇開源工具、托管服務(wù)或完全托管的自助服務(wù)引擎。

阿帕奇Spark

Spark是一種分布式通用集群計算框架。Spark 引擎在攝取數(shù)據(jù)時計算并優(yōu)化有向無環(huán)圖 (DAG)。（DAG 是一種單向前進的數(shù)據(jù)流，沒有循環(huán)）。Spark 的內(nèi)存數(shù)據(jù)處理引擎對動態(tài)或靜止數(shù)據(jù)執(zhí)行分析、ETL、機器學(xué)習(xí)和圖形處理。它為某些編程語言提供高級 API：Python、Java、Scala、R 和 SQL。

優(yōu)點：

• 具有大型企業(yè)應(yīng)用的成熟產(chǎn)品，已在許多用例的生產(chǎn)中得到驗證
• 隨時支持SQL查詢。

缺點：

• 實施和維護復(fù)雜且勞動密集
• 幾秒鐘的延遲，消除了一些實時分析用例

亞馬遜Glue

Amazon Glue 是一種完全托管的 ETL 和數(shù)據(jù)發(fā)現(xiàn)服務(wù)，構(gòu)建于 Apache Spark 之上。Glue 提供了一個無服務(wù)器環(huán)境，可以使用它自動配置的虛擬資源來運行 Spark ETL 作業(yè)。使用 Glue，可以針對 S3 執(zhí)行 ETL 作業(yè)以轉(zhuǎn)換流數(shù)據(jù)，包括各種轉(zhuǎn)換和轉(zhuǎn)換為 Apache Parquet。

優(yōu)點?

• 可以減少正在進行的集群管理的麻煩

缺點

• 仍在作為服務(wù)發(fā)展
• 限于 Spark 的批處理性質(zhì)，這會帶來一定的延遲和限制
• 必須在存儲層做很多優(yōu)化（例如在 S3 上壓縮小文件）以提高查詢性能 

阿帕奇Flink

還處理批任務(wù)的流處理框架。Flink 也是一個聲明式引擎。它將批處理視為具有有限邊界的數(shù)據(jù)流。數(shù)據(jù)通過源進入并通過匯離開。它基于流和轉(zhuǎn)換的概念。 

優(yōu)點：

• 流優(yōu)先方法提供低延遲、高吞吐量
• 真正的逐條處理
• 不需要對其處理的數(shù)據(jù)進行手動優(yōu)化和調(diào)整
• 動態(tài)分析和優(yōu)化任務(wù)

缺點：

• 一些縮放限制
• 比較新；與其他框架相比，生產(chǎn)中的部署更少

阿帕 Flume

用于聚合、收集和移動大量日志數(shù)據(jù)的可靠分布式服務(wù)。它具有靈活的基本架構(gòu)。從 Web 服務(wù)器捕獲流數(shù)據(jù)到 Hadoop 分布式文件系統(tǒng) (HDFS)。

優(yōu)點：

• 中央主服務(wù)器控制所有節(jié)點
• 容錯、故障轉(zhuǎn)移以及高級恢復(fù)和可靠性功能

缺點：

• 難以理解和配置復(fù)雜的邏輯/物理映射
• 占用空間大——>50,000 行 Java 代碼

阿帕奇Storm

Apache Storm 處理大量數(shù)據(jù)并以比許多其他解決方案更低的延遲提供結(jié)果。適用于近乎實時的處理工作負載。Storm 是一個組合引擎，開發(fā)者預(yù)先定義 DAG，然后處理數(shù)據(jù)。這可能會簡化代碼。但這也意味著開發(fā)人員必須仔細規(guī)劃他們的架構(gòu)以避免低效的處理。

Apache Storm 架構(gòu)建立在 spouts 和 bolts 之上。Spouts 是信息的來源。它們將信息傳輸?shù)揭粋€或多個螺栓。整個拓撲形成一個DAG。

優(yōu)點：

• 非常適合實時處理
• 使用微批次可以靈活地調(diào)整工具以適應(yīng)不同的用例
• 廣泛的語言支持

缺點：

• 可能會降低可靠性，因為它不能保證消息的順序
• 實施起來非常復(fù)雜

阿帕奇Samza

Samza 使用發(fā)布-訂閱模型來攝取數(shù)據(jù)流、處理消息并將結(jié)果輸出到另一個流。這是一個合成引擎。Samza 依賴于 Apache Kafka 消息系統(tǒng)、架構(gòu)，并保證提供緩沖、容錯和狀態(tài)存儲。

優(yōu)點：

• 提供復(fù)制存儲，以低延遲提供可靠的持久性
• 簡單且具有成本效益的多用戶模型
• 可以消除背壓，持久化數(shù)據(jù)供以后處理

缺點：

• 不支持非常低的延遲
• 僅支持 JVM 語言
• 不支持恰好一次語義

亞馬遜Kinesis Streams

由 AWS 作為托管服務(wù)提供的專有事件流工具。每秒從數(shù)十萬個來源收集千兆字節(jié)的數(shù)據(jù)。以毫秒為單位捕獲實時分析用例的數(shù)據(jù)。與 Kafka 的 pub-sub 模型非常相似，包括彈性縮放、持久性和低延遲消息傳輸（根據(jù)亞馬遜的說法，在 70 毫秒內(nèi)收集數(shù)據(jù)）。

優(yōu)點：

• 易于設(shè)置和維護的托管服務(wù)
• 與亞馬遜廣泛的大數(shù)據(jù)工具集集成

缺點：

• 商業(yè)云服務(wù)，每個分片按小時收費；處理大量數(shù)據(jù)時可能會很昂貴
• 需要犧牲一定程度的控制和定制，以換取易用性和減少對基礎(chǔ)設(shè)施的關(guān)注

五 工具比較——分析引擎

數(shù)據(jù)從業(yè)者使用越來越多的工具從存儲和流式數(shù)據(jù)中獲取洞察力和價值。這些工具反過來與商業(yè)智能應(yīng)用程序一起工作，以可視化和探索數(shù)據(jù)、數(shù)據(jù)建模和其他用于機器學(xué)習(xí)和人工智能的預(yù)測分析應(yīng)用程序。

今天使用的常見分析工具包括：

• 大數(shù)據(jù)查詢引擎：

• Amazon Athena
• Presto
• Trino / Starburst
• Redshift Spectrum
• Hive
• 其他

• 專用文本搜索引擎

• ElasticSearch

• Amazon OpenSearch

• Apache Solr (open source, based on the same library as ES, but much less prevalent)

• Kusto – managed MS offering

• 存儲層

• 數(shù)據(jù)倉庫

大數(shù)據(jù)查詢引擎

顧名思義，這些技術(shù)旨在或已經(jīng)發(fā)展為針對從 GB 到 PB 的各種規(guī)模的數(shù)據(jù)源運行交互式分析查詢。它們可以搜索任何形式的數(shù)據(jù)——結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化——并且可以運行許多同時查詢，如果可能的話實時。他們可以查詢存儲在任何地方的數(shù)據(jù)，而無需將數(shù)據(jù)移動到單獨的結(jié)構(gòu)化系統(tǒng)中，例如關(guān)系數(shù)據(jù)庫或數(shù)據(jù)倉庫。

亞馬遜Athena

Athena 是一個分布式查詢引擎，使用 S3 作為其底層存儲層。它的性能很大程度上取決于數(shù)據(jù)在 S3 中的組織方式，因為沒有數(shù)據(jù)庫可以代替 ETL 工具進行轉(zhuǎn)換。ETL 到 Athena 必須優(yōu)化 S3 存儲以實現(xiàn)快速查詢和處理有狀態(tài)操作。  

Athena 執(zhí)行全表掃描而不是使用索引。這意味著某些操作（例如大表之間的連接）可能會非常慢。

Presto

Presto（或 PrestoDB）是一個依賴于 Hive 元存儲的開源分布式 SQL 查詢引擎。它專為對任何數(shù)量的數(shù)據(jù)進行快速分析查詢而設(shè)計。它是亞馬遜基于 Athena 的基礎(chǔ)服務(wù)。與 Athena 一樣，您可以使用 Presto 查詢云對象存儲中的數(shù)據(jù)；您不必先將數(shù)據(jù)移動到單獨的分析系統(tǒng)中。查詢執(zhí)行在可擴展的純內(nèi)存架構(gòu)上并行運行。

Presto 具有通過其連接器直接連接 S3 之外的各種數(shù)據(jù)源的功能，包括 HDFS 數(shù)據(jù)塊和關(guān)系數(shù)據(jù)庫。

Trino / Starburst

Trino 是一種分布式 SQL 查詢引擎，旨在查詢分布在一個或多個異構(gòu)數(shù)據(jù)源上的大型數(shù)據(jù)集。Trino 最初名為 PrestoSQL，是原始 prestoDB 開源項目的一個分支。它由 Trino Software Foundation 的大型貢獻者和用戶社區(qū)維護。

Starburst 是 Presto 基金會管理委員會的成員，維護著一個名為 Starburst Enterprise 的企業(yè)級 Trino 商業(yè)發(fā)行版。Starburst Enterprise 包括額外的安全功能、更多連接器、基于成本的查詢優(yōu)化器、對運行額外部署平臺的支持等。它旨在幫助大公司安全地從他們的 Trino 部署中提取更多價值。

Redshift Spectrum

Redshift 是一個關(guān)系數(shù)據(jù)庫；Redshift Spectrum 是一個查詢引擎，駐留在專用的 Redshift 服務(wù)器上并訪問 S3 中的數(shù)據(jù)。

與 Athena 相比，Redshift 是：

• 快點
• 更健壯（具有額外的計算能力）
• 更貴
• 管理起來更復(fù)雜，需要大量的集群管理專業(yè)知識

亞馬遜向 Redshift 引入了 RA3 節(jié)點類型，以提高性能并增加存儲容量。Amazon 的 Redshift 高級查詢加速器 (AQUA) 位于 Amazon Redshift RA3 集群的計算和存儲之間，并與 Amazon Redshift RA3 實例一起運行。它不適用于數(shù)據(jù)湖。

Hive

Apache Hive 是一個開源數(shù)據(jù)倉庫應(yīng)用程序，用于讀取、寫入和管理大型數(shù)據(jù)集。它與 Apache Hadoop 分布式文件系統(tǒng) (HDFS) 或其他數(shù)據(jù)存儲系統(tǒng)（如 Apache HBase）配合使用。您通過命令行工具和 JDBC 驅(qū)動程序連接到 Hive。使用 Hive 的 SQL-like 接口查詢存儲在與 Hadoop 集成的各種數(shù)據(jù)庫和文件系統(tǒng)中的數(shù)據(jù)。

專用文本搜索引擎

顧名思義，專用文本（或全文）搜索引擎檢查文檔和數(shù)據(jù)庫記錄中的所有單詞。（元數(shù)據(jù)搜索方法僅分析文檔的描述。）它們承諾通過高級索引和基于相關(guān)性的更直觀的搜索結(jié)果快速檢索數(shù)據(jù)。

Elasticsearch

Elasticsearch 是一個基于 Lucene 的開源可伸縮搜索引擎。它通常用于日志搜索、日志分析以及 BI 和報告。您可以在任何地方運行它。  

將 Elasticsearch 包含在流式架構(gòu)中以明確查詢?nèi)罩疚募那闆r并不少見。為此，將所有原始數(shù)據(jù)存儲在數(shù)據(jù)湖中以供重放和臨時分析。然后對其進行去重，過濾掉不相關(guān)的事件，并將該子集發(fā)送到 Elasticsearch。

可以使用 Kafka Connect 將主題直接流式傳輸?shù)?Elasticsearch。 

將所有日志存儲在 Elasticsearch 中不需要自定義編碼。但由于 Elasticsearch 日志通常包含大量文本，因此相對較大，存儲成本高昂

亞馬遜OpenSearch

OpenSearch 項目由亞馬遜創(chuàng)建，是一個基于 Elasticsearch 和 Kibana 的分叉搜索項目。（亞馬遜沒有計劃 Elasticsearch 和 Kibana 的當(dāng)前或未來版本。）它與 Elasticsearch 相同，但隨著時間的推移會有所不同。

阿帕奇Solr

Apache Solr 是一個基于 Apache Lucene? 構(gòu)建的開源企業(yè)搜索平臺。它提供分布式索引、復(fù)制和負載平衡查詢、自動故障轉(zhuǎn)移和恢復(fù)以及集中配置。它被設(shè)計為可靠的、可擴展的和容錯的。  

Microsoft Azure 數(shù)據(jù)資源管理器

Azure 數(shù)據(jù)資源管理器是一項用于存儲和運行大量數(shù)據(jù)的交互式分析的服務(wù)。它基于 RDMS，支持?jǐn)?shù)據(jù)庫、表和列等實體。您可以通過 Kusto 查詢語言創(chuàng)建復(fù)雜的分析查詢。

Kusto 補充但不替代傳統(tǒng) RDBMS 系統(tǒng)，用于 OLTP 和數(shù)據(jù)倉庫等場景。它對所有形式的數(shù)據(jù)（結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化）表現(xiàn)同樣出色。Kusto 不執(zhí)行單個行和跨表約束或事務(wù)的就地更新。 

存儲層

與其他類型的流架構(gòu)組件一樣，存儲層也在不斷發(fā)展，充分利用它們的策略也在不斷發(fā)展通常，可以選擇文件存儲、對象存儲（數(shù)據(jù)湖，主要是mostly0 和數(shù)據(jù)倉庫）。

文件存儲——Hadoop 旨在處理大量數(shù)據(jù)。相對而言,對于中小型文件，它仍然足夠簡單和有效。但是元數(shù)據(jù)是有限的，并且只能通過整個文件進行搜索，因此隨著容量的增加，使用 HDFS 作為主要存儲層的成本、復(fù)雜性和延遲變得不合適。

對象存儲——通常是指數(shù)據(jù)湖，其中最突出的是 Amazon S3；微軟 Azure 數(shù)據(jù)湖和谷歌云存儲。文件位置被標(biāo)記，元數(shù)據(jù)是可靠的。因此縮放是無限的，搜索比文件存儲快得多。但數(shù)據(jù)必須經(jīng)過轉(zhuǎn)換和優(yōu)化才能使其可查詢。

數(shù)據(jù)倉庫——這些最適合結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)必須在存儲在倉庫中之前進行預(yù)處理（讀取模式）。倉庫可以提供簡單的數(shù)據(jù)訪問和快速查詢，但不能以經(jīng)濟高效的方式擴展，也不能很好地處理非結(jié)構(gòu)化數(shù)據(jù)。它們通常還需要一個封閉的架構(gòu)——也就是說，它們實際上只適用于各自供應(yīng)商的工具集。有許多可用的數(shù)據(jù)倉庫；最著名的是 Snowflake 和 Amazon Redshift。

六 流數(shù)據(jù)常見用例

流式數(shù)據(jù)處理使實時或近實時獲得可操作的洞察成為可能。特別適合流式傳輸?shù)挠美ǎ?/p>

• 欺詐檢測——將復(fù)雜的機器學(xué)習(xí)算法與實時交易分析相結(jié)合，以識別模式并實時檢測表明欺詐的異常情況。
• 網(wǎng)絡(luò)安全——數(shù)據(jù)流中的異常有助于數(shù)據(jù)安全從業(yè)者隔離或消除威脅，例如來自單個 IP 地址的可疑流量。
• 物聯(lián)網(wǎng)傳感器數(shù)據(jù)——實時計算數(shù)據(jù)流，例如監(jiān)控機械或環(huán)境條件或庫存水平并幾乎立即做出響應(yīng)。
• 在線廣告和營銷情報——跟蹤用戶行為、點擊次數(shù)和興趣，然后為每個用戶推廣個性化的贊助廣告。實時衡量觀眾對內(nèi)容的反應(yīng)，以快速、有針對性地決定為訪客和客戶提供哪些服務(wù)并吸引潛在客戶。
• 產(chǎn)品分析——跟蹤數(shù)字產(chǎn)品中的行為以了解功能使用、評估用戶體驗變化、增加使用并減少放棄。
• 日志分析——IT 部門可以將日志文件轉(zhuǎn)化為集中的易于使用的消息流，以從日志文件中提取意義；通常與可視化工具和開箱即用的過濾器結(jié)合使用。
• 云數(shù)據(jù)庫復(fù)制——使用變更數(shù)據(jù)捕獲 (CDC) 在云中維護事務(wù)數(shù)據(jù)庫的同步副本，以支持?jǐn)?shù)據(jù)科學(xué)家使用高級分析。

七 流處理常見陷阱

流處理是從海量數(shù)據(jù)流中獲取商業(yè)價值的最佳方法。但路徑不一定是直截了當(dāng)?shù)?。在設(shè)計流式傳輸架構(gòu)時，請牢記這些陷阱：

• Apache Spark 的復(fù)雜性
• 過度依賴數(shù)據(jù)庫
• 小文件的激增

Apache Spark 的復(fù)雜性

Spark 是一個強大的開源流處理器，并且被廣泛使用。但是，與 Hadoop 一樣，它是一個復(fù)雜的框架，需要大量的專業(yè)知識。 它功能強大且用途廣泛 – 但它不易使用、部署簡單或運行成本低廉。那是因為：

• 專為大數(shù)據(jù)和 Scala 工程師打造，而非分析團隊。在 Spark 中構(gòu)建數(shù)據(jù)轉(zhuǎn)換需要在 Scala 中進行冗長的編碼，并具備在對象存儲、分區(qū)和合并小文件方面實施數(shù)十種 Hadoop 最佳實踐的專業(yè)知識。
• 不是一個獨立的解決方案。Spark 只是更大的大數(shù)據(jù)框架的一部分。對于流處理、工作流編排和狀態(tài)管理，需要組裝相當(dāng)多的額外工具，每個工具都有自己的專業(yè)技能集，從而增加了更多的復(fù)雜性和成本。
• 需要很長時間才能實現(xiàn)價值。Spark 的大規(guī)模實施是一個復(fù)雜的編碼項目。隨著雇用或培訓(xùn)專家、定制開發(fā)和手動調(diào)整以優(yōu)化和擴展 Spark 所需的時間，從開始到生產(chǎn)需要幾個月或更長時間。
• 造成技術(shù)債務(wù)并扼殺敏捷性。對數(shù)據(jù)或分析要求的任何更改都需要一個編碼周期，包括回歸測試/QA。  
• 造成數(shù)據(jù)工程瓶頸。數(shù)據(jù)團隊必須實施任何需要新 ETL 流程或管道更改的新儀表板或報告。因此，每個變更請求都必須符合工程團隊的 Sprint 計劃。這可能會很痛苦，并最終會減少整個組織對數(shù)據(jù)的訪問。
• 是昂貴的。 的確，沒有直接的許可費用（盡管通過托管 Spark 服務(wù)可能會產(chǎn)生高昂的訂閱費用）。但是，將額外硬件的成本添加到專業(yè)知識的成本中，Apache 部署很容易超過大多數(shù)軟件許可的價格。當(dāng)使用高端開發(fā)人員進行普通的數(shù)據(jù)管道構(gòu)建和維護時，也會產(chǎn)生機會成本。

過度依賴數(shù)據(jù)庫

如果已經(jīng)在管理大量數(shù)據(jù)流，這可能是顯而易見的——但將流數(shù)據(jù)保存在關(guān)系數(shù)據(jù)庫中是站不住腳的：

• 事務(wù)數(shù)據(jù)庫必須保留用于操作。任何額外報告或處理都會妨礙表現(xiàn)。
• 基于事件的數(shù)據(jù)存儲為對象而不是表。但是關(guān)系數(shù)據(jù)庫是建立在表格存儲之上的；使用它們來存儲非結(jié)構(gòu)化數(shù)據(jù)需要冗長的清理和轉(zhuǎn)換過程，并在攝取時造成工程瓶頸。
• 存儲成本很容易使所有其他項目成本相形見絀，尤其是當(dāng)將大數(shù)據(jù)存儲在存儲和計算緊密耦合的數(shù)據(jù)庫中時。
• 操作型數(shù)據(jù)庫只包含相對較新的數(shù)據(jù)，而且通常只包含數(shù)據(jù)點的最新狀態(tài)。挖掘模式和趨勢或跟蹤數(shù)據(jù)沿襲以從錯誤中恢復(fù)是非常具有挑戰(zhàn)性的。
• 流數(shù)據(jù)的價值通過探索技術(shù)、預(yù)測建模和機器學(xué)習(xí)得到釋放。與傳統(tǒng)數(shù)據(jù)庫相比，這些分析需要更廣泛、更靈活的數(shù)據(jù)訪問。

小文件的激增

將小文件寫入對象存儲非常簡單。但無論是在云端還是本地使用 Hadoop 或 Spark，小文件都會破壞性能。打開每個文件、讀取元數(shù)據(jù)和關(guān)閉文件都需要幾毫秒的時間，這在處理數(shù)百萬個文件時變得有意義。此外，許多文件會導(dǎo)致許多不連續(xù)的磁盤尋道，而對象存儲并未為此進行優(yōu)化。

為了緩解這種情況，請在數(shù)據(jù)架構(gòu)中使用壓縮——定期將較小的事件文件合并到較大的檔案中——以提高查詢性能。最好的方法是：

• 地定義壓縮窗口。過于頻繁地壓縮是一種浪費，因為文件仍然非常小，任何性能改進都是微不足道的。當(dāng)系統(tǒng)等待壓縮作業(yè)完成時，壓縮太少會導(dǎo)致處理時間過長和查詢速度變慢。
• 刪除未壓縮的字段以節(jié)省空間和存儲成本。當(dāng)然，始終保留原始狀態(tài)的數(shù)據(jù)副本以用于重放和事件溯源。
• 壓縮完成后重新配置 Athena 表分區(qū)，這樣 Athena 將讀取壓縮后的分區(qū)而不是原始文件。
• 保持文件大小盡可能大，但仍然足夠小以適應(yīng)未壓縮的內(nèi)存。

同時，遵循一些最佳實踐可以確保在構(gòu)建流式架構(gòu)時更快地獲得更多價值。

八 綜述

隨著流數(shù)據(jù)的規(guī)模持續(xù)增長，組織可以通過構(gòu)建或升級數(shù)據(jù)架構(gòu)來保持競爭力，使他們能夠?qū)崟r或接近實時地處理和分析數(shù)據(jù)。該過程的每個步驟都有多種方法、技術(shù)和工具。通過采用有限數(shù)量的最佳實踐并堅持開放數(shù)據(jù)架構(gòu)以最大限度地增加選擇，數(shù)據(jù)堆棧不僅具有成本效益，而且在可預(yù)見的未來具有足夠的靈活性和可擴展性。