数据集市

      数据市场（或叫数据集市，Data Mart）就是一个从操作的数据和其他的为某个特殊的专业人员团体服务的数据源中收集数据的仓库。从范围上来说，数据是从企业范围的数据库、数据仓库，或者是更加专业的数据仓库中抽取出来的。数据中心的重点就在于它迎合了专业用户群体的特殊需求，在分析、内容、表现，以及易用方面。数据中心的用户希望数据是由他们熟悉的术语表现的。

      在实践中，数据中心和数据仓库这两个词可以在某种形式下互相表现。然而，大多数的作者似乎更愿意在谈到用户需求分析的时候用到数据中心这个词，而涉及对已经存在的数据的分析和如何以数据将后将被用到的方式来收集的时候使用数据仓库这个词。数据仓库是数据的中心集合（在地理上可以分布）；数据中心是从数据仓库或者不是数据仓库中抽取出来的数据，它着重在服务于特殊设计目标的易访问性和可用性。一般来说，数据仓库更倾向于是一个战略，但不是一个未完成的概念；而数据中心更倾向于战术，它的目标在于满足即时的需求。　　

       数据仓库（如图1所示）是一个集成的、面向主题的数据集合，设计的目的是支持DSS（决策支持系统）功能。在数据仓库里，每个数据单元都和特定的时间相关。数据仓库包括原子级别的数据和轻度汇总的数据，是面向主题的、集成的、不可更新的(稳定性)、随时间不断变化（不同时间）的数据集合，用以支持经营管理中的决策制定过程。

　　图1所示的以数据仓库为基础的决策支持环境，要求数据仓库能够满足所有最终用户的需求。然而，不同最终用户的需求侧重点是不同的，这就要求数据仓库存储的数据要具有充分的灵活性，以能够适应各类用户的查询和分析；另一方面，最终用户对信息检索要求是高性能—越快越好。但是，对数据仓库而言，灵活性和性能（速度）是一对矛盾体—要保障灵活性以满足尽可能多用户的查询需求会影响整个数据仓库的性能。为了解决灵活性和性能之间的矛盾，数据仓库体系结构中增加了数据集市（如图2所示）—一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据，从而满足用户对性能的需求。

一、数据集市的特征

      数据集市的特征包括规模小；有特定的应用；面向部门；由业务部门定 义、设计和开发；业务部门管理和维护；能快速实现；购买较便宜；投资快速回收；工具集的紧密集成；提供更详细的、预先存在的、数据仓库的摘要子集；可升级到完整的数据仓库。

二、数据集市中数据的结构

      数据集市中数据的结构通常被描述为星型结构或雪花结构。一个星型结构包含两个基本部分—一个事实表和各种支持维表。事实表描述数据集市中最密集的数据。在电话公司中，用于呼叫的数据是典型的最密集数据；在银行中，与账目核对和自动柜员机有关的数据是典型的最密集数据。对于零售业而言，销售和库存数据是最密集的数据等等。

      事实表是预先被连接到一起的多种类型数据的组合体，它包括：一个反映事实表建立目的的实体的主键，如一张订单、一次销售、一个电话等等，主键信息，连接事实表与维表的外键，外键携带的非键值外部数据。如果这种非键外部数据经常用于事实表中的数据分析，它就会被包括在事实表的范围内。事实表是高度索引化的。事实表中出现30到40条索引非常常见。有时实事表的每列都建了索引，这样作的结果是使事实表中的数据非常容易读取。但是，导入索引所需的资源数量必须为等式提供因数。通常，事实表的数据不能更改，但可以输入数据，一旦正确输入一个记录，就不能更改此记录的任何内容了。

      维表是围绕着事实表建立的。维表包含非密集型数据，它通过外键与事实表相连。典型的维表建立在数据集市的基础上，包括产品目录、客户名单、厂商列表等等。

      数据集市中的数据来源于企业数据仓库。所有数据，除了一个例外，在导入到数据集市之前都应该经过企业数据仓库。这个例外就是用于数据集市的特定数据，它不能用于数据仓库的其他地方。外部数据通常属于这类范畴。如果情况不是这样，数据就会用于决策支持系统的其他地方，那么这些数据就必须经过企业数据仓库。

      数据集市包含两种类型的数据，通常是详细数据和汇总数据。就像前面描述过的一样，数据集市中的详细数据包含在星型结构中。值得一提的是，当数据通过企业数据仓库时，星型结构就会很好的汇总。在这种情况下，企业数据仓库包含必需的基本数据，而数据集市则包含更高间隔尺寸的数据。但是，在数据集市使用者的心目中，星型结构的数据和数据获取时一样详细。

      数据集市包含的第二种类型数据是汇总数据。分析人员通常从星型结构中的数据创建各种汇总数据。典型的汇总可能是销售区域的月销售总额。因为汇总的基础不断发展变化，所以历史数据就在数据集市中。但是这些历史数据优势在于它存储的概括水平。星型结构中保存的历史数据非常少。

      数据集市以企业数据仓库为基础进行更新。对于数据集市来说大约每周更新一次非常平常。但是，数据集市的更新时间可以少于一周也可以多于一周，这主要是由数据集市所属部门的需求来决定的。

三、关于数据集市的误区

      误 区1：数据集市是比较小的。用大小来判断一个企业是在实施数据仓库还是数据集市的做法是很天真的。一种定义认为数据量小于50GB 的数据库是数据集市， 大于50GB 的是数据仓库。事实上， 数据集市集中解决的是某一种业务功能的特殊需要， 并且维持数据和数据模型来满足这种要求。尺寸大小不是数据集市的本质特征， 因为它同样可以有几百GB 的描述更多细节的数据。 数据集市也可以只有几个GB 的综合数据就可以满足面向应用的执行信息系统的需要。 真正的问题在于， 数据集市（它可能是一个数据仓库的子集） 的数据模型一定是满足应用的特定需求的。

      误区2：数据集市容易建立， 可以更快地投入运行。 一个单一的数据集市的确比数据仓库的复杂性程度低一些， 因为它只针对某一需要解决的特定的商业问题， 但是围绕数据获取的很多复杂问题并没有减少。 数据获取包括从可以使用的数据源中提取、 确认和集成数据， 把它们输送到数据集市和数据仓库中。 

       数 据 集 市 往 往 要 从 多 个 数 据 源 中 提 取 数 据， 这 就 需 要 一 个 可 以 从 多 个 数 据 源 提 取 数 据 的 应 用 程 序。 这 个 过 程 很 耗 时， 因 为 这 个 过 程 与 建 立 一 个 数 据 仓 库 一 样， 需 要 相 同 的 计 划 和 管 理， 并 且 需 要 把 数 据 模 型 化。

       对 于 数 据 仓 库 的 批 评 是 在 数 据 仓 库 推 出 时， 就 因 为 商 业 需 求 的 迅 速 变 化， 已 经 成 为 过 时 的 了。 然 而， 数 据 集 市 在 很 快 过 时 方 面 的 风 险 更 大， 因 为 它 针 对 某 种 特 别 需 求， 而 数 据 仓 库 建 立 的 是 一 种 中 性 的 应 用。 与 经 常 发 生 在 数 据 仓 库 身 上 的 情 况 一 样， 经 常 是 数 据 集 市 刚 刚 投 入 运 行， 需 求 已 经 发 生 了 变 化， 部 门 已 经 重 组， 职 能 已 经 转 变， 数 据 集 市 的 作 用 比 想 象 的 要 小 的 多。

       误 区3： 数 据 集 市 很 容 易 升 级 成 数 据 仓 库。 事 实 上， 数 据 集 市 针 对 特 殊 的 业 务 需 要， 不 可 能 很 容 易 地 伸 缩。 它 们 发 布 特 定 应 用 的 数 据 模 型， 所 以， 如 果 没 有 事 先 的 重 塑 数 据 模 型， 追 加 数 据 是 非 常 困 难 的。 而 且， 因 为 在 实 施 数 据 集 市 时， 忽 略 了 很 多 结 构 问 题， 所 以， 当 试 图 扩 展 数 据 宽 度 时 更 加 困 难。 例 如， 一 个 数 据 集 市 可 以 很 快 地 解 决 一 个 业 务 问 题， 比 如， 怎 样 找 到 最 畅 销 款 式 的 鞋 的 销 售 数 字， 为 了 增 加 关 于 这 种 鞋 的 信 息， 比 如， 新 顾 客 的 百 分 比， 就 需 要 新 的 数 据 模 型。 相 反， 数 据 仓 库 是 分 阶 段 建 设 的， 而 且 同 时 可 以 建 设 一、 二 个 主 题 领 域， 它 就 提 供 了 相 对 中 性 的 应 用， 当 增 加 主 题 和 应 用 时， 它 的 结 构 也 容 易 升 级。

      数 据 集 市 的 实 施 方 针 ---- 当 这 些 不 切 实 际 的 观 念 被 驱 散 以 后， 就 可 以 讨 论 实 施 方 针 问 题 了。
      1 ． 为 数 据 集 市 准 备 与 数 据 仓 库 不 同 的 实 施 队 伍。 不 要 低 估 建 立 一 个 数 据 集 市 所 需 要 的 资 源。 通 常 的 错 误 是 用 建 立 数 据 仓 库 的 同 一 支 队 伍 来 搞 数 据 集 市， 这 支 队 伍 通 常 会 被 业 务 领 域 的 即 时 战 术 性 需 求 搞 的 心 烦 意 乱 — — 而 数 据 集 市 正 是 基 于 这 个 需 求 才 会 被 建 立， 因 此 不 能 提 供 数 据 仓 库 体 系 结 构 所 需 的 重 点 和 计 划。 如 果 使 用 不 同 的 实 施 队 伍， 就 可 以 在 数 据 仓 库 建 设 中 采 用 数 据 集 市 建 设 中 已 经 取 得 的 成 果， 进 而 有 效 地 节 约 资 源。

       2 ． 数 据 集 市 的 精 心 计 划 可 以 应 用 在 数 据 仓 库 项 目 中。 数 据 集 市 最 好 的 方 法 是 当 这 个 业 务 领 域 朝 着 数 据 仓 库 的 战 略 目 标 前 进 时， 它 仍 然 能 够 满 足 需 要。 很 多 数 据 集 市 方 案 供 应 商 说, 这 样 的 实 施 是 容 易 的， 并 且 可 以 避 免 很 多 关 于 数 据 调 查、 集 成 和 转 换 的 复 杂 任 务 的 讨 论。

       数 据 集 市 的 项 目 负 责 人 和 数 据 仓 库 的 负 责 人 应 该 密 切 合 作， 相 互 沟 通， 以 减 少 多 余 的 数 据 调 查 工 作。 在 数 据 调 查 过 程 中 采 集 的 信 息 可 以 存 储 起 来， 通 过 提 取 和 转 换， 成 为 新 的 数 据 仓 库 的 数 据 元 素。

      3 ． 业 务 领 域 对 于 战 术 型 解 决 方 案 的 需 求 更 加 敏 感。 由 于 来 自 商 业 用 户 对 关 键 数 据 需 要 的 压 力， 企 业 必 须 确 定 那 些 领 域 迫 切 需 要 建 设 数 据 集 市。 这 一 步 骤 要 得 以 迅 速 实 施， 必 须 对 使 用 的 数 据 进 行 分 析， 并 且 挑 选 出 业 务 领 域 中 对 数 据 要 求 的 重 叠 部 分， 这 样 才 能 减 少 数 据 调 查 的 工 作 量 和 实 施 的 时 间。

       4 ． 把 数 据 源 限 制 在3 个。 数 据 获 取 是 数 据 集 市 和 数 据 仓 库 建 设 中 最 复 杂 的 部 分。 有 些 企 业 只 有 一 个 或 两 个 关 系 数 据 库 作 为 数 据 源， 但 是 由 于 一 般 的IS 部 门 支 持5 ～8 种 数 据 管 理 技 术 和30 ～50 个 数 据 存 储 点， 数 据 获 取 和 集 成 的 复 杂 性 就 很 快 成 为 数 据 集 市 建 设 中 最 难 掌 握 的 问 题 了。 假 如 数 据 源 超 过3 个， 并 且 这 些 数 据 源 都 是 很 关 键 的， 那 么 就 应 该 考 虑 建 立 另 一 个 数 据 集 市 了。

      5 ． 制 定 一 个 政 策 来 预 防 数 据 集 市 的 膨 胀。 每 一 个 数 据 集 市 的 实 施 都 增 加 了 数 据 获 取 和 维 护 的 过 程， 这 个 过 程 增 加 了 运 行、 维 护 和 管 理 费 用。 原 来 被 认 为 是 运 行 系 统 维 护 的 子 项 目， 现 在 变 得 更 加 复 杂。 企 业 因 此 应 该 制 定 政 策， 预 防 数 据 集 市 的 膨 胀， 一 旦 数 据 仓 库 建 成， 就 可 以 用 作 数 据 集 市 的 数 据 源。

       数 据 集 市 通 过 向 特 定 的 业 务 领 域 提 供 特 殊 应 用 的 数 据 源 和 数 据 模 型 来 支 持 决 策。 遵 循 本 文 提 供 的 实 施 方 针， 企 业 可 以 为 需 要 的 业 务 领 域 提 供 数 据 集 市 解 决 方 案， 同 时 为 建 立 一 个 战 略 性 的 数 据 仓 库 做 好 准 备。

四、“仓库”和“集市”的区别

　　数据仓库和数据集市之间的区别，可以用图3（来自www.billinmon.com）直观地表示。
　　从图中可以看出，数据仓库中数据结构采用规范化模式（关系数据库设计理论），数据集市的数据结构采用星型模式（多维数据库设计理论）。数据仓库中数据的粒度比数据集市的粒度细。图3反映了数据结构和数据内容的两个特征，其他方面的比较则如表1所示。

　　数据集市能“独立”吗？

　　企业规划数据仓库项目的时候，往往会遇到很多数据仓库软件供应商。各供应商除了推销相关的软件工具外，同时也会向企业灌输许多概念。其中，数据仓库和数据集市是最常见的两个术语了。各个供应商术语定义不统一、销售策略不一样，这往往会给企业带来很大的混淆。最典型的问题是：到底是先上一个企业级的数据仓库呢？还是先上一个部门级的数据集市？这其实是是否要上独立型数据集市的问题。

　　数据集市可以分为两种类型—独立型数据集市和从属型数据集市。独立型数据集市直接从操作型环境获取数据，从属型数据集市从企业级数据仓库获取数据，带有从属型数据集市的体系结构如图2所示。
　　数据仓库规模大、周期长，一些规模比较小的企业用户难以承担。因此，作为快速解决企业当前存在的实际问题的一种有效方法，独立型数据集市成为一种既成事实。独立型数据集市是为满足特定用户（一般是部门级别的）的需求而建立的一种分析型环境，它能够快速地解决某些具体的问题，而且投资规模也比数据仓库小很多。
　　独立型数据集市的存在会给人造成一种错觉，似乎可以先独立地构建数据集市，当数据集市达到一定的规模再直接转换为数据仓库。有些销售人员会推销这种观点，其实质却常常是因为建立企业级数据仓库的销售周期太长以至于不好操作。
　　多个独立的数据集市的累积，是不能形成一个企业级的数据仓库的，这是由数据仓库和数据集市本身的特点决定的—数据集市为各个部门或工作组所用，各个集市之间存在不一致性是难免的。因为脱离数据仓库的缘故，当多个独立型数据集市增长到一定规模之后，由于没有统一的数据仓库协调，企业只会又增加一些信息孤岛，仍然不能以整个企业的视图分析数据。借用Inmon的比喻：我们不可能将大海里的小鱼堆在一起就构成一头大鲸鱼，这也说明了数据仓库和数据集市有本质的不同。
　　如果企业最终想建设一个全企业统一的数据仓库，想要以整个企业的视图分析数据，独立型数据集市恐怕不是合适的选择；也就是说“先独立地构建数据集市，当数据集市达到一定的规模再直接转换为数据仓库”是不合适的。从长远的角度看，从属型数据集市在体系结构上比独立型数据集市更稳定，可以说是数据集市未来建设的主要方向。

　　数据集市怎么建？

　　建立不同规格的数据仓库、数据集市的成本，国外的咨询机构有专门的评估，在一定程度上可以借鉴。但是这些结果在国内也许并不适用，因为国情不同，在国内的构建成本需要专门的调研。以我们为企业构建的客户主题数据集市为例，一般成本在20万元到50万元人民币之间。

　　数据仓库（集市）的设计可以采用迭代式的方法。在迭代式开发中，每个迭代为上一次的结果增加了新的功能。功能增加的顺序要考虑到迭代平衡以及尽早发现重大风险。通俗地说，就是在正式交货之前多次给客户交付不完善的中间产品“试用”。这些中间产品会有一些功能还没有添加进去、还不稳定，但是客户提出修改意见以后，开发人员能够更好地理解客户的需求。如此反复，使得产品在质量上能够逐渐逼近客户的要求。这种开发方法周期长、成本高，但是它能够避免整个项目推倒重来的风险，比较适合大项目、高风险项目。

　　理论上讲，应该有一个总的数据仓库的概念，然后才有数据集市。实际建设数据仓库（集市）的时候，国内很少这么做。国内一般会先从数据集市入手，就某一个特定的主题（比如企业的客户信息）先做数据集市，再建设数据仓库。数据仓库和数据集市建立的先后次序之分，是和设计方法紧密相关的。而数据仓库作为工程学科，并没有对错之分，主要判别方式应该是能否解决目前存在的实际问题，并为今后可能发生的问题保持一定的可伸缩性。

　　“实战”分析

　　数据仓库、数据集市到底如何应用呢?让我们从一个例子分析——假设为某银行构建一个分行级别的数据仓库，再为该分行国际业务部构建从属型数据集市。

　　数据仓库的数据来源于银行的业务系统，包括储蓄、卡、个贷、外汇宝、中间业务等等，分析的主题包括客户、渠道、产品等。数据仓库的数据粒度根据分析的要求而定，一般包括具体的历史记录（存款、取款、外汇交易、POS消费、中间业务缴费记录）。然后，将这些记录汇总到天、周、月、季度、年等各个层次，具体数据粒度由分析的需求而定。另外，数据仓库还存储一些业务逻辑——为分析而计算的一些指标。比如，客户的价值或客户的忠诚度。这些指标的计算不能通过单一的业务系统取得，它需要从所有业务上综合考虑，这也是数据仓库系统的优点之一。

　　假设整个分行有20万个客户，那么数据仓库将包20万个客户所有业务的历史数据、汇总数据以及数据仓库指标数据，数据量会达到几十甚至数百G（这只是非常小规模的数据仓库）。为了满足全行所有部门用户的查询和分析，数据仓库只能采用范式化设计。这样，不管用户有什么查询需求，只要有数据存在就能满足所需。

　　假设国际业务部门的客户有2万人（使用外汇宝）。如果不构建数据集市，他们会直接在数据仓库上查询相关的信息，比如外汇宝客户去年一年外汇交易额在各种交易方式（柜台、网上、电话银行等）的分布。这种查询的效率和性能是非常低的，如果各个部门的所有用户都直接在数据仓库上查询相关的信息，数据仓库的性能会下降，以至于无法满足大多数用户对性能的需求——谁都不愿意为一个简单的查询等待数分钟甚至数小时。因此，构建部门级的数据集市是非常必要的，这主要基于性能上的考虑。国际业务部门的数据集市，集中了数据仓库中与本部门直接相关的业务数据，例如2万个客户外汇交易的历史数据以及汇总。它采用星型模式（雪片或两者混合），可以方便OLAP工具的查询和分析。

　　背景资料：迭代式开发方法已存在很久了，它还拥有其它不同的名称，如“渐进式”（Evolutionary）、“阶段式”（Staged）、“螺旋式”（Spiral）等等。迭代式开发重要问题之一是迭代阶段需要多长。一般的趋势是让每一个周期尽可能地短，这样就能得到频繁的反馈，及时地知道开发者所处的状况。
部分摘自：中国计算机用户