這裡是 WWW 第貳拾壹期，Wow Weihang Weekly 是一個毫無章法的個人週刊，出刊週期極不固定，從一週到五年都有可能。初期內容以軟體工程為主，等財富自由後會有更多雜食篇章。

The Best Medium-Hard Data Analyst SQL Interview Questions

作者總結自己的面試和工作經驗，整理出 Data Analyst 和 Data Scientist 的 SQL 面試題，著重在 self-join 和 window function 的相關練習。雖然 SQL 能力不是應徵資料分析職位的關鍵因子，我覺得反而是資訊工作者不可或缺的基本能力，從行銷、產品經理到工程師都應該要會 SQL DQL（Data Query Language），才能從報表、產品或系統看出洞見 。

Anxiety in product development

本文透過幾個行為觀察，分析是否掉入 anxiety driven development 的無限迴圈，這裡來個超譯摘要：

  • 害怕輸輸去： 怕失去市佔、怕失去顧客、跟著競爭對手的 feature 跑，導致產品開發看似 agile 其實更不穩定，總是晚一個世代，將創新扼殺在時間漩渦。
  • 一心只想贏： Unique Selling Proposition（UCP）可以理解為產品在市場上的生態區位，可以說是「獨特賣點」，利用 UCP 是好事，但以價格創造的 UCP 最羸弱，最沒使用者忠誠，最容易被其他人宰割。
  • 並非發光的都是金子： 著急業務落後者容易短視近利，這種短期勝利可能只是短暫消除焦慮感，卻讓整個團隊陷入愁雲慘霧，回饋感漸低，特別是在專案尾聲想偷渡 feature 而不是留 buffer。
  • 掌舵： 主要是說退一步並勾勒出真實的展望，並以此影響策略，（對不起這已超出我能理解的範圍，請自行看原文）
  • 不可能的承諾： 焦慮讓你想要找回掌控權？你會開始將流程官僚化，寫下每個 ticket 細節與需求，這反而嚴重打擊各位的動機。
  • 脫離官僚： 信任帶來新幸福，信任你的市場研究和策略，信任你的團隊的專業和洞見，讓他們自行成為一個有機體。

Things I Wished More Developers Knew About Databases

世界上大多數的開發者都碰過資料庫，但其實對資料庫一知半解，常常各種掉資料或是 deadlock。來自 Google 的 @rakyll 列出一些和資料庫相關常見的誤解和經驗，其實每個主題都可以獨立寫篇文章，以下稍微摘要：

  1. **當 99.999% 的時間網路不構成問題時，恭喜！你很幸運： **網路非常不可靠，從硬體，拓撲到鯊魚咬電纜（台灣人早就知道會咬了），而且網路掌控在大型企業或雲端供應商手中，對開發者來說很難鑑定其錯誤。
  2. 一個 ACID，各自表述： 不是所有資料庫都符合 ACID，宣稱符合 ACID 的資料庫也不一定行為正確，這裡 MongoDB 的沒開 journal 60 秒才 fsync 一次的事件又被拿出來鞭屍，當然，最近 Jepsen 幹爆 MongoDB 4.2.6 的事件也可以關注一下。
  3. 每個資料庫能達成的一致性和隔離性程度不同： ACID 的 Consistency 和 Isolation 的光譜其實很廣，而且這兩個特性其實很貴，所以不同資料庫的 tradeoff 不盡相同，可以參考 Jepsen Consistency Model 還有各資料的 Isolation Level 大表看看你要什麼
  4. 不適用 exclusive lock 時，樂觀鎖是個選項： 樂觀鎖是一種在讀取 tuple 時先記錄 checksum/timestamp/version 資訊，寫入時再檢查 tuple 的這些資訊是否改變來決定寫入與否（但要注意 isolation level 和 dirty read 的關係，如果 write 太多可能樂觀鎖效能會較差）
  5. 除了 dirty read 和 data loss，還有更古怪的事： 前兩者可以透過注意鎖和 race condition 來避免，但 read/write skew 這種邏輯錯誤更難發覺。
  6. 我的資料庫和我在執行順序上無法總是達成共識： txn 的順序是依照接收到 txn 順序執行，而非 code 撰寫順序，如果有不同的操作需要保證順序，請包入同一個 txn。
  7. application-level sharding 可以實作在應用層之外： 例如額外的 sharing service 處理這塊，application 還是處理商業邏輯就行，像 YouTube 底層的 Vitness ，或是 Shopee 底層的 TiDB 的底層 TiKV 都是箇中高手。
  8. AUTOINCREMENT 有害論： 在分散式系統不易生成正確的 AUTOINCREMENT ID、當作 partition key 可能會產生 hotspot、有其他 unique key 是 AUTOINCREMENT key 就是廢物
  9. 資料雖過期但有用（而且是 lock-free）： MVCC 可以達到 Repeatable read isolation level，對 read-heavy app 或是 globally distributed app 能有效降低延遲。（代價就是偶爾要跑 GC 或 VACUUM）
  10. 時間會在不同來源間扭曲： 所有時間 API 都在說謊，就算用 NTP 服務還是有網路延遲。作者在這邊偷偷推銷 Google 的 TrueTime，但有趣的是 API 回傳是個 time range，當前時間就落在這個範圍中。
  11. 我都把「延遲」念「延遲」： latency 在不同領域意義不同，client latency = database latency + network latency，服用前請看說明書。
  12. 評估效能該考慮 per transaction 等場景的需求： 幫自家資料庫打廣告時不能只著重在 read/write throughput，應還要設計不同的場景、constraint、transaction 才能，脫離應用場景的 benchmark 都是流氓。
  13. nested transaction 有害論： nested txn 會導致非預期的行為，例如 如果 inner txn 錯誤 rollback，那 outer txn 該 rollback 嗎？如果是開發 request-response 的 web app，我自己會傾向一個 request-response 就是一個 txn。
  14. transaction 不該管理應用層的狀態： 如果一個 txn 改變的 global state 但是 txn failed，retry 第二次時哪個 global state 就和第一次不一致了。
  15. query planner 能協助理解資料庫： 可以知道到底是 table scan 還是 index scan 等來決定 SQL 怎麼寫可以最佳化。
  16. online migration 複雜但可行： 拆成一個個可復原的小步驟，dual write -> change read -> change write -> remove old model，可以參考 Stripe 怎麼做，當然，還有 code-first 和 data-first 等不同的 migration mode。
  17. 可觀的資料庫成長所帶來的狀況難以預測： 這正是為什麼我們要在 scaling 前各種 migration/refactor/rewrite，不要以為你懂資料庫底層運作就很屌，從 hotspot、data 分佈不均、容量硬體、流量網路 partition，Scale will introduce new unknowns。（然後各種 data model 到部署流程和大小都要改變）