在本文中阿里雲資深產品專家雲郎分享了基於阿里雲 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字環。這邊是資料、這邊是平臺。平臺側，一定要支援按需裁減的方案。在這個過程中，要分階段實施，整個過程中，效能、成本、靈活擴充套件性、資料的安全以及穩定運維的複雜度是我們要關注的問題。資料側，我們要關注並打通資料的全鏈路，要關注全域資料以及資料資產化。

總之，通過我們背後的指導思想和我們給出的技術解決方案，希望與大家能夠一起探索一些新的基於雲上的資料倉庫構建的最佳實踐，從而儘量避免走彎路。這就是所有我今天想跟大家分享的內容與目的，非常感謝！

原文連結
本文為雲棲社群原創內容，未經