中型企業在雲端建置挑戰以及商業隔閡 (Business Silos)

雲端運算 (Cloud Computing) 是現在許多中小型新創企業的首選,現在很少有聽過中小型新創公司在做新專案的時候去購買主機自己架設伺服器、網路設備等,幾乎沒有。雲端運算己經是現在企業規畫中重要的一環,以及解決現在商務規劃上的科技建置的首選。雖然這些雲端運算非常容易取得,但是這些在於中小企業在業務上的規劃在企業成長的時候複雜程度是越來越高,需要越來越多技術人員去維護而且要對這些雲端供應商的服務都要非常的了解。

雲端運算對於商業決策有好處?

由於現在的全球的競爭以及供應是越來越分散,以及市場的複雜程度每年都在逐漸越來越高,競爭力從原本有些許行業有地域性的優勢都面臨全球競爭的壓力。再來使用者對於企業的要求也越來越高,有了雲運算的體驗可以使得企業有最快的速度取得最快的運算以及利用雲供應商的資源去部署全球資源,達到業務拓展。這是雲運算對於整個產業的改變,讓所有服務可以更快速的開發以及部署。

中小型企業的商業挑戰?

中型的企業在 IDC 最近的一份報告指出,中型企業常遇到的最大挑戰為雲運算規劃,原因是當企業在成長的時候會需要不斷的去改進商業上軟體的效能,以及更快的發布很好的體驗給消費者。

對於中型企業有什麼特別的地方,由於他們相對沒有足夠的資源可以分配在優化雲端運算以及未來規劃,雲運算在規劃、分析、洞察以及優化都需要不少的成本進行維護。且並不是單一的準則能夠去優化以及去規劃為來擴充問題的解決方案。如果一開始沒有好好的規劃,最後會慢慢的有技術債、數據債的產生。

雲端運算對於中小型的未來困難?

然而初期要使用雲端運算的服務很簡單,上網站註冊即可開始使用。一開始這些雲端服務都提供很多免費的 credit 供您使用。但是當企業規模成長從小公司慢慢轉換成中型公司的時候,在伺服器的規劃以及雲端應用的規劃就顯得特別重要。

但雲端供應商由於希望提供最廣的服務供給所有使用者,所以在很多地方都是留給使用者他們自己去設定去安裝。像是伺服器增減,雲端廠商他們有提供這些功能,但是企業需要自己填寫什麼伺服器增減的 policy ,一般企業在一開始不太知道這要怎麼設定以及最佳化。然而這個功能就可以節省可高達 75% 的雲端運算的成本,如沒有安裝的情況會造成很大的資源浪費。

除了在雲端資源的浪費外,由於現在在商業上我們不只只有開發者會接觸數據,連所有的業務人員都會與數據接觸,要怎麼同時兼顧數據的增長、規劃部署、人員數據安全性以及使用方式。都將會是越來越多中大型企業會面臨的巨大挑戰。

在尋找優化數據的解決方案嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

Cloud-Native v.s. Cloud-Based 應用

現今有很多不同的軟體應用,有些會提及到 “Cloud Native” 這個詞,但是很多人會把他與另一個詞作混淆叫做 “Cloud Based” 究竟這兩個名詞有什麼不一樣呢?事實上,他們是代表著完全不一樣的事情!以下我們將會分析說明這兩者的差異。

雖然這兩個名詞都存在有 Cloud 這個字眼,也就是說兩者都是藉由雲端去運算去運行整套系統。但是他最大的不一樣是,筆者認為是他能不能讓你搬移而且建置在自己的雲端系統,另一個重大的不一樣是他有沒有移植性。

如果您還沒有看過另一篇介紹關於 “Cloud Native” 這個名詞的請參考 “什麼是 Cloud Native? 為什麼 Cloud Native 這麼熱門?” 以及 Cloud Native 的組織所帶來的整個雲端運算的影響,請參考 “什麼是 CNCF?及其帶來對 Cloud Native 社群的影響”

Image result for cloud native vs cloud based
Source

Cloud Native 著重項目

接下來繼續了解兩者的差異,Cloud Native 主要是注重在容器的協作(Container Orchestration)也就是他能夠自動化的擴充以及高也就是他能夠自動化的擴充以及高可用性在雲端架構及環境中。更進一步地說,他基本上是建造在雲端供應商所提供的 Microservices 之上,所以讓企業在導入 Cloud Native 的時候可以加速導入流程、研發以及伺服器管理等。

通常很多系統都會使用 Kubernetes 去管理很多不同的容器以及維護所有伺服器運算資源,確保所有的容器之間運作正常,以及當企業使用的時候有高峰(Spike)發生的時候他會自動去擴充運算雲資源,達到伺服器自動擴充。

Image result for cloud native vs cloud based
Source

上圖可以看到,也就是企業所提供的軟體,可能運行在客戶的公有雲、混合雲、或是私有雲上。如上圖所有的服務都是藉由這些雲供應商的 API 進行運算。

那 Cloud-based 呢?

以上的解釋完後,您可能就知道這兩者的差異了。Cloud-based 就像是我們每天所在用的 Outlook, Gmail, Salesforce, 以及 Slack 等等…。這些都是 Cloud-based 的軟體而不是 Cloud Native 的軟體。您只要直接上他的網站以及系統,就能夠享有他所提供的服務。

結論

希望藉由這樣簡單的解釋後,您會更了解這兩者的差異!下次就知道 Cloud Native 與 Cloud-based 的兩者差異。

找尋 Cloud Native 的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 CNCF?及其帶來對 Cloud Native 社群的影響

如果您第一次聽到 Cloud Native 建議您先看看 “Cloud-Native v.s. Cloud-Based 應用”

在注意雲運算以及 Cloud Native 的朋友一定會關注一個新的組織叫做 CNCF (Cloud Native Computing Foundation) 這是一個主要為雲原生為中心的基金會幫助,幫助企業在整合到雲服務以及架構有更多的可移植性以及減少企業對於被供應商鎖死 (Vendor lock-in) 可能性。但筆者認為這個組織的野心以及策略是和以往的開源社群非常不一樣的。這篇將會帶大家更認識 CNCF 這個組織。

我們先來看看主要的董事成員來自哪些公司呢?有 Google, AWS, Huawei, DigitalOcean, Red Hat, VMware, Azure, JD.com, Oracle, Alibaba Cloud, JPMorgan, SAP, Apple, Cisco, 等等… 就可以知道這些非常知名的雲運算龍頭都參與了這個 CNCF 的組成,意味著大家對於 Cloud Native 的這個組織意義非同小可。

Source

如果您不了解 Cloud Native 這個詞可以先參考這篇文章了解,Cloud Native 為什麼會這麼熱門 “什麼是 Cloud Native? 為什麼 Cloud Native 這麼熱門?” 。這篇主要是了解為什麼要組成 CNCF 以及他們對於這個社群的影響。

簡單的解釋 Cloud Native 這個詞也就是軟體設計完全依照 “雲原生” 而設計,這個有許多的好處第一個就是較省錢,這方面指的是您不用一開始買一大堆機器,流量高峰的時候可以租更大的運算處理即可,可以節省一開始花費大量的前期費用。第二個好處是可以有更好的使用者體驗,這些雲運算供應商有完善的網絡可以讓您的網站不論在世界上的其他地方的人也可以很快的讀取您的網站。第三敏捷,在雲端供應商在他們的平台中都有許多 Microservices 所以可以很快的 implement 像是 AI, ML, 以及大數據運算的系統,這些都是雲原生所帶來的好處。

在近幾年越來越多企業也都發展自己的雲服務,現今最大的幾個供應商為 AWS, Azure, Google, Alibaba 等。但當他們在發展更多他們的雲服務的時候,他們開始遇到許多問題。

系統疑慮:

  1. 企業擔心 Vendor lock-in:當選擇了一項服務時,我未來的所有東西都要被這個雲服務所綁住。
  2. 軟體規格不一:照成每個供應商當企業在使用的時候有許多整合上的困難,以及未來困難移植到其他方案。

商業上考量:

  1. 新市場拓展:由於新市場拓展的接受度如果要高且拓展快的話,整個在雲供應商的軟體應盡量符合原本企業已有的架構作供應。
  2. 更廣的客群:雲供應商希望可以有更廣的收集到不同使用者個回饋以及資訊,讓他們更知道在設計這些雲架構的時候需要注意哪些事項。
  3. 發揮影響力:如果單純從一個服務的角度來做行銷,不如有一個強而有力的社群來幫助這些雲廠商能夠發揮影響力到更大的規模。
  4. 對雲供應商軟體接受度:由於沒有一個開放社群的話,很多的系統都像是黑盒子,企業會擔心未來會有什麼系統上的變數以及限制。

雖然說這些 Cloud Native 軟體可以讓很多企業可以在自己的企業內部管理主機或是數據更方便,因為 Cloud Native 軟體通常也可以兼容 on-prem 的情境。但是畢竟雲運算是未來,因系統到了一定的規模以及擴張後上雲是最簡單的管理方式。

有了以上這些問題以及目標,所以就有了這個組織的誕生。

CNCF 的誕生。

筆者認為,CNCF 這個組織商業上的考量占比絕對是非常大的。畢竟 Cloud Native 這個詞就是為了要讓更多企業更容易上雲,使得企業在上雲的這個過程少了更多的質疑

以下是 CNCF 在其官網上說明,其成立宗旨:

Companies are realizing that they need to be a software company, even if they are not in the software business. For example, Airbnb is revolutionizing the hospitality industry and more traditional hotels are struggling to compete. Cloud native allows IT and software to move faster. Adopting cloud native technologies and practices enables companies to create software in-house, allows business people to closely partner with IT people, keep up with competitors and deliver better services to their customers. CNCF technologies enable cloud portability without vendor lock-in.

CNCF Q&A (Source)

讓更多新的雲運算軟體接受度越來越高,而且有較為統一的規範以及指導。CNCF 的初衷就是把許多雲原生的領域像是 Microservices, containers, orchestration services 和更多雲相關軟體,在同一個組織下監督。讓整個組織以及軟體之間更無痛的接軌,幫助更多更快更廣的企業上雲。

在這些大咖的雲廠商的推廣下,整個組織的拓張是非常迅速的!CNCF 已經在過去兩年內貢獻者成長四倍。

以下是一些截至目前為止 (2019/11)的所有在 CNCF 的專案。

專案分三類 Graduated, Incubating, Sandbox

結論

Cloud Native 筆者認為,必定是個具有龐大影響力的未來且 CNCF 只會有更多專案加入,幫助企業上雲。 CNCF 是一個在開源組織下,具有宣傳性以及策略性的組織, 和以往的開源基金會不太一樣,最大得到利益的人就是這些雲供應商。不論如何,擁抱 Cloud Native 吧!他將會是未來。

找尋 Cloud Native 的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 AWS S3 Glacier?適合在哪裡使用?

如果你已經在使用 AWS (Amazon Web Services) 的一定聽過 S3 (Simple Storage Service)。大部分的人最長還是存在 S3 裡面因為它的價格已經算是非常可以接受的,但是 AWS S3 Glacier 是一個更低價的儲存空間以及儲存策略,讓您在某些情境下非常適合使用。

以下我們將著重這 S3 Glacier 的差別進行分析與講解。

什麼是 Amazon S3 Glacier?

如一開頭所說的,他也是一種在 Amazon 的倉儲模式,他像是 S3 是用於儲存資料但是他是主要在設計是以成本極低的儲存服務,通常是給資料備份和存擋提供儲存的方式。Amazon S3 Glacier 可使任何企業或組織輕鬆且經濟實惠地將資料保留數月、幾年,甚至幾十年。

所以當您的數據存存很大量例如好幾 TB 的資料在 S3 而且又是像是 log 的檔案,以 10TB 的數據為例在 S3 是以 0.023USD/GB 收費,所以也就是每個月你的 log 檔就要花費 230USD 的錢… 但是如果存在 Glacier 的話只需要 40USD 幾乎省了快 6 倍的錢。有很多大型企業他們的當日的 log 檔可能就是數 TB ,這些 log 可能存了未來都用不太到,只有需要回顧或是回去分析的時候再拿出來即可。

那 S3 Glacier 怎麼收費?值得注意的事情是 AWS S3 Glacier 的費用最貴的地方其實是擷取以及傳輸、擷取分有三種快速、標準、大批三種。三種的分別跟獲取資料速度有差。

快速擷取通常可在 1-5 分鐘傳回資料,非常適合作用中存檔使用案例。標準擷取通常可在 3-5 小時內完成,適合較無時間急迫性的需求使用,例如備份資料、媒體編輯或長期分析。大批擷取是成本最低的擷取選項,可在 5-12 小時內傳回大量資料。Amazon S3 Glacier Deep Archive 儲存類別提供兩個擷取選項,範圍從 12 到 48 小時。

值得注意的是,檔案如果放不夠久的話都會有額外費用。Amazon S3 Glacier 是專為需要長久保留資料的使用案例設計的。如果要刪除的存檔已存放長達 3 個月或以上,則從 Amazon S3 Glacier 刪除資料是免費的。如果存檔在上傳後三個月內就刪除,則需要支付提早刪除費。在美國東部 (維吉尼亞北部) 區域,如果在三個月內刪除,則依比例分配計算的提早刪除費為每 GB 0.012 USD。如果您上傳資料 1 個月後刪除 1 GB,則提早刪除費為 0.008 USD。然而,如果您 2 個月後刪除 1 GB,則提早刪除費為 0.004 USD。

Optimize AWS storage
Image source: Amazon Web Services

除了儲存外,還有 Amazon S3 Glacier Select

Glacier 還有一個滿實用的功能,他可以直接在 Glacier 上進行查詢,擷取所需檔案。每個指標的定價取決於三個選項的資料請求速度。「快速」查詢 <250 MB 通常在 1-5 分鐘內傳回。「標準」查詢通常在 3-5 小時內傳回。「大批」查詢通常在 5-12 小時內傳回。

Source

找尋 AWS 上的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 Cloud Native? 為什麼 Cloud Native 這麼熱門?

如果您第一次聽到 Cloud Native 建議您先看看 “Cloud-Native v.s. Cloud-Based 應用”

Cloud Native 是一個近期常聽到的一個名詞,今天讓我們了解一下什麼是 Cloud Native 呢?很多人會把 Cloud Native 與 Cloud-based 兩個名詞搞混,他們兩個其實是完全不一樣的東西。讓我們來開始吧!

Source

什麼是 Cloud Native?

Cloud Native 用來表示已經包裝好容器 (Containerize) 的應用、軟體,也就是說 Cloud Native 是用來指應用程式已經被容器包裝好可以直接 deploy 成一個 Microservice 或是變成一個很有彈性的架構經過 DevOps 或是 CI/CD 的流程可以直接變成一個新的服務。

Related image
Source

在傳統的做法,管理團隊會需要管理架構並分派資源以及伺服器,而 Cloud Native 則是一個已經包裝好的容器您可以直接的發布在雲運算、儲存、分派資源,或是在您的伺服器中立即的部署 Cloud Native 的服務。

我們來看一下官方對 Cloud Native 這個詞的定義。

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

CNCF definition (Source)

可以看到以上的定義,基本上 Cloud Native 當然就是主要要瞄準雲原生的應用程式,讓服務可以很快地上公有雲、私有雲以及混合雲的架構。而且讓這個雲原生的應用可以很有彈性的去自動化管理系統以及服務。

Cloud Native 有多紅?

以下是筆者在 2019 年 11 月的截圖。

2019 年 11 月狀況

上圖為 2019 年 11 月的狀況,以下為 2018 年的狀況。貢獻者就已經快兩倍的成長。

2018 年狀況

在看以下 2017 年的狀況,對短短兩年內就已經有差不多四倍的成長!!這是非常驚人的成長速度呀!

2017 年狀況

為什麼 Cloud Native 會這麼熱門?有很大一部份的原因就是現在的 Cloud 供應商都是以 Cloud Native 的專案延伸,像是 Kubernetes 在 AWS 就有 EKS,Google Cloud Platform 有 GKE (Google Kubernetes Engine),Azure 有 AKS (Azure Kubernetes Service)。所以這些雲供應商都很大力的推廣 Cloud Native 這個新名詞。

如果您看到 Cloud Native XXX 的服務,基本上就是代表他的服務可以非常快就可以上雲開始應用,後面所使用的 Service 都會幫您管理或是自動部署整個雲端的伺服器的發佈、編排、優化等,主要圍繞在雲架構中。

為什麼 Cloud Native 會這麼紅?

原因很簡單,因為雲服務現在已經是所有企業發展的主流。大家現在要開發任何服務基本上都會先從雲的解決方案開始找。所以雲相關的軟體應運而生,也就是您所看到的 Cloud Native 軟體、應用。

那 Cloud Native 的應用有什麼特色呢?

  1. 打包成一個可以快速發佈的容器:Cloud Native 應用為一包打包好的獨立服務 (Microservices) 所包裝好的輕量容器,讓您可以一下就把這個應用把上獨立的上雲使用。
  2. 依照每個情境最適合的情況做設計:比起過去要開發其他軟體都要去思考既有服務的架構,不論是程式語言及框架可都要考慮到過去的程式架構進行設計,而 Cloud Native 則是完全獨立。
  3. 延續 Microservice 的精神:在 Cloud Native 延續 Microservice 的設計讓他可以獨立的運行,並簡單的銜接其他服務。
  4. 分離於伺服器以及作業系統:由於很多 Cloud Native 的應用是建至於雲服務,所以他在使用的時候都不必在想說要支援 MacOS, Linux, 還是 Windows 等問題。
  5. 立即發佈於雲架構與自動化擴充:就和他的名稱一樣,雲原生所以可以很快速的把服務上雲,並同時有彈性的快速自動化擴充以及優化伺服器!

結論

您還沒有使用過 Cloud Native 應用嗎?照著個趨勢 Cloud 將來會在所有的應用程式中,多多關注 Cloud Native 的動態吧!

找尋 Cloud Native 的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 Microservices?以及優勢劣勢為何?

Microservices 是近幾年在軟體設計上很重要的趨勢,跟以往的 Monolithic 的架構相比他是非常不一樣的設計思維。為什麼 Microservices 近幾年會受到這麼大的重視,很大一部份是因為雲端供應商的大力推廣,您所常見到的 AWS, Google Cloud Platfrom 以及 Azure 都是 Microservices 的架構而設計。

讓我們來更進一步了解為什麼 Microservices 是現今的主流,以及他改變了什麼軟體上設計的思維呢?

什麼是 Microservices?

Microservices 最大的設計概念就是,把每個小部分可以獨立的服務以及功能讓他能夠獨立運算以及運作,當要用時透過 HTTP 或是 TCP 等 protocal 進行溝通,以下為一些 Microservices 的理念:

  1. 標準化服務
  2. 耦合性弱:讓每個服務可獨立運作
  3. 讓服務抽象化:把所有內部運作隱藏起來,變成一個標準介面供使用者使用
  4. 服務組合性強:由於服務每個都是獨立運作,所以他們有介面可以讓他們互相能夠溝通以及組合。
  5. 獨立性強:他們可以各自獨立。

以下為 Microservices 與傳統的 Monolithic 架構的差異:

Source

Microservices 最常見,也是最標準的範例就是雲端運算的供應商。

讓我們來看看以下 AWS, Google Cloud Provider 以及 Azure 他們所提供的服務地圖吧!

Image result for aws services 2019
AWS 的服務
Image result for gcp services 2019
Google Cloud Platform
Image result for azure services 2019
Azure

每一個 Cloud 供應商,都有提供非常完善的整個生態,而且每個服務都是根據 Microservices 的概念去做開發,也就是讓每個專案的耦合性低,可以獨立運作且要整合服務以及溝通上都是容易。

現在有許多企業都開始提倡 Microservices ,也是這些雲端供應商的龍頭不斷的推廣這個概念,使得越來越多組織和團隊都接受這樣的框架!你可以使用不同供應商部分的服務 Microservices 來組合成你自己想要的應用。

Microservices 的優勢

最大的好處就是團隊可以很自由的開發、擴充、維護、發布,每一個 Microservices 都是獨立的,所以不用擔心一個 service 設定錯了會影響其他服務的運行。您如果用過雲端供應商的服務,就了解現在要使用一個 service 是多麼簡單,一個按鍵即可開始使用。

Microservices 的優勢如下:

  1. 更快速的開發
  2. 更快地能夠把產品推到市場
  3. 服務獨立:不用擔心一個錯誤會影響到者個產品
  4. 容易擴充服務規格:可以依照單一的服務需求做擴充
  5. 容易擴充功能:當企業有更多業務的時候,可以馬上開啟一個新的 service 進行擴充。

Microservices 的劣勢

每個新的架構,不可能完美,有優勢也會有劣勢的地方。那 Microservices 的劣勢為何呢?

Microservices 的劣勢如下:

  1. 設定複雜:由於每個服務都獨立開來在不同的介面中,當您混合更多服務時在維護上會越來越複雜。
  2. 學習曲線高:現在使用 Microservices 通常都會直接使用雲端供應商的服務,所以除了原本要學習的系統以及程式語言外,還要學習這些雲端服務的限制以及設定,有時候非常複雜。
  3. 錯誤維護:由於每個服務都是各自獨立,所以再有錯誤的時候可能會是在 Network 或是在流量上的控制都要去設定以及維護。
  4. 難以做測試:因為每個發佈都是在雲端服務,所以使得要用更進一步的 script 或是開發流程確保所有環境運作正常。

結論

Microservices 必定是未來,尤其是有 Amazon, Google, Azure 這些雲端供應商大力推廣以及教育的情況下,越來越多個人以及企業會擁抱 Microservices 的框架!

難以管理大數據 Microservices 嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 OLTP?什麼是 OLAP?

在數據管理中有兩個很重要的名詞,很基本但是也是很重要的觀念。就是 OLTP 以及 OLAP 這兩個名詞皆是代表數據管理,其目標以及應用情境是完全不一樣,這也包含他們的設計理念是不一樣的。

Image result for olap vs oltp

讓我們來仔細了解這兩者的差異吧!

什麼是 OLTP?

OLTP 是指 Online Transactional Processing 的簡稱,這個詞中 Transactional 是非常重要的,代表的是說他的處理通常包含了讀以及寫,通常 OLTP 是指系統能夠處理大量的更新以及新增的查詢。所以在傳統的 OLTP 系統中,數據的正確性以及一致性是首要要達到的目標之一。所以一般的 OLTP 中會常常聽到 ACID (Atomatic, Consistent, Isolated, Durable) 合規。這代表他們諄循著一個事務 (Transaction) 完成後才會執行下一筆,確保整個系統的資料一致性。

數據一致性為什麼這麼重要?因為 OLTP 可能同時有多位使用者同時操作,所以要確保當一個使用者更新資料後,另一個操作中的使用者也能拿到最終的狀態。不然就可能會有數據不一致以及不同步問題。這也是為什麼常常會聽到 ACID compliance 這個詞在 OLTP 中。

什麼是 ACID

根據 Wiki 中的定義

Image result for acid database

ACID,是指資料庫管理系統DBMS)在寫入或更新資料的過程中,為保證事務(transaction)是正確可靠的,所必須具備的四個特性:原子性(atomicity,或稱不可分割性)、一致性(consistency)、隔離性(isolation,又稱獨立性)、持久性(durability)。

  • Atomicity(原子性):一個事務(transaction)中的所有操作,或者全部完成,或者全部不完成,不會結束在中間某個環節。事務在執行過程中發生錯誤,會被回滾(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過一樣。即,事務不可分割、不可約簡。
  • Consistency(一致性):在事務開始之前和事務結束以後,資料庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設約束觸發器級聯回滾等。
  • Isolation(隔離性):資料庫允許多個並發事務同時對其數據進行讀寫和修改的能力,隔離性可以防止多個事務並發執行時由於交叉執行而導致數據的不一致。事務隔離分為不同級別,包括未提交讀(Read uncommitted)、提交讀(read committed)、可重複讀(repeatable read)和串行化(Serializable)。
  • Durability(持久性):事務處理結束後,對數據的修改就是永久的,即便系統故障也不會丟失。

OLTP 使用的情境

當您在使用銀行系統的時候就是一個非常標準使用 OLTP 的系統,銀行系統必須要確保您每次拿取的資料都是一致性而且是完全正確的。想像真實世界,不太可能你現在領了一些錢之後到了另一個 ATM 你的金額還是維持照舊,所以銀行系統都會需要很高的資料一致性,且完全符合 ACID 的規範。

什麼是 OLAP 呢?

OLAP 又是什麼呢?它代表著 Online Analytical Processing。一般的 OLAP 的系統可以讓數據聚合 (data aggregation) 以及批次處理 (Batch processing),OLAP 大部分是用來做歷史資料的分析以及報告。和 OLDP 最大的不一樣是他不需要處理、儲存、以及保持資料的一致性,而是用 OLAP 可以很快的使用 Query 去得到數據洞察得到數據聚合後的結果。

OLAP 使用情境

對於所有的 BI 系統以及報告工具都是 OLAP 的系統。像是如果銀行中他有 OLTP 的系統確保他的一致性後,他就能用 OLAP 的系統去做報告以及商業智慧分析等應用。例如:他可以把所有全台灣的使用者在過去一個月的交易做分析,這時候他就會較適合使用 OLAP 系統作分析。

結論

OLTP 重視數據處理以及一致性,OLAP 重視數據分析。但通常他們兩個會搭配使用,儲存資料的時候先存到 OLTP 中確保數據一致性,要做分析的時候再使用 OLAP 做重要報表。

找尋 (大) 數據 OLAP 管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

Row-Oriented 資料庫 v.s. Columnar 資料庫?

在做一些數據工程的時候,會常常聽到兩種非常不同的資料庫儲存方式一種是 Row-based 另一種是 Columnar-based。近幾年來 Columnar 的 database 也越來越受到重視,由於在數據分析的 data warehouse 時,某些情境 Columnar 的資料庫會比 Row-based 來得有效率很多。

讓我們來了解這兩個最大的差異吧!

Row-based Database

有哪些資料庫是屬於 Row-based 的資料庫呢?

  • MySQL
  • PostgreSQL
  • MSSQL

這些數據庫基本上都是 Row-based 的資料庫,以下為一個 Row-based 的儲存方式。

每一列儲存一個數據項目。所以一般 Row-based 的資料庫在儲存資料的時候存在 disk 上會長得像這樣

001:10,Smith,Joe,60000;
002:12,Jones,Mary,80000;
003:11,Johnson,Cathy,94000;
004:22,Jones,Bob,55000;

Row-based 設計上是為了很快的得到一個列的資訊,例如我可以很快地使用一個 id 去取得一列的整個資訊。

Columnar Database

有那些數據庫是 columnar 的數據庫呢?

  • Amazon Redshift
  • BigQuery

而 Columnar 的 Database 所儲存的方式就和 Row-based 非常不一樣,以下為他會在 disk 上儲存的樣式。

10:001,12:002,11:003,22:004;
Smith:001,Jones:002,Johnson:003,Jones:004;
Joe:001,Mary:002,Cathy:003,Bob:004;
60000:001,80000:002,94000:003,55000:004;

可以看到他是從一個 column 的資訊一項一項的存進來,而不是一列一列的存。

Row-based 和 Column-based 最大的不一樣是他如何儲存數據。這會使得應用在不同的情境時它的效能差異會非常大。

什麼時候應該用 Row-based DB?

一般來說,Row 的儲存方式是何在 transaction 的處理,以及常常需要獲取一個範圍的列搜尋,如果使用 Column-based 會把所有的 columns 都掃完才會到下一個欄位項目,這會造成很多不必要的數據掃描,通常這會很直接地影響到雲運算成本。

像是做網站以及 App 應用,很多時候要拉出一個客戶的資料,使用他的例如 customer_id 這時候用 Row-based Database 是個適合的選項而不是 Column-based 的數據庫。

什麼時候應該用 Column-based DB?

Column-based 的數據庫適合在數據分析的時候去使用,在某些像是欄位的掃描 max, min 時他不會像是 Row-based 要把整個 database 全部掃描完才能夠運算,這時候使用 Row-based 會造成雲運算成本大增。

還有一點就是 Column-based 所儲存的數據會把每個 column 的數據存在不同的檔案或文件中。所以通常在做資料分析的時候不需要把所有欄位的資料一次拉出來,通常會只想要針對幾個欄位的資料做數據運算。這時候使用 Column-based 的數據運算可以節省非常多的雲端數據處理以及費用,而且更快速。

資料庫正規化 v.s. 反正規化

談到 Row-based 以及 Columnar 的數據庫,通常都是會混合使用這兩個非常不同的數據庫。原因是使用的情境是完全不一樣,所以通常我們會把正規化的資料放在 Row-based 的數據庫中,而反正規化的資料放在 Columnar 數據庫中。

什麼是正規化?資料庫正規化,又稱正規化標準化,是資料庫設計的一系列原理和技術,以減少資料庫中資料冗餘,增進資料的一致性。

  1. 欄位唯一性 (Field Uniqueness)
  2. 主關鍵欄位 (Primary Key)
  3. 功能關聯性 (Function Dependence)
  4. 欄位獨立性 (Field Independence)

簡單來說就是正規化,我們希望資料庫存的資料是最一致而且有效率的儲存。所以我們在設計 MySQL 的資料庫的時候我們都會有 Primary Key, Foreign Key 把相同的數據拉開到不同的 Table 中。

反正規化則是希望把四五個不同的 Table 的資料,先把很多常用的資料做操作像是 Join 以及合併變成一個 Table ,這樣未來在做數據分析以及運算的時候不用一直在拉出很多 Table 做很昂貴的運算,而且可以針對所需要的後續分析的情境做最有效的反正規化設計,幫助未來在 Query 以及運算時會更快。

但反正規化有他的缺點,他會需要有很多重複的欄位在不同的資料集中,因為他可能會依照未來的使用做最有效的資料結構設計,而不是在儲存上最佳化。

Image result for normalization vs denormalization
Source

結論

是的,數據管理是一個很大的學問,光是 Row, 以及 Column-based 數據很直接的會影響雲端上的儲存成本以及應用端的處理效率。而且當企業在同時擁有 Row 以及 Column-based 的時候,會做很多資料的複製以及管理,沒有適當管理的話就會照成企業長期的數據債問題。

想要有效地處理數據嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

BigQuery 的收費機制與設計

現在聽到許多企業慢慢轉到 BigQuery 平台上去做大數據分析,問了一些朋友的原因,大部分的回答是 BigQuery 很便宜。但其實 BigQuery 由於絕大部分是採以量計價,所以使用上要較小心,使用 BigQuery 需要注意哪些細節呢?

以量計價的收費

事實上當我們去看 BigQuery 的收費機制的時候感覺上真的是滿划算的

1TB 才只有 $5 美元,而且每月前 1TB 是免費的!看起來真不錯。

除的運算方面的算法外,儲存也會有相關費用,也可以接受就像是 AWS 的 S3 費用差不多!

固定費率的收費方式

當然還有固定的費用,每月 $10,000 美金的方案,但我們這邊就先不考慮討論。這是針對比較大量使用 query 的人可能會考慮。

以量計價真的划算嗎?

但目前遇到的朋友們都是因為前面以量計價的方式考慮 BigQuery。但是以量計價的方式其實是很常讓您會收到超乎意料的 Google Cloud 帳單。我們來看看一個實際案例…

Source from Stackoverflow

沒錯您沒有看錯,突然暴增到數千…美金。

以量計價怎麼算的?

BigQuery 是一個 columnar 的 data warehouse,也就是資料的運算方式是採用columns 去做掃描,而不是像傳統的 relational database 是用 row 的方式去得到資訊。

所以像是以下的 Query ,我們去 Query BigQuery 所提供的 Bitcoin 的 dataset

SELECT count(*) FROM `bigquery-public-data.bitcoin_blockchain.transaction`

這個 query 只有 $0 美元的費用因為這個 query 中沒有任何 column

但是呢?現在這個情境,猜猜需要多少運算量?

SELECT timestamp, transaction_id FROM `bigquery-public-data.bitcoin_blockchain.transactions` LIMIT 1

我現在要 select 兩個 columns 然後只要一筆,竟然需要 23.5GB 跑這個 query… 是不是很意外呢?這是因為 BigQuery 是一個 column-based 的 data warehouse 所以您雖然只要拿第一筆資料,但是他需要去要 timestamp, transaction_id column 的資料掃過一遍他才拿得到一整列您所需要的資料。

現在再來試試看另一個 query

SELECT * FROM `bigquery-public-data.bitcoin_blockchain.transactions` LIMIT 1

這次需要 587.1GB 才能跑出以上的這個 Query,雖然我只要一個 row 但是他會把所有的 column 都掃描過一遍…夠嚇人吧!

再來看另一個例子

SELECT max(timestamp) FROM `bigquery-public-data.bitcoin_blockchain.transactions`

這個情況會需要 2.5GB 的容量去跑,還比範例二的 LIMIT 1 來的小,原因是所需要的 column 只需要 timestamp

接下來我們來跑一個比較複雜的 Query 如下。

這是只需要 20.9GB 還比我只要獲取範例二 LIMIT 1 的情境 23.5GB 還來得小。

所以您可能開始問說,要怎麼樣有效率的方式所 filter query 呢?這時候將資料表分區分群有助於降低查詢處理的資料量。為達到最佳做法的成效,請盡可能採用分區和分群的做法。

什麼是分區 (partitioned)?

分區資料表是一種特殊的資料表,其中分成多個區段 (稱為分區),可讓您更容易地管理和查詢資料。透過將大型資料表分成較小的分區,可以提高查詢效能,並且可以透過減少查詢讀取的位元組數來控制費用。

BigQuery 中的資料表分區有兩個類型:

  • 依擷取時間分區的資料表:根據資料的擷取 (載入) 日期或到達日期分區的資料表。
  • 分區資料表:依據 TIMESTAMP 或 DATE 資料欄分區的資料表。
SELECT max(temp) FROM `bigquery-public-data`.noaa_gsod.`gsod*` WHERE _TABLE_SUFFIX BETWEEN '2010' AND '2018'

上面這個 query 會減少 columns 在掃描的 size 所以他會是 262MB 而不是 1.11GB 會被掃瞄。

什麼是分群 (clustered tables)?

使用叢集處理的時機

目前 BigQuery 支援對分區資料表建立叢集,使用時機如下:

  • 資料已使用 date 或 timestamp 資料欄分區。
  • 您通常會在查詢中,對特定資料欄使用篩選或匯總。

擷取時間分區資料表和依據 DATE 或 TIMESTAMP 資料欄分區的資料表都支援建立資料表叢集

結論

要有效率的使用 BigQuery 其實並不簡單,需要完全了解整個系統以及資料庫的性能,已做到最有效率的應用。在使用上也要非常小心以免在未來收到帳單的時候就來不及了!

比起 AWS Redshift 等其他的 cloud data warehouse。是用 Instance 數量去收費來看,如果不會優化 SQL 或是不了解 BigQuery 的優化的話 Redshift 會比 BigQuery 來的容易控制預算許多。

想要簡單化數據管理嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

大數據檔案格式類型 Row-based 還是 Column-based?

一開始接觸大數據的人會很好奇,為什麼大數據的檔案格式跟以前聽到的不太一樣!其實是有許多原因,讓我們需要有特殊的檔案格式去處理大量的數據,讓我們仔細地瞭解吧!

當在使用大數據處理資料時,原始的數據通常是非常大量的。一般儲存的格式並不適合去儲存大量的數據量是 human readable 的格式例如:JSON, XML, CSV 並不是最理想的方式去儲存資料,而且事實上用人類閱讀的儲存格式是非常沒有效率,也並沒有支援檔案平行處理的能力。平行處理是在大數據中非常重要的技術,因為基本上單一電腦是沒辦法處理這麼大量的資料。

資料的效率、成本以及有能力做平行運算是非常重要的,也是優先需要去支持的功能特色。所以後來演變成有許多專為大數據而設計的資料格式像是 Optimized Row Columnar (ORC), Avro 以及 Parquet 等格式來儲存大數據數據。但這些為了大數據而設計的資料格式,每種資料格式都有他擅長的處理檔案類型。

讓我們來認識這些為了大數據而設計的檔案儲存格式吧!

這些格式有什麼共通點

擴充以及平行運算

由於他們是瞄準極大數據的倉儲,所以他們在優化以及壓縮上面有非常多的優化。當數據量非常大的時候,非常好的壓縮性能可以節省巨大的開銷。ORC, Parquet 以及 Avro 並不是人類看得懂的格式,是給機器看的 binary 格式,這些類型的格式會把檔案分散到許多硬碟內去儲存,使得有能力做到擴充以及平行運算。

已定義的數據

這些格式都會儲存一份他們的 schema 在檔案中,所以當你在不同的機器運行時,他們可以很快地得知 data schema 進行近一步的運算及處理。

範例:ORC 儲存的方式

以下可以看到他會切割成很多等份叫做 Stripes 區塊,然後在 file footer 存上一些輔助的資訊。

  1. 這個檔案包含的 stripe 列表
  2. 每個 stripe 有幾個列
  3. 每個欄位的 data types
  4. 每個 column 的 counts, min, max 跟 sum

在 postscript 存放一些壓縮的資訊。

Image result for orc file structure
Source: Hive ORC Wiki

這些格式有什麼差異性?

最大的差異就是他們怎麼處理資料儲存的方式。Parquet 跟 ORC 是用 column 的方式去儲存資料,Avro 則是採用 row-based 的方式去儲存。

Column-based (Parquet, ORC):

Image result for parquet logo
Image result for orc file logo
  • 優化大量分析的工作量
  • 主要優化讀取速度
  • 常用於 Hadoop, Hive, Impala, Apache Drill, Apache Arrow

使用情境:假設今天我們要分析一個銷售的資料,我們要找哪些消費者依照他在哪裡消費做分析,以傳統的 column-based 的方式我可以拿出消費者名稱以及地點做分析,用 column-based 可以很快的只拉出這兩個欄位做分析。而像是 row-based 的話他就會把每個列都掃描才拉出欄位。

Row-based (Avro):

Image result for avro file logo
  • 優化 Transactional 的工作量
  • 主要優化寫進的速度
  • 常用於 Apache Kafka, Druid

使用情境:假設今天我常常使用的搜尋是依照一段時間去做分析,例如在航空業,常常會想要了解某一區間的航班資料,例如早上 10 到晚上 5 點的所有航班資料。這時候 rolw-based 的情況會較為適合。

所以要使用什麼樣的儲存方式,與您想要做的案例是有很大的相關性的,不同的情境適合使用不同的方式儲存方式。一般來說,Parquet 以及 ORC 會有較好的壓縮比起 row-based 的 Avro 的格式,像是如果 IoT 的應用會一直不斷地儲存資料所以壓縮的量會有非常大的差異在儲存成本上,這時候可能 Parquet 以及 ORC 會較適合。

Image result for avro vs parquet vs orc
Source: Datanami

結論

大數據的領域是不是很酷!不同的應用場景,所適合的儲存方式以及邏輯是完全不一樣的,由於數據量到一定的程度後所有的費用以及速度就會變成非常大的差異。所以才會針對很多非常特別的情境下有完全不一樣的技術。

延伸閱讀

以下有個非常好的投影片,比對有關幾個常見格式的效能測試。

想要導入大數據?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!