阿里妹導讀：位於杭州阿里巴巴西溪園區旁邊的大型商場“親橙裡”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、坪效、租售比均是我們重點關注的指標，它們可以衡量店鋪的運營效率以及健康度。下圖是我們對親橙裡76個商家的GMV、客流、租金指標進行彙總後生成的氣泡圖，業務可根據此圖表，了解商家所處位置象限，以進一步進行運營及招商的調整。

基於GMV、客流、租金指標的商家氣泡圖

會員

會員系統是親橙裡重點打造的服務：

1）會員交易自動實時積分；

2）多方權益打通；會員免費停車，交易積分兌停車權益，趣抓、ROM、黃小鹿權益，等等；

3）自然植入的人臉互動場景、完成會員身份識別閉環；通過停車、客流、軌跡、交易、場內互動等多個場景，嘗試多維度認識會員；

4）基於OneID的能力，我們將親橙裡會員和淘系會員打通；同時結合集團的線上大資料和場內的線下資料，使使用者畫像更完整和豐滿；另外基於集團LBS資料的能力，我們可以挖掘距離商場周邊3公里/5公里範圍內的潛客，並結合他們在場內的到訪、活動、下單等資料進行跟蹤分析。

資料視覺化

我們的日常資料報表，在視覺化上目前選型的都是集團內的成熟產品，如有數、dataV。

同時，針對建築本身的空間特點，我們正在規劃基於2D/3D地圖、CAD/BIM模型等做一些建築資料視覺化的嘗試。

雙11

去年雙11是親橙裡第一個雙11，我們也首次和集團資料技術及產品部合作，把親橙裡的實時資料對接到集團媒體大屏。

運維監控視覺化

目前，我們也在和雲智慧基礎產品事業部研發效能合作的「須彌山-態勢平臺」共建出了親橙裡的監控模型。