Semantic Layer，商業世界與資料世界溝通的橋樑 （三）
“Semantic layer is designed to cover the last mile of analytics.” 在系列文的第一篇時曾提過這句話。它指的是 semantic layer 讓資料從資料源頭到分析工具的最後一哩路得以程式化、標準化，並提升了資料的易用性及可理解性。當商業使用者需要資料輔助決策時，不再需要借助技術人員的協助， 便能透過 semantic layer 進行自助分析。
乍聽之下，自助分析解放了資料團隊的雙手，不再需要一天到晚處理只有一次性需求的 ad-hoc request，終於解決了資料分析師以及資料科學家們被當作 query monkey 的問題。資料專家們也終於可以開始應用自己的統計專業以及問題分析的能力，幫助公司找出更深入的洞見。
但實際上要能讓 semantic layer 發揮功效，並非建構出 semantic layer 就好。 Semantic layer 建構完成後，要怎麼讓組織內的人願意改變舊有的工作模式，改而使用 semantic layer；當人們開始使用後，又是否擁有足夠的資料素養，將資料轉換為正確的資訊等等都是 semantic layer 最終能否有效的問題。
或許我們應該說，要讓商業使用者能夠自助分析，建構好 semantic layer 的工程是最簡單的一步。建構期間跨部門的溝通、如何確保自助分析能對商業產生正面的影響是相對困難的事情。如果只是因為覺得 data request 很煩，已經影響資料團隊該有的生產力¹，便將 semantic layer 丟給商業使用者使用，未來反而很有可能會被其他類型的需求反噬，長遠來說，不一定有正向的影響。
實踐 Semantic Layer之時與之後會遇到的挑戰
指標 (Metrics) 的命名
Semantic layer建立的目的之一 ，是為了讓公司內部的各項指標運算方式得到統一，但不同部門之間對於同一指標名詞背後的運算邏輯定義並不相同，像是財務、會計、業務部門對於「營收」一詞的認列方式很可能不一致。資料部門不僅是在溝通時要小心，在指標命名時，更有可能需要權衡各部門之間的命名權，建立一套指標建立的規則與機制。
這部分可以透過各級主管都在場的會議來確認指標定義，流程比較「完善」的公司，也可以透過簽呈來加強指摽計算的正式性。我曾經待過的外商公司，則沒有太多這方面的問題，當時的主管採先到先行制，商業部門的人（應該）沒什麼異議的接受了。可見公司內部的文化以及人員心態的開放度，也會影響指標命名唯一性的難易度。
使用者的固有習慣
我在當時的公司利用 Power BI 建立 semantic layer，落地後，也與同仁合力成功將所有的儀表板轉移到其上，讓商業部門最常使用的資料決策工具有一致的定義；甚至有不少積極的使用者，開始用 semantic layer 找出自己需要的資料。但同時，也有不少使用者維持舊有的方式，使用自己習慣的方式撈取資料再進行視覺化或是探索式分析。觀察到可能的原因有：
- 想將資料視覺化盡善盡美：在移植舊儀表板或是建立新儀表板與商業使用者溝通的過程中，常常發現一些「過於細節」或是「很有創意」的視覺化方式。由於 Power BI 本身的限制 （或是當時我們對於 Power BI 不夠熟悉），加上 semantic layer 建構好後，不再具有任意轉換資料的彈性，有許多視覺化沒辦法如想像中的呈現。儘管就視覺化來說，不同的方法也可以傳遞同樣的資訊，還是有些有毅力的使用者，為了完成理想中的樣子，從源頭開始進行資料轉換，最後再進行視覺化。
- 覺得資料轉換過程不透明，所以不敢輕易使用：還記得當時商業團隊有一位 Excel 專家，每次都需要從業務系統下載資料，檢查資料有無錯誤後，再用公式列出自己想要的資料。儘管我們的 pipeline 已經有檢查錯誤的機制在裡面，Excel 專家利用 PowerBI 的 UI 也能快速撈取自己想要的資料，他還是覺得轉換過程不透明，不如自己再做一次比較實際。
- 能透過 SQL 直接從資料庫撈取資料：Power BI 雖然有提供 API 串接撈取資料，但使用的是 DAX 語言，對於會 SQL 的人來說（包括我自己），不如使用在資料倉儲中已經整理好的 data model 還比較方便。
從上述例子可以看出即使 semantic layer 已經開發完成，但要讓幾乎所有使用者都願意使用，似乎還需要一段時間。
改變使用者的習慣不僅需要長時間的磨合，有時更需要給予政治/制度上的壓力。今年一月底 Airbnb 的 工程師 Robert Chang 在 dbt meetup 也提到，美國有不少科技公司想導入 metrics layer (semantic layer)，卻得不到支持。他也很務實地說，Airbnb 能夠在 2020 前後順利地建構並導入 Minerva 到全公司，除了當時面臨資料信用破產的問題，也是因為在公司中有實質影響力的人願意大力支持並推行。
另外，該如何設計出足夠泛用或是讓使用者不需要改變太多舊有習慣的工具其實也是一門學問。我想，有不少 semanitc layer 工具，使用 SQL dialect 作為 Query 語言，應該也是為了處理這樣的問題。但從長期的角度來看，該使用什麼樣的語言作為 semantic layer 的介面最為適合呢，其實還是個待議的問題²。
有了 Semantic Layer 就不再需要處理 Ad-hoc Request 了嗎
在 dbt slack 的 #tools-powerbi ，Microsoft 的內部 BI PM Alex Dupler 曾經提到³：「 semantic model 的定位不該是回答商業使用者面對的每一個問題，而是利用它做出一連串 80/20 法則的分流：建立在 semantic model (semantic layer)上的儀表板以及報表，已經有辦法滿足 80% 的需求，剩餘需求的 80 % （合計 96%） 也應該能夠透過 semantic model 取得。最後 4 % 的 80%，則是藉由 ad-hoc request 的方式讓技術人員撰寫 Query 解決。」
對於商業使用者來說， semantic layer 已經足以回答大部分「能夠採取行動」的問題。 但剩下的一小部分，仍須透過撰寫 Query 取得，這一小部分也許是一些新定義的指標，或是客製化的報表。
也許 Ad-hoc Request 沒有不見，只是變成另一個樣子。
在當時的外商公司實踐完 semantic layer 之後，發生了另一個有趣的現象：三不五時會有人來問我們，他們使用 semantic layer 撈取資料的方法對嗎？或是請問我們該怎麼做才能做出想要的視覺化。由此可見，當我們準備導入新工具時，也需要做好一定的配套措施，教導大家如何使用這項工具。
另外，也許是費米估算以及維度分析的問題，都有辦法被回答了，開始出現更多尋找相關性的問題。統計學專業雖然可以開始上線，但還是會出現不少：
- 從產業特性來看，總覺得不太需要（深入地）做就能知道結果。
- 問了一個回答後，也沒辦法採取行動的問題。
想對資料有更多了解本身是件好事，但在商業世界中，資料團隊的職責並不是寫專欄或是發 Paper ，花了一個月的時間，最後只得到一個近似於 「It’s good to know」，或是「這次的分析好有洞見啊！」 的回覆，可說是糟糕透頂。身為資料分析師的我們，不妨想想，Ad-hoc Request 令人討厭的點是哪些，semantic layer 本身有助於我們減少這些現象嗎？
Semantic Layer 能解決所有問題嗎？
新工具的導入，必須伴隨流程、制度、以及文化的調整，才能達到最大效益。有了先前的經驗，我認為在導入 semantic layer 的初期可期待的邊際效益只有兩個：
- 解決指標定義不一致的問題 （可以視為一部份的 data quality issue)。
- 讓非技術使用者有機會不需要使用 SQL 也能完成自助分析。
然而，前者不一定需要 semantic layer 才能解決，在指標不多時，設計良好的資料模型 (data model）、紀錄完整的指摽定義文件加上資料團隊內部一致的工作流程，就能解決大部分第一點所產生的問題。後者雖然能夠幫忙解決大量的資料需求，但解決不了商業使用者對資料無止盡的好奇心。
當然我們也期待，當商業使用者能夠自助分析後，分析師可以不再被頻繁地打擾，專注於更深度的分析。理想豐滿，但現實總是骨感，semantic layer 也許可以加快每一次「分析」的速度，卻不必然增加做出具有影響力的分析的機率。分析師的分析結果不具影響力這件事情，其實不盡然是因為一次性的需求太多而造成，反而是商業團隊不夠了解該如何與分析師合作，或是資料團隊不夠主動所造成。
Self-service analytics 的漫漫長路
也許是資料團隊被煩到不勝其擾了，self-service analytics tool 在 Linkedin 上的討論也越來越多。但導入新工具前，我們不妨想想，理想中資料團隊在企業中順利運作的樣貌長怎麼樣？ Semantic Layer 又該在其中扮演什麼樣的角色呢？它能夠解決說少資料團隊的問題呢？建構好之後，真的有必要讓每個人都有權限從中撈取資料嗎？
在商業模式、指標的數量達到一定規模以前， semanyic layer 能解決的問題，其實並不多。
Self-service analytics 看起來很美好，但如何確保組織內部的資料素養 (data literacy)已經達到一定的水平，讓這條道路阻且長。
[1] 資料團隊的生產力：資料團隊的生產力，可以定義為對商業決策的影響力。但我也看過用「解決的 data request 數量」作爲資料團隊 KPI 的公司。
[2] 關於什麼樣的語言適合作為 semantic layer 的另一篇討論
[3] 原文：You shouldn’t try to have your shared dataset/metrics layer/semantic model answer every single question your business faces. Instead you need to view the data stack as a series of 80/20 rules. The pre-built reports built on your shared dataset should satisfy 80% of the demand. The same shared model should satisfy 80% of the remaining demand (96%). but you let your Business unit SME/Analyst partners access your DBT layer to pull out data for custom/ad hoc solutions for the 80% remaining of the demand (99.2%). They build single report vertipaq models and you have a process to get the knowledge gained from that ad hoc reporting slowly incorporated into the central metrics layer.
