它是真实的“盗梦空间”？在这里，一切都可能是数据

阿里妹导读：位于杭州阿里巴巴西溪园区旁边的大型商场“亲橙里”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、客流、租金指标进行汇总后生成的气泡图，业务可根据此图表，了解商家所处位置象限，以进一步进行运营及招商的调整。

基于GMV、客流、租金指标的商家气泡图

会员

会员系统是亲橙里重点打造的服务：

1）会员交易自动实时积分；

2）多方权益打通；会员免费停车，交易积分兑停车权益，趣抓、ROM、黄小鹿权益，等等；

3）自然植入的人脸交互场景、完成会员身份识别闭环；通过停车、客流、轨迹、交易、场内互动等多个场景，尝试多维度认识会员；

4）基于OneID的能力，我们将亲橙里会员和淘系会员打通；同时结合集团的线上大数据和场内的线下数据，使用户画像更完整和丰满；另外基于集团LBS数据的能力，我们可以挖掘距离商场周边3公里/5公里范围内的潜客，并结合他们在场内的到访、活动、下单等数据进行跟踪分析。

数据可视化

我们的日常数据报表，在可视化上目前选型的都是集团内的成熟产品，如有数、dataV。

同时，针对建筑本身的空间特点，我们正在规划基于2D/3D地图、CAD/BIM模型等做一些建筑数据可视化的尝试。

双11

去年双11是亲橙里第一个双11，我们也首次和集团数据技术及产品部合作，把亲橙里的实时数据对接到集团媒体大屏。

运维监控可视化

目前，我们也在和云智能基础产品事业部研发效能合作的「须弥山-态势平台」共建出了亲橙里的监控模型。

本图为mock数据本图为mock数据

原文链接
本文为云栖社区原创内容，未经允许不得转载。