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

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

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

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

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

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

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

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

從廣義上講，它由四個(gè)部分組成：

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

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

流處理器/消息代理 

流處理器從其來源收集數(shù)據(jù)，將其轉(zhuǎn)換為標(biāo)準(zhǔn)消息格式，然后連續(xù)流式傳輸以供其他組件使用。（此類組件可以是存儲(chǔ)組件，例如數(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

流處理工具

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

例子：

• 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)換可能會(huì)直接發(fā)生在數(shù)據(jù)流入和存儲(chǔ)在數(shù)據(jù)湖或其他存儲(chǔ)庫之前，或者在數(shù)據(jù)被攝取和存儲(chǔ)之后。

查詢引擎

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

示例（并非詳盡無遺）：

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

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

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

例子：

• 亞馬遜 S3
• 微軟 Azure 存儲(chǔ)
• 谷歌云存儲(chǔ)

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

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

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

部署讀取模式模型

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

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

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

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

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

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

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

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

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

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

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

保持架構(gòu)開放

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

要?jiǎng)?chuàng)建一個(gè)開放式架構(gòu)：

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

優(yōu)化查詢性能

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

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

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

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

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

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

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

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

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

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

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

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

亞馬遜Kinesis

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

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

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

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

阿帕奇Kafka

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

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

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

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

托管Kafka服務(wù)

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

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

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

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

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

四 工具比較：批處理和實(shí)時(shí) ETL 工具

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

阿帕奇Spark

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

亞馬遜Glue

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

優(yōu)點(diǎn)?

• 可以減少正在進(jìn)行的集群管理的麻煩

缺點(diǎn)

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

阿帕奇Flink

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

阿帕 Flume

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

阿帕奇Storm

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

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

• 可能會(huì)降低可靠性，因?yàn)樗荒鼙ＷC消息的順序
• 實(shí)施起來非常復(fù)雜

阿帕奇Samza

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

亞馬遜Kinesis Streams

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

五 工具比較——分析引擎

數(shù)據(jù)從業(yè)者使用越來越多的工具從存儲(chǔ)和流式數(shù)據(jù)中獲取洞察力和價(jià)值。這些工具反過來與商業(yè)智能應(yīng)用程序一起工作，以可視化和探索數(shù)據(jù)、數(shù)據(jù)建模和其他用于機(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

• 存儲(chǔ)層

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

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

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

亞馬遜Athena

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

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

Presto

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

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

Trino / Starburst

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

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

Redshift Spectrum

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

與 Athena 相比，Redshift 是：

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

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

Hive

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

專用文本搜索引擎

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

Elasticsearch

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

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

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

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

亞馬遜OpenSearch

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

阿帕奇Solr

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

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

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

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

存儲(chǔ)層

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

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

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

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

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

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

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

七 流處理常見陷阱

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

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

Apache Spark 的復(fù)雜性

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

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

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

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

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

小文件的激增

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

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

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

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

八 綜述

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