Airbnb Tech Blog Safeguards changes in production 1
Airbnb Tech Blog Safeguards changes in production 2
Airbnb Tech Blog Minerva
Airbnb 公開的資訊中有兩個地方他們在生產環境用到了 DuckDB。
Airbnb 開發了一套安全部署系統,處理他們快速擴展所帶來的生產環境變更風險,特別是如何在變更進入生產環境後迅速偵測並解決問題(東西壞了,可以快速定位甚至可以靠這套系統自動 roll back)。
可以想像得到這套系統需要很多 real-time 的計算,不出意外的是這套系統的主要架構就是 Flink + Kafka。 Kafka 作為 Airbnb 部署的 logging store , 不間斷的把資料餵給 Flink sink 成 Parquet 丟到 S3 上面.
We leverage Flink’s built in support for parquet and S3 as a file sink to write the files. In order to provide exactly-once semantics, Flink will only write files when checkpointing occurs. Files output by the NRT pipeline are consumed by the ramp controller to make decisions. To keep our latency low, we checkpoint every 5 minutes.
有了 S3 上的 Parquet 接著就是 DuckDB 登場的時候,
Once the files are downloaded the job leverages duckdb’s parquet reader functionality to aggregate to the user level. Once we have a local user aggregate the job evaluates the various sequential models discussed in the first post.
這邊不得不提到 DuckDB 最被廣為使用的一個功能,Out of the box 的 AWS S3 Parquet 分析能力,S3 是現在雲儲存的事實標準,Jeff Bezos 對 S3 的最初設計規格非常清楚簡潔 —— 他希望打造一個 Web 版 malloc(C 語言記憶體分配函數)。 確實辦到了 👍
我在 Day01 的時候已經不小心先用了 DuckDB 分析 S3 Parquet 的這個功能。
...
FROM 'https://ironman24.douenergy.com/employees.parquet'
...
我把一個叫做 employees.parquet 放到 S3(事實上是 Cloudflare R2)上面, DuckDB 看到一個 https 的 url prefix 跟看到 parquet 做為檔案名稱結尾,就知道用去那個 endpoint 下載 parquet 當作 FROM 的 source TABLE。
各位可以在昨天有提到 DuckDB WASM shell 試試看怎麼查詢這個 parquet
'https://ironman24.douenergy.com/employees.parquet' 的所有員工姓氏與薪水
試試看裡面的空白要填什麼