1.1.1 Doris應需而生

在Doris誕生之前，百度和大多數互聯網公司一樣，使用MySQL的Sharding為OLAP報表業務提供支持。在早些年，百度的主要收入來源是廣告，廣告主需要通過報表查看廣告的展現效果、點擊量、收入等信息，并且根據不同維度分析制定后續廣告的投放策略。隨著百度本身流量的增加，廣告流量也隨之增加，MySQL的Sharding方案無法滿足業務需求，主要痛點如下。

?大規模數據導入會導致MySQL的讀性能大幅降低，有時還會出現鎖表現象，導致查詢超時，尤其在頻繁導入數據時，問題更為明顯。

?MySQL在數據量達千萬級別時性能很差，只能從產品層面來限制用戶的查詢時間，抑制了用戶需求，增加了很多后臺取數的需求。

?MySQL單表存儲的數據有限，如果數據量過大，查詢就會變慢。而且隨著數據量的快速增長，Sharding方案維護成本飆升。

上述痛點也是目前大多數未引入Doris的企業所面臨的，特別是在互聯網行業，數據量大，且較少采用商業軟件，主要以開源MySQL為核心構建報表查詢系統，需要將在線分析處理結果進行多次聚合，才能滿足報表的查詢需求。

在2008年那個時間點，處理數據存儲和計算的成熟開源產品很少，HBase的導入性能只有約2000條/s，不能滿足業務快速增長需求。另外，業務還在不斷增加，數據存儲和數據分析的壓力越來越大。于是，百度選擇了自主研發之路，Doris由此誕生。

在Doris 1版本中，數據仍然通過用戶ID進行哈希分布，將同一個用戶ID的數據交由一臺機器處理，這樣大量的Join操作都可以在本地完成。Doris 1架構包含數據存儲、元數據管理、數據導入和API網關4個部分，其中數據存儲組件負責數據的存儲和讀寫，元數據管理組件負責數據文件的目錄管理和表信息管理，數據導入組件負責寫入外部導入的數據，API網關負責接收、解析、規劃查詢請求。

相比于MySQL的Sharding方案，Doris主要在如下幾個方面進行了改進。

?Doris 1的數據模型將數據分為Key列、Value列。比如一條交易數據的Key列包括用戶ID、時間、地域、來源等，Value列包括展現次數、點擊次數、消費額等。在這樣的數據模型下，所有Key列相同的行對應的Value列能夠進行聚合，比如數據的時間維度最細粒度為小時，那么同一小時內多次導入的數據能夠合并成一條記錄，這樣對于同樣的查詢來說，Doris 1需要掃描的數據條目相比MySQL會少很多。

?Doris 1將MySQL逐條插入的方式改為批量更新，并且通過外圍模塊將同一批次數據進行排序以及預聚合。這樣一個批次中相同Key列的數據能夠被預先聚合，另外排序后的數據能起到聚集索引的作用，提升查詢性能。

?Doris 1提供了天表、月表這種類似物化視圖的功能。比如用戶想將數據按天進行匯聚展現，那么可以通過天表來實現。而相對于小時表，天表數據量會少很多，相應的查詢性能也會提升幾倍。

至此，Doris已經有了聚合模型、物化視圖、批量讀寫3個基本特點了。Doris 2主要將Doris 1進行通用化改造，包括支持自定義表結構等，使Doris能夠應用于其他產品，拓展了一些應用場景。