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