Meta (Facebook) 把 MySQL replication 丟上自製的 Raft 系統

看到「Building and deploying MySQL Raft at Meta」這篇,在講 Meta (Facebook) 把 MySQL 的 replication 架構換成自己用 Raft 的系統。

舊的系統是走 MySQL 的 semisync replication:

Previously, our replication solution used the MySQL semisynchronous (semisync) replication protocol.

其中 semisync replication 是在 MySQL 5.5 加入的功能,在至少一個遠端收到 replication log 後才傳回成功 (可以設定數量):「Semisynchronous Replication」。

Semisynchronous replication falls between asynchronous and fully synchronous replication. The source waits until at least one replica has received and logged the events (the required number of replicas is configurable), and then commits the transaction.

然後舊的系統是透過一包 Python 軟體在管理這些機器的各種 failover 操作:

The control plane operations (e.g., promotions, failover, and membership change) would be the responsibility of a set of Python daemons (henceforth called automation).

這個方法常遇到的問題是切換 primary server (以前叫做 master server) 時有可能會因為 binlog position 接不起來而失敗。

所以後來 MySQL 導入了 GTID,可以緩解這個問題,但還是有可能會發生不同的 secondary server (以前叫做 slave server) 會有不一樣的資料。

而在 Meta 改出來的架構裡面,把 replication data 直接寫到一個用 Raft 同步的系統,同步到其他的 secondary server 上面:

In MySQL Raft:

  • Primary writes to binlog via Raft, and Raft sends binlog to followers/replicas.
  • Replicas/followers receive in binlog and apply the transactions to the engine. An apply log is created during apply.
  • Binlog is the replicated log from the Raft point of view.

是個一般單位不太會遇到的架構,而且可以預期其他公司的人遇到類似問題應該也不會用這個方法解...

玩最近 Facebook Research (Meta) 放出來的 LLaMA

很多地方應該都有提到 Facebook Research (Meta) 放出來的 LLaMA 了,對應的論文是「LLaMA: Open and Efficient Foundation Language Models」這篇,但這邊論文提到的 open 並不是一般常見的 open 定義,而只是常見的行銷詞彙而已,實際上只是 free for charging with constraints。

另外要注意 LLaMA 是個 LLM 而已,跟 ChatGPT 不算是同樣性質的東西,能對比應該是 GPT-3 (或是 GPT-3.5)。

主要是 ChatGPT 多了 SLRL 的步驟,而產出來的東西更接近商業化產品要的結果。

LLaMA 的特點在於效能不錯,可以用 LLaMA-13B 打贏 GPT-3 (175B),另外這次訓練出來最大的 LLaMA-65B 則可以站上第一梯隊 (與 DeepMindChinchilla-70BGoogle ResearchPaLM-540B):

LLaMA-13B outperforms GPT-3 (175B) on most benchmarks, and LLaMA-65B is competitive with the best models, Chinchilla-70B and PaLM-540B.

但跟以前差異最大的是,這次 Facebook Research 決定把訓練完後的 model 檔案放出來,所以就有了後續很多的進展:

We release all our models to the research community.

首先一開始 Facebook Research 要求使用者填表單才提供下載 (2/24 的時候),但三月初的時候 GitHub 上有人直接把 BitTorrentmagnet 連結附上去,送了一個 pull request:「Save bandwidth by using a torrent to distribute more efficiently #73」,所以你就有「方法」可以取得 model 檔案,但還是可以注意一下使用限制:

To maintain integrity and prevent misuse, we are releasing our model under a noncommercial license focused on research use cases. Access to the model will be granted on a case-by-case basis to academic researchers; those affiliated with organizations in government, civil society, and academia; and industry research laboratories around the world. People interested in applying for access can find the link to the application in our research paper.

除了可以透過 BitTorrent 下載外,comment 裡面也有 IPFS 的連結可以下載。

有需要下載這包檔案的人要注意檔案很大,大約 240GB,其中 65B model 佔了 128GB 左右。

被放出來以後就開始有很多人在上面包起來用,其中目前比較完整的應該是「Running LLaMA 7B and 13B on a 64GB M2 MacBook Pro with llama.cpp」這篇提到的方法,裡面提到的 ggerganov/llama.cpp 專案同時支援了 WindowsmacOSLinux,而且可以用 CPU 跑,速度也不慢。

試著用 llama.cpp 跑,65B 的 model 在家裡桌機有 64GB RAM 的情況下是可以應硬扛的,跑降到 4bits 的 model 大約吃 41GB RAM 左右。

比較驚訝的是 efficient 這個部份,拿 CPU 跑 65B 版本是跑得動的。

隨便丟個「文字接龍」進去 LLaMA-65B 讓他接,可以看到接出來的東西還可以:

main: prompt: 'The main difference between javascript and java are '
main: number of tokens in prompt = 10
[...]

The main difference between javascript and java are 1)Java is a compiled language while JavaScript
is not. So that the performance of Javascript code can be lower than Java Code, but they run on different platforms: browser vs server or local machine;
2)'javac' to compile .java file to bytecode(for JVM), and 'jar'(to make executable jar files for client systems).
3)Java uses more memory (RAM) that javascript. So the Javascript code is generally small than Java
codes.(A web application written in JavaScript may run faster on a PC with 64 MB of RAM compared to one running using applets.) While an advantage offered by J

如果是 LLaMA-7B 的話會快很多,但回答就有點微妙了:

main: prompt: 'The main difference between javascript and java are '
main: number of tokens in prompt = 10
[...]

The main difference between javascript and java are 1) Javascript is interpreted, while Java compiles to native machine code. (Compiled languages have a performance advantage over Interpreted ones
.)
2) The language standardization process for JavaScript has not been completed at the time of this writing which leaves it open to being hacked or changed by those who care enough about your website to do so... In Java, everything is set in stone. (Or at least as much code that can be shipped on a CD-ROM disk)
Sorry if my response was not clear - but you're right! I think that "2" above should really have said: "(

訓練所花的資源的部份,可以從論文裡面看到,如果是 2048 張 A100 的話大約要跑五個月 (照這個語氣,實際上大概不是這個數字):

Finally, we estimate that we used 2048 A100-80GB for a period of approximately 5 months to develop our models.

另外也有列出 GPU hours 可以參考:

Facebook 使用 AV1 的記錄

Facebook 整理了一份他們採用 AV1 的記錄:「How Meta brought AV1 to Reels」,要注意這邊的產品線是短影片類型。

因為之前剛好也有碰到 codec 這塊,但最後是因為 AV1 在 client 的支援度還跟不上,而選了在 Android 上支援度更好的 VP9

在文章前面有提到 server 端的需求,也就是 encoder 的部份,這是因為 AV1 的 encoding 真的很慢 (i.e. 外星技術),還在每過幾個月就會看到 encoder 技術重大突破的階段,所以得花時間去研究。

Facebook 後來決定用 SVT-AV1,因為效能上好很多 (以他們測試的那個時間點):

At any given point on the y-axis, SVT-AV1 can maximize encoding speed compared with any other production encoder. For example, the M8 preset is about as efficient as libvp9 preset 0, but M8 is almost 10 times faster.

而在 client 端的 decoder 部份,他們評估了 dav1dlibgav1 之後,選擇用 dav1d (iOS 與 Android 都是):

Two major open source software decoders are compatible with multiple platforms: dav1d was developed by VideoLAN and the open source community and can serve as an app-level decoder, while Google’s libgav1 is integrated into the Android SDK.

[W]e decided to integrate dav1d into the player for both iOS and Android platforms.

但在軟解的情況下只能解 720p30,然後中高階的才能解 1080p30,不過這對於短影片來說夠用:

dav1d can support 720p30 real-time playback on most of the devices in our sample, achieving 1080p30 on certain mid-range and high-end models.

所以就 Facebook 目前提供的資料來看,這部份還沒到輕鬆應對的情況,還得繼續看各家 library 的進展...

John Carmack 離開 Meta (Facebook)

這幾天另外一個比較大的人事變化,John Carmack 決定離開 Meta (Facebook):「I resigned from my position as an executive consultant for VR with Meta.」,裡面直接提到的是效率問題,但應該是搞不定政治問題。

接下來他會跑去搞自己在八月弄的新創 Keen Technologies,主打 AGI 主題,八月當時的新聞在這:「John Carmack’s AGI startup raises $20M from Sequoia, Nat Friedman, Patrick Collison and others」。

不過有個好奇的點,是這篇的 url 是不帶 encrypted tracking parameters 的,這是怎麼拿到的...

美國人使用社群媒體的情況

在「Social Media Usage by Age」這邊看到的文章,把美國人使用社群媒體的情況做成圖,資料來源是 Pew Research Center 的「Social Media Fact Sheet」這裡。

很明顯的可以看到 Google (Alphabet) 基本上就是 YouTube 一個產品吃天下,而 Facebook (Meta) 有三個產品在滲透,包括 Facebook、InstagramWhatsapp

LinkedIn 在出社會後會開始用,另外 Pinterest 這麼多老人家在用到是很驚奇 XDDD

HTML 裡 head 的整理...

HEAD - A free guide to <head> elements」這篇整理了 HTML 裡 <head> 的標準,以及網路上夠大的廠商所定義的標準 (另外還把中國的瀏覽器也拉出來)。

從目錄就可以看出來講了哪些:

另外一種看法就是,你要怎麼樣讓你的 <head> 塞滿垃圾然後變得很肥... XD

GitHub 的 Webhook IP 增加網段

GitHub 發出的 Webhook 的來源位置增加網段了:「Webhook IP addresses are changing」。

目前是 192.30.252.0/22,在 2019/04/09 後將會增加 140.82.112.0/20,如果有用防火牆的人需要修改設定,把多的這段加上去。

去年就把這個網段放進 API 裡,但一直都還沒啟用,所以如果你有透過 API 動態更新防火牆規則的話就沒問題,現在是最後登機廣播了:

This block of IPs has been in the /meta API endpoint since May 2018, but we wanted to announce this update in case you missed it.

HTTPS 因為安全性而不能使用 Referrer 的問題

Nuzzel 上看到老文章在討論 HTTPS 環境下因為安全性考量,而不能帶出 Referrer 的問題:「Where did all the HTTP referrers go?」。

原文中「Fixing Referrers in HTTPS: The Meta Referrer」這邊就有提到 HTML5 meta referrer,也就是 W3C 的「Referrer Policy」,問題是到現在還是 Draft 啊...

也因為過了三年,其實 draft 裡面多了不少參數可以用:

  • neverno-referrer 表示不傳。
  • origin 表示只傳 protocol + host 的部份,後面 path 的部份不要傳。
  • defaultno-referrer-when-downgrade 表示當 downgrade 時 (HTTP request 的部份) 不要傳。
  • origin-when-cross-origin 表示當跨站時用 origin 的邏輯,但本站還是用完整的路徑。
  • always 或是 unsafe-url 則是永遠都傳。

其中刪節號表示 W3C 不建議再使用,應該用後者比較新的。

不過因為在 Can I use 上面可以看到 Microsoft Edge 只支援舊的關鍵字 (也就是刪節號的那些),所以還是可以考慮先用舊的關鍵字,讓 Microsoft Edge 也可以被保護到:「Referrer Policy」。