先說(shuō)說(shuō)我前幾天遇到的一個(gè)實(shí)際問(wèn)題拿到一份 8GB 的nginx日志要分析接口異常率本地編輯器打開(kāi)就卡死grep 一次要等幾分鐘。用 split 把大文件拆成若干小文件之后事情立刻變得清爽。這不是什么高深的技術(shù)但“文件拆分”這個(gè)動(dòng)作在日常運(yùn)維、數(shù)據(jù)處理、文件傳輸里幾乎天天用得上。很多人一聽(tīng)到 split第一反應(yīng)是代碼里那個(gè)把字符串按分隔符切開(kāi)的字符串函數(shù)。其實(shí)在命令行世界split 是一個(gè)專(zhuān)門(mén)按大小或行數(shù)切分文件的工具Linux 和 macOS 自帶Windows 下也有替代方案。這篇文章我把自己實(shí)際用過(guò)的拆分思路、命令參數(shù)、真實(shí)案例和踩過(guò)的坑都整理了適合運(yùn)維工程師、數(shù)據(jù)分析師、開(kāi)發(fā)人員也適合平時(shí)要傳大文件、做備份的非技術(shù)人員參考。1. 為什么要拆文件先弄清真實(shí)需求拆文件不是炫技而是為了解決“單文件太大導(dǎo)致沒(méi)法處理、沒(méi)法傳輸、沒(méi)法存儲(chǔ)”的問(wèn)題。我總結(jié)下來(lái)絕大多數(shù)場(chǎng)景跑不出這四類(lèi)需求。1.1 傳輸瓶頸才是最大動(dòng)因文件太大拷貝、上傳、下載都痛苦。拿 FTP 傳一個(gè) 20GB 的備份包中途網(wǎng)絡(luò)抖一下整個(gè)任務(wù)失敗又要從頭再來(lái)。但如果你先把它拆成 20 個(gè) 1GB 的分片哪個(gè)失敗了就重傳哪個(gè)成本和挫敗感完全不一樣?，F(xiàn)在一些工具也支持?jǐn)帱c(diǎn)續(xù)傳但在很多老舊系統(tǒng)、專(zhuān)網(wǎng)環(huán)境、甲方限定工具的前提下拆分成小文件仍然是最通用、最穩(wěn)妥的土辦法。生活里類(lèi)比一下就是一整輛大貨車(chē)想過(guò)一段限重 10 噸的橋你硬開(kāi)上去會(huì)出事但你把貨卸開(kāi)分幾趟運(yùn)過(guò)去問(wèn)題就解決了。計(jì)算機(jī)世界的“限重”通常是網(wǎng)絡(luò)帶寬、平臺(tái)單文件大小限制、工具內(nèi)存上限。1.2 工具和平臺(tái)的軟限制很多軟件處理大文件時(shí)會(huì)直接“罷工”。老版本的 Excel 打開(kāi)幾十萬(wàn)行 CSV 就卡成 PPT數(shù)據(jù)庫(kù)導(dǎo)入工具對(duì)單文件大小有隱性上限日志分析平臺(tái)對(duì)超大 raw 文件解析慢得讓人懷疑人生。把這些文件拆小不是為了改數(shù)據(jù)而是為了“適配下游工具的脾氣”。我還遇到過(guò)一個(gè)典型情況第三方后臺(tái)系統(tǒng)要求上傳附件單個(gè)文件不超過(guò) 2GB但客戶(hù)給的離線(xiàn)數(shù)據(jù)包是 5GB。這時(shí)候你不需要對(duì)文件內(nèi)容做任何改動(dòng)只要把它按大小拆開(kāi)、分批上傳再到目標(biāo)端合并數(shù)據(jù)一份不少。1.3 備份與存儲(chǔ)介質(zhì)的格式限制FAT32 格式的 U 盤(pán)和移動(dòng)硬盤(pán)單個(gè)文件不能超過(guò) 4GB。現(xiàn)在很多新設(shè)備默認(rèn) exFAT 或者 NTFS 問(wèn)題不大但老設(shè)備、車(chē)載系統(tǒng)、某些嵌入式存儲(chǔ)還是 FAT32。如果備份文件是 6GB直接拷不過(guò)去拆成兩半就解決了。還有一個(gè)常見(jiàn)場(chǎng)景是異地離線(xiàn)交付數(shù)據(jù)要拷貝到多塊硬盤(pán)、分人攜帶、分批發(fā)送。拆成固定大小的分卷每塊硬盤(pán)放一部分再去目標(biāo)端拼接比硬塞一個(gè)超大文件靠譜得多。1.4 拆和壓縮不是一回事這里必須把兩個(gè)概念分清楚。壓縮是把文件體積變小比如用 gzip、zip、xz它改變的是“大小”拆分是把一個(gè)文件切成多塊內(nèi)容拼回去和原來(lái)一模一樣它改變的是“數(shù)量”。實(shí)際工作中兩者經(jīng)常搭配使用先壓縮讓文件從 20GB 變成 5GB再按 1GB 拆成 5 份。先拆再壓縮通常沒(méi)有意義反而會(huì)降低壓縮率。搞清楚你到底是“需要變小”還是“需要切成多塊”后面的工具選型就不會(huì)亂。2. split 命令全解析幾個(gè)核心參數(shù)一次吃透Linux 和 macOS 系統(tǒng)自帶的 split 命令語(yǔ)法其實(shí)非常簡(jiǎn)單split [選項(xiàng)] [輸入文件] [輸出前綴]。想要用好它核心就是搞清楚三個(gè)問(wèn)題按什么規(guī)則切、輸出文件怎么命名、文件要不要保留擴(kuò)展名。2.1 按行數(shù)切分-l 參數(shù)如果你處理的是日志、CSV 這類(lèi)文本文件按行切分是最符合直覺(jué)的方式。一行數(shù)據(jù)是一個(gè)完整記錄拆開(kāi)后每個(gè)小文件的行數(shù)是確定的方便后續(xù)分析和導(dǎo)入。默認(rèn)情況下split 按每 1000 行切分一次。如果你想按 5 萬(wàn)行拆命令是split -l 50000 access.log access_part_這會(huì)生成 access_part_aa、access_part_ab、access_part_ac…… 這樣的文件依次往下排。2.2 按大小切分-b 與 -C 的區(qū)別按字節(jié)大小拆分用 -b比如把一個(gè)大日志拆成 100MB 一份split -b 100M app.log app_log_單位方面GNU split 有套自己的換算規(guī)則大寫(xiě)的 K、M、G 表示 1024 倍數(shù)而 KB、MB、GB 表示 1000 倍數(shù)。比如 -b 1K 是 1024 字節(jié)-b 1KB 是 1000 字節(jié)。平時(shí)我們說(shuō)的“1M”習(xí)慣上就是 1024K所以直接寫(xiě) -b 100M 就好不用糾結(jié)。需要注意按字節(jié)切分時(shí)如果文件是文本可能出現(xiàn)一行被攔腰切斷的情況。例如 100M 的切分點(diǎn)正好落在一行日志中間某個(gè)小文件的末尾會(huì)留下半行下一個(gè)小文件的開(kāi)頭是另半行。如果小文件只是用來(lái)傳輸后合并那沒(méi)問(wèn)題如果要直接對(duì)切出來(lái)的文件做 grep、統(tǒng)計(jì)、導(dǎo)入數(shù)據(jù)庫(kù)就麻煩了。這時(shí)候用 -C 參數(shù)替代 -b它表示“每個(gè)文件最大不超過(guò)指定大小并且盡量在換行符處切斷”。命令長(zhǎng)這樣split -C 100M app.log app_log_-C 的本質(zhì)是“按大小約束 行邊界對(duì)齊”對(duì)文本文件是更安全的選擇。它的代價(jià)是每個(gè)文件大小不完全一樣但最大不超過(guò)你給的閾值。這個(gè)參數(shù)我實(shí)際用得最多尤其是處理文本型數(shù)據(jù)。2.3 輸出命名規(guī)則后綴、前綴和擴(kuò)展名split 默認(rèn)的行為很容易讓人迷惑輸出前綴默認(rèn)是 x后綴默認(rèn)是 aa、ab、ac…… 于是直接運(yùn)行 split 大文件.big會(huì)得到 xaa、xab 這類(lèi)文件很難一眼看出是什么內(nèi)容。我建議所有人在真實(shí)項(xiàng)目中都用“自定義前綴 數(shù)字后綴 擴(kuò)展名”的寫(xiě)法。數(shù)字后綴要加 -d 參數(shù)帶擴(kuò)展名要加 --additional-suffixsplit -b 100M -d -a 2 --additional-suffix.log app.log app_log_這條命令的含義是按 100MB 拆 app.log使用兩位數(shù)字后綴00、01、02……每個(gè)文件保留 .log 擴(kuò)展名前綴是 app_log_。最終生成的文件是app_log_00.log app_log_01.log app_log_02.log為什么推薦數(shù)字后綴而不是默認(rèn)的字母后綴因?yàn)樽帜?aa 到 zz 最多只能支持 676 個(gè)文件而且很多工具對(duì)字母序的識(shí)別容易出錯(cuò)。數(shù)字后綴尤其是固定位數(shù)填充的排序、腳本遍歷都更可控。-a 2 表示后綴長(zhǎng)度兩位如果分片數(shù)預(yù)計(jì)超過(guò) 100 個(gè)就改成 -a 3。哪怕現(xiàn)在只有幾個(gè)分片我也習(xí)慣預(yù)留足夠位數(shù)避免最后出現(xiàn)排序混亂。2.4 輸入文件與標(biāo)準(zhǔn)輸入split 可以指定輸入文件也支持從標(biāo)準(zhǔn)輸入讀取。用標(biāo)準(zhǔn)輸入的場(chǎng)景通常是把前一個(gè)命令的輸出直接喂給它比如先壓縮再拆分tar -czf - ./data | split -b 4G -d - data_backup.tar.gz.這里的 - 表示從標(biāo)準(zhǔn)輸入讀取。為什么要這么寫(xiě)如果先把整包壓縮成文件再拆中間需要生成一個(gè)臨時(shí)大文件占用磁盤(pán)用管道直接拆全程不落臨時(shí)文件。這是我處理超大目錄備份時(shí)的首選方案。3. 三個(gè)實(shí)戰(zhàn)案例日志、CSV、備份分卷3.1 案例一按 100MB 拆日志快速定位問(wèn)題窗口我拿到 8GB 的 nginx access.log目標(biāo)是找出某天下午的異常請(qǐng)求。先用 -C 按行邊界拆成 100MB 的小塊split -C 100M -d -a 2 --additional-suffix.log access.log access_log_這樣得到大約 80 個(gè)文件每個(gè)文件行數(shù)完整grep、awk 處理單個(gè)文件都是秒級(jí)響應(yīng)。定位到對(duì)應(yīng)時(shí)間段后再針對(duì)具體某幾個(gè)文件深入分析我還會(huì)把 grep 結(jié)果重定向輸出grep -E 5[0-9][0-9] access_log_35.log error_35.log實(shí)際體驗(yàn)下來(lái)這種方式比直接在大文件上反復(fù) grep 效率高很多尤其是你只需要局部數(shù)據(jù)的時(shí)候。3.2 案例二按行拆分帶表頭的 CSV保留每份表頭CSV 拆分有個(gè)特殊需求每一份小文件最好都保留表頭。直接按行數(shù)拆子文件默認(rèn)沒(méi)有表頭導(dǎo)入數(shù)據(jù)庫(kù)或者 Excel 時(shí)第一行就會(huì)變成數(shù)據(jù)。我的做法是先把表頭單獨(dú)取出來(lái)給每個(gè)子文件拼接回去head -1 orders.csv header.txt total$(wc -l orders.csv) tail -n $((total - 1)) orders.csv | split -l 500000 -d - orders_slice_ for i in orders_slice_*; do cat header.txt $i orders_part_$i done拆完檢查首行確認(rèn)每一份都有表頭。這里有個(gè)細(xì)節(jié)wc -l 統(tǒng)計(jì)的是總行數(shù)包含表頭所以 tail 要減去一行。如果不處理這個(gè)差數(shù)最后一份小文件會(huì)多出異常的一行或者少最后一筆記錄。這種偏移錯(cuò)誤在數(shù)據(jù)導(dǎo)入時(shí)特別隱蔽必須細(xì)心。3.3 案例三超大備份文件分卷壓縮、傳輸與合并備份目錄通常是小文件特別多的目錄幾百 GB 的圖片、視頻、代碼倉(cāng)庫(kù)。直接拆分這些目錄沒(méi)有意義正確做法是先壓縮成單個(gè)歸檔再按卷切分tar -czf - ./project | split -b 4G -d - backup.tar.gz.注意前綴我故意寫(xiě)成了 backup.tar.gz.末尾帶一個(gè)點(diǎn)生成出來(lái)就是backup.tar.gz.00 backup.tar.gz.01 backup.tar.gz.02還是“前綴 后綴”的格式但前綴里已經(jīng)包含擴(kuò)展名拼接的時(shí)候更方便。傳輸?shù)侥繕?biāo)機(jī)器后合并并解壓cat backup.tar.gz.* backup.tar.gz tar -xzf backup.tar.gz如果壓縮率要求更高可以把 tar 的 -z 換成 -Jxz 壓縮或者 -jbzip2代價(jià)就是壓縮和解壓時(shí)間更長(zhǎng)。我個(gè)人的習(xí)慣是磁盤(pán)空間緊張選 xz時(shí)間緊張選 gzip。還有一個(gè)很多人不知道的細(xì)節(jié)如果你用的是圖形界面?zhèn)鬏攝ip 自帶分卷壓縮更符合使用習(xí)慣。命令是zip -s 100m -r backup.zip ./folder這會(huì)生成 backup.zip、backup.z01、backup.z02 等一系列文件解壓時(shí)只要雙擊任何一個(gè) zip 分卷zip 工具會(huì)自動(dòng)把其他分卷拼接起來(lái)不需要手動(dòng) cat。這個(gè)方案最適合非技術(shù)背景的同事操作。4. Windows 環(huán)境與腳本化讓拆分成為可復(fù)用的手藝很多朋友用的是 Windows默認(rèn)沒(méi)有 split 命令。想用命令行的思路解決有幾個(gè)辦法裝 Git Bash、打開(kāi) WSL、或者下載 GNU coreutils 的 Windows 版本。還有一個(gè)更省事的選擇——用 7-Zip 的圖形界面做“分卷壓縮”右鍵文件選擇“分卷壓縮”再輸入每卷大小整個(gè)過(guò)程不用記命令。但如果數(shù)據(jù)量很大、要經(jīng)常處理我強(qiáng)烈建議裝一個(gè) Git Bash它在 Windows 下可以直接跑 Linux 那一套拆分命令體驗(yàn)基本一致。4.1 Windows 圖形界面下的快速分卷7-Zip 的分卷操作其實(shí)是“壓縮成多個(gè)分卷壓縮包”和純粹的拆分在形式上類(lèi)似最終也能還原成原文件。核心步驟就三步選中要處理的大文件右鍵 - 7-Zip - 添加到壓縮包。在“切分為分卷”一欄輸入分卷大小比如 4000M。生成 zip 分卷后全部放在同一目錄解壓時(shí)程序自動(dòng)讀取所有分卷。這種方式不要求懂命令適合大多數(shù)日常場(chǎng)景。缺點(diǎn)是效率不如純命令行拆分而且如果文件本身就是壓縮包再包一層壓縮是浪費(fèi) CPU 和存儲(chǔ)空間。4.2 寫(xiě)一個(gè)拆分與校驗(yàn)的小腳本如果每周都要拆文件把命令封裝成腳本能省不少事。下面這個(gè) bash 函數(shù)是我一直在用的一個(gè)簡(jiǎn)化版邏輯是先檢查參數(shù)再按 100MB 大小切分最后生成每個(gè)分塊的 MD5 值split_file() { if [ $# -lt 1 ]; then echo 用法: split_file 文件名 [塊大小] return 1 fi file$1 size${2:-100M} split -b $size -d -a 3 --additional-suffix.part $file ${file}_ md5sum $file_* ${file}_checksums.md5 }腳本生成的校驗(yàn)文件很有用。因?yàn)椴鸱直旧碇皇前盐募谐蓧K如果某一塊在傳輸中損壞等合并完才發(fā)現(xiàn)就太晚了。通過(guò) md5sum 逐塊校驗(yàn)?zāi)芫_定位哪一塊出了問(wèn)題。4.3 Python 腳本作為跨平臺(tái)替代方案Windows 沒(méi)有原生 split手動(dòng)寫(xiě)一個(gè) Python 腳本反而是最可控的辦法。想法很簡(jiǎn)單按指定字節(jié)數(shù)讀取原文件寫(xiě)入多個(gè)小文件同時(shí)記錄每塊的哈希值import os import hashlib def split_file_by_size(src, chunk_size, dst_prefix): chunk_size chunk_size * 1024 * 1024 # 默認(rèn)按 MB 計(jì)算 index 0 with open(src, rb) as f: while True: data f.read(chunk_size) if not data: break dst f{dst_prefix}{index:03d}.part with open(dst, wb) as out: out.write(data) h hashlib.md5() h.update(data) print(f{dst} md5{h.hexdigest()}) index 1 split_file_by_size(big_data.bin, 100, big_data_)這個(gè)腳本最大的好處是純 Python 就能跑不依賴(lài)任何第三方庫(kù)。想要支持按行數(shù)拆分就把讀文件模式改成循環(huán) readline 計(jì)數(shù)即可邏輯也不復(fù)雜。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這里整理的是我在實(shí)際使用過(guò)程中真實(shí)踩過(guò)或者見(jiàn)別人踩過(guò)的坑每一個(gè)都對(duì)應(yīng)具體問(wèn)題直接對(duì)照處理就行。5.1 合并后順序錯(cuò)亂問(wèn)題按字母序合并時(shí)文件 10 排在了 2 的前面。比如拆出 file_1、file_2、file_10用 file_* 通配符時(shí)默認(rèn)按字典序排列結(jié)果是 file_1、file_10、file_2合并出來(lái)的文件必然損壞。解決拆分時(shí)用固定位數(shù)的數(shù)字后綴比如 -a 3 生成 file_001、file_002、file_010。這樣按字典序就是正確的自然順序。如果文件已經(jīng)拆壞了用 sort -V 可以按版本號(hào)排序把順序捋回來(lái)。5.2 合并后校驗(yàn)不一致問(wèn)題cat 合并后的文件 md5 和原文件對(duì)不上。解決這種問(wèn)題九成出在傳輸環(huán)節(jié)不是拆分環(huán)節(jié)。處理流程是逐個(gè)核對(duì)每個(gè)分卷的 md5 是否和拆分時(shí)一致找出損壞的分卷重新傳輸。如果沒(méi)有逐塊校驗(yàn)文件就重新生成一次校驗(yàn)清單。大文件傳輸用 rsync 帶校驗(yàn)參數(shù)會(huì)更省心它會(huì)自動(dòng)處理塊的比對(duì)。5.3 中文文件名亂碼問(wèn)題split 生成的中文文件名在 Linux 下正?？降?Windows 共享目錄后出現(xiàn)亂碼。解決文件塊命名盡量用純英文前綴避免用特殊符號(hào)或中文。不是每個(gè)平臺(tái)的默認(rèn)字符集都支持 UTF-8 的完整顯示為了兼容性前綴簡(jiǎn)單一點(diǎn)比如 log_batch_、data_part_內(nèi)容本身不會(huì)因?yàn)槲募苡绊憽?.4 按字節(jié)拆分把一行數(shù)據(jù)切斷了問(wèn)題用 -b 拆分日志后某些文件的首行或尾行是不完整的半行導(dǎo)致按行統(tǒng)計(jì)時(shí)數(shù)據(jù)缺失。解決文本數(shù)據(jù)用 -C 替代 -b或者干脆按行數(shù)拆。如果你確定只是傳輸用途不需要解析-b 倒是沒(méi)影響。5.5 拆分導(dǎo)致磁盤(pán)空間不足問(wèn)題8GB 日志拆成多個(gè) 100MB 文件雖然每個(gè)都不大但所有分塊加起來(lái)還是 8GB磁盤(pán)不夠拆到一半報(bào)錯(cuò)。解決先 df -h 看剩余空間。如果空間緊張可以先壓縮再拆分邊壓縮邊用管道輸出不落臨時(shí)文件或者把分塊直接輸出到另一個(gè)掛載點(diǎn)避免和目標(biāo)文件擠在同一塊盤(pán)上。5.6 split 和日志滾動(dòng)有什么區(qū)別問(wèn)題為什么不用 logrotate 而用 split解決logrotate 是按時(shí)間或文件大小自動(dòng)輪轉(zhuǎn)日志目的是防止單個(gè)日志文件無(wú)限增長(zhǎng)它是服務(wù)配套的機(jī)制split 是手動(dòng)、按需地把已有文件切塊目的是傳輸或分析。兩者定位不同可以互相配合。比如先讓 logrotate 每天輪轉(zhuǎn)再把幾天前的日志用 split 切塊歸檔。最后分享我的一點(diǎn)個(gè)人體會(huì)。文件拆分這個(gè)操作聽(tīng)起來(lái)基礎(chǔ)但使用頻率和“救命指數(shù)”都很高。我自己現(xiàn)在遇到大文件第一反應(yīng)就是“先拆了再說(shuō)”尤其是拿去給別人處理時(shí)小文件對(duì)各方都友好。如果你只是想臨時(shí)把幾個(gè)大文件發(fā)給同事與其研究命令不如直接用 7-Zip 做分卷壓縮簡(jiǎn)單粗暴還自帶還原功能。要是天天和數(shù)據(jù)文件打交道那 split 這套命令行操作還是值得練熟畢竟管道、壓縮、校驗(yàn)、并行傳輸一套連招下來(lái)省下的時(shí)間是實(shí)打?qū)嵉摹?