如果你打算評估一個數(shù)據(jù)倉庫或者分析型數(shù)據(jù)庫能不能扛住真實業(yè)務那 TPC-DS 基本是繞不開的壓測工具。它不只是一堆 SQL 腳本而是一套完整的決策支持基準規(guī)范模擬零售行業(yè)幾十張表的數(shù)據(jù)模型再加上 99 條非?！暗筱@”的分析型查詢用來檢驗數(shù)據(jù)庫在海量數(shù)據(jù)下的掃描、關(guān)聯(lián)、聚合、窗口計算等綜合能力。但很多人第一次接觸 TPC-DS 時卡住的不是后面的測試而是最前面的編譯安裝。TPC-DS 不像 k6 這類壓測工具下載個二進制就能跑它給的是 C 源碼包使用前必須自己編譯出dsdgen和dsqgen兩個工具這里面的坑其實不少。這篇內(nèi)容我會從“第一次在 Linux 上完整把 TPC-DS 跑起來”這個視角出發(fā)把編譯安裝的前因后果、完整步驟、驗證方法以及我實際踩過的幾個編譯運行問題全部寫清楚。無論你是剛開始研究壓測工具選型還是已經(jīng)被 make 報錯折磨到懷疑人生這篇都有參考價值。1. 先理解TPC-DS壓測工具到底是測什么的1.1 它是一套針對分析型場景的“標準考卷”很多人第一次聽到 TPC-DS 會把它和 TPC-C 混淆。TPC-C 壓的是聯(lián)機交易系統(tǒng)場景是大量短事務、高頻寫入、行級查詢而 TPC-DS 壓的完全是另一類負載數(shù)據(jù)倉庫里的復雜報表分析、多維聚合、ETL 之后的數(shù)據(jù)探索。TPC-DS 的模型來自一個模擬零售商的業(yè)務系統(tǒng)整體上由 24 張表組成其中包含 7 張事實表和 17 張維度表。事實表里存儲的是 store_sales、store_returns、catalog_sales、web_sales 這類大規(guī)模銷售或退貨流水維度表則描述商品、客戶、地區(qū)、時間、促銷渠道等信息。這個模型的最大特點是它故意設(shè)計成了類似真實數(shù)倉的雪花模型或星型模型數(shù)據(jù)表之間有很深的關(guān)聯(lián)路徑字段類型也覆蓋了數(shù)值、字符、時間等常見類型還有大量的 NULL 值、邊界值、數(shù)據(jù)傾斜場景。在查詢負載上TPC-DS 提供了 99 條不同的查詢模板。這些查詢不是簡單SELECT *而是會混合出現(xiàn)多表 JOIN、嵌套子查詢、group by 聚合、窗口函數(shù)、case when 條件分支、日期運算、集合操作等。比如一條查詢可能先從 web_sales 里篩出某個時間段的數(shù)據(jù)再去關(guān)聯(lián) customer 維度、item 維度、promotion 維度最后在多個維度層級上做聚合比較。想跑得準又跑得快數(shù)據(jù)庫的優(yōu)化器、執(zhí)行引擎、統(tǒng)計信息、存儲格式都必須足夠能打。所以我在實際交流時經(jīng)常把它形容成一場“分析型 SQL 的統(tǒng)一考試”TPC-C 相當于測試收銀臺能不能快速處理結(jié)賬TPC-DS 則是在考商業(yè)分析團隊能不能從千萬行流水里快速算出一份經(jīng)營報告。后面如果要給數(shù)據(jù)倉庫、分析型數(shù)據(jù)庫、湖倉引擎做橫向?qū)Ρ萒PC-DS 是一個非常通用的參考基準。1.2 為什么大家都愿意把 TPC-DS 當成壓測標尺判斷一個壓測工具值不值得用主要看三件事場景是否貼近真實、結(jié)果是否可復現(xiàn)、流程是否被行業(yè)認可。TPC-DS 在這三點上做得都比較到位。它有嚴格的規(guī)范去約束數(shù)據(jù)生成方式、查詢執(zhí)行方式、結(jié)果校驗方式尤其是數(shù)據(jù)生成的隨機種子、表的規(guī)模、SQL 參數(shù)替換規(guī)則都有明確要求。這一點很關(guān)鍵。我們在做數(shù)據(jù)庫選型時如果每個人自己隨手寫幾條 SQL 去壓測很難保證兩個數(shù)據(jù)庫跑的是同一套邏輯甚至同一條 SQL 在兩個庫里執(zhí)行計劃都完全不同。而使用 TPC-DS 統(tǒng)一生成的數(shù)據(jù)和查詢至少能做到“大家用的是同一套考卷”誰的成績更好一目了然。另外TPC-DS 是公開標準的測試負載不是某個數(shù)據(jù)庫廠商自己定義的測試工具。所以很多大廠在做技術(shù)分享時提到的“XX數(shù)據(jù)庫 TPC-DS 1TB 性能評測”大家心里會有個基本預期這是規(guī)?；?、復雜查詢、真實數(shù)倉模型下的結(jié)果而不是壓幾條簡單 SQL 給出的數(shù)字。作為用戶我們自己也可以按文檔跑出對應規(guī)模的數(shù)據(jù)驗證廠商成績是否“注水”。1.3 編譯安裝是進入正式壓測之前的“守門員”如果在搜索引擎里搜 TPC-DS大概率會發(fā)現(xiàn)它壓縮包里的代碼形態(tài)離“開箱即用”還有一段距離。TPC-DS 官方發(fā)布的是源碼包里面包含數(shù)據(jù)生成器、查詢生成器和模板文件。我們真正要用的核心可執(zhí)行文件有兩個dsdgen負責按照指定比例因子生成原始數(shù)據(jù)文件。dsqgen負責讀取查詢模板生成帶具體參數(shù)值的 SQL 腳本。這兩個工具都需要先編譯才能在當前 Linux 環(huán)境下運行。原因也很簡單TPC-DS 作為標準測試工具要適配不同操作系統(tǒng)、不同硬件架構(gòu)官方如果只給一個 Linux x86_64 的二進制那 macOS、Windows、ARM 環(huán)境就都用不了。更重要的是C/C 編譯出來的二進制對系統(tǒng)庫和 CPU 指令集非常敏感在一個老版本 glibc 上編譯、拿到新版系統(tǒng)未必能跑反之用太新的環(huán)境編譯再拿回老系統(tǒng)又可能因為缺少符號無法啟動。自己編譯雖然多一步但能保證工具和你當前測試環(huán)境完全匹配。我第一次編譯 TPC-DS 時也覺得這一步很沒必要后來才發(fā)現(xiàn)正因為它的編譯過程“有點原始”才逼著使用者把目錄結(jié)構(gòu)、參數(shù)文件、模板路徑都理解清楚。如果連工具怎么編譯、如何找依賴文件都不清楚后面生成數(shù)據(jù)、替換 SQL 參數(shù)時大概率也會一頭霧水。把這一步啃下來等于把整個 TPC-DS 的使用流程打通了一半。2. 編譯安裝前先解決三個環(huán)境細節(jié)2.1 首選 Linux x86_64但也要關(guān)注發(fā)行版差異TPC-DS 的工具集大部分教程和測試案例都默認在 Linux 上編譯執(zhí)行如果你是在云服務器、物理機或者容器環(huán)境里做數(shù)據(jù)庫壓測建議優(yōu)先選擇 Linux 發(fā)行版。Ubuntu/Debian、CentOS/Rocky、openEuler 這些發(fā)行版本身差異不大關(guān)鍵是能不能裝上編譯工具鏈。我在編譯時用的是一臺 Ubuntu 22.04 x86_64 服務器。為什么要強調(diào) x86_64因為 TPC-DS 的官方 makefile 對平臺有判斷邏輯Linux 下最常見的MACHINE和OS配置都是LINUX。如果你的機器是 ARM 架構(gòu)比如蘋果 M 系列芯片的 Linux 虛機那編譯參數(shù)可能要做額外調(diào)整不能完全照搬網(wǎng)上的命令。如果是在容器或者最小化系統(tǒng)里跑還要注意磁盤空間。TPC-DS 編譯本身占不了多少空間但后面用-SCALE生成數(shù)據(jù)時1GB 的規(guī)模并不是只占 1GB 就結(jié)束了。以 TPC-DS 的零售模型看維度表會膨脹事實表更大加上查詢過程和日志磁盤建議至少預留數(shù)據(jù)規(guī)模 3 倍以上的空間。我第一次在 / 根目錄空間很小的機器上跑生成到一半報 “No space left on device”后來只能重新?lián)Q數(shù)據(jù)目錄相當浪費時間。2.2 提前裝好編譯器、make 和解析器依賴早期 TPC-DS 工具包的編譯過程相對粗糙對新版 GCC 的兼容性并不是每次都理想但基本依賴還是那么幾類C/C 編譯器一般就是gcc和g。make用來解析 Makefile 并執(zhí)行編譯目標。flex和bison用于生成查詢模板解析器相關(guān)代碼。標準庫頭文件和基礎(chǔ)命令比如binutils、unzip。在 Debian/Ubuntu 系列上可以直接安裝全套apt update apt install -y build-essential flex bison在 CentOS/RHEL/Rocky 系列上可以這樣yum install -y gcc gcc-c make flex bison unzip為什么要單獨把 flex 和 bison 列出來因為 TPC-DS 里的dsqgen組件在編譯時可能會涉及模板解析代碼的生成。如果你沒裝這兩個工具執(zhí)行到一半可能會看到y(tǒng)acc或lex相關(guān)的報錯出錯后很多人會誤以為是系統(tǒng)缺了什么大依賴實際只需要補齊這兩個小工具。裝完后重新make clean再make即可。編譯器版本方面太老的 GCC比如 4.x編譯新版 TPC-DS 工具包時可能會遇到 C11 語法不被支持的問題。如果系統(tǒng)自帶的編譯器版本實在太老建議先通過發(fā)行版的軟件源安裝更新的編譯器或者直接在比較新的 Linux 發(fā)行版上編譯。壓測工具本身并不需要多高級的優(yōu)化重點是要保證編譯過程中語法兼容。2.3 源碼包獲取認準官方工具包別拿錯文檔在動手之前要先清楚去“哪里下載”。搜索 TPC-DS 時你會看到官網(wǎng)提供了兩種主要下載物TPC-DS 標準規(guī)范文檔PDF描述測試流程和管理規(guī)則。TPC-DS Tools 工具包zip 壓縮包里面才是數(shù)據(jù)生成器和查詢生成器源碼。我們編譯安裝時需要的是第二個也就是工具包。官網(wǎng)對工具包的下載做了一定訪問控制一般需要按頁面提示填寫信息后獲取下載地址。這個過程很簡單但需要注意別在命令行里直接使用某些臨時地址因為鏈接可能會隨會話過期。建議先用瀏覽器下載到本地確認 zip 包完整后再上傳到服務器或放行到測試環(huán)境。也有不少開源項目把 TPC-DS 的代碼做成了 GitHub 倉庫比如第三方維護的tpcds-kit它們的編譯腳本通常更友好甚至會自動 patch 掉一些官方源碼在 macOS 和 Linux 上的兼容問題。如果你只是想在內(nèi)部環(huán)境快速跑一版數(shù)據(jù)用這類第三方發(fā)行版也完全可以。但如果你要做正式的、可對外引用的性能測試那還是應該用官方發(fā)布包并且記錄好版本號因為不同版本在數(shù)據(jù)分布和查詢模板上存在差異混用版本會導致測試結(jié)果沒有可比性。無論是官方包還是第三方包解壓后第一件事不是急著編譯而是先讀一下 README 或者 docs 目錄下的說明。很多奇怪的問題其實在文檔里都已經(jīng)寫明白了只是大家習慣直接跳過。我在做這類工具安裝時習慣把源碼包頂層目錄列出來先把目錄結(jié)構(gòu)大致過一遍mkdir -p ~/tpc-ds cd ~/tpc-ds unzip TPC-DS_Tools_v3.2.0.zip cd TPC-DS_Tools_v3.2.0 ls -la看到tools、query_templates、specification這類目錄出現(xiàn)后就知道版本沒有拿錯。tools目錄里放著編譯源碼query_templates里放著 SQL 生成模板兩邊后續(xù)都會用到。3. 編譯安裝全流程從 Makefile.suite 到 dsdgen、dsqgen3.1 解壓后的目錄結(jié)構(gòu)與編譯參數(shù)設(shè)計TPC-DS 的源碼目錄結(jié)構(gòu)和很多傳統(tǒng)數(shù)據(jù)庫工具不太一樣它不是執(zhí)行一個./configure就能自動探測系統(tǒng)環(huán)境的而是需要你通過頂部的一個makefile.suite文件告訴編譯系統(tǒng)“我在什么操作系統(tǒng)上跑”。進入解壓后的根目錄通常會看到一個類似makefile.suite的文件它就像整套工具編譯的“總控面板”。tools子目錄下的 Makefile 會去 include 這個總控文件所以你在tools目錄里直接執(zhí)行 make 時真正讀取的編譯參數(shù)可能來自上層目錄。打開makefile.suite后最常見的需要確認的配置項是OS LINUX MACHINE LINUXOS告訴編譯系統(tǒng)當前的操作系統(tǒng)類型MACHINE告訴編譯系統(tǒng)當前的硬件/平臺類型。把這兩項都設(shè)置成LINUX對應 Linux x86_64 是最常見的默認配置。如果某些發(fā)行版默認沒有設(shè)置或者你在 macOS 上編譯就需要根據(jù)你看到的模板改成對應的值。這里我強調(diào)一下一定要檢查不要認為官網(wǎng)發(fā)的包默認就一定能編譯。有些版本默認值寫的是OS LINUX但如果之前有人在同目錄下改過編譯參數(shù)或者 zip 解壓時權(quán)限、換行符出了問題就會導致變量沒被正確識別。最常見的現(xiàn)象是 make 時提示某個平臺相關(guān)內(nèi)容找不到或者把非 Linux 路徑下的庫引入進來。遇到這種問題先回makefile.suite找原因往往比在 makefile 里硬調(diào)更有效。3.2 官方源碼的主目錄結(jié)構(gòu)與編譯入口以 TPC-DS 官方工具包為例解壓后的大致目錄層次是這樣的不同版本可能會略有差別TPC-DS_Tools_v3.2.0/ ├── makefile.suite ├── query_templates/ ├── specification/ ├── ETL/ └── tools/ ├── dsdgen.cpp ├── dsqgen.cpp ├── makefile ├── ...tools目錄是編譯的主戰(zhàn)場。進入該目錄后執(zhí)行make即可觸發(fā)編譯。但我不建議第一次就直接傻乎乎地make因為如果編譯失敗你會看到滿屏的 error 卻不知道從哪看起。比較穩(wěn)妥的做法是先把編譯日志保存下來再快速定位錯誤cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/tools make clean make 21 | tee make.log為什么要make clean因為如果之前有人編譯過、生成了舊的.o目標文件你修改了makefile.suite后這些舊文件可能不會自動全部重建造成一些非常“詭異”的鏈接報錯。執(zhí)行 clean 后再 make可以保證所有源碼都按照新的參數(shù)重新編譯。如果編譯順利你會在tools目錄下看到新增的dsdgen和dsqgen兩個可執(zhí)行文件。有的版本還會生成tpcds.idx等數(shù)據(jù)處理文件這些文件是運行時配套的不要手滑刪掉。3.3 make 過程中的實際輸出怎么看很多人一看到編譯輸出就緊張覺得幾十行 warning 就是有問題。其實 C 編譯里的 warning 很常見像“未使用變量”“隱式類型轉(zhuǎn)換”這類提示一般不影響工具使用。真正需要關(guān)注的是 error 級別的輸出也就是以error:開頭的內(nèi)容。我編譯時發(fā)現(xiàn)如果缺少 bison/flex報錯通常會指向某個.y或.l文件并提示找不到y(tǒng)acc或lex。如果缺少 g會直接提示g: command not found。如果把OS或MACHINE改成了一組不存在的類型make 時則可能提示某個-D宏沒有被定義甚至直接進入一個錯誤的編譯分支?？吹竭@些錯誤先對照第 2 節(jié)檢查環(huán)境再回頭檢查 makefile.suite效率會高很多。如果 make 過程中出現(xiàn)了非常長的找不到標準庫頭文件的報錯比如iostream: No such file or directory那基本可以確定編譯工具鏈沒裝全或者當前環(huán)境中 C 標準庫路徑?jīng)]配置好。此時不要盲目去修改源碼先執(zhí)行一下g --version確認 g 真實存在且版本可用再嘗試用包管理器補齊libstdc-dev或g。3.4 編譯產(chǎn)物確認與安裝到統(tǒng)一目錄make 成功后我建議先驗證一下產(chǎn)物能不能正常執(zhí)行cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/tools file dsdgen dsqgen ./dsdgen -helpfile命令能看到可執(zhí)行文件的格式如果是 64 位 ELF說明編譯出來的架構(gòu)沒問題。./dsdgen -help能打印出 dsdgen 支持的所有參數(shù)如果能看到那說明工具已經(jīng)可以運行。很多人編譯完就留在tools目錄里用這樣也沒問題但如果后面還要生成多份數(shù)據(jù)集或者要把工具提供給其他測試同學使用更推薦把工具集中復制到一個獨立目錄比如/opt/tpc-ds/bin或者用戶目錄下的~/tools/tpc-ds/bin。mkdir -p /opt/tpc-ds/bin cp dsdgen dsqgen tpcds.idx /opt/tpc-ds/bin/注意這里我要提醒一句dsdgen運行時不光要靠可執(zhí)行文件還需要tpcds.idx這類分布數(shù)據(jù)文件。如果你只拷貝了dsdgen和dsqgen運行時會提示找不到 DISTRIBUTIONS 文件。把tpcds.idx一起拷過去并把tools目錄里的數(shù)據(jù)文件路徑搞一致會省去很多麻煩?？截愅瓿珊罂梢园?opt/tpc-ds/bin加進PATH環(huán)境變量export PATH/opt/tpc-ds/bin:$PATH但注意這樣只是當前終端生效后續(xù)重新登錄會丟。如果希望長期生效可以寫到.bashrc或/etc/profile.d/tpc-ds.sh中。這一步雖然不是編譯本身但對后續(xù)壓測工具使用體驗影響很大。4. 編譯成功不等于能用功能驗證與數(shù)據(jù)生成流程4.1 先跑一個最小規(guī)模的數(shù)據(jù)生成任務工具編譯完自然要實際生成一份測試數(shù)據(jù)驗證一下。TPC-DS 的數(shù)據(jù)生成器dsdgen用一個叫SCALE的參數(shù)控制數(shù)據(jù)規(guī)模SCALE 1表示生成大約 1GB 的原始數(shù)據(jù)。之所以說“大約”是因為 TPC-DS 不是簡單按行數(shù)線性擴展而是按每個表的目標規(guī)模比例放大最終總大小接近 1GB。在執(zhí)行之前先建立一個數(shù)據(jù)輸出目錄例如mkdir -p /tmp/tpcds/data cd /tmp/tpcds/data然后回到tools目錄執(zhí)行cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/tools ./dsdgen -SCALE 1 -DISTRIBUTIONS ./tpcds.idx -DIR /tmp/tpcds/data這里有幾個參數(shù)需要解釋一下-SCALE 1數(shù)據(jù)規(guī)模倍率1 代表約 1GB。-DISTRIBUTIONS ./tpcds.idx指定分布數(shù)據(jù)文件路徑。如果dsdgen和tpcds.idx在同一目錄并且你在當前目錄執(zhí)行也可以省略但建議在腳本里顯式寫清楚避免路徑對不上。-DIR /tmp/tpcds/data數(shù)據(jù)文件輸出目錄。這個命令運行幾分鐘后就能在/tmp/tpcds/data下看到很多.dat結(jié)尾的文件。比如日期表、商品表、銷售表等。用wc -l可以簡單看看每個文件行數(shù)wc -l /tmp/tpcds/data/*.dat | tail -5 head -3 /tmp/tpcds/data/store_sales.datSCALE 1的 store_sales 數(shù)據(jù)行數(shù)一般會在幾十萬到百萬級別總文件看起來不大但對測試流程來說已經(jīng)能跑通全鏈路了。我建議新手第一輪壓測不要一上來就生成 10GB 或 100GB先用 1GB 驗證工具穩(wěn)不穩(wěn)、目錄路徑對不對、文件格式是否符合預期。確認沒問題后再根據(jù)被測數(shù)據(jù)庫的實際容量和對標場景放大規(guī)模。4.2 用 dsqgen 生成真正的壓測 SQL數(shù)據(jù)文件生成只是第一步。TPC-DS 的 99 條 SQL 并不是直接寫死的值而是放在查詢模板里。模板里有各種位置參數(shù)比如日期范圍、類別編號、客戶數(shù)量等需要運行dsqgen解析模板并替換成指定規(guī)模的隨機參數(shù)才能生成可供數(shù)據(jù)庫執(zhí)行的 SQL。生成 SQL 前確認你已經(jīng)進入解壓后的根目錄里的query_templates目錄因為dsqgen需要指定模板文件所在的目錄和模板列表。一個常見命令如下cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/query_templates ../tools/dsqgen -DIRECTORY . \ -INPUT templates.lst \ -DIALECT netezza \ -OUTPUT_DIR /tmp/tpcds/queries先創(chuàng)建好/tmp/tpcds/queries目錄。這里的-DIALECT netezza指的是“生成 SQL 的風格”。TPC-DS 的模板最初是為某一種特定 SQL 方言寫的不同數(shù)據(jù)庫在函數(shù)、類型轉(zhuǎn)換、字符串語法上有細微差異dsqgen會根據(jù) dialect 參數(shù)對模板內(nèi)部的部分語法做替換。如果被測數(shù)據(jù)庫不在官方支持的 dialect 列表里比較通用的辦法是先生成 netezza 風格或直接參考你的數(shù)據(jù)庫官方文檔里推薦使用的 dialect。生成后打開幾個 SQL 文件看看如果里面有特別數(shù)據(jù)庫不支持的函數(shù)可以在導入階段做統(tǒng)一替換或者在執(zhí)行前用文本處理腳本過濾。很多數(shù)據(jù)庫產(chǎn)品比如分析型數(shù)據(jù)倉庫都已經(jīng)兼容 PostgreSQL 或 MySQL 語法你可以按實際支持的語法做少量修正。4.3 如何判斷生成的查詢“能用”dsqgen執(zhí)行完成后會在輸出目錄里生成一個或多個 SQL 文件。不少人看到文件生成就覺得萬事大吉直接把整個 SQL 丟進數(shù)據(jù)庫執(zhí)行結(jié)果跑出來一片報錯。這里我建議執(zhí)行前先做兩層驗證。第一層是看 SQL 的規(guī)模對不對。用文本工具統(tǒng)計一下query_0.sql里包含多少個查詢正常情況應當接近 99 個如果少了要檢查模板列表是否完整。第二層是抽樣執(zhí)行。不要先跑全量而是從生成的文件中挑一個最簡單的查詢比如基于 date_dim、item 這類小表的查詢先單條執(zhí)行。這一步能快速發(fā)現(xiàn) dialect 選擇是否正確、字段名是否和實際表結(jié)構(gòu)匹配。確認單條 SQL 能跑后再逐步增加查詢條數(shù)最后才用并發(fā)或計時腳本跑完整 99 條。不要因為 SQL 是工具生成的就默認它一定能一次通過。4.4 完整的壓測數(shù)據(jù)鏈路長什么樣把數(shù)據(jù)文件和 SQL 文件都準備好后接下來就是壓測工具真正發(fā)揮作用的階段。常見做法是把.dat文件通過數(shù)據(jù)導入工具加載到被測數(shù)據(jù)庫表中表結(jié)構(gòu)和 TPC-DS 模型一致再把 SQL 文件里的查詢依次執(zhí)行或者使用一個外部腳本控制并發(fā)、記錄耗時和正確性結(jié)果。如果你用的是 PostgreSQL 系數(shù)據(jù)庫可以用COPY命令導入.dat文件。如果用的是其他分析型數(shù)據(jù)庫通常也有對應的導入指令或者直接用官方提供的 ETL 腳本把文本文件轉(zhuǎn)換為更適合批量加載的格式。這里有個容易踩的細節(jié).dat文件里字段分隔符是豎線|不是逗號導入時記得指定分隔符否則所有字段會擠到第一列導致建表、校驗全部錯亂。我第一次用 psql 的\copy導入時忘了指定 delimiter結(jié)果生成了一大堆錯誤數(shù)據(jù)排查了很久才發(fā)現(xiàn)是這么低級的問題。5. 編譯安裝和初運行中的常見問題與排查思路5.1 編譯階段的典型報錯對照表安裝 TPC-DS 的過程中編譯階段的報錯是最多的。我把實際見過的情況整理成了表格方便你在遇到類似問題時快速對照。報錯現(xiàn)象大概率原因處理方式g: command not found沒裝 C 編譯器安裝gcc-c或build-essentialmake: command not found沒裝 make安裝makelex/yacc 相關(guān)錯誤缺少 flex/bison安裝flex bison后重新 make clean makeOS/MACHINE 相關(guān)問題makefile.suite 平臺參數(shù)沒配對編譯前檢查并設(shè)置OSLINUX、MACHINELINUXiostream: No such file or directoryg 缺失或 libstdc 開發(fā)包缺失補全編譯工具鏈后重試undefined referencemake clean 沒執(zhí)行舊對象文件殘留執(zhí)行 make clean 后完整重新編譯cannot find -lxxx某些靜態(tài)庫缺失根據(jù)報錯中的庫名搜索安裝對應 dev 包這里想重點說下make clean的價值。TPC-DS 這類老 C 項目依賴關(guān)系和自動依賴生成并不算完善如果你第一次編譯發(fā)現(xiàn)缺了 flex裝好 flex 后直接再 make系統(tǒng)可能只重新編譯部分文件導致“改了環(huán)境但沒生效”的假象。最穩(wěn)妥的做法始終是make clean make5.2 數(shù)據(jù)生成階段的常見報錯對照表編譯通過只是第一步運行dsdgen和dsqgen時也有不少問題同樣整理成速查表報錯現(xiàn)象大概率原因處理方式DISTRIBUTIONS file not found沒指定 tpcds.idx 路徑加-DISTRIBUTIONS /path/tpcds.idx參數(shù)No space left on device數(shù)據(jù)規(guī)模超出磁盤空間清理磁盤或換更大目錄Permission denied輸出目錄無寫權(quán)限檢查目錄權(quán)限或改用有權(quán)限的路徑無法打開輸出文件-DIR指定目錄不存在先 mkdir -p 輸出目錄Segmentation fault (core dumped)內(nèi)存不足或二進制與系統(tǒng)不兼容減小 SCALE確認平臺參數(shù)正確數(shù)據(jù)文件都是空文件dsdgen 當前目錄缺少輔助文件在 tools 目錄下運行或顯式指定 DISTRIBUTIONS關(guān)于內(nèi)存不足導致的段錯誤多說一句。雖然生成數(shù)據(jù)主要吃 CPU 和磁盤但某些向量數(shù)據(jù)和排序過程還是會占用較多內(nèi)存。如果是低配虛擬機比如 2GB 內(nèi)存還跑多個進程并行生成直接崩潰也不奇怪。建議第一輪只用單進程、小 SCALE 驗證然后再考慮并行比如用-PARALLEL 2 -CHILD 1分別開兩個進程。5.3 疑似環(huán)境問題時的系統(tǒng)化排查方法早期使用 TPC-DS 時環(huán)境問題很容易被誤判為代碼問題。比如在某個 Linux 發(fā)行版上編譯通過但換一臺機器執(zhí)行時提示無法加載動態(tài)庫或直接段錯誤多半不是寫錯了命令而是編譯環(huán)境與運行環(huán)境差異太大。遇到這種情況我的排查順序是這樣的先確認執(zhí)行環(huán)境架構(gòu)uname -m排除 ARM 和 x86_64 混淆。再確認當前 shell 的 PATH 和動態(tài)庫搜索路徑echo $PATH、ldd ./dsdgen。查看可執(zhí)行文件依賴了哪些系統(tǒng)庫ldd dsdgen。如果動態(tài)庫缺失優(yōu)先補齊庫文件如果庫版本太低盡量在更干凈或更新的系統(tǒng)上重新編譯一次。在實際排障時ldd是非常好用的工具它能直接告訴你編譯出來的二進制需要哪些.so文件。如果某個庫顯示not found那這個工具拿到其他機器上大概率也會運行失敗。與其到處拷貝缺失庫不如就直接在目標機器或同版本系統(tǒng)上重新編譯這種“土辦法”反而更穩(wěn)。5.4 編譯期間的日志也要學會保存我見過很多同學卡在編譯錯誤上第一反應是把錯誤截個圖下來但看不到上面幾百行里更早的 error。正確做法是在第一次觸發(fā)編譯時就順手把完整日志存下來make 21 | tee /tmp/tpcds_make.log這樣不僅方便你自己搜索報錯點還能在向別人提問時給出完整上下文。日志里有時候能看到多個 error但真正的根因往往是最前面那一個后面的 error 可能只是前面錯誤的連帶反應。比如頭文件找不到后面幾百行未定義標識符的報錯其實都不需要看修復頭文件路徑后它們會一起消失。6. 關(guān)于后續(xù)使用的一些實用建議和踩坑體會把 TPC-DS 編譯安裝這件事說清楚之后我還想聊一些后續(xù)真正做壓測時會用到的經(jīng)驗。很多文章只寫到能生成數(shù)據(jù)就結(jié)束了但實際把工具集成進測試流程后你會遇到比編譯安裝更多的問題。第一優(yōu)先用腳本統(tǒng)一封裝命令不要每次手工敲。TPC-DS 的dsdgen參數(shù)并不復雜但一旦涉及并行生成、多規(guī)模數(shù)據(jù)集手工敲會很容易漏參數(shù)或把不同規(guī)模的數(shù)據(jù)混在同一目錄里。我在實際使用中會為不同 SCALE 值分別建目錄比如data_1/、data_100/、data_1000/然后寫一個簡單的 shell 腳本把數(shù)據(jù)生成和 SQL 生成兩個步驟串起來SCALE${1:-1} mkdir -p /tmp/tpcds/data_$SCALE cd /opt/tpc-ds ./dsdgen -SCALE $SCALE -DISTRIBUTIONS ./tpcds.idx -DIR /tmp/tpcds/data_$SCALE這樣重復跑同一規(guī)模數(shù)據(jù)時只需要改一個變量不容易出線路徑混亂。第二不要光記官方命令不記版本。TPC-DS 不同版本之間生成的模板、表結(jié)構(gòu)、查詢數(shù)量可能都有差異。如果你要對比兩個數(shù)據(jù)庫最好使用同一個版本的工具包和同一規(guī)模的 SCALE否則測試結(jié)論很難讓聽的人信服。第三數(shù)據(jù)生成是可以并行的但并行后文件會被切分成多個分片導入數(shù)據(jù)庫前需要把分片合并或讓數(shù)據(jù)庫并行加載工具識別分片。實際導入時要注意這樣會占用大量 IO建議在目標數(shù)據(jù)庫磁盤壓力較低的時候執(zhí)行避免把壓測環(huán)境搞成 IO 阻塞。我自己在做這套工具時最大的體會是“編譯安裝只是入場券真正難的是把數(shù)據(jù)、查詢、數(shù)據(jù)庫三者的邊界理清楚”。如果你第一次編譯 TPC-DS 時報錯不用慌大部分問題都出在環(huán)境缺依賴或者平臺參數(shù)沒配對。按make clean make、補依賴、查 DISTRIBUTIONS 路徑這條路走下來基本都能過。最后再分享一個小技巧把編譯好的二進制連同tpcds.idx、查詢模板和 templates.lst 整份放到一個單獨的目錄不要每次臨時去解壓包翻。這樣后面不管誰要用只要把這個目錄拷走再配好 PATH 就能直接用。對于長期做數(shù)據(jù)庫壓測的團隊來說這套“干凈的環(huán)境目錄”能節(jié)省很多重復試錯的時間。