以下文章來源于PolarDB ，作者淵雲、晉北
客戶推薦語錄
阿裡雲瑤池旗下的雲原生資料庫PolarDB PostgreSQL版的存儲具備彈性擴容能力，最大可支援100TB存儲空間。它的大表優化和彈性跨機并行查詢（ePQ），成功解決了社群PostgreSQL針對大表的查詢和并發更新慢的問題。在小鵬汽車的智能輔助駕駛業務上，實作了每日TB級大資料表的7000萬行更新和大資料表秒級分析查詢。
——小鵬汽車智能輔助駕駛SRE負責人
1、客戶介紹
1.1 關于小鵬汽車
小鵬汽車是中國領先的智能電動汽車公司，緻力于為對技術充滿熱情的消費者設計、開發、制造和營銷智能電動汽車。公司的核心使命是通過科技驅動智能電動汽車的變革，引領未來的出行方式。為了提升客戶的駕駛體驗，小鵬汽車投入了大量資源自主研發全棧式智能輔助駕駛技術、車載智能作業系統，以及涵蓋動力總成和電子電氣架構的車輛核心系統。
1.2 業務場景
智能輔助駕駛是小鵬汽車的重點技術方向，每天有海量的圖檔、視訊資料采集上傳。有海量的資料存儲在對象存儲中，同時還需要在關系資料庫中針對每個檔案生成一條“目錄”，以便批量地查找和管理檔案，記錄檔案的位置、屬性、名額等。這就導緻了這個“目錄”要覆寫到全量的資料檔案，即資料庫的超大單表，并且随着名額的變化要經常進行表的全量資料更新。
2、遭遇瓶頸——海量資料的考驗
小鵬汽車原先使用的資料庫是社群PostgreSQL，随着智能輔助駕駛業務的快速增長，系統面臨資料處理的三重挑戰：
2.1 大表查詢慢
面對海量資料，單機并行處理能力已經達到極限，無法應對TB級大表的查詢，小鵬汽車的智能輔助駕駛分析業務承受前所未有的壓力。小鵬汽車資料中心最龐大的資料表體量已攀升至7 TB，而超過TB級别的資料表數量更是多達四張。當大表的分析查詢時間達到數十分鐘甚至數小時時，這一資料處理瓶頸已成為制約智能輔助駕駛業務的關鍵難題，迫切需要一種新的技術解決方案來破解。
2.2 大表頻繁更新
在小鵬汽車的标注業務中，面臨着一個日益嚴峻的問題：TB級大資料表每天的更新量高達7000萬行。這一龐大的資料流量引發了一系列的問題，尤其是在TB級大表更新過程中，過多的檔案校驗作業導緻了檔案系統的IOPS達到極限，進而導緻了系統性能的急劇下降。最終，這種過載使得單行資料更新耗時達到分鐘級，進而觸發資料庫雪崩，對公司的業務營運構成了直接的威脅。
2.3 存儲空間快速增長
資料庫總容量飙升至30 TB并且以每月2 TB的驚人速度持續增長。社群版的PostgreSQL資料庫面臨着一個嚴峻挑戰：它無法實作自動化的擴容。這樣迅猛增加的存儲需求正急劇逼近系統的極限，成為了一個亟待解決的難題。
3、突破僵局——PolarDB的方案
随着資料量越來越大，社群版PostgreSQL遇到性能瓶頸，資料處理鍊路産生堆積，尤其是資料批量更新更是成為卡點，影響智能輔助駕駛研發效率。針對現狀和PostgreSQL生态相容性考慮推薦客戶測試雲原生資料庫PolarDB PostgreSQL版（PolarDB PostgreSQL版，簡稱為 PolarDB-PG），在相容現有業務代碼的同時，解決單機資料庫的性能瓶頸，提高研發效率：
3.1 ePQ加速TB級大表分析查詢
ePQ是Elastic Parallel Query（彈性并行查詢）的縮寫。PolarDB-PG通過ePQ優化器，生成能夠被多個計算節點并行執行的執行計劃。ePQ的執行引擎将在多個計算節點上協調執行該計劃，同時利用多個節點的CPU、記憶體、I/O帶寬來掃描和計算資料。PolarDB-PG ePQ的架構示意圖如下所示：
基于此架構，PolarDB-PG的ePQ相較于社群PostgreSQL有如下優勢：
- 極緻的分析查詢性能：1TB TPC-H測試平均提升23倍性能，性能可随并行度、節點數線性提升。
- 業務完全透明：無須修改任何業務代碼，僅需在控制台打開polar_enable_px開關即可使用ePQ。
- 一體化存儲：TP/AP共享一套存儲資料，減少存儲成本。TP高壓力寫入下，AP引擎提供毫秒級資料新鮮度。
3.2 大表優化解決大表頻繁更新問題
▶︎ 客戶業務問題
在小鵬汽車的場景下，單表的大小達到TB級别，最大可達到7 TB。業務側采用短連接配接 + 高并發（> 400）更新的方式來通路TB級大表。在這種情況下，大表的檔案通路操作（例如 open/lseek）會将整個資料庫的IOPS打滿，IO時延飙升，觸發資料庫雪崩。
▶︎ 原因分析 ️
在社群PostgreSQL中，每張表的檔案都是以Segment為機關來進行存儲，每個Segment大小為1GB。在如下三個場景需要使用open/lseek檔案通路操作來擷取檔案大小：
- 刷髒操作：在髒頁寫入情況下，需要定位每一個髒頁需要寫入的具體位置。這個時候，需要打開寫入頁面前所有的segment檔案，通過lseek擷取所有segment檔案大小并求和，最終，check髒頁寫入位置正确。
- DML引發的表擴充：在Insert/Update過程中，如果找不到空閑頁面，會進行表擴充。表擴充的時候需要擷取目前表的大小用來定位表擴充後的位置，擷取目前表大小需要逐個open/lseek segment檔案。
- 優化器進行代價估計：優化器在對普通表進行代價估計的時候，需要擷取表大小用來判斷采用seqscan還是indexscan。擷取目前表大小需要逐個open/lseek segment檔案。
小鵬汽車智能輔助駕駛場景下， 7 TB的大表意味着7000個Segment檔案，每次對大表進行刷髒或者表擴充的時候，單次檔案寫入操作會被放大成7000個Segment檔案長度校驗。同時業務側還是采用短連接配接 + 高并發的方式通路大表，意味着檔案句柄無法緩存，隻能采用檔案操作（open/lseek）來通路Segment檔案長度，最終大表的海量檔案通路将整個資料庫的IOPS打滿，IO時延飙升，觸發資料庫雪崩。
▶︎ 解決辦法
PolarDB-PG用如下三個方法解決了大表寫入問題：
- 二分查找擷取表大小：在檔案擴充或者優化器代價估計。社群PostgreSQL擷取表檔案大小，需要逐個擷取每個segment大小，複雜度為 O(N)；PolarDB-PG優化過後，按2的倍數依次打開segment檔案（例如 0、1、2、4、16、32....），直至檔案不存在，鎖定檔案大小區間，例如[64,128)。然後在 [64,128)二分查找segment N存在并且 N+1 不存在，最終檔案的大小鎖定為(N-1)*segment_size + 第 N 個 segment大小（segment_size為1GB）。經過優化後，表檔案大小擷取的複雜度由 O(N) 降低至 O(logN)。
- 減少備援檔案校驗：社群PostgreSQL在刷髒寫入一個頁面的時候，需要逐個打開之前所有Segment檔案計算頁面寫入位置資訊，檢查頁面寫入位置資訊正确。PolarDB-PG優化過後，在保證資料正确性的基礎上，減少備援的檔案校驗，僅擷取 SegN-1和SegN兩個檔案大小。
- 表大小緩存（Relation Size Cache）：PolarDB-PG設計的表大小緩存，會在優化器進行代價估計的時候優先采用緩存，而不是通過IO擷取檔案大小。
3.3 存算分離實作彈性擴容
▶︎ 客戶業務問題
小鵬汽車的PolarDB-PG執行個體資料量達到30 TB，并且以平均每月2 TB的速度在增長。基于ECS自建的PostgreSQL資料庫已無法應對資料增長的需要。
▶︎ 解決辦法
PolarDB-PG基于存儲計算分離的架構，PolarStore存儲叢集可獨立擴充，支援彈性擴容，存儲按量進行計費，最大支援100 TB存儲，PolarStore存儲叢集的讀寫帶寬穩定在1.6 GB/s以上。大容量 + 高帶寬確定PolarDB-PG的 IO 和存儲空間不成為瓶頸。
4、迎接轉機——系統性能的蝶變
4.1 大表分析查詢速度提升3.6倍
以資料統計業務為例，大表（這裡簡稱為 xxx）的表大小為7.6TB，通過如下語句查詢：
select count(1) as cnt from xxx where create_time>='2024-03-19 01:00:00' and
create_time<'2024-03-19 02:00:00'; 未使用ePQ查詢，采用原生單機并行查詢，并行度為6，執行時間為66秒。
采用ePQ 2個RO節點，24并發查詢，執行時間可降低至18秒。
采用ePQ跨機并行查詢相較于單機并行查詢速度可提升3.6倍，能達到查詢性能随并行度線性提升。再增加隻讀節點，查詢速度仍可繼續提升。
4.2 資料等待事件降低至幾乎為0
下圖展示了檔案系統seek和open iops的變化，紅線左側是優化前的表現，紅線右側是優化後的表現。
優化前：整體的open/seek iops達到30000 ～ 40000。
優化後：整體的open/seek iops達到5000 左右，減少80%的iops數量。
如下圖所示，圖中的每一項表示資料庫在運作過程中的等待事件總量。由原來平均 600+的FileOpen/FileSeek等待事件，優化到後面幾乎沒有FileOpen/FileSeek等待事件( < 1)。
優化前：
優化後：
4.3 存算分離實作彈性擴容
下圖展示了小鵬客戶的總資料量和7天内資料增長量。總資料量達到37 TB級别，資料增長量峰值達到每7天1.5 TB，平均以每月2 TB的速度增長。但PolarDB-PG的存儲空間不成為瓶頸。
下圖展示了小鵬汽車智能輔助駕駛業務在業務高峰期的IO讀寫帶寬，穩定在1.6 GB/s 以上。PolarDB-PG的高讀寫帶寬確定智能輔助駕駛業務在高峰期正常運作。
5. 總結
PolarDB-PG的自動彈性擴容、大表優化和彈性跨機并行查詢已經成為小鵬汽車智能輔助駕駛業務應對TB級别大表标注、分析查詢的"利器"。同時，PolarDB-PG針對大表的高性能解決方案也可以更好地滿足類似汽車領域内智能輔助駕駛業務的資料庫通路需求：
- 支援TB級别大表的秒級分析查詢；
- 支援TB級别大表每日7千萬的頻繁标注更新；
- 提供100 TB的存儲空間、存儲彈性自動擴容、按量付費方式；
- 所有大表優化對業務完全透明，無需業務修改，省去開發和運維負擔。