在神策 2021 數據驅動大會北京場技術論壇上，神策數據首席架構師張鐸發表了主題爲《神策私有化部署的架構演進》的演講，本文爲精選內容。主要包括：
-
私有化部署的意義
-
神策私有化部署的演進及技術挑戰
-
SaaS 化部署的意義及技術挑戰
-
SaaS 化的分析雲
-
神策部署模式的未來
在開始演講前先問大家一個問題，作爲技術人員，你願意選擇幾個大的 SaaS 集羣還是選擇上千個私有化部署的小集羣來實現技術指標？
如果是我的話，我會願意選大集羣，因爲挑戰高併發、巨大數據量會更有成就感；如果選小集羣的話，可能會遇到很多比大集羣更麻煩、更意想不到的問題。神策數據選擇的就是充滿挑戰的私有化部署。截止目前，神策數據每天幫助客戶處理超過 2500 億行數據的導入，數百萬次 SQL 的查詢。
一、私有化部署的意義
爲什麼選擇私有化部署？其實這不是一個技術決策，而是業務決策。
首先，在神策數據創業初期，因企業知名度及客戶忠誠度有待提升，部分客戶對神策數據的 SaaS 模式慎之又慎。因此，私有化部署成爲神策數據業務拓展的必然選擇。
其次，私有化部署是符合中國國情的選擇。在國內市場，部分行業管制嚴格，比如以證券、保險、銀行爲代表的金融業，他們的業務數據幾乎不會上雲。
基於以上兩點考量，神策數據選擇了私有化部署。
二、神策私有化部署的演進及技術挑戰
神策私有化部署的演進，總共分爲三個階段。
第一階段：2015-2018 年，單一產品線時代
這個階段神策數據會通過私有化部署來爭取更多客戶，具體表現爲：根據客戶的現有資源和業務需求，針對性提供產品與服務支持，對於一些特定場景的訴求會盡力去滿足。
總結起來，這個階段雖然我們在業務上很成功，但在技術上並非無可挑剔。
第二階段：2018-2019 年，產品矩陣時代
隨着業務的逐步發展，神策數據的客戶越來越多，客戶需求也越來越複雜，單靠神策分析一個產品已經無法滿足客戶的所有需求，因此，我們開始打造神策產品矩陣。
在私有化部署這件事兒上，我們開始嘗試標準化，也就是將客戶環境標準化。但在實際落地時卻發現困難重重，客戶環境不是標準化也很難實現標準化。爲了能夠儘快推動交付不影響客戶的業務進度，我們會通過多方案針對性解決問題，但這不可避免地會增加交付和技術團隊的工作量。
第三階段：2020 年至今，雲操作系統時代
在吸取了之前的經驗教訓之後，我們總結，標準化是必須要做的，但不能只侷限於機器環境——在應用服務化方面，通過抽象的 API 接口，把服務之間相互依賴的部分標準化。
同時，神策數據秉承聲明式的設計理念，通過聲明式資源定義，將外部依賴的資源也進行標準化。作爲平臺提供方，神策數據讓業務線只需要關心或聲明想要達到的狀態，而不需要關心怎麼達到這個狀態。
此外，我們把有狀態服務和無狀態服務進行拆分，用不同的管理系統進行分別管理。針對無狀態服務，我們會進行容器化，或者用 K8s 進行管理。
這個階段我們需要做到全面標準化，但又要足夠靈活。最終達到的目的是絕大部分客戶的環境都成爲了“標準”環境。目前來看這一套標準化的方案進展正常，這爲我們後續服務更多客戶打下了堅實的基礎。
在以上三個階段的演進過程中，我們也面臨着如下挑戰：
挑戰一：支持各種模式的混合部署
針對客戶的版本、業務需求等提供個性化支持以及各種模式的混合部署。
挑戰二：歷史版本收斂
爲避免線上並行多個版本導致維護成本急劇增加，需要針對私有化部署的客戶進行歷史版本收斂。神策數據通過訂閱制的付費模式，在版本更新後主動爲客戶進行升級。
挑戰三：小集羣 K8s 化的難點
K8s 是業界通用的資源抽象模式，但是其搭建成本較高，比如控制面至少需要三臺機器等。對此，我們嘗試通過 K3s 來解決這個問題。對於已經在雲上的小規模客戶，後續可能採用直接雲上託管 K8s 服務。
挑戰四：內存不夠
隨着產品組件越來越多，功能越來越複雜，客戶私有化集羣的資源量卻是不變的，因此，內存成了私有化部署演進過程中不可忽視的問題。針對 Java 程序本身內存漲上去難以下降的問題，我們自行編譯了 JDK，引入了新的 GC 算法，讓 Java 程序的堆內存佔用可以在低峯期收縮。
挑戰五：資源受限的情況下查詢優化
在資源受限的情況下，如何進行查詢優化？
首先，我們針對用戶行爲分析場景進行定向優化。
（1）用戶行爲分析數據本身是有序的，通過重寫 SQL，我們將 join 全排序變爲歸併排序，這是我們做的第一個優化。
（2）爲了避免某些場景中的無效用戶量增加，我們採用兩種解決方案，一是客戶在數據治理上清理重複數據；二是在查詢方面記錄用戶最後的活躍時間，直接過濾掉不活躍用戶，避免過多數據的干擾。
（3）外連接消除。當用戶上報和增加限制條件後的實際連接不一致時，我們會依據實際連接進行計算，有效節省資源。
（4）高基數分組優化。對於數據量級較大但看數需求穩定在 Top1000 左右的客戶，我們會將提取 Top1000 的操作放到內層，提前把不需要的數據過濾掉。
其次，我們還會做查詢資源預估。在資源不夠時，針對並行的多個查詢任務，將其按照順序依次進行；同時基於歷史資源消耗進行預估，客戶使用頻次越高，估算越準確。
最後，我們還做了神策數倉負載管理平臺，幫助客戶清楚地瞭解內部資源是如何消耗的，查詢使用是否合理等。
挑戰六：各種意想不到的問題
在私有化部署過程中，還會遇到各種意想不到的問題。比如遇到客戶機房着火導致機房中大部分機器物理損壞，我們需要從僅有的一臺機器上搶救數據；或者遇到客戶機房所有機器一起瞬間斷電，導致數據損壞丟失等。
諸如此類的問題，都需要我們在做系統時考慮到。
三、SaaS 部署的意義及技術挑戰
私有化部署的主要侷限點在於 SLA 無法做到很高。因爲私有化部署的機器都部署在客戶環境中，系統一旦出現問題，光是連接到客戶的環境都需要耗費不少時間，再加上諸如安全性等種種限制，排查問題耗時較久。另外，因爲客戶環境本身是物理斷網的，必須派人去現場勘察，恢復時間較長，如此種種原因導致 SLA 不能達到特別高。
那爲什麼神策分析雲使用私有化部署時能夠成功，客戶能夠接受？這是因爲神策分析雲是一個旁路系統，且是離線場景，不會直接影響到客戶的業務。
而神策營銷雲則不同，營銷雲是一個業務系統，這意味着對 SLA 要求很高，一旦營銷活動出現問題將會直接影響客戶經營，這種情況下 SaaS 化就成了神策營銷雲的優先選擇。
同樣地，SaaS 化部署也會迎來新的技術挑戰。除了大家比較常見的 SaaS 集羣要多租戶之類，還面臨着兩個特殊的挑戰：
第一個就是營銷雲 SaaS 化，但分析雲依然是私有化部署，而營銷雲需要用到分析雲裏面的數據，這時該如何做？針對這個問題，神策數據開發了一條私有端到 SaaS 端的數據通路，保證營銷雲可以利用分析雲的數據進行營銷觸達。關於安全性我們也有特別的考慮：一方面，這個通道是加密的，保證安全不會泄露；另一方面，該通道具體傳了什麼樣的數據都是可以追蹤的。此外，即便是結果數據，也只是暫存而不是長期儲存在 SaaS 端。
第二個挑戰是對於那些因爲政策安全等原因，仍然會選擇私有化部署營銷雲的客戶，這種情況如何處理呢？我們採用了一套代碼和架構，多種部署模式的思路，也就是將神策數據整個通用的部署架構抽象成各種各樣的組件，有的是私有化部署和 SaaS 共享的組件，有的則是兩者分別特有的。
四、SaaS 化的分析雲
我們可以看到，相較於私有化部署，SaaS 化有以下優勢：
1、通過固定的機器進行成本分攤，對於中小客戶來說成本將顯著降低。
2、利用雲上的分層存儲，只緩存熱數據，可以降低存儲成本。
3、SaaS 理論上可以保證更高的 SLA，前面也提到，這也是爲什麼營銷雲必須要 SaaS 化。
五、神策部署模式的未來
關於神策部署模式的未來，主要有以下四點：
第一，神策數據未來的部署模式將是私有化和 SaaS 並存的狀態。
第二，爲了降低維護成本，我們將堅持一套代碼和架構、多種部署實現的方式。
第三，我們會從客戶實際需求出發，根據客戶的實際情況選擇最適合的部署方式。
第四，回到神策數據的價值觀——爲客戶帶來價值，不管技術上進行什麼樣的突破和改變，我們最終都是爲了更好地爲客戶帶來價值。