數據是創立Asana的核心部分，并且每一個團隊都依賴他們自己的方式。我們的負責增長的團隊依靠事件數據來分析試驗結果（對比試驗）。 我們做很多快速的實驗，通常會有很多實驗一起跑，讓這些互相影響的作用和其他關鍵度量引導我們需要放棄什么和投入什么。
項目經理，設計師和產品工程師通過分析使用數據來發現不可避免的妥協，比如簡潔性對強大性。通過這種方法，我們可以知道什么樣的新產品方向能夠釋放出最多的潛力。
市場部門需要明確在他們的競爭力中的哪個部分能夠驅使新用戶到Asana。財會部門需要非常可靠的關于總體增長模式的統計數據來幫助Asana確認能持續發展到2064年。你是怎樣建造一個支持所有這些多樣需求的系統呢 ？
圖1 Asana 數據基礎架構
從小開始，逐漸增長
上圖并不是我們一開始就建立的系統。我們從一個十分簡單的系統開始，也就是一些python腳本和MySQL數據庫，它們全都運行在一個機器上。剛開始的時候，一個簡潔的系統能夠減少系統維護，并且如果還沒有任何用戶，或許你就可以從這里開始。
但是，從2011開始，Asana的增長就一直穩定（看下面的圖）。然后我們就開始碰到一些限制。最近，針對數據基礎架構，我們做了一系列的變化。所有的一切都證明是很有價值的。
往監控，測試和自動化上投資來減少救火的次數
從MySQL遷移到Redshift，得到一個可擴展的數據倉庫
從本地的日志處理遷移到基于Hadoop的可擴展的日志處理
引進商業智庫工具來允許非專家來回答他們自己的數據問題
Asana隨著時間變化時的“時間”數量圖。按照原始數據量做單位
圖2 Asana穩定增長趨勢圖
結束無休止的問題
一年前，我們遇到了一些關于數據處理健壯性的問題。當圖表中有個重要的變化，人們立馬會質疑數據的整體性。把問題和有趣的想法區分開來是很難的。數據科學已經是一門藝術，所以你需要基礎架構來給你提出的問題一個信得過的答案。
然而，99%的準確性還是不夠好。在數據基礎架構小組那里，我們花費了太多時間鼓搗非常緊急的問題，而且這點使得我們沒法取得更長期的發展。這太痛苦了。
受到啟發
當壞的事情發生后，我們會采取“5個為什么”的方法來發現問題的原因和解決這個問題。比如，我們曾經讓一個數據處理腳本錯誤地生成了一個超級大的日志文件，它太大了，以至于我們無法用電子郵件發送。作為解決方案，我們在發生日志文件前就開始把日志文件分割成小段，并且在發送郵件錯誤的時候發送警告信息和在腳本輸出結果上增加監控。
在其他的一些我們還沒有辦法洞悉原因的例子里，我們就增加日志，檢測和預警。例如，我們的實驗總是經常性的落后，所以我們在不同的處理階段增加更廣泛的日志記錄來看看哪里花費了最多的時間，并且用來指示什么部分需要優化。
當我們的監控和日志記錄不夠的時候，最壞的事情持續了好幾個月。一個比較極端的例子就是，我們的一個工具花費了比其應花費時間多很多的時間。一段時間后，我們發現了一些查詢被傳遞進了一個不知道為什么我們也沒搞懂的、含有有特殊時區信息的時間類。
這些查詢顯著地增加了查詢時間。由于這個任務花費了一天多的時間來完成，所以第二天的任務才能接著開始，然而這導致了MySQL鎖過期。當生成圖像的時候，這些任務就沒法取得所有需要的數據。
我們隱藏了零數值，并且必須要每次人工地做很多工作去清理。錯誤總是導致更多的錯誤，所以打補丁也沒有用。最終，這個事件使得我們真正要去把測試的優先級提到最高。
一年前，我們的數據基礎架構的代碼上面幾乎就沒有任何測試。然而我們還不能滿足我們當前的測試覆蓋率，但是我們已經做了很多改進。當你得到一個失敗的測試結果并且你意識到這個本可能出問題的部分使得你改變了產品的一些代碼，這樣的感覺好極了。
雖然我們一直在探索節點增加的特性，我們還是使用python內置的單元測試模塊。我們把努力的方向放在為數不多的，特別是在那些我們能夠建立自己的架構代碼的領域，從而使得我們的數據科學家和其他的數據用戶能夠寫出他們自己的測試。
自動化測試
原來我們用cron來運行所有的事情。任務會在不同的時間段運行，我們期望某些任務在另外一些依賴它們的任務開始前完成。但是事情不總是這樣。比如，一個任務運行失敗，那就需要很多人為的清理。接著，我們開始使用Luigi 來建立一個管道。
這個管道懂得依賴性，就像你看到的下圖中我們的管道的一小部分示例。通過Luigi，當一個任務運行失敗，我們會得到告警，而且所有依靠它的任務都不會運行，直到我們修復那個運行失敗的問題。只需要恢復管道并且讓未完成的任務繼續，這樣就簡單多了。這個也是我們并行化這些任務的第一步。
我們的過去的預警方式很粗糙簡陋。我們有顯而易見的比如關于可用的硬盤空間的預警，但是這個花費很多思考和努力來克服困難從而得到我們今天擁有的一切。現在，我們覆蓋了所有的系統警告，從內存和CPU使用率到Redshift集群上長時間的高負載。
我們監控我們數據管道的變化，當時間花費超出預期或者一些任務沒有能夠在我們期望的時間內完成時就發出預警。我們監控數據本身，保證重要的變量都是非零的，并且用回歸分析來提示一個事件出現多于或者少于在過去的幾個星期中我們看到的次數。
圖3 用Luigi畫的我們數據的ETL 管道
我們改進關于優先處理郵件警示的過程。我們十分重度地依賴Asana，它工作十分良好，特別是在分擔責任和當數據會出現預知的錯誤時通知用戶。有了這些努力，問題逐漸變得少了。一旦不再花費時間讓已有的數據基礎架構發生癱瘓，我們就有時間來建造未來。
我們的數據基礎架構的最新發展
可擴展的數據倉庫 (Redshift)
最初，我們使用MySQL數據庫作為數據倉庫，因為我們的工程師擅長優化這個數據庫。但是，因為MySQL是基于行記錄的，所以它不適合在非常大的數據集合上運行包含復雜鏈接操作的聚集查詢。當我們遇到了性能問題，我們修改索引。當我們還遇到更多的性能問題，我們在MySQL之上建立一個定制的、面向直方圖的查詢緩沖層。
依舊，每一處優化只能幫助我們走得這么遠，并且我們并不想把我們的寶貴的工程師資源花在建立分析數據庫上。很多公司都宣稱Redshift幫助他們很好的提速。所以我們也打算試一試。結果太好了。在最極端的情況下，一個日常的查詢在MySQL上需要6個小時，但是在Redshift上，只需要幾秒鐘，而且不需要任何修改。
圖4 可擴展的數據倉庫
一個在MySQL上需要花費數分鐘的查詢，但在Redshift只需要1秒鐘遷移的過程。
遷移到Redshfit可不是一個小事情。我們已存在的數據管道是適合于MySQL的計劃而建造的。并且每一個人都很熟悉這個特點。我們努力抽象出Redshift的特性。比如，通過亞馬遜的S3加載數據和依據主鍵合成數據到一個已有的表格。
缺少對于主鍵的支持是意料之外的最大缺點。然后遷移我們已存在的數據管道的樂趣就開始了。復雜的依賴性意味著我們必須小心地按照正確的順序遷移寫入。有時，當我們遷移從MySQL的一個表格到Redshift的所有查詢時，我們必須同時寫入到MySQL和Redshift。
最困難的部分是協調部門之間的努力去遷移數量巨大的、相互依賴的MySQL查詢語句。而且其中的一些只被很少的一部分人理解和使用。我們從數據科學家和商業團隊中得到了關于他們最棘手的部分的有價值的反饋。繼而，我們使得他們的工作變得更愉快。
解鎖新的分析
然而我們選擇Redshift時的主要目的是解決性能和可擴展性的問題，不過它順便也改進了可訪問性。這點來得有點間接和意外。在遷移到Redshift的同時，我們也在探尋商業智能工具。我們評估了一些工具，本來最喜歡Looker，而且決定嘗試一下。
不幸的是，當我們把它和MySQL連在一起時的分析結果太慢了，以至于我們沒法推薦給我們的商業團隊。把Looker和Redshift鏈接后，性能從需要數分鐘變得足以實時地在絕大多數查詢上循環。這個組合太強大了，以至于我們的商業團隊自己就決定用它了。
我們絕大多數的商業團隊就憑他們自己，其中有些成員甚至連SQL查詢不熟悉，也能夠玩數據。更好的是，他們能夠在不需要數據基礎架構小組的支持下做到這點。他們的團隊負責人說：“這個就仿佛我把1995年自動擋的吉普牧馬人換成了法拉利一樣爽… 有快又有樂趣！”
進一步地擴展
Redshift還提供了工具用來限制給單獨的進程和程序的資源。我們非常依靠這些功能來防止某些個人把數據庫獨占，從而別人無法使用。通過增加機器的數量，然后按一些按鈕我們就能在半個小時內加速和增加存儲量。在將來，我們還可能自動化這個過程。
可擴展的日志處理 (彈性 MapReduce)
我們日常的數據處理延遲變得很長，但是我們努力保持處理時間在24小時內。雖然Redshift起了很大的幫助，但是我們也需要擴展日志處理部分。我們決定采用這個行業的長期標準 Hadoop MapReduce。
除了容易變得可擴展的，這也是一個更容易的數據處理方式。和建造易使用框架的努力一起，這個使得更多的每天工作不是寫代碼的同事也能夠把日志處理成有用的模式。因此，這個既是一個大的擴展性項目也是一個易用性的項目。
我們在Yelp的映射歸納任務框架(mrjob)的基礎上建立我們的系統。因為我們都知道Python很好，而且在靈活的MapReduce上開始跑任務也比較容易。
我們知道這個明顯地比Java和流慢一些，但是那個層次的性能還不重要到讓我們降低易用性。我們在設計基礎架構的時候就好像知道在將來我們會把mrjob換到到其他的一些東西。
當我們開始用MapReduce的時候，我們仍舊同時寫入MySQL和Redshift中。起初，這個讓我們同時從Hadoop集群上加載數據到兩個數據庫中。但是這個并不好使，因為大多數的集群會空閑很長的時間，而有時我們就很容易地碰到過期。
所以我們提倡放棄MySQL，而在集群之外，移動數據到Redshift。亞馬遜的彈性MapReduce可以存儲輸出到S3。我們利用這個來存儲數據，并且加載它到Redshift上來作為一個來自單獨的服務器的任務。
當前，我們用一個八個節點的集群，這個給我們4到6倍的性能提升。當我們負責增長的團隊要增加三倍的運行任務的時候，我們只需要增加Hadoop集群的大小或者增加更多的集群。
我們運行在亞馬遜彈性MapReduce上，就使得這樣做變得更容易。可擴展性還間接地幫助了易用性。因為不用擔心他們的代碼變得很慢和對數據管道有負面的影響，我們的商業團隊在增加更多的數據處理上變得舒服很多。
商業智能工具 (Interana and Looker)
當調研商業智庫工具的時候，有人介紹Interana。一個基于交互事件的、處理原生日志文件的分析解決方案。然而，這個并不是我們一開始需求的東西。我們集合我們的數據后發現它可以滿足一個之前并沒有預料到的需求：超快循環分析原生日志。
我們就成為他們的最初的幾個用戶之一。在早期的產品設計里，我們和他們反復交流，使得他們實現了很多我們的性能需求。這逐漸地成為我們產品團隊數據分析中的一個集成部分。
同時，Looker繼續成為我們商業團隊的一個重要的補充。我們的團隊需要及時分析某幾個時間點上數據的狀態。
我們能夠在幾秒鐘內處理十億數量級的數據點。從而展現出很多我們的數據中深層次的數據分析，這在以前不可能的。任何查詢數據模式的人都能夠很快地切割數據來發現根本原因并且擁有我們全部的數據集的訪問權來快速地在區塊中篩查。
這允許他們探索我們的用戶怎樣使用這個產品，從通過群組來做簡單的事件計數到復雜的對話和漏斗分析。現在，我們很少寫專門的腳本來扒下創建特殊聚集的日志。我們開始用Interana來分析性能日志。團隊成員說：“一旦當Interana加入到我們的數據處理管道中，查找和解決回歸分析的效率就提高了一個數量級。”
一些Looker擅長的例子：
查詢金融和收入數據；多種方式分切收入來理解增長的趨勢
視覺化隨著時間流逝的群效應（見截圖右側部分）
數據堆砌；所有滿足一個標準的客戶，等等。
圖5 Looker擅長的例子
Looker幫助我們查看大維度建模在時間軸上的群效應
一些Interana 擅長的事情：
1、交互的漏斗分析
2、視覺化用戶行為，導致新能問題（截圖中的右邊部分）
3、理解長期使用這個應用的用戶會做什么操作
圖6 Interana使我們能夠找出在Asana中最慢的一些共同的行為
接下來除了這些大項目，我們加固了一切，從而使得同事不會輕易的不小心弄癱瘓設備。Justin Krause，我們的商業智庫負責人說：“我們的工作生活變得非常好了，我幾乎不會弄壞任何東西了。” 大多數星期里，我們只用半個小時的時間來維護基礎設備。
我們喜歡我們現在的狀態，但是這個僅僅是漫長旅行中的一點。伴隨增長，新的功能，新的生意需求，我們管道中的很多部分在將來的歲月中都會變得過時。
我們知道事物總是會出現新的、有趣的錯誤，所以我們也增加測試和監控，以謀求在發生前發現大部分情況。我們還留意在數據分析領域中，哪個新系統變得流行，我們就會做出相應的對策。
我們認為會在下面幾點探索一下：
1、加入Hive，在Redshift之上增加一些東西，或者在Interana的能力范圍之外用另外一個系統來做原始的日志查詢。
2、流數據分析的系統
3、比mrjob更快的Hadoop，或者可能用像Spark一樣的東西來做內存中的MapReduce
4、更好的異常探測和趨勢預警
5、限制單點缺陷
如果你對在快速變化的環境下建立數據基礎架構有很好的想法，請加入我們下一階段的旅行吧。
如果你想分析大數據和學習各個組之間怎樣工作，就以一個數據科學家的身份來用這個基礎架構！Clark Bernier，我們的一個數據科學家說：“和一群有天賦，有擔當的數據基礎架構團隊一起工作是在Asana中作為數據科學家時最美好的一部分。
我能夠專心于數字和他們的含義中，我相信我的分析能夠如閃電般一樣飛速。”
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
相關文章
