一 為什么要使用流數據架構

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

傳統的批處理架構可以滿足較小規模的需求。但流媒體資源——傳感器、服務器和安全日志、實時廣告、來自應用程序和網站的點擊流數據等等——每秒可以生成多達 1 Gb 的事件。流式數據架構在生成數據時使用這些數據，并準備好進行分析。考慮到數據流的獨特特征，后者尤其重要——通常是非結構化或半結構化數據，在進行任何認真的分析之前必須對其進行處理、解析和結構化。

流式架構提供了批處理管道無法提供的多項優勢：

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

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

二 流式架構的組件

流數據架構是一個軟件組件框架，用于從多個來源攝取和處理大量原始數據流。 

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

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

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

流處理器/消息代理 

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

作為數據管道的流處理器

例子：

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

流處理工具

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

例子：

• 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

請注意，根據您的需求和您創建的架構，數據轉換可能會直接發生在數據流入和存儲在數據湖或其他存儲庫之前，或者在數據被攝取和存儲之后。

查詢引擎

數據現在已準備好進行分析。工具和技術差異很大，具體取決于用例。 

示例（并非詳盡無遺）：

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

流式數據存儲

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

例子：

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

三 流式架構最佳實踐

在構建流架構時，請牢記這些技術：

• 部署讀取模式模型
• 分離實時和歷史數據
• 維護所有傳入事件的不可變日志
• 分層數據湖
• 保持架構開放
• 優化查詢性能

部署讀取模式模型

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

 將用于實時分析的數據與歷史數據分開

優化用于實時或近實時分析的數據以確保快速讀取。以原始形式保留歷史數據以供臨時查詢使用，用于：

• “回放”過去的事態
• 錯誤恢復
• 追蹤數據沿襲
• 探索性分析

維護所有傳入事件的不可變日志

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

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

為了降低成本，將日志存儲在對象存儲中。當收到分析師或研究人員的請求時，創建一個 ETL 作業以將數據從不可變日志流式傳輸到分析平臺，并從那里回放。 

根據用戶的技能對數據湖進行分層

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

針對不同用戶組配置的云數據湖

保持架構開放

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

要創建一個開放式架構：

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

優化查詢性能

以下最佳實踐可提高大多數業務案例的查詢性能：

• 適當地分區數據以供您使用
• 轉換為高效的列式文件格式
• 經常壓縮（合并）小文件

分區數據

如何對數據進行分區對查詢成本和速度有重大影響。查詢運行更高效、成本更低，因為適當的分區限制了Amazon Athena 等查詢引擎為回答特定分析問題而必須掃描的數據量。

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

轉換為高效的列式文件格式

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

經常壓縮以解決“小文件問題”

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

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

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

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

亞馬遜Kinesis

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

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

• 所需吞吐量所需的分片（分區）數量 每個分片本質上是一個包含數據子集的單獨流；Kinesis 每個流有多個分片）。
• 生產者傳輸到數據流的數據量，因此對于大量數據，成本可能很高。

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

阿帕奇Kafka

Apache Kafka 是一個開源的 pub-sub 系統，已經發展成為一個成熟的水平可擴展和容錯系統，用于高吞吐量數據重放和流。

• 設置/配置：優化 Apache Kafka 的吞吐量和延遲需要同時調整生產者和消費者。服務器端配置——例如，復制因子和分區數——對于通過并行性實現最佳性能也至關重要。為了獲得高可用性，必須將 Kafka 配置為盡快從故障中恢復。

• 在 Kafka 中構建 ETL 管道存在挑戰；除了數據轉換的基本任務外，還必須考慮事件流數據的獨特特征。

• 成本：Kafka 需要自己的集群。設置 Kafka 集群需要學習和分布式系統工程實踐以及集群管理、供應、自動縮放、負載平衡、配置管理和重要的 DevOps 參與的能力。還需要大量節點（代理）、復制和分區以實現系統的容錯和高可用性。 
• 用于：實時數據處理；應用程序活動跟蹤；日志記錄和/或監控系統。

托管Kafka服務

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

Confluent Cloud是 Kafka 的完全托管云服務，可加速事件驅動服務和實時應用程序的開發，而無需您管理 Kafka 集群。 

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

Amazon MSK是一項完全托管的服務，可簡化使用 Apache Kafka 管理消息隊列和處理流數據的生產應用程序的構建和運行。  

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

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

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

阿帕奇Spark

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

優點：

• 具有大型企業應用的成熟產品，已在許多用例的生產中得到驗證
• 隨時支持SQL查詢。

缺點：

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

亞馬遜Glue

Amazon Glue 是一種完全托管的 ETL 和數據發現服務，構建于 Apache Spark 之上。Glue 提供了一個無服務器環境，可以使用它自動配置的虛擬資源來運行 Spark ETL 作業。使用 Glue，可以針對 S3 執行 ETL 作業以轉換流數據，包括各種轉換和轉換為 Apache Parquet。

優點?

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

缺點

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

阿帕奇Flink

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

優點：

• 流優先方法提供低延遲、高吞吐量
• 真正的逐條處理
• 不需要對其處理的數據進行手動優化和調整
• 動態分析和優化任務

缺點：

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

阿帕 Flume

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

優點：

• 中央主服務器控制所有節點
• 容錯、故障轉移以及高級恢復和可靠性功能

缺點：

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

阿帕奇Storm

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

Apache Storm 架構建立在 spouts 和 bolts 之上。Spouts 是信息的來源。它們將信息傳輸到一個或多個螺栓。整個拓撲形成一個DAG。

優點：

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

缺點：

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

阿帕奇Samza

Samza 使用發布-訂閱模型來攝取數據流、處理消息并將結果輸出到另一個流。這是一個合成引擎。Samza 依賴于 Apache Kafka 消息系統、架構，并保證提供緩沖、容錯和狀態存儲。

優點：

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

缺點：

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

亞馬遜Kinesis Streams

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

優點：

• 易于設置和維護的托管服務
• 與亞馬遜廣泛的大數據工具集集成

缺點：

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

五 工具比較——分析引擎

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

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

• 大數據查詢引擎：

• 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

• 存儲層

• 數據倉庫

大數據查詢引擎

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

亞馬遜Athena

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

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

Presto

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

Presto 具有通過其連接器直接連接 S3 之外的各種數據源的功能，包括 HDFS 數據塊和關系數據庫。

Trino / Starburst

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

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

Redshift Spectrum

Redshift 是一個關系數據庫；Redshift Spectrum 是一個查詢引擎，駐留在專用的 Redshift 服務器上并訪問 S3 中的數據。

與 Athena 相比，Redshift 是：

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

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

Hive

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

專用文本搜索引擎

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

Elasticsearch

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

將 Elasticsearch 包含在流式架構中以明確查詢日志文件的情況并不少見。為此，將所有原始數據存儲在數據湖中以供重放和臨時分析。然后對其進行去重，過濾掉不相關的事件，并將該子集發送到 Elasticsearch。

可以使用 Kafka Connect 將主題直接流式傳輸到 Elasticsearch。 

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

亞馬遜OpenSearch

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

阿帕奇Solr

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

Microsoft Azure 數據資源管理器

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

Kusto 補充但不替代傳統 RDBMS 系統，用于 OLTP 和數據倉庫等場景。它對所有形式的數據（結構化、半結構化和非結構化）表現同樣出色。Kusto 不執行單個行和跨表約束或事務的就地更新。 

存儲層

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

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

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

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

六 流數據常見用例

流式數據處理使實時或近實時獲得可操作的洞察成為可能。特別適合流式傳輸的用例包括：

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

七 流處理常見陷阱

流處理是從海量數據流中獲取商業價值的最佳方法。但路徑不一定是直截了當的。在設計流式傳輸架構時，請牢記這些陷阱：

• Apache Spark 的復雜性
• 過度依賴數據庫
• 小文件的激增

Apache Spark 的復雜性

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

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

過度依賴數據庫

如果已經在管理大量數據流，這可能是顯而易見的——但將流數據保存在關系數據庫中是站不住腳的：

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

小文件的激增

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

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

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

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

八 綜述

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