隨著數據已經逐步成為一個公司寶貴的財富，大數據團隊在公司往往會承擔更加重要的角色。大數據團隊往往要承擔數據平臺維護、數據產品開發、從數據產品中挖掘業務價值等重要的職責。所以對於很多大數據工程師，如何根據業務需求去選擇合適的大數據組件，做合適的大數據架構工作就是日常工作中最常遇到的問題。在這裡根據七牛雲在日增千億級的日誌分析工作，和大家分享一下大數據技術架構選型的一些經驗。
大數據架構師在關注什麼
在一個大數據團隊中，大數據架構師主要關注的核心問題就是技術架構選型問題。架構選型問題一般會受到哪些因素的影響呢？在我們的實踐中，一般大數據領域架構選型最受以下幾個因素影響：
- 數據量級
這一點在大數據領域尤其是一個重要的因素。不過從根本上講，數據量級本身也是一種業務場景的衡量。數據量級的不同往往也就昭示著業務場景的不同。
- 業務需求
經驗豐富的大數據架構師能夠從紛繁的業務需求中提煉出核心技術點，根據抽象的技術點選擇合適的技術架構。主要的業務需求可能包括：應用實時性要求、查詢的維度和靈活程度、多租戶、安全審計需求等等。
- 維護成本
這一點上大數據架構師一方面要能夠清楚的瞭解各種大數據技術棧的優劣勢，在滿足業務需求的要求下，能夠充分的優化架構，合理的架構能夠降低維護的成本，提升開發的效率。
另一方面， 大數據架構師要能清楚的瞭解自己團隊成員，能瞭解其他同學的技術專長和品位，能夠保證自己做的技術架構可以得到認可和理解，也能得到最好的維護和發展。
接下來我們會圍繞這幾個方面去看看，做一個最適合自己團隊業務的架構選型會如何受到這些因素的影響？
技術架構選型
業務需求是五花八門的，往往影響我們做技術選型的不是種種需求的細節，而是經過提煉後的一些具體的場景。就好比，業務需求提出我們要做一個日誌分析系統，或者要做一個用戶行為分析系統，這些具體需求背後我們要關注哪些具體的點？這是一個很有趣的問題，我們在做大數據的過程中，常發現我們對這些需求的疑問很多時候會落在以下幾個問題上。
其中數據量級作為一個重要的因素影響著我們對於技術選型的決定，另外在數據量的變化之外各種業務場景的需要也會影響我們對技術組件的選擇。
- 數據量級
如同我們上文中提到的，數據量級這個指標是一個特殊的業務場景的衡量，也是在大數據應用中影響最大的一個因素。往往對應不同的數據量級的業務，我們會有不同的考慮方式。
一般數據量級在 10GB 左右，數據總條數在千萬量級的數據，這種數據往往是業務最核心的數據，如用戶信息庫等。這種數據量由於其核心的業務價值，往往要求強一致性和實時性。在這種量級上，傳統關係型數據庫如 MySQL 等都能很好的解決各種業務需求。當然如果面對關係型數據庫難以解決的問題，比如全文索引等的時候，架構師還是需要根據業務需求選擇 Solr 或者 Elasticsearch 等搜索引擎解決此類問題。
如果數據量級增長到 1 億到 10 億級別的時候，一般來說這個階段就會面臨一個選擇，是採用傳統的 RDBMS+ 合理的索引+分庫分表等各種策略呢？還是應該選擇一些諸如 SQL On Hadoop 或者 HTAP、OLAP 組件呢？這時候靈活性其實還是相對比較大的，一般我們經驗是，如果團隊內有數據庫及中間件方向的專家工程師，希望保持架構簡單性，可以選擇繼續使用傳統關係型數據。但是如果為了對未來業務有更高的擴展性，能夠在可見的時間內支撐起更廣泛的業務需求，還是建議選擇使用大數據組件。
當數據量已經增長到 10 億到百億級別，特別是 10TB 以上了之後，往往我們傳統的關係型數據庫基本就已經被我們排除在可選的技術架構之外了。這時候常常要結合各種業務場景去選擇具體的場景的技術組件，比如我們要仔細審視，我們的業務場景是否是需要大量的更新操作？是否需要隨機讀寫能力？是否需要全文索引？
以上是一些主流的分析型引擎在各個數據量級下大致的表現結果，這個圖表中的數據僅僅是在大部分場景下的一般表現情況（並非精確測試結果，僅供參考）。不過值得注意的是，雖然看起來我們總是希望響應時間越少越好，數據量級越高越好，但要知道大數據領域並沒有銀彈，能夠解決所有的問題。每個技術組件都是犧牲了部分場景，才能在自己的領域中保持優勢。
- 實時性
實時性是一個如此重要的因素，所以我們在一開始就必須要重點的考慮業務需求中對實時性的要求。業務中的實時性往往包含兩方面的含義：
一方面，實時性體現在數據攝入的實時性上，數據攝入的實時性指的是當業務數據發生變化時候，我們的大數據應用能接受多少的延遲能看到這個數據？從理想情況上來說，當然業務上無論如何都是希望系統越實時越好，但是從成本和技術上兩方面去考量這個問題，我們一般分為實時系統（毫秒延遲）、近實時系統（秒級延遲）、準實時系統（分鐘級延遲）和離線系統（小時級或者天延遲）。一般延遲時間和吞吐能力，和計算能力都是反比的，吞吐越強，計算越精確，延遲時間會更長。
另一方面，實時性也體現在查詢的延遲上面，這個延遲計算的是，用戶發出查詢請求之後，要等待多長時間，服務端能夠返回計算結果。這個大部分情況下決定於產品的具體形態，如果這個產品是要給終端用戶進行展示，比如風雲榜、熱搜榜、推薦商品等統計類產品，是要有很高的 QPS 需求的產品，必然會需要將延遲控制在亞秒級。在另一種場景下，如果一個產品是給數據分析師，或者運營人員進行數據探索使用，往往這時候會經過大規模且不可控制的計算，這時候可能更適合於一種離線任務的模式，用戶的忍耐程度也會更高，支持分鐘級甚至小時級別的數據輸出。
可以從這個圖中看出，一般在實時領域會選擇 HBase，Cassandra 這種能支持事務同時支持高更新吞吐量的技術組件，或者也可以選擇 TiDB、Spanner、Kudu 等這種 HTAP 組件，同時支持事務和分析的分佈式數據庫。
如果追求更高的分析性能，可以選擇專業的 OLAP（On-Line Analytical Processing）組件，如 Kylin 或者 Druid，他們屬於 MOLAP （Multi-dimensional OLAP），支持提前創建數據立方，對指標進行預聚合，雖然犧牲一定的查詢靈活程度，但是保證了查詢實時性。
而 Elastic Search 是相對最為靈活的一個 NoSQL 查詢引擎，一方面它支持全文索引，這個是其他引擎所不具備的。另外它也支持少量的更新，支持聚合分析，也支持明細數據的搜索查詢，在近實時領域適用場景非常的多。不過由於 ES 是基於 Lucene 的存儲引擎，相對需要資源成本會更高，而且分析性能對比其他引擎不具備優勢。
另外，如果我們的數據是離線或者追加的方式進行歸檔，同時產品形態需要依賴大批量數據的運算。這種產品往往可以忍受較高的查詢延遲，那麼 Hadoop 生態的一系列產品會非常適合這個領域，比如新一代的 MapReduce 計算引擎 Spark，另外一系列 SQL On Hadoop 的組件，Drill，Impala，Presto 等各有各自的優點，我們可以結合其他業務需求來選型。
- 計算維度/靈活度
計算維度和計算靈活度，這兩個因素是對計算選型很重要的因素。試想一下，如果我們的產品只產出固定的若干指標項，我們完全可以使用 Spark 離線計算將數據結果導入到 MySQL 等業務數據庫中，作為結果集提供展示服務。
但當如果我們的查詢是一個交互式的，如果用戶能夠自己選擇維度進行數據聚合，我們無法將所有維度的排列組合都預計算出來，那這時候我們可能就需要的是一個 OLAP 組件，需要能夠根據指定維度做指標預聚合，這種選型能增強結果展示的靈活度，也能大大降低查詢的延遲。
更深一步，用戶如果不僅僅能夠對數據指標進行計算，同時要能夠查詢到原始的明細數據，這時候可能 OLAP 組件不再適用，那麼可能就需要到 ES 或者 SQL On Hadoop 這樣更加靈活的組件。這時候如果有全文搜索需求，那麼就選擇 ES，如果沒有就選擇 SQL On Hadoop。
- 多租戶
多租戶需求也是一個大數據架構師經常需要考慮到的問題，多租戶的需求往往是來源於許多不同的使用方，這種需求對於一個公司的基礎架構部門非常常見。
多租戶要考慮哪些呢？
第一是資源的隔離性，從資源節省的角度來看，肯定是不同租戶之間資源可以共享的話，資源可以充分的利用起來。這也是我們一般做基礎架構部門最希望做的工作。不過對於很多租戶來說，可能業務級別更高，或者數據量更加的龐大，如果和普通的租戶一起共享資源可能會造成資源爭搶。這時候就要考慮物理資源的隔離。
第二，就要考慮用戶安全。一方面是要做認證，需要杜絕惡意或者越權訪問數據的事情發生。另一方面要做好安全審計，每次敏感操作要記錄審計日誌，能夠追溯到每次行為的來源 IP 和操作用戶。
第三但也是最重要的一點，就是數據權限。多租戶系統並不僅僅意味著隔離，更加意味著資源能夠更加合理有效的得到共享和利用。現在數據權限往往不能侷限於一個文件、一個倉庫的讀寫權限。更多的時候我們可能要對某個數據子集，某些數據字段進行數據授權，這樣每個數據所有者能夠將自己的資源更加安全的分發給需要的租戶。將數據能夠更加高效的利用起來，這也是一個數據平臺/應用重要的使命。
- 維護成本
對於架構師而言大數據平臺的維護成本是一個至關重要的指標，經驗豐富的架構師能夠結合自身團隊的特點選擇合適的技術方案。
從上圖可以看出大數據平臺可以根據服務依賴（是依賴雲服務還是自建大數據平臺）和技術組件的複雜度分為四個象限。
• 使用成本和技術組件複雜度成正比，一般來說組件複雜度越高，組件數量越多，多種組件配合使用成本會越高。
• 維護成本和服務供應商以及組件複雜度都有關係，一般來說，單一的技術組件要比複雜的技術組件維護成本低，雲服務提供的技術組件要比自建大數據組件維護成本要更低。
• 團隊要求來說，一般來說與使用成本趨同，都是技術組件越複雜，團隊要求越高。不過另一方面團隊要求與服務供應商也存在關係，如果雲服務廠商能夠承擔起組件的運維工作，實際上是可以幫助業務團隊從運維工作中解放出更多的工程師，參與到大數據應用的工作中。
所以一般來說，架構師對於技術選型的偏好應該是，在滿足業務需求和數據量需求的前提下，選擇技術架構最簡單的，因為往往這種選型是最容易使用和維護的。在這個基礎上，如果有一支非常強大的技術開發和運維團隊，可以選擇自建大數據平臺；如果缺乏足夠的運維、開發支撐，那麼建議選擇雲服務平臺來支撐業務。
整理/夏立城 上海藍盟創始人兼CEO，復旦校友創新創業俱樂部副會長，致力於用IT外包網絡維護服務賦能企業客戶發展，助力其創新、迭代和進化。
閱讀更多 夏掰創業 的文章
