估算 YouTube 影片總量的方式

Hacker News Daily 上看到「How big is YouTube? (ethanzuckerman.com)」這篇,原文在「How Big is YouTube?」。

算是個老問題了,而且應該是統計學上比較簡單的方法。先列出作者最後的成果:「TubeStats」。

作者用的方法是觀察 YouTube 的 vid:

Here’s how this works: YouTube URLs look like this: https://www.youtube.com/ watch?v=vXPJVwwEmiM

可以分析出來 vid 包括了 64-bit 的資訊,這個資料型態對工程師來說,看起來就很像是 uniformly distributed:

That bit after “watch?v=” is an 11 digit string. The first ten digits can be a-z,A-Z,0-9 and _-. The last digit is special, and can only be one of 16 values. Turns out there are 2^64 possible YouTube addresses, an enormous number: 18.4 quintillion. There are lots of YouTube videos, but not that many. Let’s guess for a moment that there are 1 billion YouTube videos – if you picked URLs at random, you’d only get a valid address roughly once every 18.4 billion tries.

然後就是隨機去產生 vid 去掃,這個方法跟 drunk dialing 的行為很像,算是 random sampling 的方式:

We refer to this method as “drunk dialing”, as it’s basically as sophisticated as taking swigs from a bottle of bourbon and mashing digits on a telephone, hoping to find a human being to speak to. Jason found a couple of cheats that makes the method roughly 32,000 times as efficient, meaning our “phone call” connects lots more often. Kevin Zheng wrote a whole bunch of scripts to do the dialing, and over the course of several months, we collected more than 10,000 truly random YouTube videos.

另外在 2011 年就有提出來利用 autocomplete 機制去算:

By comparing our results to other ways of generating lists of YouTube videos, we can declare them “plausibly random” if they generate similar results. Fortunately, one method does – it was discovered by Jia Zhou et. al. in 2011, and it’s far more efficient than our naïve method. (You generate a five character string where one character is a dash – YouTube will autocomplete those URLs and spit out a matching video if one exists.) Kevin now polls YouTube using the “dash method” and uses the results to maintain our dashboard at Tubestats.

目前他們的預估大約是 13B 左右的影片,換算大約是用掉 33.63 bits 了 (233.6):

In our case, our drunk dials tried roughly 32k numbers at the same time, and we got a “hit” every 50,000 times or so. Our current estimate for the size of YouTube is 13.325 billion videos – we are now updating this number every few weeks at tubestats.org.

而這邊提到的 32768 * 50k 會中一次的部分,這邊的大約是 30.61 bits,這樣加起來是差不多 64 bits 沒錯。

不過要注意的是,他們沒有給出 interval,所以 13B 的上下可能是一倍左右的差距 (6.5B~26B 之類的),這邊的數字當作概念比較好...

EC2 推出 18TB 與 24TB 的機器...

AWS 又把機器給生出來啦:「EC2 High Memory Update – New 18 TB and 24 TB Instances」。

一樣是限制要買三年 RI 才能用,不過價錢頁面上好像還在更新,在「Amazon EC2 Dedicated Hosts Pricing」只看到了之前就公佈的 12TB 價錢,還沒看到 18TB 與 24TB 的部份...

然後以前會跟同事說,資料小於這台機器記憶體大小的不能叫 big data (當時是 12TB),現在升級到 24TB 啦...

Twitter Moments 很大?

看到「How big is Twitter Moments?」這篇,在談 Twitter Moments

依照推算,Twitter Moments 的使用量應該比全世界任何一個媒體都大,但你會發現實際上沒有音量。沒有人談論他,沒有人引用他... 但估算起來他應該是超級大的產品?

有種「到底怎麼樣才算是一個成功的產品」的反思。

在 F5 設備上使用 Let's Encrypt 憑證

找資料的時候翻到 F5 官方有給一篇導引,介紹如何自動化 Let's Encrypt 的憑證:「Lightboard Lessons: Automating SSL on BIG-IP with Let's Encrypt!」。

在 F5 的 GitHub 上也有一包「f5devcentral/lets-encrypt-python」可以看看。

還沒仔細看 & 測試,但大概有些輪廓了。看起來要考慮到裡面用的 letsencrypt.sh 已經改名成 dehydrated,另外就是實際測試了...

其實憑證貴的不是費用,是跑採購流程的成本... 單 domain 的如果可以用 Let's Encrypt 解決的話會可以省下不少功夫。

Amazon Rekognition:圖片辨識 API

GoogleVision API,到 MicrosoftComputer Vision API (參考「微軟也推出圖片辨識的 API 了」),AWS 也推出類似的服務了:「Amazon Rekognition – Image Detection and Recognition Powered by Deep Learning」。

與其他兩家都是類似的方式,丟圖進去然後用系統已經 train 好的資料給你分析結果... 然後依照次數算錢。

有種算是補產品線的感覺啦...

透過 Deep Learning 辨識人臉馬賽克的技術

在某些新聞報導透漏出了受害者的某些背景身份,於是你手上有了這兩個資料:

  • 符合這些背景身份的四十個人的照片。
  • 人臉被馬賽克後的新聞照片。

現在的問題是,要怎麼判斷出新聞照片裡是哪個人:「Defeating Image Obfuscation with Deep Learning」。

類似這樣的實驗,從 40 個人中找出正確的人,有 50% 的正確率:

也許 50% 不算到能用的程度,但這代表老大哥的技術已經在發展了...

電子書在美國的販售管道與作者的獲利

在美國,五大出版商在電子書拆分上對作者佔的比例不斷的下滑,這也代表話語權不斷的下降,而且愈來愈不需要這些「大」出版商了:「Independent authors are starting to outsell the Big Five」。

這邊所提到的 Big Five 可以在「The Big Five Trade Book Publishers」這邊查到,分別是:

  • Hachette Book Group
  • HarperCollins
  • Macmillan Publishers
  • Penguin Random House
  • Simon and Schuster

另外也可以把 Amazon 當作是電子書產業的大公司。可以看到獨立發行的比率愈來愈高:

AuthorEarnings.com has published a report on this very subject, so I jumped into the data. Their May 2016 report reports 1340 authors earn over $100,000 per year on Amazon.com. The striking fact here: “Half of them are indies and Amazon-imprint authors.”

「出版社」的架構受到的挑戰愈來愈多了。

Humble Bundle 對抗信用卡盜刷的方法

Humble Bundle 說明他們如何對抗信用卡盜刷的方法,主要是不斷的降低風險,然後讓人介入的機會降低 (因為人事成本很高):「How Humble Bundle stops online fraud」。

其中第一點是特別想提的:

Our first line of defense is a machine-learning-based anti-abuse startup called Sift Science, which we’ve been training for years across 55,000,000 transactions. Given how many orders we process, Sift Science has a really good idea when someone is up to no good. The model adapts daily as we get more data.

Sift Science 在 2014 的時候提過:「偵測信用卡交易是否為盜刷的服務」。做的事情很簡單,你把大量的資料傳給 Sift Science,包括了各種使用者身份資訊,以及信用卡資料,Sift Science 可以透過 Machine Learning 的方法告訴你這筆交易的風險,讓你進一步的判斷。

其實不少家都有做類似的服務,像是 MaxMindminFraud (就是做 GeoIP database 很有名的那家公司的另外一個產品)。當交易量很大的時候是個很有趣的應用,降低處理盜刷後續處理的成本。

Amazon EBS 推出新磁碟種類

Amazon EBS 推出了新的磁碟種類,都是比現在更經濟 (白話文:更便宜) 的方案:「Amazon EBS Update – New Cold Storage and Throughput Options」。

第一種是 Amazon EBS Throughput Optimized HDD,代號是 st1;第二種是 Amazon EBS Cold HDD,代號是 sc1,兩種都是傳統磁頭硬碟。

第一種 st1 重視 sequential 的 throughput:

Starts at 250 MB/s for a 1 terabyte volume, and grows by 250 MB/s for every additional provisioned terabyte until reaching a maximum burst throughput of 500 MB/s.

第二種 sc1 則是重視堆資料的費用:

Designed for workloads similar to those for Throughput Optimized HDD that are accessed less frequently; $0.025 / gigabyte / month.

要注意的是,IOPS 是可以累計的,而未滿 1MB 的 access 會計算成 1MB,所以只適合大量 sequential access 的應用,像是 Hadoop 這類 big data 類的應用:

For both of the new magnetic volume types, the burst credit bucket can grow until it reaches the size of the volume. In other words, when a volume’s bucket is full, you can scan the entire volume at the burst rate. Each I/O request of 1 megabyte or less counts as 1 megabyte’s worth of credit. Sequential I/O operations are merged into larger ones where possible; this can increase throughput and maximizes the value of the burst credit bucket (to learn more about how the bucket operates, visit the Performance Burst Details section of my New SSD-Backed Elastic Block Storage post).

另外 sc1 也是目前每單位裡面最便宜的價錢,不知道拿來當 root 會底多慢 XDDD

Amazon S3 與 HDFS 的速度差異

作者繼續以 A Billion Taxi Rides 的資料測試各種差異,這次測了 Amazon S3HDFS 的速度差異:「A Billion Taxi Rides: AWS S3 versus HDFS」。

前半部都在說明測試的環境設定,重點在文章的最後面 (也就是「Benchmarking HDFS」這段),裡面有各種 query 的速度。HDFS 的速度大約是 Amazon S3 的 1.25 到 1.75 倍,作者給的結論是:

Though the speed improvements using HDFS are considerable, S3 did perform pretty well. At worst there's a 1.75x overhead in exchange for virtually unlimited scalability, 11 9's of durability and no worrying about over/under-provisioning storage space.

雖然 HDFS 比較快,但 Amazon S3 其實表現的不錯,另外資料安全性 (平均 99.999999999%,也就是 11 個 9 的 durability) 及不需要怕空間不夠的優點也是應該考慮進去的因素。