A Survey of Large Scale Data Management Approaches in Cloud Environments

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. 提出了一個框架，估算和比較在不同的雲服務供應商部署應用程序的性能和成本。這個框架計算服務供應商所提供的雲服務的共同的特徵，如存儲和網絡。這個框架的初步結果表明，雲服務供應商，他們提供在性能和成本的顯著不同的服務，沒有供應商在所有服務皆稱王。因此，對託管根據他們需求的所設計的應用程序的不同供應商做系統評估是有需要的。

O’Reilly Blogger Review Program 部落客免費看電子書

今天在玩物尚誌的部落格文章中看到O’Reilly Blogger Review Program 邀請部落客寫書評
正好我在念書與工作階段都還蠻常看O’Reilly出的書籍，因此便想試試看
於是便點選鏈結進入到O’Reilly Blogger Review Program
 
因為我沒有他的帳號 因此便先新申請一個  不過申請完他又跳到首頁畫面

只好在重新由鏈結回到O’Reilly Blogger Review Program
這時候已經登入，選擇Join頁面，就會在右手邊看到你的帳號，繼續下一步
Apply using the registration form below.

點選之後會要你填寫申請書 重點是要把你的部落格位址填入
    
之後選擇你感到興趣的領域  送出就可以了 看到下面的畫面可以開始選書籍了
  
到Available Products網頁 可以看到目前可以選擇的書籍 但是目前點選書籍會出現
You can't request this product until we review and approve your application
這是因為申請還沒通過 等申請通過之後就可以選擇了


 

宜蘭遊記。國光雪隧線。南方澳踩線之旅--冬山車站、三剛鐵工廠、富美活海鮮、珊瑚法界、蘇澳冷泉

遊覽日期 :2013/6/21
這次參加國光旅遊新路線 國光雪隧線的踩線之旅

從台北捷運圓山站出發前往宜蘭 蘇澳 南方澳
這條新的路線可以從台北捷運圓山站、南港站搭乘國光客運到達 宜蘭的羅東、宜蘭、頭城、南方澳、烏石港等地，既方便台北人前往宜蘭，也方便宜蘭人前往台北或去桃園機場。

在早上八點半左右我們在台北捷運圓山站一號出口集合
在國光客運的新式遊覽車到來後紛紛上車 不過上車前當然是要拍個照囉

這就是我們要搭乘的車子 白色的底 紫色的彩繪 看起來乾淨又優雅

車上的座椅比一般的舒適很多 據說是人體工學座椅

 

座位前方有影音多媒體可以觀看 據說比飛機上的還要先進

 

還可以利用USB插座來充電 還有無線上網可以使用  很是貼心

 

國光客運人員介紹國光雪隧線的內容

 

國光客運表示，將在本月二十八日到三十日（周五至周日）大請客，三天內民眾可隨時免費搭乘，還送海鮮吃遍遍DM、免費海鮮餐卷、超值福袋、蘭陽博物館門票等，發送地點在捷運南港展覽館站創客運業免費搭三天首例，另外國光將有五十六部全新豪華巴士載客，車上提供個人隨選MOD視訊設備，可看電視和電影、還有無線上網功能等。
國光旅遊活動網址:
http://www.kingbus.com.tw/newscontent.php?news_num=444&page=1

 

 

我們第一個停的點是號稱全台灣最美的火車站的 冬山車站
車站的造型據說是參考菜瓜布  看起來很是特別

 

車站外面還有造型藝術

 



台鐵本舖外面有古早味的郵箱

 

牆上還有很多遊客寫上祝福與紀念的掛牌

 

接著我們直接來到了南方澳 在遊客中心下車 從圓山到南方澳大概坐了一個半小時的車吧 (如果沒去冬山車站的話)

遊客中心裡面有各式各樣的介紹  可以對南方澳有個初步的了解

想不到連 宜蘭蘇澳的南方澳遊客中心也在拜乖乖 (工程師才了解的梗)

 不過我們當天去看得導覽設備還是當機了 看來那包乖乖大概是過期了

 

二樓的牆上有當地漁產的模型標示 介紹當地盛產的鯖魚  鬼頭刀 黑鮪魚等

 南方澳遊客中心採用綠建築設計 強調節能與環保 所以窗戶都是開著的採自然風

外面還有風力發電設備

可愛的招牌告示

在遊客中心外面就是漁港，停滿了各式各樣的漁船 我看到這上面佈滿燈泡的漁船就不禁想像起他在海面上燈火通明吸引趨光性魚類的樣子

遊客中心的隔壁是寶石珊瑚媽祖廟

 

顧名思義 裡面的媽祖神像是用寶石珊瑚雕刻而成的  這裡面的故事就等你親自來發掘囉

看到捐獻箱裡面的紙鈔竟然大部分是人民幣  看來媽祖也需要大陸市場阿

 



密密麻麻雕刻著細緻木雕的屋頂  所謂的雕梁畫棟大概就是這樣了吧

參觀完寶石珊瑚媽祖之後我們到了南方澳著名的文物館 ---三剛鐵工廠

鐵工廠裡面有一些懷舊的照片 述說著鐵工廠成立時期的輝煌

店裡面陳列了不少重型機器 每一台身上都有厚厚的歷史味道

二樓的入口處有大大的圖像介紹三剛鐵工廠成立的歷史

現任店主是三剛鐵工廠創立者的廖心賀的兒子  傳承的過程還夾雜了一段舊時代友情的故事
廖心賀先生在開創鐵工廠後不幸亡故  其遺孀與子女則在其好友兼股東的幫助下度過最艱難的一段日子 真是令人感動

三剛鐵工廠的店主本身也是文化工作者  常常應邀去大專院校演講上課
這次參訪還幫我們上了一小段蘇澳的歷史 非常引人入勝 可惜時間不夠 才聽到西鄉隆盛的大兒子的故事就要去吃飯了

店主拍的蘇澳港日出的照片真是一級棒的 現在來蘇澳的很少會住宿到隔天 其實應該待到隔天早上起來看日出的  下次有機會的話真想安排在蘇澳住一天  想必會有非常夢幻的感受

從三剛鐵工廠的頂樓可以俯視整個港區  是個不錯的拍照地點

店內的樓梯是非常有古早味的水泥樓梯 有濃厚的懷舊風格

而店裡的商品中 我對鐵鍊鱷魚最感到興趣  造型獨特有趣

午餐我們在知名的富美活海鮮用餐  不得不說在漁港旁邊吃飯真的不用擔心吃到不新鮮的

店內客人眾多  雖然還只是星期五的中午  可以想見星期六日會有多少人擠在裡面 

 

食材看起來都很新鮮  旁邊還有活跳跳的水箱海產  龍蝦 螃蟹 魚類都在裡面游泳

 

開始上菜囉 除了我不敢吃的生魚片外  中間的貝類很鮮甜 干貝唇蠻入味的  好吃

鮮燙蝦子 蝦味十足  肉身十分有彈性  絕對是鮮味滿分  雖然個頭不大 不過一口一隻剛剛好

炒鯊魚肉  啥    鯊魚肉怎麼會這麼嫩呢   加入豆醬熱炒的味道讓人想多吃一碗白飯

嘿嘿 龍蝦耶~~~新鮮的龍蝦肉相當彈牙  沒話說  就是讚

炒高麗菜   中和一下滿是海鮮味的口腔味覺

旭蟹冬粉   冬粉上面鋪滿了旭蟹切塊  蟹肉鮮甜 味道香濃

如果沒看錯  應該是清蒸迦納魚吧   紮實的口感 配合醬汁入口 害我又盛了一碗白飯

酸菜豬肚排骨湯   跟一般辦桌的差不多

味增湯  裡面的魚塊應該是鱸魚吧  肉質細緻 不過吃到這邊已經快撐了

飯後水果

我們今天吃的是每桌3000十人份的料理

店裡還有其他不同價位的合菜

吃完飯在街頭逛一下消消脹

 

接著我們還到這次踩線我最感驚豔的地方---珊瑚法界
宜蘭縣蘇澳鎮南安路220號
03-9963355
網址:http://www.coralmuseum.org

珊瑚法界創自民國65年。館長賴榮興鑑於堆珊瑚的深厚情感所設立，館內一樓是一般商品展示，二樓、三樓需要付費參觀 成人票100元 二樓主要展示寶石珊瑚的生態與產業背景 三樓陳列精美的珊瑚雕刻 建議一定要上去看看 尤其是三樓  都是真正的藝術品  令人驚豔
另，這次是因為踩線之旅目的是推銷觀光，所以才經店主許可我們拍照 正常二三樓是不準拍照的，請務必遵守或跟店主洽商。

 

雅致的店門口招牌與獨特的建築讓人產生十足的好奇心

一樓陳設一些珊瑚雕刻 

二樓會介紹寶石珊瑚的生態與如何捕撈的過程

上面是捕撈寶石珊瑚用的工具  旁邊那顆不是寶石珊瑚  只是展示用的普通珊瑚石
下面展示各色寶石珊瑚

 

台灣寶石珊瑚的分布

工作室裡面的工具

 三樓陳列很多美麗的雕刻作品

下面這一座是鎮店之寶
長寬大概三十公分的珊瑚上面   密密麻麻的雕刻滿建築與佛像 真是太厲害了

 

三樓還有很多的雕刻作品 不過都擺上來這一篇就太長了 我決定另外獨立寫一篇珊瑚法界的 把三樓拍的照片都放上去 每一件作品都很值得一看

 

接著我們來到海邊 美麗的豆腐岬

在路邊我們看到正在整理漁具的漁夫 

這可是用來釣黑鮪魚的延繩釣唷

接著我們來到

蘇澳(南方澳) 地中海咖啡/民宿

宜蘭縣蘇澳鎮造船路102號

訂房專線 : 0983-819-800

AM10:00~PM9:00

 

咖啡館是地中海情調設計 上面這是後門喔

下面是前門的海景沙灘 

整個建築充滿了地中海風情

裡面的裝飾也很獨特

在咖啡館的頂樓還有小小的教堂呢

 

頂樓的戶外休閒區

 

小教堂的內部簡單又有味道  具有宗教氣息的彩色玻璃帶來不一樣的感受

最後我們來到蘇澳車站 先給它獨特的圓弧造型拍個照

從蘇澳車站去往冷泉的方向 我們先去吃點點心  涼意叭噗 

店裡的叭噗  讓人回味起小時候拿著零錢去投天霸王的記憶
店裡的冰品都是真材實料 芋頭口味裡面吃的到顆粒的芋頭喔

最後一站 我們來到蘇澳冷泉 
既然來到蘇澳怎麼可以不來這邊走走呢

蘇澳冷泉最近剛好要舉辦活動 7月13-15日 有蘇澳冷泉文化節活動 聽說在火車站前面會辦潑水節  那幾天要到蘇澳玩的朋友可得好好瘋一下囉

我們因為時間的關係 所以沒有能夠好好的泡一下冷泉  只能看別人泡囉 下次自己來就可以好好享受了

園區裡面有小包廂  可以好好享受不被打擾的泡湯樂趣

最後 再把好消息告知大家
國光客運表示，將在本月二十八日到三十日（周五至周日）大請客，三天內民眾可隨時免費搭乘，還送海鮮吃遍遍DM、免費海鮮餐卷、超值福袋、蘭陽博物館門票等，發送地點在捷運南港展覽館站創客運業免費搭三天首例，另外國光將有五十六部全新豪華巴士載客，車上提供個人隨選MOD視訊設備，可看電視和電影、還有無線上網功能等。