【术语】数据开发

数据开发技术方向主要有数据仓库、在线分析处理（OLAP）以及数据挖掘三部分组成。

数据仓库

架构

数据仓库

• 数据仓库 Data Warehouse，DW
  关于数据仓库概念的标准定义业内认可度比较高的，是由数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出：
  中文定义：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
  英文定义：A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions.
  数据仓库是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。它出于分析性报告和决策支持目的而创建。首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程。
  数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。多维分析和数据挖掘是最常听到的例子,数据仓库能供给它们所需要的、一致的数据。

数据集市

• 数据集市 Data Mart，DM
  数据集市以某个应用为出发点而建设的局部数据仓库，通常面向一个业务小组或团队，只限于单个主题的区域，例如顾客、部门、地点等，数据集市只关心自己需要的数据。不会全盘考虑企业整体的数据架构和应用，每个应用都有自己的数据集市。所以数据集市可以基于仓库建设也可以独立建设。
• 操作集市 Oper Mart
  操作集市是为了企业战术性的分析提供支持，它的数据来源是操作数据存储（ODS）。它是ODS在分析功能上的扩展，使用户可以对操作型数据进行多维分析。
  操作集市是ODS的子集，数据来源于ODS，用于战略分析和报表；操作集市中的数据和ODS中的数据同步更新；操作集市以多维技术进行建模，即星型结构；操作集市是一个临时的结构，当不在需要时会清掉所有数据，即不保存历史数据。
  操作集市和数据集市很相似，但是它不能用来取代用于战略性分析的数据集市。由于操作集市的数据来源于ODS，所以它的数据比数据集市的数据要新。但是出于容量的考虑，操作集市中不保存历史数据，是一个临时的结构。

ODS

• 操作数据存储 Operational Data Storage，ODS
  操作数据存储一种数据库类型，通常用作一个面向数据仓库的中间区域。与包含静态数据的数据仓库不同，ODS的内容在业务运营的过程中是不断更新的。它还是一种数据结构，既有数据仓库的一些特性，也有作业系统的一些特性。通常，ODS是一种可选的结构，有些公司需要用到，有些则不需要。
  Kimball认为ODS在两种情况下是需要的：第一种情况是提供操作型报表，这些报表需要提供面向主题的、集成的数据，所以操作型的源系统无法提供；这些报表和数据仓库中的报表也不相同，因为它们可以是一些定制好的，写死在程序中的报表。第二种情况是需要提供实时的信息时，由于数据仓库的更新频率一般都是24小时，而用户会有更急切的需求来了解数据源的信息，这时，建立操作数据存储是很有必要的。

ETL

• ETL Extract-Transform-Load
  ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。

抽象

主题

• 主题 Subject
  主题是对数据综合、归类、并按一定的业务逻辑抽象出来的分析对象。主题是与传统数据库的面向应用相对应的，是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类并进行分析利用的抽象。每一个主题对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
  面向主题的数据组织方式， 就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。所谓较高层次是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应， 数据仓库中的数据是面向主题进行组织的。主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。
• 主题域 Subject Area
  定义一：主题域是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。
  定义二：主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。确定主题边界实际上需要进一步理解业务关系，因此在确定整个分析主题后，还需要对这些主题进行初步的细化才便于获取每一个主题应该具有的边界。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。
  经过对以上内容深入分析，发现定义一与定义二并不矛盾，只是所站的视角不同，“数据主题集合”的观点从数据着眼，前提是已经经过分析、梳理列出所有可能的数据主题，此处数据主题是细粒度的，是从微观到宏观；“边界论”的观点中，某个主题是分析的主题，是宏观概念，而非数据主题。

主体

• 主体
  主体是指事物的主要部分。一般情况主题更抽象，最好能让人一看就清楚的了解所说的内容是关于哪些方面的。而主体偏实际，是能展现实际性以及内容丰富，通俗易懂，案（事）例结合。

模型

• 模型 Model
  模型是对现实事物的反映和抽象，能帮助我们更好地了解客观世界。
• 数据模型 Data Model
  数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。
  它定义了数据之间关系和结构，使得我们可以有规律地获取想要的数据，数据模型表现的抽象的实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。数据建模是数据组织和存储方法，是强调从数据业务、数据存取和使用角度合理组织数据的一种方法论。
• 业务数据模型 Business Data Model
  业务数据模型简称业务模型 ，主要解决业务层面的分解和程序化。它是最高层次的数据模型，主要完成：划分整个单位的业务，一般按照业务部分的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系；深入了解各个业务部门的具体业务流程并将其程序化；提出修改和改进业务部门工作流程的方法并程序化；数据建模的范围界定，这个数据仓库项目的目标和阶段划分。
• 概念数据模型 Conceptual Data Model
  概念数据模型简称概念模型 ，主要是针对业务模型进行抽象处理，生成领域（主题域）概念模型。
  概念数据模型的内容包括重要的实体及实体之间的关系，以及主要主题和重要业务之间的关系。在概念数据模型中不包括实体的属性 ，也不用定义实体的主键 。主题域建模的流程大致可以划分成如下几个部分：在前一个阶段业务建模的过程中，已经对业务系统进行数据的梳理。根据各业务的特点列出数据主题详细的清单，并对每个数据主题都作出详细的解释，然后经过归纳、分类，整理成各个数据主题域，列出每个数据主题域包含哪些部分，并对每个数据主题域作出详细解释，最后划分成主题域概念模型。
  在概念数据模型中最常用的是E-R模型 、扩充的E-R模型、面向对象模型及谓词模型。
• 逻辑数据模型 Logical Data Model，LDM
  逻辑数据模型简称逻辑模型，它是以概念模型为基础，对概念模型的进一步细化、分解。逻辑模型通过实体和实体之间的关系描述业务的需求和系统实现的技术领域，是业务需求人员和技术人员沟通的桥梁和平台。此模型既要面向用户，又要面向系统 ，主要用于数据库管理系统（DBMS）的实现。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图,反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。 逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。
  在逻辑数据类型中最常用的是层次模型(Hierarchical Data Model)、网状模型(Network Data Model)、ER模型(Entity-Relationship Data Model)。
• 物理数据模型 Physical Data Model，PDM
  物理数据模型简称物理模型，主要解决逻辑模型的物理化以及性能等一些具体的技术问题。它是面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有对应的物理数据模型。DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集等特殊结构。
  物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。 物理数据模型的内容包括确定所有的表和列，定义外键用于确定表之间的关系，基于用户的需求可能进行范式化等内容。
  逻辑模型转变为物理模型包括以下几个步骤：实体名（Entity）变为表名（table）；属性名（attribute）转换为列名（column），确定列的属性（Property）；物理模型必须对列的属性进行明确的定义，包括：列名、数据类型；物理模型确定后，还可以进一步确定数据存放位置和存储空间的分配。
• 实体 Entity
  实体是逻辑数据模型中的一种对象，在数据库中的定义是“客观存在并可相互区别的事物”，对应物理数据库中的表（Table）。
• 关系 Relationship
  关系是实体之间的联系，反映了现实世界中事物的关联关系和特定的业务规则。
• 属性 Attribute
  属性是逻辑数据模型中的一种对象，在数据库中的定义是“实体所具有的某一特性”，对应物理数据库中的字段（Field）。
• 实体关系 Entity Relationship，ER
  实体关系是描述数据模型的一种标准方法。
• 事实 Fact
  在《数据仓库工具箱》一书中对事实的定义是：事实涉及来自业务过程的度量，基本都以数量值表示。一个事实表行与粒度存在一对一关系。简单来说事实就是业务流程中的一条业务，是一个度量集合，它按照粒度的划分包含着度量，连接着维度。在维度建模中，对业务过程的度量称为事实，事实是数据中的数字型度量。事实根据灵活性与用途将数字度量分为三类：可以与事实表关联的任意维度汇总的是可加事实；可以操控某些维度但不能操控全部维度的是半可加事实；本身是操作后的度量（比例，占比等）是不可加事实。在设计时应该解决不可加事实的出现，尽可能使用半可加事实来描述不可加事实。
  举例：以一个客户把一个商品放入购物车中这么一条数据来举例，在这一条数据中，一定包含了以下信息：商品种类、商品名称、商品单价、商品数量。以上述四条信息举例，商品种类与商品名称不是事实，而商品单价与商品数量是事实。
• 维度 Dimension
  维度是用来反映业务的一类属性，这类属性的集合构成一个维度。维度用来描述事实，他从不同角度描述事实，也就是说维度是描述事实的角度。在维度建模中，将度量称为“事实”，将环境描述为“维度”，维度是用于分析事实所需要的多样环境。
  举例：以一个客户把一个商品放入购物车中这么一条数据来举例，我们可以以什么角度来看这条数据。首先，时间角度，这条订单数据是在哪天发生的，这就是时间维度；然后，地域角度，这条订单数据的用户是哪个省份的，这就是地域维度；其次，品牌维度，这条订单的商品是什么品牌，这就是品牌维度；最后，商品种类维度，这条订单商品是什么种类，是电器还是厨具，这就是商品种类维度。
• 维的层次 Hierarchy of Dimension
  维度层次是描述维度内部结构的属性集合，它刻画了维度内部不同成员间的相对关系。
• 维的级别 Level of Dimension
  维的级别是维度层次结构的一个元素。级别描述了数据的层次结构，从数据的最高（汇总程度最大）级别直到最低（最详细）级别（如大分类-中分类-小分类-细分类）。级别仅存在于维度内。级别基于维度表中的列或维度中的成员。
• 维的成员 Member of Dimension
  维的成员构成维度的基本单位，若维是多级别的，则不同的级别的取值构成一个维成员，是维的一个取值。部分维级别同样可以构成维度成员，例如“某年某季度”、“某季某月”等都可以是时间维的成员。

在一个数据维(Dimension)里至少包含一个层次(Hierarchy)，而一个层次又至少要包含一个级别(Level)。在每一个级别里，可以拥有多个成员(Member)。在事实表关键字与数据维成员交叉的地方，每一个成员至少有一个数据值出现在该位置上。一张图解释这一切。

• 业务过程 Business Process
  业务过程是组织完成的操作型活动。业务过程时间建立或获取性能度量，并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择非常重要的，因为过程定义了特定的设计目标以及对粒度、维度、事实的定义。
• 度量 Measure
  度量是业务流程节点上的一个数值。度量是绝对的定量值。对于在事实表或者一个多维立方体里面存放的数值型的、连续的字段，就是度量。一个度量字段肯定是统一单位，例如元、户数。如果一个度量字段，其中的度量值可能是欧元又有可能是美元，那这个度量没法汇总。
• 指标 Metric
  指标是表示某种相对程度的值。区别于度量概念，那是一种绝对值，尺子量出来的结果，汇总出来的数量等。指标是基于两个或更多度量计算得出相对的定量值。例如ARPU，用收入比上用户数，例如收入增长率，用本月收入比上上月收入
• 指示器 Indicator
  指示器是基于度量或指标，并依据某个基准值得到的定性结果。如果说度量和指标是定量话，指示器就是一种定性的。我们身边充当指示器的有：红绿灯，提醒行人车辆是否等待或通行；监控室里的警报灯，提醒哪儿出现异常；汽车仪表盘，提醒驾驶员油是否足够，速度如何。它们起到的作用是传递一种宏观的信息，促使人的下一步行动。红灯停绿灯行；看到警报亮起要赶紧派人查看。
• 粒度 Grain
  粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。 细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大，用于确定某一事实表中的行表示什么。粒度是与具体指标相关的，具体表现在描述此指标的某些可分层次维的维值上。
  粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。
• 度量值 Measures：在多维数据集中，度量值是一组值，这些值基于多维数据集的事实数据表中的一列，而且通常为数字。此外，度量值是所分析的多维数据集的中心值。即，度量值是最终用户浏览多维数据集时重点查看的数字数据（如销售、毛利、成本）。

建模

模型查询

即席查询

• 即席查询 Ad Hoc Queries
  即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高。数据模型对所有的查询都是相同的，这也是维度建模的一个优点。

冰山查询

• 冰山查询 Iceberg Query
  冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈值的聚集值。
  以销售数据为例，你想产生这样的一个顾客－商品对的列表，这些顾客购买商品的数量达到3件或更多。这可以用下面的冰山查询表示：
  Select cust_id,SUM(amt) From purchase Group by cust_id Having SUM(amt)>=3
  这种在给出大量输入数据元组的情况下，使用having字句中的阈值来进行过滤的查询方法就叫做冰山查询。输出结果可以看作“冰山顶”，而“冰山”是输入数据。这种冰山查询在数据仓库的数据概况分析阶段、数据质量检查阶段和数据挖掘的购物篮分析中都经常使用。

交叉探察

• 交叉探察 Drill Across
  在基于总线架构（Bus Architecture）的维度建模中，大部分的维度表是由事实表共有的。比如“营销事务事实表”和“库存快照事实表”就会有相同的维度表，“日期维度”、“产品维度”和“商场维度”。这时，如果有个需求是想按共有维度来对比查看销售和库存的事实，这时就需要发出两个SQL，分别查出按维度统计出的销售数据和库存数据。然后再基于共有的维度进行外连接，将数据合并。这种发出多路SQL再进行合并的操作就是交叉探查。当这种交叉探查的需求很常用时，有一种建模方法可以避免交叉探查，就是合并事实表（Consolidated Fact Table）。合并事实表在性能和易用性上都比交叉探查要好，但是被组合的事实表必须处于相同的粒度和维度层次上。

实体建模

• 实体建模 Entity Modeling
  实体建模并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
  由于实体建模法，能够很轻松的实现业务建模的划分。因此，在业务建模阶段和领域建模阶段，实体建模方法有着广泛的应用。一般在没有现成的行业建模的情况下，可以采用实体建模的方法，和客户一起清理整个业务的模型，进行领域概念的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。但是，实体建模也有着自己先天的缺陷，由于实体说明法只是一种抽象客观事件的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。

范式建模

• 范式建模 Third Normal Form，3NF
  范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
  范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
  在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件：
  ①1NF：每个属性值唯一，不具有多义性。要求属性具有原子性，即列不可再分解；
  ②2NF：每个非主属性必须完全依赖于整个主键，而非主键的一部分。要求记录有惟一标识，即不存在部分依赖；
  ③3NF：每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。要求字段没有冗余，即不存在传递依赖；
  优点：常用于OLTP数据库建模，从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模； 应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。
  缺点：由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足响应的需求；需要全面梳理企业所有的业务和数据流，周期长，人员要求高。

维度建模

• 维度建模 Dimensional Modeling
  维度建模是kimball最先提出的，是专门用于分析型数据库、数据仓库、数据集市建模的方法。维度建模法简单描述就是按照事实表、维度表来构建数仓、集市。维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的相应性能。 基于事实表和维表就可以构建出多种多维模型，包括星形模型、雪花模型和星座模型。
  用于度量的事实表，事实表一般会有两个或者多个外健与维度表的主键进行关联。事实表的主键一般是组合健，表达多对多的关系。
  用于描述环境的维度表，单一主键。维度表的属性是所有查询约束和报表标示的来源。维度提供数据的入口点，提供所有DW/BI分析的最终标识和分组。
  所以维度建模表示每个业务过程包含的事实表，事实表里面存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生的实际存在的文本环境。
  优点：维度建模非常直观，仅仅围绕着业务模型，可以直观的反应出业务问题。不需要经过特别的抽象处理，即可以完成维度建模；不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo，而且相对来说便于理解、提高查询性能、对称并易扩展。
  缺点：由于在构建星型模型之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理的过程中，往往会导致大量的数据冗余；不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
• 总线架构 Bus Architecture
  总线架构是Kimball的多维体系结构中的三个关键性概念之一，另两个是一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。
  在多维体系结构的数据仓库架构中，主导思想是分步建立数据仓库，由数据集市组合成企业的数据仓库。但是，在建立第一个数据集市前，架构师首先要做的就是设计出在整个企业内具有统一解释的标准化的维度和事实，即一致性维度和一致性事实。而开发团队必须严格的按照这个体系结构来进行数据集市的迭代开发。
  一致性维度就好比企业范围内的一组总线，不同数据集市的事实的就好比插在这组总线上的元件。这也是称之为总线架构的原因。
  实际设计过程中，我们通常把总线架构列表成矩阵的形式，其中列为一致性维度，行为不同的业务处理过程，即事实，在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵（Bus Matrix）。
  总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础，也建立了一套可以逐步建立数据仓库的方法论。由于总线架构是多维体系结构的核心，所以我们有时就把多维体系结构直接称为总线架构。
• 一致性维度 Comformed Dimension
  在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。
  一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。一致性维度强调的是维度一致性、共享性，认为事情发生的环境是可以部分抽象出来的、且是有共性的，数据集市涉及到的相同维度应该是完全一致的。一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。因为有了一致性维度，所以一些跨集市分析是可以通过星座模型形式实现的。
  这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。
• 一致性事实 Comformed Fact
  在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。
  一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。一致性事实强调的是事实一致性，支持跨集市查询分析没有二义性。为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。
  这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。

事实表

• 事实表 Fact Table
  在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。事实表中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度，表里的一条数据代表一个业务事件。

以粒度的不同来化分，事实表可以分为三类，分别是事务粒度事实表，周期快照粒度事实表和累积快照粒度事实表。

• 事务粒度事实表 Transaction Grain Fact Table
  事务粒度事实表的一行代表对应空间或时间上某点的度量事件。事务出现以后，就会在事实中出现一条记录。事务粒度事实表也称为原子粒度事实表(Atom Fact Table)。一旦事务被提交，数据进入到事实表中，那么事实表中的数据就不能再修改了，其更新方式为增量更新。典型的例子是销售单分列项事实表。
• 周期快照粒度事实表 Periodic Snapshot Grain Fact Table
  周期快照粒度事实表用来记录有规律的，可预见时间间隔的业务累计数据。通常的时间间隔可以是每天、每周或者每月。粒度是周期性的，而不是个体事物。该类表通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许存在的。该类表的外键的密度是均匀的，因为即使周期内没有活动发生，也会在事实表中为每个事实插入包含0或空值的行。典型的例子是库存日快照事实表。
• 累积快照粒度事实表 Accumulating Snapshot Grain Fact Table
  累积快照事实表的行汇总了发生在开始和结束之间可预测步骤内的度量事件，该类表一般用来涵盖一个事务的生命周期内的不确定的时间跨度，用于跟踪业务事实的变化。它负责跟踪一个业务的整个生命周期，每当状态发生更改，就会修改表记录、或者新增一条记录。典型的例子是具有多个日期字段的发货事实表。
  通常来说，事务和快照是建模中的两个非常重要的特点，将两者相结合可以使模型建立的更完整。

以用途的不同来化分，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。

• 原子事实表 Atom Fact Table
  原子事实表是保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。
• 聚集事实表 Aggregated Fact Table
  聚集事实表是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，该类表是对原子粒度事实表数据进行简单的数字化上卷操作，目的是为了提升查询性能，如用月份维度表代替日期维度表。事实数据是相应事实的汇总，即求和或求平均值等。在做数据迁移时，当相关的维度数据和事实数据发生变化时，聚集事实表需要做相应的刷新。物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式。
• 合并事实表 Consolidated/Merged Fact Table
  合并事实表是指将位于不同事实表中处于相同粒度的事实进行组合建模而成的一种事实表。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合。这种建模方法通常被用来横跨多个业务主题域来建立数据集市，在Kimball的总线架构中，由合并事实表为主组成的合并数据集市称为二级数据集市。合并事实表的粒度可以是原子粒度也可以是聚集粒度。在做数据迁移时，当相关的原子事实表的数据有改变时，合并事实表的数据需要重新刷新。合并事实表和交叉探察是两个互补的操作。聚集事实表和合并事实表的主要差别是合并事实表一般是从多个事实表合并而来。但是它们的差别不是绝对的，一个事实表既是聚集事实表又是合并事实表是很有可能的。因为一般合并事实表需要按相同的维度合并，所以很可能在做合并的同时需要进行聚集，即粒度变粗。合并事实表可以给数据仓库带来很大的性能提升，提供的跨主题的事实数据也给用户带来了很大的方便。但是，对于合并事实表中涉及到的维度，需要在数据准备区保证它们是一致性维度。

其他类型事实表

• 非事实型事实表 Factless Fact Table
  在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。
  第一类非事实型事实表是用来跟踪事件的事实表：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。
  第二类非事实型事实表是用来说明某些活动范围的事实表：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。
• 蜈蚣事实表 Centipede Fact Table
  蜈蚣事实表是指那些一张事实表中有太多维度的事实表。连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规范化过了头。蜈蚣事实表虽然使查询效率有所提高，但是伴之而来的是存储空间的大量增长。在维度建模的数据仓库中，维度表的字段个数可以尽可能的增加，但是事实表的字段要尽量减少，因为相比而言，事实表的记录数要远远大于维度表的记录数。一般来说，事实表相关的维度在15个以下为正常，如果维度个数超过25个，就出现了维度过多的蜈蚣事实表。这时，需要做的事情是自己核查，将相关的维度进行合并，减少维度的个数。
• 旋转事实表 Pivoted Fact Table
  旋转事实表是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化为一条记录。旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。如果在SQL或者查询工具中进行这种转换会非常麻烦，效率也很差。和合并事实表类似，有时当基础表中没有记录时，旋转事实表也要存储一些零值在里面。
• 切片事实表 Sliced Fact Table
  切片事实表中的字段结构和相应的基础表完全相同，差别在于存储的记录的范围。切片事实表中保存记录的是相应基础表中记录的子集，记录数通常与某个维度记录数相同。这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的数据，即各个地区都保存自己地区的数据，总部和所有地区的表结构都相同，然后总部将所有地区的数据合并在一起。切片事实表的结构与相对应的基础表相同，数据来源于相对应的基础表。切片事实表由于缩小了表中数据的记录数，所以查询的效率得到了很大的提高。
• 稀疏事实表 Sparse Facts
  当在一个事实表中建立多个事实，有可能多个事实不同时发生，如果同时生成的几率很小，我们称之为稀疏事实表。

维度表

• 维度表 Dimension Table
  维度表一般纪录是对事实的描述信息，每一张维度表对应现实世界中的一个对象或者概念。维度表存储的是那些会被其它表所引用的、不会常变的静态信息。每个维度表都包含单一的主键列，主键可以作为与之关联的任何事实表的外键。
• 代理关键字 Surrogate Key
  代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。代理关键字用于维度表和事实表的连接。与之相对的自然关键字的称呼有natural keys，samat keys等。在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字。数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值就可以了解一些业务信息。当然，退化维度作为事实表的复合主键之一时例外。
  使用代理关键字，优点：使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲；使用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整型的，可以减小事实表中记录的长度；使用代理关键字可以建立一些不存在的维度记录，例如“不在促销之列”，“日期待定”，“日期不可用”等维度记录；使用代理关键字可以用来处理缓慢变化维，Kimball的缓慢变化维处理策略的核心就是使用代理关键字。当然也有缺点：代理关键字的使用使数据加载变得非常复杂。
• 缓慢变化维度 Slowly Changing Dimension，SCD
  缓慢变化维，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维。在维度建模理论中，有8种处理方式，包括基础的5种以及混合的3种。 再加上大数据时代的2种极限型，共10种，具体如下：方法0: 保留原始值；方法1: 直接覆盖；方法2: 增加新行；方法3: 增加新属性列；方法4: 增加微型维度；方式5: 微型维度与方式1支架表；方式6: 将方式1属性增加到方式2维度；方式7:双重外键并且方式1与方式2结合；方式8: 快照维度；方式9：历史拉链维度。
• 退化维度 Degenerate Dimension
  退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。
• 微型维度–Minidimension
  微型维度的提出主要是为了解决快变超大维度（rapidly changing monster dimension）。以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。
• 多值维度 Multivalue Dimension
  多值维度有两种情况：
  第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾客ID放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。
  第二种情况是事实表在某个维度表中有多条对应记录。举例来说，对于一个健康护理单分列项事实表来说，它的粒度是一个健康护理单，但是该护理单却有可能有多次诊断，即该事实表与诊断维度的是一对多的关系。这个与事实表粒度不匹配的诊断维度也称之为多值维度。处理多值维度最好的办法是降低事实表的粒度。多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如果多值维度不能避免的话，应该建立桥接表来进行处理。
• 角色模仿维度 Role Playing Dimensions
  角色模仿维度是为了处理一个维度在一个事实表中同时出现多次而使用的一种技术处理手段。在建立了角色模仿维度以后，在底层只有一个物理表存在，但是针对这个物理表会建立多个角色提供给数据访问工具，而且对数据访问工具来说这多个角色是不同的。例如对与累计快照事实表中会出现多个日期字段联接到日期维度。这时就可以针对日期维度建立多个角色模仿维度。角色模仿维度的建立方法通常是使用视图来完成。
• 杂项维度 Junk Dimension
  杂项维度是由操作系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。在操作系统中，我们定义好各种维度后，通常还会剩下一些在小范围内取离散值的。

宽表

• 宽表 Wide table
  所谓宽表模型，是基于维度模型的扩展，采用退化维度的方式，将不同维度的度量放入数据表的不同的列中；它更易于理解，具有更高的查询效率；易于模型扩展；宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。

星型模式

• 星型模式 Star Schema
  星型模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。
  星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：维表只和事实表关联，维表之间没有关联；每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；以事实表为核心，维表围绕核心呈星型分布；

雪花模式

• 雪花模式 Snowflake Schema
  雪花模式(Snowflake Schema)是对星形模式的扩展，其中某些维表被规范化，进一步分解到附加表（维表）中。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，比较靠近第三范式，但是无法完全遵守，且由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。

星座模式

• 事实星座模式 Fact Constellation 或星系模式 galaxy schema
  星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。在业务发展后期，绝大部分维度建模都采用的是星座模式。

数据分析

BI

• 商业智能 Business Intelligence，BI
  BI 是 Business Intelligence（商业智能）的缩写，是指企业利用已有数据进行数据分析从而指导商业决策的过程。BI 有广义和狭义之分，广义上的 BI 是指只要涉及利用数据及其分析结果进行商业决策的行为都属于 BI 的范畴；而狭义上的 BI 则主要多维分析，在实际工作中，狭义 BI 也更流行一些。

OLTP

• 联机事务处理 Online Transaction Processing，OLTP
  OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。
  OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
  OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

OLAP

• 大规模并行计算框架 Massively Parallel Processing，MPP
  MPP是massively parallel processing的简称，即大规模并行计算框架。相比MR等架构，MPP查询速度快，通常在秒计甚至毫秒级以内就可以返回查询结果，这也是为何很多强调低延迟的系统，比如OLAP系统大多采用MPP架构的原因。
• 联机分析处理 OLAP Online Analytical Processing，OLAP
  OLAP是一种多维分析技术，其主要的功能在于方便大规模数据分析及统计计算，对决策提供参考和支持。广义的 OLAP 泛指数据查询分析，像报表、即席查询、多维分析都属于 OLAP 的范畴。一般来说OLAP根据建模方式可分为MOLAP、ROLAP和HOLAP 3种类型。
• MOLAP
  MOLAP表示基于多维数据组织的OLAP实现（Multidimensional OLAP）。以多维数据组织方式为核心，也就是说，MOLAP使用多维数组存储数据。多维数据在存储中将形成“数据立方体（Cube）”的结构，此结构在得到高度优化后，可以最大程度地提高查询性能。随着源数据的更改，MOLAP 存储中的对象必须定期处理以合并这些更改。两次处理之间的时间将构成滞后时间，在此期间，OLAP对象中的数据可能无法与当前源数据相匹配。维护人员可以对 MOLAP 存储中的对象进行不中断的增量更新。MOLAP的优势在于由于经过了数据多维预处理，分析中数据运算效率高，主要的缺陷在于数据更新有一定延滞。因此，MOLAP适合业务需求比较固定，数据量较大的场景。
  MOLAP代表有Kylin、Druid等。
• ROLAP
  ROLAP表示基于关系数据库的OLAP实现（Relational OLAP）。以关系数据库为核心，以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表：一类是事实表，用来存储数据和维关键字；另一类是维表，即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。ROLAP的最大好处是可以实时地从源数据中获得最新数据更新，以保持数据实时性，缺陷在于运算效率比较低，用户等待响应时间比较长。
  ROLAP代表有Hive、Presto、SparkSQL、Impala、ClickHouse、Greenplum等。
• HOLAP
  HOLAP表示基于混合数据组织的OLAP实现（Hybrid OLAP），用户可以根据自己的业务需求，选择哪些模型采用ROLAP，哪些采用MOLAP。一般来说，会将非常用或需要灵活定义的分析使用ROLAP方式，而查询频繁而稳定但又耗时的那些模型采用MOLAP实现。

多维分析

• 多维分析 Multidimensional Analysis
  多维分析是指在分析型系统中，用户可以通过拖拽维度（Dimension）来汇总度量（Measure）以方便使用者可以从不同角度观察数据。如果从报表的角度来看，多维分析类似自助报表，业务人员基于一个事先准备的结果集进行动态报表查询，可以进行切片、钻取、旋转（行列变换）等操作。
  现在很多时候 BI、OLAP 和多维分析被狭义地叫成一样的东西，其实是特指实现了多维分析的产品，比如我们说 BI 产品、OLAP 产品都是在指多维分析。
• 立方体 Cube
  CUBE叫数据立方体，可以理解成是一个数据集，在多维分析中使用者需要基于一个结果集进行拖拽分析，这个结果集就是 CUBE 了，多维分析针对 CUBE 进行查询、上钻、下钻、切片、旋转、钻取等操作。
• 钻取 Drill Down
  在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据；也可以钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。
• 上卷 Roll Up
  钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。
• 切片 Slice
  选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。
• 切块Dice
  选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。
• 旋转 Pivot
  即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。

从上面的描述来看，BI、OLAP、多维分析从狭义上来讲基本可以画等号，但从广义上来看 BI 的范畴显然更大一些，其次是 OLAP，然后是多维分析，而 CUBE 属于多维分析的范畴，所以 CUBE 的范围最小，用图形表述一下四者之间的关系可以这样：

数据挖掘

机器学习

• 机器学习 Machine Learning
  从广义上来说，机器学习是一种能够赋予机器学习的能力以此让它完成直接编程无法完成的功能的方法。但从实践的意义上来说， 机器学习是一种通过利用数据，训练出模型，然后使用模型预测的一种方法。通俗来讲，机器学习就是：三个基本的要素，任务T、经验E和性能P。机器学习=通过经验E的改进后，机器在任务T上的性能p所度量的性能有所改进=T–>(从E中学习)–>P（提高）。
  机器学习的应用范围：机器学习与模式识别、统计学习、数据挖掘、计算机视觉、语音识别、自然语言处理等领域有着非常深的联系。

  - 模式识别 = 机器学习
  两者的主要差别在于前者是从工业界发展起来的概念，后者则主要源自计算机学科。它们中的活动能够被视为同一个领域的两个方面。
  - 数据挖掘 = 机器学习 + 数据库
  数据挖掘是一种思考方式，告诉我们应该尝试从数据中挖掘出知识，但不是每一个数据都能挖掘出金子的。一个系统绝对不会由于上了一个数据挖掘模块就变得无所不能。大部分数据挖掘中的算法是机器学习的算法在数据库中的优化。
  - 统计学习近似等于机器学习
  统计学习是个与机器学习高度重叠的学科，由于机器学习中的大多数方法来自统计学，甚至能够觉得，统计学的发展促进机器学习的发展。
  - 计算机视觉 = 图像处理 + 机器学习
  图像处理技术用于将图像处理为适合进入机器学习模型中的输入，机器学习则负责 从图像中识别出相关的模式。计算机视觉相关的应用非常的多，比如百度识图、手写字符识别、车牌识别等等应用。
  - 语音识别 = 语音处理 + 机器学习
  语音识别就是音频处理技术与机器学习的结合。语音识别技术一般不会单独使用，通常会结合自然语言处理的相关技术，有关的应用有苹果的语音助手siri等。
  - 自然语言处理 = 文本处理 + 机器学习
  自然语言处理技术主要是让机器理解人类的语言的一门领域。
  

• 标签 Lable
  标签是我们要预测的事物，即简单线性回归中的 y 变量。标签可以是小麦未来的价格、图片中显示的动物品种、音频剪辑的含义或任何事物。
• 特征 Feature
  特征是输入变量，即简单线性回归中的 x 变量。简单的机器学习项目可能会使用单个特征，而比较复杂的机器学习项目可能会使用数百万个特征
• 样本 Example
  样本是指数据的特定实例：x。（我们采用粗体 x 表示它是一个矢量。）我们将样本分为以下两类：有标签样本、无标签样本。
  有标签样本同时包含特征和标签。即：labeled examples: {features, label}: (x, y)
  我们使用有标签样本来训练模型。
  无标签样本包含特征，但不包含标签。即：unlabeled examples: {features, ?}: (x, ?)
• 模型 Model
  模型定义了特征与标签之间的关系。模型在未进行训练前，其可能的参数是多个甚至无穷的，故可能的模型也是多个甚至无穷的，这些模型构成的集合就是假设空间。
  模型生命周期的两个阶段：①训练是指创建或学习模型。也就是说，向模型展示有标签样本，让模型逐渐学习特征与标签之间的关系；②推断是指将训练后的模型应用于无标签样本。也就是说，使用经过训练的模型做出有用的预测 (y’)。例如，在推断期间，您可以针对新的无标签样本预测。
• 策略 Strategy
  策略即从假设空间中挑选出参数最优的模型的准则。模型的分类或预测结果与实际情况的误差（损失函数）越小，模型就越好。那么策略就是误差最小。
• 算法 Algorithm
  算法即从假设空间中挑选模型的方法（等同于求解最佳的模型参数）。机器学习的参数求解通常都会转化为最优化问题，故学习算法通常是最优化算法，例如最速梯度下降法、牛顿法以及拟牛顿法等。
• 监督学习 Supervised Learning
  监督学习的任务是学习一个模型，使模型能够对任意给定的输入，对其相应的输出做出一个好的预测。即：利用训练数据集学习一个模型，再用模型对测试样本集进行预测。本质是在结果可验证（如房产的最终售出价格和明天的天气）的情况下，建立输入参数（房产面积）和输出参数（售出价格）之间的关系（或者映射，或者函数），这种关系被称为假设（Hypothesis）。
  有监督算法常见的有：线性回归算法、BP神经网络算法、决策树、支持向量机、KNN等。
  监督学习主要解决两类问题回归和分类。
• 回归 Regression
  回归模型可预测连续值。例如，回归模型做出的预测可回答如下问题：加利福尼亚州一栋房产的价值是多少？用户点击此广告的概率是多少？
• 分类 Classification
  分类模型可预测离散值。例如，分类模型做出的预测可回答如下问题：某个指定电子邮件是垃圾邮件还是非垃圾邮件？这是一张狗、猫还是仓鼠图片？
• 无监督学习 Unsupervised Learning
  无监督学习为直接对数据进行建模。没有给定事先标记过的训练范例，所用的数据没有属性或标签这一概念。事先不知道输入数据对应的输出结果是什么。自动对输入的资料进行分类或分群，以寻找数据的模型和规律。如聚类算法：针对数据集，自动找出数据中的结构，从而把数据分成不同的簇。
  无监督算法常见的有：密度估计(densityestimation)、异常检测（anomaly detection)、层次聚类、EM算法、K-Means算法(K均值算法)、DBSCAN算法 等。
  有监督的核心是分类，无监督的核心是聚类。

深度学习

• 深度学习 Deep Learning
  深度学习是一种实现机器学习的技术，也包含了监督学习算法和无监督学习算法。常见的卷积神经网络就是一种监督学习方法，在图像分类（如人脸识别）上应用非常广泛。生成对抗网络（GAN）是一种无监督学习方法，经常被用来做图像生成（如深度卷积对抗生成网络(DCGAN)可用于生成卡通图像）。