存儲技術日報Vol.20220913: 什麼是伯克利RISE Lab提出的下一代雲計算架構Sky Computing？
什麼是 arena-based memory management？
https://www.zhihu.com/question/541458151/answer/2564360250
arena-based memory management 本質上可以被視為一種記憶體池的實作方式。它的基本思路是預先配置設定一塊連續的大記憶體，後續的記憶體都從這塊記憶體中遞增配置設定。
通常的實作方式是一個指針數組，其中每個指針都指向一塊大記憶體，如下圖所示
配置設定的政策也非常簡單，從 cur_block_開始，找到第一塊可以容納所需要記憶體的塊，然後進行配置設定（沒有的話就重新配置設定一塊更大的記憶體，并加入到 blocks_中），并調整 cur_blocks_、next_loc_ 和 cur_block_end_的值。
這種記憶體管理的優勢之一就是非常快速， 這篇文章中作者 Hanson 論證了在某些情況下，Arena-based memory management 的每位元組配置設定速度甚至比已知最快的堆配置設定政策都要快。
它的另一個優點是，釋放記憶體時是直接釋放一整個塊，這也就使得位于同一塊内的對象具有相同的生命周期（與目前塊的生命周期相同）。這使得對于對象的管理更為簡單。同時對于 Rust 這類所有權管理非常嚴格的語言而言，使用 Arena-based 的管理方式可以更為簡單的實作諸如雙向連結清單這種具有循環引用的資料結構。在這篇關于 Ghost Cell 的論文中，作者就使用了 Arena 實作了雙向連結清單。
Arena-based memory management 的缺點也非常明顯，當你配置設定的對象大小變化幅度非常之大時，會有非常嚴重的記憶體碎片問題，同時由于釋放時是直接釋放一整個塊，是以你的整個 blocks_ 可能會變得非常大，因為其中包含了許多實際上已經不需要的可以釋放的對象。
應用此類記憶體管理政策的最佳情景應該是需要配置設定一系列大小相仿的、實際的生命周期也差不多的對象，這樣可以有效避免記憶體碎片和死資料。
什麼是伯克利RISE Lab提出的下一代雲計算架構Sky Computing？
原文位址: https://www.zhihu.com/question/533781841/answer/2541871219
在 Cloud Computing 時代，使用者大多是跟單一的雲廠商綁定，上雲本身就麻煩，雲廠商之間的遷移成本也很高；Sky Computing 的解決方法則是加入 Intercloud Brokers 解決 workloads 需要适配不同雲廠商規格的問題。
建構 Intercloud Brokers 并不簡單。除了對公有雲原有業務的封裝（從 IAM / Billing / Job API，到資源拉起和處置等等），還需要考慮不同種類 workload 跨雲的相容性。Broker 層的主要技術挑戰将來自優化器，優化器可以根據雲計算 workload 的特性生成不同執行計劃，是滿足業務要求下提高成本效益的關鍵。不過，由于圍繞雲計算有大量的開源項目存在，而很多開源項目都有完善的雲廠商生态支援，Intercloud Broker 的原型啟動起來相對容易一些。
論文作者們推測， Sky Computing 有兩個“殺手應用”：一個是大資料處理和機器學習，這些應用依托于開源項目，并且能夠通過跨雲提高成本效益；另一個是資料合規，brokers 在雲廠商之上支援相容集功能的設定，可以比客戶更靈活的适配不同地區的資料合規性需求。前者更多是技術問題，也是本文讨論的重點；後者則更多是商業和政策上的權衡。
其實在 Sky Computing 提出以前，像 Databricks 這樣的大資料産品早就做了“多雲整合”。但是在 Sky Computing 論文中，它們屬于 Portable multi-cloud 産品。
目前大火的 Data Warehouse（也包括所謂 Lakehouse）産品，其實本質上是把 Storage 和 Query & Processing 放在同一個 App 内。這些産品都支援從不同的雲廠商的産品作為資料源，并且可以做到像在同一個 SQL 執行個體一樣做無感覺的 workload。然而，雲廠商對使用者來說還是可感覺的，需要主動選擇雲廠商，管理資料源或使用 DW 自身的存儲。盡管像 Delta Lake，Hudi，Iceberg 這樣的項目為跨雲的分析型大資料處理提供了相對統一的 SQL 标準，但開源市場中還是缺少對雲計算 workload 多雲排程的管理。現有的 DevOps 工具也主要集中在底層 API（如容器排布和 EC 執行個體的管理），不能讓高層級的 Job API（如 BI 和 ML 任務）在多雲的情況下對底層無感覺。此外，Sky Computing 并不意味着将統一的 API 适配到所有雲廠商，特定的 workload 會通過 Broker 的優化器主動排程到相容且代價最優的雲産品上。
在 Sky Computing 論文之前，雲計算行業就已經有了這樣的觀點：未來的開發者們将不會直接接觸底層雲廠商，而是更多的接觸到雲廠商之上的 SaaS 軟體層。Intercloud Brokers 則是這個封裝的“終極形态”。在理想狀态下， Intercloud Broker、雲廠商、客戶的互相磨合，XaaS 服務可能會成為一個更細粒度的市場：雲廠商要麼專注于在 Intercloud 層通用的功能集，把它的成本做低、穩定性進一步增強，要麼提供更特制化的産品給細分場景使用；Broker 層則封裝不同雲廠商的差異化服務，并通過優化器進一步提高效率。然而，底層雲廠商在基礎服務（例如 S3 存儲，EC2 示例和 FaaS 等功能）已經鎖定了大額的利潤，内部很少有推動多雲的動力，而 Broker 層與底層雲廠商存在的競争關系會考驗 Sky Computing 的可落地性。RISE lab 的産學研優勢這次能否得到延續呢？
一個Go語言實作的流量回放工具
https://mp.weixin.qq.com/s?__biz=MzkyNzI1NzM5NQ==&mid=2247487474&idx=1&sn=99365a1fce202a91215b839c5a789fe6&utm_source=tuicool&utm_medium=referral
今天給大家推薦一款使用Go語言編寫的流量回放工具 -- goreplay ；工作中你一定遇到過需要在伺服器上抓包的場景，有了這個工具就可以助你一臂之力， goreplay 的功能十分強大，支援流量的放大、縮小，并且內建了 ElasticSearch ，将流量存入ES進行實時分析；
goreplay是一個開源網絡監控工具，可以實時記錄TCP/HTTP流量，支援把流量記錄到檔案或者 elasticSearch 實時分析，也支援流量的放大、縮小，還支援頻率限制； goreplay 不是代理，無需任何代碼入侵，隻需要在服務相同的機器上運作 goreplay 守護程式，其會在背景偵聽網絡接口上的流量， goreplay 的設計遵循 Unix 設計哲學： 一切都是由管道組成的，各種輸入将資料複用為輸出； 可以看一下官網畫的架構圖：