解密IFTTT的數據架構
隨著信息技術的發展，人們在日常生活和工作中都不可避免的要用到郵箱、聊天工具、云存儲等網絡服務。然而，這些服務很多時候都是單獨運行的，不能很好的實 現資源共享。針對該問題，IFTTT提出了“讓互聯網為你服務”的概念，利用各網站和應用的開放API，實現了不同服務間的信息關聯。例如，IFTTT可 以把指定號碼發送的短信自動轉發郵箱等。為了實現這些功能，IFTTT搭建了高性能的數據架構。近期， IFTTT的工程師Anuj Goyal 對數據架構的概況進行了介紹，并分享了在操作數據時的一些經驗和教訓。
在IFTTT，數據非常重要——業務研發和營銷團隊依賴數據進行關鍵性業務決策；產品團隊依賴數據運行測試/了解產品的使用情況，從而進行產品決 策；數據團隊本身也依賴數據來構建類似Recipe推薦系統和探測垃圾郵件的工具等；甚至合作伙伴也需要依賴數據來實時了解Channel的性能。鑒于數 據如此重要，而IFTTT的服務每天又會產生超過數十億個事件，IFTTT的數據框架具備了高度可擴展性、穩定性和靈活性等特點。接下來，本文就對數據架 構進行詳細分析。
數據源在IFTTT，共有三種數據源對于理解用戶行為和Channel性能非常重要。首先， AWS RDS 中的 MySQL 集群負責維護用戶、Channel、Recipe及其相互之間的關系等核心應用。運行在其Rails應用中的 IFTTT.com 和 移動應用 所產生的數據就通過 AWS Data Pipeline ，導出到 S3 和 Redshift 中。其次，用戶和IFTTT產品交互時，通過Rails應用所產生的時間數據流入到 Kafka 集群中。最后，為了幫助監控上百個合作API的行為，IFTTT收集在運行Recipe時所產生的API請求的信息。這些包括反應時間和HTTP狀態代碼的信息同樣流入到了Kafka集群中。
IFTTT的KafkaIFTTT利用Kafka作為數據傳輸層來取得數據產生者和消費者之間的松耦合。數據產生者首先把數據發送給Kafka。然后，數據消費者再從Kafka讀取數據。因此，數據架構可以很方便的添加新的數據消費者。
由于Kafka扮演著基于日志的事件流的角色，數據消費者在事件流中保留著自己位置的軌跡。這使得消費者可以以實時和批處理的方式來操作數據。例如，批處理的消費者可以利用 Secor 將每個小時的數據拷貝發送到S3中；而實時消費者則利用即將開源的庫將數據發送到 Elasticsearch 集群中。而且，在出現錯誤時，消費者還可以對數據進行重新處理。
商務智能
S3中的數據經過ETL平臺Cranium的轉換和歸一化后，輸出到AWS Redshift中。Cranium允許利用SQL和Ruby編寫ETL任務、定義這些任務之間的依賴性以及調度這些任務的執行。Cranium支持利用Ruby和 D3 進行的即席報告。但是，絕大部分的可視化工作還是發生在 Chartio 中。
而且，Chartio對于只了解很少SQL的用戶也非常友好。在這些工具的幫助下，從工程人員到業務研發人員和社區人員都可以對數據進行挖掘。
機器學習IFTTT的研發團隊利用了很多機器學習技術來保證用戶體驗。對于Recipe推薦和問題探測，IFTTT使用了運行在EC2上的 Apache Spark ，并將S3當作其數據存儲。
實時監控和提醒
API事件存儲在Elasticsearch中，用于監控和提醒。IFTTT使用 Kibana 來實時顯示工作進程和合作API的性能。在API出現問題時，IFTTT的合作者可以訪問專門的Developer Channel，創建Recipe，從而提醒實際行動（SMS、Email和Slack等）的進行。
在開發者視圖內，合作者可以在Elasticsearch的幫助的幫助下訪問Channel健康相關的實時日志和可視化圖表。開發者也可以通過這些有力的分析來了解Channel的使用情況。
經驗與教訓
最后， Anuj表示 ，IFTTT從數據架構中得到的教訓主要包括以下幾點：
- 通過Kafka這樣的數據傳輸層實現的生產者和消費者的隔離非常有用，且使得Data Pipeline的適應性更強。例如，一些比較慢的消費者也不會影響其他消費者或者生產者的性能。
- 從一開始就要使用集群，方便以后的擴展！但是，在因為性能問題投入更多節點之前，一定要先認定系統的性能瓶頸。例如，在Elasticsearch中，如果碎片太多，添加更多的節點或許并不會加速查詢。最好先減少碎片大小來觀察性能是否改善。
- 在類似的復雜架構中，設置合適的警告來保證系統工作正常是非常關鍵的！IFTTT使用 Sematext 來監控Kafka集群和消費者，并分別使用 Pingdom 和 Pagerduty 進行監控和提醒。
- 為了完全信任數據，在處理流中加入若干自動化的數據驗證步驟非常重要！例如，IFTTT開發了一個服務來比較產品表和Redshift表中的行數，并在出現異常情況時發出提醒。
- 在長期存儲中使用基于日期的文件夾結構（YYYY/MM/DD）來存儲事件數據。這樣存儲的事件數據可以很方便的進行處理。例如，如果想讀取某一天的數據，只需要從一個文件夾中獲取數據即可。
- 在Elasticsearch中創建基于時間（例如，以小時為單位）的索引。這樣，如果試圖在Elasticsearch中尋找過去一小時中的所有API錯誤，只需要根據單個索引進行查詢即可。
- 不要把單個數據馬上發送到Elasticsearch中，最好成批進行處理。這樣可以提高IO的效率。
- 根據數據和查詢的類型，優化節點數、碎片數以及每個碎片和重復因子的最大尺寸都非常重要。