在大数据环境下，一个数据应用往往需要通过多个计算资源来配合完成，
最简单来说，一般数据需要先在离线环境当中进行离线加工处理(ETL)，再同步至在线数据库当中进行在线分析查询(OLAP)。
标签中心要与多个数据库进行通信
标签中心获取多个计算存储资源的数据元信息后进行逻辑建模，并把各个数据服务模块接口传入的指令解析后将真实的计算命令传给每一个计算资源。
以最常见的OLAP分析场景来看，一般需要从业务库当中将数据进行抽取，加载到大数据（离线）计算服务MaxCompute当中进行集中加工、衍生后，再把所需要分析的数据同步到在线分析库（在大数据量下通常会使用分析型数据库AnalyticDB）当中。
1、数据订阅
在数据服务需要使用数据时，将分散在多个存储当中的数据订阅至数据服务需要计算的位置的功能。
a、对于同步且相应时间要求高的场景来说，需要用户在相应的数据服务当中进行提前的手工订阅操作，
b、对于异步或者请求相应要求不高的同步的计算场景来说，这个订阅过程对于用户来说透明。
2、智能搬运
从分散的数据源抽取数据，加工数据，建表和索引存储到分析数据库analyticDB、关系数据库rds的过程。
对于关系数据库，通过大数据计算maxCompute，再订阅到目标库（rds、analyticDB）
对于流式计算数据场景，将离线数据、流式数据归并，将规则所需数据订阅到【表格存储】，再订阅到目标库（rds、analyticDB）
3、技术架构
4、产品特性
随着不同的业务板块的开展会逐渐纳入更多的数据源，传统数据仓库做法会面临几个问题：
a、需要不断地在物理层进行数据表的归并，下层表的频繁变化可能会造成数据使用的不稳定；
b、当标签需求越来越多，因为不可能无限制的在物理层将数据拼在一张宽表当中，那分散的数据表会越来越多，会造成检索和管理的困难。
c、在不同的应用中不可能是整表使用，往往是需要多张表中的某几列，那多个应用不断的抽取再整合也会造成管理和检索的困难。
d、标签可能是实时数据、也有可能是离线数据，数据存储方式不同同样造成管理使用困难
和传统bi相比，有如下特性：
a、业务视角管理围绕实体-关系-标签这三个元素进行建模，
是从业务的角度出发对数据进行组织管理，而不是从表的概念出发进行建模，便于应用层对数据运用和管理的理解、操作。
b、跨计算的统一逻辑模型
传统建模的数据来源和模型的使用一般在同一数据库当中，
而大数据环境下因为数据采集类型的多样性，和数据计算的多样性使得来源和使用分散在不同的计算存储资源当中，
数据产生与加工可能分布在不同的数据库当中，同一份数据需要进行跨流式、Adhoc类多维分析、离线算法加工等多种方式的计算，
数据需要能在多个存储和计算资源当中自由流转。
标签体系是把多个计算当中的拷贝在逻辑视图上进行唯一映射，即一个标签对应到多个计算当中的物理字段。
c、灵活拓展性
表/标签之间的逻辑关系的建立是在逻辑层上完成的，
这使得模型维护是可以动态建设的，便于模型的维护和管理，而无需在物理层将数据进行归并后再使用。
每一个标签之间可以独立使用，这种离散的列化操作方式也使的数据的使用上更为灵活。
从另一方面来说，计算能力的增强和数据使用场景的丰富，更多的数据计算是需要直接作用在明细的行为数据上，而非只是对指标的多维统计。
传统数据集市建模的“指标-维度”体系就略显狭窄。
标签的定义上涵盖了多种数值类型，既可以是单列，也可以是维度＋标签组成的复合标签（这种方式通常用于描述某种行为），赋予应用操作上更大的灵活度。