雲栖号： https://www.aliyun.com/#module-yedOfott8 第一手的上雲資訊，不同行業精選的上雲企業案例庫，基于衆多成功案例萃取而成的最佳實踐，助力您上雲決策！
AI 前線導讀：通過中台的各技術域能力的建設，技術人員在極少的投入下，就可以支撐數倍的分析人員進行數字化營運工作。3 年時間裡，菜鳥走過了從人力支撐到中台支撐的曆程。菜鳥進階技術專家陳飛在 QCon 全球軟體開發大會（上海站）2019 分享了資料中台技術的實踐、過程中的心路曆程以及未來的思考，本文整理自此次演講。
不知道大家對資料中台這塊了解多少，今年資料中台這個概念又火起來了，大家可能會想要了解一下這個東西是什麼。比如，菜鳥的資料中台是什麼？菜鳥資料中台的整個技術演進？阿裡也在前段時間的雲栖大會上釋出了阿裡資料中台，那阿裡資料中台和菜鳥資料中台有什麼關系，有什麼差別？還有菜鳥是怎麼做資料中台的，怎麼去考核資料中台，等等這些問題。
今天我的分享就是圍繞着以上問題。整體會分成三塊來講，一個是概述篇，對阿裡生态中台演進、資料中台、菜鳥資料中台做一個簡單的概述，友善大家了解一下資料中台到底是個什麼東西。第二個是技術演進篇，這部分會回到我們真正的技術這一塊去講整個資料中台的技術演進。最後一部分是一個簡單的移動資料營運的示例，一個我們對外的場景。
概述篇
阿裡生态中台演進
中台概念
2015 年，阿裡啟動了中台戰略。中台這個詞提了這麼多年，它到底是什麼？
首先，中台是一種經營理念。從整個公司管理來說，這種經營理念就是我利用中台的思想去提升整個公司的組織效率、協同效率和營運效率。
它也是一種組織形式。中台不是說我技術業務拉到一起，畫個架構圖，它其實需要組織架構來保障，是以中台是一種組織形式。
中台火了之後，各種各樣的中台就湧現出來了，很神奇。之是以一夜之間冒出這麼多中台，是因為中台其實是“平台思維”的自然演進。今天很多的中台都是之前的一些平台化的東西的更新版，更新後給了它一個新的一個概念，叫中台。當然，它跟平台是有差别的。
我們了解的整個中台其實有三個特點。第一個是沉澱，除了要完成業務系統開發、業務場景的開發，做技術要有沉澱的東西，去展現出我的技術能力和價值。第二，提升效率，這個很容易了解。第三，降低創新成本，當你有了中台，你的很多能力沉澱起來了之後，你可以很友善地去做前台的業務創新。比如說有某個 App 火起來了，我們可以很快就做出一個競對的 App，因為底層的能力都是現成的，我可以很友善地就把 App 做出來。當然，如果你不具備業務中台能力，其實沒有必要一定要去提中台，業務内自己運作效率才是最高的。
中台演進曆程
下面來講一下阿裡的業務中台、資料中台、菜鳥中台的演進過程。
阿裡早期，各個業務線，各個事業群相對獨立，自己玩自己的，底層的中間件到上層業務系統，大家會有一定的重複建設。後來開始有一個共享事業部，把整個阿裡生态内所有的技術中間件給收掉了，可以看作是一個平台。再到 2015 年，阿裡提出了中台戰略，就有了業務中台，比如說淘寶和天貓裡面都涉及到交易、會員和支付，這些東西我們往業務中台裡去沉，慢慢就變成了阿裡說的“大中台小前台”。這是業務中台這一塊。
資料中台其實也是一樣。從最開始各個事業群自己建設，到橫向的“資料技術産品”、到今天的資料中台，阿裡的資料中台這樣一步一步變成今天的樣子。
我們可以看到，不管是業務中台還是資料中台，前面都有一個平台階段。
那菜鳥的資料中台是什麼？菜鳥資料中台跟阿裡資料中台稍有差異。因為菜鳥成立的時間要晚一些，在那個時間點，平台化的思想在整個阿裡生态體系内已經非常成熟了，大家對于這個東西的認可度非常高。是以菜鳥資料最開始做的時候就是“平台産品“+“數倉“用于支撐上面各業務線的資料化營運場景。今年我們提資料中台，是希望将沉澱的的能力（資料、資産、服務、解決方案）以中台的形式去開放賦能到生态中。
這是我們從整個阿裡生态内去看中台這塊的一個演進的情況。
阿裡資料中台
我稍微展開講一下阿裡的資料中台。阿裡資料中台有一個官網，大家去網上搜一下應該就能找到。阿裡資料中台是把資料中台分成了三塊：方法論、組織、工具。
方法論是什麼？其實可能很多人都聽過，比如阿裡經常講的全域資料，背後是一系列在做資料化營運過程當中沉澱出來的一些方法論。如 OneID，就是我去拉通去看，我們把所有的消費者或者是把所有的商家的資料合到一起，我們去打造一個全域資料。如 OneModel，資料建設了這麼多年，沉澱的一套資料建設方法論。還有 OneService，是再資料向上使用的時候，一套工具和方法論。
組織是什麼？組織結構上來說跟業務中台的差别，業務中台可能都是做技術的，資料中台裡面有資料開發的人員、産品經理，還有産品開發的同學等等，可能還有其他一些細分的工種，構成了整個中台的一個組織。
最後是工具，所有的理念需要變成具象的東西，可操作的東西，需要通過工具去承載。
這是整個阿裡資料中台。
菜鳥資料中台
再下來講講我們菜鳥資料中台。
菜鳥資料平台，我們給它起了個名字叫 CBD，不是大家熟知的城市中的 CBD（中央商業區）。C 是 Cainiao，B 是 Best，D 是 Data。合起來就是我們把我們認為菜鳥最好的資料放在這個地方，提供給大家去用。
順便講一個問題，就是資料中台怎麼去衡量它？首先中台一定要有前台的場景來去使用它，一定要被內建的。為了看我們資料中台建設是好還是壞，我們定了三個 KPI 來量化，第一，數倉的核心表有多少，這個很直覺，你說你是資料中台，結果就三五張表，談什麼資料中台。第二，累計接入應用數，接入應用數是在衡量今天你的資料中台有多少應用內建了你，有多少應用接入了你，這個其實是在辨別我們中台到底有沒有在發揮價值。第三個是服務調用，資料好像有一百個應用接了，但其實一天就調個 10 萬次，這有什麼意義呢？調用次數其實也是衡量整個資料中台價值的一個核心的名額。
背景
接下來講講菜鳥資料中台，為什麼我們要做菜鳥資料中台？
我前面講過，菜鳥資料中台在最開始的時候，就是平台化的思維，“平台産品“加上“數倉“來去支撐菜鳥各個業務線的資料化營運工作，有資料平台的搭建，資料産品的開發 等。我們為什麼要往中台更新，我認為大概有三個出發點或背景，第一更新，第二效率，第三協同。
更新怎麼了解？從 2015 年甚至更早的時間到今天，我們的體系化和資料都有了很多沉澱，工具化體系化已經非常完備。對于我們自己而言需要有新的突破，是以從内部來說，我們需要有這麼一個新的更新。
第二，效率，這是從菜鳥整個業務來看的。不知道大家對菜鳥了解有多少，可能有些人覺得是個快遞公司，是個物流公司，是不是就送個包裹？不是那樣，大家把它想得有點簡單。大家可以在菜鳥官網上看，其實我們的業務線非常多，十個左右，這還是還比較大的業務線。這麼多業務線，隻靠今天的資料部去支撐，有些場景是覆寫不到的。一些業務線或者是相對沒有那麼重要的場景下面，他們也有資料化營運、資料分析的需求。是以其實我們是希望能夠把我們的沉澱以中台的形式開放出來，讓他們去內建使用，進而提升整個菜鳥的數字化營運效率。
第三個是協同，協同怎麼了解？這裡我要提一下菜鳥的使命，全國 24 小時必達，全球 72 小時必達。大家看起來隻是一個數字，背後是包裹經過了一系列的物流網絡，一系列的物流節點最終送達到了你的手裡，比如說分撥、網點，國際還有很多幹線、海關等等很多的環節。為了達到 24 小時，72 小時，需要整個物流網絡非常高效。高效是從哪來的？就是今天我們希望通過數智化的手段來去提升整個物流網絡的營運效率。在這個過程當中，菜鳥自己的資料化營運做得很好，但是能不能達到 24 小時、72 小時，還需要跟很多菜鳥的合作夥伴，菜鳥生态公司一起來提升整個物流網絡的效率。是以這裡有一個協同，我們希望把我們的資料、工具、方法論能夠給到大家，然後共同提升整個物流網絡的效率。
以上菜鳥資料中台建設的背景。
内容
這是菜鳥資料中台的一張簡圖，下面是中台，上面是前台。
資料中台裡面又分成四塊内容，資料，服務，解決方案和心智。
最基礎的就是資料，包含資料中心和資料服務。資料中心很容易了解，那資料服務怎麼了解？我們沉澱了一些重要的全域資料之後，把它服務化，别人想用的時候可以很便捷地把它拿到自己的業務系統裡面去調用，是以服務化簡單了解就是一個 RPC 服務。
再往上是解決方案。解決方案我們又細分成了兩塊，一個叫資料智能解決方案，另外一個叫業務資料解決方案。資料智能是說今天我們生産了這麼多的資料，不管你是要去做一個資料平台，還是把資料拿到業務系統裡面做業務決策，或是用來做風控，在衆多場景應用的過程當中，其實需要一系列的工具和平台去支撐，我們把這個東西統稱為“資料智能解決方案“。還有一塊業務資料解決方案，就是資料圍繞某個特定的業務場景，通過工具化的形式也好，通過資料輸出的形式也好，我們為解決一個切切實實的業務問題來打造的解決方案。比如說你的一個包裹從一個倉出庫了，我需要找一條線路送達到你，哪條線路時效是最快的，哪條線路成本是最低的。這個時候就需要資料的支撐，可以根據曆史上每條線路，哪條最快，出風險的機率是多少等等，做一個判斷，最終選一個最優解。這就是圍繞一些業務場景去做的一些解決方案。
還有一塊是什麼呢？你說你有資料中台，但是誰知道你有資料中台，誰知道你的資料中台有什麼内容？我們資料中台有一塊專門處理這些問題，叫中台心智。中台心智簡單了解是一個偏營運的工作，我把建設完的資料、做出來那些工具解決方案，通過定期郵件也好，通過教育訓練也好，告訴大家我們中台有這麼多内容，我們這個資料能做這些事情，希望大家可以跟我多發生一些連接配接。這裡不僅僅是一個營運，我告訴你我們有什麼，其實也是在量化我的價值，拓展我們資料的價值。是以資料中台的心智也是很重要的一塊。
概述
最後對菜鳥資料中台做一個概述。菜鳥資料中台是什麼？僅僅是資料、服務、解決方案這些就夠了嗎？不夠。我一直在說組織架構，整個中台的團隊，當這些東西合在一起才是整個菜鳥資料中台，才是我們的 CBD，通過這個東西我們去支撐菜鳥，去支撐生态公司，去做生态協同，還有我們内部的數智化營運，資料創新。
小結
這裡簡單做個小結。首先這裡有很多概念性的東西，中台是什麼？中台是一種經營理念，是一種組織形式，是平台産品或平台思維的自然演進。然後是阿裡資料中台，它是方法論 + 組織 + 工具。菜鳥資料中台是資料 + 服務 + 解決方案 + 中台。
看到這裡大家可能産生了新的問題，菜鳥資料中台和阿裡資料中台怎麼不一樣，你們不是一個生态體系嗎？怎麼又搞出兩個概念出來呢？其實它們本質上是一樣的東西。隻是比如說我們說的一些服務解決方案，其實映射的就是阿裡資料中台講的方法論和工具，而它的組織對應的就是我們的中台團隊。本質上其實是一樣的，隻是在不同的場景下，我們面臨着不同的問題，講法可能稍微會有些差異。
技術演進篇
整體技術架構
接下來講講整個資料中台的技術演進，從 2015 年到現在我們做的一些事情。
先看一張整體技術架構圖，分三層，底層是基礎設施，基礎平台，中間是中台，上面是前台。
有些同學可能會有困惑“資料中台和大資料平台”的差別是什麼？圖中的基礎平台就是我們過去常說的大資料平台，包含了資料的采集、計算、加工等。阿裡内部是 ODPS，Blink；開源有 Spark、Hadoop 等等。資料中台是建構在整個大資料平台之上的，它是圍繞資料營運、分析、應用等場景去做的一套解決方案。
資料中台分成兩塊，一個是資料層，一個是服務層。資料層就是我前面說的“數倉“，這裡邊包含菜鳥的所有資料，沉澱的資料資産。再往上是服務層，這裡劃分成了幾個套件，每個套件都是圍繞資料使用的一個場景做的解決方案 / 工具。先不展開，稍後我會分開細講。
旁邊縱向的東西是資料管理套件，從資料的加工生産到使用，它從全鍊路的視角把資料給管理起來。
資料營運套件
先講講資料營運。我們提資料平台、資料倉庫，要解決的問題就資料化營運的問題。資料最基礎的應用形式就是看闆 / 報表，這是 2015 年我們開始做中台的時候面臨的最重要的問題。當然，那個時候還沒有提中台的概念。
當時我們大概有好幾個研發同學，每天寫資料服務向上提供接口到前端，前端通過可視化元件做個渲染，開發一堆的報表出來。這不是個很複雜的業務，沒有什麼業務邏輯，不需要領域架構，不需要劃分域，不用搞領域模組化那套重的東西。就簡單把資料取出來，然後提供接口給前端，前端做個展示，這麼簡單的東西，研發人員的價值怎麼展現？
是以我們就去做了整個資料營運套件。大家做資料化營運的過程當中，一定會有一個門戶網站 / 産品，或者說資料平台，你進去之後能看到跟業務相關的所有的資料，能基于這些資料去做分析決策。裡面最核心的就是站點以及看闆，這個套件也是圍繞這兩塊去建設。
站點搭建的部分我就不細講了，主要就是賬号體系、權限體系和站點配置管理這些東西。
看闆搭建這塊我稍微展開講一下。看闆本質上就是把所需資料以一種可視化的形式展現出來。這裡面我們把它分成兩塊，資料服務 / 資料集 負責把資料取出來，看闆配置負責把資料展示出來。看闆又細分為 分析看闆、資料大屏、名額看闆和移動看闆 幾種形式。
分析看闆：結構通常是上面是幾個大的名額，反映整個業務的情況；中間可能有一些預警的東西，哪個名額有異常，是因為什麼原因導緻的，細分 / 下鑽次元的情況；下面可能是一些明細資料。這種分析看闆相對比較固定，如果有靈活分析需求，還有一種形式，把多元的寬表，放在 OLAP 引擎裡，看闆可以自由選擇分析緯度、下鑽、上卷等。
大屏看闆：雙十一的時候經常有各種各樣的媒體大屏，我們内部其實也會在各個指揮室做各種各樣的資料大屏。
名額看闆：這是一套圍繞業務做的定制化解決方案。當你去做一條業務的時候，最核心的是什麼？你怎麼去看待業務做得好還是壞？你的業務的名額體系是什麼？這些核心名額可以在名額看闆裡展現。
移動看闆：為移動端制作的看闆，滿足移動辦公需求。
站點搭建和看闆搭建構成了資料營運套件。經過幾年，我們所有的研發已經全部從看闆開發工作當中釋放出來了，現在都是分析師自己基于這套工具去搭他想要的資料營運站點。
資料服務套件
到了 2016 年的時候，其實菜鳥已經建設了很多的資料，這些資料不僅僅可以用來搭看闆，其實很多業務系統也需要基于資料做風控或者業務決策等。
現在分布式微服務架構這麼成熟，資料最簡單提供服務的方式其實就是寫個 SQL 把資料查出來，包一個服務化的接口暴露出去。這種方式有個很大的弊端，資料的管控會非常難，這是其中第一個問題。第二個問題是效率非常低。
管控難，難在我很難知道你把我的服務接口用在了哪個産品和哪個場景，而且在有些場景下，我的資料甚至不是以服務化的方式給你的，而是放到一張 DB 裡面，我完全不知道我的資料被誰用了，我也不知道我開放出去了多少資料，調用情況怎麼樣，整個鍊路管控起來會非常難，針對這個問題，我們做了資料服務套件。所有資料都是放在自己的存儲裡，以統一服務化的方式給到需求方，需求方直接對接一個标準化的服務就可以了，不用關心底層的存儲。
第二個問題是效率。資料量小的情況下 MySQL 就能支援簡單的分析；資料到了億級别，百億、千億級别，MySQL 搞不定了，這個時候會引入 OLAP 引擎 ，開源的有很多，這裡就不例舉了，我們内部使用的是 ADB，阿裡雲上也有這個産品。另外有些場景中，資料是 KV 形式，做大資料的都知道 HBase，高吞吐，但 HBase 是不支援 SQL 查詢的（最新版本可以通過 Apache Phoenix），你需要通過 SDK 去操作它，而且它是 free schema 的，連個表結構都沒有，可能每一行的資料結構都有差異。每一個應用去接這些資料的時候都要去了解這麼多的存儲、SDK，學習成本高、效率低下。
圍繞這兩個問題，我們做了統一資料服務平台，它解決了幾個核心問題。第一，統一之後整個管控的問題就解決掉了，我知道我的資料在哪裡，資料被誰用了，被調用了多少次。第二，我們做了一套 Engine，通過 SQL 統一去查詢背後的所有資料。簡單一點講，就是你一寫完一個 SQL，我通過 SQL Parser 解析成 AST 之後，把裡邊所有原資訊拿出來，我就知道你是在查哪張表，哪個字段，你的條件是什麼， 我會通過你寫的 SQL 去做解析，去轉換成 NoSQL（HBase） 的 SDK。再比如内部有個産品叫 Tair，是一個記憶體緩存的中間件，基于 SQL 标準化之後，整個效率提升得非常快。現在寫一個資料服務接口，隻要邏輯比較清楚，分鐘級就能完成一個資料服務接口，别人可以通過 HCF 或者是 HTTP 的形式來調用。
裡邊還有幾個特性，比如跨源 Join，單元化部署，本地模式。下面稍晚展開講一下跨源 Join。有些場景下，流計算的資料，它的資料寫入的 TPS 非常高，通常是放 NoSQL，另外有部分業務資料在 MySQL 裡邊，業務場景需要 2 個資料 結合起來展示，即跨源去做 join。實作的方案是，SQL 解析完之後，如果是跨 DB 的查詢，會把它拆分成多個 DB 查詢的執行計劃，各 DB 查完後再在記憶體中做一個記憶體的 Join 以及聚合計算。這裡考慮穩定性結合場景，我們會限定各 DB 的傳回行數。
現在整個資料服務，每周的調用量大概在億級别，每天幾千萬，根據不同的場景提供 SLA。最進階别可以做到業務核心鍊路中。舉個具體的業務場景，人在香港通過天貓國際下單，通過商品的一些重量資料，動态計算運費，背後的重量測試服務，就是通過資料服務提供的。這是絕大部分資料服務解決方案達不到的。
資料管理套件
2016 年，資料服務這塊也做得挺好之後，一個新的挑戰來了，随着資料看闆增多，同樣的一個名額，比如說物流訂單量，都叫這個名字，在不同的頁面裡，展示的數值有差别，一個頁面可能是 10000，另一個可能是 10010（純假設）。使用者（分析師、營運......）一看，這兩個值對不上，你們這個資料不準。其實背後是名額口徑有細微的差異。我們考慮去做整個資料協同的解決方案。
整個解決方案大概是這樣的，最核心的是中間的名額管理，分析師、業務營運，去名額管理系統裡面，把名額體系和口徑管理起來，然後需求提給資料開發的同學，資料開發的同學接到需求之後，根據資料口徑把資料開發完，再把這個資料關聯回名額上面。分析師、業務營運同學，就可以基于前面的工具去搭他的看闆。這樣的話，看闆上面展示的每個名額，我都能知道這個名額清晰的口徑是什麼。這解決了資料協同的問題。
另外還有一個問題，我們有了這麼多的看闆，很多的資料，它們的生命周期如何管理？就像開發人員經常會接手一些遺留系統，需要有監控來告訴我，系統還有誰在通路？通路了什麼？通路了多少次，我才能決定這些系統的未來。資料也是一樣，我們需要知道資料在哪裡？資料用在了哪裡？哪些人在用？
是以我們做了整個資料的全鍊路追蹤。第一，ODPS 也好，Blink 也好，對于我們本身資料的生産計算這塊的東西，我們自身是有中繼資料的，我可以知道我有生産了多少資料，花了多少成本。第二，前面提到的資料服務，能提供資料放在了哪些存儲裡面，被哪個系統調用了，被內建了多少次。第三，通過資料營運套件，能知道資料是在哪個看闆上，看闆被誰通路了，通路了多少次，什麼時間通路的。基于全鍊路跟蹤，就可以解決資料生命周期閉環的問題。可以基于這套鍊路發現哪些資料是沒在用的，哪些看闆是沒在用的，可以把它下掉。可以量化資料的價值，資料今天在哪個看闆裡被某個總裁看到了，這個總裁天天看這個的資料。
智能推送套件
再下來到了 2017 年，看闆越來越多，但在一些場景下（比如：大促），不能天天盯着這麼多的看闆。我們在想是不是可以把這個模式稍微做一個轉變，過去都是人找資料，今天我們把它反過來，變成資料找人。當這個資料可能異常的時候，可以把預警或者一些看闆推送給相關人，請相關人進行關注。
這套理念和監控系統的理念差不多，大家都知道監控系統， CPU 超 80% 或者多少了報個警，概念比較類似。我們把那套理念套到了資料營運這個場景裡面去。
裡面有個觸發器，它可以是定時的，也可以基于資料去做一些判斷，比如說同行比超出多少等等。還有個資訊卡，我們在資訊卡這塊做了很多工作，比如說圖中的資訊卡，它可以是一段文字，可以是個圖表，可以是跟它相關聯的一些名額，最終這些元素構成了一整個資訊卡，然後通過釘釘去推給你。阿裡内部所有人辦公都是用釘釘的，我們所有的消息都會通過釘釘去觸達，觸達率其實遠高于傳統的郵件。
技術建設總覽
差不多接近尾聲了。因為篇幅的原因，我沒法去把所有的每一個套件都展開去講。整理了一個時間線，從 2015 年到現在，雖然是按時間線講的，但是每年基本都是很多事情一起在做的。
技術架構思考 -2D 原則
最後講講我們在做資料中台過程當中，對架構的一個思考。雖然我們沒有那麼複雜的業務、不是線上業務系統、不需要領域模組化、但還是有一些自己的思考。
在做技術中台過程中，我們總結出了一個 2D 原則。
第一個叫 DIP+。搞技術應該都懂 DIP，為什麼提 DIP 呢？因為今天我們把資料中台輸出給我們的生态公司以及合作夥伴的時候，他們不可能把他們的系統部署在阿裡内部，他一定是在雲上，這個過程當中就會遇到一個什麼問題？同樣一個工具，自己内部使用，我要去維護一套代碼，這個客戶在雲上使用，因為中間價的差異，難道我又要維護一套代碼？這個成本也太高了。于是我們通過 DIP 的依賴倒置把基礎設施給隔離開。所有套件都關心核心邏輯，而在具體場景裡邊，我通過基礎設施的一個插件來解決具體場景依賴問題，這樣就可以一套代碼解決不同環境部署問題。那為什麼叫 DIP+ 呢？我們在不同的場景裡面，它的功能可能是有差異化的，但是我們去做能力建設的時候，不希望做那麼多版本出來，是以對于我們而言，能力在不同的場景裡面，通過配置或開關來去解決不同場景下的一個訴求。
第二個叫 DLCF。我們在中台一直在說要被內建，怎麼內建？第一，有些場景定制化程度非常高，中台能力不具備，要定制化幫他去開發，定制化去對接。第二，有些其實能力差不多，但需要一些簡單的插件，或者簡單寫一些腳本。這叫低代碼。第三，它通過簡單的配置，就能把我們整個的套件內建進去。最後就是開箱即用。
我為什麼沒有在這張圖上把它畫在一起，而是階梯型，一個慢慢往上走，因為我覺得這個東西也在衡量中台的成熟度，當你始終都是在做定制化開發的話，我覺得這個中台的技術成熟度是很低的。當你如果基本上做到了大部分都配置開發，那你的中台成熟度是相對比較高的。
小結一下，技術演進這部分裡面，我們講了資料營運套件、資料服務套件、資料管理套件和智能推送套件，最後介紹了一個 2D 原則。
場景篇
移動資料營運
這是一張簡單圖，是我們在提了中台概念之後幫我們的一些生态公司，或者是我們合作夥伴做的移動端的一個駕駛艙，友善他們随時在釘釘端就可以看到業務的情況。
我的分享就到這裡，希望對大家有用，謝謝大家。
原文釋出時間：2020-1-4
本文作者：陳飛
本文來自阿裡雲雲栖号合作夥伴“
AI前線”，了解相關資訊可以關注“
”