大家好，我們是 Berry AI 的 Software Team。

前面七天 ML Team 講的是怎麼把影像變成每一台車的旅程，昨天 Day 17 講的是上線之後怎麼持續確認這些數字準不準。數字準了之後，還要在使用者需要的時候送到他們手上，而且每個地方看到的要是同一個數字。接下來七天，我們介紹數據最後一哩路上的系統與挑戰。

同一個數字，三種人在三個地方看

先看一台車：中午開進得來速車道，排隊、點餐、取餐，整段過程前後幾分鐘。這幾分鐘的計時數字，有三種人會在不同的地方看到：

• 店員，在廚房的螢幕上。店內的即時看板 (Drive-thru Real-Time Dashboard) 顯示車道上每一台車已經等了多久，旁邊是車道的即時影像，店員靠它決定先處理哪一台。這裡的資料要在幾秒內更新，門市斷網的時候也要能用。
• 店經理，在隔天早上的信箱裡。開店之前就會收到一份 PDF 報表，昨天每個餐期的平均點餐時間、取餐時間都在上面。
• 品牌總部與加盟商，在瀏覽器裡的 BI 動態看板 (Berry Board)。總部看全品牌、加盟商只看自己的店，同一張報表，每個人看到的列數不一樣。

Day 02 那一百條難題裡，第 75 條講的就是這段：同一個數據要在店內看板、雲端報表與對外 API 各算一次，每個地方都要得出同一個數字。店內與雲端是兩套系統，中間的網路不一定穩定。每間店的時區、餐期、營業時間、車道配置又都不一樣，要讓它們的結果一致並不容易。

店內那條路要快，雲端這兩條路要準、要一致。

Software Team 負責的系統

對照上面那張圖，Software Team 負責的系統如下：

• 店內的即時看板，包含車道即時影像的播放器。
• Edge server 與雲端之間的資料同步：旅程紀錄上傳、斷網期間先存本機、恢復後補傳。
• 雲端的資料管線 (data pipeline)，把每一台車發生的事件換算成客戶想看的營運指標。
• BI 動態看板與它的權限控制，還有對客戶開放的 API。
• 每天寄到客戶信箱的 PDF 報表，從產生到寄送。
• 內部工具，例如自行開發的標註工具 BerryTool。

這些系統本身也需要監控，Day 23 會說明如何從瀏覽器外部確認店內的即時看板正常運作。

門市數量增加之後

每個系統的第一版都是先求快、求有，讓客戶先用得到。之後門市從幾十間增加到上千間，原本的做法陸續不夠用，我們再隨著門市數量一步步改。Day 20 到 Day 24 這五篇，講的就是這些系統怎麼迭代：

• BI 動態看板，從後端以 Python 計算指標、前端自行繪製圖表，換成導入開源 BI 平台 Superset。
• 營運指標的計算，從 6,000 行手寫的 Python 換成 dbt (data build tool，以 SQL 定義資料轉換的工具)。
• Email 報表，從 xlsx 樣板換成直接把 BI 動態看板轉成 PDF。
• 店內即時看板的監控，從被動的「客戶打電話來說螢幕黑了」，變成由監控程式主動發現問題。
• 車道影像播放器，從 RTMP + FLV 換成 WebRTC。

這些架構上的改動理由各不相同，其中最常出現的是兩件事：數字要一致，日後要容易修改。同一個數字不能算出兩個版本；PM 想調整報表的欄位順序，不應該需要工程師開 PR、送 review、等部署。

接下來六篇的主題

小結

Software Team 負責把 ML Team 算出來的數字送到店員、店經理、總部與加盟商手上，而且三種人看到的要一樣。看板、data pipeline、報表、播放器，每一樣都有現成的做法。難的是上千間店的時區、餐期、車道配置與網路狀況各不相同，要在這些條件下每天準時把數字送到。

明天從 BerryTool 開始，講一個標註工具怎麼從零做起。

參考資料

• Apache Superset
• dbt
• WebRTC (W3C)

本系列由 Berry AI 工程團隊出品。更多工程實戰紀錄都在 Berry AI 技術部落格。