菜鳥數據中臺技術演進之路

不知道你們對數據中臺這塊瞭解多少，今年數據中臺這個概念又火起來了，你們可能會想要了解一下這個東西是什麼。好比，菜鳥的數據中臺是什麼？菜鳥數據中臺的整個技術演進？阿里也在前段時間的雲棲大會上發佈了阿里數據中臺，那阿里數據中臺和菜鳥數據中臺有什麼關係，有什麼區別？還有菜鳥是怎麼作數據中臺的，怎麼去考覈數據中臺，等等這些問題。

今天個人分享就是圍繞着以上問題。總體會分紅三塊來說，一個是概述篇，對阿里生態中臺演進、數據中臺、菜鳥數據中臺作一個簡單的概述，方便你們理解一下數據中臺究竟是個什麼東西。第二個是技術演進篇，這部分會回到咱們真正的技術這一塊去講整個數據中臺的技術演進。最後一部分是一個簡單的移動數據運營的示例，一個咱們對外的場景。

概述篇阿里生態中臺演進 中臺概念

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 原則。

場景篇移動數據運營

這是一張簡單圖，是咱們在提了中臺概念以後幫咱們的一些生態公司，或者是咱們合做夥伴作的移動端的一個駕駛艙，方便他們隨時在釘釘端就能夠看到業務的狀況。

個人分享就到這裏，但願對你們有用，謝謝你們。