有一些資料應用是名稱裡就有已經有提到「資料」或「分析」，又或是一般人都知道這些與資料有關，比方說：

• 機器學習、資料科學
• 推荐引擎
• 詐欺偵測
• IoT (Internet of Things)

另一方面，有兩類資料應用，可能因為太常見了，我們有時候反而沒有注意到，它們也是資料應用：

1. 客戶全方位視角 (Customer 360)
2. 應用軟體自監控 (Application health and security)

客戶全方位視角

客戶全方位視角這類應用指：「在行銷或是銷售，利用一些客戶資料，並有效地做自動化。」比方說，教寫程式的 Bootcamp 公司，依照學生的程度，把學生分為不同的群組，定期地對不同的群組送出客製化的電子報或是新課程資訊。又或是針對女性客戶販售高價服裝的女裝業者，除了週年慶期間寄送優惠券之外、客戶生日也要寄送生日賀卡。

在這類型的應用，反向 ETL (Reverse ETL) 常常佔了很重要的角色。會稱之為 ETL 的程式，資料的流動有方向性：「資料是從應用軟體 (application) 流向資料倉儲 (data warehouse)」。那如果資料的流向恰好相反呢？明明是 ETL 的程式，但是資料的流向卻是從資料倉儲流向應用軟體，這就稱之為 Reverse ETL 了。

在上頭的例子裡，補習班要寄送電子報，女裝業者要寄送折扣優惠，客戶分群的資料都是從資料倉儲流向電子報軟體，也因此， Reverse ETL 程式是客戶全方位視角不可或缺的一部分。此外，正如 EL 程式已經有許多的廠商提供解決方案， Reverse ETL 的商業解決方案也愈來愈多了。目前 Reverse ETL 的領導解決方案是 Hightouch 與 Census

應用軟體自監控

應用軟體自監控是指：「應用軟體本身會採集一些程式在運作過程的關鍵資料，以供管理者日後做效能調校、除錯、入侵檢查等。」之前我們談到的軟體，至少有兩個都有這種自監控的功能：

1. Metabase
2. 關聯式資料庫 (RDBMS)

Metabase 的付費功能有查核 (Audit) 的功能，可以看出儀表板 (dashboard) 的使用頻率、還有儀表板的運作速度。使用頻率可以讓我們了解，是否該儀表板有人在使用 (有無商業價值？)、儀表板的運作速度則可以做為校能調校的依據。

關聯式資料庫都會提供 Explain 指令，這個指令可以協助做資料庫的效能改善。

在之前的 Metabase - 自動化一文之中有提到過，有三件工作常是 IT 系統從「可用」走向「好用」的最後一哩路，然而，要堅持紀律把它們做好卻頗為困難：

1. 自動化 (automation)
2. 除錯介面 (debugging interface)
3. 可延伸的抽象層 (extensible abstraction)

上述的除錯介面基本上就可以視為是應用軟體自監控，由於這部分會依照軟體的用途不同而有截然不同的設計，那在開發軟體的過程之中，該怎樣逐步發展，可以發展出好用的除錯介面呢？我通常請客戶這樣子思考：

對於一個有充分考慮「錯誤處理」的系統，當它出錯時，運行與維護系統的管理者要做的第一件事是，他對系統提問 (Query)：『系統，列出你現在的內部狀態、與剛才你執行出錯的工作之內部工作記錄。』

嗯，如果管理者無法對軟體系統提問的話 (應該是絕大多數的軟體都做不到…)，顯然是還有介面待設計與發展。

後記

有一回，客戶請我協助改善的軟體模組，與會計的存貨成本計算有關：『該模組需要去取得資料庫裡的存貨資訊，利用會計的先進先出 (FIFO) 法，來算出存貨成本。』我用了約 50 行的 SQL (搭配了 windows function) 去取代了原本寫了 500 多行的 Node.js ，由於省去了大量的 IO ，效能也大幅改進。

客戶問我，「怎麼會想到這樣子來解決？」

「經典的 SQL puzzle ，當然是優先考慮純 SQL 的解決方案囉。」我如此回答。

註：Lifo-fifo Inventory 其實是經典的 SQL 問題，在 Joe Celko 的一本書 Joe Celko's SQL Puzzles and Answers 就有提到過。

其它資源

1. 對 dbt 或 data 有興趣 👋？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加
2. 歡迎訂閱 PruningSuccess 電子報，主要談論軟體開發、資料處理、資料分析等議題。