Netflix的首頁是經過客製化的，會根據使用者的喜好有不同的外觀，當然，推薦影片的種類也會完全根據使用者的偏好。要做到這種程度，是因為在系統背後有一個應用程式會根據各種演算法將好的UX遞送給使用者。

這個應用程式稱為RMI (Real-time Merched Impression)，其架構如下。

graph TD
    imp[Impression Source] --> kb1[KeyBy] --> join[Join] --> rmi[RMI Sink]
    pb[Playback Source] --> kb2[KeyBy] --> join

這篇是翻譯Netflix最近釋出的Psyberg系列文，同時也會補充一些相關的資訊。

最主要的出處是以下三篇：

• Streamlining Membership Data Engineering at Netflix with Psyberg
• Diving Deeper into Psyberg: Stateless vs Stateful Data Processing
• Psyberg: Automated end to end catch up

引言

Apptio是一間做企業IT管理解決的公司，旗下有數款方案針對敏捷開發流程的管理軟體。在2023年六月，被IBM重金收購，從其端出牛肉到出關只有幾年的時間，本身就是一間很敏捷的公司。

他們寫了一篇關於如何加速軟體開發的方法論，並且鉅細靡遺的描繪各種軟體開發場景，是一篇非常值得一讀的文章。

以下翻譯自：8 Ways to Crank Up Speed in Software Development

導讀

在討論數據品質(Data Quality)前，我們往往是看著別人提出的品質指標，並且想方設法的套進自己的組織內，但這樣的流程是不對的。即便是Uber這種已經建立完整監控數據品質架構的公司，也不是一步登天的。

事實上，Uber也經過很長一段時間去摸索該如何設定指標以及如何建立架構，因此我們看到的一套完整架構也是根據組織內部的需要逐步調整最後才能貼合現實。

翻譯自：Uber Tech Blog

Uber在全球市場能有效維運線上環境歸功於數以百計的服務、機器學習模型和成千上萬的資料集。當成長突飛猛進時，Uber透過維護數據品質來提供優秀的商業決策。若是沒有數據品質保證，下游的服務和機器學習模型成效會顯著下降，這需要很多額外操作才有辦法回填那些髒資料。最糟糕的是，這有可能會根本無法被察覺，而變成隱形殺手。

這促使Uber建立一個數據品質平台(UDQ)來監控這些問題。為了資料品質能夠達標，UDQ支援超過2000個重要資料集，被且偵測到超過90%的資料問題。這篇文章會描述Uber怎麼定義數據品質標準，以及如何整合工作流程以便良好維運。

這篇文章會從Elasticsearch的底層實作解釋應用程式要怎麼做會更好，但我不打算使用很晦澀的方式來描述太深入的細節，因此我會盡量使用簡化過的流程來說明。

在開始之前讓我們先來了解Elasticsearch幾個重要的術語。

• Index：這就像是RDBMS的table或是MongoDB的collection，不要和RDBMS的index混淆了。
• Shard(或稱Primary Shard)：資料要寫入index的存取點，當然也能夠讀取資料。
• Replica：讀取資料的存取點，無法用來寫入資料。

這幾個術語跟今天的三個技巧息息相關。

在講解小紅書導入HTAP的過程之前我們先來簡單介紹一下小紅書。

小紅書號稱是中國版的Instagram，但除了一般的影音圖文分享等社群功能外，還包含電商營運平台等。根據小紅書的官網，截至2019年為止，活躍用戶已經破億了。

既是社交平台又是電商平台，每天產生的資料量是億級。為了要支援資料驅動決策，這些海量資料必須經過多層的清洗、轉換和聚合，更重要的是，決策的實時性也需要關注。

除此之外，小紅書的應用場景和用戶數都持續增長，因此整個資料基礎建設的擴充性也是一大挑戰。

最終，小紅書採用了TiDB作為他們實時串流的存儲。

技術階梯

之前身為EM的時候(Engineering Manager)很喜歡在1對1會議上問團隊成員一個問題：把能力分成幾個象限，你會各給自己幾分？你預期要達到幾分？

這套流程我很喜歡，能夠有效在1對1會議上開啟一個有用的對話，並且也能同步彼此的認知以及安排未來的職涯發展和工作規劃。

事實上，這樣的作法並不是我獨創的，也有很多制式的模版，在Github上甚至也有人開源一個工程端的泛用型的模版。

這篇文章是對這個模版的翻譯。

在上一篇文章我們提到主任工程師的四種角色，在這篇文章中我們對工程端的常見四個角色定義其能力象限。

• Developer：另外常見的稱呼有programmer或軟體工程師，這角色需要有很深的技術底子。
• Tech Lead：這就上一篇文章提過的角色，算是系統的擁有者之一，需要兼顧實際開發、架構知識以及線上環境維運。
• Technical Program Manager：TPM是驅動跨工程團隊協做的先鋒，為的是讓產品走向不至於與技術脫節。
• Engineering Manager：部門的管理者，負責讓部門維持和諧氣氛以及提昇部門的技術水準。

主任工程師的種類

大部分公司內的生涯階梯(career ladder或說職涯規劃)都對主任工程師(staff engineer)定義了一組一致的標準。每個人都希望能從這清楚的標準中知道公司內的權責，但我們要知道，這標準其實是一般性的，不是為了每個人量身訂做的。對於主任工程師來說更是如此，一個主任工程師的權責往往結合了數種角色，很難被清晰定義。

不過這其中還是有規則可循的，大部分主任工程師的權責其實都能被歸納出一些模式，了解這些模式能更有效了解主任工程師這個角色。大致上來說有以下這四種。

• Tech Lead：負責引導特定團隊，有點像是管理職，但多數時候這個角色會負責複數個特定領域。有些公司也會賦予這個角色管理權限，使其更貼近管理職，可以招聘、打考績等。
• Architect：架構師負責確保某些關鍵系統的方向、品質和策略。這個角色必須同時具備深厚的技術底子並了解商業需求，甚至要領導組織決策。
• Solver：這常被稱為救火隊，負責處理複雜難解的問題以及給予適當方向，有時候這角色會在特定領域深耕，但也有可能會隨著組織需要輪調。
• Right Hand：這像是經營高層的左右手，具有一定的決策權。當要運作一個大型組織，這角色會扮演中樞角色，用來快速做出正確決策。

對於電商來說，大促是很重要的，無論是中文圈的1111或外語區的黑色星期五，這些大促事件基本上可以為店家帶來鉅額收益，甚至一天就佔一年GMV的兩成以上。

當然，大促期間也會伴隨巨大的流量，並為電商網站帶來嚴重挑戰。因此，這篇文章我會就我看到的資訊來介紹Shopify如何應對大促事件。

在開始談論技術細節前，我們先來看一些Shopify在2022黑色星期五的數據。

• 在每分鐘3 TB的egress流量下維持99.999+%的uptime。
• MySQL的尖峰QPS超過14M，平均也超過8.5M。
• 尖峰時刻每秒索引16G的log。
• 為了監控擴充性和可用性，每分鐘收集20B以上的運維指標，並且每秒儲存27G的指標資料。
• 全站QPS為1.27M。
• 透過Resque處理超過32B個非同步任務。
• 傳送超過24B個webhook。
• 批次的資料管線總共寫入1.1T個訊息。
• 尖峰時刻Kafka每秒處理20M個訊息。

有鑑於繁體中文的資源太少，我想或多或少做點翻譯，把一些有用的文章和書籍翻成中文。

當然，會以我日常閱讀為主，主要是架構師、大數據相關的。

順便測試一下放圖片。