背景

image

苏宁八大产业,每个产业有自己的数据集市,每个数据集市有自己的维度表，没有统一的维度管理(包括管理规范和系统支撑)。业务痛点包含以下几个方面：

• 维度业务口径不统一，缺乏有效的管理流程来对其进行管理和约束，维度建设存在重复和歧义。

• 对于维度服务的开发，各个产品中心需要各自实现，造成开发成本重复投入。例如公司的维度。

• 业务人员想查询维度信息，缺乏可靠的公共平台去快速方便的查询。

• 部分维表存在于各数据集市，没有进行统一维度管理，使用时需联系相关方确认，比较耗时。

• ETL开发人员/产品人员，存在大量手工配置表需要规则维护，缺乏快速开发工具。

目的

建立统一的维度管理系统，实现对维度信息的统一管控，并为集团的数据产品提供统一的维度数据服务，包含维度开发管理，维度信息管理及维度数据服务三个方面。

• 维度管理：基于数据管理办公室维度管理规范，对维度新增、修改、发布等生命周期进行统一管理。

• 维度服务：基于数据仓库磐石HIVE层模型源数据，建立服务化的维度表模型，在模型基础上建立维度，包括系统维度和手工维度定义，支持离线和实时大数据量的维度查询服务，维度创建完成后为各数据产品提供高可用，高性能的数据服务。

• 血缘分析：基于指标、维度、报表应用层数据，建立实时全链路数据血缘分析图谱；满足各业务端在不同流程节点对于数据变更影响分析的需求。

• 为整个集团的统一权限提供统一的维度服务。

• 为整个集团的数据分析类产品提供统一的维度服务。

image

维度数据

image

如上图所示，ETL将采集的数据，进行数据清洗之后存储到维度数据仓库（磐石）中，维度系统再将维度数据仓库中的数据同步达到维度库系统。

维度数据存储方式：维度数据一般以一百万的数据量作为分割点，一百万以上数据量的维度采用的存储是HBASE，一百万以下的数据采用的存储是MYSQL。

维度数据同步方式：存储到HBASE的维度数据采用的是BULKLOAD导入，存储到MYSQL的维度数据采用的是SPARKSQL+RDD写入。针对数据同步都已经实现通过页面配置任务的方式一键同步，节省人工。

为什么采用这种存储方式？

1， 针对数据量的大小采用不同的存储引擎，节约存储资源，提高维度服务的稳定性。

2， 实时指标的计算：OALP需要关联维度表和事实表做指标数据加速（实时计算指标数据）。这种需要实时的查询维度表的所有维度属性，调用量非常庞大，所以采用了直接查询HBASE的方式。

3， 维度需要提供基于维度值ID查询维度值名称的服务(包括批量精确查询和模糊查询)，HBASE在精确查询上性能较高。MYSQL由于数据量不大，可以再加一层分布式缓存，提高精确查询维度值的性能。

维度建模

1， 选择业务过程

根据业务场景以及可用数据源

2， 声明粒度

根据事实表及应用场景，确定汇总粒度，一般尽可能的用最细粒度

3， 确定维度

根据确定的粒度，定义对应的维度，最细粒度，也是最低层次的维度

4， 确定事实

确认将哪些事实放到事实表中，维度表只是做关联，不做维度数据的查询服务。

维度定义

• 维度按集团产业进行指标一级业务域划分，包括：云商、文创、体育、投资、金融、置业等；在各业务域下，对维度进行主题分类，主要有：时间类（DT）、组织类（OG）、产品（PD）、销售平台（SP）、经营方式（BM）、终端(TM)、业务渠道(BC)、营销(MK)、会员(MB)、采购模式(PM)、地点(AD)、兴趣点(IS)、参数(PT)等。

image

• 维度编码按上图所示进行编码，例如ZZ_WD_0001，ZZ表示组织维度主题，WD维度唯一标识，维度首次下发其编码号采取连续编码的形式。维度说明的编码使用规则包括:

1. 当增加新的维度时，编码号将在已用号码的基础上递增，四位十进制编码号不能满足需求时，可增加编码号长度为五位十进制数，以此类推。

2. 当删除已有的维度时，其编码号将不再利用。

3. 当修改已有的维度时，其编码号不变。

4. 当拆分已有的维度或合并两个及两个以上的维度时（数据应用场景需要），其编码号的使用原则按照删除原维度，并新增拆分/合并后的维度执行。

维度管理

维度：目前维度平台支持快速定义维度,通过设置维度的基本信息，选择维度映射的维度表，做好维度与维度表的映射，设定维度的一些特性（布尔维度，时间维度，杂项维度等），检测维度的定义结果。达到了让业务人员能够只是通过页面操作就可以制定需要的维度。

维度表：数据开发人员可以通过维度库平台定义维度表，定义好之后可以集成数据仓库的同步任务一键将仓库的数据同步到维度表中，将维度表与维度做映射关系。

维度层级：维度库平台支持定义维度层级，只要是维度库平台上有的维度表并且做好维度与维度的映射关系之后，就可以定义需要的维度层级，根据维度层级提供维度值的上卷下钻查询服务。

维度血缘：提供了维度，指标，报表的血缘关系，以及还准备做的维度数据的血缘，维度，指标，报表调用次数的血缘等等。

image

维度服务

1. 维度服务调用申请：

调用维度服务，需要在维度库管理系统中申请调用权限。等维度管理系统授权之后，生成维度服务调用授权码，在调用维度服务的时候带上维度服务调用授权码，维度服务会根据授权码判定是否有访问权限。

2. 维度系统提供的服务：

• 目前维度管理系统提供了包括维度（维度定义，维度基本信息），维度表（维度表详细信息，维度与维度表映射信息），维度层级（维度层级关系），维度值（根据维度值ID精确查询，根据维度值ID或者名称模糊查询，带层级关系的维度值查询，等其他定制化的维度值查询服务）。
• 维度服务采用的TCP传输协议，由我司的统一服务管理（RSF 解决分布式系统间的服务调用问题，提供一种透明的、高性能的RPC服务调用方案。），可以对调用方进行限制迸发，可以设置接口局的幂等，可以设置异常阀值，超时时间。可以设置熔断机制，告警的。保障接口的稳定性。
• 为了提高维度值查询服务的性能及稳定性，我们还做了如下措施:

1,对存储在HBASE的维度表，我们又加了一层存储到ELASTICSEARCH（提供维度值的模糊查询服务）

2，针对负载较高的HBASE表，加了一层本地缓存，解决热点问题。

3，对存储在MYSQL的维度表，我们又加了一层存储到分布式缓存ZEDIS（提供维度值精确查询服务）。提供了定时或者手动刷新缓存数据的功能，以及缓存数据的监控机制。

image

监控分析

由于维度服务的调用量是亿万级别的，系统的监控统计，采用的是Log4j+kafka+druid的架构，如下图所示，应用将调用日志采用log4j- KafkaLog4jAppender写入kafka中，再将kafka与druid集成，准实时的输入druid中，业务基于druid做统计分析，查看维度服务调用成功或失败的情况。

除了维度服务的调用监控，平台还有针对维度值的数据量监控（主要监控暴增或者突然没有维度数据的情况），维度值数据质量的监控（根据维度表和事实表做数据比对，分析维度值数据的差异情况）。维度数据同步任务的监控（每个维度表的数据同步情况监控，异常告警到具体的任务负责人）。通过各种有效的监控手段，来提升维度服务的稳定性和准确性。

image

未来展望

1. 未来平台会更加的完善,会有越来越多的维度在平台上建设,提供更加稳定和高效的维度查询服务。

2. 能够支持更多个性化的维度，能够支持维度的数据版本（例如过去一段时间的维度值），支撑全集团所有数据产品的维度调用服务，将平台打造成苏宁主数据服务的航空母舰。

3. 通过维度数据资产体系的建立，实现集团一切业务数据化，连接打通数据孤岛，驱动一切数据业务化，助力企业数字化转型，让数据做到真正意义上的产生价值。

4. 通过提供各种维度数据支持数据产品及各类应用产品，帮助各岗位用户在日常经营决策中做出正确决策。

总结

目前平台的现状及以后的规划

1， 完善系统监控功能点：缓存任务较多，没有有效的监控，告警机制。

2， 完善业务监控功能点：数据量监控，数据异常监控，告警功能

3， 落地维度新增、变更、下线全流程审核管理功能.

4， 完善应用层的维度、指标、报表数据链路的血缘分析图谱，全方位透析资产，

5， 打通全链路维度变更通知的消息机制，降低数据链路变更带来的风险，

6， 多系统用户资源隔离、限流，保障多个部门在使用和体验上的一致性，

7， 支持用户自定义维度、完善个人工作台，基于通用维度进行维度的衍生，

8， 维度门户的建设，将业务端和管理端进行隔离，提升用户体验