阿裡妹導讀：位于杭州阿裡巴巴西溪園區旁邊的大型商場“親橙裡”2018年正式開業。和傳統的線下綜合型商場不同的是，親橙裡從規劃之初就定位為數字化商場，通過植入自研的IBOS平台完成建築内的所有子系統的接入，而讓建築和建築内的裝置、空間、人的“線上”是我們數字化的第一個目标。為了實作這個目标，阿裡工程師做了哪些動作，一起往下看。
建築數字化基礎——建築IoT和邊緣計算
裝置資料字典
建築樓宇内的裝置紛繁複雜，包括裝置種類、功能、性能、安裝方式、通訊方式、通訊協定等等各個方面都不一而同，而這些裝置正是建築樓宇正常營運和管理的前提，構成了建築樓宇自動化的基礎。是以，建築數字化的前提是建築裝置數字化，而裝置數字化的前提是首先需要定義統一的資料字典。我們将建築樓宇領域的空調、給排水、消防、安防、強電、弱電六大系統、100多種裝置類型統一進行編碼、分類、定義完整的資料模型。
Niagara——建築IoT神器
上面提到建築樓宇内的裝置類型繁多，雖然有一些行業标準，但标準本身也比較複雜、且沒有一個标準能接入所有或絕大多數子系統；是以、建築IoT系統中，裝置統一接入一直是個挑戰。Niagara較完美地解決了這個問題。Niagara是基于Java的開放物聯網解決方案，其邊緣終端産品JACE支援多種通訊I/O端口、内置了大量常見的樓控系統和裝置驅動，同時支援驅動插件式管理、允許使用者二次開發；支援分布式部署架構、相容包括Haystack、LonWorks、BACnet在内的多種行業标準。
Niagara的引入解決了兩個痛點問題：
1）異構子系統的接入、屏蔽了大量裝置協定的開發和适配；
2）按照标準資料類型、統一機關、精度等，将原始裝置資料标準化為Haystack格式的資料封包，便于上層系統（IBOS）處理。
IBOS邊緣計算
人、裝置、空間是構成建築的三個基本要素（類比商場的人、貨、場），是以人、裝置、空間也是建築領域的基礎領域模型，其他模型都可以在此基礎上進行建構。IB平台的邊緣計算也正是圍繞這三種基礎領域模型來設計：IB-Connector接入裝置資料的同時，會根據資料字典的定義，動态轉換為人、裝置、或空間模型；IB規則引擎，本質是圍繞人、裝置、空間模型執行個體之間互操作、基于事件驅動的實時計算引擎。另外，它還提供豐富的元件支援，可以按需靈活自定義模型并把資料發送到雲端、供雲端服務消費和使用。下圖簡單示例了親橙裡的水電表裝置如何通過邊緣計算平台把資料實時上送到雲端并接入資料中心。
資料中心大圖
IB資料中心，以建築業務數字化和數字業務化為目标，對下采集建築線上線下的各種資料，進行建築全域統一模組化和加工；向上提供PaaS化的資料服務和算法服務，并最終為業務層提供輔助決策。
下面是資料中心的架構大圖，依然是分層架構。總體上自下而上可分為四層。
1）資料源，包括采集的各類線上的和線下的資料，來自IBOS、IB應用、集團DT（OneData、A+等）以及其他合作BU的資料，另外還包括外部資料等；
2）資料模組化和計算，包括各種異構資料源的資料接入和清洗、針對建築領域的全域資料的資料模型設計、實時資料/離線ETL開發；
3）資料服務中台，面向業務領域的應用層資料OLAP分析，提供高性能、通用、開放的資料服務；
4）應用，包括純資料類的應用例如招商、選址（辦公/商業場景）、營運分析、消費者洞察、客流動線、财務模型分析等，以及基礎的商業、辦公/産業營運、資産管理類應用中的資料統計/分析類場景。
資料模型建設
資料模型建設是資料倉庫開發中的關鍵環節。我們在對親橙裡的所有業務系統（客流、停車、POS、CRM、多屏和導購、招商租賃、物業和能效管理等）及其關鍵場景進行梳理、識别出公共的業務領域、并抽象出核心的領域模型；在此基礎上進行彙總分析，進行邏輯模組化、包括模型之間的關系和模型内部的關鍵屬性。下圖簡單示例了模型建設的整個過程。
在模組化方法上，我們采用了目前業内主流的Kimball次元模組化（這也是集團推薦的方式）。次元模組化的特點總結了如下幾點：
資料備援小（很多具體資訊都存在相應的次元表中了）
結構清晰（表結構一目了然）
便于做OLAP分析（這個很重要、我們有很多業務資料分析的場景和需求）
有一定的擴充性：當增加新的資料分析需求時，可以較容易地擴充模型
一定程度上增加使用成本，比如查詢時要join多張表
有時會産生資料不一緻（如次元表和事實表）
當然、次元模組化也不是十全十美，但确實是最适合我們場景的模組化方法。
資料服務中台
親橙裡的應用場景豐富，不同的應用場景對資料有不同的需求；為了靈活高效地提供不同應用的資料接口，我們設計開發了資料接口服務；基于實時計算和離線計算加工好的彙總資料，通過提供圖形化的方式、及SQL的方式來完成接口的自定義、釋出以及監控。帶來的好處也非常明顯：
- 上層應用可靈活自定義所需的資料接口、不再強依賴資料開發團隊；
- 統一資料口徑、便于資料品質監控和管理；
- 降低了資料集市/應用層表的規模，将資料開發團隊從上層應用的需求中解放出來，專心底層和中間層資料和算法開發；
- 完善的API管理、運維、監控、流控、自動化測試等機制，保障服務效率和品質。
對于上線的資料接口，提供接口的調用qps、rt、調用異常等監控，支援報警規則配置和推送。
核心商業場景
客流、交易、會員是線下零售場的最核心場景，也是親橙裡數字化的重點場景。
客流
客流系統是傳統線下商場最基礎的系統之一。類比線上電商和A+，線下商場就是站點，商鋪就是頁面，客流系統采集到的人次、人數就是商場/商的"PV"、"UV"；通過定義活躍度模型，我們也可以統計線下場的月活、日活，并針對活躍使用者進行挖掘分析。
| 業務價值
1）客流監測及預測，幫助商場和商家更合理地安排資源，更客觀地評估業态吸客能力及優化決策。
2）客群分析（性别/年齡/活躍度）幫助大小B決策提供針對性的服務，提升顧客體驗，提高顧客黏性及忠誠度。
3）客流資料聚合銷售資料，幫助大小B更客觀更精确評估人員/活動/業态的績效。
4）顧客識别（身份識别/行為軌迹分析），幫助商場和商家更直接觸達會員群體，加強互動，提高會員黏性及忠誠度。
5）客流動線及熱點分析，幫助商場更準确捕捉業态冷熱分布，更合理優化布局；
幫助商家更大程度協同發展、更合理優化店内陳列、商品類别及人員安排，持續增強吸客能力。
| 技術方案
傳統的客流系統一般隻支援人次統計、并不支援去重、更不支援身份識别，同時裝置本身的識别精度、安裝位置和角度、光照條件、現場調校、系統維護等都會影響最後的統計精度，是以擷取較高品質的客流資料是傳統線下場的痛點之一。經過充分的調研、測試和驗證後，我們采用了頭肩識别+人臉識别的混合方案，每個商場/商鋪的出入口通過兩組攝像頭分别抓拍頭肩和人臉，除了可以統計路過、進店、離開的人次，還支援去重以及使用者特征識别（年齡、性别等）和身份識别。
| 活躍度模型
根據不同周期下的通路頻次，可以定義出訪客活躍度和會員活躍度等級。
通過這個定義，系統可以自動給訪客/會員打标，進而統計出日活、周活、月活訪客/會員數，以及各活躍度訪客/會員的占比。
交易
親橙裡的交易非常複雜，商家衆多、交易系統不統一；同時由于親橙裡的招商初期并未約定采用統一收銀方式，後期商家入駐後再推進統一POS方案也比較困難：
1）對阿裡系商家如盒馬、心選、小廚，以及天貓智慧門店，這類商家的交易直接走TP；
2）對大部分餐飲類、零售類、服務類企業，我們部署了口碑的POS系統；
3）剩餘的商家，我們上線了銷售管理系統。由商家小二背景手動錄入資料，系統采集後流入資料倉庫；
| GMV
基于交易資料的三類名額即GMV、坪效、租售比均是我們重點關注的名額，它們可以衡量店鋪的營運效率以及健康度。下圖是我們對親橙裡76個商家的GMV、客流、租金名額進行彙總後生成的氣泡圖，業務可根據此圖表，了解商家所處位置象限，以進一步進行營運及招商的調整。
基于GMV、客流、租金名額的商家氣泡圖
會員
會員系統是親橙裡重點打造的服務：
1）會員交易自動實時積分；
2）多方權益打通；會員免費停車，交易積分兌停車權益，趣抓、ROM、黃小鹿權益，等等；
3）自然植入的人臉互動場景、完成會員身份識别閉環；通過停車、客流、軌迹、交易、場内互動等多個場景，嘗試多元度認識會員；
4）基于OneID的能力，我們将親橙裡會員和淘系會員打通；同時結合集團的線上大資料和場内的線下資料，使使用者畫像更完整和豐滿；另外基于集團LBS資料的能力，我們可以挖掘距離商場周邊3公裡/5公裡範圍内的潛客，并結合他們在場内的到訪、活動、下單等資料進行跟蹤分析。
資料可視化
我們的日常資料報表，在可視化上目前選型的都是集團内的成熟産品，如有數、dataV。
同時，針對建築本身的空間特點，我們正在規劃基于2D/3D地圖、CAD/BIM模型等做一些建築資料可視化的嘗試。
雙11
去年雙11是親橙裡第一個雙11，我們也首次和集團資料技術及産品部合作，把親橙裡的實時資料對接到集團媒體大屏。
運維監控可視化
目前，我們也在和雲智能基礎産品事業部研發效能合作的「須彌山-态勢平台」共建出了親橙裡的監控模型。
本圖為mock資料本圖為mock資料
原文釋出時間為：2019-10-12
作者：永諾
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。