🥇服務器分析系統

這是有關分析系統的系列文章的第二部分（鏈接到第 1 部分).

如今，毫無疑問，仔細的數據處理和結果解釋幾乎可以幫助任何類型的業務。在這方面，分析系統加載的參數越來越多，應用程序中觸發器和用戶事件的數量也在不斷增長。
正因為如此，公司正在向分析師提供越來越多的“原始”信息來分析並將其轉化為正確的決策。分析系統對公司的重要性不應該被低估，系統本身應該是可靠和可持續的。

客戶分析師

客戶分析是公司通過官方 SDK 連接其網站或應用程序、將其集成到自己的代碼庫中並選擇事件觸發器的服務。這種方法有一個明顯的缺點：由於任何所選服務的限制，所有收集的數據都無法按照您想要的方式進行處理。例如，在一個系統上運行 MapReduce 任務並不容易，而在另一系統上您將無法運行模型。另一個缺點是定期（令人印象深刻）的服務賬單。
市場上有許多客戶分析解決方案，但分析師遲早會面臨這樣一個事實：沒有一種通用服務適合每項任務（而所有這些服務的價格一直在上漲）。在這種情況下，公司通常決定創建自己的分析系統，並具有所有必要的自定義設置和功能。

服務器分析師

服務器端分析是一種可以在公司自己的服務器上（通常）內部部署的服務。在該模型中，所有用戶事件都存儲在內部服務器上，允許開發人員嘗試不同的數據庫進行存儲並選擇最方便的架構。即使您仍然想使用第三方客戶端分析來執行某些任務，這仍然是可能的。
服務器端分析可以通過兩種方式部署。首先：選擇一些開源實用程序，將它們部署在您的計算機上並開發業務邏輯。

優點
缺點

你可以定制任何東西
通常這非常困難並且需要單獨的開發人員

第二：採用 SaaS 服務（Amazon、Google、Azure），而不是自己部署。我們將在第三部分更詳細地討論 SaaS。

優點
缺點

中等數量時可能會更便宜，但大幅增加時仍然會變得太貴
無法控制所有參數

管理工作完全轉移到服務提供商的肩上
並不總是知道服務內部有什麼（可能不需要）

如何收集服務器分析

如果我們想擺脫使用客戶分析並構建自己的客戶分析，首先我們需要考慮新系統的架構。下面我將逐步告訴您需要考慮什麼、為什麼需要每個步驟以及可以使用哪些工具。

1. 數據採集

就像客戶分析一樣，首先，公司分析師選擇他們想要進一步研究的事件類型並將其收集在列表中。通常，這些事件按一定順序發生，稱為“事件方案”。
此外，我們假設一個移動應用程序（網站）擁有常規用戶（設備）和許多服務器。為了安全地將事件從設備傳輸到服務器，需要中間層。根據架構的不同，可能會出現多個不同的事件隊列。
阿帕奇卡夫卡 - 發布/訂閱隊列，用作收集事件的隊列。

根據在 Quora 上發帖 2014 年，Apache Kafka 的創建者決定以 Franz Kafka 的名字命名該軟件，因為“這是一個寫入優化的系統”，並且因為他喜歡 Kafka 的著作。 — 維基百科

在我們的示例中，有許多數據生產者及其消費者（設備和服務器），Kafka 幫助將它們相互連接。消費者將在接下來的步驟中被更詳細地描述，他們將是主要參與者。現在我們將只考慮數據生產者（事件）。
Kafka 封裝了隊列和分區的概念，更具體的內容最好閱讀其他地方（例如，在文件）。無需贅述，讓我們假設為兩個不同的操作系統啟動了一個移動應用程序。然後每個版本都會創建自己單獨的事件流。生產者將事件發送到 Kafka，它們被記錄在合適的隊列中。

（圖片故)

同時，Kafka 允許您分塊讀取並以小批量處理事件流。 Kafka 是一個非常方便的工具，可以根據不斷增長的需求（例如，通過事件的地理位置）進行很好的擴展。
通常一個分片就足夠了，但在擴展時（一如既往），通信會變得更加複雜。可能沒有人願意在生產中只使用一個物理分片，因為架構必須是容錯的。除了Kafka之外，還有另一個著名的解決方案——RabbitMQ。我們沒有在生產中將其用作事件分析隊列（如果您有此類經驗，請在評論中告訴我們！）。但是，使用了 AWS Kinesis。

在繼續下一步之前，需要提到系統的另一個附加層 - 原始日誌的存儲。這不是一個強制層，但如果出現問題並且 Kafka 中的事件隊列重置為零，它將很有用。存儲原始日誌不需要復雜且昂貴的解決方案，您可以簡單地將它們以正確的順序寫入某處（甚至寫入硬盤）。

2. 處理事件流

在我們準備好所有事件並將它們放入適當的隊列中之後，我們繼續進行處理步驟。在這裡我將討論兩種最常見的處理選項。
第一個選項是在 Apache 系統上啟用 Spark Streaming。所有 Apache 產品都運行在 HDFS（一個安全的副本文件系統）上。 Spark Streaming 是一個易於使用的工具，可以處理流數據並具有良好的擴展性。然而，它可能很難維護。
另一種選擇是構建您自己的事件處理程序。例如，要執行此操作，您需要編寫一個 Python 應用程序，在 docker 中構建它，並訂閱 Kafka 的隊列。當觸發器到達 docker 中的處理程序時，處理就會開始。使用這種方法，您需要保持不斷運行的應用程序。
假設我們已經選擇了上述選項之一併繼續進行處理本身。處理器應該首先檢查數據的有效性，過濾掉垃圾和“損壞”事件。為了驗證我們通常使用地獄犬。之後，可以進行數據映射：對來自不同來源的數據進行規範化和標準化，以便將其添加到公共表中。

3. 數據庫

第三步是保存標準化事件。在使用現成的分析系統時，我們經常需要訪問它們，因此選擇一個方便的數據庫非常重要。
如果數據非常適合固定模式，您可以選擇點擊屋或其他一些列數據庫。所以聚合會很快起作用。缺點是該方案是嚴格固定的，因此無法在未經細化的情況下添加任意對象（例如，當發生非標準事件時）。但它可以很快完成。
對於非結構化數據，可以採用NoSQL，例如： Apache Cassandra。它在 HDFS 上運行，複製良好，可以啟動許多實例，並且具有容錯能力。
您可以提出一些更簡單的問題，例如， MongoDB的。即使對於小體積，它也相當慢。但優點是它非常簡單，因此適合入門。

4. 聚合

仔細保存所有事件後，我們希望從批次中收集所有重要信息並更新數據庫。在全球範圍內，我們需要相關的儀表板和指標。例如，從事件中收集用戶個人資料並以某種方式衡量行為。事件被聚合、收集並再次保存（已經在用戶表中）。同時，可以通過將過濾器連接到協調聚合器的方式來構建系統：僅從某種類型的事件中收集用戶。
之後，如果團隊中有人只需要高級分析，您可以連接外部分析系統。您可以再次使用 Mixpanel。但由於它相當昂貴，因此並非所有用戶事件都發送到那裡，而是僅發送需要的事件。為此，我們需要創建一個協調器，將一些原始事件或我們自己之前聚合的內容傳輸到外部系統、API 或廣告平台。

5. 前端

您需要將前端連接到創建的系統。一個很好的例子就是服務。紅達什，是一個幫助構建面板的數據庫 GUI。交互如何進行：

用戶進行 SQL 查詢。
作為回應，他收到了一個信號。
為其創建一個“新的可視化”並獲得一個漂亮的圖表，您可以自己保存它。

服務中的可視化效果會自動更新，您可以配置和跟踪您的監控。如果是自託管，Redash 是免費的，但如果是 SaaS，則每月費用為 50 美元。

結論

完成上述所有步驟後，您將創建服務器端分析。請注意，這並不像連接客戶端分析那麼簡單，因為一切都需要您自己配置。因此，在創建自己的系統之前，值得將嚴肅的分析系統的需求與您準備分配給它的資源進行比較。
如果您進行了所有計算並發現成本太高，那麼在下一部分中我將討論如何製作更便宜的後端分析版本。

謝謝閱讀！我很樂意回答評論中的問題。

來源： www.habr.com

服務器分析系統