我們要接觸的性能測試跟互聯(lián)網(wǎng)的不太一樣。我們知道預(yù)測服務(wù)仍然還是訪問密集型業(yè)務(wù)。但是模型調(diào)研的過程是屬于計算密集型業(yè)務(wù)。我們要模擬的情況不再是高并發(fā)。而是不同的數(shù)據(jù)規(guī)模，數(shù)據(jù)分布和數(shù)據(jù)類型。我們?nèi)粘５男阅軠y試都是需要在各種不同的數(shù)據(jù)下跑各種不同的算子和參數(shù)。所以我們首先需要一種造數(shù)機制，能幫助我們按需求生成大規(guī)模的數(shù)據(jù)。我們選擇的是spark，利用分布式計算在hadoop集群上生成大量的數(shù)據(jù)。

原理也很簡單，接觸過spark的同學(xué)肯定都知道在spark中生成一個RDD有兩種方式， 一種是從文件中讀取，另一種是從內(nèi)存中的一個list種解析。第一種方式肯定不是我們想要的， 所以從內(nèi)存中的list解析就是我們選擇的方式。假如我們想生成一個10億行的數(shù)據(jù)。就可以先使用python 的xrange造一個生成器以防止內(nèi)存被撐爆。然后用這個生成器初始化一個有著10億行的空的RDD，定義并操作RDD的每一行去生成我們想要的數(shù)據(jù)，然后設(shè)置RDD的分片以及消耗的container，內(nèi)存，cpu等參數(shù)。提交到集群上利用集群龐大的計算資源幫助我們在段時間內(nèi)生成我們需要的數(shù)據(jù)。 前兩天我再一個3個節(jié)點的集群上造過一個1.5T的數(shù)據(jù)，大概用了5個小時。這樣一開始的時候我們是寫spark腳本來完成這些事。后來需求越來越多，我們發(fā)現(xiàn)可以造數(shù)做成一個工具。把表和字段都提取到配置文件中進行定義。就這樣我們成立了shannon這個項目。慢慢的從造數(shù)腳本到造數(shù)工具再到造數(shù)平臺。

它的架構(gòu)特別簡單，就是對原生spark的應(yīng)用，這里我就不展示spark的架構(gòu)是什么樣了。就貼一下造數(shù)工具的設(shè)計圖吧。

簡單來說shannon分了3層。最底層是基本數(shù)據(jù)類型層。負責(zé)字段實例化，定義并實現(xiàn)了shannon支持的所有數(shù)據(jù)類型。例如，隨機，枚舉，主鍵，unique key，控制分布，大小，范圍等等。

測試環(huán)境管理

常見的測試場景我們基本上都說完了。 我們再說一說測試環(huán)境管理的問題。 為了能夠保證研發(fā)和測試效率，一個能夠支撐大規(guī)模測試環(huán)境的基礎(chǔ)設(shè)施是十分必要的。為什么這么說呢？

首先但凡是涉及到機器學(xué)習(xí)的業(yè)務(wù)，運行時間都非常慢。 有時候做測試的時候跑一個模型要幾個小時甚至一天都是有的。也就是說，我們運行測試的成本比較高。如果在運行測試的途中環(huán)境出了什么問題那么損失還是很大的。多人共用一套環(huán)境難免會有互相踩踏的情況，例如一個RD在測試自己的模塊，另一個人上來把服務(wù)重啟了。這時候我們心里一般就是一萬頭某種動物飄過。所以我們一般希望每個人都能擁有一套獨立的環(huán)境甚至一個人多套環(huán)境。這就增加了測試環(huán)境的數(shù)量。尤其是團隊越來越大的時候，測試環(huán)境的數(shù)量已經(jīng)到達了一個恐怖的量級。

其次如果各位所在的公司也像我們一樣做TO B的業(yè)務(wù)，那么我們的測試環(huán)境就需要多版本管理，要有能力隨時快速的搭建起特定版本的產(chǎn)品環(huán)境供開發(fā)，產(chǎn)品，測試，以及技術(shù)支持人員使用。所以這無疑又增加了環(huán)境管理設(shè)置的復(fù)雜度。

再有就是隨著環(huán)境數(shù)量的擴張，我們的環(huán)境從單節(jié)點走向集群，這時候我們對環(huán)境調(diào)度能力的要求會比較高，例如我們要對環(huán)境的資源進行計算和限制，保證最大化利用資源的同時不會撐爆系統(tǒng)。例如我們要保證系統(tǒng)有足夠的冗余，在某些環(huán)境出現(xiàn)故障的時候能夠自動檢測出來并在冗余節(jié)點進行恢復(fù)。例如我們需要能夠?qū)崿F(xiàn)多租戶管理，執(zhí)行資源管控，限制超售行為. 例如我們希望系統(tǒng)有一定能力的無人值守運維能力等等。

所以我們經(jīng)過一段時間的討論和實驗，引入了k8s+docker來完成這個目標(biāo)。docker的優(yōu)勢大家應(yīng)該都知道，快速，標(biāo)準(zhǔn)化，隔離性，可遷移性都不錯。 通過鏡像我們可以迅速的將測試環(huán)境的數(shù)量提升一個量級，鏡像的版本管理正適合TO B業(yè)務(wù)的多版本管理。 之所以選擇k8s，是因為k8s相較于swarm和mesos 都擁有著更強大的功能和更簡單的部署方式。剛才說的預(yù)測服務(wù)需要部署很多個agent，使用k8s的話只需要設(shè)置一下replica set的數(shù)量，k8s就會自動幫我們維護好這個數(shù)量的實例了，很方便 。k8s的調(diào)度機制能很輕松的滿足我們剛才說的對于災(zāi)難恢復(fù)，冗余，多租戶，高可用，負載均衡，資源管理等要求。所以我們當(dāng)初懷揣著對google莫名的憧憬走上了k8s的踩坑之旅。