揭秘 IFTTT 每天處理幾十億事件數據的基礎結構

數據對于IFTTT至關重要。我們的 BD 和營銷團隊依靠數據來做出關鍵的業務決策。產品團隊依靠數據來測試來了解用戶是如何時候我的產品的，以做產品決策。數據團隊本身依靠數據建立產品，比如 Recipe推薦系統和垃圾郵件檢測工具。此外，我們的合作伙伴依靠數據來實時獲取Channels的性能。

因為數據對于IFTTT如此關鍵，并且我們的服務每天處理幾十億事件，所以我們的數據基礎設施必須具有高可擴展性、可用性的和彈性，以便跟上產品的快速迭代。在這篇文章中我們將帶你瀏覽數據基礎設施和架構，也會分享一些我們在構建和操作數據的收獲。

數據來源

在IFTTT有三種數據來源，對于理解用戶的行為和Channels的效率至關重要。

第一，在 AWS RDS 有一個 MySQL 集群，用來維護應用的基本內容的當前狀態，比如用戶、Channels和Recipes，包括他們的關系。IFTTT.com 和移動應用靠 Rails 應用支撐。獲得數據并導出到S3，每天用AWS Data Pipline導入到Redshift。

接下來，像用戶與 IFTTT 產品的交互數據，我們從Rails應用里收集事件數據到Kafka集群。

最后，為了幫助監控數以千計的合作伙伴 API 的行為（behavior），我們收集在運行 Recipes 時 workers 產生的 API 請求的信息，包括響應時間和HTTP狀態碼，都導入到Kafka集群。

IFTTT 的 Kafka

我們使用Kafka做數據傳輸層，實現數據生產者和消費者之間的解耦。這種架構中，Kafka在系統中作為生產者和消費者之間的一種抽象層，而不是數據直接推向消費者。生產者將數據推送到Kafka，消費者從Kafka中讀數據。這使得添加新數據消費者更松散。

因為Kafka作為基于日志的事件流，因為消費者跟蹤他們自己在事件流中的位置。這使消費者數據能在兩種模式中切換：實時和批量。它還允許消費者數據進行重新處理他們以前所消耗的數據，如果在產生了錯誤的情況下數據需要重新處理，這將很有幫助。

一旦數據在Kafka中，我們將它用在各種位置。批量數據的消費者每小時將數據的一個副本分批放到 S3。實時數據的消費者將數據發到 Elasticsearch 集群，用的 library 我們希望能盡快開源。

商業智能

用Cranium（內部ETL平臺）將S3中數據變換和歸一化后導入到AWS Redshift。Cranium使我們能夠用SQL和Ruby編寫ETL 任務（job），它定義了這些任務之間的依賴和安排他們執行。Cranium支持數據可視化報告（利用Ruby和D3），但是大多數數據可視化是用 Chartio。我們發現對于SQL經驗有限的人來說Chartio非常直觀。

無論是工程中還是業務中甚至是社區中人們都可以利用這些數據來解決問題，發現新的點。

用 Chartio 做數據可視化

機器學習

我們采用一些先進的機器學習技術來確保IFTTT用戶有良好的體驗。對于Recipe的推薦和濫用檢測，我們用在EC2上的運行Apache Spark，用S3作數據存儲。更多的內容我們將在之后的博文中解釋。

實時監控和報警

API 事件存儲在 Elasticsearch 中，來進行實時監控和報警。我們使用Kibana來可視化worker進程的實時性能和合作伙伴的API性能。

IFTTT的合作伙伴訪問Developer Channel（當他們的API有問題時觸發這個Channel）。他們可以用Developer Channel 創建Recipes，可選擇不同的方式（SMS，Email，Slack，等）來通知合作伙伴們。

在開發者dashboard，合作伙伴可以訪問實時日志和可視化他們的Channel健康狀況。 用Elasticsearch來實現比較好 。此外，提供給開發者強大的分析能力幫開發者們了解 誰在使用他們的Channel以及如何使用的。

經驗

我們從開發數據基礎設施主中總結出一些經驗：

• 通過使用像Kafka這樣的數據傳輸層將生產者和消費者分離，使得數據管道更有彈性。比如，幾個慢點消費者不會影響其他消費者或生產者的性能。
• 從一天開始就以集群的模式啟動，這使得你可以很容易地擴展。但是在擴展集群前要確定性能瓶頸是什么。比如，在 Elasticsearch 中如果shard非常大，添加更多節點并不會幫助提高查詢速度。你不得不減少shard。
• 在復雜系統中，要在一些地方給適當的報警，確保一切正常。我們用Sematext來監控Kafka集群和消費者們。我們也用Pingdom來監控，用Pagerduty來報警。
• 為了能充分信任你的數據，自動驗證數據是非常重要的。比如我們開發了一個服務，來比較生產中的表和Redshift中的表，如果有異常將報警。
• 使用基于日期的文件夾結構 (YYYY/MM/DD)來將 event 數據持久化存儲（我們例子中的S3）。這方式存儲易于處理。比如如果你想讀某一天的數據，你只需要從一個目錄中讀取數據。
• 與上面類似的是，在Elasticsearch中創建基于時間的索引（例如：每小時）。如果在Elasticsearch中查詢最后一小時所有API錯誤，那么利用簡單的索引就可以做到，提高效率。
• 要批量提交event（基于時間段或者大量事件）到Elasticsearch，而不是提交獨立的event。這有助于限制IO。
• 根據運行的數據和查詢的類型，來優化 Elasticsearch 的節點數、shard數、shard 和 replication factor 的最大值等參數。