Semantic layer，商業世界與資料世界溝通的橋樑 （一）
你知道 semantic layer 是什麼嗎 ？
你相信有了這項工具後，商業使用者撈取資料不再需要借他人之手嗎？再偷偷告訴你，使用它之後，你將不再看到一群人圍在電腦旁，七嘴八舌地討論著各組報表/儀錶板之間的數字為什麼不同，資料工作者拉出一段又一段 Query 只為了找出資料問題在哪裡的光景。
商業使用者可以快速自由地取用資料，數據的定義以及品質能得到統一，資料工作者也不再被當成 SQL monkey。雖然我不是資料科學家，但這聽起來很不錯，對吧！
我知道你在想什麼，這聽起來好到不真實，這是詐騙嗎？我要你看一下下面這張圖：
可以發現 semanic layer 的討論度急遽成長（雖然主要集中在歐洲以及美洲），這兩三年來更是在各個產業被廣泛應用，被視為企業要達到自主分析的最後一哩路，更有不少新創是以開發 semantic layer 作為 SaaS 產品而獲得創投青睞。其中，Google 更是收購了 Looker，並將 Data Studio 改名為 Looker Studio，深化資料分析平台的佈局。
很明顯地，semantic layer 被視為可以有效解決資料團隊痛點的方案，並且被各式新創甚至是S&P 500 的企業加速採用，要了解什麼是 semantic layer 最好的時間就是現在。
所以，你現在只有一個選擇，那就是花點時間看完這篇文章，並找到適當的時間點與工程師合作將 semantic layer 導入你的組織當中，將資料應用的能力賦予給所有的商業使用者。
你知道 Semantic 是什麼嗎？
俗話說得好，開發能力不好不一定是技術不好，更常見的是英文太爛。在了解 semantic layer 之前，你知道 semantic 是什麼意思嗎？
讓我開始想深入了解什麼是 semantic layer 的動機，是看到 Lauren Balik 的一篇文章，他的一段註解讓我展開了追求 「semantic layer 跟 metrics layer 的差別到底是什麼」的求知之旅：
dbt Lab’s Semantic Layer is not really a semantic layer, but a metrics layer.
然而，英文不好的我在網路上滑了四五個月的文章，仍舊無法參透什麼是 semantic layer。
直到有一天，我才恍然大悟，問了外文系的朋友這個問題：
「 誒誒，你知道 semantic 是什麼意思嗎？」
經過一番討論後，發現 emoji 是個很好的 semantic：當兩個人對同一個詞彙的定義在腦海中生成了一樣的畫面，那他們對這個詞彙的 semantic 就是一樣的了。
簡單來說， semantic 就是語義的意思。例如：
- 腳踏車與自行車雖然念起來不一樣，但他們 的「所指」都是 🚲，那麼，就可以說他們擁有相同的 semantic value¹。
- 相對地，台灣的土豆 ( 🥜) 跟中國的土豆 (🥔)，雖然唸起來相同，寫法也相同，但「所指」卻不同，因此擁有不同的 semantic value。
Semantic 在商業中為什麼重要呢？
而 semantic 在 商業以及資料分析中為什麼重要呢？不妨讓我們回想一下，在資料分析時，「誤會」是怎麼產生的²：
- 在ETL 時，每一張報表底下的 SQL script / code 都不相同，當需求來的又快又急，就容易出現錯誤。人與人溝通時可以透過頻繁的來回使用不同詞彙指涉同一個 semantic。但是跟電腦的溝通需要透過精確的程式語言。當不同的需求牽涉到相同指標，卻由不同人或是不同寫法撰寫，就有很大的概率形成對「電腦」來說是不同 semantic 的指令，「電腦」就會產生「誤會」，回吐不一致的結果。
- 不同的團隊或是 stakeholder，對同一個詞彙的定義本來就不相同，呈現出來的數字/用語當然也不相同。像是在 B2B 產業中，「客戶」指的有可能是公司（法人），也有可能是公司的窗口 （自然人）。就曾發生過被瑣事操煩到焦頭爛額的高階主管向資料團隊提出要將「客戶」分級的需求，但跟中階主管進一步討論後，才發現提出需求時，高階主管指的「客戶」交錯指涉法人與自然人，在 semantic 不清的情況下，自然也就無法利用資料分析進行對應的分級，只好再回過頭來跟高階主管重複確（ㄧㄣˇ）認 （ㄉㄠˇ）需求。
不難發現，在資料工作者的日常中，充滿著溝通，不論是與人的溝通，或是與電腦的溝通。然而每次溝通過程中都會充斥著用不同詞彙指涉同一個 semantic，或是同一個詞彙指涉多個不同 semantic 的情形。很多時候可以透過前後文或是商業思維推敲，但也時常有一不注意就變成雞同鴨講，需要不斷反覆來回的時候。
當商業模式及商業活動沒有太大變動，類似的需求卻需要一再往返，不僅造成了工作上的負擔，對企業而言更是繁重的溝通成本，更重要的是如果對指標產生誤會，就有可能導致決策的錯誤以及對資料的不信任。
因此，讓人與電腦之間以及人與人之間的溝通對於同一個詞彙擁有一致的 semantic，便是 semantic layer 存在的意義。
當商業世界對於商業詞彙已經有統一的定義，便能藉由系統架構、程式語言的方式實踐 semantic layer ，讓「撈取資料並進行視覺化」這件事更加自動化，達到所謂的 self-serve analytics。因此，也有人說
Semantic layer is designed to cover the last mile of analytics.
Semantic Layer 在數據棧中的定位
在了解 semantic layer 是商業世界與資料世界溝通的橋樑這一概念後，接著便是想辦法在實務上進行實踐了。礙於篇幅，可能無法在這篇文章中就告訴大家 semantic layer 通常具備哪些元素，但不妨先從傳統資料團隊分工的視角了解 semantic layer 這座「橋」想跨越的是什麼樣的巨河：
從圖片可以看出，每出現一個需求，就會出現一次資料轉換以及指標計算。這些計算就可以視為一座使用者自己搭建的小橋，一個只屬於自己團隊甚至是單一需求的小小的 semantic layer。團隊間要彼此交流時，便會出現「語言隔閡」。
最後當需求越來越多時，便會導致從資料倉儲到分析工具的這一段路就像是新北市的路況，由密密麻麻的小橋所搭建，不是在地人根本很難記得哪幾條橋 (Transformation Code)，最後會抵達哪些目的地 ( Metrics)。
而如果你是資料工作者，在工作時也肯定常常 OS: 為什麼同樣的 join、where 條件甚至是 case when 以及 aggregate function 我要寫了又寫，寫了又寫？
這些問題輕則重工，重則每個工程師/分析師的指標計算邏輯、命名方法都不一樣，導致生成出的報表五花八門。萬一最後有些指標的計算方法改變了，這些報表就要逐一修改。而在採用 semantic layer 後，便能有效地解決這些問題：
semantic layer 這時便能做為資料倉儲以及各個視覺化工具之間一座大鋼橋，讓商業使用者能使用自己熟悉的視覺化工具 (如：Excel, Tableau, Metabase, PowerBI, Superset, Python, R 等等）從統一的路徑跟資料倉儲中整理好的資料互動。
而為了構造一座方便的橋樑，工程師們需要在 ETL/ELT 時先在橋的另一側系統性地將資料倉儲中的資料整理成「商業使用者能夠理解並自行組裝的樣子」；接著定義好各項指標，並標明清楚的說明以及指引，最後打造出一條足夠有彈性的通道，讓使用者可以使用自己習慣的工具往返橋樑的兩側，順利取得自己想要的資料。如此一來，如果商業邏輯有所改變，只需要在橋的左側做一次變動，右側做好的報表以及儀表板便能自動更新到最新的定義。
那「商業使用者能夠理解並自行組裝的樣子」長怎樣呢？ 指標的定義會有哪些細節呢？各式各樣的工具又是怎麼透過 semantic layer 跟資料倉儲互動的？還請待我下回分解！
[1] 語言學上，同一個詞彙是否具有同一個 Semantic Value 好像也會因人而異，取決於每個人的個人經驗。舉例來說，「狗」對我來說可能是友善的拉布拉多，但對另一個人來說可能是恐怖的路邊野犬。但對於 Business Intelligence 來說，如果背後的運算邏輯一致，且 Metrics 的 定義也符合商業思維，應該就能稱之為具有相同的 Semantic Value，不致影響溝通了。
[2] 「誤會」這個詞，其實原本想用的是 “ data quality ”。但後來想想，有些 data quality 的問題，不也是源自於誤會嗎？ 不同資料分析師對於同一資料源產生了不同的誤會，或是商業使用者誤會分析師指標的定義等等。
