1、序言
本文主要介紹Apache Doris在京東廣告報表查詢場景下的應用。文章將從我們原有系統開始講述，包括我們遇到的問題，面臨的挑戰，以及我們為何選擇使用Apache Doris。最後將介紹Doris在我們在生產環境下的使用情況，包括Apache Doris在京東「618」，「雙11」大促中的表現。希望通過我們的使用實踐為大家提供一些經驗參考，也歡迎大家對我們的不足之處提出建議。
2、背景介紹
京準通是京東集團旗下的廣告營銷推廣平臺。我們團隊主要負責京準通平臺的報表查詢服務，主要為廣告主/運營/採銷等提供實時/離線的報表的查詢，支持了十餘個業務線，300多張報表，覆蓋了京準通內絕大多數效果報表，每日千萬級查詢總量，百億級數據增量，毫秒級的查詢耗時。
3、原有系統存在的問題
我們原來有一套京東廣告自己內部開發廣告效果數據查詢系統，可以支持數據預聚合，支持原子導入，支持按列建立Rollup表。由於這些特性的原因，原有系統在廣告效果數據報表的特定場景下，可以滿足日常線上查詢的需求。
但隨著業務的迭代，上層查詢系統對我們的要求越來越高，主要表現以下幾個方面：
1. 原有系統已經逐漸無法滿足我們日常業務的性能需求。
2. 日常業務所需的Schema Change，Rollup等操作，在原有系統上有極高的人力成本。
3. 原有系統的數據無法遷移，擴容需要重刷全部歷史數據，運維成本極高。
4. 在「618」和「雙11」的時候，原有系統會成為我們對外服務的一個隱患。
因此我們需要一個合適的數據查詢引擎來替代我們原有系統，考慮到我們團隊的人力和研發能力，我們選擇使用開源的OLAP引擎來替換原有系統。
4、技術選型
這裡簡單介紹我們日常操作的關注的痛點，也是我們在之後技術選型方面主要考慮的方面。
查詢
我們為廣告主提供在線報表數據查詢服務，因此該OLAP查詢引擎必須滿足：可以支持高並發查詢，可以毫秒級返回數據，且可以隨著業務的發展水平擴展。此外我們也承接了越來越多運營和採銷同事的多維數據分析的需求，因此希望該OLAP引擎也可以支持高吞吐的Ad-hoc查詢。
數據導入
我們需要同時支持離線（T+1）大規模數據和實時（分鐘級間隔）數據的導入，數據導入後即可查詢，保證數據導入的實時性和原子性。離線數據（幾十G）的導入任務需要在1小時內完成，實時數據（百M到幾G）的導入任務需要在10分鐘內完成。
擴容
在「618」這類大促前我們通常會進行擴容，因此需要新系統擴容方便，無需重刷歷史數據來重新分布數據，且擴容後原有機器的數據最好可以很方便地遷移到新機器上，避免造成數據傾斜。
根據日常業務的需要，我們經常會進行Schema Change操作。由於原有系統對這方面的支持很差，我們希望新系統可以進行Online Schema Change，且對線上查詢無影響。
數據修復
由於業務的日常變更會對一些表進行數據修復，因此新系統需要支持錯誤數據的刪除，從而無需重刷全部歷史數據，避免人力和計算資源的浪費。
目前開源的OLAP引擎很多，但由於面臨大促的壓力，我們需要儘快完成選型並進行數據遷移，因此我們只考察了比較出名的幾個OLAP系統：ClickHouse，Druid和Doris。最終我們選擇了Doris來替換我們的原有系統，主要基於以下幾方面的考慮：
1. Doris的查詢速度是亞秒級的，並且相對ClickHouse來說，Doris對高並發的支持要優秀得多。
2. Doris擴容方便，數據可以自動進行負載均衡，解決了我們原有系統的痛點。ClickHouse在擴容時需要進行數據重分布，工作量比較大。
3. Doris支持Rollup和Online Schema Change，這對我們日常業務需求十分友好。而且由於支持MySQL協議，Doris可以很好地和之前已有的系統進行融合。而Druid對標準SQL的支持有限，並且不支持MySQL協議，對於我們來說改造成本很高。
5、廣告場景應用
經過對我們系統的改造，目前我們使用Doris作為我們系統中的一個數據存儲層，匯總了離線和實時數據，也為上層查詢系統提供統一的效果數據查詢接口。如下圖所示：
數據導入
我們日常實時數據主要包含展現/點擊跟單數據，DMP人群包的效果數據以及十幾條產品線的點擊，展現和消耗數據，導入時間間隔從1分鐘到1小時不等，數據量在百M左右的可以秒級導入，數據量在1G左右的可以在1分鐘內完成。離線數據主要包含搜索詞的效果數據和各種營銷工具的基礎數據，大多數都是T+1數據，每日新增數據量在20G-30G，導入耗時在10-20分鐘。
預計算
對於我們的大多數效果數據報表，廣告主的查詢維度相對固定且可控，但要求能在毫秒級返回數據，所以必須保證這些查詢場景下的性能。Doris支持的聚合模型可以進行數據的預聚合，將點擊，展現，消耗等數據匯總到建表時指定的維度。
此外，Doris支持建立Rollup表（即物化視圖）也可以在不同維度上進行預聚合，這種自定義的方式相比Kylin的自動構建cube，有效避免了數據的膨脹，在滿足查詢時延的要求下，降低了磁碟佔用。Doris還可以通過Rollup表對維度列的順序進行調整，避免了Kylin中因過濾維度列在HBase RowKey後部而造成的查詢性能低下。
現場計算
對於一些為廣告主提供的營銷工具，維度和指標通常會有30~60列之多，而且大部分查詢要求按照所有維度列進行聚合，由於維度列較多，這種查詢只能依賴於現場計算能力。目前我們對於這種類型的查詢請求，會將其數據儘量均勻分布到多臺BE上，利用Doris MPP架構的特性，並行計算，並通過控制查詢時間範圍（一個月），可以使TP99達到3s左右。
業務舉例
正是由於Doris具有自定義的預計算能力和不俗的現場計算能力，簡化了我們的日常工作。以我們為廣告主提供的營銷工具「行業大盤」為例，如圖所示，這種業務場景下，不僅要計算廣告主自身的指標數據，還需計算廣告主所在類目的指標數據，從而進行對比。
原有系統數據分片只能按照指定列進行散列，沒有分布式查詢計劃，就不能匯總類目維度數據。原先為了解決這種業務場景，雖然底層是同一數據源，但我們需要建兩個表，一個是廣告主維度表，一個是類目維度表，維護了兩個數據流，增大了工作負擔。
使用了Doris之後，廣告主維度表可以Rollup出類目維度表。查詢廣告主維度數據時可以根據分區分桶（按照時間分區，按照廣告主ID分桶）確定一個Tablet，縮小數據查詢範圍，查詢效率很高。查詢類目維度時，數據已經按照廣告主ID進行分片 ，可以充分利用Doris現場計算的能力，多個BE並行計算，實時計算類目維度數據，在我們的線上環境也能實現秒級查詢。這種方案下數據查詢更加靈活，無需為了查詢性能而維護多個預計算數據，也可以避免多張表之間出現數據不一致的問題。
6、實際使用效果
日常需求
– Doris支持聚合模型，可以提前聚合好數據，對計算廣告效果數據點擊，展現和消耗十分適合。對一些數據量較大的高基數表，我們可以對查詢進行分析，建立不同維度或者順序的的Rollup表來滿足查詢性能的需求。
– Doris支持Online Schema Change，相比原有系統Schema Change需要多個模塊聯動，耗費多個人力數天才能進行的操作，Doris只需一條SQL且在較短時間內就可以完成。對於日常需求來說，最常見的Schema Change 操作就是加列，Doris對於加列操作使用的是Linked Schema Change方式，該方式可以無需轉換數據，直接完成，新導入的數據按照新的Schema進行導入，舊數據可以按照新加列的默認值進行查詢，無需重刷歷史數據。
– Doris通過HLL列和BITMAP列支持了近似/精確去重的功能，解決了之前無法計算UV的問題。
– 日常數據修復，相較於以前有了更多的方式可以選擇。對於一些不是很敏感的數據，我們可以刪除錯誤數據並進行重新導入；對於一些比較重要的線上數據，我們可以使用Spark on Doris計算正確數據和錯誤數據之間的差值，並導入增量進行修復。這樣的好處是，不會暴露一個中間狀態給廣告主。我們還有一些業務會對一個或多個月的數據進行重刷。我們目前在測試使用Doris 0.12版本提供的Temp Partition功能，該功能可以先將正確數據導入到Temp Partition中，完成後可以將要刪除的Partition和Temp Partition進行交換，交換操作是原子性的，對於上層用戶無感知。
大促備戰
– Doris添加新的BE節點後可以自動遷移Tablet到新節點上，達到數據負載均衡。通過添加FE節點，則可以支撐更高的查詢峰值，滿足大促高並發的要求。
– 大促期間數據導入量會暴增，而且在備戰期間，也會有憋單演練，在短時間內會產生大量數據導入任務。通過導入模塊限制Load的並發，可以避免大量數據的同時導入，保證了Doris的導入性能。
– Doris在我們團隊已經經歷了數次大促，在所有大促期間無事故發生，查詢峰值4500+qps，日查詢總量8千萬+，TP99毫秒級，數據日增量近300億行，且實時導入數據秒級延遲。
使用實踐
– Doris支持低延時的高並發查詢和高吞吐的Ad-hoc查詢，但是這兩類查詢會相互影響，遷移到Doris的初期日常線上的主要問題就是高吞吐的查詢佔用資源過多，導致大量低延時的查詢超時。後來我們使用兩個集群來對兩類查詢進行物理隔離，解決了該問題。
– Doris在0.11版本時FE的MySQL服務IO線程模型較為簡單，使用一個Acceptor+ThreadPool來完成MySQL協議的通信過程，單個FE節點在並發較高（2000+qps左右）的時候會出現連接不上的問題，但此時CPU佔用並不高。在0.12版本的時候，Doris支持了NIO，解決了這個問題，可以支撐更高的並發。也可以使用長連接解決這個問題，但需要注意Doris默認對連接數有限制，連接佔滿了就無法建立新的連接了。
7、總結
通過一年多時間的生產環境使用，Doris滿足了我們日常使用的需求，並通過了多次大促的考驗，證明了其在廣告效果數據場景下適用性，和高並發場景下的可靠性。在日常使用中，其良好的設計也大大降低我們的維護成本，縮短了我們日常業務的開發時間。Doris已經成為了京東廣告的核心系統之一。
當前Doris已經逐漸成熟，其周邊的生態也越來越完善，未來可以在更多業務場景下進行嘗試。Doris研發團隊的核心成員組建了鼎石科技，不僅對Apache Doris有更強的支持，而且他們研發的企業版產品，相對於開源版本功能更加完善，性能也更加卓越。在使用Doris的過程中，鼎石科技的小夥伴們也給予了我們很大的幫助。
未來，我們會進一步探索Doris在廣告其他方面的應用，包括廣告物料數據方面等。期待Doris的功能和性能進一步提升，最終成為解決數據分析問題的統一平臺。