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