Instagram 改善影片上架速度的方式

不是什麼魔法,其實是改產品面上的規格 (但是發表到 Instagram Engineering 上):「Video Upload Latency Improvements at Instagram」。



The idea is, instead of blocking until all video versions are available, we can publish the video once the highest-quality video version is available.

然後是把影片切段上傳,所以傳一半就可以先處理一半,變成 pipeline 的概念,但增加程式的複雜度,以及被迫要調整影片品質的參數:

Segmented uploads reduce upload latency in many cases but come with a few tradeoffs. For instance, segmented uploads increase the complexity of the pipeline. There are some quality metrics that are only available per segment at transcode time, such as SSIM. These metrics are not helpful to us on a per segment basis. Therefore, we need to do a duration weighted average of the SSIM of all segments to come up with the SSIM of the whole video. Similarly, handling exceptions is more complex since there are more cases to handle.

另外有一種特例是上傳的影片本身就已經符合伺服器的規格,這樣的話可以直接放行 (不過這樣不會有 security concern 嗎...):

Another performance optimization we use to improve the upload latency and save CPU utilization is something we call a “passthrough” upload. In some cases, the media that is uploaded is already ready for playback on most devices.

都是想的出來而且會帶有 tradeoff 的方法,而不是完全正面的改善 :o

幫你的 iPhone 電話簿找到對應的頭像

前幾天看到的:「Announcing Vignette」,透過 social network 的資料,把本來電話簿裡面的 icon 更新:

透過 app store 的搜尋找不太到,我一開始用了「Vignette」搜不到,但用「Vignette Update」就可以。或者你可以透過他提供的連結直接開 app store:「Vignette – Update Contact Pics」。

這是一個 IAP 類的付費服務,搜尋是免費的,但如果要把資料更新回通訊錄,需要付 USD$4.99 (一次性),台灣帳號是付 TWD$170,應該是因為最近的稅務調整:

Vignette allows you to scan your contacts and see what it can find for free. If you wish to actually save these updates to your contact list, you must pay for a one-time in-app purchase. That purchase costs $4.99, is not a subscription, and is the only in-app purchase.

搜尋的範圍包括了 GravatarTwitterFacebookInstagram

Email is used for Gravatar
A custom network called Instagram

另外作者有提到這個 app 不傳資料到伺服器上,都是在自己的裝置上連到上面提到的 social network 尋找:

Privacy is paramount
All the processing is done on-device; this isn’t the sort of app where your contacts are uploaded en masse to some server, and out of your control.


Instagram 解決 Cassandra 效能問題的方法

在解決 Cassandra 效能問題中大概就 ScyllaDB 特別有名,用 C++ 重寫一次使得效能大幅改善。而 Instagram 的人則是把底層的資料結構換掉,改用 RocksDB (這公司真的很愛自家的 RocksDB...):「Open-sourcing a 10x reduction in Apache Cassandra tail latency」。

主要原因是他們發現 Cassandra 在處理資料的部份會有 JVM 的 GC 問題,而且是導致 Cassandra 效能差的主要原因:

Apache Cassandra is a distributed database with it’s own LSM tree-based storage engine written in Java. We found that the components in the storage engine, like memtable, compaction, read/write path, etc., created a lot of objects in the Java heap and generated a lot of overhead to JVM.

然後在換完後測試可以看到效能大幅提昇,也可以看到 GC 的延遲大幅降低:

In one of our production clusters, the P99 read latency dropped from 60ms to 20ms. We also observed that the GC stalls on that cluster dropped from 2.5% to 0.3%, which was a 10X reduction!

比較一下這兩者的差異:在 ScyllaDB 是全部都用 C++ 改寫 (資料結構不換),這樣就直接解決掉 JVM 的 GC 問題。在 Rocksandra 則是在 profiling 後挑重點換掉 (這邊看起來是處理資料的 code,直接換成 RocksDB),另外順便把一些界面抽象化... 兩個不一樣的解法,都解決了 JVM 的 GC 問題。


TechCrunch 這篇「Trump and Clinton spent $81M on US election Facebook ads, Russian agency $46K」講到 Facebook 目前階段所判斷出來,能夠識別是俄羅斯政府投入的資金,只有 USD$46K,相較於美國兩黨投入了 USD$81M 差了 1760 倍:

While there might have been other Russian disinformation groups, the IRA spent $46,000 on pre-election day Facebook ads compared to $81 million spent by Clinton and Trump together, discluding political action committees who could have spent even more than that on the campaigns’ behalf.

而俄羅斯投入的廣告散佈率超過 1.26 億的 Facebook 使用者,以及 2000 萬 Instagram 的使用者:

Facebook today said that the Russians still reached 126 million Facebook users, as well as 20 million Instagram users.

俄羅斯這團隊的水準真不賴... 只可惜大概沒辦法寫在 resume 上。


拍照後讓程式自動人肉搜索 Social Network 上的照片...

在 social network 上掃了一堆照片後,路上隨便拍照讓程式自動人肉搜索找出可能的對象:「Russian photographer matches random people with social network photos」。

這個計畫叫做「YOUR FACE IS BIG DATA」,作者的照片來源是來自俄羅斯最大的社交網站 VKontakte,而計畫的網站在「Конец анонимности: Идентификация случайных попутчиков」這邊,可以連進去看他自動找出來的圖。

演算法本身並不難,有種老大哥計畫的感覺... 可以想像 FacebookInstagram 或是 VKontakte 如果自己做了之後拿給政府單位用的情況?

新版 Instagram 將可以看到影片播放次數了

Mashable 的報導說下個版本的 Instagram 將會提供影片播放次數資訊了:「Instagram videos will get cool new updates to let you see how popular you are」。

The number of times a video is viewed on Instagram will soon no longer be a mystery.

Instagram is adding a new feature that will tally view counts much like parent company Facebook already does, eliminating a major blindspot for marketers attempting to tap into the app's 400-million strong audience organically.

愈來愈多 social network 往 video 這塊著力...

Google Chrome 上看連線是使用 IPv4 或是 IPv6

想說應該會有 extension 可以看連線是 IPv4 或是 IPv6,找了一下果然有:「IPvFoo」。

右上角會出現目前連線的屬性。透過 Google Chrome 提供的 webRequest 取得資訊後更新上去的。

目前比較常見的站台應該是 Facebook (包括 Instagram)、GoogleYahoo,也剛剛好都是 HTTPS Policy 的先驅... 不過可以看出來不是所有的資源都走 IPv6,還是有不少走 IPv4 的 domain。

Twitter 的主網站沒有 IPv6,但幾個自己的子網域有?看起來還在逐步測試開通...

HiNet 的 IPv6 服務已經可以透過網路櫃台直接線上申請 (需要幾個工作天開通),我用 Ubuntu 可以 PPPoE 取得...

Instagram 的 Hyperlapse

Instagram 上星期推出了 Hyperlapse:「The Technology behind Hyperlapse from Instagram」。

如果講得很簡略,就是「防手振的錄影 app」,可以直接看 Instagram 提供的範例影片:

文章裡面還解釋了很多原理,有興趣的人可以看看 :p

Instagram 從 AWS 搬到 Facebook 機房

InstagramInstagram Engineering Blog 上宣佈的消息:「Migrating From AWS to FB」。

整個 migration 的過程是採取不停機轉移,所以 effort 比直接停機轉移高很多:

The main blocker to this easy migration was that Facebook’s private IP space conflicts with that of EC2. We had but one route: migrate to Amazon’s Virtual Private Cloud (VPC) first, followed by a subsequent migration to Facebook using Amazon Direct Connect. Amazon’s VPC offered the addressing flexibility necessary to avoid conflicts with Facebook’s private network.

先把整個系統轉移到 Amazon VPC 裡,然後再拉 AWS Direct Connect 串起來,接下來才是慢慢把 instance 轉移到 Facebook 的機房內。


To provide portability for our provisioning tools, all of the Instagram-specific software now runs inside of a Linux Container (LXC) on the servers in Facebook’s data centers.

所以已經導入 LXC 了...

Instagram 說明用 PostgreSQL 的五個優點...

先不管 Instagram 最近的負成長以及反駁,剛剛在 Instagram Engineering 上看到對 PostgreSQL 的稱讚:「Handling Growth with Postgres: 5 Tips From Instagram

FacebookMySQL 的領域裡的實力以及貢獻度可是數一數二,但 Instagram 在被 Facebook 買下後仍然繼續使用 PostgreSQL,總是有些原因存在... 雖然真正的原因不一定是技術,但這篇試著用技術解釋的內容還是可以看一看,了解 PostgreSQL 有哪些特點...

第一個是講 partial indexes,這與 MySQL community 常講的 partial index 是不同的東西。

MySQL 的 partial index 是指只 index 某個欄位的一部分,像是 VARCHAR(255) 裡面只 index 前面的 10 chars;而 PostgreSQL 的 partial indexes 則是指符合某個條件的 row 才 index。

第二個是 functional indexes,可以針對欄位計算後再 index。MySQL 的 partial index 在 PostgreSQL 裡可以用 functional indexes + substr() 達到相同的效果,而且還有其他 function 可以用,花樣更多。

兩個都是 MySQL 做不到 (或是做不好),但 PostgreSQL 做的不錯的。一般在 MySQL 要達到 PostgreSQL 的這兩個功能需要另外開一個欄位,在裡面儲存去正規化後的值,再對這個欄位 index。

第三個是講 defrag 的事情,這部份 MySQL 也可以用第三方的工具 Percona Toolkit 搞定。第四個講 PostgreSQL 的 Write-Ahead Log,有點像是 MySQL 的 binlog。最後一個講 Python 上的 psycopg2

看來看去就是 index 那塊最明顯。可以直接減少去正規化的欄位...