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

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

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

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

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

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

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

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

技術架構(gòu)選擇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更進一步，如果用戶不僅可以計算數(shù)據(jù)指標，還可以查詢原始的明細數(shù)據(jù)，此時OLAP組件可能不再適用，可能需要ES或SQL On等更靈活的組件。 這時候如果有全文檢索的需求，就選擇ES，如果不需要，就選擇SQL On。

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

多租戶應該考慮什么？

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

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

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

對于架構(gòu)師來說，大數(shù)據(jù)平臺的維護成本是一個至關重要的指標。 有經(jīng)驗的架構(gòu)師可以根據(jù)自己團隊的特點選擇合適的技術方案。

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

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

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

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

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

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