事件分析策略

概述

所以你想做事件分析嗎？太棒了！這份文件提供了一些你應該知道的基本事項。以下是一些章節供你閱讀

• 實作事件分析的通用策略。描述了三個需要考量的高階選項。

• 事件分析管線的結構及其運作方式。這將幫助你在整個過程中做出更好的決策。

• 實用建議。如何避免麻煩，並從許多在你之前嘗試過這些事情的人的錯誤中獲益。

事件分析策略

團隊選擇哪個選項很大程度上取決於他們的需求，但大多數人傾向於隨著產品和業務規模的擴大而逐步採用這些選項。

• 使用端到端 SAAS 分析供應商。當你無法承擔自行管理任何事件分析管線的成本，或者你只是不想這麼做時，你會選擇這個選項。

  • 優點

    • 完全無需人工干預，且無需基礎架構

    • 最快完成部署的選項

    • 解決方案通常針對事件分析工作負載進行了最佳化

  • 缺點

    • 專有解決方案，無法控制功能

    • 資料是孤立的，無法與應用程式中的任何其他資料合併

    • 在較高資料量下通常會變得相當昂貴

    • 在大多數情況下，你不會擁有你的資料，如果你決定要對其進行更多操作，也無法完全取回資料

  • 範例解決方案

    • Google Analytics

    • Mixpanel

    • Keen IO

• 由託管服務建立的自訂管線。這是中間路線。你可以取回一些關鍵的控制元素，但需要付出更多努力。

  • 優點

    • 你擁有管線中的所有資料，讓你有機會決定以任何你想要的方式使用它

    • 你將能夠將各種資料來源結合在一起，實現原本不可能的分析

    • 資料隱私和安全性更牢固地掌握在你手中

  • 缺點

    • 你正在承擔收集和儲存資料的責任，因此你需要準備好擁有這個解決方案

    • 通常你需要建立和維護一些程式碼，以處理提取和轉換收集到的資料以供使用

  • 範例解決方案

    • AWS Mobile Events + S3 + Redshift + BI

    • AWS Kinesis + S3 + DWH + BI

    • Kafka + S3 + DWH + BI

    • Kafka + Storm + BI (即時)

    • Segment.io + S3 或 Redshift + BI

• 完全自訂管線。這是一個完全構建的、不受限制的管線，通常包含高度客製化的組件。

  • 優點

    • 完全控制管線的每個步驟，確保你有能力解決任何你需要解決的問題

    • 你可以根據自己的特定需求進行最佳化，而不是依賴更通用的解決方案

    • 你所有的資料都可以根據需要移動和整合，因此任何分析都是可能的

  • 缺點

    • 這是成本最高的選項，肯定需要專門的人力來執行

    • 建立完整的資料管線需要時間，通常需要數月或數年

  • 範例解決方案

    • 你在這裡是孤軍奮戰，這不就是你想要的嗎？

分析管線的結構

資料管線有很多種形式和規模，但在大多數情況下，以下步驟代表了一個討論管線中各部分的堅實框架。

• 產生 - 這是資料產生的地方和方式。可能來自行動應用程式、瀏覽器中的使用者、後端伺服器等等。在大多數情況下，你要么自己編寫程式碼，要么使用第三方 SDK，例如 GA、Segment.io、Mixpanel 等。

• 收集 - 資料產生後，通常需要將其發送到某個地方並儲存以供下游使用。在大多數情況下，這是一種基於 HTTP 的 API。重要的是要記住，資料通常只收集一次，但旨在多次使用，因此在此處設計發布/訂閱模型以允許多個訂閱者使用相同的資料是有意義的。

• 處理 - 資料收集後，通常會經過一個或多個轉換，以準備供使用。此步驟通常是高度客製化的，並且很大程度上取決於資料的產生和收集方式，以及可用的資料倉儲。這是你的 ETL，它實際上是你管線中的黏合劑。

• 資料倉儲 - 指的是資料如何儲存並提供分析。這可以簡單到 CSV 檔案，也可以複雜到擁有 2,000 多個節點的 Hadoop 集群。選擇資料倉儲的主要因素是資料量和分析需求。

• 分析 - 從資料倉儲中提取資料並將其格式化以供主動使用（通常是人類）的一組工具和流程。這是你的 BI 工具和自訂儀表板的重點所在。如果你有 ML 專業，那麼你也會在這裡使用建模軟體。

實用建議

一般想法

• 在升級到更複雜的方法之前，盡可能地使用每個解決方案。

• 不要低估運行自己的管線所涉及的工作。資料管線不是一個設置好就可以自行運行的系統；它需要定期維護和照顧。

• 管線各部分的總體難度/時間成本往往是

  • 產生 = 簡單

  • 擷取 = 中等 -> 簡單 (隨著你越來越熟練)

  • 處理 = 困難 -> 中等 (隨著你越來越熟練)

  • 資料倉儲 = 困難 -> 中等 (隨著你越來越熟練)

  • 分析 = 中等

當選擇端到端 SAAS 服務時

• 通常你需要編寫一些程式碼來實作第三方 SDK，並將資料產生程式碼整合到你的應用程式中。根據你想要追蹤的內容，這可能非常容易（例如網站上的 GA），或者可能更複雜一些。

• 客戶/用戶/使用者將資料發送到第三方，因此至少需要考慮一些法律和隱私影響。在大多數情況下，這不是大問題，但值得思考。

• 你將通過供應商創建的專有工具集訪問你的資料，這可能好壞參半。在大多數情況下，你會在你能做的事情方面遇到障礙，並且你只能接受它們，因為你無法更改任何內容。

當你計劃啟動自己的管線時

• 請記住，要執行此操作，你必須運行一些基礎架構，即使它是託管服務（例如在 AWS 上），因此請確保你具備一些基本技術運營能力。

• 很容易認為你需要一位資料工程師來執行此分析策略，但如果你保持簡單，則不需要。沒有理由倉促聘請資料工程師。

• 首先專注於建立穩定且穩健的資料收集模式，因為「實際上」一切都由此而來。一旦你有了穩固的資料收集基礎，你就可以在其上構建很多東西。這裡的首選是 AWS Kinesis 和 Kafka。

• 你的資料倉儲選擇主要取決於資料量。對於小資料量，請堅持使用最簡單的工具，例如開源 SQL 資料庫。當你超出這個範圍時，你將會考慮分析型 DWH，其中有很多選擇：AWS Redshift、Vertica、ParAccel 和 Terradata 是其中的知名品牌。還有更新的工具，例如 Spark、Presto、Impala 和 Druid。

• 每個人都希望他們的資料管線是即時的（意味著資料可以立即用於分析），但執行起來肯定需要更多工作，因此請盡早決定這是否對你來說值得。要做到這一點，通常你需要專門的工具和不同的管線配置，因此請考慮到這一點。

靈感來源

• 完全託管的分析管線