BLE(Bluetooth Low Energy)簡介

參考資料:

  1. TI BLE課程
  2. Core Bluetooth on iOS

Bluetooth Low Energy技術及其特點

  1. BLE是Bluetooth 4.0的一部份
  2. 特點為:低功耗(很省電,可以用一顆鈕扣般大小的電池,維持運作一年以上的壽命)、低延遲、低吞吐量(傳輸速度低)
  3. 不需要像傳統的藍芽,一定要經過MFi認證才可與蘋果設備連接。
  4. 傳輸速率低於100kb/s,而傳統藍芽則大於3mb/s
  5. BLE、傳統藍芽以及Wifi的比較:
    2013-11-15_171626
    如上圖所示,Wifi、傳統藍芽以及BLE都是在同一個頻段下,左圖紅色部份是三個廣播頻道,避開WIFI了幾個常使用到的頻段,也因此wifi與BLE可以有良好的互存性。在右上的圖代表這三種傳輸方式所需要的供電量,右下的圖則是顯示這三種的傳輸量的比較圖
  6. 現有的Bluetooth類型大致有下面三種,左邊的就是BLE,中間的可以連接BLE及傳統藍芽,右邊的只能與傳統藍芽設備或是Bluetooth Smart Ready連接,Bluetooth Smart Ready則可與這三種任何一種進行連接。
    2013-11-15_172908
  7. Bluetooth Dual Mode也就是上面所畫的Bluetooth Smart Ready設備,可同時與傳統藍芽以及BLE做連接。和BLE連接時便使用BLE的模式、耗電量也與BLE相同。和傳統藍芽則也是使用傳統藍芽的功耗、傳輸速度及模式。

Bluetooth Low Energy協議

  1. 分為Controller、Host及App層
    2013-11-15_174159

    1. Physical Layer:物理層
    2. Link Layer:鏈路控制層
    3. HCI:提供標準藍芽事件及通知層
    4. Logical Link Control and Adaption Protocol:負責連接和事件
    5. Security Manager:配對、數據加密這類
    6. Attribute Protocol:所有數據傳輸經過這層實現(ATT),定義了Client和Server,Client就傳Request,Server傳response。
    7. Generic Attribute Profile:具體實現數據的傳輸(GATT)。Server上所有的ATT都被實作了,成為一個個的。Services,通過這樣的形式把數據包給Client。把ATT定義的屬性根據不同的服務進行歸類、組合,同時把一系列的讀寫整合起來,成為一系列的數據通信操作流程,提供給上層的Profile去用。
    8. Generic Access Prifile:設備查找、連接建立(GAP),定義了四個角色
      PeripheralCentral:兩個設備連接後,進行通訊的角色。Peripheral通常是連接外面的設備(從設備),例如說血壓計等等。而Central則是連接主設備,例如手機、電腦等等。Peripheral通常是ATT及GATT的Client,Central通常是ATT及GATT的Server。
      BroadcasterObserver:兩個設備在不見連接的時後,進行通訊的角色。Broadcaster會通過一個簡單的設備,不斷的把數據丟出去,例如一個單純的溫度計。Observer則接收這些封包把相應的溫度值儲存起來。
    9. App層:一些PROFILE和一些應用組成。在APP層經過Profile的實做,來做讀寫操作的動作。

Connection parameter連接參數

  1. 連接參數會直接影響BLE的性能以及功耗,非常重要
  2. 在兩個BLE設備建立連接以後,所有的通信都是在Connection Event進行通訊,下圖是一張BLE通訊時耗電量的示意圖,橫軸代表時間、縱軸代表耗電量。所以可以看到,設備建立連線的大部份時間,都是處於Sleeping狀態下,並且在此時耗電量很低,這也是BLE省電的主要原因。另外在每次的Connection Event開始時,會由Master發起通訊要求,然後由Slave回覆
    2013-11-18_174034
  3. 參數介紹:
    Connection Interval:多久開始一次Connection Events。這會影響到BLE的傳輸速度和耗電。
    Slave Latency:為了節省Slave的電源,當Slave沒新的事件要傳給Master時,最多可忽略幾個Master發起的通訊要求。
    Supervision Timeout:設定當多久沒有收到任何通訊要求時,中斷連線。
    上面數值必需滿足以下條件Supervision Timeout > (1 + Slave Latency) * (Connection Interval)
    這是因為Slave Latency不能算在Supervision Timeout裡面,否則會造成不正常斷線
  4. 上面三個參數都是可以在連線建立之後動態修改的,因此實際應用開發的時候,大家可以根據實際需求配置上面三個參數

產品上市

  1. 產品要在全球各地的市場上市,要能夠通過SIG的認證(https://www.bluetooth.org/)
  2. 另外有一個Unplug Fests,可以測試藍芽相關功能
  3. 相關資訊請看:http://v.youku.com/v_show/id_XNTk4MDU1NDY4.html

蘋果對iOS上的BLE開發要求

  1. 在連接時iPhone設備時,不能直接取得IEEE的地址,而是取得一個resolvable address。也因此無法直接對iOS設備做advertisements
  2. 連接參數上,Interval必需大於20毫秒,小於2秒。Supervisor time 小於等於6秒。Slave latency小於等於4秒。
  3. 在iOS裡,會隱藏藍芽物理地址、Characteristic handles、Characteristic descriptors、以及連接參數。雖然連接參數在iOS裡是可以設定的,但假如在連接後,經由Slave去修改連接參數,則這些被修改的數值是沒辦法取得的。
  4. 我們無法直接獲得IEEE地址,但在iOS7裡可以使用UUID來進行連線
    2013-11-18_190345
  5. 重新連線的狀況:分別看前景、背景、暫停狀況下的設定方式
    2013-11-18_190436
  6. 尋找外接設備
    2013-11-18_190810

CDN – 內容傳遞網路

CDN(內容傳遞網路)

在wiki上的解釋是:
內容傳遞網路(Content delivery network或Content distribution network,常簡寫成CDN)是指一種透過網際網路互相連接的電腦網路系統,提供高效能、可擴展性、及低成本的網路將內容傳遞給使用者。

簡單來說,CDN就是在全球各地怖署節點,讓使用者可以就近從最近節點取得快取檔案,像是我們架網站時,可把一些共用的如JQuery函式庫、靜態圖片等檔案放置到CDN伺服器(如這篇文章: [JQuery]使用CDN來載入JQuery)來加快網站的讀取速度。也可以避免被攻擊者使用DDos的方式來癱瘓伺服器。

CDN的功能及優點包括

  1. 高效能:CDN可以讓使用者「就近取得檔案」,內容提供者事先將檔案推到全球的 CDN 節點,在台灣的下載者儘量從台灣取得檔案,在日本或香港的下載者也儘量從當地的伺服器取得檔案。並且因為下載者透過 CDN 下載靜態元件,可以減少原始 server 的負荷。
    ps: 要決定使用者到那個節點要決定使用者應該要到哪組 server 通常有這些方法:

    1. GeoDNS
    2. Anycast
    3. HTTP Redirect (會比較差)
  2. 高可靠度:當今天主要網站當機了,使用者可以從CDN的備援網站去讀取檔案,不至於讓整個網站癱瘓。也可以避免DDos的大量機器人攻擊來癱瘓網站。
  3. 低成本:因為內容提供者不需要在一個 data center 上建立非常粗的水管。舉例來說,如果傳遞需要 100Gbps 的流量,利用 CDN 架構(將資料提供者分散在世界各地),每個 data center 也許只需要 5Gbps 的流量。由於十個 10Gbps 網路與 100Gbps 網路的成熟度不同,成本也會不相同。

CDN提供的服務者包括Akamai、Amazon CloudFront等等(請見下圖)


這是我從別的網站找來的CDN運作示意圖
原本我們讀取網站的模式如下圖,我們會先去和DNS從網址要到伺服器ip,
再去用ip和我們的網頁伺服器讀取網頁內容

clip_image010
使用CDN的架構後,使用者用網址和DNS伺服器要ip位置時,
CDN的DNS伺服器會從使用者所傳來的資訊,去判別離使用者最近的CND節點,
然後使用者再去和該CDN伺服器要取檔案,
因此當某個節點壞掉時,網站還是可以藉有其他節點去正常運作

clip_image012

下面有一些我找的資源

  1. 淺談私有 CDN(內容傳遞網路)佈署 :http://blog.lyhdev.com/2012/02/cdn.html
  2. 免費的雲端加速代理網路-CloudFlare:http://blog.soft.idv.tw/?p=1110
  3. 內容傳遞網路 :http://zh.wikipedia.org/wiki/內容傳遞網路
  4. Amazon CloudFront (CDN) – 內容傳遞網路 : http://ten2.tw/blog/amazon-cloudfront-cdn/
  5. CDN服務提供者:http://blog.gslin.org/archives/2009/03/09/1965

初探Hadoop開放原始碼平台環境

開放原始碼的雲端運算平台技術(1)

初探Hadoop開放原始碼平台環境
文/圖 沈炳宏.責任編輯/洪羿漣

大量資料的處理一直是電腦科學與實務應用中非常重要的課題,雲端運算的風起雲湧也使得分散式運算這項技術成了新顯學,整合MapReduce演算法並已被 各大企業所廣泛採用的Hadoop套件,更是開發雲端運算技術的佼佼者,本系列文章將會帶領讀者一步步瞭解並活用該技術。


近年來最熱門的雲端運算(Cloud Computing),其概念結合了IaaS、PaaS、SaaS、Web 2.0和其它相關技術(如MapReduce、Ajax、虛擬化),共同在網際網路架構上,來滿足使用者在運算資源的高度需求。目前雲端運算有各家專業研 究機構分別提出了不同的定義,如表1所示。

雲端運算不是一項新興技術,而是一種過去就有分散式運算(Distributed Computing)的形式,與代表多台電腦同時進行運算與叢集運算(Cluster Computing)的概念類似,皆是指透過整合大量電腦的運算資源來處理運算需求。

不過叢集運算多為硬體業者採用,強調同一資料中心中的大量電腦;雲端運算則納入網際網路的概念,由遠端網際網路上的伺服器群進行資料的存取與運算,由於這 些伺服器群可能分散在各處不同的資料中心,同時處理來自各地成千上萬使用者的需求,從使用者的觀點來看,根本無從分辨是哪一台伺服器處理了自己送出的運算 需求,如同把需求送入模糊的雲朵中一般,因此便將這種分散式運算模式稱為雲端運算。

諸如Google、Yahoo和Amazon等大型網路公司,由於財力雄厚,可以採購數以萬計的伺服器,叢集便成為一個龐大的運算資源,讓使用者得以透過 網路來存取資料或進行運算,而近年來爆紅的Facebook,也將Hadoop使用在分析Facebook塗鴉牆上某一關鍵詞出現頻率的Lexicon專案,以及改善使用者體驗、搜尋結果等功能上。

雲端服務 vs. 雲端運算
除了雲端運算這項口號之外,還有人提出了雲端服務的概念,這是由於雲端運算通常指的是在網路上提供且為商業和客戶服務的消費模型,這些服務包含了以資訊科 技為主的服務,如軟體即服務(SaaS, Software as a Service)以及提供伺服器運算及儲存能力的服務等,但實際上還有更多和資訊科技無關的商業和客戶的服務,如線上購物、銷售、娛樂等,而這些服務多半 與運算的功能無關,而更為貼近人們的生活,對這些客戶而言,他們所使用的不是雲端運算這項功能,而是由雲端運算環境所提供的雲端服務。

若要更明確的定義這兩者的區別,雲端服務專注在藉由網路連線從遠端取得服務,如提供使用者安裝和使用各種類型作業系統的Amazon EC2服務。這類型的雲端運算可以視為軟體即服務概念的延伸,利用這些服務,使用者甚至可以只靠一支手機做到許多過去只能在個人電腦上完成的工作。

雲端運算則是著眼於利用虛擬化以及自動化等資訊技術,來建構和普及電腦中的各種運算資源,這種類型可以視為傳統資料中心(Data Center)的延伸,且不需要經由第三方機構提供外部資源,便可套用在整個公司的內部系統上。

IDC研究機構則針對雲端服務和雲端運算提供了更清楚的定義,所謂的雲端服務應該有如表2的特性。

透過這些特性,可讓雲端服務的提供者和消費者享受到比起傳統服務遞送模式更為簡易且便宜的優點,這些特性可以降低花費,加速服務遞送的速度,簡化存取的方式,大量增加可用服務的數量和內容,並增進了服務整合性的可能。

雲端運算包含了六種特性,如表3所示;可提供的遞送模型則有SaaS、PaaS、IaaS等三種類型,如表4;部署模型則有私有雲、社群雲、公眾雲和混和雲等四種類型,如表5。

雲端運算架構
實際上雲端運算就是一種分散式運算的實作模式和概念,透過由網際網路所構成的「雲」中,以動態可擴展性和虛擬化的運算資源來提供Web服務,將龐大而複雜 的運算處理程序自動拆解成無數個較小的子程序,交由多部伺服器所組成的龐大電腦叢集進行分散和平行運算分析後,將處理結果回傳給雲端使用者。

對於這些雲端技術和基礎設施,使用者無須擁有專業知識和任何控制權,透過雲端運算,服務提供者可以在數秒之內,達成處理數以千萬計甚至億計的資訊,達到和超級電腦同樣強大效能的各式各樣網路服務。

提供雲端運算時,會涉及的軟體系統架構,通常涵蓋多重的雲端元件,這些元件會透過應用程式設計介面如Web服務來相互通訊,雲端架構會延伸至用戶端,讓用戶端的瀏覽器和軟體應用程式得以存取雲端應用程式。

軟體應用程式的設計,可透過網際網路隨需使用服務,以雲端架構做為建置基礎的應用程式,是一種基本的運算基礎架構,有需要時才會使用(例如處理使用者要 求);可以隨需獲取必要資源(例如運算伺服器或儲存設備)、執行特定工作,然後放棄不需要的資源,通常會在完成工作後自我處置。

透過雲端運算可以解決與大規模資料處理有關的重大難題,如:
●在不同機器上分配與協調大規模工作、在不同機器上執行程序,並在某一部機器故障時,提供另一部機器以供回復。
●根據動態工作量,自動調整所需資源。
●在完成工作時擺脫這些機器。
●取得應用程式所需的大量機器。
●在有需要的時候取得機器。

組成雲端運算的架構則如圖1所示,由下而上分別為基礎架構平台、儲存服務、平台服務、應用程式服務以及客戶端所組成。基礎架構提供了虛擬化運算、電腦叢集、硬體抽象化、虛擬化等硬體服務功能,以及可由使用者配置的運算環境作業系統、網路,記憶體、磁碟、CPU等設定。

圖1:雲端運算架構。

儲存服務表示雲端上的分散式持續資料儲存,其可能使用不具結構化的傳統式檔案系統來進行資料儲存,例如:HDFS、Key-Object pair、Amazon S3,或者結構化的資料儲存如Amazon SimpleDB、Google AppEngine DataStore;平台服務則是提供開發與執行應用程式服務的雲端平台,例如Google App Engine可讓開發人員在Google的基礎架構上,執行Web應用程式,其中也提供了Java與Python程式語言的執行環境,並完全支援通用的 Web技術與服務,以便用來執行MapReduce應用程式的開放原始碼分散式運算平台;客戶端則是仰賴雲端運算架構來執行應用程式服務,主要操作介面是 透過主流的瀏覽器,如微軟Internet Explorer、Mozilla Firefox、Google Chrome,以及智慧型行動裝置,如Android、iPhone、Windows Mobile。

接下來的文章中將會介紹由Apache所提供開放原始碼的Hadoop雲端運算開發環境,並分別探討在Hadoop中核心的Map-Reduce演算法概念,以及由Hadoop所延伸的HDFS、HBase、Pig、ZooKeeper等套件。

Hadoop簡介
Hadoop的原始作者是Doug Cutting先生,其過去就開發了Apache Lucene文字搜尋引擎,這是用Java設計的高效能文件索引引擎API,其可索引文件中的每一字,讓搜尋的效率比傳統逐字比較還要高的多,而在開發這個元件的過程,也進而開發了Apache Nutch這個基於開放原始碼所開發的網頁搜尋引擎元件。

其利用了Lucene函式庫開發,並加入了許多與網頁協定相關的特性,如網頁爬蟲(Web crawler)、網頁連結架構資料庫、HTML和其他文件格式的剖析器等,在Nutch 0.8版之後,Hadoop為獨立項目演變為獨立的Hadoop開發套件。

Hadoop這個代號並不代表任何英文字彙或者縮寫代碼,其是一個無中生有被創造的名稱,作者曾經針對這個名稱做過相關解釋,Hadoop名稱來自於作者 小孩的一個絨毛填充黃色大象玩具,而官方的吉祥物也採用了該圖案(圖2),主要原因在於開發這項套件的過程中作者需要為開套件提供一個代號方便溝通,而 Hadoop這個名字具備了幾個特性,如相當容易拼字和發音,毫無意義、且沒有在任何地方使用過,因此雀屏中選。

在Hadoop其後所發展的幾個相關套件和模組也都參考了這樣的方式,名稱都不會與主要功能實際相關,而會採用與大象或其他動物的概念來命名作為其開發代號,某些較小的模組功能則會給予較有意義的名稱,如jobtracker會用來追蹤MapReduct的作業。

其實Hadoop(圖2)命名的概念也非常類似當年Google命名的由來,Google是英文單詞「Googol」按照通常的英語拼法改寫而來的。Googol是一個大數的名稱,也就是10的100次方,表示1後面加上100個零。

圖2:Hadoop吉祥物。

乍看之下好像沒有特殊之處,但實際上該數字比宇宙所有的基本粒子數量總和還要大。Googol這個字是由美國數學家Edward Kasner九歲的侄子Milton Sirotta發明的,後來在數學家Edward Kasner和James Newman的著作《Mathematics and the Imagination》(http://tinyurl.com/lxunra)中被引用,Google公司使用這個字顯示了公司想征服網路無窮無盡資 料的夢想,最後沒有選用Googol可能是因為版權的問題,而且當註冊Google.com網域的時候已經被註冊。

Hadoop的定位是用來處理與保存大量資料的雲端運算平台,目前屬於Apache頂層專案,在Hadoop中包含了最著名的分散式檔案系統(HDFS)、MapReduce框架、儲存系統(HBase)等元件,如圖3所示,以及根據Hadoop延伸發展的其他子專案:
●Core:一組用於分散式檔案系統和一般性I/O之用的元件和介面。
●Avro:提供高效能、跨語言以及可保存資料的RPC資料序列化系統。
●Pig:超大資料集的資料流語言以及執行環境,可在HDFS和MapReduce叢集環境中執行。
●ZooKeeper:分散式且高可用性的協調服務,可為建置分散式系統提供分散式鎖定等原始鎖定功能。
●Hive:分散式資料倉儲,透過Hiave可管理存放於HDFS的資料,並提供根據SQL發展的查詢語言來查詢資料。
●Chukwa:分散式資料收集和分析系統,其會執行收集器以便在HDFS中儲存資料,且會使用MapReduce來產生報表。

圖3:Hadoop組成元件。

Hadoop主要核心完全使用Java開發,而使用者端則提供C++/Java/Shell/Command等程式開發介面,目前可執行於Linux、Mac OS/X、Windows和Solaris作業系統,以及一般商用等級的伺服器。

在Hadoop中最核心的演算法參考了由Google針對大量資料處理所累積的經驗,並於2004年所發表的MapReduce演算法,隔年Doug Cutting隨即公佈Apache Nutch開始採用全新的MapReduce實作。而在2006年Hadoop程式碼從Apache Nutch移至全新的Lucene子專案,2008年Hadoop成為 Apache頂層專案。

MapReduce
MapReduce誕生源由是Google需要進行大規模資料處理,而在這個過程中,發現了處理大量資料時會面臨某些共同問題,如需要使用許多機器協同計算,以及處理輸入資料時有兩項基本作業:Map和Reduce。

這兩項作業主要是受到函數編程的啟發,以Map/Reduce為基礎的應用程式,能夠運作在由上千台PC所組成的大型叢集上,並以一種可靠容錯的方式平行處理上P級別的資料集。

在函數編程中很早就有了Map和Reduce觀念,其實類似於演算法中各個擊破的作法(Divide and Conquer),也就是將問題分解成很多個小問題之後再做總和。Map函數的輸入是一個鍵/值序對組,輸出則為另一組中繼過渡的鍵/值序對組。而 Reduce函數則負責針對相同的中繼過渡的鍵/值序對組合併其所有相關聯的中繼值,並產生輸出結果的鍵/值序對組,如圖4所示。

圖4:MapReduce運算方式。

MapReduce則是由Google所發展的軟體框架,目的是對電腦叢集上的大型資料集執行分散式運算,讓使用者可以把心力放在定義Map和 Reduce函數,MapReduce框架會協調機器資源配置並處理的程式輸入、輸入與執行,所有的執行細節交由MapReduce框架處理。透過 MapReduce可以用於大型資料處理,例如:搜尋、索引製作與排序,大型資料集的資料採礦與機器學習,大型網站的網站存取日誌分析等應用。

HDFS
HDFS的設計理念是在分散式的儲存環境裏,提供單一的目錄系統 (Single Namespace),一個典型的超大型分散式檔案系統中,通常會有數萬個節點、數億個檔案、以及數十Peta Bytes的資料量,而這樣的分散式檔案系統具備的資料存取特性為Write Once Read Many存取模式

也就是檔案一旦建立、寫入之後就不允許修改,在這之中,每個檔案被分割成許多區塊(block)與異地備份,每個區塊的大小通常為128 MB,系統會將每個區塊複製許多複本(replica),並分散儲存於不同的資料節點(DataNode)上。

除此之外,HDFS中很重要的概念是其認為移動運算到資料端通常比移動資料到運算端來的成本低,這是由於資料的位置資訊會被考慮在內,因此運算作業可以移至資料所在位置,處理資料的檔案複本預設是每個檔案儲存3份,該設定可由開發人員自訂。

HDFS採用的是一般等級伺服器,因此透過複製資料的方式以因應硬體的故障,當偵測到錯誤時,即可從複製的備份資料執行資料回復。圖5所示為HDFS架構,未來會陸續在專欄文章中進行更深入的HDFS探討。

圖5:HDFS架構。

HBase
簡而言之,HBase的目標是作為Hadoop所使用的資料庫,這可讓我們需要在隨機且即時的讀寫超大資料集時所使用。HBase是一種分散式儲存系統, 其類似RDBM資料表的資料結構(Multi-Dimensional Map),並具備高可用性、高效能,以及容易擴充容量及效能的特性。

HBase適用於利用數以千計的一般等級伺服器上,來儲存Petabytes級的資料,其中以Hadoop分散式檔案系統(HDFS)為基礎,提供類似Bigtable的功能,HBase同時也提供了MapReduce程式設計的能力。

在HBase中使用了和Bigtable非常相似的資料模型,使用者在資料表中儲存許多資料列,每個資料列都包括一個可排序的關鍵字,和任意數目的資料列,資料列的格式會以:

所有的更新操作都有時間戳記(Timestamp),HBase對每個資料列單元,只會儲存指定個數的最新版本。客戶端可以查詢從某個起始點的最新資料,或者一次得到所有的資料列版本,圖6所示為HBase架構,未來會陸續在專欄文章中進行更深入的探討。

圖6:HBase架構。

小結
將服務搬到網際網路已逐漸為現今各資訊服務業者的共識,因此,本土軟體業者在研發新的軟體產品時,應以雲端服務的方式進行產品研發,至於早就出現在市場且系統功能趨於成熟的軟體產品,如企業資源規劃(ERP)等系統,則應視狀況開發出一套可於雲端執行的版本。

發展雲端運算及雲端服務是台灣軟體業者走入國際舞台及擴大市場占有率的捷徑,雲端服務市場的崛起將會是未來1、2年的事情,台灣軟硬體業者能否立即投入該 市場,將是決定其能否在該市場占得一席之位的關鍵。透過Hadoop的協助,開發人員將無須深入瞭解分散式運算應用程式所需的各種知識,僅需要將大量資料 和解決方式實作Map和Reduce,快速建構出雲端運算的執行環境和服務。

【原文刊載於RUN!PC雜誌:2009年11月號】