分享嘉賓：李海波 京東 OLAP架構師
編輯整理：梁旭艷作業幫
出品平臺：
導讀：京東OLAP采取為主Doris為輔的策略，有3000臺服務器，每天億次查詢萬億條數據寫入，廣泛服務于各個應用場景，經過歷次大促考驗，提供了穩定的服務。本文介紹了在京東的高可用實踐，包括選型過程、集群部署、高可用架構、問題和規劃。
01應用場景和選型
京東數據分析的場景非常多，在交易、流量、大屏、用戶分析和算法等多場景中采用到了OLAP技術。那么在應用中有遇到什么樣的難點，應對這些問題如何做的技術選型和最終方案呢？
1.京東OLAP的場景的難點
交易數據：零售的訂單和財務數據，查詢需要多表關聯和大量的精確計算，數據字典和組織架構的變化會涉及回溯歷史數據，如三元組中，崗位會頻繁變化，變化之后需要按照最新崗位去查詢相關訂單的數據，崗位和SKU的量還比較大，如果是大寬表則歷史數據都要更新，如果是關聯表則關聯查詢性能是一個較大的問題。
流量數據：流量數據包含瀏覽和點擊，數據量大，查詢時掃描數據量大，精確去重/近似去重/分組計算量大，大查詢會導致資源消耗比較多，如果并發較大，集群資源會存在瓶頸。
用戶分析：在分析場景涉及到像留存率、轉化漏斗等計復雜的數據計算模型，分析的維度并不固定因此也無法做預計算，分析覆蓋的數據周期較長，明細數據的大查詢較多。
大促大屏：每次大促時作戰指揮室有大屏輪播展示各類核心指標，一塊屏上需要展現很多指標，SQL多并發較大，數據都是亞秒級實時變化，另外大屏對可用性的要求也很高。
2. 多維分析組件選型考察方面
上面我們介紹了OLAP技術在京東一些場景中的難點，基于眼前的這些問題，那么在多維分析中通過哪些考量來做OLAP組件的選型呢？
海量：是衡量OLAP最基礎的指標，擴展性要好，是否可以支持單集群百臺以上服務器，支撐每天百億+的數據分析計算。
適應性：選擇的組件可以覆蓋到大部分的分析場景，不需要通過增加其他額外的組件來支持多樣化的業務需求，致使架構的復雜性提升。
靈活性：能夠在任意維度上進行組合，靈活的調整數據指標，動態增刪列，很好的響應業務需求。
時效性：比如做到分鐘級/亞秒級端到端數據延時，讓相關人員能夠即時的看到決策效果，并做響應的調整。
3. 京東OLAP組件實施思路
在對OLAP組件考量和調研之后，和大多數公司一樣選用主流的和Doris作為京東內部主要的OLAP引擎，因為性能、擴展性和穩定性較好，而Doris在可維護性和易用性方面更好，所以在生產中選擇了以為主Doris為輔的策略，形成高低搭配。同時，針對開源產品后臺功能不強的情況，通過自研管控面來進行集群管理，用戶自助式操作，降低了運維成本，降低了用戶的使用門檻。
02集群部署
集群部署方面主要是通過業務隔離、多租戶配額、機型適配和靈活部署方案來運維高可用的集群。規劃合適的集群規模是第一個需要考慮的問題，我們通過綜合對比后選擇了小集群多租戶的模式。集群部署主要有三大模式：大集群、獨立集群和小集群。
那么在小集群多租戶模式中又是怎樣實現高可用的呢，在這還是以下面四點展開：
物理隔離：根據不同業務特點、業務場景通過部署多個集群實現物理隔離，避免業務相互影響，同時資源使用上可以互補。
① 分析性查詢和日常報表隔離。分析性查詢涉及到大查詢和時間跨度比較大的查詢，占用大量的資源，可能會影響到其他業務，這兩部分業務盡量不要放在一個集群中。
② 高并發和低延遲場景隔離。因為高并發會大量占用集群 CPU 和內存，影響其他業務的查詢和寫入；低延時隔離，低延時指數據需要秒級寫入，會有大量小文件寫入，在數據合并中壓力比較大，影響其他業務的寫入。
③ 業務級別隔離。重要業務需要更高的保障確保高可用，避免因為一些低優先級的業務占用資源導致高優業務出現事故，也可以低優和高優搭配，在集群資源不足時，通過對低優降級支援高優業務。
④ 實時和離線隔離。像離線主要是大存儲，大數據量寫入時耗費磁盤資源和IO性能，而實時往往是大數據的計算CPU使用率比較高，如果實時和離線的使用量并不是很大，也可以混布，這樣可以充分利用資源。
多租戶配額：為了保證集群的穩健、業務的高可用、提升資源的利用率以及降低業務間的相互影響，我們通過多租戶、配額和權限管理進行限制。我們的目標是通過配額來限制非預期的行為，特別是錯誤的使用導致集群不穩定。
① 系統限制：設置服務最大內存不超過服務器物理內存的80%，集群總的并行的Query數為CPU核數的2-5倍，避免內存資源不足導致OOM和CPU 負載過高。
② 查詢大小：從內存占用、所需的線程數和查詢耗時上限制，設置單個的查詢占用內存資源為系統資源的20%，單個Query的線程數為CPU核數的20%；查詢時長10-30s，寫入時長60-180s。
③ 查詢次數：限制并發查詢數，比如5/節點；或者為了保證高峰數據的穩定性，可以限制20個query/節點/10秒。一般是并發數和query數同時限制。
④ 我們針對賬號進行了分離，比如同一個業務分為查詢賬號、導數賬號、下載賬號，對各種賬號分別設置配額，同時，針對配額我們也是嚴格先壓測在設置符合業務實際需要的配額。
⑤ 讀寫分離和SQL追蹤，在每個SQL的前面有一段/**/的跟蹤ID是上層生成的，中包含產品、模塊、功能、接口等信息，通過我們很容易找到慢查詢、錯誤查詢等SQL的位置。
機型適配：OLAP中既有存儲又有計算，是計算和存儲都密集型，離線和實時的場景對機型性能的要求不同，所以按需選擇不同的機型，做到資源的合理搭配。
① 資源類型配比要合理。不同場景資源類型的需求是不一樣的。按照我們的經驗，計算量大的業務，選擇CPU核數多主頻高的，比如分組和去重的計算；數據保留時間長的業務，磁盤空間則需要大；如果使用字典，數據需要加載到內存，則需要考慮大一點內存。一般來說有一個基線的配置如CPU32核內存64-128G磁盤2-10T。
② 離線推薦HDD磁盤。在離線場景中，需要存儲數年的數據，存儲空間占用大，一般采用普通機械磁盤，數據在外部排序順序寫入，磁盤寫入速度和IO都能滿足要求。使用HDD磁盤時，需要堅持小批次大批量的原則，盡量降低小文件對系統的負擔，采用大容量的磁盤，一個好處就是可以做一些物化視圖，來提升查詢性能，以空間換時間。而實時場景，我們一般選擇SSD或NVME，隨機寫入能性能好，可以低延時高頻寫入小文件，能獲得更低的數據延時，更低的IO繁忙率。
③ 優先選擇單機性能高。分組或去重計算，需要把全部或部分數據匯聚到少量實例中，然后在匯聚實例中計算，依賴單節點的計算性能，集群相同核數的情況下優先選擇CPU核數多和主頻高的，比如32核的10臺和64核的5臺，后者在某些場景下計算性能更優。
部署方案：支持多副本、多實例、多磁盤集群部署
① 如何確定分片、副本數。根據業務存儲的量級進行預估分片的數量，盡量讓每個分片數據大小控制在在1-10G左右（1M-10M/條），每個分片的磁盤空間不要超過60%；為了保證數據的可靠性，通過配置多副本的方式避免單點故障造成數據不可訪問，建議副本數是2個以上、一個副本QPS 大概是10-300，如果QPS特別大，則需要更多的副本，我們單集群QPS最高能達到2000。
② 流行的CH部署方是單實例的，比如5分片2副本，需要10臺服務器，每臺服務器部署一個節點，如果查詢并發少CPU和內存會有浪費。因此，我們采用多實例多副本的部署模式，如下圖4臺服務器，我們部署了4分片和2副本，當然我們天然也支持單實例多副本的模式。
③ 怎么支持橫向擴容。通過增加副本的方式提升實現高可用，增加分片的方式提升寫入和讀取效率，也可以通過掛載的方式擴容磁盤。增加副本可以把新副本放在新的機器上，達到每個分片的副本數量一致即可。增加新的分片，可以增加Node5和Node6，然后類似Node1和Node2的副本間交叉備份的，就可以增加S5和S6。
03高可用架構
通過業務側規避，架構升級，管控面研發和雙流，提升OLAP的高可用性，在京東特別是大促可用性要求很高，有些業務要求5個9左右，但是仍然可能遇到有些挑戰，那么我們在架構上需要做哪些努力呢？
1. 單集群高可用架構
硬件故障是無法避免的，因此如何做到在硬件故障時用戶使用上無感知是我們努力的方向。我們部署的CH集群在架構上劃分為3層：DNS域名解析、CH代理層、CH集群節點。
應用層通過JDBC/HTTP方式域名進行請求，DNS域名解析后將請求打到，根據路由規則做請求分發，即實現了無感知上線下線CH節點同時實現了負載均衡，通過的負載均衡和流量分發，我們支持了日均6000億條數據寫入的集群。
Panel 集中化管理創建物化視圖權限不足，負責賬號的申請、集群部署、擴容、節點上下線、遇到故障時節點的替換以及提前預警告知等。
來負責分布式DDL元數據的更新和副本同步，故障發生時能夠盡快的修復，在集群部署時盡量CH集群一一對應，避免在大規模情況下 共用出現性能瓶頸，一般一個集群是3-5個節點。
負責集群數據遷移工作，我們一般使用目標集群的來同步源集群的數據。
2. 掛掉一個節點在各種情況下的影響
數據安全，因為是多副本部署，數據有最少一個的備份，掛了一個副本，數據也不會丟失。
查詢時，會轉發到健康節點，故障節點不會收到查詢請求。另外，接收查詢節點對副本有策略，比如輪詢、隨機等，同時使用的邏輯，會對副本進行排序，執行子查詢計劃時會把子查詢發給優先級高的健康副本，故障節點也不會收到子查詢請求。
寫入時，情況稍微復雜，如通過域名來寫分布式表或隨機寫本地表和查詢的機制類似。如果指定分片寫入本地表，可以在QUERY中指定分片序號，會轉發寫入到指定分片的某個副本上，同樣會跳過故障副本節點。的機制是任一副本寫入成功，其他副本會自動同步數據。
DDL操作，當節點掛掉之后故障節點上的DDL操作會失敗，拋出異常。有兩種方案，一種是不用ON ，自己遍歷每個節點執行DDL，如果執行失敗先記錄，等節點恢復了再重新執行一遍，另一種是先下線故障節點，等修復后再上線，或者備用機先進行替換。DDL操作的處理所需的工作量最大。
3. 節點下線、上線、替換
前面說到了節點掛掉后產生的影響，這塊看下如何實現節點替換和上下線。
節點下線：修改配置文件，刪掉要下線的節點信息，并且下發到所有節點進行通知，節點會重新加載配置文件，完成節點下線，如果是永久下線，還需要清理中的該節點的副本相關信息。配置下發用salt或，節點清理可以自己寫一個工具遍歷zk路徑。
節點上線：同樣將上線的節點信息配置到集群中并下發通知其他節點，但是因為新上線的節點沒有元數據信息，因此需要通過工具將 中其他副本的元數據信息同步過來。
節點替換：在節點上線步驟的基礎上，看看如果新節點的IP有變化，也需要在 中進行更新或者增加。
這有一個通用的節點故障處理流程，即確定是否可以恢復；如果不可恢復，進行節點的下線，可恢復的情況下，定位原因嘗試修復，修復完事后進行上線，或者不可修復進行節點的替換。節點上下線和替換，因為步驟較多，手工操作工作量較大，整個過程我們自動化了。
4. 雙活集群方案
當集群中但節點故障，我們可以快速的下線節點保證業務的正常，如果發生整個機房的故障問題，需要長時間的排查修復，我們同樣有集群雙活的保障，分鐘級的切換備用集群。
因為雙活機房間數據目前離線是通過Spark同時向兩個集群寫入數據，實時是通過Flink 消費雙寫兩個集群 ，只能保證數據的最終一致性，這種方式對于業務端比較復雜，所以關于能否實現OLAP集群間的雙寫，通過分布式共識機制同步雙集群群副本，通過域名切換集群，這是未來我們要考慮的一個工作。
5. 參數優化 – 系統、、
京東的場景多數據量大，遇到的問題也多，我們做了大量測試和試驗，調整了很多參數包括Linux系統、和JVM、的調優，通過優化這些參數，可以讓集群處于一個高性能穩定運行的狀態。如按列存儲，小文件比較多，inode數量需要改大一些；如這個參數避免內存超過限制；如zk中的參數優化會讓不那么頻繁出問題，可以參考官方的配置。
04問題和規劃
1. 常見問題和解決方案
系統問題：包括通過設置CK內存解決OOM問題；在硬件資源遇到故障時快速的下線節點；注意在Part文件太大時內存文件Cache 會失效。
導數問題：太頻繁/Part數太多/分區太多都會導致小文件問題；分布式表寫入性能差，數據分發太慢；導數分區不合理Znode數量大；數據字段更新，選擇合適的表引擎和方案。
元數據和ZK：DDL卡住/失敗可以增加增加DDL線程數解決；ZK和CH元數據不一致，通過輪詢檢查和修復腳本進行保障，控制Znode規模避免因數量太大引發的超時問題；還有就是在遷移數據ZK壓力較大，需要重點關注。
查詢問題：CPU不均勻，造成流量分發不均勻和數據傾斜；在查詢中通過改寫子查詢，本地join 以及物化視圖的方式改進性能不好的Join查詢；大查詢的影響，通過Quota限制，命中索引；當并發太大，CPU太高，通過增加Cache的方式緩解。
并發能力，因為CH是MPP架構，分布式表的查詢會分發到所有節點去執行，每個分片的節點都會參與計算，并發能力和單機是一樣的創建物化視圖權限不足，增加副本可以提升并發能力。另一方法是提升單個查詢的查詢性能，比如通過改寫SQL、物化視圖或者字典表的使用降低查詢時間。在查詢時間優化到幾十毫秒以內，增加副本數可以讓QPS達到數千甚至上萬。
Join優化，CH的不夠自動化，很多SQL需要顯式的指定執行順序和優化參數。我們之前做過的TPC-DS的測試，大部分多表Join的SQL都需要改寫，比如把Join改為子查詢，改為本地表Join，設置去做分布式等，改寫之后的性能比較好，但大表和大表的Join在右表數據量達到千萬級別之后，性能會急劇下降。
2. 架構問題 – 瓶頸
和是一種松散耦合的架構，執行DDL操作時，每個節點是輪詢DDL隊列去執行，執行完畢后設置標記，接收到SQL的節點輪詢狀態直到所有節點執行成功然后返回給客戶端，這種模式和大部分有節點的分布式系統稍有不同，如Kudu和Doris。
存在性能瓶頸，存儲了表元數據、副本、Part信息、Merge和日志以及DDL隊列，Znode數量是隨文件數量而增長的，如果Znode數量太大，GC時卡頓導致操作延時較大，Znode應當小于2000萬左右，吞吐量的瓶頸3w/s左右。理論上，是可以通過不同節點訪問不同的ZK集群來分散壓力，但是這種方式較為復雜。
分布式能力偏弱，如果用過Doris之后，再來看的分布式能力的話，在節點管理、元數據管理、事務管理、彈性伸縮等方面較為簡陋，需要做大量的工作去運維。比如在Doris中，可以通過SQL命令增加、退休和刪除節點；后臺同步元數據讓元數據在節點中始終保持一致；兩段提交的事務機制，保證數據導入的原子性；同時擴縮容，后臺會自動同步文件，讓集群中的數據處于均衡狀態。
3. 架構問題 – 擴縮容的問題
主要是擴副本和擴分片進行擴容，前面已經簡單介紹過：
橫向擴副本：直接修改配置文件，增加副本信息，然后在手動的注冊，之后臺專門的線程會將主副本數據進行同步，操作時應該按分片逐步滾動操作，避免同時同步數據壓力太大。
縱向擴分片：也擴副本方式類似，分片比較好擴展，但是擴分片之后舊分片數據沒法自動均衡，這塊社區也正是在改進，我們有計劃在社區基礎上，進行工具化研發，能夠在后臺在線進行數據均衡。
4. 未來規劃
短期：統一的元數據管理
為了解決上面的問題，我們目前正在開發基于Raft分布式共識算法的替代方案，一方面是提升吞吐量和容量，另一方面是需要和結合更加緊密，保存更多元數據類型以增強CH的分布式能力，比如節點狀態，元數據管理，副本、分區和文件信息，并在此基礎上形成彈性擴縮容的能力，集群遷移和備份恢復能力，以及跨數據中心數據復制能力。
中期：OLAP管控面加強
在使用CH和Doris的過程中，特別是大促的經歷，讓我們積累了大量的運維和故障處置腳本，我們正在把這些腳本進行產品化，讓用戶自助式使用OLAP，如資源申請，創建用戶和庫，自助式的監控報警，異常處理和性能診斷，對管理員側，做到集群部署和管控，以及故障自動診斷和治愈。管控面的產品化，降低了運維的工作量，提升了人均可維護的集群和機器數量。
長期：云原生的OLAP
在容器化部署的同時，進一步實現云原生，利用HDFS和對象存儲的優勢，甚至可以和數據湖對接，把存儲層放到外部，避免數據的重復存儲，節省導入時間，計算節點可以彈性擴縮容。存儲分離出來之后，存儲如何擴縮容，以及計算節點和存儲分片之間如何映射，本地數據如何緩存等都是新的問題，這塊需要繼續研究。
其他方面如查詢優化、分布式緩存、易用性提升等也都在規劃之中。截止目前為止，京東OLAP集群的規模有將近3000臺服務器，每天8千萬次查詢，1萬億條數據寫入，總計3PB的數據規模，覆蓋交易、流量、算法等場景，同時我們也積極參與和回饋社區。京東OLAP采取了和Doris雙引擎策略，兩個引擎都有深度使用，近期會發布深度詳細的對比文章，從內核、性能、功能到運維都會涉及，敬請期待。如果探討相關問題或想加入京東OLAP團隊可以聯系。