iCHEF 在 2022 下旬推出了專門給連鎖集團的新產品，本文分享其中的跨分店報表系統，系統設計上面對的一些挑戰和我們的選擇。
依照時間搜尋是報表一個很常見的需求，一個有性價比考量的報表系統，在時間搜尋的粒度上有合理的限制，能讓系統未來的維護簡單許多。舉例來說，使用者可選擇的最小粒度為半小時，可以選擇 15:30 ~ 21:00，不能選擇 15:15 ~ 20:45，上述時間最小粒度可依據商業需求而定。
有了固定的時間區間，我們就可以預先將大量的離散的時間資料，彙總成單位時間內的統計資料，例如 12:00 ~ 12:30 的小計營業額／訂單數等等，使用者在看報表時，我們可以確保最多只需要從資料庫拿出 x 筆資料就可統計完成，而不會隨著訂單數的波動而有影響，確保報表效能的穩定。
這個資料預處理的過程，在理想世界都很美好很簡單，每 x 分鐘定時統計前 x 分鐘的資料就完成了。但現實世界中，資料可能延遲上傳，也可能某些資料還在 queue 裡排隊等待處理中。為此，我們開了另一個 queue 來處理這類情境，在資料落地處判斷該資料是否已遲到（不會再被前述 x 分鐘定時統計掃到），如遲到，就在待統計 queue 中加入此資料，以避免為了確保資料正確而不停地回頭統計。
預先做資料處理，就像做菜預先備料一樣，如果蔥薑蒜都下鍋了才開始備料，除了燒焦的蔥薑蒜有點苦以外，還可能因為太趕把手指都切掉了，手指想必也不是很容易料理；或是食材解凍不夠，很容易外面都焦了裡面還沒熟，成了名副其實的 raw data。當然如果你的系統像小當家一樣切完會直接飛進鍋裡，就不必煩惱這麼多了。
我們的客戶中還有一個常見的需求，跨夜，有些店家固定營業到凌晨，例如 02:00，如果以 00:00 來切分每日營業額的話，資料就會失去意義。
上述將資料處理成單位時間小區塊的做法，也正好能達成跨夜報表的需求，畢竟系統處理的就是半小時半小時的資料，只要資料庫查詢時下好條件即可；另一方面，這樣的基礎架構除了能處理跨夜需求，當然也就能處理不同時區的需求。
飯後甜點
過程中我們還有一些考量供大家參考、討論：
- 商業上允許的話，早早定好報表支援的資料期限，可減輕未來系統維護、和客戶溝通的成本。
- 如商業上想要報表的反應更即時，也可以將單位時間的統計工作切分，例如本來統計十分鐘的工作，拆成十個 worker 同時各自處理每分鐘的資料，最後再彙整寫入資料庫。
- 有研究 AWS redshift 的適用性，但一來沒有 unique constraint 擔心資料重複的問題，二來對現況來說花費頗高。此外 redshift 不支援許多 function，其中
GENERATE_SERIES在報表中很方便，大家有興趣的話可敲碗另發一篇。
iCHEF 近年為了連鎖集團，除了提供分店菜單管理、會員管理、報表系統等，也即將推出門市訂貨系統，讓分店向總部訂貨、總部揀貨出貨、分店點收不亂套，敬請期待。歡迎各位老闆內洽諮詢。
