目前，國內自主研發的文件系統可謂鳳毛麟角。淘寶在這一領域做了有效的探索和實踐，Taobao File System（TFS）作爲淘寶內部使用的分佈式文件系統，針對海量小文件的隨機讀寫訪問性能做了特殊優化，承載着淘寶主站所有圖片、商品描述等數據存儲。
最近，淘寶核心系統團隊工程師楚材（李震）在其官方博客上撰文（《TFS簡介》，以下簡稱文章）簡要介紹了TFS系統的基本情況，引起了社區的關注。
文章首先概括了TFS的特點：
- 完全扁平化的數據組織結構，拋棄了傳統文件系統的目錄結構。
- 在塊設備基礎上建立自有的文件系統，減少EXT3等文件系統數據碎片帶來的性能損耗。
- 單進程管理單塊磁盤的方式，摒除RAID5機制。
- 帶有HA機制的中央控制節點，在安全穩定和性能複雜度之間取得平衡。
- 儘量縮減元數據大小，將元數據全部加載入內存，提升訪問速度。
- 跨機架和IDC的負載均衡和冗餘安全策略。
- 完全平滑擴容。
當前，TFS在淘寶的應用規模達到“數百臺PCServer，PB級數據量，百億數據級別”，對於其性能參數，楚材透漏：
TFS在淘寶的部署環境中前端有兩層緩衝，到達TFS系統的請求非常離散，所以TFS內部是沒有任何數據的內存緩衝的，包括傳統文件系統的內存緩衝也不存在......基本上我們可以達到單塊磁盤隨機IOPS（即I/O per second）理論最大值的60%左右，整機的輸出隨盤數增加而線性增加。
TFS的邏輯架構圖1如下所示：
圖1. TFS邏輯架構圖（來源：淘寶核心系統團隊博客）
楚材結合架構圖做了進一步說明：
- TFS尚未對最終用戶提供傳統文件系統API，需要通過TFSClient進行接口訪問，現有JAVA、JNI、C、PHP的客戶端
- TFS的NameServer作爲中心控制節點，監控所有數據節點的運行狀況，負責讀寫調度的負載均衡，同時管理一級元數據用來幫助客戶端定位需要訪問的數據節點
- TFS的DataServer作爲數據節點，負責數據實際發生的負載均衡和數據冗餘，同時管理二級元數據幫助客戶端獲取真實的業務數據。
文章發表以後，讀者反響熱烈，在評論中提出了各種問題與作者楚材進行技術交流，由此可見國內社區對自主研發文件系統的關注程度。
爲了讓讀者更深入地瞭解TFS的奧祕，InfoQ中文站針對TFS的來由、運行環境、擴展性、架構、發展規劃及開源事宜等問題對楚材（李震）進行了專訪。
InfoQ：淘寶爲何會選擇自主研發文件系統？
TFS(Taobao File System)，是淘寶自主研發的一套分佈式文件系統，用於存儲淘寶網主站的數據，例如商品圖片、商品描述、交易快照、社區圖片等等等等。這些數據的一個突出特點是單個文件尺寸較小，通常不大於1MB，但是數量巨大，傳統的文件系統或者網絡存儲設備很難解決類似的問題。
淘寶網最早採用NetApp提供的網絡存儲設備，但是在2006～2007年期間，由於數據量的急劇膨脹，我們面臨着系統更新換代的壓力，而由於應用連接數量和文件數量的限制，實際上簡單的升級已經變得非常昂貴且得不償失了。
數據是淘寶應用的核心，在這方面我們需要提供更加安全、高效、廉價的解決方案，需要發展自己的技術，更加適應淘寶網自身的應用特性。經過評估，已有的一些開源分佈式文件系統都無法完全滿足我們需求。淘寶網也許是當時國內互聯網最先遇到類似問題的公司，當然也可能是其他公司遇到但未進行相關的宣傳，總之，當時並不像現在一樣有一些相對可靠的開源系統可以選擇。
InfoQ：TFS系統的運行環境如何？
在做TFS選型的時候，我們依照當時淘寶網使用的主流操作系統使用了REHL，並構建在LINUX的EXT3文件系統上。選擇REHL的理由是開源操作系統，我們有更多的自由度，同時成本也更加節省。關於硬件平臺，隨着硬件的發展和我們認識的變化，經過了一個相對比較長的變遷。分佈式文件系統對CPU的要求並不高，同時由於我們採用了一些特殊的手段，也使得系統元數據減少，那麼對內存大小的要求也並不高了，所有的性能和成本瓶頸都集中在了磁盤IO上。我們所有硬件架構的演變也都體現在磁盤的使用方式上。
最早我們使用SAS146G×6的磁盤進行存儲，後來換成了SAS300G×6的磁盤，使用了RAID5機制，這也是當時硬件平臺的主流。當我們積累了一定的經驗並逐步對系統穩定性有了信心之後，這種方式就逐步落後了。RAID5機制的備份和我們已經在應用層實現的數據冗餘功能重複，磁盤空間被大量浪費，RAID卡的工作原理也無法優化TFS更加註重隨機IO的特性，最終我們去除了RAID卡，並使用多進程，每個進程管理一塊磁盤的方式，充分發揮磁盤的隨機讀寫性能。
SAS300G×6的磁盤我們使用了一段時間，相對比較穩定，這讓我們有信心使用更大容量的節點而不會過於擔心服務器失效帶來的數據遷移對系統性能的影響，當前TFS主要的機型使用SAS300G×12的磁盤配置。
隨着淘寶網前端的CDN越來越高效、穩定，到達TFS的請求流量也更加平緩，這讓我們有可能對單個節點的服務能力做出更加可靠的規劃，也可以使用更加廉價的存儲設備，未來我們的主要存儲節點將使用1TSATA×12甚至更大的磁盤設備，進一步降低成本。
InfoQ：TFS的應用規模達到數百臺PC server和PB級數據量，其擴展性如何？架構上是如何保證的？
在TFS中我們將大量的小文件合併成爲一個大文件，類似GFS中Chunk的概念，而Chunk的定位信息我們稱之爲一級索引，而chunk內部具體的文件定位信息我們稱之爲二級索引，同時在TFS文件名稱中包含這些索引信息，在用戶寫入一個文件之前，他必須向TFS系統申請一個文件名稱。這種方式雖然在某些情況下顯得不像傳統文件系統那樣靈活，但也給了我們系統更大的可擴展性。我們保證可以中心控制節點的內存可以支撐PB級別的一級索引，而二級索引僅需要針對單臺數據量。這樣，我們就避免了數據量膨脹帶來的擴容難度。當存儲容量出現不足，我們需要進行系統擴容的時候，可以根據數據增長情況進行規劃，任意數量的加入提供相應存儲的服務器。而這些新的存儲服務器會向中心控制節點進行報告。而中心控制節點在有數據寫入時，將根據已存儲容量的百分比、系統當前負載等參數動態地分配寫入的服務器。同時，在系統空閒時間段，中心控制節點也會根據當前的數據分佈情況制定數據遷移計劃，並逐步完成數據平衡。與此類似，當發生服務器崩潰時，中心控制節點也會進行數據遷移以保證足夠的備份，同時也會進行數據均衡操作。這些操作都是自動進行的，不需要人工干預。
這種方式在1000臺以內的集羣基本上能夠工作良好，如果集羣規模更大，中心控制節點可能會出現一些性能瓶頸，屆時我們可以使用一個分佈式集羣來解決，相應已經比較成熟的技術方案現在已經比較多了。
InfoQ:您在介紹TFS的特點時，多次提到“性能”這個關鍵詞，請問對於一個文件系統來說，性能一般應該考慮哪些因素？目前，提高文件系統性能的通用方法有哪些？
現在我們可以討論一下TFS的性能考量的維度了。其實當前每個流行的分佈式文件系統都有自己的側重點，分別針對自己不同的應用場景。對於離線型的數據分析需求，由於數據總量巨大，底層分佈式文件系統更加註重系統的整體吞吐率，爲了適應當前流行的map_reduce模型，這一類的文件系統會將文件切成多份，分而治之。同時和上層的邏輯配合，採用大塊順序寫入、讀出的方式來提升性能，典型的代表就是Hadoop使用的HDFS。
實際提供線上服務的分佈式文件系統中，也根據服務類型的不同而採用差異化的存儲方式，例如針對音、視頻等相對比較大的文件，可能採用和離線應用相同的方式將文件切片併發讀寫訪問，從而達到更高的傳輸速度。由於相同容量下文件數量比較少，甚至有可能完全實現類似傳統文件系統的目錄、權限等功能，而不會受到inode的限制。如果面臨淘寶相同的海量小文件存儲，這種方式就完全無法提供性能的支持了，inode數量的膨脹會很快吃掉大量的昂貴內存，如果要平衡成本將部分inode放入磁盤，面對基本上完全隨機、沒有熱點的訪問又無法保證尋址的效率，我們只能通過減少元數據的方式來解決這個問題。
爲什麼說我們的TFS面臨着完全隨機、基本上沒有熱點的數據訪問？在淘寶的數據部署中，TFS前端有兩層更加靠近用戶的緩存系統來保證用戶展示頁面的速度，最終到達TFS的請求大概只有總請求數量的2%左右，隨着前端緩衝的效率不斷提升，這個比例還會繼續下降，我們可以想象一下是否仍然有熱點數據存在。與此同時，淘寶網的業務特點決定了相對於讀取請求，寫入請求量不在一個數量級上，而修改操作量就更少，這就決定了我們使用進行隨機修改、隨機寫入的方式來避免順序寫入不進行修改給隨機讀取帶來的成本。
不同的應用場景，不同的存儲架構，不同的性能考量，有什麼通用的性能優化手段嗎？從我們的實踐經驗來看，似乎沒有，很難有一種方法解決所有的問題，或者說解決了這些問題之後，大家會發現相對專用的文件系統，通用系統總是不能達到你預期的性能，同時也帶來了大量開發和調優方面的複雜性。這種情況下，也許我們建立不同的集羣解決不同的問題更加高效，這一切都取決於你支撐的業務需求是怎麼樣的，Google級別集羣規模的架構和簡單搭建起來的NFS都有其存在的價值。
當然，還是有一些通用的規則的。如果你需要支持的是一個線上服務，那你就要儘量減少一次請求引發的IO數量，IO包括網絡及物理磁盤，這些操作引發的性能開銷是由物理結構決定，無法用技術手段去優化的。也就是說，這些操作的數量實質上形成了你這個系統的性能天花板，當你設計一個文件系統的架構時，你可以根據這個天花板預估到在不同情況下這套系統的性能表現是怎麼樣的。
其次，你需要在併發和同步開銷之間做出平衡，根據業務的特點選擇更適合於你自己的方案，例如從一塊磁盤上連續讀1MB數據和通過網絡併發從10塊磁盤上分別讀取100KB數據返回給用戶，你會選擇哪種？那麼從一塊磁盤上連續讀取100MB數據和100併發分別讀取讀取1MB呢，系統是否有能力支撐這樣的併發？絕大部分時候，我們是在做類似的選擇。
第三，你需要在成本和性能之間做出平衡，我們可以很方便的使用內存型緩衝來極大地提升系統性能，如果你的系統熱點數據集中的話。隨着SSD技術的成熟，它可以提供的隨機讀性能相對傳統機械磁盤讓人興奮，隨機寫性能也有了極大的改善，雖然不像讀取提升的那樣誇張。如果你的應用讀寫比例比較高，又可以承受成本，儘量使用SSD吧，雖然當前的成本還是相對昂貴的。
InfoQ：從TFS的邏輯架構圖來看，NameServer作爲中心控制節點，DataServer作爲數據節點，這樣的架構基於哪些因素或者需求的考慮？
TFS有中心控制節點和數據節點的區分，分別管理兩級索引解決數據訪問的尋址和傳輸。相對當前一些開源分佈式系統的去中心化趨勢，似乎不是非常優秀。但如同對性能的論述一樣，每種系統架構都有其存在的價值，中心節點的存在可以保證事務性，我們在某些情況下必須保證寫入數據的強一致性，同時在當前的應用規模中也可以非常安全、高效的解決問題。如果有更高的可用性、擴展性需求，我們會在TFS部分中部分體現去中心化的思想。
InfoQ：未來TFS的發展計劃如何？
TFS未來的開發首先仍然會立足於淘寶網自身的業務需求，同時會照顧開發社區中的需求。我們會逐步支持大文件的存儲，也會支持目錄和用戶權限，同時計劃實現按照訪問特性分佈的分級存儲，儘量在性能和成本之間達到一個平衡，還有一些更加精細化的管理功能，例如數據量配額的管理等等。從上面的一些討論來看，我們不大會做一個通用的分佈式文件系統，始終會專注解決當前尚無很好解決方案的問題。
InfoQ：您在博客中提到9月份建立TFS開源社區，這對國內社區是個絕佳的學習機會，請問目能否再描述一點開源的細節？
TFS計劃在9月底開源，而今年6月底，淘寶網將推出自己的開源社區——code.taobao.org，TFS將完全基於這個開源社區進行開源，大家馬上就可以看到。同時已經基本確定使用GPL V2開源版權協議。
InfoQ：對於有志於參與到TFS或者目前從事其他類似系統級核心應用的開發人員來說，請問有什麼好的建議？
對於有志於參加TFS開發，或者自身已經在從事基礎平臺、核心系統研發的同行，我相信大家都有相同的感受，在當今計算機體系結構內，我們很難有革命性的技術進展。當前已知的大規模的分佈式文件系統都構建在Unix類操作系統之上，或者說絕大部分都構建在Linux之上，這也是從成本方面進行的考量。而各種分佈式文件系統架構也大同小異，決定是否成功的關鍵在於細節，這些細節包括操作系統級別的特化、文件系統級別的特化、實現方面是否足夠優秀、足夠穩定等等。因此你需要對系統內核有所瞭解，對文件系統有所瞭解，比如你知道EXT3的組織方式纔可能儘量避免讀取一段數據卻引發多次磁盤磁頭移動的情況，這樣你才能最大化的利用好系統資源。而實現的特化可能體現在一個優秀算法的編寫、一個高效的通信機制等等，這就要求你有紮實的代碼編寫能力，對算法和數據結構有頗深的造詣。大家都知道，細節決定成敗！
InfoQ中文站將繼續關注TFS等國內自主研發文件系統的發展，也歡迎大家發表自己的看法。
專家介紹
李震，花名楚材，工作於淘寶技術研發部核心系統研發，負責存儲組的開發，關注領域主要包括大集羣分佈式系統的研發、海量數據處理、海量數據檢索等等。