【💊 Python的解憂錦囊】如何使用Buffer流將檔案分段上傳至Minio

更新於 發佈於 閱讀時間約 4 分鐘
raw-image


MinIO 是一個高性能的物件存儲系統,設計用於大規模的數據存儲需求, 甚至是各種非結構化數據也都能往這邊儲存, 也支持群集擴展, 非常適合正在尋找儲存方案的朋友們。


我們在「【💎 Message Queue - Kafka 案例篇】如何將檔案流上傳到minio - 完整檔案 」介紹了如何從kafka將資料流到minio, 但該篇的主軸在於完整的檔案一次上傳, 這一次我們要來鑽研一下如何模擬本地檔案串流上傳到minio的過程, 接著我們會另外撰寫一篇主題來談談如何結合kafka。


我們今天的主題來談談如何使用Python將檔案「串流」上傳到minio,為什麼要特別提到串流? 主要是隨著時代的演進, 應用逐漸從批次處理轉為即時處理, 使用者體驗逐漸強調「即時」, 而背後的技術從應用程式、訊息佇列、資料庫、儲存媒介也都開始支持「串流功能」, 今天我們將針對「MinIO」這套媒介進行「串流」功能的介紹, 並實際使用「Python」進行展示。


環境準備

這邊我們使用docker來運行minio, 並提供docker compose的配置檔如下:

 minio:
image: minio/minio:latest
container_name: minio
ports:
- "9000:9000"
- "9001:9001"
environment:
MINIO_ACCESS_KEY: minioadmin
MINIO_SECRET_KEY: minioadmin
command: server /data --console-address ":9001"


接著請啟動服務:

docker compose up -d


啟動服務之後我們就準備開始實作囉!


安裝套件

這邊我們需要安裝一下Minio Client才能由客戶端進行檔案上傳。

pip install minio



設定minio連線資訊並創建Bucket

client = Minio(
endpoint='minio:9000',
access_key='minioadmin',
secret_key='minioadmin',
secure=False,
)

bucket_name = 'files'

# 建立儲存桶
if not client.bucket_exists(bucket_name):
client.make_bucket(bucket_name)


設計內部Buffer流

這個內部Buffer流主要做為minio put_object與記憶體之間的檔案封包橋樑, 我們可能會從本地檔案、kafka、遠端伺服器拉取檔案封包, 我們可以將這些檔案封包暫存在我們記憶體實作的I/O流, 讓minio client自動去分塊上傳, 避免大檔案要一次拿取完才能上傳到minio伺服器。


這個Buffer流的實作是關鍵重點的部份, 它就像接水管一樣, 將來源與目的橋接, 順利讓資料流入, 大致上的設計草圖如下:

raw-image


程式碼如下:

raw-image



引流並上傳到Minio

我們將上傳到minio的部份用另外一個執行緒去進行, 這是因為我們必須讓讀寫分離才能夠很好的實驗控制的邏輯。


當我們讀完「【💎 Message Queue - Kafka 案例篇】如何將檔案流上傳到minio - 完整檔案 」 都知道上傳的關鍵函數是「put_object」, 它可以接入一條資料水管, 正好將我們設計的資料水管給接入看看。

raw-image



驗證成功與否

我們試著打開Monitoring → Trace來追蹤上傳的狀況, 這邊我們可以看到每5MB一包為單位進行上傳的過程。

raw-image



最後上傳成功才會出現檔案如下:

raw-image



結語

處理部份上傳的部份也真是不容易啊! 過程中不斷的翻閱官方文檔與試誤, 最終勉強的試出一條可以用Buffer流控制分段上傳的實現方案, 也讓我們更深入的了解到put_object的使用方式。


留言
avatar-img
留言分享你的想法!
avatar-img
阿Han的沙龍
132會員
299內容數
哈囉,我是阿Han,是一位 👩‍💻 軟體研發工程師,喜歡閱讀、學習、撰寫文章及教學,擅長以圖代文,化繁為簡,除了幫助自己釐清思路之外,也希望藉由圖解的方式幫助大家共同學習,甚至手把手帶您設計出高品質的軟體產品。
阿Han的沙龍的其他內容
2025/01/29
🤔 簡單且靜態就足夠了? 相信我們在開發Python應用程式的過程中, 常常會借用Enum來定義我們可能的選項, 就像顏色紅、綠、黃會有這樣的結構: class Color(str, Enum): RED = 'red' GREED = 'green' YELLOW = 'yel
Thumbnail
2025/01/29
🤔 簡單且靜態就足夠了? 相信我們在開發Python應用程式的過程中, 常常會借用Enum來定義我們可能的選項, 就像顏色紅、綠、黃會有這樣的結構: class Color(str, Enum): RED = 'red' GREED = 'green' YELLOW = 'yel
Thumbnail
2025/01/08
當我們的系統發展到一定程度時, 難免會面臨到正式上線的問題, 要如何讓維運更加簡易呢? 尤其隨著複雜的客製化配置的出現時, 我們應該如何有效的管理, 甚至驗證配置是否如預期資料型態、格式…, 而正好 pydantic 可以滿足這樣的需求, 就讓我們來看看怎麼使用吧! 需安裝的套件 pip i
Thumbnail
2025/01/08
當我們的系統發展到一定程度時, 難免會面臨到正式上線的問題, 要如何讓維運更加簡易呢? 尤其隨著複雜的客製化配置的出現時, 我們應該如何有效的管理, 甚至驗證配置是否如預期資料型態、格式…, 而正好 pydantic 可以滿足這樣的需求, 就讓我們來看看怎麼使用吧! 需安裝的套件 pip i
Thumbnail
2025/01/02
要如何使用unicorn啟動多個FastAPI服務, 歡迎參考我們的「【💊 Python的解憂錦囊 - FastAPI】如何啟動多個Workers」。 當我們試著設計帶入模組化時… 我們在「【💊 Python的解憂錦囊 - FastAPI】使用 lifespan 來共享資料與管理生命週期
Thumbnail
2025/01/02
要如何使用unicorn啟動多個FastAPI服務, 歡迎參考我們的「【💊 Python的解憂錦囊 - FastAPI】如何啟動多個Workers」。 當我們試著設計帶入模組化時… 我們在「【💊 Python的解憂錦囊 - FastAPI】使用 lifespan 來共享資料與管理生命週期
Thumbnail
看更多
你可能也想看
Thumbnail
我們在學習kafka的過程中最不習慣的就是不管什麼樣的資料, 在kafka的傳輸過程都會是binary的資料格式, 因此我們在撰寫程式的過程中並不是那麼的直觀, 必須將資料從float、int…資料型態轉型成binary才能順利傳送, 那麼基於這樣的前提之下, python這套程式語言可以怎麼做
Thumbnail
我們在學習kafka的過程中最不習慣的就是不管什麼樣的資料, 在kafka的傳輸過程都會是binary的資料格式, 因此我們在撰寫程式的過程中並不是那麼的直觀, 必須將資料從float、int…資料型態轉型成binary才能順利傳送, 那麼基於這樣的前提之下, python這套程式語言可以怎麼做
Thumbnail
我們在「【Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有介紹如何架設kafka, 其中我們使用環境變數來進行kafka的配置, 但除了環境變數之外, 其實還能夠用檔案配置的方式來對kafka進行配置, 如此一來我們就可以將配置檔與啟動檔完全分開,
Thumbnail
我們在「【Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有介紹如何架設kafka, 其中我們使用環境變數來進行kafka的配置, 但除了環境變數之外, 其實還能夠用檔案配置的方式來對kafka進行配置, 如此一來我們就可以將配置檔與啟動檔完全分開,
Thumbnail
情境描述 我們在「🔒 阿Han的軟體心法實戰營 - kafka」有關於kafka的教學文章, 那麼在開發過程中我們遇到了 👻 詭異事件, 那就是我們嘗試在做一個檔案串流時, 發現Producer明明傳送了大約16MB檔案大小的封包到kafka, 每一包約(1024 * 1024 ) bytes
Thumbnail
情境描述 我們在「🔒 阿Han的軟體心法實戰營 - kafka」有關於kafka的教學文章, 那麼在開發過程中我們遇到了 👻 詭異事件, 那就是我們嘗試在做一個檔案串流時, 發現Producer明明傳送了大約16MB檔案大小的封包到kafka, 每一包約(1024 * 1024 ) bytes
Thumbnail
為什麼會有Schema Registry的出現? 因為Kafka的零拷貝原則, 也就是kafka本身並不會去碰觸到訊息也不進行資料驗證, 而是bypass的傳送, 預設都以位元組來傳輸資料會比較有效率, 但位元組誰看得懂啊...。 加上Kafka的特性是生產者與消費者並不能直接溝通, 因
Thumbnail
為什麼會有Schema Registry的出現? 因為Kafka的零拷貝原則, 也就是kafka本身並不會去碰觸到訊息也不進行資料驗證, 而是bypass的傳送, 預設都以位元組來傳輸資料會比較有效率, 但位元組誰看得懂啊...。 加上Kafka的特性是生產者與消費者並不能直接溝通, 因
Thumbnail
更快、更短、更即時是串流傳輸必要的元素, 而我們常常在使用Python請求API時都是等待式回應, 也就是一個請求過去之後, 待對方處理完畢後再行回應, 但假設需要下載的檔案、內容非常大時, 是不是使用者只能傻傻的等待整個傳輸結束後才能顯示? 這樣的使用者體驗也實在太糟糕了, 對於使用者來說除了完全
Thumbnail
更快、更短、更即時是串流傳輸必要的元素, 而我們常常在使用Python請求API時都是等待式回應, 也就是一個請求過去之後, 待對方處理完畢後再行回應, 但假設需要下載的檔案、內容非常大時, 是不是使用者只能傻傻的等待整個傳輸結束後才能顯示? 這樣的使用者體驗也實在太糟糕了, 對於使用者來說除了完全
Thumbnail
Lua 開檔寫檔的運用 io.output()...
Thumbnail
Lua 開檔寫檔的運用 io.output()...
Thumbnail
我們在「【🎓 Python的深度問答集】torchaudio 對部分段落進行音訊解碼」有分享到如何對一包包的封包進行音訊解碼, 但隨著音檔越大, 最終解碼的速度會越來越慢, 而這並非串流的本意, 串流應該就像水管一樣, 收到多少資料就運算多少量, 並不會隨著累積的容量越大而導致效能下降。 但實際
Thumbnail
我們在「【🎓 Python的深度問答集】torchaudio 對部分段落進行音訊解碼」有分享到如何對一包包的封包進行音訊解碼, 但隨著音檔越大, 最終解碼的速度會越來越慢, 而這並非串流的本意, 串流應該就像水管一樣, 收到多少資料就運算多少量, 並不會隨著累積的容量越大而導致效能下降。 但實際
Thumbnail
訊息的即時傳遞已然成為現代社會的趨勢了, 而扮演中樞平台的系統架構功能也漸趨複雜完整, Kafka是一個事件流平台, 正好滿足串流時代之下的即時訊息傳遞架構, 因此我們有必要深入來學習這套事件流平台, 不論是自動化、金融交易、IOT、物流…皆離不開即時的需求, 所以就讓我們蹲好馬步來好好的學習一
Thumbnail
訊息的即時傳遞已然成為現代社會的趨勢了, 而扮演中樞平台的系統架構功能也漸趨複雜完整, Kafka是一個事件流平台, 正好滿足串流時代之下的即時訊息傳遞架構, 因此我們有必要深入來學習這套事件流平台, 不論是自動化、金融交易、IOT、物流…皆離不開即時的需求, 所以就讓我們蹲好馬步來好好的學習一
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News