MaxCompute 構建企業雲數據倉庫CDW的最佳實踐建議

在本文中阿里雲資深產品專家雲郎分享了基於阿里雲 MaxCompute 構建企業雲數據倉庫CDW的最佳實踐建議。

本文內容根據演講視頻以及PPT整理而成。

你們下午好，我是雲郎，以前在甲骨文作企業架構師8年，目前是MaxCompute產品經理。

在這麼長的客戶工做過程當中，做爲產品PD，必定是跟客戶在一塊兒的。我常常被一些問題挑戰:雲郎，咱們如今要建數據倉庫，我該怎麼去規劃？雲郎，我如今這邊是大數據的建設團隊，好像數據團隊不怎麼理我，什麼狀況？雲郎，咱們這邊如今建了一個平臺，如今性能好像有問題，是否是咱們哪些地方設計的有問題，仍是考慮的不夠？能夠看到，不一樣的客戶在不一樣的階段有不一樣的問題，在這麼多的客戶問題裏，背後到底隱藏了什麼規律？在這裏面有沒有一些最佳實踐，咱們能夠總結出來，讓你們去少走一些彎路，這是個人出發點。

既然談到最佳實踐，你必定要知道哪些不是最佳實踐，就像醫生必定要看過不少病人之後，才更容易判斷是否是健康。

個人客戶從哪裏來呢？
第一，是阿里巴巴自己有不少個BU，剛纔咱們也談到了阿里巴巴全部的數據都是運行在MaxCompute，去作數據倉庫，去作加工處理。也許你會挑戰我，你解決阿里的問題，咱們碰不到，沒錯，我也確實發現這個問題，即便咱們能解決阿里的問題，可是不必定能解決客戶的問題。
第二，咱們碰到的問題，也不必定能表明客戶的問題，由於你的規模和我不同、你的現狀和我不同、你的能力和我不同、你的目標和我不同。MaxCompute也在雲上提供服務，咱們雲上有不少客戶，在座的不少朋友都是MaxCompute的用戶。因此我把客戶的範圍進一步歸入到我目前已有的這些客戶裏面。也許你還會問，你說你是最佳實踐，那是基於你本身產品的最佳實踐，難道他不用你的產品，你就不能再去分析嗎？
因此，我又分析了第三類客戶，在中國，有不少企業使用了非阿里的技術，那麼他們在這大數據方面又碰到了哪些問題？我相信在座各位也作過不少分享，例如A公司的大數據實踐經驗， B公司的大數據演進歷程，那麼咱們也會基於這樣的案例作出分析。
第四，在阿里這樣的一個生態裏，收購了不少公司，在外界公司和阿里內部公司融合遷移的過程當中，又有哪些最佳實踐？
因此咱們把這四類客戶統一塊兒來看，從現象到本質，這是今天我想要跟你們分享的內容。

你們都在談大數據，最先在2013年開始在甲骨文作信息解決方案，當時已經研究出了大數據。我在以前是作DB的，Data Base。後來發現轉了個身，轉成了BD，Big Data。在這個過程當中，技術好像作了個變化，就翻了個身，關濤講了不少，你們頗有體會。那這些技術在過程當中怎麼去用？方法有沒有發生變化？客戶常常問我一個問題，雲郎，我要拿MaxCompute來幹什麼？我說了不算，後來我就作了不少分析。我發現無論去作什麼應用，客戶在MaxCompute之上，他首先主要都是在構建他的數據倉庫，如今咱們把它叫做Cloud Data Warehouse，你們知道數據倉庫，它既是一套數據體系，同時它也是一個工程過程，要更多的從工程的角度來看，咱們看到這是如今目前業界很是典型的數據倉庫實時的生命週期流程。咱們發現技術從Data Base，DB轉到了BD，可是這張圖不少還被普遍的應用，當我跟不少客戶的架構師，大數據負責人或者開發人員去溝通的時候，咱們發現他背後的思路都是沿着這張設計的生命週期而產生的。那咱們能夠看到從這個數據倉庫，當碰到Cloud Native，再到咱們說轉到Big Data之後，那麼怎麼真的去作Cloud Native這樣一個Data Warehouse，咱們看到在這個過程當中，從項目的工程規劃到業務需求，到最終咱們看到一個小的迭代維護，數倉開發完成，交付你們去使用。

在這個過程當中，咱們能夠看到傳統的DB時代，是以建設爲中心的一個項目。那麼到了大數據，建了是生下來，養纔是關鍵。養之道在於什麼呢？在於運營。因此整個環節中，咱們能夠看缺失了大數據的精髓所在。

咱們看分別是哪些狀況呢？

第一，我相信不少人來自於互聯網公司，若是你來自央企、政府部門，恭喜你，你可能沒有這個痛苦，由於你有足夠的時間去規劃，給你半年時間，給你500萬，你幫我作規劃諮詢出來。但你若是是互聯網公司，對不起，今天上崗，明天幫我把數據拿出來，好很差？因此咱們是沒有那麼多時間的。那咱們在這裏面須要作到什麼呢？輕量化，咱們從數據倉庫整個生命週期上，咱們要的是敏捷數倉。那軟件工程，咱們要的是敏捷開發，數據倉庫。

第二，對於需求的問題，爲何你能作規劃？由於你能知道後面會發生什麼，你的業務基本上是固定的，你能知道政府部門後面要幹什麼、你能知道央企後面要幹什麼，但若是你是互聯網公司，你到明年存不存在都還不必定，也就是說你可能還沒規劃完，就要轉型了，業務要轉型了，需求很是不明確，那你能不能作到明確，挑戰很是大。

第三，若是咱們規劃出來一個很是完美複雜的技術方案，它的落地週期會給咱們帶來挑戰，因此咱們須要技術上可否簡化？要快速纔是王道。

第四，關於數據建模，你一開始就想把這些模型都創建起來，其實這是不少數據工程師常常碰到的問題，我有這麼多數據，我所有都能把它灌進來，把這個模型固化下來。咱們發現掉到這個井裏之後，帶來的後果是什麼呢？你長長久久的是技術本身關在門裏邊，結果業務在門外邊，他敲你的門，永遠敲不開，由於我還在作數據模型的事情，我還在作我本身的事情。

咱們能夠看到關於數倉的應用，你建了大數據，絕對不是傳統的把DB轉成BD，你就仍然去作報表，你的場景毫不是這麼簡單。在這裏必定還有機器學習，人工智能、預測等衆多的應用，它才能發揮價值。這是一個迭代的過程。可能按月都是對這個模型比較讚美的，由於每每可能三個月是一個週期，從提出一個需求，到最後實現，在傳統裏，可能須要月的時間。今天按小時、按天幫我實現，個人數據倉庫要發生變化，你怎麼去構造？

還有就是運維這一側，開發人員和運維人員能作到我們今天的所謂的DevOps，若是你是數據開發人員，怎麼樣能作到整個大數據平臺的DevOps，這是很大一個挑戰。

在以項目管理爲中心、以建設爲中心這樣的背景下，咱們能夠看到真正的數據運營是被忽視的，因此這是咱們今天整個要引出的話題，就是數據的價值必定要經過運營才能得以呈現。運營又是什麼概念呢？

企業大數據計算平臺的建設，跟咱們人的發展同樣，剛開始，談戀愛，蜜月期很是好，其實不少鍋碗瓢盆的問題是不用考慮的。但隨着建設的發展，結婚，生小孩，鍋碗瓢盆的問題必定要考慮的，因此不一樣的問題，其實考慮的痛苦點不同。

咱們看到這樣一個時間軸，橫軸，以時間來推進，第一個月，六到十二個月，十二個到十八個月，到第二十四個月，在分析了上百家的企業客戶後，咱們看到在這樣一個週期裏，分別會碰到什麼樣的問題，技術方案不同，但痛苦是同樣的，風險是同樣的，這是橫軸。

縱軸，業務規模是這條黃色的線，風險是藍色線。業務在這裏面能包出來的半徑就是咱們所謂的價值，藍線包起的面積就是咱們的風險，剛纔關濤也談到了，說咱們的業務面積和風險面積，哪個更大，這就決定了咱們的成敗。咱們看到這樣一張圖，在第一個月是蜜月期，大部分客戶均可以快速的經過定製化方案，快速啓動數據倉庫，由於是蜜月期，很是快，這個時候有熱情、有投資、有人手，咱們快速一個月搞起來了。到了半年到十二個月，業務上來了、規模上來了，這個時候要搭火箭了，要快速成長了，進入青春期了，青春期這個地方是有一個火箭的，這個火箭跟小孩子的成長同樣，到青春期有兩個方面，你管得好，他就是一我的才，管得很差，他可能就變成了一個混混。那這個火箭就在於往哪條線上走。

隨着業務大規模的擴展，數據量、計算量急速增加，這個時候就給咱們的性能、成本帶來了巨大的挑戰和要求，系統能不能解決持續的發展矛盾，就成本、性能、數據安全和分析效率裏面的矛盾隨着咱們業務的發展，咱們如今碰到這些問題，該怎麼去解決？在整個風險上升的過程當中，咱們看到這條線是說風險在上升的。上升了之後，有不少公司，包括咱們的客戶，能夠看到在這個以後就會啓動一輪治理和優化，包括性能的優化、成本的優化，經過階段性的優化，達到好的效果。

接下來業務還在不斷髮展，咱們能夠看到在這兩條線裏面又會走向風險失控的過程當中，也就是說咱們的系統在這個時候變成了成本中心。咱們過去由於有錢有想法，開發了不少定製化的系統，這個時候你的人員開始流動了，你全部定製化的系統就變成了什麼？黑盒子，你碰都不敢碰，就放在這兒等，等SOS，這是風險演變的過程。

對於咱們而言，最佳實踐顯然是不能走這條路的，咱們要避免這樣一條彎路。

再進一步的思考，對咱們作的這樣一個平臺通過治理和優化還不夠。若是咱們能轉型再造，其實能夠回到一個好的狀態，健康最佳實踐的狀態。那這個轉型再造，以阿里大數據平臺來講，有兩個重要的轉型再造，第一個是技術的轉型再造，你們也知道，咱們是最先使用雲梯一Hadoop，咱們從技術的轉型再造就是變成咱們的備胎MaxCompute，其實在2013年在阿里內部早就轉正了，最近備胎很火，它在最初是備胎。轉型再造由本身的技術來替換升級。

接下來，就是業務，阿里這樣的規模，咱們內部的技術能夠輸出到阿里雲上，來進行業務的轉型。咱們得到了這樣新生的過程，能夠看到在整個風險轉移過程當中，你們是在哪個位置，咱們要有清晰的認識。咱們指望的是咱們的技術和業務均可持續發展。在這個裏面的核心點，要解決的是成本可控和性能的不斷提高。數據越多，不是變慢，而必定要更快。數據既要安全，還要共享。你們知道數據進來，誰都不能碰，是沒有用的，要讓數據價值要獲得充分體現。

因此咱們看到整個建設數據平臺的階段性風險，在這個裏面，你們都會栽跟頭，包括咱們都會碰到不少困難。運用《三體》的一句話：「在這些拐點上，毀滅你，與你無關。」，真的是等不及的。對這樣一些客戶的實質性的洞察，我提出一個新的方法論，不知你們有沒有釣過魚，有沒有釣過大魚？釣小魚時，是把魚鉤和魚繩是直接拴在一塊兒的，由於小魚的力量不會那麼猛。但若是你作過海釣，釣大魚的時候，你有沒有發現，若是你的魚鉤和魚繩是直接拴在一塊兒的，那個魚咬了餌之後，把鉤掛住之後，它會忽然有一個很大的力，你的魚繩是直的，因此它會把你的魚繩直接崩掉，形成系統崩潰，在這個裏面就會出現這樣的問題，釣過魚的人就會有這樣的經驗。

可是這裏面是有解決方案的，魚繩上你們都知道是有一個8字環繞線法，把這個線繞得比較虛一點，當這個魚咬到個人鉤，拉的時候，它不會直接拉後面的魚繩，它會用力用到8字環緩衝的這一段線，它忽然間把這一段線拉緊了，那一段線是多股繞在一塊兒的，會有更大的抗擊力，這時候大魚上鉤之後，這個線就不會斷了。

平臺和數據有沒有這樣一種過程？咱們的平臺和數據，剛纔那一個過程是徹底獨立的，我只考慮建設平臺，不考慮數據。可是咱們看到在更多的企業裏面，平臺是一個團隊，數據是一個團隊，或者平臺有不少撥人，數據有不少撥人，但無論怎樣，平臺就是平臺，數據就是數據，咱們說平臺和數據的關係就是我中間畫的一個陰陽圖。因此在這裏面能夠看到，咱們不是簡單的把平臺和數據的工做拼在一塊兒，它就是8字環。咱們能夠看到8字環的奧妙在於從平臺的策略與規劃、設計與實現，這是兩步。你有了最初的原型之後，有了基礎平臺之後，立刻要進入數據運營。你們能夠看到第三步，要在這個裏面，有簡單的數據要去發現，讓數據人員去分析理解、要去探索、要去資產化、要去運營，到了這一步以後，再回到咱們的平臺側去進行開發運維，再進行優化治理。

平臺和數據是對立的，仍是說平臺孕育了數據，數據也孕育了平臺，在這裏面，咱們樹立了什麼樣的觀點？我以爲是你們要去好好思考的。若是你是數據，你去想一想你跟平臺的關係。若是你是平臺，你去想一想你跟數據的關係是什麼？這樣的關係處理很差之後，基本上是不會有最佳實踐的。

因此，第一個是要解決敏捷性的問題，由於你在這裏面能夠很快進入數據階段，從而更敏捷。同時咱們要避免剛纔說的拉鉤斷掉的問題。要鏈接平臺和數據，釋放平臺對數據的支撐力，平臺原本對數據有很好的支撐力，怎麼能釋放出來？這是咱們要考慮的。

還有一個是「風險」，咱們要經過這種方式，不斷的實踐、驗證，將風險消化在平常中。而非作了一個3年規劃，到第二年才發現風險是巨大的。

針對如上內容，給出幾點建議。

• 你是否試圖經過大數據解決未知問題，仍是每天在作已知的報表？
• 你是否有去作預測？是否有作機器學習？是否有對預測性問題的分析？
• 你是否有去引入外部數據來解決問題？你們也能夠看到，剛纔我爲了要回答最佳實踐，做爲一個產品經理，他要去得到的數據源，不只限於阿里內部客戶和雲上客戶，若是我不能去看那些使用了非阿里大數據客戶的狀況的話，他自己也不是一個大數據思惟的工做方式，因此我以爲它是一個思考的模式，無處不在。
• 你對待數據的態度。不少時候，數據處理完，就沒事了。其實你在這裏面不斷的探索、挖掘、分析其中他人不知道的問題，這纔是價值。你能發現問題、解決問題，就是價值，價值不是虛的，問題能解決了，就是有價值。可是咱們作了嗎？在這個過程中，你也許會說人家沒有給我提需求？若是別人提了需求，你來作，這叫支撐。若是你能發現問題，讓別人去作，這叫驅動。什麼叫數據驅動型，若是這些事情咱們都不幹，它不就是一個虛無飄渺的東西嗎？
• 關於咱們組織的問題，雖說咱們在作大數據，可是咱們對它的態度是什麼呢？每一個人在談PPT的時候，都會說數據是資產，歷來沒有人說服務器是資產。可是你作的時候，你必定會說：「我沒有服務器，我怎麼能活呢？我怎麼能作事情呢？」咱們看到就變成這樣一個模式，在這種模式下，你能夠看到貌似數據無處不在，可是數據處處不能用，由於處處都是孤島。咱們能夠看到在數據驅動型的組織裏面，整個業務自己是受數據驅動的，好比說螞蟻金服，因此你的數據在中間，業務在外面。這樣的狀況下，你纔可能把本末倒置的問題解決掉，這是關於組織的問題。

  咱們對驅動組織作了一個分類，數據支撐了咱們運營、生產最基本的工做，仍是支撐了咱們的管理工做，仍是對決策起到了做用，到底在哪個層面上？

必定要基於可持續發展的策略進行規劃，以終爲始去想這個問題，這個終，多是一年、兩年、也多是三年。阿里有句話，路走對了，就不怕遠。可是咱們走錯了，原本往東的，就走西了。在規劃階段要看四個方面。

• 第一，TCO和TVO，TCO是咱們總體運營的成本，咱們要花的錢。TVO是咱們想要獲得的價值是什麼？
• 第二，技術方案。
• 第三，可持續發展。
• 第四，風險控制。

挑重點來講，第一，你們都談到TCO，我以爲你們要注意財務的結構，不一樣的公司的喜愛程度是不同的，有的但願現金流更充足，有的但願一會兒能把錢花出去。要符合企業財務的成本結構，也就是說你要把它變成一次性的資產支出，仍是變成平常的運營支出？要想清楚企業要的是什麼？若是這個搞不清楚，後面就是很大的矛盾。

第二，在這個過程當中不要忽視隱性支出，要知道隱性成本是什麼的，不能對隱性成本是視而不見的。TVO，咱們要以終爲始，兌現數據的業務價值。

作大數據的同窗，無論是作數據仍是作平臺，若是咱們不能幫助企業兌現數據的業務價值，可能很快就會面臨殘酷的結果。這裏的價值，就是咱們經過支撐業務、驅動業務也罷，你必定要挖掘出數據的價值的。

關於技術方案。說到定製化，一般由於咱們後面看到了風險，定製化就變成黑盒。咱們說定製化和產品化的邊界要考慮清楚。當咱們無限的擴充本身定製化邊界之後，你要想到有一天這些東西變成黑盒子之後，它意味着什麼？另外，你是選擇服務器，仍是無服務器，咱們的聚焦點是平臺，仍是數據，這是你們要去考慮。

還有業務適配，不要老是推倒重來。風險應儘早暴露，你們知道規劃出來都是PPT文檔，文檔裏面都是坑，你越晚執行，坑就埋得越久，前面滾雪球滾得很大了，後面解決起來，成本就很是大了。跟軟件開發缺陷解決的原理是同樣的。這個裏面必定要有風險意識。

關於規劃，在設計階段，要支持快速的實現。並不是要求你一天作到，但在互聯網行業去作，可能兩週、一個月，每每三個月就是個階段，能快速實現，三個月真的是一個很長的時間。

架構的設計，從全面性、系統、鏈路，這都是很美好的事情，可是我真心給出建議是夠用就行了，不要過分設計。

技術選型，在PoC咱們要找的是什麼？好用、能用、不能用？你要在這個裏面找到它們的邊界、它們的拐點。你老是找每一個系統裏面最好的那一點，可是你不知道這個裏面不可用的點在哪裏？我舉一個例子，你們就明白了，就是你評測這個系統的時候，你要知道它哪一個地方更好，哪一個地方好用、哪一個地方能用、哪一個地方不能用？當有人承諾全部都是最好用的時候，你就必定要注意。要避免定製化部分的滾雪球，避免定製化陷阱。

在落地實現方面，舉個例子，數據增量，對開發者而言，作數據開發時，好比我寫一個數據的生產過程，那時候的數據量很小，你不會考慮分區。180天之後，由於你沒有考慮外延，它慢慢就增多到180倍了，這個最佳實踐，你們是要留意的。後面咱們的團隊也會總結出來一個技術方面的最佳實踐。包括數據傾斜、做業調度與安全模型、細粒度，這些你們都要考慮到。

在數據價值呈現中，要結合咱們的數據探索和模型固化，由於數據倉庫都是講模型固化的，必定要有模型。可是模型，你們知道週期會變長、會變得僵化、業務會變得不靈活，因此咱們必定要把模型固化和數據探索結合起來，結合剛纔那位同窗關注的數據混合和數據倉庫的關係，在我看來，數據倉庫更適合作模型這一塊的工做，數據混合每每更適合去作數據探索。你能夠在數據探索中很快的發覺隱藏的問題，更快速的進行數據分析，但也會面臨挑戰，數據受權、產出是問題。由於你沒法把你全部的數據都放在裏面，讓每一個人想看什麼就看什麼。數據倉庫，咱們拼了命的作安全，仍然受到你們的挑戰，這是現實問題。

探索以後，如何更敏捷的作數據倉庫呢？那麼你經過這個裏面探索出來的模型來提升複用，經過複用來提高效率。經過模型傳播知識，例如，我如何瞭解我客戶的活躍程度呢？咱們經過模型，拿到這個模型之後，另一個同窗也就理解了，這個模型裏面藏的是知識。還有下降成本，因此咱們把Schema、Schema less這兩種結合起來，將會進一步提升咱們數據處理分析的敏捷性。

還有就是數據資產化，不然的話，你永遠都說不清楚你本身的價值，你其實在幫別人作一個什麼呢？你是在作別人成本的事情，你只有把它資產化了，作數據的人才能說清楚本身的價值在哪裏。經過資產化能夠作什麼？要爲治理提供依據，你只有列得清清楚楚了，才知道哪一個地方花多了、哪一個地方花少了，花得健康不健康，要有這樣健康排名。有了這個排名，咱們就能夠作數據運營。

不少時候，數據運營被解釋成數據化運營。數據化運營和數據運營是大相徑庭的概念。數據化運營是指拿了數據之後，去作運營工做。數據運營，指的是說要把個人數據運營起來。這裏，能夠結合貨幣的概念，流動性。要提升數據的流動性，提升在數據管理團隊之外的投放量，這是很金融化的一個詞，我在準備的時候，就是看了金融的模型來作這個事情。由於要解決流動性的問題金融行業最有經驗，因此我也看了模型。

投放量，咱們能夠看到，這是咱們的數據管理團隊，你們都像小蜜蜂同樣很勤勞，數據獲取、加工組織、存儲。。。小蜜蜂和蜂王都很勤快。那貓頭鷹在哪裏呢？這個圖怎麼沒顯示出來，作數據分析的人不是小蜜蜂，應該是貓頭鷹，很是敏銳，眼睛很毒。數據分析要發現、要探索、要應用、要建模，在這裏，經過數據運營核心要作什麼呢？控制數據的流動性變化趨勢，你的數據，誰在用？流到哪一個地方去？你如今公司的數據流動性，你要採起緊縮政策，仍是寬鬆政策？咱們必定要把這個事情作起來，你能夠經過數據安全來作，也能夠經過專門的團隊來作，若是沒有這部分，就會有風險。

關於數據安全、數據生產管理、數據質量管理、開發管理，咱們也要作到適可而止，不要過分。以安全爲例，最初的時候，我做爲MaxCompute PD，給客戶推薦 MaxCompute是有細粒度安全管理的，你必定要用上。後來，客戶慢慢教育了我，細粒度的安全管理當然很好，但他到用的那一天，他天然會用。他沒用的那一天，當然有他的理由。由於任何管理，越細，成本就越高。企業是否願意在這方面投資，這就是一個現實的問題。若是我沒有那麼多的投資，勢必就會考慮把數據的受權範圍作到以部門、團隊爲受權對象，受權粒度以一個項目爲主就夠了。因此要平衡細粒度安全管理和管理成本，並作出選擇。包括生產管理基線，開發環境，質量管理等，必定要在管理上將責任落實到人，還要實現完善的監督機制，去確保這個能落實，保證數據質量。

優化和治理，每每是個沉重的話題。先說咱們的城市，之前談城市管理，如今談城市治理。城市小的時候，管理就夠了，城市大了，就要治理了，治理什麼？三個字，髒亂差。就像咱們的系統大到必定程度後，也會出現髒亂差。因此須要治理，要從計算層面、存儲、質量、模型、安全、成本方面進行全方位治理，這當中最有效的抓手就是成本。在整個治理的閉環中，有現狀分析、問題診斷、治理、優化、效果反饋，這些咱們都要去落實，才能根本上治理髒亂差。

最後，咱們來看基於MaxCompute構建大數據平臺。從數據開發，是一套Dataworks的平臺，經過接入業務數據源，到數據接入、到數據處理、數據服務以及到應用，這是一個完整的大數據解決方案。在整個大數據平臺中，咱們強調小核心、大外圍。其實在大數據平臺中，數據處理佔據了80%以上的成本，因此必定要讓它簡單。阿里基於這樣一個策略，推出了完整的解決方案。處理方面有MaxCompute，機器學習方面有PAI，在流計算方面，咱們有Stream Compute。

剛纔談到的關於數據那部份內容，這是平臺、這是數據，由這張圖映射到剛纔咱們說的數據中孕育着平臺、平臺中孕育着數據的這樣一個設計理念。在上面，這是以數據爲中心的，在下面，這是以平臺爲中心的，整個合成咱們想要的大數據處理平臺。

同時咱們也分析了不少客戶，不少客戶都已經選擇了Hadoop。因此，咱們也推出了MMA遷移工具和遷移服務，來幫助咱們把Hadoop這樣的集羣遷移到阿里雲的MaxCompute和Dataworks，以及後面的機器學習PAI、流計算等等來幫助咱們加速、提效、提升準確性。

最後總結一下，從方法到落地，我背後的思想就是8字環。這邊是數據、這邊是平臺。平臺側，必定要支持按需裁減的方案。在這個過程當中，要分階段實施，整個過程當中，性能、成本、靈活擴展性、數據的安全以及穩定運維的複雜度是咱們要關注的問題。數據側，咱們要關注並打通數據的全鏈路，要關注全域數據以及數據資產化。

總之，經過咱們背後的指導思想和咱們給出的技術解決方案，但願與你們可以一塊兒探索一些新的基於雲上的數據倉庫構建的最佳實踐，從而儘可能避免走彎路。這就是全部我今天想跟你們分享的內容與目的，很是感謝！

---

本文做者：晉恆

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。