split這個(gè)詞換個(gè)圈子意思就完全變樣程序員聽到split第一反應(yīng)是字符串處理函數(shù)做射頻硬件的人聽到split ring resonator想到的則是超材料諧振環(huán)結(jié)構(gòu)。但在文件管理這個(gè)領(lǐng)域split只有一個(gè)最樸實(shí)的含義——把一個(gè)大文件切成一堆小文件。工作中這類需求太常見了日志文件動(dòng)不動(dòng)幾個(gè)GB編輯器打開直接卡死數(shù)據(jù)庫(kù)導(dǎo)出的SQL備份有2GB想傳到服務(wù)器上傳輸總是斷甲方硬性要求視頻素材按1GB一份交付否則網(wǎng)盤上傳直接失敗。解決這些問(wèn)題核心思路就是拆分而Linux下最正統(tǒng)的工具就是split命令配合cat合并、md5sum/sha256sum校驗(yàn)再加上Windows環(huán)境下的7-Zip分卷方案就湊齊了全套文件拆分的家當(dāng)。這篇文章從原理到實(shí)操把大文件拆分的步驟、命令、合并、校驗(yàn)、排查一次性講透給經(jīng)常和大文件打交道的數(shù)據(jù)運(yùn)維、開發(fā)、網(wǎng)管以及所有被文件體積卡住的朋友一套能直接抄的作業(yè)。1. 為什么要把大文件拆成多個(gè)小文件1.1 大文件的四大難題很多人第一反應(yīng)是文件大就大唄放那兒又不會(huì)跑。真遇到實(shí)際問(wèn)題就明白了大文件帶來(lái)的干擾是多方面的。第一個(gè)是文件系統(tǒng)層面的單文件大小限制。U盤和移動(dòng)硬盤大多是FAT32格式這種格式在格式化時(shí)就已經(jīng)規(guī)定好了單個(gè)文件最大4GB。相機(jī)拍攝的高碼率視頻、虛擬機(jī)的VHD磁盤鏡像稍微大一點(diǎn)就提示文件過(guò)大無(wú)法復(fù)制到目標(biāo)文件系統(tǒng)。強(qiáng)行拷貝的結(jié)果就是中途失敗甚至把U盤文件系統(tǒng)都搞出問(wèn)題。NTFS、ext4這些現(xiàn)代文件系統(tǒng)雖然單文件上限很高但很多存儲(chǔ)設(shè)備、網(wǎng)盤后端并不是這些系統(tǒng)兼容性坑就在這。第二個(gè)是內(nèi)存和編輯器的加載壓力。很多文本編輯器、IDE在打開文件時(shí)會(huì)嘗試把內(nèi)容映射到內(nèi)存一個(gè)2GB的日志文件直接能把8GB內(nèi)存的筆記本拖到swap交換區(qū)鼠標(biāo)轉(zhuǎn)圈CPU占用居高不下。就算勉強(qiáng)打開了搜索一個(gè)關(guān)鍵詞要等幾十秒想改個(gè)內(nèi)容更是天方夜譚。這種情況下把文件拆開變成幾百M(fèi)B甚至幾十MB的小塊操作體驗(yàn)完全不同。第三個(gè)是傳輸環(huán)節(jié)的尺寸限制。FTP客戶端斷點(diǎn)續(xù)傳雖然好但服務(wù)端如果配置了2GB上限大文件直接拒絕接收。HTTP文件上傳、網(wǎng)盤同步、郵箱附件幾乎每一個(gè)環(huán)節(jié)都對(duì)單文件大小有隱性要求。視頻素材給客戶、模型文件給同事、數(shù)據(jù)庫(kù)備份給DBA被文件太大無(wú)法發(fā)送卡住的經(jīng)歷幾乎人人都遇到過(guò)。第四個(gè)是備份和歸檔的物理介質(zhì)不匹配。整塊服務(wù)器的數(shù)據(jù)鏡像動(dòng)輒幾十GB但移動(dòng)硬盤要分給多人協(xié)作、DVD光盤一張才4.7GB、U盤格式還是FAT32。把一個(gè)大歸檔文件拆成多個(gè)小塊才能適配這些存儲(chǔ)介質(zhì)否則最終只能犧牲數(shù)據(jù)完整性。1.2 拆分底層邏輯字節(jié)流的切片與重組說(shuō)句實(shí)在話拆分這件事技術(shù)上沒(méi)什么玄學(xué)。所有文件在底層都是一串連續(xù)的字節(jié)序列拆分就是把這串字節(jié)按固定步長(zhǎng)切片每一片單獨(dú)保存為一個(gè)文件合并則正好反過(guò)來(lái)把切片按原始順序重新拼接。切分要求兩塊一是無(wú)重疊漏掉任何一段都會(huì)導(dǎo)致文件損壞二是無(wú)遺漏多復(fù)制一段也不行會(huì)讓文件長(zhǎng)度變錯(cuò)、內(nèi)容錯(cuò)位。只要滿足這兩個(gè)條件理論上拆分多少塊、用什么大小拆都沒(méi)有區(qū)別。這個(gè)邏輯解釋了為什么split命令支持按字節(jié)拆和按行拆兩種模式。按字節(jié)拆最簡(jiǎn)單純粹從字節(jié)流的角度切割適用于一切文件類型按行拆則是從文本結(jié)構(gòu)的角度考慮能保留每一行的完整性特別適合日志、SQL腳本、CSV這類有行概念的文件。但底層數(shù)據(jù)都非常簡(jiǎn)單拆分后依然能完整合并因?yàn)槲募?shù)據(jù)本身就是連續(xù)的字節(jié)串切回去再拼起來(lái)一字不差。理解了這一點(diǎn)你會(huì)意識(shí)到一個(gè)關(guān)鍵結(jié)論拆分本身不會(huì)損壞文件。真正的風(fēng)險(xiǎn)在于拆分后的管理環(huán)節(jié)——分卷丟了、順序亂了、傳輸中某一塊數(shù)據(jù)出了損毀這些問(wèn)題才可能導(dǎo)致最終合并失敗。所以后面我花了不少篇幅講命名規(guī)范和校驗(yàn)這些環(huán)節(jié)的重要性一點(diǎn)都不比split命令本身低。2. Linux下用split命令拆分文件2.1 按大小拆split -b的用法Linux環(huán)境下最正統(tǒng)的拆分工具就是split命令沒(méi)有之一。它簡(jiǎn)單、穩(wěn)定、幾乎存在于所有發(fā)行版哪怕是最精簡(jiǎn)的容器鏡像只要帶了coreutilssplit就可用。最常用的場(chǎng)景是按大小拆分指令格式如下split -b 100m bigfile.bin part_-b參數(shù)指定每個(gè)分塊的字節(jié)大小單位支持k、m、g分別對(duì)應(yīng)KB、MB、GB。其中需要注意GNU split里k、m、g表示1024進(jìn)制而KB、MB、GB則區(qū)分1000進(jìn)制平時(shí)不糾結(jié)這個(gè)差異影響不大。上面的命令就是把bigfile.bin按每塊100MB大小切開生成part_aa、part_ab、part_ac……如果文件大小不是100MB的整數(shù)倍最后一塊會(huì)自動(dòng)保留剩余字節(jié)你不用多操心。想用數(shù)字后綴而不是字母后綴加上-d參數(shù)即可split -b 500m -d backup.sql part_backup_模式下會(huì)生成part_backup_00、part_backup_01、part_backup_02這樣的文件對(duì)習(xí)慣看數(shù)字的人更友好也方便后續(xù)腳本循環(huán)處理。如果預(yù)估塊數(shù)會(huì)很多比如超過(guò)100塊記得加上-a 3這類參數(shù)把后綴拉長(zhǎng)到三位數(shù)避免順序錯(cuò)亂。后面合并環(huán)節(jié)我還要專門提這個(gè)坑。按大小拆分適合一切文件包括二進(jìn)制文件、壓縮包、數(shù)據(jù)庫(kù)備份文件。但有一個(gè)注意點(diǎn)如果拆的是文本格式文件某一行內(nèi)容可能恰好被切到兩個(gè)分塊里每個(gè)分塊里都有半行數(shù)據(jù)。如果要單獨(dú)分析某個(gè)分塊還得拼行就不太舒服了。文本文件更推薦按行拆。2.2 按行拆split -l處理文本文件按行拆的命令是split -l 50000 access.log log_-l 50000表示每個(gè)分塊最多包含50000行。按行拆的好處是每個(gè)小文件都是結(jié)構(gòu)完整的任何一塊都可以獨(dú)立打開、獨(dú)立分析。這個(gè)特性對(duì)日志排查、SQL腳本分段執(zhí)行、CSV數(shù)據(jù)分批導(dǎo)入非常有價(jià)值。實(shí)戰(zhàn)里一個(gè)特別典型的場(chǎng)景是分析Apache或Nginx日志。日志文件動(dòng)輒幾個(gè)GB直接grep整個(gè)大文件當(dāng)然可以但如果你只是想分塊反向排查某一天的報(bào)錯(cuò)先把大文件按行切成合理大小再用grep、awk分別處理每個(gè)小文件操作會(huì)更順手資源占用也更低。配合split的按行模式每個(gè)分塊內(nèi)部仍然保持時(shí)間順序連續(xù)很多東西就不用重新排序。實(shí)際用的過(guò)程中行數(shù)挑多少取決于你的需要。我一般習(xí)慣把日志按100000行一個(gè)塊來(lái)切因?yàn)榘偃f(wàn)行級(jí)別的日志文件單個(gè)分析起來(lái)已經(jīng)有點(diǎn)吃力了十萬(wàn)行則比較輕快。如果只是想快速瀏覽甚至可以切到10000行一塊。這個(gè)尺度不是死標(biāo)準(zhǔn)核心是讓單個(gè)文件大小適合你用工具處理而不是追求某個(gè)固定的行數(shù)。2.3 命名規(guī)則與合并還原cat的正確姿勢(shì)很多第一次用split的人都會(huì)疑惑為什么拆分完出現(xiàn)一堆xaa、xab開頭的文件這其實(shí)是split的默認(rèn)前綴。split命令不指定前綴時(shí)輸出文件固定以x字母加兩個(gè)字母后綴命名xaa、xab、xac……直到xzz。理解了命名規(guī)則就不會(huì)在目錄里看到一堆x文件時(shí)措手不及。想控制文件名把前綴作為第二個(gè)參數(shù)傳進(jìn)去即可split -b 100m bigfile.tar.gz backup_合并更是簡(jiǎn)單直接用cat按順序拼接即可cat backup_aa backup_ab backup_ac bigfile_restored.tar.gz偷懶一點(diǎn)用通配符也行cat backup_* bigfile_restored.tar.gz但通配符方案有個(gè)前提條件通配符展開時(shí)文件按字典順序排列而split的默認(rèn)后綴aa、ab、ac……恰好就是字典順序所以能對(duì)上。可一旦塊數(shù)超過(guò)預(yù)設(shè)位數(shù)或者你混入了其它名字類似的文件順序就可能錯(cuò)亂。穩(wěn)妥做法是強(qiáng)制使用固定位寬的數(shù)字后綴然后按數(shù)字順序合并比如split -b 100M -d -a 3 bigfile.tar.gz backup_這樣文件名是backup_000、backup_001、backup_002……合并時(shí)也可以先排序再接上這是我最推薦的姿勢(shì)。2.4 split進(jìn)階參數(shù)數(shù)字后綴、自定義后綴、自動(dòng)壓縮除了-b、-l這兩個(gè)主力參數(shù)split還有幾個(gè)進(jìn)階選項(xiàng)值得了解。--additional-suffix參數(shù)可以在每個(gè)分塊文件的末尾追加字符串例如split -b 100m -d -a 3 --additional-suffix.part big.tar.gz data_生成的是data_000.part、data_001.part有了擴(kuò)展名很多下載工具和傳輸工具會(huì)識(shí)別得更友好別人拿到文件也能一眼明白這些是分塊。--filter參數(shù)則更有意思它可以在每個(gè)分塊輸出時(shí)執(zhí)行一條shell命令。經(jīng)典用法是邊拆邊壓縮一條命令同時(shí)完成拆分和壓縮極大節(jié)省磁盤和傳輸時(shí)間split -b 100m --filtergzip $FILE.gz bigdata.bin data_這里的$FILE是split自動(dòng)傳入當(dāng)前分塊文件名的變量結(jié)果會(huì)得到data_aa.gz、data_ab.gz這類帶壓縮的分塊。合并時(shí)反過(guò)來(lái)先連接再解壓cat data_*gz | gunzip bigdata.bin這種邊拆邊壓策略在處理超大文件時(shí)非常實(shí)用。原始文件可能好幾個(gè)GB壓縮后每塊體積變小拷貝和傳輸都更快。不過(guò)注意一點(diǎn)前提是數(shù)據(jù)本身壓縮率足夠比如文本、日志、數(shù)據(jù)庫(kù)導(dǎo)出文件就非常適合如果原文件已經(jīng)是壓縮包再壓一遍就沒(méi)有意義了。3. Windows環(huán)境下的大文件拆分方案3.1 7-Zip分卷最省心的選擇Windows沒(méi)有自帶類似于Linux split命令的原生工具但真要在Windows下拆分文件我反而更推薦用7-Zip的分卷功能因?yàn)樗巡鸱趾蛪嚎s合并成了兩步走的一步操作對(duì)普通用戶最友好。操作流程非常直觀右鍵文件選擇7-Zip點(diǎn)擊添加到壓縮包在彈出窗口的分卷大小一欄填入目標(biāo)大小比如100M、1G點(diǎn)擊確定。7-Zip會(huì)根據(jù)文件大小自動(dòng)生成多個(gè)分卷文件擴(kuò)展名形如file.7z.001、file.7z.002、file.7z.003。解壓時(shí)要求所有分卷放在同一個(gè)目錄里雙擊第一個(gè)同名分卷7-Zip會(huì)自動(dòng)讀取后續(xù)分卷并完成解壓。這里的關(guān)鍵參數(shù)就是分卷大小。它不是隨便填的而是根據(jù)目標(biāo)存儲(chǔ)介質(zhì)的單文件限制來(lái)定。比如要把文件拷進(jìn)FAT32格式的U盤分卷就不能超過(guò)4000M一般設(shè)為2000M左右比較安全要給客戶發(fā)郵件分卷就得控制在幾十MB要傳網(wǎng)盤那就看網(wǎng)盤對(duì)單個(gè)文件的上限是多少。7-Zip在分卷大小一欄的輸入框里還可以直接填100M、1G、2000M等格式非常方便。另外7-Zip的格式選擇也影響最終效果。選7z格式分卷小且壓縮率高但對(duì)方也需要用7-Zip解壓選zip格式兼容性更好幾乎任何系統(tǒng)都能直接解壓但分卷文件名和體積處理就沒(méi)那么整齊。給外部客戶交付時(shí)我一般用zip或7z給自己團(tuán)隊(duì)內(nèi)部用7z這個(gè)取舍看實(shí)際場(chǎng)景。3.2 WinRAR分卷老牌方案依然能打WinRAR的分卷功能同樣是老牌實(shí)用工具。選中文件后點(diǎn)擊添加在常規(guī)選項(xiàng)卡下找到切分為分卷大小一欄填入體積數(shù)值比如500M、1GB。WinRAR生成的分卷后綴是file.part1.rar、file.part2.rar、file.part3.rar解壓時(shí)需要所有分卷在一起點(diǎn)任一分卷都能觸發(fā)解壓流程。WinRAR和7-Zip在分卷思路上沒(méi)有本質(zhì)區(qū)別都是先把文件分包再按順序重組。選哪個(gè)更多看你平時(shí)用慣了哪個(gè)。有一點(diǎn)值得提醒WinRAR分卷默認(rèn)也會(huì)附帶壓縮對(duì)已經(jīng)壓過(guò)的視頻、圖片這類數(shù)據(jù)壓縮步驟純屬浪費(fèi)時(shí)間白白增加解壓耗時(shí)。如果用WinRAR處理這類文件可以把壓縮方式選為存儲(chǔ)也就是不壓縮只分卷速度會(huì)快很多。7-Zip在分卷彈窗里同樣可以選擇壓縮級(jí)別為僅存儲(chǔ)效果一樣。3.3 命令行與Git Bash方案如果堅(jiān)持在Windows上用純命令行方案也不是完全沒(méi)辦法。PowerShell可以按字節(jié)讀取并寫出分塊但性能實(shí)在談不上好大文件動(dòng)輒要等很久我平時(shí)很少用。真正推薦變通思路是在Windows上安裝Git BashGit Bash自帶一整套GNU工具集包括split、cat、md5sum命令和Linux完全一致。這樣一來(lái)Windows和Linux下拆分文件的命令就可以無(wú)縫切換腳本寫一套兩邊都能跑。還有一個(gè)純Windows自帶的奇技淫巧是copy /b。它通常用來(lái)合并文件格式也很簡(jiǎn)單copy /b file.001 file.002 file.003 restored.big這種方案沒(méi)有原生拆分對(duì)應(yīng)指令需要靠其它方法先生成多個(gè)分片文件整體非常麻煩但合并這步copy /b確實(shí)管用。在做不出Linux環(huán)境的現(xiàn)場(chǎng)臨時(shí)救急用一下也可以正規(guī)流程還是建議Git Bash或分卷壓縮工具。4. 合并與校驗(yàn)確保文件無(wú)損還原4.1 合并的順序與命名規(guī)范拆分只是前半程真正決定數(shù)據(jù)能不能安全還原的是合并環(huán)節(jié)。合并最大的兩個(gè)隱患一個(gè)是順序錯(cuò)亂一個(gè)是混入無(wú)關(guān)文件。順序錯(cuò)亂主要是命名不規(guī)范導(dǎo)致。前面提過(guò)用默認(rèn)雙字母后綴時(shí)最多產(chǎn)生676個(gè)分塊aa到zz一旦文件超過(guò)這個(gè)數(shù)后綴就會(huì)進(jìn)位成三位通配符按字典排序時(shí)可能把a(bǔ)aa排在aa前面合并結(jié)果直接亂套。規(guī)范做法就是給split加-d -a參數(shù)用定長(zhǎng)數(shù)字后綴并且數(shù)字位數(shù)要足夠容納所有分塊。如果你切出來(lái)200個(gè)塊就用-a 3預(yù)留三位空間如果塊數(shù)可能上千直接-a 4寧多勿少?；烊霟o(wú)關(guān)文件的問(wèn)題則更隱蔽。用cat part_*合并時(shí)通配符會(huì)把目錄下所有以part_開頭的文件全卷進(jìn)來(lái)哪怕這個(gè)文件根本不是本次拆分產(chǎn)生的。我之前就見過(guò)有人把part_temp.bak這種臨時(shí)備份文件也留在了同目錄合并后文件大小憑空多了好幾MB行還錯(cuò)亂了。所以合并前最好先確認(rèn)分塊列表或者把分塊統(tǒng)一放到一個(gè)干凈的臨時(shí)目錄里再執(zhí)行cat。實(shí)際操作里我更偏向列出完整的文件名清單比如用ls確認(rèn)一遍再按順序拼接。4.2 MD5/SHA256校驗(yàn)實(shí)操拆得快不如驗(yàn)得準(zhǔn)。合并完成只是第一步數(shù)據(jù)是不是真的和原始文件一模一樣必須通過(guò)哈希校驗(yàn)來(lái)確認(rèn)。哈希算法的原理很簡(jiǎn)單對(duì)任意長(zhǎng)度的數(shù)據(jù)用算法算出一個(gè)固定長(zhǎng)度的摘要數(shù)據(jù)任何一位發(fā)生變化摘要都會(huì)完全不同。所以原始文件算一個(gè)哈希合并還原的文件再算一次哈希兩個(gè)值完全一致基本可以認(rèn)定文件沒(méi)有損壞。Linux下最常用的兩個(gè)命令md5sum bigfile.bin sha256sum bigfile.binmd5速度快但安全性差一點(diǎn)檢查文件完整性足夠了。更加穩(wěn)妥的場(chǎng)合推薦sha256sum碰撞概率極低雖然計(jì)算速度略微慢一些但幾乎可以忽略。這里的關(guān)鍵建議是在拆分之前就把原始文件的哈希記錄下來(lái)而不是拆分完再回去補(bǔ)算。因?yàn)橹挥胁鸱智暗墓２耪嬲齺?lái)自源文件拆分后任何一步出錯(cuò)都沒(méi)法和原始文件比對(duì)。保存哈希的方式也很簡(jiǎn)單一行重定向進(jìn)文本文件就行md5sum bigfile.bin checksum.txtWindows PowerShell下對(duì)應(yīng)命令Get-FileHash -Algorithm MD5 bigfile.bin Get-FileHash -Algorithm SHA256 bigfile.bin輸出結(jié)果直接對(duì)比即可。4.3 沒(méi)有原哈希怎么驗(yàn)證還原成功理想情況下你能保留拆分前的哈希但現(xiàn)實(shí)里經(jīng)常會(huì)碰到原文件已經(jīng)刪了或者文件是別人發(fā)的沒(méi)有提供哈希的情況。這時(shí)候怎么判斷合并對(duì)不對(duì)第一件能做的就是比較文件大小。合并后的文件大小等于所有分塊大小之和如果大小和原始記錄一致可以排除大部分低級(jí)錯(cuò)誤。第二檢查文件頭和文件尾。對(duì)于文本內(nèi)容用head和tail命令看首尾幾行是否正常如果原始是SQL語(yǔ)句看開頭的CREATE TABLE和結(jié)尾的commit是否齊全基本八九不離十。第三針對(duì)特定格式做驗(yàn)證比如壓縮包用gzip -t測(cè)試完整性圖片用file命令檢查格式視頻則拖動(dòng)播放時(shí)間軸看尾部是否可讀。這些替代方法都不如哈希校驗(yàn)嚴(yán)格但至少能在沒(méi)有原哈希的情況下提供基礎(chǔ)保障。所以平時(shí)養(yǎng)成習(xí)慣拆完立刻記錄哈希會(huì)省掉很多莫名其妙的問(wèn)題。5. 四個(gè)典型場(chǎng)景的實(shí)操記錄5.1 數(shù)據(jù)庫(kù)備份跨服務(wù)器傳輸我曾經(jīng)處理過(guò)一個(gè)MySQL備份文件SQL導(dǎo)出來(lái)2.3GB要從內(nèi)網(wǎng)A機(jī)器傳到隔離區(qū)的B機(jī)器。這個(gè)場(chǎng)景是split的教科書用法。操作流程是先校驗(yàn)原始備份哈希md5sum backup.sql origin.md5然后按500MB一塊切成5份這里用數(shù)字后綴和三位位寬split -b 500m -d -a 3 backup.sql backup_生成backup_000到backup_004。接下來(lái)用scp逐個(gè)傳輸傳一個(gè)算一個(gè)md5做一次中轉(zhuǎn)校驗(yàn)確保每一塊傳輸都沒(méi)有損壞。到目標(biāo)機(jī)器后按順序合并cat backup_000 backup_001 backup_002 backup_003 backup_004 restore.sql最后再用md5sum對(duì)比原始哈希和目標(biāo)文件的哈希。一致才允許導(dǎo)入數(shù)據(jù)庫(kù)。為什么選擇500MB而不是更大或者更小因?yàn)?.3GB整體傳容易在長(zhǎng)連接中斷開重傳成本高而500MB一塊傳完每塊不到一分鐘即使中途斷了只需要重傳這一塊。塊數(shù)也不至于太多5塊剛好是一個(gè)人可以手工跟蹤的數(shù)量級(jí)。這里的核心思路是失敗粒度最小化寧可多傳幾塊也不要整體大文件一次傳輸失敗就前功盡棄。5.2 日志文件按時(shí)間切分分析有一次處理apache的access.log文件有1.8GB里面混了一整年的訪問(wèn)記錄。如果單純用split -l按行數(shù)切雖然文件變小了但每個(gè)塊里可能跨越好幾個(gè)日期按天統(tǒng)計(jì)還是得重做。這種場(chǎng)景更適合用awk按日期字段直接切分。Apache日志每行格式大致如10/Oct/2024:13:55:36 0800日期在第四個(gè)字段。一條awk命令就能把所有行按日期歸類awk {print day_ substr($4,2,11)} access.log這條命令會(huì)讀取每一行取第四個(gè)字段去掉左方括號(hào)后的前11個(gè)字符比如10/Oct/2024把它作為文件名的一部分每行追加到對(duì)應(yīng)日期的文件里。跑完之后目錄里就是day_10/Oct/2024這種按天命名的文件處理起來(lái)非常舒服。這種方案比split -l更精細(xì)但前提是日志格式穩(wěn)定字段位置固定。如果日志格式被程序改過(guò)、時(shí)間戳位置不同awk腳本也得跟著調(diào)整。日常排查時(shí)我一般先head看兩行確認(rèn)字段格式再寫awk命令免得拆完才發(fā)現(xiàn)日期字段對(duì)不上。5.3 超大視頻分卷外送給客戶交付15GB的拍攝素材是另一個(gè)高頻場(chǎng)景。客戶那邊明確要求不接收單個(gè)超過(guò)1GB的文件我就用7-Zip做分卷。先把素材目錄選中右鍵添加到壓縮包格式選7z壓縮級(jí)別選僅存儲(chǔ)因?yàn)橐曨l素材本身已是壓縮編碼再壓也壓不出多少空間純浪費(fèi)解壓時(shí)間。分卷大小填1G點(diǎn)確定。生成的文件是素材.7z.001、素材.7z.002、素材.7z.003到001為止一共15個(gè)分卷。把分卷逐個(gè)拷給客戶同時(shí)額外生成一個(gè)校驗(yàn)文件Get-FileHash -Algorithm SHA256 素材.7z.001然后通知客戶把所有分卷放在同一個(gè)目錄雙擊第一個(gè)分卷解壓。這里有個(gè)容易被忽略的體驗(yàn)問(wèn)題15個(gè)分卷散落在聊天記錄或者郵件里客戶下載時(shí)很容易漏掉其中一個(gè)。我的做法是把所有分卷統(tǒng)一放一個(gè)文件夾再用普通方式壓縮這個(gè)文件夾成一個(gè)套殼文件這樣客戶只需要下載一個(gè)殼再解壓內(nèi)部就行。雖然多了一次解壓步驟但減少漏卷的概率交付體驗(yàn)反而更好。5.4 Git倉(cāng)庫(kù)大文件不該用split還有一種場(chǎng)景很多人會(huì)誤入歧途Git倉(cāng)庫(kù)里的模型文件太大push之后發(fā)現(xiàn)超限第一反應(yīng)是把它拆成小文件再提交。這個(gè)思路是錯(cuò)的。split適合解決的是傳輸和存儲(chǔ)介質(zhì)限制不能解決Git倉(cāng)庫(kù)膨脹的問(wèn)題。就算把200MB的模型文件拆成10個(gè)20MB的文件Git倉(cāng)庫(kù)里依然存著200MB的二進(jìn)制數(shù)據(jù)歷史記錄里還是會(huì)保留每一版完整的模型文件。倉(cāng)庫(kù)體積照樣飛速膨脹克隆速度越來(lái)越慢Git服務(wù)端的限制照樣可能觸發(fā)。正確的解法是使用Git LFS把大文件指針存入倉(cāng)庫(kù)、真實(shí)數(shù)據(jù)存到遠(yuǎn)端存儲(chǔ)服務(wù)。已經(jīng)在歷史記錄里的超大文件則可以通過(guò)git filter-repo這類工具重寫歷史讓倉(cāng)庫(kù)瘦身。這個(gè)案例想說(shuō)明的是split是一個(gè)文件層面、傳輸層面的工具遇到什么問(wèn)題先判斷問(wèn)題出在哪一層。物理存儲(chǔ)和傳輸受限用split合理版本管理工具自身的限制應(yīng)該用對(duì)應(yīng)工具鏈解決拆文件只是治標(biāo)不治本。6. 常見問(wèn)題與排查技巧實(shí)錄6.1 高頻問(wèn)題速查表整理幾個(gè)我實(shí)際踩過(guò)或者被同事問(wèn)得最多的問(wèn)題按現(xiàn)象-原因-解法列成表方便速查?，F(xiàn)象原因解法合并后文件無(wú)法打開或提示損壞分塊順序錯(cuò)亂或漏了分塊重新按數(shù)字順序合并先ls確認(rèn)分塊列表合并后文本出現(xiàn)亂碼Windows/Linux換行符差異或UTF-8多字節(jié)被切斷文本文件優(yōu)先按行拆split -l盡量不要用按字節(jié)拆文本cat part_*合并時(shí)結(jié)果文件比預(yù)期大通配符匹配到了其它無(wú)關(guān)文件分塊移入干凈目錄再合并或顯式列出分塊文件名split -b后分塊數(shù)超過(guò)文件名容量塊數(shù)超過(guò)后綴位數(shù)文件名溢出用-d -a 3或更大位寬提前預(yù)留空間某個(gè)分塊傳輸后校驗(yàn)失敗網(wǎng)絡(luò)傳輸中數(shù)據(jù)損壞重新傳輸該分塊傳輸后立即校驗(yàn)hashFAT32 U盤無(wú)法拷貝超過(guò)4GB的文件文件系統(tǒng)限制用7-Zip分卷或split切成小于4GB的塊分卷壓縮包解壓時(shí)提示缺少分卷某個(gè)分卷沒(méi)有放在同一目錄把全部分卷放同一目錄用第一個(gè)卷解壓6.2 實(shí)操中反復(fù)踩過(guò)的坑第一個(gè)坑是拆分前沒(méi)做哈希記錄。很多人圖省事文件切完就把原始文件刪了等合并時(shí)發(fā)現(xiàn)某塊壞了想核對(duì)數(shù)據(jù)對(duì)不對(duì)卻沒(méi)有任何基準(zhǔn)。我的習(xí)慣是先跑一遍md5sum或sha256sum把哈希寫進(jìn)文件再動(dòng)手拆花費(fèi)不到一秒鐘后續(xù)能省一整晚。第二個(gè)坑是對(duì)文本文件用了按字節(jié)拆。有一次拆一個(gè)UTF-8編碼的SQL備份按字節(jié)拆分后某幾塊的末尾出現(xiàn)了半個(gè)中文字符導(dǎo)入數(shù)據(jù)庫(kù)時(shí)直接報(bào)錯(cuò)。UTF-8的多字節(jié)字符可能被拆到兩個(gè)分塊里造成單塊文件本身編碼不合法。從源頭上規(guī)避文本文件就按行拆除非你能接受合并時(shí)先拼接再處理編碼問(wèn)題。第三個(gè)坑是合并時(shí)忽略了分塊文件順序。我見過(guò)有人手工拼接上百個(gè)分塊排序規(guī)則沒(méi)想清楚把第10塊接到了第9塊前面最終文件整個(gè)不可用。正確做法是提前統(tǒng)一命名固定數(shù)字后綴位數(shù)合并時(shí)先ls檢查再用腳本按順序處理不要依賴肉眼確認(rèn)。第四個(gè)坑是傳輸過(guò)程中有一塊出了問(wèn)題但所有人沒(méi)察覺。文件切小了確實(shí)降低單次傳輸失敗的概率但并不能保證網(wǎng)絡(luò)一定不出錯(cuò)。所以大文件拆完傳輸時(shí)每傳完一個(gè)分塊就順手校驗(yàn)一次哈希比最后合并完再發(fā)現(xiàn)數(shù)據(jù)壞了效率高得多。傳完一塊校驗(yàn)一塊雖然增加了一點(diǎn)操作量但排查范圍直接被限定到單個(gè)分塊定位成本極低。最后一個(gè)坑也是最隱蔽的磁盤空間沒(méi)有提前規(guī)劃。合并后的文件大小等于所有分塊之和需要預(yù)留同樣大小的空間。我遇到過(guò)有人在剩余空間只剩7GB的目錄里合并一個(gè)6GB拆分文件最終合并到一半磁盤滿了前功盡棄。給合并操作留出至少1.2倍目標(biāo)文件大小空間算是安全經(jīng)驗(yàn)。最后說(shuō)點(diǎn)個(gè)人體會(huì)。文件拆分這個(gè)事工具本身非常簡(jiǎn)單真正值錢的是合并策略和校驗(yàn)意識(shí)。我見過(guò)太多人拆完就刪原文件結(jié)果一個(gè)月后想還原發(fā)現(xiàn)某個(gè)分卷早丟了徹底抓瞎。所以實(shí)操上我有個(gè)習(xí)慣拆分前先算一個(gè)大文件的哈希存到文本里拆分后把分卷名、大小、塊數(shù)抄到一個(gè)README文件和分卷放在一起。這樣無(wú)論過(guò)了多久、換不換機(jī)器拿著README就能無(wú)損還原。再分享一個(gè)我常用的省事技巧就是前面提到的邊拆邊壓縮。split的--filter參數(shù)是真的好用一行命令把大文件切成多個(gè)小段的同時(shí)完成壓縮傳輸時(shí)既能續(xù)傳又能省帶寬這個(gè)技巧我在多個(gè)項(xiàng)目里穩(wěn)定跑了很多年強(qiáng)烈建議你試試。