2016年11月29日 星期二

區塊鏈如何運作?

source: https://www.inside.com.tw/2016/09/01/how-does-the-blockchain-work


原文為《How Does the Blockchain Work?》。譯者簡志偉,為軟體開發者,譯文刊載於 Medium 。INSIDE 獲授權部分轉載,完整文章請至譯者 部落格 觀看。
這篇文翻譯自」How Does the Blockchain Work?」全文。作者 Michele D'Aliessi 用淺白易懂的文字闡述比特幣 (Bitcoin) 和區塊鏈 (Blockchain) 的運作原理,是一篇很棒的入門文章,因此我決定挑戰翻譯看看,讓更多人了解這個技術。
本翻譯文已取得 Michele D'Aliessi 的同意,全文如下:
自網路問世以來,區塊鏈技術可能是目前為止最棒的發明。它讓我們不用倚靠在無形的信賴或權威機構來做利益交易。舉例來說,我和你打賭 50 元明天舊金山的天氣。我賭它會是晴天,你賭它會是雨天。我們會有三種方式來完成交易:
  1. 我們信賴彼此。不論結果是晴天或雨天,輸家要給贏家 50 元。如果我們是朋友,這會是一個好的交易方式。然而,即便是朋友,也有可能會賴皮不認輸而不願付錢,更何況是陌生人。
  2. 我們可以訂定合約,如果有任何一方不願付錢,贏家可以告輸家。但要花錢花時間打官司,只為了討回 50 元,實在是得不償失。
  3. 我們找一個中立的第三者,每人分別先給她 50 元,結果揭曉後,她再把所有的錢 100 元給贏家。無奈的是,這個第三者有可能捲款潛逃。
我們無法信任陌生人,也覺得打官司勞神傷財。區塊鏈技術很有趣,因為它幫我們實現第三個交易方式,而且安全、快速和便宜。
我們可以只寫幾行程式碼,讓它執行在區塊鏈網絡 (Blockchain Network) 上,進行交易。以打賭天氣的例子,這支程式會確保 100 元的安全,並且一到明天會自動確認天氣狀況,結果揭曉後,也會自動將 100 元匯到贏家的帳戶裡。在區塊鏈網絡上的交易,是無法被竄改或停止,而且益於大型交易,如賣一間房子或一家公司。
本文的目的是不用艱澀的技術用詞來解釋區塊鍊是如何運作,給讀者技術背後擁有的邏輯和機制的基本概念。
比特幣 是最為人所知的一項使用區塊鍊技術的應用。電子貨幣可被用來做物品交換,就像美元、歐元、人民幣和其他國家的貨幣。我們先來說明比特幣是如何運作,說明過程中會一點一點帶入區塊鍊的概念。
比特幣讓人們第一次可以在網路上交易身家財產,而且是安全的,沒有人可以挑戰其合法性。
-Marc Andreessen

所以,什麼是比特幣?

一塊比特幣就是一個單位的電子比特貨幣 (BTC),並且就像真實的一塊錢貨幣一樣,本身是沒有價值的,只有在進行物品交易時才會產生價值。
在比特幣系統裡,有一本 帳本 (ledger),它是一個電子檔案記錄著所有的交易紀錄。


圖 1. 比特幣電子帳本
這帳本不是存放在一個中央機構,像是銀行,或是一個資料庫。它擁有無數份副本,散佈存放在區塊鍊網絡上的每一台電腦裡,而每台電腦我們稱為「節點 (node)」。
如果 David 想用比特幣轉帳給 Sandra,他就送一個訊息告訴網絡說:他的帳戶減 5 BTC,然後 Sandra 的帳戶加 5 BTC。在網絡中的每個節點都會收到訊息,並且將這筆交易記錄到自己的帳本裡,然後更新帳戶的餘額。


圖 2. 請求交易訊息
說到這裡,關於帳本是由一群電腦共同維護,而不是由一個類似銀行的中心機構來掌管,有三個啟發:
  • 在銀行系統中,我們只知道自己的交易紀錄和帳戶餘額,而在區塊鍊網絡裡,每個人可以知道任何人的交易紀錄。
  • 一般來說你信任你的銀行,而比特幣是分布式系統,運行在網路上,任何事情發生錯誤,是沒有客服人員可以幫你的。
  • 區塊鍊不是建構在信賴情感上,其安全性和可靠性是透過特殊的數學函數和程式碼達到的。
我們可以定義區塊鍊是一個系統,它讓一群互聯的電腦安全地共同維護一份帳本。
為了能在區塊鍊網絡裡進行交易,你需要一個 錢包 (wallet),它讓你可以存放和交易你的比特幣。只有你可以花費你的比特幣,所以每個錢包被特殊的加密法所保護著,使用一對獨特且配對的鑰匙:公鑰和私鑰,才能解鎖。
如果一個訊息被公鑰加密,只有配對的私鑰才能解密讀到訊息。反之,如果你用你的私鑰加密訊息,只有配對的公鑰可以解密。所以當 David 想要轉帳,他需要用他的私鑰將轉帳訊息加密後,送到網絡裡,然後每個節點使用 David 的公鑰將訊息解開,以確認是由 David 發送的。
在加密完成時會產生一個電子簽名,它會被節點們用來確認交易訊息的發送來源和真偽。電子簽名內容是一串文字,它是由交易訊息和私鑰所組成的,所以不能用在其他的交易訊息上。如果你更改交易訊息中任何一個字元,電子簽名也會跟著改變,所以駭客很難更改你的交易訊息或是得知交易金額。


圖 3. 電子簽名與加密交易
錢包的公鑰其實是網絡裡的一個位址 (send to address),所以當你轉比特幣給某人時,你其實是將比特幣轉公鑰的位址。而且你必須證明你是私鑰的所有人,才能進行轉帳。請注意,在網絡裡的交易訊息已經是被加密過的,你不用揭示你的私鑰。
每個節點都保有一份帳本,但節點是如何知道你的帳戶餘額?區塊鍊系統並沒有記錄每個人的帳戶餘額 (譯注:所以帳本實際上不是像圖 1 一樣),事實上,它只有紀錄網絡上每筆交易紀錄 (如圖 4)。為了得知你的帳戶餘額,你必須分析和驗證所有曾經跟你錢包產生交易的紀錄。


圖 4. 區塊鍊網絡的帳本
「帳戶餘額」的計算和驗證需要靠之前的交易紀錄。舉個例子,為了轉出 10 BTC 給 John,Mary 先發起一個交易訊息,它包入了之前部分的轉入交易紀錄,只要這些紀錄的轉入金額加總起來剛好或大於 10 BTC 即可發送訊息。這些包入的交易紀錄稱作輸入 (inputs),每個節點會驗證這些輸入的金額加總是等於或大於 10 BTC。這些計算和驗證會由錢包和節點自動完成,使用者不需要煩惱。

圖 5. 區塊鍊的交易訊息結構
至於,系統如何信任這些輸入?它去確認你的錢包在之前所有的轉入交易紀錄中是否真的有這些輸入。為了簡化和加速驗證的過程,每個節點會保留一份特殊的資料來達到目的,也因為這個驗證過程,錢不可能會無緣無故多出來。
持有比特幣代表的是,帳本上你還未變成輸入的交易紀錄。
在比特幣網絡上執行交易的程式碼都是開源的,這表示任何人只要有電腦和網路就可以進行交易。然而,程式的錯誤有可能導致你的比特幣會不見。還記得嗎?比特幣是分散式網絡,並沒有專屬的客服人員替你找回遺失的錢或錢包密碼。所以你想要用比特幣進行交易,建議使用正式的比特幣錢包軟體 (例如 Bitcoin Core),並且妥善保存你的錢包密碼或私鑰。

2016年1月10日 星期日

你不得不知的Cortex-M3和M4微控製器使用秘訣

Source-- http://3g.autooo.net/utf8-classid88-id131465.html
http://www.2cm.com.tw/coverstory_content.asp?sn=1311050001

你不得不知的Cortex-M3和M4微控製器使用秘訣

2014-08-08

許多嵌入式開發人員對ARM Cortex處理器架構頗為熟悉,但很少有人能夠對這種流行架構了如指掌,從而可以充分發揮它獨特的特性和性能。ARM Cortex-M4處理器尤為如此,它擁有引以為豪的增強架構、天生的數字信號處理(DSP)能力和可選的浮點加速器,使精於此道的程序設計人員或硬件工程師可以充分發揮它的優勢。本文接下來將就Cortex-M3/M4微控製器(MCU)的一些更有趣的(但經常遭到忽視的)特性展開詳細的論述。
  大部分采用Cortex-M3/M4 MCU的目標應用是便攜式的,並且供電電源來自電池或能源收集係統,因此我們所探討的大部分概念涉及如何減少係統整體能耗的技術。然而,在許多情況下,這些節能技術也是處理器應用設計的有力工具,可提供:
  ● 更符合成本效益的解決方案
  ● 更大的升級和采用新特性的設計冗餘
  ● 有助於產品在激烈競爭市場上脫穎而出的性能和特性
  
ARM Cortex基本介紹
  就像Advanced RISC Machines(ARM)公司在20世紀80年代所推出的第一代16位處理器內核一樣,ARM Cortex係列以哈佛式RISC架構為基礎,采用適度的矽封裝工藝獲得更高性能,以及代碼和內存效率。該架構在過去十年間大有進展,擴展出了三種不同的子係列,以滿足特定應用的需求:
  ● A型係列處理器針對高效能開放應用平台而優化設計。
  ● R型係列處理器注重提升實時應用的性能和可靠度。
  ● M型係列處理器特別為采用嵌入式MCU的應用而設計,其性能必須在能源效率和降低解決方案成本之間加以平衡。適用於Cortex M係列的常見應用包括智能電表、人機接口設備、汽車與工業控製係統、白色家電、消費電子產品和醫療器材等。
  
Cortex-M3對比Cortex-M4
  Cortex-M3架構背後的指導思路是設計一種既要滿足應用的成本效益又要提供高性能計算和控製1的處理器。類似的應用包括汽車車身係統、工業控製係統和無線網絡/傳感器產品等。M3係列為32位的ARM處理器架構引進了多項重要特性,包括:
  ● 不可屏蔽式中斷
  ● 高度確定性、嵌套、向量式中斷
  ● 原子位操作
  ● 可選的存儲保護(MPU)
  除了絕佳的計算性能,Cortex-M3處理器先進的中斷結構還能確保係統迅速響應真實世界的事件,同時仍然提供極低的動態與靜態功耗2。
  圖1:Cortex-M3與M4處理器內核的比較。
  圖1:Cortex-M3與M4處理器內核的比較。
  Cortex-M3和M4處理器共享許多相同的設計要素,包括先進的片內調試特性,以及執行完整ARM指令集或ARM指令子集(用於THUMB2處理器)的能力。Cortex-M4處理器的指令集具有增強的高效DSP特性庫,包括擴展的單周期16/32位乘法累加器(MAC)、雙16位MAC指令、優化的8/16位SIMD運算及飽和運算指令。總體來說,M3與M4最顯著的差別在於,M4具有可選的單精度(IEEE-754)浮點單元(FPU)。
  
多項秘訣造就巧妙解決方案
  嵌入式設計的成敗經常取決於如何在係統性能、能耗和解決方案成本之間找到適當的平衡。許多情況下,開發人員可以采用Cortex-M處理器上的獨特特性來優化產品成本或能源需求,同時維持、甚至提升它的性能。例如,Cortex-M內核天生的串行I/O能力能夠用於節省能源、簡化開發、釋放外設以用於其它應用任務。
  除了傳統的串行調試(Serial Wire Debug)功能之外,基於ARM Cortex-M的MCU還可以通過它的單引腳串行監視器輸出(Serial Wire Viewer Output,SWO)3提供指令跟蹤接口,如圖2所示。這個接口可以直接把“printf格式的”調試信息傳遞給應用代碼。SWO允許調試信息直接在任何標準的IDE中瀏覽。此外,這些信息也可以用獨立的SWO監視器(例如,Segger的J-Link SWO Viewer軟件4,或是Silicon Labs的energyAware Commander 4)進行瀏覽。由於SWO輸出內建於內核硬件本身,因此它是Cortex-M內核與生俱來的優點。SWO不占用MCU的任何UART接口,這些接口它們可能早已被分配給了應用。
  圖2:專用ARM Cortex SWO接口節省I/O引腳並加速調試。
  圖2:專用ARM Cortex SWO接口節省I/O引腳並加速調試。
  基於SWO的調試還有一個重要的優勢在於,它讓微控製器在進入最低的休眠模式時,保持調試連接有效,而在大多數情況下,傳統的調試連接這時是不能正常工作的。SWO的指令追蹤還可以用於跟蹤程序計數器,以幫忙IDE統計出程序各項功能所占用的時間。這些統計數字能夠與電流測量結合起來,幫助開發人員對設計功耗進行微調。
  基於Cortex-M的微控製器供應商正在開始重新認識這項優點,而且有些廠商已經為了這個目的而把功耗模式和電流測量硬件納入到本身的開發平台。例如,Silicon Labs的EFM32 Gecko MCU入門級和開發級工具包都包含功耗測量輸出,並可搭配energyAware Profiler工具6中的程序代碼追蹤功能。圖3顯示了如何讓設計人員精確定位到哪個程序功能塊最耗費能源,並且能夠快速調試其它與能源有關的問題。
  圖3:軟硬件工具精確定位耗能最大的功能,無需示波器和萬用表,快速排除問題。
  圖3:軟硬件工具精確定位耗能最大的功能,無需示波器和萬用表,快速排除問題。
  
智能休眠節省每一微瓦
  ARM Cortex-M處理器的Sleep-on-Exit(中斷完成時直接進入休眠)是另一項“一箭雙雕”的功能,可同時節省CPU周期和能耗。這點在由中斷所驅動的應用中格外有用,因為處理器的大部分時間不是在執行中斷處理,就是在中斷事件之間休眠。在進入中斷服務例程(ISR)時,MCU必須花費好幾個指令周期把當前線程狀態入棧,然後在退出中斷處理返回時恢複原有線程狀態,即“出棧”。當應用需要處理器在退出ISR後直接進入休眠狀態時,傳統MCU仍然必須恢複原先存儲的狀態信息,然後線程代碼才能讓MCU進入休眠狀態。同樣地,當下次的中斷喚醒MCU時,它的狀態必須再次入棧。
  而當使能ARM Cortex-M微控製器上的Sleep-on-Exit功能後,MCU就會在中斷處理完成後直接進入休眠狀態,而不用先返回到原有線程上(見圖4)。這會使處理器仍然保持在中斷狀態,因為消除了喚醒再入棧過程,因而節省下許多寶貴的機器周期。消除入棧出棧過程既節省了時間也節省了能耗,否則電能就會被不必要的指令周期白白消耗,也包括哪些傳統MCU在休眠和喚醒之間管理堆棧的代碼。而且,當處理器被中止調試請求(Halt Debug Request)喚醒時,出棧過程將會自動進行。
  ARM Cortex-M處理器
  ARM Cortex-M的Sleep-on-Exit功能通過避免不必要的代碼執行和減少出棧入棧操作降低功耗。
  圖4:ARM Cortex-M的Sleep-on-Exit功能通過避免不必要的代碼執行和減少出棧入棧操作降低功耗。(引自:《The Definitive Guide to the ARM Cortex-M31》)
  
ARM Cortex-M4運行更快、休眠功耗更低
  像許多MCU一樣,Cortex-M3/4處理器通常能夠采用高時鍾速率的方法在中斷驅動的應用中節省能耗。如果處理器大部分時間處於休眠狀態,這種看似違背直覺但普遍采用的節能策略就會很好,因為運行時間減少所節省的能耗遠遠大於稍高的操作電流。簡單來說,多花10%的電可以省掉20%的時間,總體來說是節能了。
  這種技術可以應用在任何Cortex-M係列的處理器上,而涉及密集運算任務的應用也能從Cortex-M4處理器的額外能力中受益。它的單周期DSP指令和可選的浮點加速器能大大減少諸如數字信號處理、過濾、分析或波形合成等功能所需要的執行周期數。
  一些應用僅僅需要DSP處理能力。例如,有些安全係統采用一種以聲學分析來感測玻璃破損的裝置。玻璃破損時會發出一連串獨特的聲音和振動,並且在玻璃特有的固有頻率時達到最大,在這個例子中是13kHz。大多數采用傳感器接口的係統隻有在所監測的頻率被監測到時,才喚醒處理器。但是當設計中使用帶DSP功能的Cortex-M4時就能額外節能,因為它在執行實際的玻璃破損分析時比軟件解決方案更快。
  甚至,這些使用基於M4微控製器的應用可以更加節能,因為MCU中所包含的高級休眠模式和自治外設可以在CPU休眠時執行許多日程任務。例如,以Cortex-M4為內核的Wonder Gecko MCU7具有五種不同的低功耗模式,包括20nA的關機狀態和950nA的深度休眠模式(實時時鍾有效、RAM和寄存器內容保持、使能掉電檢測)。
  上麵提及的節能特性也能帶來其它優勢。例如,在超音波/聲學水表之類的應用中,它們必須在小電池供電下運行多年,需要MCU盡可能長的保持在休眠狀態。除了有助於減少MCU喚醒時間之外,Cortex-4 DSP和浮點算術指令也能使用成熟的濾波功能從廉價聲學傳感器輸出中獲得所需的信息,從而避免采用昂貴的超聲波流量傳感器。在這個應用實例中,Wonder Gecko MCU的外設還能夠作為模擬狀態機提供額外的能量節省,它僅僅在需要時才喚醒Cortex-M4處理器。
  
結論
  雖然並不完備,但這些林林總總的秘訣與妙方應該能讓各位產生好的思路,可以在下一次設計中充分利用Cortex-M係列中一些較不為人知的特性所帶來的好處

麻雀雖小 五臟俱全:MCU專用RTOS簡述

麻雀雖小 五臟俱全:MCU專用RTOS簡述

DIGITIMES中文網 原文網址: 麻雀雖小 五臟俱全:MCU專用RTOS簡述 http://www.digitimes.com.tw/tw/dt/n/shwnws.asp?CnlID=13&packageid=9376&id=0000424643_EE45QU335SXGR42FQO53O&cat=10&ct=1#ixzz3wuesZBnC


微控制器(MCU)廣泛應用在各行各業,如各式家電、工業自動化,即時控制、資料採集等領域,為因應工控所需的即時(Realtime)控制、快速回應等需求,因此MCU大多搭載RTOS(即時作業系統)運作。隨著物聯網的興起,軟體業也為RTOS加入物聯網的成分,以提早卡位物聯網的核心軟體市場…


各種處理器專用之OS

在一般功能(General-purpose)的處理器市場分類中,若以功能與執行速度來說,大致分為CPU > MPU > MCU。CPU的功能最強,主要應用在電腦產品;MPU功能次之,其應用多元,主要應用在嵌入式系統與精簡型電腦等多種;而MCU則是以單一應用為主,應用在各式家電、電子產品、嵌入式產品、穿戴式裝置、物聯網(IoT)應用產品等控制應用。

MCU內部整合了KHz~MHz級的CPU、KB~MB級的記憶體單元(RAM與ROM/EEPROM/Flash)、時脈產生器(Oscillator;Clock Generator)、與I/O擴充單元等,可視為一種速度較慢的系統單晶片(SoC)。

由於內部記憶體容量小,因此大型作業系統如Windows、Linux等是不可能塞入MCU去執行的,且MCU大多被應用在即時控制的環境,因此許多容量小的RTOS(Real-Time Operating System;即時作業系統),便成為開發MCU軟體的主要平台。


主打嵌入式應用的中高階RTOS

RTOS的種類繁多,主要設計給基於MPU或MCU的嵌入式系統所使用。例如MPU等級專用的有Integrity、QNX、VxWorks等功能強大之RTOS;至於體積較小巧,主要支援MCU等級為主的RTOS,則有Nucleus、ThreadX、Unison OS、ucOS II/III等等。

以Green Hills Software推出的Integrity OS為例,就是一種支援MPU (甚至CPU等級)為主的RTOS。其強項在於Integrity-178版本已通過EAL 6+?(資訊安全)認證與DO-178B(飛安環境) A級認證,被應用在極度重視安全和可靠性的市場,例如戰鬥機(如B-2、F-16、F-22、F-35)與民航機(如Airbus A380)等領域。該RTOS支援ARM、XScale、Blackfin、Freescale (已併入NXP) ColdFire、MIPS、PowerPC、AMD x86(嵌入式APU)等CPU/MPU平台。

另一個知名的QNX RTOS,採用微核心架構,是唯一成功打入商用市場的OS,其強項是多媒體的即時處理能力,適用於車(機)上娛樂裝置與手機等嵌入式市場。QNX於2010年被BlackBerry購併,並開發出BB 10作業系統。QNX支援IA32、MIPS、PowerPC、SH-4、ARM、StrongARM、XScale等CPU/MPU平台。

至於像是IntervalZero的RTX、RTX64,則是設計來與微軟Windows共存共容的RTOS,搭配EtherCAT協定來做為工廠自動化的應用。其中,Windows主要負責GUI、儲存、運算,RTX則負責即時工控與資料採集,讓工控軟體開發更容易。以上的RTOS都是MB至GB等級的MPU等級OS,不適用於MCU的環境。


主打MCU應用的商用RTOS

中低階RTOS部分,主要是把軟體功能極盡精簡到MB甚至KB等級,使整個OS與主要應用程式,均可以塞入MCU裡的ROM/EEPROM/Flash。由於MCU應用的領域更加廣泛,其軟體必須力求更加精簡,因此MCU專用的RTOS大多具備非常高度模組化的架構,從核心、驅動程式、檔案系統、週邊I/O、網路支援等,都可以量身訂作,以利產品快速上市。

商用的RTOS有些會提供原始碼給授權客戶,而開源的RTOS則更能自由使用,讓開發人員可以編譯出程式碼最小、最佳化的執行環境。

由於各晶片廠所推出的MCU產品/開發板,都會有其對應的OS與IDE(整合軟體開發環境),但這些OS與軟體開發環境可能只適用於該廠的MCU產品,因此第三方軟體廠商,就開發出跨晶片/跨硬體平台的OS與IDE,讓開發人員不須因為換了硬體平台,軟體就必須全部改寫。

目前MCU OS/IDE市場佔有率最高的,大多是軟體公司所推出商用RTOS(搭配各廠商的MCU產品),然隨著ARM推出Cortex-M、Cortex-R等指令集架構,進軍穿戴式與物聯網應用市場,使得ARM架構(採開源碼)的RTOS開始有提升的趨勢。

Mentor Graphics旗下Accelerated Technology公司所推出的Nucleus,採Microkernel設計,號稱有30億個裝置導入,優勢是核心長度可以小至2KB,且開發人員不需要撰寫嵌入式裝置專用BSP(開發板支援套裝軟體),因此被廣泛應用到消費性電子、行動裝置、車用電子、智慧能源、醫療儀器、工業/工控等領域。

早期採用聯發科MT6217晶片的大陸山寨、白牌、雙卡2G手機,就是執行Nucleus RTOS。該RTOS支援ARM、MicroBlaze、MIPS、Nios II、Power、SuperH、XScale等嵌入式MCU架構。

Express Logic推出的ThreadX,則是一套免收權利金的RTOS,其優點是具備超快速的開機時間、反應時間,其Picokernel核心長度低於2KB,並通過安全規範,號稱有21億個裝置導入使用。例如HP的旗下印表機和事務機便採用該RTOS。可廣泛支援各式32位元MCU,包含ARM、Atmel、BlackFin、CoreFire/68K、EFM32、Freescale (NXP)、FM3、H8、XMC、M-Core、MicroBlaze、MIPS、Nios II、Power、STM32、StrongARM、Synopsys ARC、TI、Win32、x86/x386、XScale等等。

Wind River公司所推出的VxWorks,主要針對嵌入式系統設計,採Monolithic (單體式)核心,優勢是具備先佔式多工處理核心、循環執行、岔斷快速反應等特性,原生支援64位元處理器架構(x64)、可進行平行(SMP)/非平行(AMP)處理,累積至今有超過15億個裝置導入。

新版VxWorks 7則瞄準IoT所需要的可擴充性、安全性、連結性、繪圖能力、虛擬化等做強化,而全功能的VxWorks微核心長度只要20KB。VxWorks廣受科技業界的採用,登陸火星的Curiosity(好奇號)便採用VxWorks。該RTOS支援Intel x86(包含Quark SoC與x86-64)、MIPS、PowerPC、SH-4、ARM等CPU/MPU架構。

RoweBots公司的Unison OS,則是一款完全相容於POSIX(可移植作業系統介面)的RTOS,適用於MCU、DSC、DSP、SoC、FPGA等32位元的硬體開發環境,其好處是特別針對物聯網的應用,提升其系統安全性,且核心程式碼在某些應用架構可以低到僅1KB。支援Microchip PIC32、Renesas R32C/SH2A、ST STM32、TI ARM Cortex-M3等32位元MCU。

Micrium的μc/OS-II (microcontroller OS version 2),主打可攜、能在ROM執行、彈性、先佔式多工的RTOS核心,可管理高達250個應用任務。μc/OS-III則主打無限應用任務、幾近於零的岔斷,並可提供原始碼給客戶。

其優勢在於該系統原始碼開放、整潔一致、註釋詳盡,亦通過FAA認證與DO-178B認證,適合各種嵌入式與物聯網的系統開發,核心大小從5或6KB~24KB。至於μc/OS-III HW-RTOS,則是針對ARM Cortex-M為主的MCU做硬體加速。該RTOS可支援超過100種DSP、MPU、MCU。


ARM MCU促使開源RTOS興起

近年來由於ARM架構的處理器橫掃全球智慧行動裝置(手機/平板)市場,除了搭配各MCU/MPU硬體平台所推出的商用RTOS/IDE之外,為進軍物聯網與穿戴式的MCU級應用,ARM推出Cortex-M與Cortex-R的指令集架構,搭配開源的OS/IDE來搶佔MCU的應用市場。

例如ARM推出的mbed OS與相關開發環境,便著重於嵌入式裝置與IoT的應用,具備連接性、高效率、安全性、生產力的OS,搭配其mbed-rtos函式庫,亦可做為RTOS的應用。該mbed開發環境,可開發出智慧家庭、智慧城市、穿戴式等應用產品。

此外,坊間針對ARM平台所推出的開源RTOS/IDE很多,例如FreeRTOS、uKOS-II、Atomthreads、BeRTOS社群版、ChibiOS/RT、CoActionOS、eCos、Embox、Erika Enterprise/RT-Druid、Keil (ARM) RTX、Lepton、nOS、Nut/OS、NuttX、RIOT、RT-Thread、TI-RTOS-KERNEL(SYS/BIOS)、TNeo等等,讓開發人員有更多的選擇。


其他專用MCU的非即時OS概述

此外,也有許多針對MCU設計的開源OS (非RTOS),但同樣具有體積小的特性,有些是針對IoT的WSN(無線感測網路)應用,例如Contiki OS、TinyOS。而有些則具備一般桌上型圖形化使用介面(GUI),例如SymbOS、Wheels OS等。

Contiki OS是一套開源的微型OS,可應用在Atmel ARM/AVR、LPC、PIC32、TI MSP430/CC2430/2538/2630/2650、STM32W等MCU做IoT應用,也可在博物館級的8位元電腦(Apple II、Atari、Commodore等)做上網連線、甚至在骨灰級遊樂器(Atari Jaguar、Game Boy/Advance、GP32、任天堂紅白機、PC Engine等)上執行。

至於SymbOS,則是一套能在8位元Z80 CPU (如MSX、Amstrad)的古董電腦上執行之免費多媒體圖形作業系統,賦予如Windows 95般的操作畫面,讓舊電腦回春。

2015年6月24日 星期三

Hadoop vs small size files

HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)

http://www.open-open.com/lib/view/1330605869374

一、概述
手机图片或者像淘宝这样的网站中的产品图片特点:
(1)、大量手机用户同时在线,执行上传、下载、read等图片操作
(2)、文件数量较大,大小一般为几K到几十K左右

HDFS存储特点:
(1)      流式读取方式,主要是针对一次写入,多次读出的使用模式。写入的过程使用的是append的方式。
(2)      设计目的是为了存储超大文件,主要是针对几百MB,GB,甚至TB的文件
(3)      该分布式系统构建在普通PC机组成的集群上,大大降低了构建成本,并屏蔽了系统故障,使得用户可以专注于自身的操作运算。

HDFS与小图片存储的共通点和相悖之处:
(1)      都建立在分布式存储的基本理念之上
(2)      均要降低成本,利用普通的PC机构建系统集群

(1)      HDFS不适合大量小文件的存储,因namenode将文件系统的元数据存放在内存中,因此存储的文件数目受限于 namenode的内存大小。HDFS中每个文件、目录、数据块占用150Bytes。如果存放1million的文件至少消耗300MB内存,如果要存 放1billion的文件数目的话会超出硬件能力
(2)      HDFS适用于高吞吐量,而不适合低时间延迟的访问。如果同时存入1million的files,那么HDFS 将花费几个小时的时间。
(3)      流式读取的方式,不适合多用户写入,以及任意位置写入。如果访问小文件,则必须从一个datanode跳转到另外一个datanode,这样大大降低了读取性能。

二、HDFS文件操作流程
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
reading:
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
writing:
 HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
三、HDFS自带的小文件存储解决方案
对于小文件问题,hadoop自身提供了三种解决方案:Hadoop Archive、 Sequence File 和 CombineFileInputFormat
(1)      Hadoop Archive
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
    归档为bar.har文件,该文件的内部结构为:
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)

创建存档文件的问题:
1、存档文件的源文件目录以及源文件都不会自动删除需要手动删除
2、存档的过程实际是一个mapreduce过程,所以需要需要hadoop的mapreduce的支持
3、存档文件本身不支持压缩
4、存档文件一旦创建便不可修改,要想从中删除或者增加文件,必须重新建立存档文件
5、创建存档文件会创建原始文件的副本,所以至少需要有与存档文件容量相同的磁盘空间
(2)      Sequence File
sequence file由一系列的二进制的对组成,其中key为小文件的名字,value的file content。
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
创建sequence file的过程可以使用mapreduce工作方式完成
对于index,需要改进查找算法
对小文件的存取都比较自由,也不限制用户和文件的多少,但是该方法不能使用append方法,所以适合一次性写入大量小文件的场景
(3)      CombineFileInputFormat
CombineFileInputFormat是一种新的inputformat,用于将多个文件合并成一个单独的split,另外,它会考虑数据的存储位置。
该方案版本比较老,网上资料甚少,从资料来看应该没有第二种方案好。

四、WebGIS解决方案概述
在地理信息系统中,为了方便传输通常将数据切分为KB大小的文件存储在分布式文件系统中,论文结合WebGIS数据的相关特征,将相邻地理位置的小 文件合并成一个大的文件,并为这些文件构建索引。论文中将小于16MB的文件当做小文件进行合并处理,将其合并成64MB的block并构建索引。
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
从以上索引结构和文件存储方式可以看出,index是一般的定长hash索引,并且采用的是存储全局index文件的方式
read的过程是将小文件append到下文件后边,然后更新索引的过程
delete文件的过程采用lazy模式,更改的是FVFlag,在空间重新分配的过程中,才会根据该flag删除文件。

五、BlueSky解决方案概述
BlueSky是中国电子教学共享系统,主要存放的教学所用的ppt文件和视频文件,存放的载体为HDFS分布式存储系统。在用户上传PPT文件的 同时,系统还会存储一些文件的快照,作为用户请求ppt时可以先看到这些快照,以决定是否继续浏览,用户对文件的请求具有很强的关联性,当用户浏览ppt 时,其他相关的ppt和文件也会在短时间内被访问,因而文件的访问具有相关性和本地性。
paper主要提出了两个基本观点:
(1)      将属于同一课件的小文件合并成一个大文件,从而减轻namenode的压力,提高小文件的存储效率
(2)      提出了一种两级预取机制以提高小文件的读取效率,(索引文件预取和数据文件预取)索引文件预取是指当用户访问某个文件时,该文件 所在的block对应的索引文件被加载到内存中,这样,用户访问这些文件时不必再与namenode交互了。数据文件预取是指用户访问某个文件时,将该文 件所在课件中的所有文件加载到内存中,这样,如果用户继续访问其他文件,速度会明显提高。
BlueSky上传文件的过程:
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
BlueSky阅览文件的过程:
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
文件合并:
文件合并过程如果合并之后文件的大小小于block64MB的大小则直接存放到一个block中。(合并之后的文件包括local index文件)
如果合并之后的文件大小大于64MB有两种方式split这个大文件:
1、                 local index文件、ppt文件、standresolution picture series存放在一个block中,剩下的picture series存在在其他的block中。
2、                 在相邻block的连接处填充空白文件,具体过程:
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
文件映射:
文件的命名方式,分离的预取图片有其自身的命名方式,具体见paper。文件映射过程中,除了block中的局部索引文件之外,还有一个全局映像文 件。该文件存放的内容为
根据全局mapping table 就可以根据merged file name 和 block Id到namenode上得到datanode的信息,然后到根据到具体的机器上找到相应的block获取到localindex file,根据original file name从local index file中查到从而定位到data。根据预取策略,在此过程中也会预取到local index file 和相关的file

六、facebookHayStack解决方案概述
 HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS) HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
haystack是一个不同于HDFS的分布式系统,如果想在HDFS的基础上构建小文件存储系统,个人认为可以参考借鉴其索引结构的设计。
1、  directory 中有logical volume  id<->physicalvolume id。根据可以通过directory拼出来http:////id>/ 。 因此在directory端存在着映射以及映射
2、  根据url到store端之后,可以根据logicalvolume id获得相应的physical volume的位置,然后physical中存在super block,根据映射可以得到photo数据
七、TFS解决方案概述
TFS(Taobao !FileSystem)是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统,主要针对海量的非结构化数据,它构筑在普通的Linux机器 集群上,可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储,通常文件大小不超过1M,满足了淘宝对小文件存储的需求,被广泛地应用 在淘宝各项应用中。它采用了HA架构和平滑扩容,保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构,可将文件名映射到文件的物理地址,简化 了文件的访问流程,一定程度上为TFS提供了良好的读写性能。
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
TFS的块大小可以通过配置项来决定,通常使用的块大小为64M。TFS的设计目标是海量小文件的存储,所以每个块中会存储许多不同的小文 件。!DataServer进程会给Block中的每个文件分配一个ID(File ID,该ID在每个Block中唯一),并将每个文件在Block中的信息存放在和Block对应的Index文件中。这个Index文件一般都会全部 load在内存,除非出现!DataServer服务器内存和集群中所存放文件平均大小不匹配的情况。
TFS中之所以可以使用namenode存放元数据信息的一个原因在于不像HDFS的元数据需要存放,filename与block id的映射以及block id与datanode的映射。在TFS中没有file的概念,只有block 的映射信息。所有的小文件被拼接成block。所以namenode中只需要存放的映射以及的映射。这样一来元数据信息就会减少很多,从而解决HDFS的namenode的瓶颈问题。
在TFS中,将大量的小文件(实际用户文件)合并成为一个大文件,这个大文件称为块(Block)。TFS以Block的方式组织文件的存储。每一 个Block在整个集群内拥有唯一的编号,这个编号是由NameServer进行分配的,而DataServer上实际存储了该Block。 在!NameServer节点中存储了所有的Block的信息,一个Block存储于多个!DataServer中以保证数据的冗余。对于数据读写请求, 均先由!NameServer选择合适的!DataServer节点返回给客户端,再在对应的!DataServer节点上进行数据操 作。!NameServer需要维护Block信息列表,以及Block与!DataServer之间的映射关系,其存储的元数据结构如下:
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
八、一种提高云存储小文件效率的解决方案
(美国西北太平洋国家实验室2007年的一份研究报告表明,他们系统中有1 200万个文件,其中94%的文件小于64 MB,58%的小于64 kB。在一些具体的科研计算环境中,也存在大量的小文件,例如,在某些生物学计算中可能会产生3 000万个文件,而其平均大小只有190 kB。)
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)
系统为每个用户建立了3种队列:
序列文件队列(SequenceFile queue,SFQ),
序列文件操作队列(SequenceFile operation queue,SFOQ),
备用队列(Backup queue,BQ)。
其中,SFQ用于小文件的合并,SFOQ用于对合并后小文件的操作,BQ用于操作的小文件数超过SFQ或SFOQ长度的情况。
HDFS小文件处理解决方案总结+facebook(HayStack) + 淘宝(TFS)







Hadoop小文件问题

http://www.gfzj.us/series/small-files/2015/01/06/hadoop-small-file.html
海量小文件对于Hadoop来说是一个灾难。如果不可避免的要使用Hadoop处理小文件,此处提供一些方案。

Problems with small files and HDFS

小文件是指那些文件大小比HDFS block size(默认64M)小很多的文件。每个小文件即使size很小,仍旧会占用一个block,不会多个小文件共用一个block。如果你在使用Hadoop时需要存储小文件,那么就意味着你可能有很多小文件,否则不会选择使用Hadoop。但是,问题就在于HDFS不能处理大量的文件。
HDFS中每一个文件、目录或是block在namenode的内存中都对应一个对象,每个对象占用150个字节,因此,一千万个小文件,每个占用一个block,那么namenode就要消耗大约2G的内存。如果有更多的小文件,意味着namenode需要消耗更多的内存,而现有的计算机硬件可能会难以满足相应需求,且会导致集群难以扩展。
另外,HDFS并不是为了有效地访问小文件而设计的:其初衷是为了流式访问大文件。如果访问大量小文件,需要执行大量的seeks操作,并需要不断地从一个datanode跳到另一个datanode,从而获取每个小文件,然而,上述每个操作都是低效的数据访问方式。

Problems with small files and MapReduce

Map tasks通常是以block为单位进行数据的处理。如果文件非常小且文件数量极大,那么每个map task处理的数据就非常少,且需要启动大量的map tasks,而记录每个map task信息(bookkeeping)也需要一定的开销。举个例子:一个是单独的1GB的文件,在HDFS中存储到16个64MB blocks;另一个是10000个100KB的小文件,大约共1GB。这10000个文件每个都用一个map task处理,那么处理这些文件所需的时间要比第一种情况慢上十倍甚至百倍。
Hadoop提供了一些方法用于减少bookkeeping带来的开销:设置mapred.job.reuse.jvm.num.tasks属性,允许一个JVM同时执行多个map tasks,以这种重用task JVM的方式减少启动多个JVM的开销;使用MultiFileInputSplit,每个map task可处理多个blocks数据。
PS: bookkeeping是指在一个job的初始化阶段记录每个task的状态和进度。

One Example

一个非常典型的小文件案例就是存储海量图片,每个图片是一个单独的小文件,这种情况就需要使用一个容器把图片进行分组打包存储。

HAR files

为了缓解大量小文件带给namenode内存的压力,Hadoop 0.18.0引入了Hadoop Archives(HAR files),其本质就是在HDFS之上构建一个分层文件系统。通过执行hadoop archive命令就可以创建一个HAR文件。在命令行下,用户可使用一个以har://开头的URL就可以访问HAR文件中的小文件。使用HAR files可以减少HDFS中的文件数量。
下图为HAR文件的文件结构,可以看出来访问一个指定的小文件需要访问两层索引文件才能获取小文件在HAR文件中的存储位置,因此,访问一个HAR文件的效率可能会比直接访问HDFS文件要低。对于一个MapReduce任务来说,如果使用HAR文件作为其输入,仍旧是其中每个小文件对应一个Map task,效率低下。所以,HAR files最好是用于文件归档。
HAR File Layout

Sequence Files

除了HAR files,另一种可选是SequenceFile,其核心是以文件名为key、文件内容为value组织小文件。回到之前提到的10000个100KB大小的文件,你可以编写程序将这些文件放到一个SequenceFile文件,然后就以数据流的方式处理这些文件,也可以使用MapReduce进行处理。一个SequenceFile是可分割的,所以MapReduce可将文件切分成块,每一块独立操作。不像HARs,SequenceFile支持压缩。在大多数情况下,以block为单位进行压缩是最好的选择,因为一个block包含多条记录,压缩作用在block之上,比Record压缩方式(一条一条记录进行压缩)的压缩比高。
把已有的数据转存为SequenceFile比较慢。比起先写小文件,再将小文件写入SequenceFile,一个更好的选择是直接将数据写入一个SequenceFile文件,省去小文件作为中间媒介。
下图为SequenceFile的文件结构。HAR files可以列出所有keys,但是SequenceFile是做不到的,因此,在访问时,只能从文件头顺序访问。
SequenceFile File Layout

HBase

HBase也可用于存储小文件,前提是文件真的很小。

个人总结

对于海量小文件,该如何处理:
  1. 如果文件大小能保证在一个较小的范围内,使用HBase
  2. 如果小文件的大小不能保证,考虑将文件直接写入HDFS,并在HBase中存储其实际地址
  3. 如果小文件是每天都产生,那么可以考虑使用HAR files或者SequenceFile(或基于其的方式,如MapFile),并将源文件删除,在HBase中存储实际地址。
如果用户需要通过HBase中的地址访问存储在HDFS中的小文件,那么就需要写相关服务来提供该功能了。



http://blog.chinaunix.net/uid-20577907-id-3989644.html
一、概述
首先明确概念,这里的小文件是指小于HDFS系统Block大小的文件(默认64M),如果使用HDFS存储大量的小文件,将会是一场灾难,这取决于HDFS的实现机制和框架结构,每一个存储在HDFS中的文件、目录和块映射为一个对象存储在NameNode服务器内存中,通常占用150个字节。如果有1千万个文件,就需要消耗大约3G的内存空间。如果是10亿个文件呢,简直不可想象。这里需要特别说明的是,每一个小于Block大小的文件,存储是实际占用的存储空间仍然是实际的文件大小,而不是整个block大小
  为解决小文件的存储Hadoop自身提供了两种机制来解决相关的问题,包括HAR和SequeueFile,这两种方式在某些方面解决了本层面的问题,单仍然存在着各自的不足。下文讲详细说明。
二、Hadoop HAR
  Hadoop Archives (HAR files) ,这个特性从Hadoop 0.18.0版本就已经引入了,他可以将众多小文件打包成一个大文件进行存储,并且打包后原来的文件仍然可以通过Map-reduce进行操作,打包后的文件由索引和存储两大部分组成,索引部分记录了原有的目录结构和文件状态。其原理如下图所示:


  缺点:
  1. HAR 方式虽然能够实现NameNode内存空间的优化,但是他是一个人工干预的过程,同时他既不能够支持自动删除原小文件,也不支持追加操作,当有新文件进来以后,需要重新打包。
  2. HAR files一旦创建就不能修改,要做增加和修改文件必须重新打包。事实上,这对那些写后便不能改的文件来说不是问题,因为它们可以定期成批归档,比如每日或每周。
  3. HAR files目前还不支持文档压缩。
三、SequeuesFile
  Sequence file由一系列的二进制key/value组成,如果key为小文件名,value为文件内容,则可以将大批小文件合并成一个大文件。Hadoop-0.21.0版本开始中提供了SequenceFile,包括Writer,Reader和SequenceFileSorter类进行写,读和排序操作。该方案对于小文件的存取都比较自由,不限制用户和文件的多少,支持Append追加写入,支持三级文档压缩(不压缩、文件级、块级别)。其存储结构如下图所示:
示例代码如下所示:
  private static void writeTest(FileSystem fs, int count, int seed, Path file,
                                CompressionType compressionType, CompressionCodec codec)
    throws IOException {
    fs.delete(file, true);
    LOG.info("creating " + count + " records with " + compressionType +
             " compression");
  //指明压缩方式
    SequenceFile.Writer writer =
      SequenceFile.createWriter(fs, conf, file,
                                RandomDatum.class, RandomDatum.class, compressionType, codec);
    RandomDatum.Generator generator = new RandomDatum.Generator(seed);
    for (int i = 0; i < count; i++) {
      generator.next();
  //keyh
      RandomDatum key = generator.getKey();
  //value
      RandomDatum value = generator.getValue();
  //追加写入
      writer.append(key, value);
    }
    writer.close();
  }
  缺点:
  目前为止只发现其Java版本API支持,未在其他开发接口中发现相关版本的实现,尤其是LibHDFS和thrift接口中,可能真是C++阵营狂热支持者的一个悲剧。
四、Hbase
  如果你需要处理大量的小文件,并且依赖于特定的访问模式,可以采用其他的方式,比如Hbase。Hbase以MapFiles存储文件,并支持Map/Reduce格式流数据分析。对于大量小文件的处理,也不失为一种好的选择。



Hadoop关于处理大量小文件的问题和解决方法

http://os.51cto.com/art/201310/413719.htm

小文件指的是那些size比HDFS的block size(默认64M)小的多的文件。如果在HDFS中存储小文件,那么在HDFS中肯定会含有许许多多这样的小文件(不然就不会用hadoop了)。而HDFS的问题在于无法很有效的处理大量小文件。
小文件指的是那些size比HDFS的block size(默认64M)小的多的文件。如果在HDFS中存储小文件,那么在HDFS中肯定会含有许许多多这样的小文件(不然就不会用hadoop了)。而HDFS的问题在于无法很有效的处理大量小文件。
任何一个文件,目录和block,在HDFS中都会被表示为一个object存储在namenode的内存中,没一个object占用150 bytes的内存空间。所以,如果有10million个文件,没一个文件对应一个block,那么就将要消耗namenode 3G的内存来保存这些block的信息。如果规模再大一些,那么将会超出现阶段计算机硬件所能满足的极限。
不仅如此,HDFS并不是为了有效的处理大量小文件而存在的。它主要是为了流式的访问大文件而设计的。对小文件的读取通常会造成大量从datanode到datanode的seeks和hopping来retrieve文件,而这样是非常的低效的一种访问方式。
大量小文件在mapreduce中的问题
Map tasks通常是每次处理一个block的input(默认使用FileInputFormat)。如果文件非常的小,并且拥有大量的这种小文件,那么每一个map task都仅仅处理了非常小的input数据,并且会产生大量的map tasks,每一个map task都会消耗一定量的bookkeeping的资源。比较一个1GB的文件,默认block size为64M,和1Gb的文件,没一个文件100KB,那么后者没一个小文件使用一个map task,那么job的时间将会十倍甚至百倍慢于前者。
hadoop中有一些特性可以用来减轻这种问题:可以在一个JVM中允许task reuse,以支持在一个JVM中运行多个map task,以此来减少一些JVM的启动消耗(通过设置mapred.job.reuse.jvm.num.tasks属性,默认为1,-1为无限制)。另一种方法为使用MultiFileInputSplit,它可以使得一个map中能够处理多个split。
为什么会产生大量的小文件?
至少有两种情况下会产生大量的小文件
1.这些小文件都是一个大的逻辑文件的pieces。由于HDFS仅仅在不久前才刚刚支持对文件的append,因此以前用来向unbounde files(例如log文件)添加内容的方式都是通过将这些数据用许多chunks的方式写入HDFS中。
2.文件本身就是很小。例如许许多多的小图片文件。每一个图片都是一个独立的文件。并且没有一种很有效的方法来将这些文件合并为一个大的文件
这两种情况需要有不同的解决方式。对于第一种情况,文件是由许许多多的records组成的,那么可以通过件邪行的调用HDFS的sync()方法(和append方法结合使用)来解决。或者,可以通过些一个程序来专门合并这些小文件(see Nathan Marz’s post about a tool called the Consolidator which does exactly this)。
对于第二种情况,就需要某种形式的容器来通过某种方式来group这些file。hadoop提供了一些选择:
HAR files
Hadoop Archives (HAR files)是在0.18.0版本中引入的,它的出现就是为了缓解大量小文件消耗namenode内存的问题。HAR文件是通过在HDFS上构建一个层次化的文件系统来工作。一个HAR文件是通过hadoop的archive命令来创建,而这个命令实 际上也是运行了一个MapReduce任务来将小文件打包成HAR。对于client端来说,使用HAR文件没有任何影响。所有的原始文件都 visible && accessible(using har://URL)。但在HDFS端它内部的文件数减少了。
通过HAR来读取一个文件并不会比直接从HDFS中读取文件高效,而且实际上可能还会稍微低效一点,因为对每一个HAR文件的访问都需要完成两层index文件的读取和文件本身数据的读取(见上图)。并且尽管HAR文件可以被用来作为MapReduce job的input,但是并没有特殊的方法来使maps将HAR文件中打包的文件当作一个HDFS文件处理。可以考虑通过创建一种input format,利用HAR文件的优势来提高MapReduce的效率,但是目前还没有人作这种input format。需要注意的是:MultiFileInputSplit,即使在HADOOP-4565的改进(choose files in a split that are node local),但始终还是需要seek per small file。
Sequence Files
通常对于“the small files problem”的回应会是:使用SequenceFile。这种方法是说,使用filename作为key,并且file contents作为value。实践中这种方式非常管用。回到10000个100KB的文件,可以写一个程序来将这些小文件写入到一个单独的SequenceFile中去,然后就可以在一个streaming fashion(directly or using mapreduce)中来使用这个sequenceFile。不仅如此,SequenceFiles也是splittable的,所以mapreduce可以break them into chunks,并且分别的被独立的处理。和HAR不同的是,这种方式还支持压缩。block的压缩在许多情况下都是最好的选择,因为它将多个records压缩到一起,而不是一个record一个压缩。
将已有的许多小文件转换成一个SequenceFiles可能会比较慢。但是,完全有可能通过并行的方式来创建一个一系列的SequenceFiles。(Stuart Sierra has written a very useful post about converting a tar file into a SequenceFile—tools like this are very useful)。更进一步,如果有可能最好设计自己的数据pipeline来将数据直接写入一个SequenceFile。
【编辑推荐】