隨著數(shù)據(jù)逐漸成為企業(yè)寶貴的資產(chǎn)，大數(shù)據(jù)團(tuán)隊(duì)在企業(yè)中的角色也越來越趨向于承擔(dān)更重要的角色。 大數(shù)據(jù)團(tuán)隊(duì)往往要承擔(dān)數(shù)據(jù)平臺(tái)維護(hù)、數(shù)據(jù)產(chǎn)品開發(fā)、從數(shù)據(jù)產(chǎn)品中挖掘商業(yè)價(jià)值等重要職責(zé)。 因此，對(duì)于很多大數(shù)據(jù)工程師來說，如何根據(jù)業(yè)務(wù)需求選擇合適的大數(shù)據(jù)組件，做好合適的大數(shù)據(jù)架構(gòu)工作，是日常工作中最常遇到的問題。 在此，基于七牛云日增千億級(jí)的日志分析工作，與大家分享一些大數(shù)據(jù)技術(shù)架構(gòu)選型的心得。

大數(shù)據(jù)架構(gòu)師關(guān)注什么

在一個(gè)大數(shù)據(jù)團(tuán)隊(duì)中，大數(shù)據(jù)架構(gòu)師主要關(guān)注的核心問題是技術(shù)架構(gòu)的選擇。 架構(gòu)選擇問題一般會(huì)影響哪些因素？ 在我們的實(shí)踐中，一般的大數(shù)據(jù)領(lǐng)域架構(gòu)選擇受以下因素影響最大：

這在大數(shù)據(jù)領(lǐng)域尤為重要。 但從根本上說，數(shù)據(jù)量級(jí)本身也是業(yè)務(wù)場景的衡量標(biāo)準(zhǔn)。 數(shù)據(jù)量級(jí)的不同，往往代表著業(yè)務(wù)場景的不同。

經(jīng)驗(yàn)豐富的大數(shù)據(jù)架構(gòu)師能夠從眾多的業(yè)務(wù)需求中提煉出核心技術(shù)點(diǎn)，根據(jù)抽象出來的技術(shù)點(diǎn)選擇合適的技術(shù)架構(gòu)。 主要業(yè)務(wù)需求可能包括：應(yīng)用實(shí)時(shí)性需求、查詢維度和靈活性、多租戶、安全審計(jì)需求等。

對(duì)此，一方面，大數(shù)據(jù)架構(gòu)師必須能夠清楚地了解各種大數(shù)據(jù)技術(shù)棧的優(yōu)缺點(diǎn)。 在滿足業(yè)務(wù)需求的要求下，他們可以充分優(yōu)化架構(gòu)。 合理的架構(gòu)可以降低維護(hù)成本，提高開發(fā)效率。 效率。

另一方面，大數(shù)據(jù)架構(gòu)師必須能夠清楚地了解自己的團(tuán)隊(duì)成員，了解其他同學(xué)的技術(shù)專長和品味，保證自己的技術(shù)架構(gòu)能夠被認(rèn)可和理解，以及最好的維護(hù)和發(fā)展。

下面我們就圍繞這幾個(gè)方面來看一下，這些因素會(huì)如何影響選擇最適合自己團(tuán)隊(duì)業(yè)務(wù)的架構(gòu)？

技術(shù)架構(gòu)選擇

業(yè)務(wù)需求是多種多樣的，影響我們技術(shù)選擇的往往不是各種需求的細(xì)節(jié)，而是經(jīng)過細(xì)化后的一些具體場景。 比如業(yè)務(wù)需求建議我們要搭建一個(gè)日志分析系統(tǒng)，或者用戶行為分析系統(tǒng)。 在這些具體要求的背后，我們應(yīng)該注意哪些具體點(diǎn)呢？ 這是一個(gè)非常有趣的問題。 在做大數(shù)據(jù)的過程中，我們經(jīng)常會(huì)發(fā)現(xiàn)，我們對(duì)這些需求的疑問，往往會(huì)落在下面幾個(gè)問題上。

其中，數(shù)據(jù)層面是影響我們技術(shù)選型決策的重要因素。 另外，各種業(yè)務(wù)場景的需求，除了數(shù)據(jù)量的變化，也會(huì)影響我們對(duì)技術(shù)組件的選擇。

上文我們提到，數(shù)據(jù)量級(jí)指標(biāo)是衡量一種特殊業(yè)務(wù)場景的指標(biāo)，也是大數(shù)據(jù)應(yīng)用中影響最大的因素。 不同數(shù)據(jù)層次對(duì)應(yīng)的業(yè)務(wù)，我們往往會(huì)有不同的思考方式。

一般數(shù)據(jù)大小在10GB左右，數(shù)據(jù)總量在千萬級(jí)別。 這類數(shù)據(jù)往往是業(yè)務(wù)的核心數(shù)據(jù)，比如用戶信息數(shù)據(jù)庫。 由于其核心業(yè)務(wù)價(jià)值，這類數(shù)據(jù)往往需要強(qiáng)一致性和實(shí)時(shí)性。 在這個(gè)層面上，MySQL等傳統(tǒng)關(guān)系型數(shù)據(jù)庫可以很好地解決各種業(yè)務(wù)需求。 當(dāng)然，如果面對(duì)關(guān)系型數(shù)據(jù)庫難以解決的問題，比如全文索引，架構(gòu)師還是需要選擇Solr或者等待搜索引擎根據(jù)業(yè)務(wù)需求來解決此類問題。

如果數(shù)據(jù)量增長到1億到10億級(jí)別，一般來說，在這個(gè)階段，你會(huì)面臨一個(gè)選擇，是采用傳統(tǒng)RDBMS+合理索引+分庫分表等多種策略？ 還是應(yīng)該選擇SQL On 或HTAP、OLAP 等組件？ 這時(shí)候其實(shí)彈性還是比較大的。 一般我們的經(jīng)驗(yàn)是，如果團(tuán)隊(duì)中有數(shù)據(jù)庫和中間件方向的專家工程師，又想保持結(jié)構(gòu)簡單，可以選擇繼續(xù)使用傳統(tǒng)的關(guān)系型數(shù)據(jù)。 但是為了對(duì)未來的業(yè)務(wù)有更高的擴(kuò)展性，能夠在可見時(shí)間內(nèi)支持更廣泛的業(yè)務(wù)需求，建議選擇使用大數(shù)據(jù)組件。

當(dāng)數(shù)據(jù)量增長到10億到100億級(jí)別，尤其是10TB以上之后，我們傳統(tǒng)的關(guān)系型數(shù)據(jù)庫基本已經(jīng)被排除在我們可選的技術(shù)架構(gòu)之外了。 這時(shí)候往往需要結(jié)合各種業(yè)務(wù)場景來選擇特定場景的技術(shù)組件。 比如我們需要仔細(xì)審視我們的業(yè)務(wù)場景是否需要大量的更新操作？ 是否需要隨機(jī)讀寫能力？ 您需要全文索引嗎？

以上是一些主流分析引擎在各個(gè)數(shù)據(jù)層面的一般性能結(jié)果。 本圖表數(shù)據(jù)僅為大部分場景下的一般表現(xiàn)（并非準(zhǔn)確測試結(jié)果，僅供參考）。 不過，值得注意的是，雖然看起來我們總是希望響應(yīng)時(shí)間越短越好，數(shù)據(jù)量越多越好，但要知道大數(shù)據(jù)領(lǐng)域沒有靈丹妙藥可以解決所有問題。 每個(gè)技術(shù)組件都犧牲了一部分場景，以保持在自己領(lǐng)域的優(yōu)勢。

實(shí)時(shí)性就是這么重要的一個(gè)因素，所以我們一開始就要著眼于業(yè)務(wù)需求的實(shí)時(shí)性要求。 業(yè)務(wù)中的實(shí)時(shí)往往包括兩層含義：

一方面，實(shí)時(shí)性體現(xiàn)在數(shù)據(jù)攝入的實(shí)時(shí)性上。 數(shù)據(jù)攝入的實(shí)時(shí)性是指當(dāng)業(yè)務(wù)數(shù)據(jù)發(fā)生變化時(shí)，我們的大數(shù)據(jù)應(yīng)用能夠接受多少延遲才能看到這些數(shù)據(jù)？ 理想情況下，當(dāng)然在業(yè)務(wù)上，系統(tǒng)越實(shí)時(shí)越好，但是從成本和技術(shù)兩個(gè)方面考慮這個(gè)問題it技術(shù)人員，我們一般分為實(shí)時(shí)系統(tǒng)（毫秒級(jí)延遲），近實(shí)時(shí)系統(tǒng)-時(shí)間系統(tǒng)（秒級(jí)延遲）、準(zhǔn)實(shí)時(shí)系統(tǒng)（分鐘級(jí)延遲）和離線系統(tǒng)（小時(shí)級(jí)或天級(jí)延遲）。 通常，延遲時(shí)間、吞吐量和計(jì)算能力是成反比的。 吞吐量越強(qiáng)，計(jì)算越準(zhǔn)確，延遲時(shí)間越長。

另一方面，實(shí)時(shí)性還體現(xiàn)在查詢延遲上。 這個(gè)延遲被計(jì)算為用戶在發(fā)送查詢請(qǐng)求后服務(wù)器可以返回計(jì)算結(jié)果之前需要等待多長時(shí)間。 在大多數(shù)情況下，這取決于產(chǎn)品的具體形式。 產(chǎn)品如果要展示給終端用戶，比如風(fēng)云榜等統(tǒng)計(jì)產(chǎn)品、熱搜榜、推薦產(chǎn)品等，就必須有很高的QPS需求。 您將需要亞秒級(jí)延遲。 另外一個(gè)場景，如果一個(gè)產(chǎn)品被數(shù)據(jù)分析師或者運(yùn)維人員用來進(jìn)行數(shù)據(jù)探索，這時(shí)候往往會(huì)進(jìn)行大規(guī)模的、不可控的計(jì)算，可能更適合離線的任務(wù)模式。 用戶也會(huì)更有耐心，支持分鐘級(jí)甚至小時(shí)級(jí)的數(shù)據(jù)輸出。

從這個(gè)圖可以看出，在實(shí)時(shí)領(lǐng)域一般會(huì)選擇HBase，它是支持事務(wù)、更新吞吐量高的技術(shù)組件，也可以選擇TiDB、Kudu等支持事務(wù)的HTAP組件并同時(shí)分析分布式數(shù)據(jù)庫。

如果追求更高的分析性能it技術(shù)人員，可以選擇專業(yè)的OLAP（On-Line）組件，比如Kylin或者Druid，屬于MOLAP（Multi-OLAP），支持?jǐn)?shù)據(jù)立方體的提前創(chuàng)建和指標(biāo)的預(yù)聚合，雖然犧牲了一定的Query靈活性，但是保證了查詢的實(shí)時(shí)性。

它是相對(duì)最靈活的NoSQL查詢引擎。 一方面，它支持全文索引，這是其他引擎所不具備的。 此外，還支持明細(xì)數(shù)據(jù)的小量更新、聚合分析、搜索查詢，適用于近實(shí)時(shí)領(lǐng)域的諸多場景。 但是由于ES是基于存儲(chǔ)引擎的，相對(duì)資源成本會(huì)更高，分析性能與其他引擎相比也沒有優(yōu)勢。

另外，如果我們的數(shù)據(jù)是離線或者附加歸檔的，產(chǎn)品形態(tài)需要依賴大批量數(shù)據(jù)的操作。 這類產(chǎn)品往往可以容忍高查詢延遲，所以一系列的生態(tài)產(chǎn)品會(huì)非常適合這個(gè)領(lǐng)域，比如新一代的計(jì)算引擎Spark，還有另外一系列的SQL On組件，Drill等，各有各的各有優(yōu)勢，可以結(jié)合其他業(yè)務(wù)需求選擇機(jī)型。

計(jì)算維度和計(jì)算靈活性，這兩個(gè)因素是計(jì)算模型選擇非常重要的因素。 試想一下，如果我們的產(chǎn)品只產(chǎn)生固定數(shù)量的指標(biāo)，我們可以使用Spark離線計(jì)算，將數(shù)據(jù)結(jié)果導(dǎo)入到MySQL等業(yè)務(wù)數(shù)據(jù)庫中，以結(jié)果集的形式提供展示服務(wù)。

但是如果我們的查詢是交互式的，如果用戶可以選擇維度進(jìn)行數(shù)據(jù)聚合，我們無法預(yù)先計(jì)算所有維度的排列組合，那么這時(shí)候我們可能需要一個(gè)OLAP組件，它需要能夠預(yù)索引索引- 基于指定維度的聚合，可以增強(qiáng)結(jié)果展示的靈活性，大大降低查詢延遲。

更進(jìn)一步，如果用戶不僅可以計(jì)算數(shù)據(jù)指標(biāo)，還可以查詢?cè)嫉拿骷?xì)數(shù)據(jù)，此時(shí)OLAP組件可能不再適用，可能需要ES或SQL On等更靈活的組件。 這時(shí)候如果有全文檢索的需求，就選擇ES，如果不需要，就選擇SQL On。

多租戶需求也是大數(shù)據(jù)架構(gòu)師經(jīng)常需要考慮的問題。 多租戶需求通常來自許多不同的用戶。 這種需求對(duì)于公司的基礎(chǔ)設(shè)施部門來說是很常見的。

多租戶應(yīng)該考慮什么？

首先是資源隔離。 從資源節(jié)約的角度來說，一定是不同租戶之間共享資源，才能充分利用資源。 這也是我們普遍希望基建部門做的最多的事情。 但是對(duì)于很多租戶來說，可能業(yè)務(wù)層次更高，或者數(shù)據(jù)量更大。 如果他們與普通租戶共享資源，可能會(huì)造成資源競爭。 這時(shí)候就需要考慮物理資源的隔離了。

其次，要考慮用戶安全。 一方面，需要進(jìn)行身份驗(yàn)證以防止惡意或未經(jīng)授權(quán)訪問數(shù)據(jù)。 另一方面，要做好安全審計(jì)，對(duì)每一個(gè)敏感操作都要記錄審計(jì)日志，可以追溯到每一個(gè)動(dòng)作的源IP和操作用戶。

第三點(diǎn)也是最重要的一點(diǎn)是數(shù)據(jù)權(quán)限。 多租戶系統(tǒng)不僅僅意味著隔離，還意味著可以更合理有效地共享和利用資源。 現(xiàn)在的數(shù)據(jù)權(quán)限往往不能局限于一個(gè)文件或者一個(gè)倉庫的讀寫權(quán)限。 更多時(shí)候，我們可能需要對(duì)數(shù)據(jù)的子集和某些數(shù)據(jù)字段進(jìn)行數(shù)據(jù)授權(quán)，以便每個(gè)數(shù)據(jù)所有者可以更安全地將他們的資源分配給所需的租戶。 更高效地利用數(shù)據(jù)也是數(shù)據(jù)平臺(tái)/應(yīng)用的重要使命。

對(duì)于架構(gòu)師來說，大數(shù)據(jù)平臺(tái)的維護(hù)成本是一個(gè)至關(guān)重要的指標(biāo)。 有經(jīng)驗(yàn)的架構(gòu)師可以根據(jù)自己團(tuán)隊(duì)的特點(diǎn)選擇合適的技術(shù)方案。

從上圖可以看出，大數(shù)據(jù)平臺(tái)可以根據(jù)服務(wù)依賴（是依賴云服務(wù)還是自建大數(shù)據(jù)平臺(tái)）和技術(shù)組件的復(fù)雜程度分為四個(gè)象限。

? 使用成本與技術(shù)組件的復(fù)雜性成正比。 一般來說，組件的復(fù)雜度越高，組件的數(shù)量就越多，使用多個(gè)組件的成本也越高。

? 維護(hù)成本與服務(wù)提供商和組件的復(fù)雜性有關(guān)。 一般來說，單一技術(shù)組件的維護(hù)成本低于復(fù)雜技術(shù)組件，云服務(wù)提供的技術(shù)組件維護(hù)成本低于自建大數(shù)據(jù)組件。 低的。

? 在團(tuán)隊(duì)需求方面，一般來說，與使用成本趨于一致。 技術(shù)組件越復(fù)雜，對(duì)團(tuán)隊(duì)的要求就越高。 但是，另一方面，團(tuán)隊(duì)需要與服務(wù)提供商建立關(guān)系。 如果云服務(wù)商能夠承擔(dān)組件的運(yùn)維，其實(shí)可以幫助業(yè)務(wù)團(tuán)隊(duì)把更多的工程師從運(yùn)維工作中解放出來，參與到大數(shù)據(jù)中來。 工作中的應(yīng)用。

因此，一般來說，架構(gòu)師對(duì)技術(shù)選型的偏好應(yīng)該是在滿足業(yè)務(wù)需求和數(shù)據(jù)量要求的前提下，選擇最簡單的技術(shù)架構(gòu)，因?yàn)檫@種選型往往是最容易使用和維護(hù)的。 在此基礎(chǔ)上，如果你有非常強(qiáng)大的技術(shù)開發(fā)和運(yùn)維團(tuán)隊(duì)，你可以選擇搭建自己的大數(shù)據(jù)平臺(tái)； 如果你缺乏足夠的運(yùn)維和開發(fā)支持，那么建議選擇云服務(wù)平臺(tái)來支持你的業(yè)務(wù)。

整理/夏立成 上海藍(lán)夢創(chuàng)始人兼CEO，湖北IT公司副總裁，致力于以IT外包網(wǎng)絡(luò)維護(hù)服務(wù)賦能企業(yè)客戶發(fā)展，幫助企業(yè)客戶創(chuàng)新、迭代、進(jìn)化。