阿里妹導讀：位于杭州阿里巴巴西溪園區旁邊的大型商場“親橙里”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數據

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的它是真实的“盗梦空间”？在这里，一切都可能是数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。