聊聊有关数据的一些基本概念和常见误区（下）

在上一期文章中，笔者分享了四组有关数据的基本概念和常见误区，接下来还有六组要讲，任重而道远哪！那么我们闲话少说，直接进入主题。如果说前四组比较偏纯概念的话，那么我们接下来就从实实在在的系统平台开始吧。

（五）数据集市、数据仓库、应用数据库、数据工厂

笔者此前在一家金融机构交流数据集市的时候，了解到许多同事对数据集市以及相关的几个概念理解的不是特别准确，这也给项目工作目标和计划推进造成了一定的困扰。业务人员都纷纷提出来，为什么要建立数据集市，我们业务部门才不关心科技部是通过数据仓库、数据集市还是什么其他数据库来实现，我们要的就是简简单单的能够满足日常业务用数需求的一个平台！

是的，笔者百分之百支持业务用户的这个观点。对于用户而言，只要能够满足其用数需求，通过什么方式那是技术的问题。不过呢，如果我们打个比方，那么大家就能看到原来数据集市和业务用户还是有着一定关系的（笑）。

首先，我们把企业看成一个家庭，把用户看成家庭成员，把数据看成一种商品（以食品为例吧）。

在家里，孩子想喝饮料、吃水果等，可以直接去冰箱里拿。妈妈煮饭炒菜煲汤，也去冰箱里拿蔬菜、肉类等原材料。用户什么时候想吃东西了，能够很方便的从冰箱里直接取来食用，或进行加工后再食用。那么，这个冰箱就像是应用数据库（或叫应用系统的数据库），冰箱里的食品就是数据。应用数据库能够快速的解决业务用户日常的用数需求，想要直接拿就行了，快速便捷。

但是，冰箱本身存储的东西是有限的，如果冰箱里的东西没了怎么办？那么当然是重新去超市采购喽，不过这个活不一定要所有的人来干，在家里买菜这样的活一般还是由妈妈负责，这样看起来妈妈是管理员（当然同时也是用户），爸爸和孩子才是真正的业务用户啊！（笑）

好了，妈妈去超市买菜去了，这里的超市就可以比做是数据集市。超市里分海鲜区、蔬果区、肉类区、饮料区等等，东西应有尽有，且按照客户的需要进行分门别类管理，便于大家进入相应的区域采购。那么数据集市也是如此，按照业务应用需求，把数据进行分类，形成不同的主题区，比如风险主题集市存储了风险管理所需的数据，管会主题集市存储了管理会计所需的数据，监管主题集市存储了外部监管统计信息披露所需的数据等等，便于管理和使用。

妈妈买完东西后，再把食品存放到家里的冰箱里，以供所有家庭成员取用。同理，业务部门的管理员会定期从主题集市中获取所需的数据，并返给应用数据库支持日常用数，只不过往往这个动作不是人工来执行，而是定制好后通过系统接口自动批量处理。这样，数据集市就完成了对应用数据库的供数了！

噢，那么大家自然而然就想到了，超市的货仓一定就是数据仓库啦！是的，这个货仓可以存储的东西非常多，虽然也是按照不同的商品分类进行管理（好比数据仓库的分区），但是用户一般不会直接到仓库里买东西，所以和用户来讲是相对隔离的。能接触仓库的就是库管员和送货员，这些人往往都是技术背景的，不属于业务用户的范畴。当然，事无绝对，不排除有些商家采取批发直销的模式，让用户直接去仓库里取货（国外有好多批发超市），不过这种情况毕竟较少了。所以，业务用户直接从数据仓库取数的情况也不是完全不存在的。

通过以上的生活实例，相信大家很容易能看出来数据集市与数据仓库、应用数据库之间的区别和联系了。所以，数据集市对业务部门来说还是很有意义的，因为至少同时作为管理员和用户的妈妈还是需要到超市里采购东西的，而且不排除作为真正业务用户的爸爸和孩子也愿意去逛逛超市，直接选择自己想要的产品（笑）。大家想想，如果家里附近没有超市，那是一件多么不方便的事啊，这就是建立数据集市的意义所在！

最近业界还出现一个很新、很火的概念，叫数据工厂，很多人不理解它的含义和定位。没关系，还是拿上面的例子来解释。大家都知道，去超市买完鱼后回来得自己去鳞、取鳔等，一系列动作特别繁琐且不便，现在的年轻人一般都懒得做。好了，如果说有这样的数据工厂，能够按照用户的需求进行数据的定制加工，帮你把这一系列麻烦事做了，甚至还可以再进一步定制化的把鱼给清炖或红烧了，那么用户就可以直接获得加工好的数据产品，何乐而不为？不过，这个加工厂如何选址、按什么工序加工、如何配送那是科技部的事，用户可以不用管了，提出对最终产品的要求即可。

（六）数据平台、大数据平台、元数据平台、数据服务平台

数据平台是一个很大的概念，但是这个概念在日常工作中往往被用的窄了。比如，很多业务用户认为数据平台就是报表平台、或者数据仓库，这和大家关注点、出发点不同是有很大关系的。

这么说吧，数据和信息是对等的，平台和系统是对等的，那么数据平台和信息系统也就是对等的。大家都知道，信息系统是多么大的概念啊，那么数据平台也是如此。有些金融机构说我们计划要建个数据平台，想问问专家有什么建议。这就好比说我想建个信息系统，请你告诉应该怎么做一样让人难以具体回答，因为还没说清楚要建什么样的信息系统。所以，咱们首先还是要清楚数据平台到底包括哪些范围和类型。

一般来说，数据平台从大面上可以分为：数据整合平台、数据管理平台、以及数据应用平台。当然，这只是第一层级的划分，不过目前业界的数据相关平台都可以归到这三大类中。

数据整合平台指的是把数据从源系统进行收集和整合、加工处理、存储和共享的平台。数据整合平台的首要目标是形成企业级统一、共享的整合数据，为后续的数据应用提供基础。当然，整合平台也不仅仅是简单整合，还包括一定的数据加工。上面提到的数据集市、数据仓库、数据工厂都属于数据整合平台的范围。

那么大家自然就会问，那么大数据平台呢，是否属于数据整合平台的范围？严格意义上不完全是，就看这大数据平台是广义的还是狭义的了。应该这么讲，广义的大数据平台和数据平台是在一个层级的，它也包括了大数据的整合平台、管理平台和应用平台。不过目前业界所说的大数据平台一般还是偏狭义的，即只包括大数据的整合平台。也就是说，狭义的大数据平台指的就是把海量的大数据进行整合和存储的平台。

区别于传统的数据整合平台，大数据平台架构由于其处理的数据类型和性质而与传统平台存在较大不同。在此前已经和大家聊过大数据的特点，那么大数据平台比较特别的地方就在于它可以高效处理海量的历史数据、外部数据、特别是非结构化数据，一般是基于Hadoop分布式架构，具有高效性、高容错性和高扩展性的特点。而传统的数据整合平台（如数据仓库）多为关系型数据库，仅比较擅长处理结构化的数据。

再来说数据管理平台，数据管理平台的目标是实现数据全生命周期的管理，确保前面提到的数据治理、管理和管控措施的系统落地，保障数据质量。元数据平台就属于数据管理平台的范畴，通过元数据的管理最终实现对数据的管理。

数据管理平台的用户主要是数据管理部门和技术部门，当然也包括数据的业务用户。不过对于业务用户而言，数据管理平台最重要的意义主要体现在，一是可以查询并了解企业级的数据规范，包括数据的业务定义、统计规则等规范语言，二是在发生数据变化后，能够进行上下游的提示。例如，数据源发生变化后影响到后端的报表应用，报表用户能够及时获取变化信息，评估对自身用数的影响并制定应对措施。这个点其实非常重要，笔者在与很多业务部门同事沟通的过程中，许多人都提出了对此类上下游数据问题的不满，好比财务部的同事会抱怨前台部门修改数据前、后都没有及时和财务部进行沟通，最后报表都已经对外报送了，但是前台数据修改后就又导致业财不一致了。这类问题可通过数据管理平台解决。

最后再来说说数据应用平台，这也是业务用户最关心的、直接使用的用数平台。企业的报表平台、统计报送平台、指标系统、管理驾驶舱系统、决策支持平台、以及高阶的数据分析和挖掘工具等都属于数据应用平台的范畴。简单一句话概括，就是支持最终业务用户日常用数的应用交付平台。不论是数据整合平台、还是大数据平台，最终都是服务于业务用户的用数需求，虽然在应用模式上有所区别，有初阶的固定报表、数据模板应用，也有中阶的指标多维灵活查询、决策驾驶舱应用，还有高阶的大数据分析和挖掘应用，都需要通过数据应用平台进行实现数据服务的最终交付。

很多同事还会问，那么数据服务平台又是什么？和数据应用平台有何区别？以笔者个人的观点，数据服务和应用都属于一个范畴，即服务于用户的视角，实在没必要进行如此独立的平台区分，许多金融机构也是只建设统一的数据应用平台。如果非要区分两者间的区别的话，那么笔者认为，数据应用更偏重于最终的数据结果交付，比如说用户通过应用界面获得想要的报表或指标；而数据服务更偏重于过程的调度，比如进行用户用数偏好分析以便选择用户可能需要的数据进行主动推送等。

（七）基础数据、主数据

上面讲完有关系统和平台的两组概念后，接下来又要回到比较抽象的几组概念了，不过大家不用担心，笔者会尽量用简单的语言快速说明，大家别打瞌睡（笑）。

先来聊聊基础数据。基础数据是相对于衍生数据而言的，是从业务前端直接产生和采集的，未进行过加工计算的基础性数据。例如，业务交易产生的交易流水数据、采集的客户基础数据、签署的合约数据等，都属于基础数据的范畴。基础数据是企业开展日常业务经营所直接产生的，为中、后台的风险管理、财务核算、管理分析和统计应用等提供了数据基础。

基础数据的缺失和质量不高是目前业界碰到的最大难题。许多企业在开展数据统计和分析时，都或多或少遇到由于基础数据缺失而导致难以进行准确的分析和预测，无法更好的支持经营管理与决策，这个困难直接体现了企业的业务前台和中、后台管理之间的先天矛盾。

从前台的角度来讲，其主要的任务在于提高业绩、提升客户体验。基础数据的采集和维护一般都需要前台业务部门人员来执行，而这项工作却往往没有纳入其绩效考核的内容，因此往往引不起前台业务人员的重视。另一方面，在业务交易过程中进行数据的采集和维护也是需要一定的时间成本，如果在客户办理业务时过分强调信息的高质量采集，也会影响业务的办理效率和客户体验。而中、后台人员为了满足其管理目的，则希望前台能够尽可能多的采集所需的基础数据。看起来，这还真是一个难以调和的矛盾啊。笔者此前就曾遇到这样一种情况，企业的后台部门为了获取统计报送所需数据，提出了前台业务系统改造的数据需求，但是前台业务部门以影响业务效率为由拒绝接受，导致了相关工作难以顺利推进。相信许多中、后台管理人员都有类似的体会吧！

所以，为了更好的协调这个先天的矛盾，我们还是要站在前台业务的视角来解决问题，而不是一味的互相推卸和指责。首先要找到一个契合点，即哪些数据是前、中、后台部门，特别是前台部门关心的数据，这些数据又能如何解决前台部门的用数需求，那么就能够求同存异，找到关键数据范围作为切入点，并以应用迭代的方式逐步完善基础数据的采集。例如，我们曾帮助企业建立客户交叉销售、客户维挽等数据分析模型以便更好的支持业务经营，通过这类应用项目，前台部门深刻意识到客户数据采集的重要性，并主动开展客户基础数据质量的提升工作。

在基础数据中，有一类数据非常重要，作为不同系统之间交互和共享的关键数据，我们把它称之为“主数据”。例如，不同业务系统都会有客户的数据、产品的数据，那么如果每个部门、系统都分别维护这些数据，必然会造成不一致。因此，需要在企业级建立统一的主数据管理，如客户主数据、产品主数据、机构主数据等，在全公司范围内都应是统一且唯一的，并确定部门和系统间交互识别这些主数据的唯一标识，如客户编号、产品编号、机构编号等。那么，这些唯一标识也成为了主数据中的主数据了，是开展主数据管理首先要统一、整合的对象。虽然这是项非常基础性的工作，但是许多企业却不见得做的好，例如有些金融机构的客户编号就没有在企业级范围进行统一，系统间的客户信息无法唯一识别，同一客户可能在机构内存在多条记录却并未整合等等。我们经常说，解决问题就要抓住问题的主要矛盾，那么主数据问题就是所有数据问题中需要迫切解决的关键性问题了。

（八）衍生数据、指标

基础数据和衍生数据是相对的两个概念，讲完基础数据，那自然就要说到衍生数据。

衍生数据是指按照一定的规则和逻辑，对已有的数据进行计算和加工后形成的数据。相对于基础数据可直接由前台部门采集而言，衍生数据一般是基于基础数据或其他衍生数据的再加工。

衍生数据常见的质量问题和基础数据不同，基础数据难在采集这个环节，而衍生数据却难在统一口径规范上。一般来说，金融机构的前、中、后台部门由于其视角和目的不同，对特定衍生数据会有不同的计算规则和口径，这也就导致了数据不一致问题。但是，这类问题解决起来相对基础数据还是简单一些，只要企业能够自上而下统一进行标准化的规范，明确衍生数据的唯一定义部门和加工系统，那么很多问题都迎刃而解了。不过说起来容易做起来难，这里面仍然需要协调各部门的不同利益和需求。

相对于基础数据中的主数据，衍生数据中也有一些非常关键的数据，用于满足管理层日常的经营管理和决策支持，我们把这些衍生数据称之为指标。

笔者在和业务人员交流的时候，其实很多人都不太清楚衍生数据的概念，但是只要提到指标，大家一下子就明白了，毕竟日常工作中都用到了各种指标。如果非要来区分一下衍生数据和指标的话，那么可以这么理解，衍生数据是一个广泛的技术概念，但是指标更偏重于业务应用，这也是为什么许多金融机构近期致力于建设企业级指标体系的原因，因为只有指标才是管理层和业务部门关心的，衍生数据离业务太远了（笑）。

接下来就简单说明一下有关指标体系的几个基本概念。

（九）报表统计项、指标、维度、度量

指标是反映对象特征属性的、可衡量的单位或方法，是具有（业务）意义的指向和标杆。

指标可分为基础指标和衍生指标，其中基础指标是具备宽泛定义的统计对象，从而为指标的灵活组合与多维分析提供基础。衍生指标是在基础指标的基础上，通过添加一个或多个统计维度形成新的指标、或通过不同指标进行运算而形成新的指标。一般来说，指标都属于衍生数据。

维度（或称统计维度、筛选条件）是对指标进行描述的不同视角，用于标示指标的不同方面的属性，例如对贷款余额这个指标，可以按照产品类型维度（如个人消费贷款、个人住房贷款等）来分析，可按照资金投放行业维度（如农、林、牧、渔等）来分析、可按照贷款期限维度（如长期、中期、短期等）来分析、也可以按照贷款状态维度（如正常、不良等）来分析等。一般来说，维度都属于基础数据。

度量是针对指标而言，和维度并没有关系，是指标的度量衡，本身并无实际统计意义，如金额、余额、比率、笔数、个数等。例如，贷款余额这个指标的度量就是余额。而报表项、统计项等无非就是指标的应用了，企业所抽象出来的指标都是来自于各类报表的具体报表项或统计项，并回过头来应用于不同的报表。

有关具体如何建设企业级指标体系，笔者在这里就不展开了，内容确实比较多，以后有机会可以专题讨论一下，很有意思的，特别是如何应用指标体系这块，能够有效解决企业的用数需求。

（十）数据模型、数据分析模型、统计模型、数据建模

近期大数据分析特别火，所以很多朋友都在谈论数据分析和建模，这就引起了许多有关模型的概念了。

其实大家在谈的数据分析模型是一种统计模型（或者叫数学模型），是以数学统计的算法构建的复杂模型，满足于一定的应用场景。目前数据分析模型的应用场景较常用于两个方面，一是客户营销，二是风险管理。在风险管理领域，许多银行金融机构为了满足新资本协议的合规要求，建立了相应的风险计量模型，实际这也是属于统计模型的一种应用了。

数据分析模型一般需要输入大量的历史数据，按照既定的参数和算法进行模型计算后，输出对业务有意义的分析结果，例如有潜在产品需求的目标客户清单、特定价格策略下客户响应预测、存量贷款未来逾期的概率预测、最低资本要求等等。数据分析模型最终还是要服务于特定的业务经营和管理要求。

相对于数据分析模型，数据模型的含义可就不同了。数据模型指的是数据的结构和关系。最顶层的模型一般是概念模型，主要是从业务视角提出的对数据的概念性的需求表述。具体的数据模型一般会分为数据的逻辑模型和物理模型。逻辑模型指的是数据之间的逻辑关系，一般通过实体关系（ER）图来体现；而物理模型大家可以简单理解为数据库的表结构了。

数据分析模型更偏重于业务应用和决策支持，数据模型则更偏重于系统设计和实施，两者的目标是不同的。

解释完这几个模型的区别，那么模型的构建（简称为“建模”）就很清晰了。业界说的数据建模一般指的还是数据模型的构建，但是描述不够准确，叫“数据模型建模”更加准确。而数据分析模型的构建则可以叫“分析模型建模”或“统计模型建模”。当然，在日常用语中，大家只说建模就可以了。

结束语：希望以上的概念解释和经验分享对朋友们理解相关术语有所帮助，许多观点也都是笔者个人的见解，不一定很准确，也算是抛砖引玉了，欢迎大家批评指正！