資料對于ifttt至關重要。我們的 bd 和營銷團隊依靠資料來做出關鍵的業務決策。産品團隊依靠資料來測試來了解使用者是如何時候我的産品的，以做産品決策。資料團隊本身依靠資料建立産品，比如recipe推薦系統和垃圾郵件檢測工具。此外，我們的合作夥伴依靠資料來實時擷取channels的性能。
因為資料對于ifttt如此關鍵，并且我們的服務每天處理幾十億事件，是以我們的資料基礎設施必須具有高可擴充性、可用性的和彈性，以便跟上産品的快速疊代。在這篇文章中我們将帶你浏覽資料基礎設施和架構，也會分享一些我們在建構和操作資料的收獲。
<a></a>
在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叢集。
我們使用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 的最大值等參數。
本文來自雲栖社群合作夥伴“linux中國”，原文發表于2013-04-02.