新浪微博「点赞功能」数据库如何设计的

对于第一个问题，设计一个schema->(messageID，likedCount)，记录每条微博的点赞数。messageID是微博的编号，likedCount是该微博的点赞人数。但是这里有两个问题需要解决，第一是并发，第二是数据量。

每条微博都有可能有很多人同时点赞，为了保证点赞人数精确就需要保证likedCount++是原子 *** 作，这个可以由应用程序来实现，也可以用redis的事务来实现(如果redis有事务机制或者自增功能的话)，但是我觉得为了性能考虑，也可以不用实现原子 *** 作，具体原因就不展开了。

每天都上亿可能更多的微博内容产生，这样就会有上亿个新的(messageID，likedCount)生成，这样的数据量是比较大的，单机数据库比较难提供高效的服务，所以需要采取sharding的功能(有时候也叫分表分库)，可能根据messageID把这些schema分散到十个或者更多的shards上(据说，sina微博有600个节点，如何三个节点组成一个shard，就有200个shards)，这样每个shard处理的请求就只有原来的十分之一，从而就能提高服务的性能。

关于点赞人列表的设计，一般来说，可能想到的schema是(messageID，userID)，但是这样的设计有一个小问题，就是有些大发的微博可能会得到几十万的点赞，这样就会产生几十万个条数据，这样数据有点多，读取起来可能也慢。所以可以用这样一个schema(messageID，partID，userIDs)，让一个messageID对于多个userID，同时比对应太多的userID，所以加入一个新的partID，一个part存1000个userID，这样几十万个点赞，只需要存几百条数据。这样做还有一个好处，用户点赞人时的，一般都不是完全显示所有点赞人，而是一批一批显示，这样可以一次只读一条数据，就可显示一批点赞用户信息。

浅析数据仓库的构建方法

随着不同的管理信息系统（MIS）在企业不同部门的大规模应用及企业对数据管理不断提出新的要求，不仅要求能实现传统的联机事务处理，而且越来越多的要求是各种应用系统能够在企业不断积累的以及从企业外部获取的丰富信息资源的基础上，把这些分散的、不一致的、凌乱的信息资源加以利用，即更多地参与数据分析和决策支持，由此出现了一种用于数据分析处理和决策支持的数据存储和组织技术，即数据仓库技术。

1、什么是数据仓库

数据仓库是面向主题的、集成的、具有时间特征的、稳定的数据集合，用以支持经营管理中的决策制定过程。数据仓库提供用户用于决策支持的当前和历史数据，这些数据在传统的 *** 作型数据库中很难或不能得到。

面向主题是指数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个 *** 作型信息系统相关。集成的是指数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

数据仓库的体系结构分数据源、数据转换、数据仓库、数据集市和用户几部分。数据源，包括企业内部的业务数据、遗留数据、其它业务系统数据及相关WEB数据等；数据转换是数据仓库构建的重要环节，主要是对各种复杂的数据源进行抽取、转换、装载及其他处理，同时要实现数据质量跟踪监控以及元数据抽取与创建等工作；数据仓库主要实现对各种数据的组织、存储及管理等；数据集市是为不同业务而单独设计的数据仓库系统，即开发者为企业内部的不同用户群定制特殊的数据仓库子系统。用户部分，即具体面向使用者的应用部分，主要是指数据仓库存取与检索为用户提供了访问数据仓库或数据集市的功能，其中分析与报告为用户使用数据仓库提供了一组工具，用于帮助用户对数据仓库或数据集市进行联机分析或数据挖掘等。

2、数据仓库构建方法

21 普通数据仓库构建方法。对于普通数据仓库的构建，企业在对整个系统的建设综合各种因素的基础上，将整个项目的实施分阶段、分步骤实施，可以在每一阶段建设的基础上分阶段纳入不同的业务系统，逐步建立起一个综合的、专题较为完善的、适合部门、子单位使用的完整的数据仓库系统，从而才能使投资尽快获得收益。

在数据仓库的构建过程中，利用模糊数学可实现数据仓库内数据的语义表示，丰富数据加工的手段，提高分析处理的能力。数据仓库的构建，一般采取先构建数据集市，最后将各个数据集市整合在一起形成数据仓库的渐进模式；通过概念层、逻辑层、物理层建模，确定相关主题域的数据集市并对其进行联机分析处理。构建数据仓库模型一般采用以下几种：

211 星型模型：星型模型是最常用的数据仓库设计结构的实现模式。使数据仓库形成了一个集成系统，为用户提供分析服务对象。该模型的核心是事实表，围绕事实表的是维度表。通过事实表将各种不同的维度表连接起来，各个维度表都连接到中央事实表。[page] 212 星系模型（也称雪花模型）：雪花模型对星型模型的维度表进一步标准化，对星型模型中的维度表进行了规范化处理。同时也是对星型模型的扩展，每一个维度都可以向外连接到多个详细类别表。在实际应用中，用户的需求多种多样，数据来源可能为多个事实表，故可采用多个事实表共存，之间通过公用的维表相关联的星系模型，也称为事实星座。

213 原子级数据模型和汇总级数据模型并存：坚持原子级数据模型和汇总级数据模型并存，而且要尽可能地细化原子级数据。

214 设立代理键：代理键是维表中一些没有业务含义的字段，只是一个由数据仓库加载程序时建立的数字。

22 空间数据仓库构建方法。随着GIS（地理信息系统）在各行业的广泛应用，最初面向事务处理为主的空间数据库信息系统已不能满足需要，信息系统开始从管理转向决策处理，空间数据仓库就是为满足这种新的需求而提出的空间信息集成系统。尤其是地理信息决策支持系统中，空间数据仓库系统显得尤为重要。

空间数据仓库具有普通数据仓库的普遍特征，但其本身有一些特殊性。并且空间数据仓也并不是空间数据库的简单集合。与空间数据库比，空间数据仓除支持数据库外，还支持数据文件、文本文件、应用程序等众多数据源；另外空间数据仓库中的数据有时间数据、空间数据、属性数据及异构数据等多种数据；其次空间数据仓库中还包括了数据处理规则、算法等；再次空间数据仓库的数据是对原始数据进行加工、处理、集成等转换，是对数据的增值和统一；空间数据库还引入了时间纵的概念，它是以时间为基准来管理数据，可以截取不同时间尺度上的信息，从瞬态到区段时间直到全体，空间数据仓库是依赖于时间维的数据结构，它可以根据不同的需要划分不同的时间粒度等级，以便进行各种复杂的趋势分析。当然，不言而喻，它还包含了空间维的方位数据。正因为空间数据仓库与普通数据仓库的不同，并且它以空间数据仓库完全不是相同的概念，一般空间数据仓库以如下体系结构分为四大功能模块，分别是源数据、数据变换工具、空间数据仓库、客户端分析工具。源数据它不仅指那些常见的空间数据库，还包括文件、网页、知识库、遗留系统等各种数据源。数据变换工具与具有普通数据仓库数据变换相同的提取转换功能，但它还包括了特有的空间变换等。空间数据仓库以立体、多维的方式来组织和显示数据。但最基本的空间维和时间维是其反映客观世界动态变化的基础，空间数据仓库技术最关键要点也就是时间维和空间维数据组织方式。目前空间数据仓库已成为国、内外GIS（地理信息系统）研究的热点并取得了较大进展。要把空间信息融合进企业现有的数据仓库中，在原有系统不作较大改动的前提下，一般采用三种模式构建企业空间数据仓库：（1）把空间信息作为多维模型中的空间维引入；（2）把空间信息作为研究主题引入；（3）在维和度量中都包含空间信息。因此，计算并存储所有空间度量是不现实的。一般使用空间索引树（如R-tree）在最细空间粒度上构建分组层次，作为空间维的分层，每个空间维需要建立一棵空间索引树。

3、结束语

总之，数据仓库构建是数据仓库技术的关键，数据仓库技术是一项基于数据管理和利用的综合性技术和解决方案，尤其是现在空间数据仓库在GIS 中的广泛应用，它成为数据库市场的新一轮增长点，同时也成为下一代信息系统的重要组成部分。

这篇文章较为完整、清晰的讲述了数仓建模分层理论，要点如下：

1、分层的意义：清晰结构体系、数据血缘跟踪、减少重复开发、复杂问题简单化及统一数据口径

2、ODS：用作缓冲，可以存一周左右，跟DWD大多重复，留存的目的还在于保持跟源端一致，方便追溯

3、DWD：针对ODS做数据的清洗和整合，在DWD层会根据维度模型，设计事实表和维度表，DWD层是一个非常规范的、高质量的、可信的数据明细层

4、DWS：基于DWD层形成某一主题的轻度汇总表或分析宽表，DWS形成大量维度退化的事实表以提高易用性，DWS层应覆盖80%的应用场景

5、TDM：标签层，通过统一的ID-Mapping 把各个业务板块，各个业务过程中同一对象的数据打通，形成对象的全域数据标签体系，方便深度分析、挖掘、应用，大家注意，这个ID不仅仅指客户或用户ID，也包括其它的主数据ID，其是全流程分析的基础

6、ADS：数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等前端系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用

7、DM：主要是提供数据产品和数据分析的数据，主要解决部门用户报表和分析需求而建立数据库，数据集市就代表数据仓库的主题域。DM 是面向单个主题的，所以它不会从全局考虑进行建设。

强烈推荐阅读！

正文开始

简单点儿，直接ODS+DM就可以了，将所有数据同步过来，然后直接开发些应用层的报表，这是最简单的了；当DM层的内容多了以后，想要重用，就会再拆分一个公共层出来，变成3层架构,这个过程有点类似代码重构，就是在实践中不断的进行抽象、总结。

数仓的建模或者分层，其实都是为了更好的去组织、管理、维护数据,所以当你站在更高的维度去看的话，所有的划分都是为了更好的管理。小到JVM 内存区域的划分，JVM 中堆空间的划分(年轻代、老年代、方法区等)，大到国家的省市区的划分，无一例外的都是为了更好的组织管理 。

所以数仓分层是数据仓库设计中十分重要的一个环节， 优秀的分层设计能够让整个数据体系更容易理解和使用 。

这一节，我们主要是从整体上出发进行分析和介绍，就和上一节数仓建模方法论一样，进度对比分析，更多细节的东西我们后面会单独拆分出来，用案例进行演示，例如维度建模，维度表的设计，事实表的设计、以及如何设计标签、如何管理标签等等。

每一个数据分层都有它的作用域，这样在使用表的时候能更方便的定位和理解。

由于最终给业务呈现的是一个能直接使用的业务表，但是表的数据来源有很多，如果有一张来源表出问题了，我们希望能够 快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低 。

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

过数据分层提供统一的数据出口，统一对外输出的数据口径，这往往就是我们说的数据应用层。

前面我们说到分层其实是为了更好更快更准的组织管理，但是这个是从宏观上来说的，接下来我们从微观上也来看一下分层。

越靠上的层次，对应用越友好,比如ADS层，基本是完全为应用设计,从数据聚合程度来讲，越上层的聚合程度越高，当然聚合程度越高可理解程度就越低。

数仓层内部的划分不是为了分层而分层， 分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题 ，当然我们常说的分层也是面向行业而言的，也是我们常用分层方法，但是你需要注意的是分层仅仅是手段而已。

ODS 全称是 OperationalDataStore， *** 作数据层存储的是面向业务系统的数据 ，也是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。

本层的数据，总体上大多是 按照源头业务系统的分类方式而分类的 ，前面我们说到为什么在数仓主要用维度建模的情况下，我们依然要学习范式建模呢，因为我们的数据源是范式建模的，所以学习范式建模可以帮助我们更好的理解业务系统，理解业务数据，所以你可以认为我们的ODS 层其实就是用的实范式建模。

这里的数据处理，并不涉及业务逻辑，仅仅是针对数据完整性以及重复值和空值的处理，其实就是做的是数据规约，数据清洗，但是为了考虑后续可能追溯数据源问题，因此 对这一层不建议做过多的数据清洗工作 ，原封不动接入源数据即可，至于数据的去噪，去重，异常值处理等过程可以放在后面的DW层

表名的设计 ODS_业务系统_表名_标记 ，这样的设计可以保持与业务表名一致，又可以有清晰的层次，还可以区分来源。标记一般指的是其他数仓特有的属性，例如表是天级的还是小时的，是全量的还是增量的。

ods 的设计可以保证所有的数据按照统一的规范进行存储。

DW是数据仓库的核心，从ODS层中获得的数据按照主题建立各种数据模型。DW又细分数据明细层DWD 和轻度汇总层DWS

这一层和维度建模会有比较深的联系，业务数据是按照 业务流程方便 *** 作的角度 来组织数据的，而统一数仓层是 按照业务易理解的角度或者是业务分析的角度 进行数据组织的，定义了一致的指标、维度，各业务板块、数据域都是按照统一的规范来建设，从而形成统一规范的 标准业务数据体系 ，它们通常都是基于Kimball的维度建模理论来构建的， 并通过一致性维度和数据总线来保证各个子主题的维度一致性 。

公共层的维度表中相同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致，因为这样可以降低我们在使用过程中犯错误的概率，例如使用了不正确的字段，或者因为数据类型的原因导致了一些奇怪的错误

将维度所描述业务相关性强的字段在一个物理维表实现。相关性强是指经常需要一起查询或进行报表展现、两个维度属性间是否存在天然的关系等。例如，商品基本属性和所属品牌。

公告明细数据层，可以说是我们数仓建设的核心了。

DWD层要做的就是将 数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理 。然后加工成面向数仓的基础明细表，这个时候可以加工一些面向分析的大宽表。

DWD层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。在DWD层会根据维度模型，设计事实表和维度表，也就是说DWD层是一个非常规范的、高质量的、可信的数据明细层。

DWS层为 公共汇总层 ，这一层会进行轻度汇总，粒度比明细数据稍粗， 基于DWD层上的基础数据，整合汇总成分析某一个主题域的服务数据 ，一般是也是面向分析宽表或者是面向某个注意的汇总表。DWS层应覆盖80%的应用场景，这样我们才能快速响应数据需求，否则的话，如果很多需求都要从ods开始做的话，那说明我们的数仓建设是不完善的。

例如按照业务划分，例如流量，订单，用户等，生成字段比较多的宽表，用于后续的业务查询，OLAP分析，数据分析等。

一般采用维度模型方法作为理论基础，更多的采用一些维度退化手法，将维度退化至事实表中，减少维度表与事实表的关联，提高明细数据表的易用性；同时在汇总数据层要加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工 。

维表层，所以其实维度层就是大量维表构成的，为了统一管理这些维度表，所以我们就建设维度层，维度表本身也有很多类型，例如稳定维度维表，渐变维度维表。

维度指的是观察事物的角度，提供某一业务过程事件涉及用什么过滤和分类的描述属性 ，"谁、什么时候、什么地点、为什么、如何"干了什么，维度表示维度建模的基础和灵魂。

所以可以看出，维度表包含了业务过程记录的业务过程度量的上下文和环境。维度表都包含单一的主键列， 维度表设计的核心是确定维度字段，维度字段是查询约束条件(where)、分组条件(group)、排序(order)，与报表标签的基本来源 。

维度表一般为 单一主键 ，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。维度建模的核心是 数据可以抽象为事实和维度 ，维度即观察事物的角度，事实某一粒度下的度量词， 维度一定是针对实体而言的 。

每个维度表都 包含单一的主键列 。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。例如customer（客户表）、goods(商品表)、d_time(时间表)这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。

维度表通常比较宽 ，包含多个属性、是扁平的规范表 ，实际应用中包含几十个或者上百个属性的维度并不少见，所以 维度表应该包括一些有意义的描述，方便下游使用 。

维度表的维度属性，应该尽可能的丰富，所以维度表中，经常出现一些反范式的设计，把其他维度属性并到主维度属性中， 达到易用少关联的效果。

维度表的设计包括维度选择，主维表的确定，梳理关联维度，定义维度属性的过程。

维度的选择一般从报表需求和从业务人员的交谈中发现，主要用于过滤、分组、排序，主维度表一般从业务库直接同步，比如用户表，但是数仓的本身也会有自己的维度，这是因为数仓是面向分析的，所以会有很多从分析的角度出发的维度。

关联维度主要是不同业务系统或者同一业务系统的表之间存在关联性(范式建模)，根据对业务表的梳理，确定哪些表和主维度表之间存在关联关系，并选择其中的某些表用于生成维度属性。

随着互联网的普及，获客成本越来越高，这也使得公司对用户运营提出了更高的要求，不仅需要精细化更需要个性化。解决这一问题的办法之一就是建立相对完备的标签系统，而数仓的标签层对于标签系统而言就像数据仓库对于数据系统一样，有着举足轻重的地位，这样的标签系统需要与业务进行紧密结合， 从业务中获取养分—用户标签，同时也要服务于业务—给用户提供更加精准和个性的服务 。

底层的标签系统就像一个索引，层层展示大千世界，而用户就从这大千世界中不断选择一些东西表明自己的身份和喜好，也不断反哺，使得这个大千世界更加丰富多彩。 其实到最后用户就是一些标签的集合。

对跨业务板块、跨数据域的特定对象进行数据整合，通过统一的ID-Mapping 把各个业务板块，各个业务过程中 同一对象的数据打通 ，形成对象的全域数据标签体系，方便深度分析、挖掘、应用。ID-Mapping 可以认为是通过对象的标识对不同数据体系下相同对象进行关联和识别。对象的标识可以标识一个对象，一般是对象的ID,比如手机号，身份z，登录账号

完成对象的ID 打通需要给对象设置一个超级ID,需要根据对象当前业务体系的ID和获取得到或者计算得到超级ID,进而完成所有业务标识的ID打通一般来说ID打通是建设标签体系的前提，如果没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面的标签刻画。

传统的计算方法要有 ID-ID之间的两两关系，例如邮箱和手机号可以打通，手机号和身份z号可以打通，那么邮箱就和身份z号可以打通，但是当数据量非常大，且业务板块非常多的时候，例如有上一个对象，每个对象有数十种ID,这个时候打通就需要非常漫长的计算

那么什么是标签呢，利用原始数据，通过一定的逻辑加工产出直接能被业务所直接使用的、可阅读的，有价值的数据。标签类目，是标签的分类组织方式，是标签信息的一种结构化描述，目的是管理、查找，一般采用多级类目，一般当一个对象的标签个数超过50个的时候，业务人员查找标签就会变得非常麻烦，这个时候我们往往会通过标签类目进行组织管理

标签按照产生和计算方式的不同可分为属性标签，统计标签，算法标签，关联标签。

对象本身的性质就是属性标签，例如用户画像的时候打到用户身上的标签。

对象在业务过程中产生的原子指标，通过不同的计算方法可以生成统计标签。

对象在多个业务过程中的特征规律通过一定的算法产出的标签。

对象在特定的业务过程会和其他对象关联，关联对象的标签也可以打在主对象上。

我们的标签一定是针对用户的，而不是一些虚假、高大上、无用的标签，一定要真实反映用户行为喜好的，所以我们不能只依赖人工智能算法的分析，来完成对一个用户标签的建立与定期维护，我们需要走出去和用户交互，引导用户使用，要抓住用户痛点，及时获取用户反馈，形成闭环。

如何引导使用呢？这个方式有很多我们就不再这里介绍了，后面我们会专门介绍这一层的建设细节。

数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用，或者使用一下其他的大数据工具进行存储和使用。

数仓层，DIM 层，TDM 层是相对稳定的，所以无法满足灵活多变业务需求 ，所以这和数仓层的规范和划分相矛盾，所以我们在此基础上建立了另外一个层，这就是ADS 层，解决了规划稳定和灵活多变之间的矛盾。其实到这里你也就慢慢的看明白了，分层和分类其实没多大差别，其实就是相似的放在一起，有点代码重构的意味啊。

数据应用层，按照业务的需要，然后从统一数仓层和DIM进行取数，并面向业务的特殊需求对数据进行加工,以满足业务和性能的需求。ADS 层因为面向的实众多的需求，所以这一层没有太多的规范，只需要按照命名规范来进行就可以了。

前面也说了，ADS 层因为面向的实众多的需求，所以这一层没有太多的规范，但是ADS 层的建设是强业务推动的，业务部门需要参与到ADS 的建设中来，至少我们得了解用户的痛点才能对症施药啊。

理清需求，了解业务方对数据内容、使用方式(怎么交互的，报表、接口、即席查询、在线查询、指标查询、搜索)、性能的要求。

盘点现有的数仓表是否可以支持，看以前有没有类似的需求，有没有可以复用的接口、报表什么的。

代码实现，选择合适的存储引擎和查询引擎，配置线上监控然后交付。

主要是提供数据产品和数据分析的数据，一般会存放在ES、Mysql、也可能直接存储在hive中或者druid供数据分析和数据挖掘使用。主要 解决部门用户报表和分析需求 而建立数据库，数据集市就代表数据仓库的主题域。

DM 是面向单个主题的，所以它不会从全局考虑进行建设，只专注于自己的数据、往往是某个业务线，例如流量主题、社交主题、电商主题等等。

创建数据库的时候，直接指定数据库的字符集，之后再该数据库中创建表的时候就不用再指定了，所有创建的表都是跟数据库字符集一样的。列如：create database \\'dbname\\' default character set utf8;

‍

数据仓库的定义？

首先，用于支持决策，面向分析型数据处理；其次，对多个异构的数据源有效集成，集成后按照主题进行重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。

数据仓库(Data Warehouse)是一个面向主题的(subject oriented)、集成的(integrated)、相对稳定的(non-volatile)、反应历史变化(time variant)的数据集合，用于支持管理决策(decision making support)。

数据仓库和数据库的区别？

从目标、用途、设计来说

数据库是面向事物处理的，数据是由日常的业务产生的，常更新；数据仓库是面向主题的，数据来源多样，经过一定的规则转换得到，用来分析。数据库一般用来存储当前事务性数据，如交易数据；数据仓库一般存储的历史数据。数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；数据仓库的设计一般不符合三范式，有利于查询

如何构建数据仓库？

数仓模型的选择是灵活的，不局限于某种模型方法。

数仓数据是灵活的，以实际需求场景为导向。

数仓设计要兼顾灵活性、可扩展性，要考虑技术可靠性和实现成本。

系统分析，确定主题。通过与业务部门的交流，了解建立数仓要解决的问题，确认各个主题下的查询分析要求选择满足数据仓库系统要求的软件平台。选择合适的软件平台，包括数据库、建模工具、分析工具等建立数据仓库的逻辑模型。确定建立数据仓库逻辑模型的基本方法，基于主题视图，把主题视图中的数据定义转到逻辑数据模型中逻辑数据模型转换为数据仓库数据模型数据仓库数据模型优化。随着需求和数据量的变化进行调整数据清洗转换和传输。业务系统中的数据加载到数据仓库之前，必须进行数据的清洗和转换，保证数据仓库中数据的一致性。开发数据仓库的分析应用。满足业务部门对数据进行分析的需求。数据仓库的管理。包括数据库管理和元数据管理。

什么是数据中台？

数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台吧数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。

这些服务和企业的业务有较强的关联性，是企业所独有且能复用的，它是企业业务和数据的积淀，其不仅能降低重复建设，减少烟囱式协作的成本，也是差异化竞争的优势所在。

数据中台通过整合公司开发工具、打通全域数据、让数据持续为业务赋能，实现数据平台化、数据服务化和数据价值化。数据中台更加侧重于“复用”与“业务”。

数据中台、数据仓库、大数据平台的关键区别是什么？

基础能力上的区别

数据平台：提供的是计算和存储能力

数据仓库：利用数据平台提供的计算和存储能力，在一套方法论指导下建设的一整套的数据表

数据中台：包含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的方式对外提供服务和价值。

业务能力上的区别

数据平台：为业务提供数据主要方式是提供数据集

数据仓库：相对具体的功能概念是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表

数据中台：企业级的逻辑概念，提现企业数据产生价值的能力，为业务提供服务的主要方式是数据API

总的来说，数据中台距离业务更近，数据复用能力更强，能为业务提供速度更快的服务。数据中台是在数据仓库和数据平台的基础上，将数据生产为一个个数据API服务，以更高效的方式提供给业务。数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

大数据的一些相关系统？

数仓设计中心：按照主题域、业务过程，分层的设计方式，以维度建模作为基本理论依据，按照维度、度量设计模型，确保模型、字段有统一的命名规范

数据资产中心：梳理数据资产，基于数据血缘，数据的访问热度，做成本的治理

数据质量中心：通过丰富的稽查监控系统，对数据进行事后校验，确保问题数据第一时间被发现，避免下游的无效计算，分析数据的影响范围。

指标系统：管理指标的业务口径、计算逻辑和数据来源，通过流程化的方式，建立从指标需求、指标开发、指标发布的全套协作流程。

数据地图：提供元数据的快速索引，数据字典、数据血缘、数据特征信息的查询，相当于元数据中心的门户。

如何建设数据中台？

数据中台在企业落地实践时，结合技术、产品、数据、服务、运营等方面，逐步开展相关工作。

理现状。了解业务现状、数据现状、IT现状、现有的组织架构定架构。确认业务架构、技术架构、应用架构、组织架构建资产。建立贴近数据层、统一数仓层、标签数据层、应用数据层用数据。对数据进行输出、应用。数据运营。持续运营、持续迭代。

中台建设需要有全员共识，由管理层从上往下推进，由技术和业务人员去执行和落地是一个漫长的过程，在实施数据中台时，最困难的地方就是需要有人推动。

数据湖的理解？

数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。

数仓最重要的是什么？

个人认为是数据集成。

企业的数据通常是存储在多个异构数据库中的，要进行分析，必须先要对数据进行一致性整合。

集成整合后才可以对数据进行分析、挖掘数据潜在的价值。

概念数据模型、逻辑数据模型、物理数据模型

概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。

概念数据模型CDM

概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，以数据类的方式描述企业级的数据需求。

概念数据模型的内容包括重要的实体与实体之间的关系。在概念数据模型中不包含实体的属性，也不包含定义实体的主键

概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系

逻辑数据模型LDM

逻辑数据模型反应的是系统分析设计人员对数据存储的观点，是对概念数据模型的进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项以及业务对象之间关系的基本蓝图。

逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。

逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑在物理上如何实现。

物理数据模型PDM

物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。

物理数据模型的内容包括确定所有的表和列，定义外键用于确认表之间的关系，基于用户的需求可能要进行反范式化等内容。

SCD的常用处理方式？

slowly changing dimensions缓慢变化维度

不记录历史变化信息添加列来记录历史变化新插入数据行，并添加对应标识字段来记录历史数据。拉链表。

元数据的理解？

狭义来讲就是用来描述数据的数据

广义来看，除了业务逻辑直接读写处理的业务数据，所有其他用来维护整个系统运转所需要的数据，都可以较为元数据。

定义：元数据metadata是关于数据的数据。在数仓系统中，元数据可以帮助数据仓库管理员和数据仓库开发人员方便的找到他们所关心的数据；元数据是描述数据仓库内部数据的结构和建立方法的数据。按照用途可分为：技术元数据、业务元数据。

技术元数据

存储关于数据仓库技术细节的数据，用于开发和管理数据仓库使用的数据

数据仓库结构的描述，包括数据模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容业务系统、数据仓库和数据集市的体系结构和模式由 *** 作环境到数据仓库环境的映射，包括元数据和他们的内容、数据提取、转换规则和数据刷新规则、权限等。

业务元数据

从业务角度描述了数据仓库中的数据，他提供了介于使用者和实际系统之间的语义层，使不懂计算机技术的业务人员也能读懂数仓中的数据。

企业概念模型：表示企业数据模型的高层信息。整个企业业务概念和相互关系。以这个企业模型为基础，不懂sql的人也能做到心中有数多维数据模型。告诉业务分析人员在数据集市中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。业务概念模型和物理数据之间的依赖。业务视图和实际数仓的表、字段、维的对应关系也应该在元数据知识库中有所体现。

元数据管理系统？

元数据管理往往容易被忽视，但是元数据管理是不可或缺的。一方面元数据为数据需求方提供了完整的数仓使用文档，帮助他们能自主快速的获取数据；另一方面数仓团队可以从日常的数据解释中解脱出来，无论是对后期的迭代更新还是维护，都有很大的好处。元数据管理可以让数据仓库的应用和维护更加的高效。

元数据管理功能

数据地图：以拓扑图的形式对数据系统的各类数据实体、数据处理过程元数据进行分层次的图形化展示，并通过不同层次的图形展现。元数据分析：血缘分析、影响分析、实体关联分析、实体差异分析、指标一致性分析。辅助应用优化：结合元数据分析功能，可以对数据系统的应用进行优化。辅助安全管理：采用合理的安全管理机制来保障系统的数据安全；对数据系统的数据访问和功能使用进行有效监控。基于元数据的开发管理：通过元数据管理系统规范日常开发的工作流程

元数据管理标准

对于相对简单的环境，按照通用的元数据管理标准建立一个集中式的元数据知识库

对于比较复杂的环境，分别建立各部分的元数据管理系统，形成分布式元数据知识库，然后通过建立标准的元数据交换格式，实现元数据的集成管理。

数仓如何确定主题域？

主题

主题是在较高层次上将数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对企业中某一宏观分析领域所涉及的分析对象。

面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。

主题是根据分析的要求来确定的。

主题域

从数据角度看（集合论）

主题语通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定由最终用户和数仓设计人员共同完成。

从需要建设的数仓主题看（边界论）

主题域是对某个主题进行分析后确定的主题的边界。

数仓建设过程中，需要对主题进行分析，确定主题所涉及到的表、字段、维度等界限。

确定主题内容

数仓主题定义好以后，数仓中的逻辑模型也就基本成形了，需要在主题的逻辑关系中列出属性和系统相关行为。此阶段需要定义好数据仓库的存储结构，向主题模型中添加所需要的信息和能充分代表主题的属性组。

如何控制数据质量？

校验机制，每天进行数据量的比对 select count()，早发现，早修复

数据内容的比对，抽样比对

复盘、每月做一次全量

如何做数据治理？

数据治理不仅需要完善的保障机制，还需要理解具体的治理内容，比如数据应该怎么进行规范，元数据该怎么来管理，每个过程需要那些系统或者工具来配合？

数据治理领域包括但不限于以下内容：数据标准、元数据、数据模型、数据分布、数据存储、数据交换、数据声明周期管理、数据质量、数据安全以及数据共享服务。

模型设计的思路？业务驱动？数据驱动？

构建数据仓库有两种方式：自上而下、自下而上

Bill Inmon推崇自上而下的方式，一个企业建立唯一的数据中心，数据是经过整合、清洗、去掉脏数据、标准的、能够提供统一的视图。要从整个企业的环境入手，建立数据仓库，要做很全面的设计。偏数据驱动

Ralph Kimball推崇自下而上的方式，认为数据仓库应该按照实际的应用需求，架子啊需要的数据，不需要的数据不要加载到数据仓库中。这种方式建设周期短，用户能很快看到结果。偏业务驱动

数据质量管理

数据质量管理是对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的数据质量问题，进行识别、度量、监控、预警等，通过改善了提高组织的管理水平使数据质量进一步提高。

数据质量管理是一个集方法论、技术、业务和管理为一体的解决方案。放过有效的数据质量控制手段，进行数据的管理和控制，消除数据质量问题，从而提高企业数据变现的能力。

会遇到的数据质量问题：数据真实性、数据准确性、数据一致性、数据完整性、数据唯一性、数据关联性、数据及时性

什么是数据模型？

数据模型就是数据组织和存储的方法，通过抽象的实体以及实体间联系的形式来表达现实世界中事务的相互关系的一种映射，他强调从业务、数据存取和使用角度合理的存储数据。

为什么需要数据仓库建模？

数仓建模需要按照一定的数据模型，对整个企业的数据进行采集，整理，提供跨部门、完全一致的报表数据。

合适的数据模型，对于大数据处理来讲，可以获得得更好的性能、成本、效率和质量。良好的模型可以帮助我们快速查询数据，减少不必要的数据冗余，提高用户的使用效率。

数据建模进行全方面的业务梳理，改进业务流程，消灭信息孤岛，更好的推进数仓系统的建设。

OLAP和OLTP的模型方法的选择？

OLTP系统是 *** 作事物型系统，主要数据 *** 作是随机读写，主要采用满足3NF的实体关系模型存储数据，在事物处理中解决数据的冗余和一致性问题。

OLAP系统是分析型系统，主要数据 *** 作是批量读写，不需要关注事务处理的一致性，主要关注数据的整合，以及复杂大数据量的查询和处理的性能。

3范式

每个属性值唯一，不具有多义性

每个非主属性必须完全依赖于整个主键，而非主键的一部分

每个非主属性不能依赖于其他关系中的属性

数据仓库建模方法？

有四种模型：ER模型、维度模型、Data Vault模型、Anchor模型。用的较多的是维度模型和ER模型。

ER模型

ER模型用实体关系模型描述企业业务，在范式理论上满足3NF。数仓中的3NF是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。

采用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据按照主题进行相似性整合，并进行一致性处理。

ER模型特点：

需要全方位了解企业业务数据

实施周期较长

对建模人员要求教高

维度建模

维度建模按照事实表和维度表来构建数仓。

维度建模从分析决策的需求出发构建模型，为分析需求服务。重点关注用户如何快速的完成数据分析，可以直观的反应业务模型中的业务问题，需要大量的数据预处理、数据冗余，有较好的大规模复杂查询的响应性能。

事实表

发生在现实世界中的 *** 作性事件，其产生的可度量数值，存储在事实表中。从最细粒度级别来看，事实表的一行对应一个度量事件。事实表表示对分析主题的度量。

事实表中包含了与各个维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数不断增加，表数据量迅速增长。

维度表

维度表示分析数据时所用的环境。

每个维度表都包含单独的主键列。维度表行的描述环境应该与事实表行完全对应。维度表通常比较宽，是扁平型的非规范表，包含大量的低粒度的文本属性。

注意：

事实表的设计是以能够正确记录历史信息为准则

维度表的设计是以能够以合适的角度来聚合主题内容为准则

维度建模的三种模式

星形模型：以事实表为中心，所有的维度直接连接在事实表上。由一个事实表和一组维度表组成。

雪花模型：是对星形模型的扩展。雪花模型的维度表可以拥有更细的维度，比星形更规范一点。维护成本较高，且查询是要关联多层维表，性能较低

星座模型：基于多张事实表，多张事实表共享维度信息

维度建模步骤：

选择业务过程

选择粒度

选定事实表

选择维度

事实表的类型？

事实表有：事务事实表、周期快照事实表、累积快照事实表、非事实事实表

事务事实表

事务事实表记录的是事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务记录一条记录。

周期快照事实表

以具有规律性的、可预见的时间间隔来记录事实。它统计的是间隔周期内的度量统计，每个时间段一条记录，是在事务事实表之上建立的聚集表。

累积快照事实表

累积快照表记录的不确定的周期的数据。代表的是完全覆盖一个事务或产品的生命周期的时间跨度，通常具有多个日期字段，用来记录整个生命周期中的关键时间点。

非事实型事实表

在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。

第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。

事实表中通常要保留度量事实和多个维度外键，度量事实是事实表的关键所在。

非事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或说明某些活动的范围。

第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。

数仓架构为什么要分层

分层可以清晰数据结构，使用时更好的定位和理解方便追踪数据的血缘关系规范数据分层，可以开发一些通用的中间层数据，能够减少极大的重复计算把复杂问题简单化屏蔽原始数据的异常。不必改一次业务就重新接入数据

数据分层思想？

理论上数据分为： *** 作数据层、数据仓库层、数据服务层。可根据需要添加新的层次，满足不同的业务需求。

*** 作数据层ODS

Operate Data Store *** 作数据存储。数据源中的数据经过ETL后装入ODS层。

ODS层数据的来源一般有：业务数据库、日志、抓取等。

数据仓库层DW

根据ODS层中的数据按照主题建立各种数据模型。

DW通常有：DWD、DWB、DWS

DWD: data warehouse detail细节数据层，是业务层和数据仓库的隔离层。

DWB: data warehouse base基础数据层，存储的是客观数据，一般用作于中间层。

DWS: data warehouse service服务数据层，整合汇总分析某个主题域的服务数据。一般是大宽表。

数据服务层/应用层ADS

该层主要提供数据产品和数据分析使用的数据，一般会放在ES、Mysql系统中供线上系统使用

数仓架构进化

经典数仓架构：使用传统工具来建设数仓

离线大数据架构：开始使用大数据工具来替代经典数仓中的传统工具

Lambda架构：在离线大数据架构的基础上，使用流处理技术直接完成实时性较高的指标计算

Kappa：实时处理变成了主要的部分，出现了以实时处理为核心的kappa架构

离线大数据架构

数据源通过离线的方式导入离线数仓中。下游应用根据业务需求选择获取数据的方式

Lambda架构

在离线数仓的基础上增加了实时计算的链路，并对数据源进行流式改造，实时计算去订阅消息队列，并推送到下游的数据服务中去。

Lambda架构问题：同样的需求需要开发两套一样的代码；资源占用增多

Kappa架构

kappa架构可以认为是lambda架构的简化版，移除了lambda架构中的批处理部分。

在kappa架构中，需求修改或者历史数据重新处理都通过上游重放完成

kappa架构最大的问题是流式重新处理历史数据的吞吐能力会低于批处理，但可以通过增加计算资源来弥补

总结

真实场景中，是lambda架构和kappa架构的混合。大部分实时指标通过kappa架构计算，少量关键指标用lambda架构批量计算

随着数据多样性的发展，数据库这种提前规定schema的模式显得力不从心。这时出现了数据湖技术，把原始数据全部缓存到某个大数据存储上，后续分析时根据需求去解析原始数据。简单来说，数据仓库模式是schema on write，数据湖模式是schema on read

OLAP简介

OLAP（On-line Analytical Processing），联机分析处理，其主要的功能在于方便大规模数据分析及统计计算，对决策提供参考和支持。

特点：数据量大、高速响应、灵活交互、多维分析

OLAP分类

存储类型分类

ROLAP（RelationalOLAP）

MOLAP（MultimensionalOLAP）

HOLAP（HybridOLAP）

处理类型分类

MPP架构

搜索引擎架构

预处理架构

开源OLAP解决方案

Persto、SparkSQL、Impala等MPP架构和ROLAP的引擎Druid和Kylin等预处理架构和MOLAP的引擎ES这种搜索引擎架构ClickHouse及IndexR这种列式数据库

OLAP引擎

Presto

Facebook开发的分布式大数据SQL查询引擎，专门进行快速数据分析

特点

可以将多个数据源的数据进行合并，可以跨越整个组织进行分析直接从HDFS读取数据，在使用前不需要大量的ETL *** 作

查询原理

完全基于内存的并行计算

流水线

本地化计算

动态编译执行计划

小心使用内存和数据结构

类BlinkDB的近似查询

GC控制

Druid

Druid是一个用于实时查询和分析的分布式实时处理系统，主要用于广告分析，互联网广告监控、度量和网络监控

特点

快速的交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内可被查询到。高可用性——Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会造成数据丢失；可扩展——Druid已实现每天能够处理数十亿事件和TB级数据。为分析而设计——Druid是为OLAP工作流的探索性分析而构建，它支持各种过滤、聚合和查询

应用场景

需要实时查询分析具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；需要一个高可用、高容错、高性能数据库时。需要交互式聚合和快速探究大量数据时

Kylin

Kylin是提供与Hadoop之上的SQL查询接口及多维分析能力以支持超大规模数据

浅谈数据挖掘与数据仓库

1数据挖掘

11数据挖掘与传统数据分析的区别

数据挖掘与传统的数据分析，如查询、报表、联机应用分析的本质区别是数据挖掘是在没有明确假设的前提下去挖掘信息、发现知识。数据挖掘所得到的信息应具有先前未知、有效和实用三个特征。即数据挖掘是要发现那些不能靠直觉发现的信息或知识，甚至是违背直觉的信息或知识，挖掘出的信息越出乎意料就可能越有价值。而传统的数据分析趋势为从大型数据库抓取所需数据并使用专属计算机分析软件。因此数据挖掘与传统分析方法有很大的不同。

12数据挖掘的应用价值

（1）分类：首先从数据中选出已经分好类的训练集，在该训练集上运用数据挖掘分类的技术，建立分类模型，对于没有分类的数据进行分类。（2）估计：与分类类似，不同之处在于，分类描述的是离散型变量的输出，而估值处理连续值的输出；分类是确定数目的，估计是不确定的。（3）聚类：是对记录分组。聚类和分类的区别是聚集不依赖于预先定义好的类，不需要训练集。中国移动采用先进的数据挖掘工具马克威分析系统，对用户wap上网的行为进行聚类分析，通过客户分群，进行精确营销。（4）关联规则和序列模式的发现：关联是某种事物发生时其他事物会发生的这样一种联系。例如：每天购买啤酒的人也有可能购买香烟，比重有多大，可以通过关联的支持度和可信度来描述。与关联不同，序列是一种纵向的联系。例如：今天银行调整利率，明天股市的变化。（5）预测：通过分类或估值得出模型，该模型用于对未知变量的预言。（6）偏差的检测：对分析对象的少数的、极端的特例的描述，揭示内在的原因。除此之外，在客户分析，运筹和企业资源的优化，异常检测，企业分析模型的管理的方面都有广泛使用价值。

2数据仓库

21数据仓库的特征

（1）面向主题（Subject Oriented）的数据集合。数据仓库围绕一些主题如顾客、供应商、产品和销售来组织。数据仓库关注决策者的数据建模与分析，而不是组织机构的日常 *** 作和事务处理。（2）集成（Integrated）的数据集合。数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。（3）时变（Time Variant）的数据集合。数据存储从历史的角度提供信息。数据仓库中的数据通常包含历史信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。（4）非易失（Nonvolatile）的数据集合。数据仓库的数据主要供企业决策分析之用，所涉及的数据 *** 作主要是数据查询，修改和删除 *** 作很少，通常只需要定期的加载、刷新。数据仓库里的数据通常只需要两种 *** 作：初始化载入和数据访问，因此其数据相对稳定，极少或根本不更新。[page] 22数据仓库的类型

数据仓库的类型根据数据仓库所管理的数据类型和它们所解决的企业问题范围，一般可将数据仓库分为下列3种类型：企业数据仓库（EDW）、 *** 作型数据库（ODS）和数据集市（Data Marts）。①企业数据仓库为通用数据仓库，它既含有大量详细的数据，也含有大量累赘的或聚集的数据，这些数据具有不易改变性和面向历史性。此种数据仓库被用来进行涵盖多种企业领域上的战略或战术上的决策。② *** 作型数据库既可以被用来针对工作数据做决策支持，又可用做将数据加载到数据仓库时的过渡区域。与EDW相比，ODS是面向主题和面向综合的，易变的，仅含有目前的、详细的数据，不含有累计的、历史性的数据。③数据集市是为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据。几组数据集市可以组成一个EDW。

23数据仓库与传统数据库的比较

二者的联系既有联系又有区别。数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。二者的区别可以从以下几个方面进行比较：

（1）出发点不同：数据库是面向事务的设计；数据仓库是面向主题设计的。（2）存储的数据不同：数据库一般存储在线交易数据；数据仓库存储的一般是历史数据。（3）设计规则不同：数据库设计是尽量避免冗余，一般采用符合范式的规则来设计；数据仓库在设计是有意引入冗余，采用反范式的方式来设计。（4）提供的功能不同：数据库是为捕获数据而设计，数据仓库是为分析数据而设计。（5）基本元素不同：数据库的基本元素是事实表，数据仓库的基本元素是维度表。（6）容量不同：数据库在基本容量上要比数据仓库小的多。（7）服务对象不同：数据库是为了高效的事务处理而设计的，服务对象为企业业务处理方面的工作人员；数据仓库是为了分析数据进行决策而设计的，服务对象为企业高层决策人员。

3数据仓库与数据挖掘的关系

当然为了数据挖掘你也不必非得建立一个数据仓库，数据仓库不是必需的。建立一个巨大的数据仓库，把各个不同源的数据统一在一起，解决所有的数据冲突问题，然后把所有的数据导到一个数据仓库内，是一项巨大的工程，可能要用几年的时间花上百万的钱才能完成。只是为了数据挖掘，你可以把一个或几个事务数据库导到一个只读的数据库中，就把它当作数据集市，然后在他上面进行数据挖掘。

通常关系型数据库是为了记录、修改和查询数据本身（增删改查），对数据本身所含有的业务含义并不关心。简单说是为了记录。

而数据仓库则是重点关注数据与数据之间的业务含义，如不同统计口径与分析方式下数值差的意义。简单说是为了分析。

那么为了保证分析结果的准确和有效，必须分解和细化分析口径，精确定位影响因素，维表和度量值就是定义分析角度和影响因素的一种方式。

数据量没达到一定程度，且业务需求不需要，例如：新闻主题表，几百G正常，就可能不必要拆分，但是像新浪这样的公司就必须要拆分。换句话而言就是要看数据量、业务发展趋势、数据的存取需求、数据访问的并发度等综合而考虑；大数据量、高并发等场景，准确说应该一般是：垂直拆分+水平拆分，肯定是提供性能、系统负载能力、支持业务增量等。

一、概述

国峰系统的BI数据分析，基于微软OLAP数据仓库模型。分为前台和后台。在后台进行有关的维度、事实建模(系统自动生成数据库表)，通过报表、图表、KPI的设计器，通过SQL语法进行业务分析逻辑的实现，在前台进行BI展示分析。

上述基于事实表+维度表的体系结构，可以从一个点发展到多个点串联，形成“星型架构”。

在BI前台通过动态SQL解析等方式，实现按维度、维度上某个属性等条件，对事实表进行查询切片，得到事实值(或根据事实值计算得到的KPI值)。

整个体系是开放式的，为拓展做好了准备。

二、维度

维度和事实表的区别，在于维度中用来存放一些“数量有限”的数据记录。如人员、客户、供应商、产品等。事实表则是用来存放一些“数量无限”的行为记录。例如销售记录、联络记录、合同记录等等。对于上述数量有限的数据记录，我们应该将其规划为一个维度。

1 进入维度管理

在如下图入口位置，进入“数据库维度管理”。

在这里统一管理国峰系统的所有数据库。左侧是分类栏，请按用途对数据库进行归类，否则数据库多了会很乱。

2 新增数据库

在左侧选中“客户”分类，右侧将出现该分类下的数据库。

在工具条上点击“新增”，

NameKey：是数据库表用到的维度唯一标识。必须是英文，不含空格、特殊符号。如：shigongxiangmu

类型选择：可选择Simple简单维度，表示没有分类层次结构。或者Comon普通维度，表示有分类层次结构。

新建后，系统会在数据库中自动新建1个维度表。也就是说，一个维度对应数据库后台1个维度表。

例如，NameKey为“shigongxiangmu”，则后台数据库会自动建立维度表：

OLAPshigongxiangmuDim

3 修改字段

下面，我们按《业务需求书》，为上述数据库设置字段。

切换到“维度字段”。在工具条上的“选择维度”下拉条中选择你刚建立的“施工项目”维度。

出现该维度已启用的字段。新建的维度，默认只自动启用了2个字段。其余字段需要手工开启：

在工具条上去掉“只显示已启用字段”的勾，

实际上在新建维度时，系统已经自动在数据库维度表中默认自动创建了所有的列。一般情况下足够了(不够的情况见下文)。

“启用”列打勾的字段，将在该数据库前台界面中出现。没打勾的列不会被用到。按《业务需求书》配置时，根据实际需要来启用有关的列。

31 字段的构成

首先，字段的英文名称，是系统自动起的，不能手工修改。

字段按编号分组：

英文名数据类型用途

Count1数字数字类型的字段。

Price1数字数字类型的字段。

Amount1数字数字类型的字段。

Support150以内文本。简单备注类型的字段。

UserTimeFrom1日期日期类型的字段。

UserTimeEnd1日期日期类型的字段。

Chose1Key维度或选项键值关联维度字段，或简单下拉选项字段。

Chose1KeyValue维度或选项文本用于数据库存放所选维度或选项的文本值。

Script1无限长度文本。长文本备注类型的字段。

新建的维度表，自动建立了从编号1，到编号20，共20组字段。因此一般情况下是够用的。

除上述编号分组字段外，系统还默认建立了如下特殊字段：

英文名数据类型用途

OLAPKeybigint数据库自增列。唯一标识这条记录。后台不可见。

FatherKey维度键值对普通维度有效。简单维度没有。记录该维度节点的父节点。普通维度表实际上是一个自我父子表，维度层级和节点都在这张表中。

FatherKeyValue维度文本用于数据库存放所选维度的文本值。

MainDemoName50以内文本维度节点的名称。必须项目。

SourceKey50以内文本维度节点的逻辑编号。

Script无限长度文本维度节点的描述。

对于维度，这些特殊字段是必须启用的!

上述字段的英文名是固定的，数据类型是固定的(文本列不能存放数字，数字列也不能存放文本，以此类推)。

如果上述20组字段不够用了，可以在工具条上“新建列”部分输入新列号“21”，点“插入”。

系统将自动插入第21组列。以此类推。可以容纳的列没有限制。

以上就是关于新浪微博「点赞功能」数据库如何设计的全部的内容，包括:新浪微博「点赞功能」数据库如何设计的、浅析数据仓库的构建方法、数仓建模分层理论等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！