A Survey of Large Scale Data Management Approaches in Cloud Environments
Authors: Sherif Sakr, Anna Liu, Daniel M. Batista, and Mohammad Alomari
Publish: IEEE Communications Survey & Tutorials, Vol. 13, No. 3, Third Quarter, 2011
I. Introduction
Cloud computing 具有下列五點特性:
1. On-demand self-service. 消費者可以自行定義所需要的服務需求，如網路頻寬、網路儲存空間、服務時間等，並且不需要透過人員來設定，而是自動化產生相關服務。
2.Broad network access. 可以透過各種輕薄短小的設備使用服務，如手機、筆電、平板電腦等。
3.Resoure pooling. 提供者的運算資源全部合在一起形成一個資源阜，並且視消費者需求以多租戶方式進行動態的資源分配服務。這些資源可能包括儲存空間、記憶體、計算單元、網路頻寬、虛擬網路、虛擬機器等。
4.Rapid elasticity. 運算能力可以隨時迅速地擴充或縮減，消費者可以在任何時間購買到不受侷限的運算能力。
5.Measured Service. 在運算資源可以依需求彈性調整的同時，也需要合適的計費方式，透過監控資源的使用量，以公開透明的方式提供給消費者與服務提供商衡量費用的標準。
Models of Cloud Services可以分成三種Service models:
1. Infrastructure as a Service (IaaS). 提供運算資源服務，建設運算環境，如CPU、RAM、網路頻寬、儲存空間等，通常以虛擬機器的方式呈現，如Amazon EC2、S3等。
2. Platform as a Service (PaaS). 提供運算平台服務，讓使用者可以在平台上開發與執行自己的應用程式，平台的維護、負載平衡、擴充都由平台提供商負責，使用者只須要專心開發自己的應用程式功能就可以了。
3.Software as a Service (SaaS). 應用程式服務，提供使用者可以透過網路使用的應用軟體，使用者不需要下載、安裝任何套件即可使用。
Cloud deployment model根據擁有與使用的人來區分:
1. Private cloud. 由單一機構使用並且由此機構或第三方來管理。Private cloud提供對於效能、可靠度與安全性的最高控制能力。然而卻因為類似傳統的伺服器農場(server farms)無法提供無前置成本的好處而被批評。
2. Community cloud. 由多家機構成立一個社群來共同使用與維護。
3. Public cloud. 由一家大型企業提供雲端服務，如amazon, Google, Microsoft。由於消費者的需求是不同的，服務提供者需要確保交付具有彈性的服務內容。因此，服務提供者的品質可以用Service Level Agreement (SLA, 服務層級協議來制定。 SLA通常包含正常工作時間、隱私、安全與備份程序。 Public cloud具有的優點包括:不需要前置設備成本，將設備維護的風險轉移到設備提供商處。而缺點是無法精細的控制資料、網路、安全設定等可能阻礙效能的部件。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~以下備註~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Service Level Agreement；SLA)指的是服務提供者與使用客戶之間，應就服務品質、水準以及性能等方面達成協議或訂定契約。在設立SLA時，服務提供者首要之務，就是與使用者達成共識，決定整體方法與指導原則，並加以標準化。在SLA起頭階段，最重要的就是給使用者適當的期待，先有簡單的事情著手(如合約)，而非一開始就處理太多細節。
在設定SLA時，如果能落實下列幾項重點，可讓企業或機構更容易因為導入SLA而更優化整體管理流程。
(1)SLA必須以服務為導向，而且這樣的服務可以創造利商業益。
(2)制定SLA時，成本、價格以及服務內容應透明化。
(3)力求簡單明瞭，細節過多容易造成資料更新時的負擔。
(4)排列優先順序，首重為企業創造價值，避免分散焦點。
(5)盡快開始評估關鍵績效指標(KPI)。
(6)應設立明確的服務經理人。
過往由於各使用部門不甚瞭解IT運作邏輯，容易對系統產生不切實際的期待，以至於訂立的SLA過高。SLA訂得越高，代表系統的運作效能與可靠度都必須增加，勢必得大幅提高採購成本支出；然而，一般情況下，這樣的採購預算不易得到老闆的支持，因此IT部門往往無從落實這些SLA目標。不過，現在透過SLA管理軟體，可先瞭解各個系統實際的狀況，再進行修正，讓SLA較容易落實，且SLA的效益也較容易被看到。
DIGITIMES中文網 原文網址: 服務層級協議(Service Level Agreement；SLA) http://www.digitimes.com.tw/tw/dt/n/shwnws.asp?CnlID=10&Cat=55&Cat1=&id=100886#ixzz2I7MdapLz
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~以上備註~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4. Hybrid cloud. 由前三種cloud中兩個或多個組成。各個cloud依然是單一的個體，但是透過標準化或專門的技術將它們連繫在一起並確保資料與應用的可移植性。 像cloud bursting就是用來做clouds之間負載平衡的技術。 當private cloud能夠承受工作負載時不需要Hybrid cloud，當private cloud超出負載時，則利用Hybrid cloud將public cloud上的資源臨時結合到private cloud進行支援。 Hybrid cloud 提供應用資料比public cloud更緊密的控制與安全性，並且依需求擴充與收縮。在不利的一面，設計一個Hybrid cloud需要決定最佳的private cloud 與public cloud之間的分割。
Cloud computing 經常會與下列技術做比較:
1. Virtualization. 虛擬化技術，將實體機器、設備、資源抽象化，如CPU、記憶體、網路等。
2. Grid Computing. 格網運算，分散式運算的一種，協調以網路連接的運算資源來達成共同的應用目的。Cloud computing 比較類似於grid computing但是cloud computing 具有槓桿式分配運算資源的能力。
3. Utility Computing. 提供客計量型的運算服務，Cloud computing 可視為Utility computing的一種實現。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~以下備註~~~~~~~~~~~~~~~~~~~~~~~~
何謂Grid Computing？
其實 cloud computing 在概念上跟 grid computing 並沒有非常嚴格的區隔或是很大的不同，兩者均可看成是 distributed computing 衍伸出來的概念。
grid computing是 較早出現的名詞，出現在網路沒有現在那麼發達的時候，那時所提供的都是陽春型的網路服務，其主要概念是將包括軟、硬體的分散伺服器資源、資料庫、儲存設備 等，透過網路串聯以組成虛擬的超級電腦，進而分享運算資源。有效運用且聯結網路現有設備的資訊資源，隨而獲得更為強大的運算能力。
Grid Computing另可讓分散於各地的虛擬組織，協調彼此的資源分享，同時滿足大量運算的需求。而集合分散的運算資源之外，Grid Computing能夠經由網路管理組織內任何一個可使用的運算資源，進而降低伺服器的閒置時間。
在此架構下，企業可直接取得電腦、資料、軟體，或者是儲存設備。此外，對於誰可以分享、分享哪些資源、什麼條件可以允許分享等，Grid Computing同 樣提供嚴格管控功能與清楚的角色定義。
例子說明－假設現在台灣有一座運算中心，新加坡也同時有一座運算中心，當新加坡運算容量及能力不能負荷時，系統會自 動轉由台灣處理，且利用各地區閒置的計算能力及空間，運算完成後再回傳原本的主機系統。若應用至商業模式，服務商可以依照使用量計算，如同自來水電般收取 費用。
何謂Utility Computing？
主要提倡一種理想的企業資訊架構，讓IT服務模仿公用服務的方式進行，如供應水、電力、瓦斯。在公用運算的架構下，運算服務就像水電一樣隨時供應，同時可根據不同行業或不同部門的不同需求，隨時按照需求提供服務，包括自動提供可計算、量度的 IT資源，包括伺服器、儲存容量、商業應用程式及網路資源。使用者可經由內部網路或公開網路存取電腦取得運算資源。
計費方式以使用量計算，如CPU的使用秒數、分或是小時。在理想的狀況中，公用運算所提供的服務，會讓突發意外逐漸減少；而透過自動預估需求，以及預先建立伺服器可偵測不正常設備的能力，隨後提出預警，同樣可讓企業提高對於軟、硬體的使用效率。
結論－Utility Computing即是指供應商從網路提供應用程式或電腦處理能力傳送給客戶，客戶再依每月的運算量付款，就如同水、電、天然氣一般的服務。
以上內容來源:http://sls.weco.net/CollectiveNote20/Cloud
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~以上備註~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4. Autonomic Computing. 目的在於建立自我管理的運算系統建立能力。主要希望能減少人工干預，降低管理複雜度，而Cloud computing主要目的在降低運算資源成本。
Cloud computing減少企業投資在運算設備上的成本，包括storage, CPUs, network bandwith，並且在理論上具有無限展延的儲存空間，快速傳輸的網路能力。因此，從資料管理的角度來看，cloud computing具有完整的可用性:1.使用者可以在任何時間讀取與寫入資料。2.反應時間是個常數，不會受使用者數量，資料量大小或其他系統因素所影響。而且使用者不用擔心備份，雲端服務提供者必須替換損壞的元件並保證資料的可用性。 另一個使用cloud computing的理由是不需要前置投資，並且成本成長是呈線性並且可以預知的。
II. Cloud data management: Goals and challenges
A. Goals
基本上，越成功的cloud data management具有越多以下特性。
Availability. 必須要有網路錯誤或資料中心離線的狀態下還能夠存取。 Communication as a Service (CaaS)被提出來達成此目。
Scalability. 必須能支援巨量資料庫，以非常高效率低反應時間的方式回應要求。
Elasticity. 必須要能因應需求具有擴展或縮減，並且能從容應對這些改變的要求，迅速的回復到穩定的系統狀態。
Performance. 在public cloud上所付出的金額與所使用的配備呈線性關係，因此一個有效率的系統效能是節省金錢的關鍵要求。
Multitenancy. 必須要能支援多個應用(租戶)同時執行，同時各個應用之間所使用的資源是獨立的不受他人影響的。
Load and Tenant Balancing. 必須能夠自動的轉移負載使大部分的硬體得到有效的利用，避免資源超載的情況出現。
Fault Tolerance. 對事務性工作來說，當有錯誤事件發生時必須能夠迅速回復並且無遺失資料或更新回最近的狀態。並且及時worker node發生錯誤，仍然需要成功的提交任務並且讓工作持續進展。
Ability to run in a heterogeneous environment. 必須設計成能在異質環境執行並且透過適當的衡量方式來避免平行處理中效能退化的問題。
Flexible query interface. 應該要能支援SQL與non-SQL(例如MapReduce)。而且能夠讓使用者定義函數(User Defined Functions, UDFs)，當queries利用這些函數時能夠自動的平行處理。
B. Challenges
雲端運算這成長會遇到下列的障礙:
Availability of a Service: 由於雲端運算是基於網際網路上的分散式系統的環境，具有網路連接中斷的潛在可能性。因此，充足的可用性成了雲端運算的一大挑戰，因為即使是最輕微的中斷都可能造成在經濟上重大的後果與影響。
Data Confidentiality: 數據的移動會提高資訊安全風險，必須要有適當的預防措施，否則一些敏感的資料，如客戶資訊，信用卡資料有可能被第三方給取走。
Data Lock-In: APIs需要進行標準化讓使用者可以容易的轉移他們的資料跟程式。
Data Transfer Bottlenecks: 雲端使用者與提供者如果要最小化成本則必須考慮在系統的每一個階層之間安置與傳輸的涵義。
Application Parallelization: 只有在工作量可以平行化的時候，計算能力才能被彈性的分配使用。取得額外的運算資源並非像是換個大點的或強力的機器那麼簡單。額外增加的資源通常以分配工作項目額外的服務器差件來達成。
Shared-Nothing Architecture: Data management 在雲端環境執行時需要遵守Shared-Nothing Architecture，系統中每一個節點是獨立的，自給自足的，並且沒有單點爭論(??)。 大部分傳統的Data management並沒有使用Shared-Nothing Architecture 。
Performance Unpredictability: 許多HPC的應用需要確認一個城市中的每個執行序同時執行，而如今的虛擬機器跟作業系統並沒有提供此一功能。
Application Debugging in Large-Scale Distributed Systems: 在雲端運算程式設計中，如何切除在非常大型規模的分散式系統中所出現的錯誤是一大挑戰。因為這些錯誤可能不會發生在較小的資料量時，所以除錯就必須要在非常大量的資料上處理。
III Cloud Data Management Systems: State-of-the-art
A. Google: Bigtable/AppEnging Datastore
Bigtable: 參見http://blog.gslin.org/archives/2009/07/25/2065/
F. Cloud Data Management: Trade-offs
一般說來，雲端服務商提供為了網站應用的下列服務:
Elastic computer cluster. 提供彈性的運算能力來執行應用程式或回應需求。
Persistent storage. 類似傳統資料庫或檔案系統的儲存服務，用來存放應用程式的資料。
Intra-cloud network. 雲端內部的連結，連接應用程式所使用的運算資源與服務。
Wide-area delivery network. 連接外部的傳輸網路，用來從分散在世界各地的資料中心傳輸資料到終端主機上。
基本上，雲端服務商須保證一個近似於內部網路的高頻寬網路路徑。外部傳輸網路通常選擇離使用者最近的資料中心負責傳遞資料，因此，目前的雲端服務商在世界各地都建有資料中心，以此來降低外部傳輸網路的延遲。電力的使用成本與網路傳遞成本之間的取捨是服務商必須考慮的，分布在世界各地的主機可能會因為各地不同的能源成本而分攤費用，但是也可能因為各地網路提供商在建置網路上的成本給抵消掉，畢竟這兩者都是一直在變動的。
To be "everything for everyone" 在建立大型資料管理應用時需要去避免的錯誤。沒有一個系統是可以完美的滿足所有的工作，因此在設計應用程式的時候必須針對所應用的領域來設計，而系統設計時的權衡點會影響到效能的權衡點，這時所面臨的挑戰是如何找出影響效能權衡點最大的系統設計部分。為了解決這個問題Jim Gray提出經驗性的規則"20 queries"。主要概念是在進行每一個專案時必須要能定義出使用者要求這個資料管理系統回答的最重要的20個問題。
~~~~~~~~~~~~~~~~~~~~~~~~~~以下為註解~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACID，是指在資料庫管理系統（DBMS）中，事務(transaction)所具有的四個特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）、持久性（Durability）。
•原子性：一個事務(transaction)中的所有操作，要麼全部完成，要麼全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
•一致性：在事務開始之前和事務結束以後，資料庫的完整性限制沒有被破壞。
•隔離性：當兩個或者多個事務並發訪問（此處訪問指查詢和修改的操作）資料庫的同一數據時所表現出的相互關係。事務隔離分為不同級別，包括讀未提交(Read uncommitted)、讀提交（read committed）、可重複讀（repeatable read）和串列化（Serializable）。
•持久性：在事務完成以後，該事務對資料庫所作的更改便持久地保存在資料庫之中，並且是完全的。
資 料來源:http://zh.wikipedia.org/wiki/ACID
~~~~~~~~~~~~~~~~~~~~~~~~~~以上為註解~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
基本上在資料從遠距離複製時很難保證ACID這四種特性。CAP定理告訴我們在一個共享式資料系統中只能選擇CAP中最重要的兩項特性。
CAP的三個特性分別是
Consistency, 在副本中的所有的紀錄必須一致。
Availability, 所有的副本都可以接受更新跟填入。
tolerance to Partitions, 當分散式的副本們彼此間失去溝通時，系統還是可以照常運作。
在實踐上，對雲端應用來說永遠能夠接受更新的要求是具有高度重要性的，即使資料同時被讀取中。為了處理局部故障的系統問題，雲端應用不使用同步傳輸，因為事務參與者的生命週期同步會造成整個系統的停止。
於是，當為了可擴展性而必須分割資料或事務時，我們必須使用同步傳輸來處理被分割的資料或事務之間的一致性問題。 然而，鑒於局部故障的問題，我們實際上不可能使用同步傳輸，因此我們需要弱化應用中的Consistency條件。
因此，當資料備份在距離寬廣的區域時，必須做的選擇是在 Consistency 與 Availability 中做取捨。因此，'C'（ACID一致性）的一部分，通常會為了產生合理的系統可用性而妥協。
於是，大部分的雲端資料管理透過鬆綁ACID的對系統的保證來克服分散式副本的困難。特別是，它們執行各種較弱的一致性模型（e.g. eventual consistency, timeline consistency, session consistency，以使所有副本不必在每一刻時間都讓數據項具有相同的值。
因此，交易數據管理應用程序(如銀行交易，證券交易，供應鏈管理），這些依靠數據庫提供的ACID保證的應用，在雲環境中傾向於相當密集地寫入或要求微秒的精度是少見的，除非成本和廣域數據傳輸的延遲有顯著減少 。
Cooper等人。 討論了雲數據管理系統所面臨的權衡如下：
Read performance versus write performance: 如果資料一直在變動，則單單儲存更新變動量的日誌結構系統是非常沒有效率的。另一方面，在每次更新時寫入完整的日誌在讀取時能夠避免重新建構的成本，但是仍然會有較高的更新成本。除非所有資料都儲存在記憶體中，否則硬碟的隨機I/O對提供讀取服務來說是必須的。 然而，對於寫入動作來說，將所有更新附掛在一個循序的硬碟日誌上可以達成很多的產能的提高。這項權衡會影響網路資源的選擇。雲端服務商可能獲得非同步的上下傳能力的網路連接來符合資料更新方式的選擇。如果系統僅僅寫入更新的變動，則可以優先提高下載的頻寬，這樣可以節省付給網路提供商的成本，以此提高利潤。
Latency versus durability: 寫入的動作可能在系統還未傳給使用者成功的結果之前同步到硬碟，或在寫入的時間先存放到記憶體並且在之後才同步。後一種方法的優點是避免磁盤操作，極大地改善寫入延遲，並有可能提高吞吐量。它的缺點是數據丟失的風險，如果一台服務器當機，則會失去尚未同步的更新。顯然，這個決定是由網絡性能的影響。如果網絡的延遲比較高，延後磁盤同步是較好的做法。通過這樣做，也能夠讓用戶感覺較低的延遲。
Synchronous versus asynchronous replication: 同步複製，確保所有副本都是最新的，但可能會導致高延遲的更新。 此外，可用性可能會受到影響，當有些副本是離線時同步複製更新無法完成。 異步複製避免了高寫入延遲，但允許副本是過時的。此外，由於複製前的失敗造成更新遺漏有可能造成數據的丟失。這種折衷的網絡上的影響是類似Latency versus durability的影響。如果網絡的延遲比較高，應該最好使用異步複製。
Data partitioning: 系統可能是嚴格的列儲存或是允許行存儲。列存儲支持高效存取完整的記錄，如果我們通常訪問的全部的記錄，是比較理想的方式。基於行的存儲用於訪問行子集是比較有效率的，尤其是當多個記錄進行存取時。這個決定會影響主機的選擇，以保證行/列不儲存在很遠的網路節點上。
Kraska et al. 認為，成本，一致性和可用性之間找到合適的平衡不是一件簡單的任務。高一致性意味著高的成本，在某些情況下，會降低可用性但可避免懲罰成本。低一致性可取得較低的成本，但可能會導致更高的懲罰成本。因此，他們提出了一種機制，不僅可讓設計人員定義的在數據上的一致性保證，而不是在事務階層，也允許在運行時自動切換一致性保證的能力。他們還描述了一個動態的一致性策略，稱為Consistency Rationing (一致性配給??)，在可能的情況下（即懲罰成本低)減少的一致性要求，在他們很重要時（即，懲罰成本太高）提高一致性。這個機制是由一個成本模型和不同決定系統應該如何表現的策略所導出。 特別是，他們將數據項分為三類（A，B，C），根據所提供的一致性層級來對待不同類別。 在A類的數據項，當違反任何一致性會導致大的懲罰成本， 因此我們需要很強的一致性。C類的數據項，可以使用session consistency ，被視為暫時的不一致是可以接受的，而B類包括所有數據項的一致性要求隨時間根據實際情況的項目而變化。因此，這一類的數據處理，無論是strong或session consistency，會根據一個統計為基礎的政策來決定。
Keeton et al. 提出了類似的方法，系統稱為LazyBase，使用戶能夠在查詢性能和結果新鮮度之間做調節。LazyBase將metadata處理分為ingestion, transformation, and query stages 的pipeline處理，以提高性能和效率。通過分解處理程序，LazyBase可以獨立決定如何安排一組metadata時的每個處理階段，因此比現有的單片解決方案提供了更多的靈活性。LazyBase使用模型轉換和查詢性能，以確定如何安排轉換作業，以滿足用戶的新鮮度和效能目標，並有效地利用資源。
Florescu and Kossmann 認為，在雲端環境中最需要優化的是以金錢計算的成本。因此，數據管理應用的一大挑戰是不再是速度有多快，可以執行數據庫工作負載量或一個特定的吞吐量是否可以實現，面臨的挑戰是在多少台機器是必要的，以滿足一個特定的工作負載的性能要求。
這個論述正好符合Jim Gray 提出的關於相對於本地計算，計算在互聯網上分佈式計算機會成本的thumb calculation 。根據Gray的規則，1美元等於1 GB通過WAN發送，或者8個小時的CPU處理時間。因此，Gray推論，除了高度密集型處理應用的計算任務外，外包工作到一個分佈式的環境會因為網絡流量費超過了所節省的處理能力費用而不划算。原則上，計算基本計算服務之間的權衡對取得經濟相關的思路是有用的。這種方法可以很容易地應用到雲計算供應商（如亞馬遜，谷歌）的定價機制。
Li et al. 提出了一個框架，估算和比較在不同的雲服務供應商部署應用程序的性能和成本。這個框架計算服務供應商所提供的雲服務的共同的特徵，如存儲和網絡。這個框架的初步結果表明，雲服務供應商，他們提供在性能和成本的顯著不同的服務，沒有供應商在所有服務皆稱王。因此，對託管根據他們需求的所設計的應用程序的不同供應商做系統評估是有需要的。
