Kyuubi 與 Spark Thrift Server 的全面對(duì)比分析
Spark Thrift Server 是Apache Spark社區(qū)基于HiveServer2實(shí)現(xiàn)的一個(gè)Thrift服務(wù)，旨在無縫兼容HiveServer2。它通過JDBC接口將Spark SQL的能力以純SQL的方式提供給終端用戶。這種“開箱即用”的模式可以最大化地降低用戶使用Spark的障礙和成本。我們先從傳統(tǒng)的 Spark 作業(yè)提交方式入手，談?wù)?Spark Thrift Server 具備的優(yōu)勢(shì)。
1.1 傳統(tǒng)作業(yè)方式
在沒有 Spark Thrift Server 的情況下，Spark 作為大數(shù)據(jù)處理工具，可能并不是對(duì)所有人都那么“友好”。
（1）門檻高
用戶通過Spark提供的 Scala/Java/Python 等接口使用 Spark時(shí)都需要一定的編程基礎(chǔ)。同時(shí)，用戶需要具備良好的大數(shù)據(jù)背景。舉例來說，用戶需要知道他們的程序最終提交哪個(gè)平臺(tái)上，YARN、Kubernetes或者是別的平臺(tái)？用戶也需要知道如何去配置他們所提交作業(yè)的資源使用，需要多少的 Executor 數(shù)，每個(gè) Executor 該配置多少的內(nèi)存和CPU？他們自己又該知道怎么去合理的使用集群上的資源呢？用多了，會(huì)不會(huì)對(duì)其他關(guān)鍵任務(wù)造成影響？用少了，集群的資源是不是閑置浪費(fèi)？成千上百的配置如何去設(shè)置？動(dòng)態(tài)資源調(diào)度，自適應(yīng)查詢，推測(cè)執(zhí)行，這些關(guān)鍵特性該如何無成本的應(yīng)用到各個(gè)任務(wù)中去？
（2）不安全
用戶通過代碼的方式訪問元數(shù)據(jù)和數(shù)據(jù)，數(shù)據(jù)安全性無法保證，“刪庫跑路”輕而易舉。所有的客戶端配置需要直接或者間接的交到用戶手中。一方面，這些配置本身就可能包含一些敏感信息；另一方面，后臺(tái)的服務(wù)也基本上“裸露”在用戶的面前。很多企業(yè)使用 Spark 的時(shí)候都會(huì)魔改加入一些適配自己場(chǎng)景的特性。例如在數(shù)據(jù)安全方面，可能大家都用過或者參考過網(wǎng)易開源出來 spark-authorizer 插件通過 Apache Ranger 來實(shí)現(xiàn)細(xì)粒度的 SQL Standard Based Authorization。但這種安全特性，通過 Spark 代碼提交作業(yè)的方式，在會(huì)寫代碼的程序員面前，只是約束力不強(qiáng)的“君子協(xié)定”。
（3）兼容性
客戶端兼容性難以保證。一個(gè)用戶的 Spark 作業(yè)最終被調(diào)度到集群上運(yùn)行，面臨著客戶端環(huán)境和集群環(huán)境不一致，用戶作業(yè)依賴和 Spark 或 Hadoop 依賴沖突等問題。如果團(tuán)隊(duì)選擇維護(hù)一個(gè)內(nèi)部魔改的 Spark 或者 Hadoop 版本，在這些版本的開發(fā)過程中，需要時(shí)刻注意是否能保持用戶接口的兼容性。在各底層版本服務(wù)端的升級(jí)換代過程中，也需要盡可能的完成用戶客戶端的升級(jí)，這時(shí)候就可能引入許多不必要的兼容性測(cè)試工作，而且很容易出現(xiàn)測(cè)試覆蓋不全的問題。
（4）延時(shí)高
Spark Application的啟動(dòng)延時(shí)。按作業(yè)的生命周期維度分類，我們可以簡(jiǎn)單的將 Spark 任務(wù)簡(jiǎn)單的分為兩種，常駐類型和非常駐類型。常駐類型作業(yè)的特點(diǎn)就是 Application的啟動(dòng)時(shí)間相對(duì)于總?cè)蝿?wù)運(yùn)行時(shí)長(zhǎng)來講忽略不計(jì)或者和計(jì)算過程完全解綁，如 Spark Structed Streaming任務(wù)，計(jì)算過程只有 Task 線程級(jí)別的調(diào)度，低延時(shí)快響應(yīng)。而非常駐類型的作業(yè)，每次都需要啟動(dòng) Spark 程序。相對(duì)而言，這個(gè)過程是非常耗時(shí)的，特別對(duì)于一些秒級(jí)分鐘級(jí)的計(jì)算任務(wù)負(fù)擔(dān)較重。
1.2 Spark Thrift Server 方式
Spark Thrift Server本質(zhì)上就是一個(gè) Spark 應(yīng)用在多線程場(chǎng)景下的應(yīng)用。它在運(yùn)行時(shí)啟動(dòng)一個(gè)由 Driver 和 Executor 組成的分布式 SQL 引擎。在 SQL 解析層，該服務(wù)可充分利用 Spark SQL 優(yōu)化器的能力，在計(jì)算執(zhí)行層，由于 Spark ThriftServer 是常駐類型的應(yīng)用，沒有啟動(dòng)開銷，當(dāng)沒有開啟動(dòng)態(tài)分配的情況下，整個(gè) SQL 的計(jì)算過程為純的線程調(diào)度模式，性能極佳。
在這個(gè)架構(gòu)的基礎(chǔ)上，基于 HiveServer2 實(shí)現(xiàn)了 Session 相關(guān)操作，來響應(yīng)客戶端的連接和關(guān)閉請(qǐng)求，也實(shí)現(xiàn)了 Operation 相關(guān)操作，來響應(yīng)客戶端查詢請(qǐng)求等。這些請(qǐng)求都由Server前端實(shí)現(xiàn)的線程池模型來響應(yīng)。并調(diào)用Server后端的對(duì)應(yīng)方法與SparkSession相關(guān)接口的綁定。然后Server后端通過一個(gè)異步線程池，將這些 Operation 提交到分布式 SQL 引擎上真正執(zhí)行。
首先，在這種模式下用戶通過簡(jiǎn)單的 SQL 語言和 JDBC 接口完成和 Spark ThriftServer 的交互，實(shí)現(xiàn)自己的業(yè)務(wù)邏輯。不需要對(duì) Spark 本身有過多的技能基礎(chǔ)，或者對(duì) Spark 所運(yùn)行的平臺(tái)，或者底層數(shù)據(jù)的實(shí)現(xiàn)有過多的關(guān)注。Spark ThriftServer 基本的容量規(guī)劃、底層服務(wù)的打通、以及后續(xù)的優(yōu)化迭代都可以在服務(wù)端完成。當(dāng)然也有同學(xué)會(huì)認(rèn)為，SQL 的表達(dá)并不能滿足所有的業(yè)務(wù)，但本身這個(gè)服務(wù)就是對(duì)標(biāo) HiveServer2 來給這類用戶提供純 SQL能力的。一些復(fù)雜的邏輯也可以嘗試使用 UDF/UDAF 之類的進(jìn)一步支持，基本上大部分的大數(shù)據(jù)處理工作，Spark ThriftServer都是可以勝任的。
其次，后臺(tái)各類服務(wù)的打通都在 Spark ThriftServer 完成，不需要將其他服務(wù)的配置，如Hive Metastore Server, Hadoop 集群等的鏈接配置交到終端用戶手中。這一定程度上保證了數(shù)據(jù)安全。在這基礎(chǔ)上，服務(wù)端的開發(fā)和運(yùn)維一般有能力去做一些認(rèn)證鑒權(quán)之類的防護(hù)工作，保護(hù)數(shù)據(jù)安全。
最后，JDBC接口協(xié)議和C/S架構(gòu)下服務(wù)端向下兼容的約束基本上保證了不會(huì)出現(xiàn)客戶端兼容性的問題。用戶只需選擇合適版本的 JDBC 的驅(qū)動(dòng)即可，服務(wù)端的升級(jí)不會(huì)造成接口的不兼容。至于版本升級(jí)中潛在的 SQL 兼容性的問題，在不使用 Spark ThriftServer 時(shí)也同樣存在，且更難解決。而且在 Spark ThriftServer 模式下，服務(wù)端提前可以做全量的 SQL 采集工作，可以在升級(jí)前期就完成校驗(yàn)。
從上面 Spark Thrift Server的基本架構(gòu)圖我們也可以看出，其本質(zhì)上是一個(gè) Spark Application。用一個(gè) Spark Application 去響應(yīng)成千上萬的客戶端請(qǐng)求，一般會(huì)存在比較大的限制。
2.1 Driver 單點(diǎn)問題
對(duì)于單線程的 Spark 應(yīng)用來說，Driver 節(jié)點(diǎn)的單點(diǎn)效應(yīng)，制約著它能起多少Executor提高并發(fā)能力及把數(shù)據(jù)分成多少個(gè) Partition 來并行的處理。隨著Executor數(shù)量的上升，Driver 需要處理更多控制面的 RPC 消息，而隨著Partition的增加，Driver 也需要處理更多數(shù)據(jù)面的 RPC 消息。在 Spark ThriftServer 這個(gè)多線程模型下，它同時(shí)還要處理大量的客戶端請(qǐng)求，單點(diǎn)的效應(yīng)會(huì)更加的明顯。另外，所有執(zhí)行線程所依賴的Hive metastore client是一個(gè)，在訪問HMS的時(shí)候也會(huì)有較明顯的并發(fā)問題。
2.2 資源隔離問題
超大任務(wù)侵占過多或者所有 Spark Thrift Server 的計(jì)算資源，導(dǎo)致其他任務(wù)延時(shí)或者卡死。
?
如果使用Fair Scheduler Pools可以一定程度上解決計(jì)算側(cè)的資源分配問題。但是在 Driver 調(diào)度側(cè)，難以避免的還會(huì)遇到HMS，HDFS訪問單點(diǎn)的問題，特別是讀寫動(dòng)態(tài)分區(qū)表或者大量 Union 的場(chǎng)景。從本質(zhì)上將，CPU/內(nèi)存/IO等資源隔離就應(yīng)該是YARN、Kubernetes這類資源管理器該干的事情。計(jì)算層做邏輯上的資源隔離，效果不可能理想，比如，這個(gè)問題在 Apache Impala 項(xiàng)目里也同樣存在。
2.3 多租戶局限
Spark Thrift Server 本身應(yīng)該是一個(gè)支持多租戶的系統(tǒng)，即它可以接受不用用戶不同客戶端的請(qǐng)求并在服務(wù)端貢獻(xiàn)線程池中分配這些資源完成用戶的請(qǐng)求返回結(jié)果。但從 Spark 自身設(shè)計(jì)角度出發(fā)，單 Spark 應(yīng)用實(shí)現(xiàn)的 Spark Thrift Server 并不能完整支持多租戶，因?yàn)檎麄€(gè) Application 只有全局唯一的用戶名, 同時(shí)包括 Driver 端和 Executor 端。這個(gè)結(jié)合 HiveServer2 來講更方便理解，Server端運(yùn)行的時(shí)候一般使用的 Service Principal進(jìn)行啟動(dòng)，客戶端連接帶有完整的用戶信息，接受服務(wù)端認(rèn)證通過后會(huì)由服務(wù)端“偽裝執(zhí)行”，所以每次執(zhí)行任務(wù)的實(shí)際用戶為客戶端用戶，這里包括了申請(qǐng)資源運(yùn)行 MR 程序，訪問 HMS 和 HDFS 等服務(wù)。
回到 Spark Thrift Server 這邊，這些資源申請(qǐng)和服務(wù)的訪問都交給服務(wù)端用戶去做。因此該服務(wù)端用戶必然需要所有元數(shù)據(jù)和數(shù)據(jù)的超級(jí)權(quán)限。從數(shù)據(jù)安全的角度，這樣做一方面造成潛在的權(quán)限泄露問題，另一方面 HMS 和 HDFS 也很難去根據(jù)不同的用戶完成審計(jì)，因此線上出了問題一般很難追根溯源。從資源隔離和共享角度，Spark Thrift Server 占用的是單個(gè)資源隊(duì)列（YARN Queue / Kubernetes Namespace, 這也導(dǎo)致很難細(xì)粒度或者彈性地控制每個(gè)用戶可使用的資源池大小，如果有資源計(jì)費(fèi)等需求就很難滿足。
2.4 高可用局限
Spark Thrift Server 社區(qū)版本是不支持高可用（High Availability, HA）的。很難想象一個(gè)沒有高可用的服務(wù)端應(yīng)用能否支撐起 SLA 的目標(biāo)，相信運(yùn)維人員是肯定睡不安穩(wěn)了。當(dāng)然，要給 Spark Thrift Server 增加一個(gè) HA 并不難，例如社區(qū)老早就有人提出這個(gè)問題，并附上了PR，詳見SPARK-11100。對(duì)于 Spark Thrift Server 的 HA 實(shí)現(xiàn)，各個(gè)廠商魔改的方式大體上分兩種思路，即“主從切換”和“負(fù)載均衡”。主從切換由Active Spark Thrift Server 和若干 Standby Spark Thrift Server 構(gòu)成，當(dāng) Active Spark Thrift Server掛掉之后，Standby 節(jié)點(diǎn)觸發(fā)選主成為 Active 節(jié)點(diǎn)接替。
這里存在很多問題，第一，主從模式下只有一個(gè) Active 節(jié)點(diǎn)，也就面臨著嚴(yán)重的 Spark Driver 單點(diǎn)問題，并不能提供很高的并發(fā)能力；第二，因軟硬件故障，而發(fā)生主從切換時(shí)，意味著“全部”的當(dāng)前任務(wù)失敗，各個(gè) Spark 作業(yè)的Failover 并不輕量，這基本上已經(jīng)可定義為P0級(jí)別的“事故”，SLA 肯定是要受到影響了；第三，Standby 節(jié)點(diǎn)造成嚴(yán)重的集群資源浪費(fèi)，無論是是否開啟 Spark 動(dòng)態(tài)資源分配的特性，從主從切換的更加順滑的目的出發(fā)，都要為Standby節(jié)點(diǎn)“搶占”一定的資源；第四，一般而言，軟件故障的概率遠(yuǎn)遠(yuǎn)大于硬件故障，而 Spark ThriftServer 軟件故障一般是由于客戶端高并發(fā)請(qǐng)求或者查詢結(jié)果集過大導(dǎo)致的，這種模式下，一旦發(fā)生切換，客戶端重試機(jī)制同時(shí)觸發(fā)，新的 Standby 節(jié)點(diǎn)只會(huì)面對(duì)更大的宕機(jī)風(fēng)險(xiǎn)。
為了解決 Spark Thrift Server Driver 單點(diǎn)問題，更加合適的做法是負(fù)載均衡模式，這樣當(dāng)客戶端的請(qǐng)求量上來，我們只要水平的擴(kuò)充 Spark ThriftServer 即可。但這種模式也有一定的限制，每個(gè) Spark ThriftServer 都是有狀態(tài)的，兩個(gè)服務(wù)之間并不能共享，比如一些全局臨時(shí)視圖、UDF 等，這表示客戶端每次連接如果要復(fù)用都必須重新創(chuàng)建它們。
2.5 UDF 使用的問題
包括前面談到的 UDF 在高可用下的復(fù)用問題，對(duì)單個(gè) Spark ThriftServer 來說，還面臨這 Jar 包沖突及無法更新和刪除的問題。另外，由于 UDF 是直接加載到 Spark ThriftServer 服務(wù)端的，但 UDF 中包含一些無意或者惡意的邏輯，如直接調(diào)用 System.exit(-1), 或者類似 Kerberos 認(rèn)證等影響服務(wù)全局的一些操作，可能直接將服務(wù)殺掉。
這里我們主要對(duì)網(wǎng)易有數(shù)大數(shù)據(jù)團(tuán)隊(duì)開源的 Kyuubi 項(xiàng)目與 Spark Thrift Server進(jìn)行功能上的比較，對(duì) Kyuubi 實(shí)現(xiàn)架構(gòu)感興趣的可參考 - Kyuubi: 網(wǎng)易數(shù)帆開源的企業(yè)級(jí)數(shù)據(jù)湖探索平臺(tái)（架構(gòu)篇）。此外，這里也引入HiveServer2 進(jìn)行更加全面的分析。大致維度的對(duì)比，請(qǐng)見下表。
3.1 接口一致性
從接口和協(xié)議上來說，Kyuubi、Spark Thrift Server以及HiveServer2是完全一致的。因此，從用戶的角度來講，總體使用方式是不變的。與HiveServer2相比，前兩者帶給用戶最大的不同應(yīng)該就是性能上的飛躍。用戶可以選擇市面上既有的 BI 工具， 如網(wǎng)易易數(shù)、 DBeaver，及Hadoop生態(tài)圈的Hue / Hive Beeline 等工具完整適配三個(gè)不同的服務(wù)。
從 SQL 語法兼容的角度，Kyuubi 和 Spark Thrift Server 一樣完全委托 Spark SQL Catalyst 層完成，所以和 Spark SQL 全兼容。而 Spark SQL 也基本上完全支持 Hive QL集合，只有少量可枚舉的 SQL 行為及語法上的差異。
3.2 多租戶架構(gòu)
維基百科: 多租戶技術(shù)（multi-tenancy technology）或稱多重租賃技術(shù)，是一種軟件架構(gòu)技術(shù)，它是在探討與實(shí)現(xiàn)如何于多用戶的環(huán)境下共享相同的系統(tǒng)或程序組件，并且仍可確保各用戶間資料的隔離性。
Kyuubi、Spark ThriftServer 和 HiveServer2 的使用場(chǎng)景是一個(gè)典型的多租戶架構(gòu)。
在資源層面，我們要考慮的是在資源隔離的基礎(chǔ)上 1) 如何在邏輯上更加安全和高效的利用這些計(jì)算資源 2) 如何賦予用戶對(duì)屬于自己的資源“足夠”的控制能力。
HiveServer2 在這方面應(yīng)該是做的最暴力最靈活的一個(gè)，每條 SQL 都被編排成若干 Spark 獨(dú)立程序進(jìn)行執(zhí)行，在執(zhí)行前都可以設(shè)置隊(duì)列、內(nèi)存等參數(shù)。但這種做法一個(gè)方面是導(dǎo)致了極高 Spark 啟動(dòng)時(shí)延，另一個(gè)方面也無法高效地利用計(jì)算資源。
Spark ThriftServer 的方向則完全相反，因?yàn)?Spark 程序只有一個(gè)且已經(jīng)預(yù)啟動(dòng)，從用戶的接口這邊已無法進(jìn)行隊(duì)列信息、內(nèi)存參數(shù)等資源調(diào)整。內(nèi)部可以通過Fair Scheduler Pools進(jìn)行“隔離”和“共享”，只能對(duì)不同的 Pool 設(shè)置權(quán)重，然后將 SQL 任務(wù)拋進(jìn)不同的 Pool 而得到公平調(diào)度的能力，離真正的意義上的資源隔離還差的很遠(yuǎn)。
Kyuubi 在這個(gè)方面在其他兩個(gè)系統(tǒng)的實(shí)現(xiàn)上，做了“中和”。圍繞 Kyuubi Engine 這個(gè)概念實(shí)現(xiàn)多租戶特性，一個(gè) Engine 即為一個(gè) Spark 程序。
從資源隔離的角度，不同租戶的 Engine 是隔離的，一名用戶只能創(chuàng)建和使用他自己的一個(gè)或者多個(gè) Engine 實(shí)例，資源也只能來自有權(quán)限的隊(duì)列或者Namespace。
從用戶對(duì)資源的控制能力上來講，用戶可以在創(chuàng)建 Engine 實(shí)例的時(shí)候?qū)ζ滟Y源進(jìn)行初始化配置，這種做法雖然沒有 HiveServer2 那樣靈活，但可以免去大量的 Spark 程序啟動(dòng)開銷。
從資源共享的角度，Engine 支持用戶端配置不同的共享級(jí)別，如果設(shè)置為 CONNECTION 級(jí)別共享，用戶的一次 JDBC 連接就會(huì)初始化一個(gè) Engine，在這個(gè)連接內(nèi)，用戶可以執(zhí)行多個(gè) Statement 直至連接關(guān)閉。如果設(shè)置為 USER 級(jí)別共享，用戶的多次 JDBC 都會(huì)復(fù)用這個(gè) Engine，在高可用模式中，無論用戶的連接打到哪個(gè) Kyuubi Server 實(shí)例上，這個(gè) Engine 都能實(shí)現(xiàn)共享。同一個(gè)用戶可以為自己的每個(gè)連接設(shè)置不同的隔離級(jí)別。比如一些 ETL 流水作業(yè)或者定時(shí)報(bào)表任務(wù)，可以選擇 CONNECTION 級(jí)別共享級(jí)別已獲得任務(wù)粒度的精細(xì)資源控制。而在一些交互式分析的場(chǎng)景中，則可以選擇 USER 級(jí)別共享并設(shè)置合適的緩存時(shí)間以獲得出色的交互響應(yīng)能力。
在數(shù)據(jù)層面，我們需要考慮就是元數(shù)據(jù)和數(shù)據(jù)訪問的安全性，不同的用戶只能訪問其有權(quán)限訪問的數(shù)據(jù)。如文件級(jí)別的ACL權(quán)限或者是元數(shù)據(jù)層面的基于 SQL 標(biāo)準(zhǔn)實(shí)現(xiàn)的諸如 SELECT/CREATE/ATTER/UPDATE/DROP 等類型和 DATABASE/TABLE/COLUMN 等級(jí)別的細(xì)粒度權(quán)限控制。這一切的實(shí)現(xiàn)都依賴一個(gè)基本的概念多租戶，Spark ThriftServer 單用戶顯然是不可能適配這套模型的，而 Kyuubi 由于實(shí)現(xiàn)了多租戶，天然就支持了文件級(jí)別的 ACL 權(quán)限控制，另外 通過適配 spark-authorizer 插件，也有能力實(shí)現(xiàn) SQL 標(biāo)準(zhǔn)的權(quán)限控制。
3.3 高可用能力
Spark ThriftServer 的高可用問題前文已經(jīng)涉及，這里不再贅述。在 Kyuubi 中，我們以負(fù)載均衡模式提供高可用， Kyuubi 服務(wù)本身不是集群資源的消耗大戶，水平擴(kuò)展不會(huì)有過多的負(fù)擔(dān)。
3.4 客戶端并發(fā)
無論是 HiveServer2 還是 Spark ThriftServer 的 SQL 的編譯優(yōu)化都在 Server端完成，這個(gè)階段需要單點(diǎn)地完成元數(shù)據(jù)的獲取，對(duì)于大型分區(qū)表掃描存在一定的瓶頸。另外 Spark ThriftServer 同時(shí)兼具著 Spark 計(jì)算側(cè)的 Driver 角色，負(fù)責(zé)調(diào)度服務(wù)，原則上 Executor 數(shù)量越多，處理的數(shù)據(jù)量越大，Server 端的壓力也就越大。在 Kyuubi 中，用戶提交的 SQL 編譯優(yōu)化都在 Engine 端完成，SQL Analyzer 階段對(duì)于元數(shù)據(jù)的訪問獲取可以從 Server 端釋放出來，同時(shí)所有的計(jì)算過程也都在 Engine 端完成，極大降低了 Kyuubi Server 端的工作負(fù)載。
3.5 服務(wù)穩(wěn)定性
撇開高可用功能不講，單個(gè) Spark ThriftServer 由于客戶端響應(yīng)邏輯和 Spark 計(jì)算強(qiáng)耦合，一方面提高客戶端并發(fā)能力則會(huì)分走大量的 Driver 端線程資源，另一方面 Driver 端在高計(jì)算負(fù)載下面臨繁重的 GC 問題，喪失一定的客戶端響應(yīng)能力。當(dāng)部分查詢返回較大的結(jié)果集時(shí)，也很容易造成 OOM 的風(fēng)險(xiǎn)。Kyuubi 由于 Server 和 Engine 分離的設(shè)計(jì)，在這方面完全不存在問題。對(duì)于 UDF 使用的問題，因?yàn)槭窃?Engine 內(nèi)部進(jìn)行加載和使用的，如果用戶“行車不規(guī)范”，最多也就“自己兩行淚”，不會(huì)對(duì)服務(wù)的穩(wěn)定性造成任何影響。
Kyuubi 在統(tǒng)一接口基礎(chǔ)上，拓展了 Spark ThriftServer 在多租戶模式下的使用場(chǎng)景，并依托多租戶概念獲得了完善的資源隔離共享能力和數(shù)據(jù)安全隔離的能力。而得益于 Kyuubi Server 和 Engine 松耦合的架構(gòu)極大提升了服務(wù)自身的并發(fā)能力和服務(wù)穩(wěn)定性。由于篇幅有限，Kyuubi 對(duì)數(shù)據(jù)湖的友好支持將在以后的分享中進(jìn)行介紹。點(diǎn)擊閱讀原文可查看本篇英文版。