它是真實的「盜夢空間」？在這裏，一切均可能是數據

阿里妹導讀：位於杭州阿里巴巴西溪園區旁邊的大型商場「親橙裏」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的方式來完成接口的自定義、發佈以及監控。帶來的好處也很是明顯：

1. 上層應用可靈活自定義所需的數據接口、再也不強依賴數據開發團隊；
2. 統一數據口徑、便於數據質量監控和管理；
3. 下降了數據集市/應用層表的規模，將數據開發團隊從上層應用的需求中解放出來，專心底層和中間層數據和算法開發；
4. 完善的API管理、運維、監控、流控、自動化測試等機制，保障服務效率和質量。

對於上線的數據接口，提供接口的調用qps、rt、調用異常等監控，支持報警規則配置和推送。

核心商業場景

客流、交易、會員是線下零售場的最核心場景，也是親橙裏數字化的重點場景。

客流

客流系統是傳統線下商場最基礎的系統之一。類比線上電商和A+，線下商場就是站點，商鋪就是頁面，客流系統採集到的人次、人數就是商場/商的"PV"、"UV"；經過定義活躍度模型，咱們也能夠統計線下場的月活、日活，並針對活躍用戶進行挖掘分析。

• 業務價值

1）客流監測及預測，幫助商場和商家更合理地安排資源，更客觀地評估業態吸客能力及優化決策。

2）客羣分析（性別/年齡/活躍度）幫助大小B決策提供針對性的服務，提高顧客體驗，提升顧客黏性及忠誠度。

3）客流數據聚合銷售數據，幫助大小B更客觀更精確評估人員/活動/業態的績效。

4）顧客識別（身份識別/行爲軌跡分析），幫助商場和商家更直接觸達會員羣體，增強互動，提升會員黏性及忠誠度。

5）客流動線及熱點分析，幫助商場更準確捕捉業態冷熱分佈，更合理優化佈局；
幫助商家更大程度協同發展、更合理優化店內陳列、商品類別及人員安排，持續加強吸客能力。

• 技術方案

傳統的客流系統通常只支持人次統計、並不支持去重、更不支持身份識別，同時設備自己的識別精度、安裝位置和角度、光照條件、現場調校、系統維護等都會影響最後的統計精度，所以獲取較高質量的客流數據是傳統線下場的痛點之一。通過充分的調研、測試和驗證後，咱們採用了頭肩識別+人臉識別的混合方案，每一個商場/商鋪的出入口經過兩組攝像頭分別抓拍頭肩和人臉，除了能夠統計路過、進店、離開的人次，還支持去重以及用戶特徵識別（年齡、性別等）和身份識別。

• 活躍度模型

根據不一樣週期下的訪問頻次，能夠定義出訪客活躍度和會員活躍度等級。

經過這個定義，系統能夠自動給訪客/會員打標，進而統計出日活、周活、月活訪客/會員數，以及各活躍度訪客/會員的佔比。

交易

親橙裏的交易很是複雜，商家衆多、交易系統不統一；同時因爲親橙裏的招商初期並未約定採用統一收銀方式，後期商家入駐後再推動統一POS方案也比較困難：

1）對阿里系商家如盒馬、心選、小廚，以及天貓智慧門店，這類商家的交易直接走TP；

2）對大部分餐飲類、零售類、服務類企業，咱們部署了口碑的POS系統；

3）剩餘的商家，咱們上線了銷售管理系統。由商家小二後臺手動錄入數據，系統採集後流入數據倉庫；

• GMV

基於交易數據的三類指標即GMV、坪效、租售比均是咱們重點關注的指標，它們能夠衡量店鋪的運營效率以及健康度。下圖是咱們對親橙裏76個商家的GMV、客流、租金指標進行彙總後生成的氣泡圖，業務可根據此圖表，瞭解商家所處位置象限，以進一步進行運營及招商的調整。

會員

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

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

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

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

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

數據可視化

咱們的平常數據報表，在可視化上目前選型的都是集團內的成熟產品，若有數、dataV。

同時，針對建築自己的空間特色，咱們正在規劃基於2D/3D地圖、CAD/BIM模型等作一些建築數據可視化的嘗試。

雙11

去年雙11是親橙裏第一個雙11，咱們也首次和集團數據技術及產品部合做，把親橙裏的實時數據對接到集團媒體大屏。

運維監控可視化

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

---

本文做者：永諾

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。