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

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

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

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

測(cè)試環(huán)境管理

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

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

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

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

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