Snowflake 雲端資料分析
這一篇介紹snowflake的雲端資料分析方法論。透過這一篇文章針對雲端資料平台內的資料分析有三個重點，
1.甚麼是現代化的雲端資料分析?
2.有甚麼樣的可能性可以讓你將散落在各個雲端平台的資料整合起來?
3.透過snowflake可以容易的取得data-driven insights
哪甚麼是Snowflake呢?基本上它很像Google BigQuery or AWS的Redshift，但不太一樣的是它是可以跨不同雲端平台並統合所有的雲端資料。是一個原生的雲端資料庫，它可以當成data warehousing, data lakes, data engineering, data science來使用。
由於第三個重點，透過數據驅動來產生新的見解。也就是透過我們現有的資料去挖掘我們沒看到的事情面向，並產生新的ideal.資料的容易存取，統合，分析，分享，進而幫助人們做出重要的決策。雲端資料的好處之一就是它不再受限傳統機房"儲存與運算"能力的限制，可以近乎無限制的儲存與運算的運算資料。增強的資料的即時性與擴大了計算週期。這個能力讓我們在偵測資安威脅，開發新的產品或服務或是增強推薦系統都得到了長足的進步。然而管理雲端資料的心態絕不跟地端機房是一樣的，我們必須要有一個雲端資料的管理準則以及一套新的雲端資料建構功能。
透過snowflake你可以達成以下三個目的:
1.幫助業務單位使用簡單的snowflake來達成強大的運算分析，你不用再管理複雜的data warehouse, data lake或其他型態的資料庫管理系統。
2.並確保"安全"，"具效能"，"可靠"的運算分析，data visualization, data mining, Business intelligence, 以及 data science.
3.不須透過copy或分享資料就可以有效的將你的資料極大化增加你的營收或榨乾資料的價值。
定義現代化數據分析的急迫性
從傳統的IT時代，資料(數據)分析就是組織少不了的日常活動之一。但資料分散在各地，互不相通也沒有統合。組織裡的各單位個常因各種業務需求需統合資料(根據他們的業務需求與權限)。然後你就會看到一堆資料庫之間一堆copy來copy去(可能是經過一些ETL工具)或移來移去的動作。這一些限制的組織的資料整體統合性。這些cloud-washed的解決方案就會造成剛剛提及的問題。
資料分析從 reactive 進化到 predictive insight
傳統的BI工具產生的大都"描述性的分析"，而這些嚴格來說是歷史性報告。大都是用來量測組織的效能與分析業務維運的資料，像是銷售報告，網站的訪客量等。簡單的來說這種方式就是很簡單: 取得資料並查核與找出過去發生甚麼事。描述性分析就是回顧歷史資料，然後將資料視覺化。就是將raw data轉化成有意義的資料(這個有意義是要看對誰)。但現代化的BI解決方案整合了機器學習的功能，透過演算法將資料做有意義的計算分析讓我們可以將資料轉變成資訊，將資訊再轉化成知識。
診斷式分析(data mining)則帶我們更進一步的將資料聚焦在相關性上，透過資料的 querying/filtering/searching來找尋資料之間的關聯與異常來告訴我們，"為甚麼它會發生"。上述說的這兩種分析方法像是車子的後照鏡，透過歷史資料告訴我們昨天或上周發生的事情.
而預測性分析則可幫助使用者展望未來，一樣是透過機器學習演算法來告訴我們明天或下周可能發生甚麼事。不一樣在於預測性分析尋找歷史資料的模式(patterns)並整合第三方的資料來源來告訴我們評估各種可能的結果。例如以組織的銷售資料來看，它可以結合外部的資料(可能是經濟數據/天氣數據/各行業的預測數據等等)來幫助我們預測下一季的銷售結果。甚至可以告訴我們下一季在組織的銷售活動中各類的商品該生產或補足倉庫裡多少貨。Just in time(及時生產)是很多行業都想達到的終極目標，這一種分析方式可以些協助組織達成這樣的目的。
而指示性分析則更進一步，它是根據預測性演算法的結果加上一些動態轉變的變數後給予特別的具體行動的指示。例如組織的銷售活動(打折或促銷)這 一種分析知道如何將銷售的機會極大化到活動目標。例如會建議A商品加上打折的B商品(類似有零售商哪種紅標商品配綠標商品的做法)，或是組織透過銷售管道給予一些特定的消費者(可能是平常注意這種商品的人)發出一些促銷訊息。這種分析方式(機器學習)的理想會是將人為分析最小化，一旦資料科學家決定了演算法並訓練好機器學習的模型這一套系統就將自行做出這些預測，並隨著時間會越來越聰明(越來越準確)。
上述這一些分析法都有他們的優點，以下這張圖可以清楚的告訴我們甚麼狀況該用甚麼分析法。
Democratizing Analytics(資料分析民主化)
傳統上資料分析都是組織裡的菁英(主管/資料分析師/或其他高度專業技能的人)做的事。但事實上這樣並沒有辦法讓組織變成是data-driven decision-making的公司，唯有組織裡人人(根據她/他本身的業務需求權限)都可以隨時隨地的分析資料組織才變成是靠數據驅動的組織，每個人都可以依據他/她所分析到的資料而下決定，而Democratizing analytics就是在打破傳統上的資料分析屏障。理想的數據分析是: "人們不用主動地去尋找資訊或數據，而是數據或資訊在人們需要時會自己送上門來"。這種資料分析民主化的方式將有效將組織內的所有人訓練成都是以資料驅動的思維來下所有日常的業務決定而非憑直覺，資料分享也增強了組織日常業務運作的流暢度。另外這種方式也可以有限的分享給合作夥伴甚至是客戶從所有人對於資料分析的新見解發現以前從未注意到的事。
雲端資料平台幫助組織有三項重要的技術革新:
1.雲端平台的崛起 — 雲端平台沒有傳統機房的固定資料處理與儲存能力，提供幾乎無限的資料處裡效能。
2.持續增長的資料 — 現今的數位化時代使得每個人每天都會產生數據資料，如同亞馬遜的創辦人所說的 : 凡人皆攜數據而來。各式各類的資料每天增長而從這些大量且多樣的資料中發現新的事物。
3.分析的重要性 — 我們將從傳統的看報表時代進化到具有前瞻性的預測與指示分析。
實現資料分析的承諾
這一段我們將介紹一些基本與進階的資料分析方法與如何在大量使用者的組織中實現資料分析民主化。另外也會解釋現今組織使用孤立的數據來分析資料的問題在哪(資料的穀倉效應)與檢視基本的資料治理並講述在雲端中資料集中化的好處。
在大部分的組織中絕大多數的人都是使用一些視覺化工具來分析他們的日常作業，但他們使用的絕大多數都是孤立的數據而非全面性的資料。一般組織的資料服務是將你的資料從收集/轉換/傳送/分享給組織中的特定人員(如之前我們提到的高階或具專業技能的人)。理想中這些資料存放地點應該是集中在同一個地點(以資料分析的角度來說)。但從長期來看身為雲端資料平台的管理者你的任務除了協助使用者分析與視覺化資料外，另一個更重要的是在分析資料之前你必須確保組織的資料是完整的、連續的、正確的。如果組織中所有的使用者不信任所分析出來的資料或是因為因誤用道具數據監管風險的資料，哪麼你的組織就不算是數據驅動的組織。
一個完整的分析做法應該包含 : 數據治理、數據品質、數據安全、metadata的管理及其他的問題。沒有有效的access control、一個普遍存在的metadata layer、嚴格的資料治理程序，你將不會有自信的調動資料並讓這些數據任組織獲得好處。要在組織內做分析你需要有前端良好的資料視覺化工具餘後端需多的資料服務，而這些服務是集中在一個雲端資料平台內。
一個完整的雲端資料平台必須要有足夠多的功能，這些功能足以容納許多現今的資料工作型態(如下圖)
把這些服務全部集中在一起。這個平台必須要安全、良好的 access control，並能夠夠包含結構化/半結構化/非結構化的資料型態。
剛剛提到大多數組織使用孤立的數據來分析資料，所以有些組織會把各個資料孤島間的資料倒過來倒過去的。很多的資料工程師或是資料科學家都是浪費時間的在做這種事，其結果仍然沒有做到組織的全部資料的全面性分析。並且使用者也是浪費時間在做資料分析，因為分析結果可能是不完整(導致數據不可信)，所以數據集中化對分析的結果具其重要性。
現實中，許多營運多年的公司充斥著各式各樣的服務(ERP/CRM/Web等等)，每個服務都有自己的資料庫。這種狀況會因為這些資料分析在不一樣的地方分析產生了多諾米骨牌效應:
data warehouses 做operational reporting,
data marts 做departmental analytics,
data lakes 做data mining and data exploration。
每一種的型態我們可能都會用不同的ETL工具來做，這會讓我們分析與管理(使用一堆工具與解決方案)上變得很複雜。因為這樣的關係， 現代化的data pipeline 於是產生了，幫助我們將資料集中化到同一個地方來分析。
對技術人員來說雖然將組織內的資料全部集中化了，但免不了還是需要讀取外部的資料(可能是合作夥伴或上下游的廠商)。所以雲端資料平台讀取多個外部資料如exteral tables(read-only)或materialized views等，這種多功能架構的雲端資料平台是還能達成資料的無縫接軌，高效能，與良好的資料治理功能存在。另外也需要能處理streaming data(例如IoT資料或詐欺偵測服務)這類型的資料，它的特點是資料需要不斷被載入或更新(near real-time)資料庫與不斷的處理的。streaming data的特性之一就是具時間序列(time series)，這種資料必須根據時間序列的特性才能分析出有意義的統計資料。
資料治理
良好的資料分析是基於良好的資料治理上的:
一個普遍性的資料治策略是，找尋一種在組織的data lifecycle中能夠維持高品質的資料，並且是在一種具一致性的控制措施中支援組織的業務目標與達成內外部的法規法令的監管要求。
資料治理的最基本的要求就是要精確地知道你擁有甚麼資料，它存在甚麼地方，誰有權去access它，以及它是如何被授權去允許去使用它的。但大部分的組織可能建立這類的資料治理政策而在內部間爭論不休，而沒有良好的資料治理意即就不會有良好的資料分析能力與沒有數據管理的能力。為了將這種爭論降低，我們就要回到資料得最基本層面來看。意即是資料的 availability/usability/consistency/integrity/security。這幾個要求是為了減少不合規的風險，保護敏感資料，以及將不良資料的不好影響降到最低。還必須要有一個嚴格的流程來防止未經授權的敏感資料傳輸。在不同的數據孤島間防止不正確的資料import/export, copying / combing data，這些都是資料治理及資安要求的一部分。
控制data access
雲端資料治理開始於你的資料從哪裡來，它會放在哪裡，誰有權access它，它將如何被使用，以及最後再你不需要時刪除它。比較容易的方式就是採RBAC的方式來控管，根據不同的role存取不同的資料，資料可以做masking或是採column level來管控。這在資安方面屬於"need-to-know”，根據你的業務需求來看你需要知道甚麼。在雲端或地端機房有著一堆的AAA驗證方案，在此就不再綴述。幾個資料安全的特點需要實行或注意，
Access control / Data protection, retention, and redundancy / Data encryption，這幾個都是你的data in transit 與 at rest需要注意的。
資料品質
資料品質最基本的是資料沒有 corrupt/inaccurate/out of data/incomplete。但大多數的組織人不知道怎樣才算是有品質的資料。這時我們需要數據管家來幫助我們，這一些人其實就是每天都在使用這些數據再做決策的人。這些人都不會是IT技術人員。我們需要這些domain know how來協助我們定義出資料品質的規則與流程，這些人也才可以不讓資料有 corrupt/inaccurate/ out of data的狀況存在。
以下五個步驟提供了良好的資料治理，良好的資料治理其實提供了我們以下這些狀況發生，
poor access controls, inconsistent metadata management, unacceptable data quality, and insufficient data security。
Step 1: 集中化你的資料
集中化的好處在於防止數據孤島會產生追數據沿襲的困難，分類數據，以及能夠實行同一套的資安規則
Step 2:實行嚴格的數據品質流程
我們需要前面提及到的數據管理員來幫我們定義規則與流程
Step 3:對所有的資料進行數據分類
Step 4: 實行一致性的數據安全程序
Step 5: 將組織的內外部的法規法令要求放在自動控制的的方案中
我們需要一套自動化的法規法令的監管方式來及時地告知我們，現行的系統中是不是已經有偏離法規法令的要求狀況存在。
以下是現代化的資料分析的基礎
解放數據的力量
這一部分我們會來描述如何使用雲端資料平台分析你的資料/數據。也會列出 BI/ data science / good query performance / SQL語法的基本原則。也會介紹基本的 data science / Machine learning的概念，並解釋SQL語言的重要性。
分辨事實與直覺
分析其實是使用一堆工具加上本身的直覺來定義我們的假設，然後使用資料分析我們的假設或是驗證每個假設之間的矛盾。長期以來分析師都使用BI工具來尋找資料裡的趨勢或是模式。然後運用他們自己的domain know(通常也包含人類的認知偏誤，不過同樣的挑戰也會在資料科學家在訓練ML模型型發生)來解釋為什麼這些趨勢或事件的模式會發生。
為了用事實支持我們的直覺，許多組織開始從歷史資料的報表轉化成較先進的分析(例如機器學習(ML)或我們前面提及的新式演算法)，去尋找那些可以預測未來的模式。但兩者不一樣的地方在於，傳統使用BI分析的人運用數據加上他的domain know去預測他覺得接下來可能會發生的事(我們稱它是Forecast-這是直覺)，而ML則是運用人類大腦無法同時運用的大量/多樣/長期的數據進行分析，在ML下我們無法辨識模式也無法辨識所有趨勢。這些都已經是資料科學以及其演算法的工作，我們只會得到機器給我們的建議(我們稱它為Prediction-這是事實)。
資料科學的潛力
資料科學包含了針對大量的資料分析使用工具與技術其中當然也包含機器學習ML。很久以前這件事是大型企業才玩得起的是，但隨著雲端技術的普及化資料科學的實行成本與時間也開始變得越來越簡單與便宜。ML的許多模型都有共用的特性存在，例如詐欺與風險偵測通用模型幫助許多保險公司偵測客戶可疑的保險賠償要求或是幫助銀行偵測客戶的信用風險。保險公司可能從客戶車輛的IoT裝置收集各種各項的數據(開車習慣)來決定保費費率及保額。許多資料科學在商業上的使用其實目的就是有一個:
"企業願意使用各式各樣企業的內部與外部的數據來預測即將到來的需求並預測可能的結果"。
要完成這件事，資料科學需要能簡單的存取完整且正確的資料並使用強大的分析工具來探索資料並了解資料告訴我們甚麼事。哪麼使用強大專用的運算資源從資料的準備到連結ML工具並有能力產出ML模型至組織的日常業務流程中就是資料科學的基本作業。
資料科學家的工作流程應該是以下六個步驟:
- 資料收集:
針對每種業務的問題(需要靠分析才知道答案的)資料科學家要能確認他/她需要哪種資料集(data set，包含內組織得內外部資料)來分析。 - 資料探索:
資料科學家可能透過資料視覺化，找尋資料的模式或是針對資料的屬性來辨認資料的模式。 - 特徵工程與轉換
一旦確認相關的資料與其潛力，資料科學家開始做資料清洗與轉換並實現Feature Engineer — 一種確認資料的通用的屬性並從這些資料創造出新的Feature來增強ML演算法的效能的流程。 - 訓練模型:
根據已準備好的資料與新的features engineered開始訓練模型(Models)以其辨識資料的Patterns(哪個Patterns才是有用與準確的)。 - 部署模型
- 評估結果:
每個模型都需要不斷的被監控與評估預測來的結果與真實的情況
視覺化在每個步驟中都會用到。雲端資料平台協助資料科學達到以下三種效果。
AutoML
有錢的大公司可能會請一堆會寫 Scala, R, Java, Python或其他開發語言來實行組織需要的資料科學。根據上面的的流程對資料進行"拷問"，提出假設進行驗證等等一堆工作，進而從資料發現新見解。若是小公司或沒有資料科學的專才一開始也可以用AutoML來協助你，基本上你就是把資料全部一股腦地丟給ML，它會去辨識資料間的相關性並提出建議。但缺點是因為這一切都是自動化的，你不知道"為什麼"機器會做出這樣的建議。
有效的資料查詢
有過資料庫管理經驗人都知道，當你將全部的資料集中在一個平台之後。全部的使用者都會對這個平台進行資料查詢，若是你沒有一套好的方法來解決這件事你就會知道這個平台的負載會有多重，重到可能影響組織的運作。尤其在地端機房這麼做的話可能更嚴重。每家的資料平台都有共通或自己的技術與方法來解決這一種問題，但大部分可能還是資料庫的查詢語法寫得不好。尤其喜歡下 "select * “ 這個語法。SQL語法功用強大也是資料科學家的基本功之一，好的資料查詢語法會讓查詢更快更有效率。而資料工程師也會使用SQL來實行data ingestion的流程(batch mode or live stream)。有些資料平台會使用 streams 與 takes來極大化平台操作的效能。所謂 stream是一種特別的 object type使用一種稱為CDC(change data capture)的技術不斷的將來源端變動的資料同步到目的端，像AWS的 DMS服務就可以讓你將不斷變動的地端資料庫轉移到雲端上去。這個好處是你可以查詢最新的資料在目的端資料而不會增加來源端的負載。task就一個排程性(重複性)的工作，例如每個月月底就要跑一次大量資料又複雜的報表。上面說的這兩種方式可能在地端資料平台會常用到，但資料分散在不同的地方。雲端資料平台的好處在於你的資料是集中化的，但每一種的資料查詢卻可以分配給不同的專屬運算資源，這就解決在傳統資料平台集中化的卻又帶來效能加重的苦果。
將雲端資料分析整合到你既有的IT架構中
這一部分就是實作面的部份，我們將解釋如何整合你現有的許多資料來源到你的雲端資料平台中。透過具彈性的 data pipeline以及建立ㄧ個統一的資料副本來支援不同的資料分析負載。這個雲端資料平台在實行這個作業的同時能夠達成”及時與彈性"，"最小的花費"，"有預期的效能"。
除了專注'技術面之外我們更需要有一個認知，資料分析/資料科學是:
"幫助組織內的知識工作者做出基於事實的決策"。
雲端資料平台就是一種黏著劑，將組織內的使用者與不斷增長的資料資源與來源連結起來。而傳統的資料平台架構會有諸多的不便於麻煩，我們可以看一下以下這張傳統資料架構圖
這種傳統的架構會造成以下問題:
- 複雜性:
每個資料來源都有自己不同的管理方式/安全設定/IT基礎架構 - 碎片化:
造成數據孤島，前面我們提及過。 - 有限的資料共享能力:
資料必須 move/copy才能分享，而這限制了組織內的協同作業並且資料治理與安全無法整合。 - 缺乏可擴展性:
這是地端機房與雲端平台的最大差異之處。 - 費用過高:
在地端機房我們永遠需要評估工作負載最高峰的需求，而其他時間則是資源閒置。對組織來說無疑是浪費浪費資源(不過若你們公司有錢沒地方花哪就是另一回事了)。
使用雲端資料平台上述說的那些傳統架構不用在管，因為雲端平台業者都當你做好了。而你的IT維護費用會變少，整個overall costs也會變少，並且還能有預期的平台效能。(這些都是雲端平台的特性).
而多雲平台的策略相信很多人都知道了在此就不在贅述，但就資料來說使用多雲平台的目的只有一個: 拿回數據的主權，不會因全都的資料都在同一個雲端平台而被鎖住在上面。一個多雲資料平台架構如下
哪為什麼要同一套雲端資料平台而不是使用某一家(AWS/Azure/GCP)的資料平台呢?因為snowflake可以讓你有效的利用這些雲端的資源並且使用的是同一套方法，因為每一家的資料分析的方法/流程/設定可能都不盡相同。若不想被綁在同一個雲端業者而又要同時利用多家業者達到有數據的自主權，使用一套雲端資料平台就是比較合理的做法(除非你們公司人多，可以發配去學不同的雲端資料分析方式，哪另當別論)。然而另一方面若之前已有使用多雲策略的組織，哪麼現有的資料散落在各個雲端平台上資料分享互通有無的執行效率也是非常差的。如何有效與安全的分享散落在不同雲端平台的資料，一套統一的雲端資料管理平台就變得非常重要(當然你也可以手動做這件事)。這樣你就不用把資料移來移去或cpoy 來copy去的，也省去多餘的儲存空間的錢。一個有效資料架構(如下圖)應該要能達到即時的資料分享(不管哪個資料是在哪朵雲上)。
一個好的雲端資料平台能夠達到分享資料是最小化的權限控制(例如某個檔案或某個資料庫欄位的分享，並也能控制組織內外部的使用者)。這麼做的目的不只是一般想達成的access control(need-to-know, Least privilege)更是要達成資料交換:
"一個資料市集，客戶可以在這上面購買第三方的資料並也能夠分享自己的資料上去"。
一個資料生態圈(組織/它的上下游夥伴/友商/客戶等)，在這個資料市集取用資料的人只需付運算的費用而沒有儲存的費用。現代化的雲端資料平台透過這種資料交換的方式將傳統上的資料分享方式的風險/費用最小化，並透過這個資料市集上的資料分析開啟的資料新的商業機會。
而現代化的 Data pipeline架構應該是如下
傳統上程式設計是會寫適合各種場景的ETL工具來將資料放進集中式的資料平台，但現今已經有很多可以適合各式場景的ETL工具可以使用了。資料工程師應該要把焦點放在如何連接這些資料來源，如何使用哪種可靠的方式來收集資料進入平台。使用ETL工具可以讓我們保有最大的選項:
意即我可以根據我的raw data(最原始的資料)轉變成我想要的任何資料型態。傳統的data pipeline搭配ETL工具通常都是用在結構化的資料上面。所以流程上會是E.T.L(extract →transform →Load)。不過若是用在半結構化的資料上，E.L.T會是比較好的選項。因為我們需要保持資料的原始性，以便在於其他地方再度使用。
推動組織的轉型與協調
上面我們提及組織的分析活動該如何的實行，這一部分我們要談的是在組織的人員於流程上如何推動此類型(資料驅動並依據事實做出決策)的改革。
培養組織有數據驅動的文化，能達成這類型的組織通常是有對的人/對的流程/對的技術三者來下達每天的業務決策/決定。甚麼讓他們做對了呢?就是奠定資料驅動的文化與使用先進的技術造就了這類轉型的成功。發展此種文化最難的部分應該是讓組織內所有的使用者有此認知，必須先從使用者的態度開始。
最重要的要先獲得組織的高層/董事會的支持，而第一線的員工也必須獲得分析資料的授權(基於他們的業務需求)。許多組織會設立CDO(chief data officers)或是CAO(chief analytics officers)，這些 C level會設立資料驅動組織所需要的Vision，資源，其他一切必要的作業。並改變組織中的所有人員對資料的心態: 由數據驅動所帶來的業務價值。
另外也會設立數據驅動的CoE(Center of Excellence)卓越中心，關於CoE的定義有興趣的讀者可以Google一下。最重要的是要培養從以前看儀表板與報到的作業轉換到組織內的每個成員都有使用資料自行分析資料的能力。然後觀察甚麼分析作業是有效甚麼是無效的。你就能了解組織內的人有甚麼資料來源是可用的或是不知道怎麼定義他們想尋找的資料。若是這樣的情況，CoE應該給予更多的時間與資源撰寫訓練教材與最佳做法。再來對組織內的人員分級，每個組織它的資料分析的能力成熟度都不會一樣。從資料分析師/資料科學家/資料工程師到組織內的Power user都需要給予不同的任務與作業還有教育訓練。隨著分析能力的成熟度越高，組織從分析活動中也會產生出更多的數據。而不斷升級的分析活動會產生更強大的業務價值。
而數據分析的道德操守也必須同時教育組織內的所有人，讓以下幾點都銘記在心:
- 隱私:
將客戶的個人資料隱私擺在第一位，如何使客戶的個人資料能夠安全. - 透明度:
向客戶公開組織資料收集的作法與如何使用這些數據。 - 客戶的可控性:
告知客戶並授權客戶退出組織的資料收集流程，並記錄實現此目的的方法。 - 教育:
向組織內的使用者組織收集客戶的資料類型，並告知這些資料對客戶的潛在風險是甚麼。 - 當責:
組織內需要有資料管家根據組織的內外部法規發令來保管這些資料。
關於組織的數位轉型
由於分析資料都是資訊科技技術，意味著組織ㄧ但決定朝向數據驅動的方向並擴及組織的全體。哪麼業務流程的數位化將不可並避免，數位轉型計畫的成功在於: 當組織內使用者要把所需要的資料/數據/答案拿到手就要越快越好。在這個流程中就必須減少人為的介入依靠資訊科技術(自然語言處理/AI/機器人等)。而雲端資料平台就位於這個中心點，讓組織的資料很容易將資料做載入/儲存/聯合等動作。並讓前端使用者使用各種不同的分析工具來分析。使用者不用擔心關於資料底層的IT技術如何處理，他們只需要專注在資料間尋找模式或找到對組織業務的新的見解。
Big Data 或AI計畫是一個長期的角度來看 — 這是組織必經的過程與旅程。組織需要採取長期的方法，以複雜文化的挑戰為出發點。
雲端分析的六個入門步驟
我們前面提及了雲端資料分析諸多要實行的事後，最後這一部分提供資料分析的六個入門步驟
Step 1: 檢視現況
檢視目前組織的資料分析技術能力清單，問自己以下幾個問題。這些問題將決定你現有的技術能力是要 reuse, repurpose or replace.
Question 1:需要被分析的資料
資料在雲端還是地端?有多少資料需要被分析?資料來源是甚麼?有既有的data model / structure了嗎?
Question 2: 數據資產
你要分析的資料是個別獨立還是全部集中在一起了?資料是完整的嗎?存取是無障礙的嗎?你能夠"快速"與"安全"的分享資料給組織內的人/外部的夥伴/共應商/客戶嗎?
Question 3: 基礎架構
你的IT基礎架構可以讓組織內外的人在進行資料分析時要使用的運算/儲存資源並不會因IT的基礎架構限制有資源不足的狀況嗎?
Question 4: Data Pipeline
你的data pipeline 足夠健全嗎?你在這個pipeline的哪裡做資料轉換?用甚麼工具餵資料進這個資料平台?這個工具可以不斷的適應一直增長的資料來源與資料量嗎?這個pipeline的資料有batch / streaming 型態嗎?
Question 5: IT管理
維護目前的資料分析平台整個IT團隊的維護代價是甚麼?你需要增購新的設備來應付偶而發生的大量分析需求嗎?
Question 6 : 雲端資源
目前組織有在使用雲端嗎?目前的雲端平台讓組織相關的Applications(如BI tools/ data science tools/data source)容易新增上去嗎?並使用單一的信任來源。
Step 2 : 招募團隊
之前提到要讓組織成功的有數據驅動的文化，正確的人員/流程/技術缺一不可。哪麼組織的R&R(roles and responsibilities)就要被明確的定義出來。軟體工程師/資料科學家/資料管家/商業分析師等等腳色的工作職場。
Step 3: 奠定堅實的基礎
一個統一的雲端資料分析平台可以讓我們的資料儲存與管理的方法一致化，而且能提供組織近乎無限的運算分析能力。提供儲存原始的資料型態且立即的對原始資料進行探索還能支援各式各項與同時大量的分析案例活動。
Step 4 : 遷移資料
將你地端或其他雲端的資料用Data pipeline的方式遷移與集中到一個單一的可信任平台，這個平台不會侷限在任何單一的地理位置。
Step 5: 開始一個試行的專案
可以從一個不會立刻影響組織的業務開始進行，這個專案可以讓組織內的利害關係人看到與展示這個專案的ROI。
Step 6: 準備成長
成功的試行專案意味著組織將更有意願繼續投入此類的專案。而這樣意味著這個雲端的資料平台影響的範圍將會愈來越來，所需要投入的資源也將越來越多。需要更多心力投注在組織所有利害關係人的需求，作業流標準化在平台的能夠加速組織的業務進行與發現新的商機。
PS:
大數據的出現讓我們比以往任何時候都能夠歸檔我們的過去、量化我們的現在、預測我們的未來。因此人類是自己歷史的數據探索家，以智慧方式在歷史的盡頭規劃自己的人生。
