00. 平臺的業務

從平臺這個概念本身來說，它提供的是支撐作用，通過整合、管理不同的基礎設施、技術框架，一些通用的流程規范來形成一個通用的、易用的GUI來給用戶使用。通用性是它的考量之一、也是所有平臺的愿景之一：希望平臺能適用于各個不同的業務線來產生價值。所以從業務上來說，作為一個平臺本身是不會、也不應該有太多specific的業務功能的。當然這只是理想情況，有時候為了平臺使用方的需求，也不得不加上一些業務領域特定的功能或者補丁來適應業務方，特別是平臺建設初期，在沒有太多業務的使用的時候。整體來看，平臺自身的業務可謂是非常簡單，可以用一張圖來表示：

平臺的業務

上面這個分支是標準的機器學習流程的抽象。從數據準備，數據處理，模型訓練，再到模型上線實現價值完成整個流程。

下面這個分支，也是機器學習和數據科學領域中不可或缺的，主要指的是類似于Jupyter Notebook這類，提供高度靈活性和可視化的數據探索服務，用戶可以在里面進行數據探索、嘗試一些實驗來驗證想法。當然當平臺擁有了SDK/CLI之后，也可以在里面無縫集成上面這條線里面的功能，將靈活性與功能性融合在一起。

01. 基礎設施

上面提到平臺本身是整合了不同的基礎設施、技術框架和流程規范。在正式開始之前，有必要介紹下本文后續所使用的的基礎設施和框架。

在容器化、云化的潮流中，Kubernetes基本上是必選的基礎設施，它提供靈活易用的基礎設施和應用管理能力，同時擴展性非常好。它可以用于

部署平臺本身

調度一些批處理任務(這里主要指離線任務，如數據處理、模型訓練。適用的技術為：Spark on kubernetes/Kubernetes Job)，

部署常駐服務(一般指的是RESTful/gRPC等為基礎的服務，如啟動的Notebook、模型發布后的模型推理服務。適用的技術為Kubernetes Deployment/Kubernetes Statefulset/Service等)。

機器學習的主要場景下，數據量都是非常大的，所以Hadoop這一套也是必不可少的，其中包含基礎的Hadoop(HDFS/HIVE/HBase/Yarn)以及上層計算框架Spark等。大數據技術體系主要用于數據存儲和分布式數據處理、訓練的業務。

最后就是一些機器學習框架，Spark系的(Spark MLlib/Angel)，Python系的(Tensorflow/Pytorch)。主要用途就是模型訓練和模型發布(Serving)的業務。

02.原始數據

原始數據，也叫做數據源，也就是機器學習的燃料。平臺本身并不關心原始數據是如何被收集的，只關心數據存儲的方式和位置。存儲的方式決定了平臺是否能支持此種數據的操作。存儲的位置決定了平臺是否有權限、有能力去讀取到此數據。按主流的情況來看，原始數據的存儲一般支持四類形式：

傳統的數據庫，例如RDS/NoSQL。這類數據源見得比較少，因為一般在大數據場景下，通用的解決方案是將此類數據源通過一些工具導入到大數據體系中(如Sqoop)。對于此類數據源的支持也是很簡單的，使用通用的Driver 或者 Connector即可。

以HDFS為媒介的通用大數據存儲。此類數據源使用較為廣泛，最常見的是HDFS文件(parquet/csv/txt)和基于HDFS的HIVE數據源。另外，由于是大數據場景下的經典數據源，所以上層的框架支持較為完善。

NFS。NFS由于其快速的讀寫能力，以及悠久的歷史。很多企業內部都有此基礎設施，因而已有的數據也極有可能存儲在上面。

OSS(對象存儲)。最過于流行的要屬S3了。對象存儲是作為數據湖的經典方案，使用簡單，存儲理論上無限，和HDFS一樣具備數據高可用，不允許按片段更改數據，只能修改整個對象是其缺點。

值得注意的是，NFS和OSS一般用于存儲非結構化數據，例如圖片和視屏。或者用于持久化輸出目的，如容器存儲，業務日志存儲。而HDFS和數據庫里面存放的都是結構化、半結構化的數據，一般都是已經經過ETL處理過的數據。存儲的數據不一樣決定了后續的處理流程的區別：

NFS/OSS系數據源，基本上都是通過TensorFlow/Pytorch來處理，數據一般通過Mount或者API來操作使用。當然也有特例，如果是使用云服務，例如AWS的大數據體系的話，絕大多數場景下，是使用S3來代替HDFS使用的，這也得益于AWS本身對于S3的專屬EMRFS的定制化。當然Spark本身等大數據處理框架也是支持此類云存儲的。

HDFS系和傳統數據庫系數據源，這個大數據框架、Python系框架都是可以的。

平臺一般會內嵌對以上數據源的支持能力。對于不支持的其他存儲，比如本地文件，一般的解決方案是數據遷移到支持的環境。

03.數據導入

這應該是整個平臺里較為簡單的功能，有點類似于元數據管理的功能，不過功能要更簡單。要做的是在平臺創建一個對應的數據Mapping。為保證數據源的可訪問，以及用戶的操作感知。平臺要做的事情可以分為三步：

訪問對應的數據源，以測試數據是否存在、是否有權限訪問。

拉取小部分數據作為采樣存放在平臺中(如MySQL)，以便于快速展示，同時這也是數據本身的直觀展現(Sample)。對于圖片、視頻類的，只需要存儲元信息(如資源的url、大小、名稱)，展示的時候通過Nginx之類的代理訪問展示即可。

如果是有Schema的數據源，例如Hive表，數據源的Schema也需要獲取到。為后續數據處理作為輸入信息。

技術上來說，平臺中會存在與各種存儲設施交互的代碼，大量的外部依賴。此時，外部依賴可能會影響到平臺本身的性能和可用性，比如Hive的不可用、訪問緩慢等，這個是需要注意的。

業務上來說，更多考量的是提高系統的易用性，舉個例子，創建Hive表數據源，是不是可以支持自動識別分區，選擇分區又或者是動態分區(支持變量)等。

04.數據處理

這里的數據處理是一個大的概念，從我的認知上來看。大體可以分成兩個部分， 數據標注以及特征處理。

數據標注

數據標注針對是的監督學習任務，目前機器學習的應用場景大多都是應用監督學習任務習得的。巧婦難為無米之炊，沒有足夠的標注數據，算法的發揮也不會好到哪兒去。對于標注這塊。業務功能上來說，基本上可以當成是另一套系統了，我們可以把它叫做標注平臺。但從邏輯關系上來說，標注數據是為了機器學習服務的。本質上也是對數據的處理，所以劃到機器學習平臺里面也沒有什么問題。

標注平臺對應了之前提到平臺的另一功能：提供通用的流程規范。這里，流程指的是整個標注流程，規范指的是標注數據存儲的規范，比如在圖像領域，目前沒有通用而且規范的存儲格式，比較需要平臺來提供一種通用的存儲格式。

數據標注有兩種，一種是人工標注; 另一種是使用已訓練好的機器學習模型來標注，然后再輔以人工確定和修訂。無論是使用哪種方式，最后都需要人工介入。因為數據標注的正確性是非常重要的，大家應該都聽過一句話： 數據和特征決定了機器學習的上限，而模型和算法只是逼近這個上限而已。 如果給你的數據都是有問題的，那模型如何能學習到正確的能力呢。

在標注平臺中，往往都是人工+模型混合使用的，整體流程如下：

在標注平臺中，人工+模型混合使用

在最開始可能沒有模型來輔助進行標注(這里的預標注)，這個時候就需要人為手工介入，以此來訓練出一個模型

當我們根據標注出的數據(訓練數據集)訓練出不錯的模型之后，就可以使用此模型來對新輸入的數據做一個預標注的工作，然后再輔以人工確認和修訂

如此反復迭代，隨著輸入數據的增多，當我們訓練出的模型準確率達到一個很高的水準之后，需要人工操作的數據就會越來越少。以此減少人工成本費

標注平臺中需要考量的問題有幾點：

一般來說，需要標注的數據量都是非常巨大的。不存在說兩三個人隨便標幾下就完事。所以更為通用的做法是做一個眾包平臺，外包給其他公司或者自由職業者(標注員)來做。參考AWS的Amazon Mechanical Turk。這就涉及到了權限控制、角色控制。

標注數據的準確性問題。不能避免有些標注員劃水摸魚，隨意標注。此時是需要己方人員去做一個審計工作的，這里就是一個工作流，和上圖所示差不多。是一個相對來說較為規范的流程，可以隨著業務來增加額外的流程。

標注工具的開發。如果有合適開源工具，可以集成開源工具，如VGG-VIA/Vatic， poplar。開源工具一般不會滿足所有的需求，在開源上做二次開發往往成本更高。這里更傾向于自己開發，這樣更能滿足需要，自定義程度高，靈活性強

標注數據的存儲。最好是一個相對通用的格式，以便于往各種其他格式做一個轉換。在使用時做一個數據格式轉換。這里更偏好Json格式類似的存儲，可讀性和代碼可操作性都非常高

技術上的考量，這里并不是太多。唯一需要注意的可能是數據的處理，如圖片、視頻標注，資源的拆剪、縮放，各種標注數據的保存，坐標計算等。相對而言，后端主要是工作流處理，前端的各種標注工具是技術核心點。

特征處理

在正式開始模型構建與訓練之前，對數據做特征處理基本上是必不可少的環節。特征處理的輸入是之前創建的數據集、或者是標注完成后產生的數據集。它的輸出是經過一系列數據操作后、可以直接輸入到模型中的數據，這里稱它為訓練數據。

這里又可以分為兩類，一類是不需要太多操作的特征處理，常見于非結構化數據，如圖片、視屏。另一類是針對結構化/半結構化數據的特征處理流程，這類數據往往不是拿來即可用的，需要一定的特征處理。

首先來看第一類，第一類的典型應用場景就是CNN圖像領域。對于輸入的圖片，一般不需要太多的操作。此類數據源往往也是存儲在NFS/OSS上的。對于此類數據的處理，一般也不會使用到大數據框架，一般都是自己手擼Python(C++)來處理；或者是放在模型訓練一起處理，不單獨拎開。Spark2.3開始是支持圖片格式的，不過目前沒有看到太多的使用案例。整體流程如下：

CNN圖像領域

本質上是一個批處理過程，Kubernetes的Job天然適用于此類問題。當然其他調度框架來做這個任務調度也是可以的。

然后是第二類，這種基本上就是傳統的特征工程了，以Hive/HDFS輸入為經典例子。由于對數據的操作是非常多樣的，所以一般傾向于構建一個數據處理的流水線，也就是Pipeline：

傳統的特征工程

把對數據的操作拆分成一個一個的操作運算(也就是一個Pipeline Node節點)，可以把它叫做算子,然后利用Pipeline把操作進行自由組合，從而達到對數據進行各種變換處理的過程。使用過Sklearn pipeline或者Spark MLlib pipeline的小伙伴應該對此并不陌生，事實上，這就是基于此的可視化建模。使得用戶可以在界面上進行拖拉拽，選擇和輸入一些參數來完成對于數據的操作，提供更靈活的功能。

那么這條Pipeline里面都有哪些操作呢，整個算子大致可以分為這幾類別：

特征處理

技術上，使用Spark MLlib是個不錯的選擇，可以適應不同數據量的規模。且天然支持這種Pipeline的形式，只需要對此做一定的封裝。同時，考慮到業務功能，還需要手動定制、修改一些算子；對于擴展這點，它的支持也是非常不錯的，自定義算子、算法都比較簡單。當然也可以基于其他框架(如Azkaban)或者自己造輪子。需要注意的是，在大數據場景下，Spark MLlib里面部分自帶的算子會有性能問題(有些直接OOM)，需要分析源碼定位然后修復。包括我們自己實現的算子，也都要考量大數據場景下這個問題，這對于測試而言是個Case。

整個Pipeline的核心是構造一個DAG，解析后，提交給對應的框架來做處理。拋開技術來說，功能上來說，易用性和快速反饋是Pipeline需要注意的。比如：

所有的算子都應該能自動獲取到可用的輸入、對應類型，自動生成輸出

支持參數校驗，Pipeline完整性校驗

支持調試/快速模式，利用部分Sample data快速驗證效果，相當于一個試驗功能

日志查看，每個算子狀態查看，以及操作完成后的Sample data查看

支持一些變量、SQL書寫，以擴展更靈活的功能，比如參數動態化

支持定時調度，任務狀態郵件、短袖及時告警、同步等

05.模型訓練

到了模型訓練這塊。從功能上來看需要的不是很多，更多是體驗上的設計。比如參數在界面上的展示和使用，日志、訓練出的Metrics的可視化、交互方式，模型的一些可視化等。核心功能包含這幾塊兒：

1.預置算法/模型

這里考量的點是：

支持界面手動調參

訓練中日志、Metrics的可視化。支持同時使用不同的參數多次訓練，直觀對比結果方便調參

需要支持常用的框架，如Spark MLlib/Tensorflow/Pytorch，或者一些特定的框架(業務方需要的)

預置算法/模型很簡單，在不同的框架上封裝一層并且暴露對應的參數給到用戶即可。有些算法可能框架不支持，這種根據情況決定如何解決(自己實現或者其他解決方案)。有一點就是，框架不宜太多，否則在后續模型發布的Serving上，也需要多套解決方案。對于訓練本身來說，分為兩種：單體/單機訓練和分布式訓練，分布式訓練是訓練這塊的大頭(也是技術難點所在)。

對于單體/單機訓練的解決方案，和上訴特征處理中的解決方案一致。優先使用Kubernetes的Job，或者使用Spark，控制下Executor即可。

對于分布式訓練，目前接觸到的，基本上都是數據并行：

分布式機器學習

以Spark為基礎的基本都使用的是PS模式。PS模式一般使用的都是異步更新參數，每個Worker只需要和PS通信，所以容錯管理上會更加簡單。AllReduce模式則是同步的參數模式，而且每個Worker都需要上下游通信，相對而言，容錯處理會更苛刻一些。

Spark系的分布式訓練，經典的算法可以由Spark MLlib提供。但是其對于DNN的支持并不好，而且Spark的訓練是一個同步的過程，如果數據傾斜的話，整個訓練的速度取決于最慢的RDD。如果要在Spark上跑深度學習的模型，一般會選用其他框架或者基于Spark的框架，如騰訊的Angel、 Intel的BigDL。兩者的思想都是一致的，同屬于PS模式下的分布式訓練，整個流程可以概括為這幾步：

利用Spark來作為任務調度、資源分配、數據讀取和容錯處理的容器

從PS拉取參數，然后將數據和參數通過JNI喂到底層的框架代碼中去(如Pytorch C++ Frontend)完成訓練，返回梯度

使用優化算法和梯度，更新參數，再將新的參數更新到PS。如此反復

借用一張Angel的圖：

Angel的圖

順著這個思路，可以以Spark為基礎，兼容任何深度學習框架。只要底層框架：

支持模型/代碼序列化，以支持分發模型到所有Worker中進行本地訓練

通過JNI能調用模型提供的接口，如Forward/Backward

這要比自己造輪子更加便利和友好，畢竟Spark已經是一個成熟的分布式計算框架了。

如果使用的是Python系的深度學習框架有兩點需要注意：

如何讀取分布式存儲上的數據以支持數據并行。也就是Spark里面Partition的概念。當然最簡單的方法，就是將數據拆分成塊，不同的節點讀取不同的數據來訓練。

另外一點在于容錯性，基于Spark的分布式訓練的優勢就在于數據的分配、容錯處理。現在就得自己去保障這兩點了。

訓練部署上面。Spark系的，使用Spark支持的即可(Yarn/Kubernetes/Standalone)。Python系的更傾向于云原生、或者基于Kubernetes的解決方案(自定義Operator是個比較好的選擇)，這里有個為云原生和容器化而生的框架：Polyaxon，值得一試。

2. 自定義算法

關于自定義算法，個人更傾向于將這個功能放在Notebook中而不是界面化的操作上，因為這個功能的自由度很高，允許用戶自己寫代碼。平臺其實只需要提供：

數據讀取能力，這里包括源數據、平臺內生成的數據

NFS/OSS使用Mount形式或者API提供(如Databricks 的DBFS)

HDFS系列的API提供支持(如提供pyspark)

調度能力，能根據需求調度起任務。

以上兩者功能，都或多或少依賴于SDK/API/CLI。可以參考大廠的實現Amazon SageMaker、Databricks Notebooks。

另外一點是GPU的支持，這點，如果是選擇Kubernetes作為基礎設施，是有基本的功能支持的，利用Extended Resource(ER)配合 Device plugin體系：

Extended Resource(ER)配合 Device plugin體系

對于Hadoop體系的話，3.1.X之后也是支持的。

這兩者對于GPU的支持都非常有限，都是處于一個能用，但是不好用的狀態。使用的時候，淌坑可能在所難免。

3. AutoML

關于AutoML這塊。目前還沒有太多的接觸。從我看來，做個簡單的隨機搜索還是問題不大的，集成算法來自動調參、自動構建模型也是不難的。就跟上訴集成算法進來是一樣的。唯一考量的是，集成那些算法進來以及計算資源的考量，尤其是深度學習大行其道的今天，類似于隨機搜索這樣耗費的資源是巨大的。如何設計這個功能，以及具體實現還是需要非常專業的領域知識。

總的來說，模型訓練這塊。是一個很偏技術的功能。完成一個Demo的端到端，實現基本的功能很簡單。但是要做到好用、穩定性這兩點就并不那么容易。尤其是分布式機器學習這一塊兒，還是需要不斷淌坑的。

06.模型發布

終于來到最后一步，是整個平臺產生價值的最后一環。模型發布，通常包含兩種發布：

發布成API(RESTful/gRPC)，以供業務側實時調用。這類服務通常對于性能要求苛刻

發布成批處理形式，用于批處理數據，上述標注平臺中的預標注屬于此類任務

對于批處理形式的發布，較為簡單。一般框架本身都支持模型的序列化和加載做預測：

Spark系的就依舊走原始路線，提交Spark Job，做批處理預測

TensorFlow類似的，配合不同的鏡像環境，Mount模型，讀取數據，配合Kubernetes Job的方式來啟動批處理達到一個統一的處理流程

對于實時推理服務，于平臺而言，能使用通用的框架/技術來做那當然是極好的。然鵝，現實很殘酷。通用的解決方案，要么性能不夠(如MLeap)，要么支持的算子/操作/輸入有限(如ONNX。想要在真正的業務場景下發揮價值都是需要淌坑的。用的更多的，往往都是性能領域強悍的C/C++/RUST來實現，比如自研、或者框架本身自帶的(如TensorFlow的Serving)，會更能滿足性能需求。平臺選用的框架最好是不要太多，這樣做Serving會比較麻煩，不同的框架都要去找解決方案實現一遍。

雖然做不到通用的模型Serving方案，但是通用的模型發布、提供服務的平臺卻是可以做到的。這是這部分的重點，即如何設計一個通用的推理平臺。一個推理平臺需要考量的點如下所示：

支持各種框架，多語言、多環境

模型版本管理

API安全性

可用性、可擴展性，服務狀態監控、動態擴容

監控、告警，日志可視化

灰度上線/AB Testing

把Serving看做是普通的Web服務。對于上訴的點，Kubernetes體系是絕佳的選擇：

鏡像，配合NFS的模型，啟動時Mount再復制到容器內部。可以支持多語言、多環境

版本管理，每個版本在NFS上創建新的版本目錄，比如0.0.1，放入對應的模型和啟動腳本配合一個Service。這樣就允許不同版本的Service同時在線，或者部分在線

API安全性，與Kubernetes本身無關。簡單的做法是為每個API生成對應的調用Token來做鑒權，或者使用API網關來做

可用性、可擴展性。利用Kubernetes原生的Liveness/Readness probe，可以檢測單個Pod中服務的狀態。使用Kubernetes的HPA、或者自己實現監控再配合Autoscale可以滿足需求，而且這些都可以成為一些配置暴露給用戶

監控、告警。可以Prometheus+Grafana+Alertmanager三件套，或者配合企業內部的運維體系

交給Istio即可。灰度發布肯定妥妥的，利用一些Cookie/Header來做分流到不同版本的服務也可以做到部分AB Testing的事情

由于Serving服務與服務之間是沒有關系的，是一個無狀態的單體服務。對于單體服務的各種處理就會比較簡單。比如不使用Kubernetes，使用AWS云的EC2來部署，配合Auto Scaling、CloudWatch等也是非常簡單的。

07. Addons

除開上訴的核心功能。一般來說，機器學習平臺還有一些擴展。最經典的當屬CLI和SDK了。

CLI就不用多說了，主要提供快捷入口。可以參考AWS的CLI。需要包含的點主要是：

提供基本的操作功能，滿足用戶的使用

以及導入導出功能。方便用戶共享配置、快速創建和使用平臺的功能

支持多環境、認證

完善的操作使用文檔、幫助命令、模板文件等

對于SDK這塊，需要和平臺本身的功能做深度集成；同時，還需要一定的靈活性。比如上訴的自定義算法，用戶可以在Notebook里面讀取平臺生成的數據集，寫完代碼后，還得支持提交分布式訓練。既要集成平臺功能，又得支持一定程度的自定義，如何設計會是一個難點。

08.探索實驗(Notebook)

Notebook本身功能并不復雜。實質上就是對Jupyter Notebook/JupyterLab等的包裝。通常的做法是使用Kubernetes的Service，啟動一個Notebook。以下幾點是需要考量的：

存儲要能持久化，需要引入類似于NFS這樣的持久目錄以供用戶使用

內置Demo，如讀取平臺數據、訪問資源、提交任務

預置不同的鏡像，支持不同的框架，以及CPU/GPU訴求用于啟動不同的Notebook

安全問題，一個是Notebook本身的安全。另一個是容器本身的安全

有可用的安全源，以供用戶安裝和下載一些包和數據

能夠訪問到基礎設施里面的數據，Mount/API

最好能有Checkpoint機制，不用的時候回收資源。需要的時候再啟動，但環境不變

大致的解決思路如下：

持久化需要Mount存儲。Storage class可以幫助

Notebook自身的安全，可以在里面增加Handler或者外面配置一層Proxy來鑒權。容器的安全大概有這幾點需要考量(要做到更嚴格還有很多可以深挖)：

限制容器內部用戶的權限

開啟SELinux

Docker的—cap-add/—cap-drop

heckpoint機制的實現，數據已經持久化在外部存儲了。只需要Save新的鏡像，作為下次啟動的鏡像即可，可使用Daemonset+Docker in dokcer的形式做一個微服務來提交鏡像。

09. 平臺的基石

這一節主要討論的是做平臺一定繞不開的問題。首先逃脫不了的是多租戶問題：

可能要和已有的系統進行集成。而不是新開發

租戶間權限、數據隔離

租戶資源配額、任務優先級劃分

技術上來說，系統自身的租戶功能難度不高。主要是數據、資源隔離這塊。要看對應的基礎設施：

Hadoop可以使用Keberos

Kubernetes可以使用Namespace

再配合不同的調度隊列。即可完成需求。

另外一點是偏技術層面的調度功能。這可以算是整個平臺運行的基礎，無論是數據處理還是模型訓練、模型部署都依賴于此， 調度系統分為兩塊：

調度本身，即如何調度不同的任務到不同的基礎設施上

狀態管理，有些任務可能存在依賴關系，會觸發不同的Action。這也是一個狀態機的問題

狀態管理這塊，業務場景不復雜的情況下自己實現即可。一般平臺上也沒有太復雜的依賴關系，經典的模型訓練也不過單向鏈路而已。如果過于復雜，可以考慮其他開源任務編排工具：

狀態管理

調度本身是一個任務隊列+任務調度組合而成。隊列用啥都可以，數據庫也可以。只要能保證多個Consumer的數據一致性即可。任務調度，如果不考慮用戶的感受，可以直接丟給對應的基礎設施，如Yarn/Kubernetes都可以。由這些基礎設施來負責調度和管理，這樣最簡單。

如果想做的盡善盡美，那還是需要維護一個資源池。同步基礎設施的使用情況，然后根據剩余資源和任務優先級來做調度。

狀態更新方面。對于Yarn體系，只能通過API去輪詢狀態、獲取日志。

對于Kubernetes體系，推薦一個Informer機制，通過List&Watch機制可以方便、快速獲取整個集群的情況：

Custom Controller

關于如何提交任務到基礎設施：

Spark/Yarn - 直接API、包裝下命令行者Livy都可

Kubernetes - SDK

10.最終Boss

做平臺，最怕的是什么？當然不是某某技術太過于復雜，攻克不下。而是沒有用戶使用平臺，或者不能通過平臺產生真實業務價值，這才是最重要的。有某一業務場景在平臺實現端到端產生價值，才能證明這個平臺的價值，才能吸引其他用戶來使用。

對于用戶來說，一般都已經有自己成熟的技術線。想要他們往平臺上遷移，實屬不易，除非已有系統滿足不了他們的需求、或者已有系統不好用。畢竟，自己用的好好的系統，遷移是需要耗時耗力的，用別人的東西也沒有自己做來的靈活；學習一個新的系統使用也是如此，有可能一開始用著并不習慣。此外，新的系統，沒有人期望第一個來當小白鼠的。有這么多缺點，當然平臺本身也有其優點。比如將基礎設施這塊甩給了第三方，不用去關注底層的東西，只要關注自己的業務了。

事實上的流程往往都是，隨著平臺MVP的發布。部分用戶開始上來試用，然后提各種想法和需求；緊接著，會逐漸遷移部分功能上來試用，比如搞些數據上來跑跑Demo，看看訓練的情況等。同時，在這個階段，就會需要各種適配用戶原始的系統了，比如原始數據導入與現有系統不兼容，需要格式的轉換；再比如只想用平臺的部分功能，想集成到自己現有的系統中等。最后才是，真正的在平臺上使用。想要用戶能端到端的使用平臺，來完成他們的業務需求，還是需要漫長的過程的。

相對而言，至上而下的推動往往更為有效。總有一批人要先來體驗、先來淌坑，給出建議和反饋。這樣這個平臺才會越來越好，朝好的地方發展。而不是一開始上來就堆功能，什么炫酷搞什么、大而全。但是在用戶使用上，易用性和穩定性并不好，或者是并不能解決用戶的需求和難點。那這種平臺是活不下去的。
fqj