摘要：雲上遙感影像檔案Cloud optimized GeoTIFF（COG）格式的詳細介紹，大量資料上雲面臨的挑戰，并分享了獲得雲原生影像最佳性能的實踐經驗。
本文分享自華為雲社群《COG雲原生優化遙感影像，瓦片切分的最佳實踐》，作者： tsjsdbd 。
遙感影像就是地球自拍照，一般檔案很大，一張檔案5GB左右。
這些影像檔案大多數都儲存為 TIFF 格式（而不是JPEG），因為TIFF格式記錄的内容是比較原始的多個波段的資訊，也不會因為壓縮丢失資訊。
這裡分享一下 TIFF檔案的格式：
TIFF是一個靈活适應性強的檔案格式，能夠在一個檔案中儲存多幅圖像。然後每幅影像帶一個标簽目錄（多個标簽），記錄它的像素深度、每像素波段資訊，RGB編碼等詳細資訊。
注意：上圖屬性之間沒有順序要求，都通過offset查找。實際上是連結清單的形式：
是以，TIFF檔案内部各Block塊之間的順序可以很靈活自由。
每幅影像，帶有一組标簽目錄，記錄該圖形的各種屬性。
标簽目錄的格式如下：
每個标簽（屬性），由于資訊内容不一樣，其值大小有差別。有些資訊小，它的标簽值（Value）直接在标簽裡面。有些資訊量比較大的，它的标簽值（Value），在标簽裡放不下，需要記錄在檔案的其他位置上，通過offset便宜對應。
1個标簽，就是記錄圖檔的一個屬性。主要是：屬性名+屬性值。
具體格式如下：
一般一幅圖檔，大概10幾個屬性。
可以看到，整個TIFF檔案，是分塊分散的記錄圖像資料的。所有資訊之間都是通過offset偏移量關聯。
ps：這裡我先給“分塊分散”标個粗。 這是它靈活性的優勢，也是後續主題要讨論的。
關于TIFF詳細格式，可參考：https://www.jianshu.com/p/ff32eb09ed3d
正是因為TIFF這種标簽化的格式，非常的好擴充，為圖檔添加地理資訊也很友善。 是以GeoTIFF就在TIFF的标簽規範裡面，增加一系列（地理資訊相關的）擴充标簽，用來記錄一幅影像的地理坐标資訊。
可以看到，一個GeoTIFF，也是正常的TIFF檔案。是以它的内容，也是分散分塊在檔案内儲存的。隻是多了一系列的地理資訊标簽。
所有标簽解釋，見：https://www.loc.gov/preservation/digital/formats/content/tiff_tags.shtml
由于TIFF檔案内部都是連結清單的形式，是以檔案标準中并沒有要求各Block塊之間彼此的順序。
有時候它是這樣的：
更常見的則是這樣的：
少數還有可能是這樣的：
無論哪種組織形式，都是符合标準的TIFF檔案。
由于我個人的程式設計語言是GO語言，是以這裡我選用了https://github.com/google/tiff
這個包（谷歌開源的TIFF檔案解析包），函數調用使用 tiff.Parse() 就行。
解析完打個斷點，就可以看到TIFF檔案的各種屬性啦：
上圖可以看到，目前分析的這個TIFF檔案裡面，有5幅圖檔。
如上圖，第一幅圖檔，有21個屬性。這是原始圖檔，帶有地理資訊屬性（标簽ID值大于3000），各屬性如下：
其餘的4幅，都隻有15個屬性。是 overview，沒有地理資訊，單純的圖檔（不帶Geo地理屬性，标簽ID都是 2xx~3xx的），如下：
我們打開其中一個标簽，看它的值：
這裡看到這個屬性ID是256，查詢規範：
得知這個表示圖檔的寬度，然後大小端屬性，我們算出：第2個位元組是28，第1個位元組是174，實際值等于：28 * 256 + 174 = 7342 像素的寬度。
可以檢視實際圖檔的像素，就是 7342。
其餘屬性，都可以按照這個方式一一檢視。
遙感影像的特點，主要是大。一般一張圖檔在5~10GB，單衛星每天增加TB級，全球每天增加PB級。随着衛星傳感器精度增加，單個影像檔案越來越大。
大，帶來的問題就是不容易儲存，本地資料中心存不下，就得上雲。但是大量的遙感資料上雲後，面臨不少挑戰：
大量的既有軟體，無法遠端讀取雲上的（特别是對象存儲，如S3）影像檔案。必須先Download到本地，然後才能打開分析。
即使為軟體增加S3驅動。遠端分析一個檔案，也不得不全量讀取檔案内容（因為它是連結清單式的檔案）。注意這個是通過網絡進行的，是以很影響效率。
單獨取影像檔案中的部分區域（瓦片，或者縮略圖），也不得不全量下載下傳or通路整個檔案。即使瓦片僅占全影像的1/N。
是以，能不能在通路雲上的遙感影像資料的時候，隻通路部分（盡可能小的）内容呢？
要達成這個目的，需要有以下能力：
雲存儲協定上支援以 Range方式讀取雲上的檔案。
GeoTIFF影像檔案，支援先讀取“所有标簽資料”，然後以Offset偏移讀取目标資料。
這2個條件裡面的第1個，目前各大雲廠商的對象存儲（如S3）都已經支援。
關鍵是第2個條件。首先，能不能把GeoTIFF的“中繼資料”，全部放到檔案頭部，把實際Data資料放到檔案尾部。
即：
這樣的話，通路一個超大的GeoTIFF遙感影像，隻需先發送HTTP GET擷取檔案頭部16K位元組，然後檔案中剩餘内容位置就都知道了。接下來想要通路什麼，再根據偏移，發送HTTP GET通路目标XX位元組的影像資料，就夠了。
然後，将圖像切成小片，可以根據“瓦片”的方式通路目标區域。因為已經有了頭部的标簽資訊，是以再通路具體區域，隻需要根據Offset，直接讀取雲上檔案的指定偏移就行。
在這種模式下，該遙感影像檔案，還是一個标準的GeoTIFF格式，隻是它更适應雲化通路。
為了讓雲優化的GeoTIFF格式更加的普及，專門成立了COG（Cloud optimized GeoTIFF）标準。規範可以參考：https://www.cogeo.org/
介紹文章可以參考：https://medium.com/planet-stories/cloud-native-geospatial-part-2-the-cloud-optimized-geotiff-6b3f15c696ed
目前該标準得到了業界很多公司的認可：
重要的是，一個COG影像檔案，也是一個标準的 GeoTIFF檔案，可以相容已有的各種軟體生态。
TIFF 和 GeoTIFF和COG 這三種檔案格式之間的關系。
有了COG檔案格式的背景介紹，接下裡我們詳細分析一下一個COG檔案，怎麼樣才能做到雲化性能最優？
一幅影像檔案，目前遠端讀取的最常用的底層庫就是 gdal了。它在第一次通路檔案的時候，預設是先取 16KB的内容。大多數的GeoTIFF檔案頭，取16KB肯定是夠了的，如下（取1次頭就可以Open）：
但是也有些GeoTIFF檔案資訊太多，使得檔案頭很大。gdal就會不得不再次取一次檔案頭，如下圖（取了2次頭才能Open）：
2次HTTP請求，才能獲得完整的TIFF檔案頭，顯然通路效率大打折扣。
這個時候，就得通過底層 gdal庫的配置，來控制首次擷取檔案頭的位元組數了。
環境變量：GDAL_INGESTED_BYTES_AT_OPEN=2000
可以使得首次請求的時候，擷取更大的檔案頭，如下圖：
但是如果影像檔案的實際頭都很小，你首次取太大肯定也浪費。
是以請根據自己的影像規格，以及影像的屬性，恰當的選擇首次取檔案頭的位元組數。避免每次都額外發送一次HTTP請求，浪費效率。
一圖影像，舉個例子，原始像素是 512*512的圖檔。
如果我們按照 256*256的Tile（瓦片）進行儲存，那麼就會有4個瓦片。
如果按照 512*512的Tile（瓦片）儲存，那麼隻有1個瓦片。
這2種儲存方式，會導緻檔案頭需要記錄的“資訊量”不一樣。4個瓦片，就得記錄4個偏移量。1個瓦片則隻需要記1個偏移量。
這裡以一個5GB左右大小的GeoTIFF檔案舉例，按照128*128像素進行瓦片，那麼所有的瓦片偏移值如下：
（标簽ID=324，代表TileOffsets，值為8位元組的整型。）
是以為了記錄所有瓦片資訊：65905(瓦片數) * 8(位元組) = 527240，就要520KB。
如果按照256*256的瓦片儲存，則可以直接減少到1/4，記錄所有瓦片的偏移資訊隻需要520KB / 4 = 130KB。可見适當加大瓦片面積，可以縮小TIFF檔案頭大小。
但是瓦片又不能太大，因為這會影響取局部區域的像素效率問題。
如下圖舉例：
如果目标區域在一個小瓦片範圍内，則瓦片大小為256*256的話，取回的檔案内容，就很小。 而512*512的話，一次取回就得整個大瓦片。顯然網絡傳輸效率會降低很多。
下面我們詳細分析性能vs瓦片大小的影響，分别以：
gdal預設tile大小256*256。
rio預設tile大小 512*512。見：https://github.com/cogeotiff/rio-cogeo
gdal指令：
rio指令：
如果你僅有gdal，也可以通過以下指令：
來控制瓦片大小。
gdal指令，可以通過docker直接獲得：
啟動gdal容器的時候，隻需要使用 -v 将主機目錄，挂載到容器内就行。例如我的：
這樣容器裡面的/tmp/cog目錄下，就可以看到主機/home/tsjsdbd裡的tiff檔案了。
下面來對2種做對比，詳細操作如下:
512*512瓦片：
第2次通過HTTP響應取回來：105119744-105840639 = 720,895 位元組
256*256瓦片：
可以看到，第2次請求的内容，小很多：139476992-139722751 = 245,759 位元組
對比發現，256的瓦片，第2次HTTP響應隻有1/3，延時也是優勢明顯。
第2次通過HTTP響應取回來：32522240-33095679 = 573,439 位元組
同樣的，第2次取的内容，小很多：41402368-41533439 = 131,071 位元組
同樣，256的瓦片，第2次HTTP響應大小隻有1/3，延時也是優勢明顯。
官方測試報告裡面（見：https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF ）
顯示 512*512 的瓦片大小，性能更優，是因為，
256*256的小瓦片，導緻TIFF檔案頭太大了。第1次16KB取不完，又取了1次導緻的。
Ps：首次取的位元組數，是可以通過配置控制的。
是以實際業務場景下，具體以多大的瓦片劃分，要根據項目影像圖檔特征适當的調整。
性能對比看，256*256的小瓦片，在做局部線上Web預覽加載時，性能更優異。
但是 256*256 的瓦片，意味着瓦片數量更多，TIFF檔案頭更大，是以需要适當控制“首次取檔案頭位元組”配置。
上述GDAL操作步驟可以參考：https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF
其他GADL配置調優可參考：https://developmentseed.org/titiler/advanced/performance_tuning/
分享了GeoTIFF影像檔案上雲後的一系列最佳實踐後，我們探讨一下，未來在COG性能方面，有沒有雲廠商提供更加深度優化方式呢？
可以想到的有：快速的獲得COG檔案頭大小，使得首次HTTP請求，精确取想要的資料，不浪費額外的網絡封包。不過這種就需要對象存儲提供一些定制能力了。
COG已經是業界普遍認可的雲原生的遙感影像資料格式，未來一定可以更加的普及，并且發揮更大的價值。其他有好的想法，也歡迎探讨分享。
華為雲地理遙感平台GeoGenius，經過多年的技術項目積累，采用了業界最佳的雲原生的遙感影像管理實踐，并且提供端到端最優的性能體驗，歡迎領域同行了解使用。
詳見：https://www.huaweicloud.com/product/geogenius.html
點選關注，第一時間了解華為雲新鮮技術~