【編者按】Nifty運(yùn)營網(wǎng)站已經(jīng)有很長一段時(shí)間，而在基于HTML5的WYSIWYG網(wǎng)頁制作平臺(tái)推出后，用戶在該公司建立的網(wǎng)站已超過5400萬個(gè)，同時(shí)其中大部分網(wǎng)站的日PV都不到100。鑒于每個(gè)網(wǎng)頁的PV都很低，因此傳統(tǒng)的緩存策略并不適用。然而即使是這樣，該公司也只使用了4個(gè)Web Server就完成了這些工作。近日，Wix首席后端工程師Aviran Mordo在“ Wix Architecture at Scale”的演講中分享了他們的策略，下面我們一起看High Scalability創(chuàng)始人Todd Hoff的總結(jié)：

以下為譯文

Wix圍繞擴(kuò)展性上的努力可以用“定制化”三個(gè)字來總結(jié)——在仔細(xì)地審視了系統(tǒng)之后，以高可用和高性能為目標(biāo)對系統(tǒng)進(jìn)行了改善。

Wix使用了多數(shù)據(jù)中心和云服務(wù)，這在通常情況下非常少見，他們將數(shù)據(jù)同時(shí)復(fù)制到Google Compute Engine和AWS。對于故障轉(zhuǎn)移，他們有專門的應(yīng)對策略。

從始至終，Wix都沒有使用事務(wù)。取而代之，所有數(shù)據(jù)都是不可變的，他們?yōu)橛美褂昧艘粋€(gè)非常簡單的最終一致性策略。Wix并不是緩存策略愛好者，簡而言之他們并沒有打造一個(gè)非常高端的緩存層。取而代之，他們將大部分的精力放在了路徑渲染優(yōu)化上，讓每個(gè)頁面的顯示時(shí)間不超過100毫秒。

Wix開始于一個(gè)非常小的系統(tǒng)，使用了單片架構(gòu)；而在業(yè)務(wù)發(fā)展過程中，他們很自然地過渡到一個(gè)面向服務(wù)的架構(gòu)。在整個(gè)架構(gòu)中，他們使用了一個(gè)非常成熟的服務(wù)識(shí)別策略，從而可以很輕易的將所有精力都集中到一個(gè)事件上來。

系統(tǒng)統(tǒng)計(jì)

• 5400個(gè)網(wǎng)站，每個(gè)月都會(huì)新增100萬個(gè)
• 800+TB的靜態(tài)數(shù)據(jù)，每天1.5TB的新文件
• 3個(gè)數(shù)據(jù)中心+兩個(gè)云服務(wù)（谷歌和亞馬遜）
• 300個(gè)服務(wù)器
• 每天7億個(gè)HTTP請求
• 總計(jì)600員工，200人的研發(fā)團(tuán)隊(duì)
• 系統(tǒng)內(nèi)服務(wù)數(shù)量達(dá)50個(gè)
• 4個(gè)公共Web Server來支撐4500萬個(gè)網(wǎng)站

系統(tǒng)組件

• MySQL
• Google和Amazon云服務(wù)
• CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）
• Chef

系統(tǒng)衍變

1. 系統(tǒng)始于簡單的單片架構(gòu)，開始時(shí)只有一個(gè)應(yīng)用服務(wù)器，對于任何人來說，這都是最簡單的初始策略，非常靈活且易于更新。

• Tomcat、Hibernate、定制網(wǎng)絡(luò)框架。
• 使用有狀態(tài)的登錄。
• 無視任何性能和擴(kuò)展性相關(guān)。

2. 兩年后。

• 仍然使用單片服務(wù)器支撐所有事情。
• 擁有了一定規(guī)模的開發(fā)團(tuán)隊(duì)，且需要支撐一定規(guī)模的用戶。
• 依賴性產(chǎn)生的問題。某點(diǎn)的改變通常會(huì)造成整個(gè)系統(tǒng)的變更，無關(guān)領(lǐng)域的故障通常會(huì)造成整個(gè)系統(tǒng)大范圍崩潰。

3. 系統(tǒng)拆分的時(shí)候到了。

• 到面向服務(wù)的架構(gòu)轉(zhuǎn)變，但是這并不是件容易的事情。比如，你如何將某個(gè)功能分離到兩個(gè)服務(wù)中？
• 聚焦用戶在系統(tǒng)中的行為，并將之主要?dú)w結(jié)為3類：修改網(wǎng)站、查看Wix建立的網(wǎng)站以及媒體服務(wù)。
• 網(wǎng)站更新包括服務(wù)器數(shù)據(jù)的數(shù)據(jù)有效性、安全和驗(yàn)證、數(shù)據(jù)一致性以及大量的數(shù)據(jù)修改操作。
• 一旦某個(gè)網(wǎng)站建立完成，用戶就會(huì)進(jìn)行查看。因此，對于整個(gè)系統(tǒng)來說，訪客的數(shù)量十倍于修改者。因此關(guān)注點(diǎn)會(huì)轉(zhuǎn)換為：

• 高可用性。因?yàn)橛脩魳I(yè)務(wù)行為，HA成為系統(tǒng)最大的特性。
• 高性能。
• 高流量值。
• 長尾問題。平臺(tái)上已經(jīng)有了大量的網(wǎng)站，但是它們通常都非常小。單獨(dú)看某個(gè)網(wǎng)站，每天可能只有10或100個(gè)PV。鑒于這種特性，緩存對于系統(tǒng)擴(kuò)展來說并不會(huì)起到太大的作用。因此，緩存變得非常低效。

• 媒體支撐是第二大服務(wù)，包括HTML、javascript、css及images。他們需要一個(gè)途徑來支撐800TB數(shù)據(jù)上的大量請求，其中緩存靜態(tài)內(nèi)容成為制勝的關(guān)鍵。
• 新系統(tǒng)看起來像一個(gè)網(wǎng)絡(luò)層，網(wǎng)站被切分為3個(gè)部分服務(wù)：修改部分（任何對數(shù)據(jù)產(chǎn)生修改的操作），媒體部分（支撐靜態(tài)內(nèi)容，只讀），公共部分（一個(gè)文件被訪問的首部分，只讀）。

服務(wù)打造的指導(dǎo)方針

• 每個(gè)服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫，每個(gè)數(shù)據(jù)庫只能一個(gè)被一個(gè)服務(wù)寫入。
• 數(shù)據(jù)庫只能被服務(wù)的API訪問，這樣可以將關(guān)注點(diǎn)分離，并將數(shù)據(jù)模型對其他服務(wù)透明。
• 鑒于性能原因，其他服務(wù)只被賦予數(shù)據(jù)庫的只讀權(quán)限，一個(gè)數(shù)據(jù)庫只能被一個(gè)服務(wù)寫入。
• 服務(wù)都是無狀態(tài)的，這讓水平擴(kuò)展非常便捷，業(yè)務(wù)的增長只需要添加更多服務(wù)器就可以支撐。
• 不使用事務(wù)。除下billing/financial 事務(wù)以外，所有其他服務(wù)都不使用事務(wù)，這里的理念是避免數(shù)據(jù)庫事務(wù)所帶來的開銷，從而提升性能。鑒于不使用事務(wù)，開發(fā)者必須考慮設(shè)計(jì)合適的數(shù)據(jù)模型來完成事務(wù)邏輯特性，從而避免不一致狀態(tài)。
• 在新服務(wù)設(shè)計(jì)時(shí)，緩存并不是所需要考慮的因素。首先，盡可能的考慮服務(wù)性能，然后快速的部署到生產(chǎn)環(huán)境，查看服務(wù)的運(yùn)行情況。只有在代碼無法優(yōu)化的情況下，才使用緩存來解決性能問題。

更新服務(wù)

• 更新服務(wù)必須處理大量的文件。
• 數(shù)據(jù)被使用不可變的JSON pages在MySQL中存儲(chǔ)，每天大約250萬個(gè)。
• MySQL是個(gè)非常棒的鍵值存儲(chǔ)。鍵的設(shè)定基于文件的哈希函數(shù)，因此鍵是不可變的，通過主鍵來訪問MySQL可以獲得非常理想的性能。
• 可接受的擴(kuò)展性。在擴(kuò)展性方面，Wix又做了什么樣的權(quán)衡？Wix之所以不使用NoSQL的原因是NoSQL往往會(huì)犧牲一致性，而通常開發(fā)者并不具備處理這種情況的能力，所以堅(jiān)持MySQL也并非不可。
• 動(dòng)態(tài)數(shù)據(jù)庫。為了給那些經(jīng)常訪問的網(wǎng)站讓路，所有網(wǎng)站的冷數(shù)據(jù)（通常是建立時(shí)間超過3個(gè)月以上的數(shù)據(jù)）都會(huì)被轉(zhuǎn)移到其他的數(shù)據(jù)庫，這些數(shù)據(jù)庫的性能往往會(huì)非常低，但是容量很高。
• 給用戶增長留有容量空間。大型檔案數(shù)據(jù)庫是非常緩慢的，但是鑒于數(shù)據(jù)使用的頻率這不會(huì)出現(xiàn)任何問題。但是一旦這個(gè)數(shù)據(jù)被訪問，在下次訪問之前這個(gè)數(shù)據(jù)就會(huì)被轉(zhuǎn)移到活躍數(shù)據(jù)庫。

打造更新服務(wù)的高可用性

• 大數(shù)據(jù)體積達(dá)到一定程度時(shí)，任何事情的高可用都是難以保證的。因此，著眼關(guān)鍵路徑，在網(wǎng)站領(lǐng)域無疑就是網(wǎng)站的內(nèi)容。如果網(wǎng)站的一個(gè)裝飾部分問題，它對網(wǎng)站的可用性不會(huì)造成任何致命影響。因此對一個(gè)網(wǎng)站來說，關(guān)鍵路徑才是唯一關(guān)注點(diǎn)。
• 防止數(shù)據(jù)庫崩潰。如果你想盡可能快的完成故障轉(zhuǎn)移，務(wù)必做好數(shù)據(jù)庫的備份，并在故障恢復(fù)時(shí)快速切換到從數(shù)據(jù)庫。
• 數(shù)據(jù)完整性保護(hù)。這里并不一定是惡意破壞，一個(gè)bug可能就會(huì)對數(shù)據(jù)存儲(chǔ)產(chǎn)生影響。所有數(shù)據(jù)都是不可變的，為任何數(shù)據(jù)保存校訂版本。最壞的情況下，即使數(shù)據(jù)被破壞到無法修復(fù)，我們也可以將之恢復(fù)到修訂版本。
• 阻止不可用情況發(fā)生。區(qū)別于桌面應(yīng)用程序，網(wǎng)站必須可以被隨時(shí)隨地地訪問。因此，在不同地理位置的數(shù)據(jù)中心，不同云環(huán)境中對數(shù)據(jù)進(jìn)行備份非常重要，這將賦予系統(tǒng)足夠的彈性。

• 在一個(gè)網(wǎng)站上點(diǎn)擊“保存”按鈕，修改會(huì)話會(huì)給修改服務(wù)器發(fā)送一個(gè)JSON文件。
• 服務(wù)器會(huì)給活躍MySQL服務(wù)器發(fā)送頁面，同時(shí)它會(huì)在另一個(gè)數(shù)據(jù)中心進(jìn)行備份。
• 當(dāng)數(shù)據(jù)在本地修改后，一個(gè)異步的進(jìn)程會(huì)將修改上傳到一個(gè)靜態(tài)網(wǎng)格，也就是所謂的媒體部分。
• 當(dāng)數(shù)據(jù)被傳輸?shù)届o態(tài)網(wǎng)格后，一個(gè)通知會(huì)發(fā)送給保存在Google Compute Engine上的存檔服務(wù)。存檔服務(wù)會(huì)連接到這個(gè)靜態(tài)網(wǎng)格，下載這個(gè)修改頁面，并將之保存在谷歌云服務(wù)中。
• 然后，一個(gè)通知會(huì)發(fā)送到修改器，告知頁面已經(jīng)存儲(chǔ)到GCE。
• 同時(shí)，系統(tǒng)會(huì)根據(jù)GCE的數(shù)據(jù)在Amazon中保存另一個(gè)副本。
• 當(dāng)最后一個(gè)通知收到后，這意味著這個(gè)數(shù)據(jù)已經(jīng)保存了3個(gè)副本：一個(gè)數(shù)據(jù)庫，一個(gè)靜態(tài)網(wǎng)格以及一個(gè)GCE。
• 對于新版本來說是3個(gè)副本，而對于舊版本來說則會(huì)存在兩個(gè)副本。
• 這個(gè)過程具備自我修復(fù)的特性。如果這里存在一個(gè)錯(cuò)誤，當(dāng)用戶下一次更新其網(wǎng)站內(nèi)容時(shí)，所有未完成的修改會(huì)被重新上傳。
• 停用文件會(huì)做垃圾收集處理。

使用無數(shù)據(jù)庫事務(wù)方式給數(shù)據(jù)建模

• 對于服務(wù)擁有者來說，他們從來都不期望發(fā)生這樣的情況：用戶同時(shí)對兩個(gè)頁面進(jìn)行修改，結(jié)果只有一個(gè)頁面被存儲(chǔ)到了數(shù)據(jù)庫中，這就造成了不一致狀態(tài)。
• 取得所有JSON文件，隨后按照順序?qū)⑺麄儽４娴綌?shù)據(jù)庫。當(dāng)所有數(shù)據(jù)被保存后，一個(gè)命令會(huì)被發(fā)布，它包含了上傳到這個(gè)靜態(tài)服務(wù)器上所有被保存頁面的ID清單（靜態(tài)服務(wù)器中文件名稱的哈希值）。

媒體部分

• 存儲(chǔ)了大量文件。800TB的用戶媒體文件，平均每天300萬個(gè)文件，5億條元記錄。
• 對圖像進(jìn)行修改。它們會(huì)針對不同設(shè)備和屏幕對圖像進(jìn)行修改。在這里，可以根據(jù)需求插入水印，同時(shí)還可以對音頻格式進(jìn)行轉(zhuǎn)換。
• 建立一個(gè)一致性分布式文件系統(tǒng)，使用多數(shù)據(jù)中心備份模式，并且實(shí)現(xiàn)跨數(shù)據(jù)中心的故障恢復(fù)。
• 運(yùn)行的痛苦。32個(gè)服務(wù)器，每9個(gè)月翻一倍。
• 計(jì)劃遷移到云中以獲得更好的擴(kuò)展性。
• 讓供應(yīng)商鎖定見鬼。因?yàn)槎际褂昧薃PI，只需要改變實(shí)現(xiàn)方式就可以在數(shù)周內(nèi)跨云服務(wù)供應(yīng)商進(jìn)行遷移。
• 在Google Compute Engine中遭遇失敗。當(dāng)他們從數(shù)據(jù)中心遷移到GCE時(shí)，很快就受到了谷歌云服務(wù)的限制。而在谷歌做出了一些改變后，系統(tǒng)得以正常運(yùn)行。
• 數(shù)據(jù)是不可變的，因此非常有利于緩存。
• 圖像請求會(huì)首先發(fā)送到CDN。如果所請求的圖像在CDN中并不存在，請求會(huì)被直接傳遞給他們奧斯丁的主數(shù)據(jù)中心。如果在主數(shù)據(jù)中心也沒有發(fā)現(xiàn)這個(gè)圖像，隨后尋找的地點(diǎn)就是谷歌云服務(wù)。如果谷歌云服務(wù)中仍然未發(fā)現(xiàn)所請求的圖像，那么下一個(gè)尋找地點(diǎn)則是坦帕市的數(shù)據(jù)中心。

公用部分

• 解析URL（在4500萬網(wǎng)站中），并將之分配給指定的渲染程序，然后轉(zhuǎn)換成HTML、sitemap XML或者robots TXT等。
• 公用的SLA，峰值時(shí)響應(yīng)時(shí)間低于100毫秒。網(wǎng)站必須是高可用的，同時(shí)也需要非常高的性能，但是緩存卻并不能發(fā)揮作用。
• 當(dāng)一個(gè)用戶修改某個(gè)頁面并進(jìn)行發(fā)布后，包括這個(gè)頁面元素的清單會(huì)被推送到公用環(huán)境，同時(shí)推送的還有路由表。
• 最小化宕機(jī)情況。解析一次路由需要促發(fā)一個(gè)數(shù)據(jù)庫調(diào)用。將請求分配個(gè)渲染器需要1次RPC調(diào)用。獲得網(wǎng)站清單也需要一次數(shù)據(jù)庫調(diào)用。
• 查詢表會(huì)在內(nèi)存中進(jìn)行緩存，每5分鐘修改一次。
• 因?yàn)樾枰獋魉徒o編輯器，數(shù)據(jù)不可能保存為同一種格式。數(shù)據(jù)使用非規(guī)范化格式進(jìn)行存儲(chǔ)，通過主鍵進(jìn)行優(yōu)化，所有需求的內(nèi)容都會(huì)在單一請求中返回。
• 最小化業(yè)務(wù)邏輯。數(shù)據(jù)是非規(guī)范化的，并且進(jìn)行預(yù)計(jì)算。大規(guī)模場景下，每秒內(nèi)發(fā)生的每個(gè)操作都會(huì)乘以4500萬次，因此發(fā)生在公共服務(wù)器上的每個(gè)操作都需要被調(diào)整。
• 頁面渲染

• 由公共服務(wù)器返回的html是 bootstrap html類型的，它使用了一個(gè)JavaScript Shell，并包含了所有網(wǎng)站清單和動(dòng)態(tài)數(shù)據(jù)相關(guān)的JSON數(shù)據(jù)。
• 渲染會(huì)被放在客戶端進(jìn)行。當(dāng)下，筆記本電腦和移動(dòng)設(shè)備已經(jīng)擁有了很強(qiáng)大的性能，它們完全可以從事這個(gè)工作。
• 之所以選擇JSON，因?yàn)榻馕龊蛪嚎s都非常方便。
• 客戶端上的bug非常容易修補(bǔ)。修補(bǔ)客戶端bug只需要重新部署一個(gè)客戶端代碼，如果在服務(wù)器端進(jìn)行渲染，html則會(huì)被緩存，因此修補(bǔ)一個(gè)bug需要重新渲染上千萬個(gè)網(wǎng)站。

公用部分的高可用性

• 雖然目標(biāo)是一直可用，但是總會(huì)發(fā)生一些意外情況
• 通常情況下：請求由瀏覽器發(fā)出，隨之會(huì)被傳輸?shù)揭粋€(gè)數(shù)據(jù)中心，通過一個(gè)負(fù)載均衡器，它將會(huì)給發(fā)送到一個(gè)公共服務(wù)器，解析路由，傳送給渲染器，隨后返回到瀏覽器，并使用瀏覽器運(yùn)行javascript。隨后，瀏覽器會(huì)對檔案服務(wù)發(fā)送請求，檔案服務(wù)會(huì)做與瀏覽器相同的操作，然后將數(shù)據(jù)儲(chǔ)存到緩存。
• 數(shù)據(jù)中心丟失發(fā)生的情況：這時(shí)候，所有UPS都會(huì)掛掉，數(shù)據(jù)中心也會(huì)丟失。所有DNS都會(huì)被改變，請求會(huì)發(fā)送給次數(shù)據(jù)中心。
• 公用部分丟失的情況：當(dāng)負(fù)載均衡器配置只進(jìn)行一半發(fā)生這個(gè)問題時(shí)，所有公共服務(wù)器都會(huì)丟失?；蛘弋?dāng)部署錯(cuò)誤版本時(shí)，服務(wù)器則會(huì)拋出故障。Wix通過定制負(fù)載均衡器代碼來解決這個(gè)問題，在公共服務(wù)器丟失時(shí)，他們會(huì)將檔案服務(wù)器路由到高速緩存，即使系統(tǒng)在警報(bào)后已經(jīng)進(jìn)行故障恢復(fù)。
• 在網(wǎng)絡(luò)連通性很爛的情況：請求由瀏覽器發(fā)出，隨之會(huì)被傳輸?shù)揭粋€(gè)數(shù)據(jù)中心，通過一個(gè)負(fù)載均衡器，并返回對應(yīng)的html?，F(xiàn)在JavaScript代碼必須取回所有的JSON數(shù)據(jù)和頁面。隨后進(jìn)入內(nèi)容分發(fā)網(wǎng)絡(luò)，發(fā)送到靜態(tài)網(wǎng)格，并獲得所有的文件進(jìn)行網(wǎng)站渲染。在網(wǎng)絡(luò)很卡的情況下，文件返回可能無法進(jìn)行。JavaScript則會(huì)做出選擇：如果主要位置無法獲得文件，代碼則會(huì)在檔案服務(wù)中獲取。

學(xué)到的知識(shí)

• 識(shí)別業(yè)務(wù)的關(guān)鍵路勁和關(guān)注點(diǎn)，仔細(xì)了解產(chǎn)品運(yùn)行的方式，開發(fā)使用場景，盡力讓你工作物有所值。
• 使用多云和多數(shù)據(jù)中心。為了更好的可用性，在關(guān)鍵路徑上建立冗余。
• 對數(shù)據(jù)進(jìn)行轉(zhuǎn)換，最小化進(jìn)程外跳，一切只為了性能。預(yù)計(jì)算并做一切可以做的事情來減少網(wǎng)絡(luò)抖動(dòng)。
• 利用好客戶端的CPU，為可用性建立關(guān)鍵路徑上的冗余。
• 從小做起，先跑起來，然后尋找下一個(gè)決策。從始至終，Wix首要解決的都是如何才能讓服務(wù)可以良好運(yùn)行的工作，然后有條不紊的轉(zhuǎn)移到面向服務(wù)的架構(gòu)。
• 長尾需要不同的途徑進(jìn)行解決。取代緩存一切，Wix通過優(yōu)化渲染途徑來提升服務(wù)，并將數(shù)據(jù)在活躍和檔案數(shù)據(jù)庫中同時(shí)進(jìn)行備份。
• 使用不可變的方式。不可變會(huì)對服務(wù)的架構(gòu)產(chǎn)生深遠(yuǎn)影響，覆蓋后端到客戶端的所有處理，對于許多問題來說，這都是個(gè)優(yōu)雅的解決方案。
• 供應(yīng)商鎖定根本不存在。所有功能都通過API實(shí)現(xiàn)，只需要修改實(shí)現(xiàn)就可以在數(shù)周內(nèi)完成不同云供應(yīng)商的遷移。
• 最大的瓶頸來自數(shù)據(jù)。在不同云環(huán)境中轉(zhuǎn)移大量數(shù)據(jù)異常困難。

原文鏈接： Nifty Architecture Tricks From Wix - Building A Publishing Platform At Scale（翻譯/童陽 責(zé)編/仲浩）

CSDN誠邀您參加中國大數(shù)據(jù)有獎(jiǎng)大調(diào)查活動(dòng)，只需回答23個(gè)問題就有機(jī)會(huì)獲得最高價(jià)值2700元的大獎(jiǎng)（共10個(gè)）， 速度參與進(jìn)來吧！

全國大數(shù)據(jù)創(chuàng)新項(xiàng)目評(píng)選活動(dòng)目前也在如火如荼進(jìn)行中，詳情點(diǎn)擊這里。

2014中國大數(shù)據(jù)技術(shù)大會(huì)（Big Data Technology Conference 2014，BDTC 2014）將于2014年12月12日-14日在北京新云南皇冠假日酒店召開。傳承自2008年，歷經(jīng)七屆沉淀，“中國大數(shù)據(jù)技術(shù)大會(huì)”是目前國內(nèi)最具影響、規(guī)模最大的大數(shù)據(jù)領(lǐng)域技術(shù)盛會(huì)。本屆會(huì)議，你不僅可以了解到Apache Hadoop提交者Uma Maheswara Rao G（兼項(xiàng)目管理委員會(huì)成員）、Yi Liu，以及Apache Hadoop和Tez項(xiàng)目管理委員會(huì)成員Bikas Saha等分享的通用大數(shù)據(jù)開源項(xiàng)目的最新成果和發(fā)展趨勢，還將斬獲來自騰訊、阿里、Cloudera、LinkedIn、網(wǎng)易等機(jī)構(gòu)的數(shù)十場干貨分享。 當(dāng)下門票團(tuán)購還有些許優(yōu)惠， 預(yù)購從速。

免費(fèi)訂閱“CSDN大數(shù)據(jù)”微信公眾號(hào)，實(shí)時(shí)了解最新的大數(shù)據(jù)進(jìn)展！

CSDN大數(shù)據(jù)，專注大數(shù)據(jù)資訊、技術(shù)和經(jīng)驗(yàn)的分享和討論，提供Hadoop、Spark、Impala、Storm、HBase、MongoDB、Solr、機(jī)器學(xué)習(xí)、智能算法等相關(guān)大數(shù)據(jù)觀點(diǎn)，大數(shù)據(jù)技術(shù)，大數(shù)據(jù)平臺(tái)，大數(shù)據(jù)實(shí)踐，大數(shù)據(jù)產(chǎn)業(yè)資訊等服務(wù)。