第二章 文獻探討
第三節 雲端運算
一、 Hadoop
端運算不是全新的技術，在 1959年6月，Christopher Strachey 就己經發表虛擬化論文，
1961年，電腦運算能力如同水電可以隨取即用的概念由 John McCarthy，雲端運算的第 一個學術定義 在 1997年由南加州大學教授Ramnath K. Chellappa 提出，1999年第一個商 業化的IaaS（虛擬主機）平台由 Marc Andreessen創建LoudCloud 所提供的服務。Google 在 2004年發表了 MapReduce論文，同年 Doug Cutting 和 Mike Cafarella 依照 Google 公開 的MapReduce 展開了 Hadoop 計畫。Hadoop主要由HDFS、MapReduce和Hbase組成，而 Hadoop HDFS 是對應到 Google File System（GFS）分散式檔案系統 ; MapReduce對應到 Google MapReduce；HBase對應到Google BigTable。自此Hadoop成為Yahoo、學術界廣 泛使用之雲端運算平台。2006年，Amazon相繼推出線上存儲服務S3和動態運算雲端EC2 等雲端服務。2008年1月，Salesforce.com推出了DevForce，Force.com平台是世界上第一 個平台即服務（PaaS）的應用。2008年4月，Google App Engine發布。2010年，台灣行 政院正式推動雲端運算產業發展方案，將雲端運算列為國家重要科技政策。隨著高速與
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
13
1. 分散式檔案系統（Hadoop Distributed File System）
其為非結構化資料庫系統，因此可以做為巨量資料的儲存端，同時為了解決處理資 料的速度問題，Hadoop提出資料在地化的概念，當使用眾多伺服器幫忙處理運算時，最 快的方法就是能直接在當台伺服器內取得資料，如此可以取得最好的處理效能。透過這 個基本的概念，Apache研發的分散式檔案系統可以儲存巨量資料且易於擴充，並且能運
Figure 9. 分散式檔案系統架構 資料來源：http://hadoop.apache.org/
作於便宜的普通硬體上，容錯性高，提供客戶總體性能較高的服務，其架構如上圖（Figure 9）所示。儲存於其中的資料被切割成許多小塊，並存至叢集內的不同機器裡，同時會 複製到整個叢集中的多台機器裡。如下圖（Figure 10）所示，每個資料塊（Block_N）
會複製兩個額外的資料塊到另兩個伺服器（Block_N' 和Block_N"），這兩塊複製資料被 儲存在不同的節點受到額外的保護。重複儲存的特性讓Hadoop可以切割細分工作（程式 運算或是資料分析），在同一時間透過叢集內所有的伺服器一起執行，如此便可以以加 速處理的速度。為了便於管理與檢索，透過master與slave 的結構，HDFS 叢集有兩種節 點，即一個NameNode（名稱節點)和多個DataNode(資料節點)，名稱節點是用來管理這 些複製至各處的資料塊，其類似一本電話簿，保留了全部資料（包括複製的資料塊）的 所有地址，讓Hadoop知道分工給哪台伺服器可以最有效率。[4][5]
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
14
Figure 10.資料塊儲存範例[4]
2. 並行分散式運算（MapReduce）
並行分散式運算是Hadoop的核心，是一種用於資料處理的編程模型，讓叢集內的數 百甚至數千台伺服器做龐大規模的同時運算。透過Map和Reduce兩個工作，首先會將要 處理的資料依使用者的設定分割成16~64MB大小，接著透過主要的節點伺服器master分 發多個Map和Reduce的任務給空閒的slave伺服器執行。運行Map任務的伺服器會將處理 完的資料暫存於緩衝記憶體內，負責Reduce任務的伺服器則依照Master伺服器的通知去 緩衝區取出資料進行任務－將處理完的資料進行合併。每台伺服器在並行分散式運算時，
會周期性的把工作的完成度和狀態的更新報告回報給主伺服器，確保當其中一台伺服器 出問題時，能將其工作分配給另一台伺服器。[4] [5]其運作狀態如下圖（Figure 11）所 示。
‧
HBase 是在Apache Hadoop的平台上提供了可擴展的結構化資料的分散式存儲系統，
以Google的BigTable為基礎，依託HDFS 作為存放裝置的基本單元，通過使用Hadoop 的 DFS 工具可以查看這些資料及其存儲結構，還可以通過MapReduce 對HBase 進行操作，
比起原生的HDFS更可提供開發者或使用者更為直觀的資料存取介面，讓資料能更有效 率的儲存及運用，並且能提供對於巨量資料隨機、即時的讀寫存取功能，目前已經是 Apache眾多開放原始碼項目中的一個大型專案。
在HBase裡面有兩個主要的概念，Row key和Column Family， Column family是在系 統啟動之前預先定義好的，每一個Column Family都可以根據“限定詞”擁有多個column；
Row key可視為RDBMS中的Primary key，但是因為HBase不支持SQL語法，因此只能夠 過Row key進行查詢。另外透過Time Stamp是資料操作對應關聯的時間戳記，可以看作 類似於版本資訊，用於管理資料庫的新舊資料。其基本的儲存結構如下表（Table 1）所 示：
Table 1Hbase邏輯數據模型[5]
RowKey Time Stamp
Column
“content:” Column “anchor:” Column
“mime:”
“nccu.edu.forum”
T3 “<html>…” “anchor:mis.nccu.com” “Forum” “text/html”
T2 “<html>…” “text/css”
T1 “<html>…” “image/gif”
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
16
透過欄位導向（column-oriented）的儲存機制，HBase將可以實現高性能的分散式讀寫操 作的優點，欄位導向的資料庫中，資料表的每列單獨存放，因此查詢時只涉及到被查詢 的列，如此就可以大量降低系統I/O。
類似於Hadoop的Master-Slave模式，HBase 中僅只有一個Master伺服器，負責管理所 有的HBase Region Server， Master本身並不存儲HBase 中的任何資料 ，而是將資料儲存 在不同的Region Server，因此當儲存空間不足時，只需加裝新Region Server 即可完成。
此外，HBase 邏輯上的資料表將被切分成多塊資料（splits），不同的split會被Master分 配给相對應的Region Server進行管理。如同下圖（Figure 12）所示。
Figure 12 HBase 邏輯資料表與儲存對照圖[5]
HBase為巨量資料的即時處理需求提供了一個開源的解決方案。它一方面使用HDFS 的高可靠性和可伸縮性的儲存功能，同時借鑒了GoogleBigTable的高效資料組織形式，
並且提供了一個類似於MySQL關聯式資料庫的shell操作介面，可對HBase內的相關資料 表和family進行新增、刪除及查詢等功能，亦可通過API，以程式的方式連結使用HBase 存儲的資料。
‧
合Mobile First的最新調查結果，台灣持有智慧型手機或平板電腦的族群約有1330萬人 [43]；預估到2015年，台灣智慧型手機普及率將達56.8%，平板電腦普及率也將達到24%。從數據上來看，很明顯的是，行動裝置的普及率會越來越高，對於未來可能至少人手一 台行動裝置。
一、 行動應用辦公室
“bring your own device (BYOD)”，行動應用辦公室成為了一個新興名詞，包括思科、
趨勢 …等多家企業已經開始在為此研發相對應的技術及安全措施。CIO Insight雜誌曾經 做過一次有關企業行動化的問卷調查，其中關於企業行動化所帶來的所有效益中，有 平板電腦，上段有提及的“bring your own device” ，則是開啟了讓行動裝置進入企業內部 的議題，透過行動裝置做為媒介，企業的主管能更快的即時的了解關鍵績效指標以及各 種資訊供己身作為決策的輔助，因此將行動裝置與商業智慧做一結合，更是時勢所趨。
思科針對600位美國IT人員與企業負責人進行調查(2012)發現超過四分之三 (76%) 的 受訪 IT 主管認為：BYOD 雖然給 IT 部門帶來了巨大挑戰，但是對他們的公司卻產生了
‧
根據(Aberdeen Group, 2010)調查指出目前行動裝置與商業智慧軟體的結合，行動網 頁為主流，但是在詢問高階主管之後，有一半以上的企業表示行動應用程式將會是未來 的主要發展方向。[1]
二、 混合型應用程式（Hybrid APP）
為了能夠在iPhone或Android上推出自己的軟體，開發人員就必須得花上不少時間先 學會這兩個平台上的相關開發技術，讓許多網頁開發者遲遲無法跨入這個領域。因此為 了解決這問題，出現有別於行動網頁（Web APP）和原生應用程式（Native APP）的開 發型態混合型應用程式，幾個 Wrapper 開發工具便應運而生。這些開發工具可以幫忙把 行動網頁打包成iPhone/Android 原生應用程式，也就是說，開發者可以延續過去的網頁 開發經驗，統一使用 JavaScript 撰寫應用程式，而不需要重新學習其他語言與開發平台。
透過下表（Table 2）可以清楚表示三者的優缺點。 Native API
使用者經驗 普通 普通 有經驗為佳
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
19
用者部署完成的程式時，自動處理複雜的跨平台轉換問題；其缺點會在程式載入和UI 界面反應會比原生應用程式（Native App）慢。
三、 Google Cloud Messaging（GCM）[14]
GCM是由Google開發用於傳遞資料從伺服器到手持裝置的免費服務，透過背景提示 訊息通知手持裝置的使用者有新的檔案產生，或是能傳遞不超過4kb大小的資料給該裝 置上的應用程式接收。以下將簡述其特性：
(1) 允許使用第三方應用伺服器，傳遞訊息至 Android 應用程式
(2) 此套服務使用推播（Push）的方式傳遞訊息，手持裝置上的應用程式不必保持著 啟動狀態，減低手持裝置的負擔，透過 Android 系統中的 Broadcast Receiver 發送 至對應且准許該權限的應用程式，並啟動該程式
(3) 透過服務產生的 ID 與 token 的使用確保任一方有權限，將訊息或是資料發送至正 確的裝置。
(4) 與過往的 Cloud To Device Message（C2DM）相比，GCM 能支援一對多及多對一 的傳送方式，單一伺服器可以透過各使用者註冊的 ID 發送至 1000 多台以上的手 持裝置；透過相同的註冊 ID，多方伺服器可以發送訊息至裝有同一台手持裝置。
GCM通過客戶端手持裝置上的應用程式、第三方應用伺服器及Google的GCM伺服 器建立整個架構，並透過認證機制維持其運作，整體運作機制流程透過下圖Figure 13分 述之：
Figure 13GCM架構與流程 資料來源：本研究整理
‧
‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
22
第六節 健保申報費用審查流程
全民健保的永續經營主要是建立在健保財務能否收支平衡，全民健保除1995年開辦 就小有虧損，1998年開始收支便出現逆差，各界對於健保財務危機產生恐慌，健保資源 浪費的議題被提上檯面，因此實施醫療服務審查有其必要性，審查健保申報費用有其行 為的必需性、恰當性，有助於提升醫療照顧品質、調合醫療資源使用度和改善醫療品質 管理[40]。
一、 現行審查流程
健保醫療費用案件審查流程如Figure 14，門診組承辦人員於受理醫療院所申報案件
健保醫療費用案件審查流程如Figure 14，門診組承辦人員於受理醫療院所申報案件