数据技术体系
1、 建模策略
● 数据库三范式（1NF）
简介：指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
缺点：数据表中的字段具有原子性，不可再分，即在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位。
表结构：
职工号，姓名，电话号码
不符合案例：职工号，姓名，联系号码（）
● 数据库三范式（2NF）
简介：在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER（Entity Relationship Diagram，实体-联系图)设计时添加，不是建库时随意添加）。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
优点：第二范式（2NF）为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一标识属性列被称为主关键字或主键、主码，非主属性完全依赖于主属性，即消除非主属性对主属性的部分函数依赖关系。
缺点：1、存在大量数据冗余；2、存在插入异常；3、存在修改异常；4、存在删除异常。
表结构：
sc为选课关系，sid为学号， cid为课程号，grade为成绩，credit为学分
● 数据库三范式（3NF）
简介：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
优点：节约存储(尤其是利用数据库进行数仓建设的时候)，规范化带来的好处是通过减少数据冗余，提高更新数据的效率，同时保证数据完整性，结构清晰，易于理解。
缺点：构建比较复杂，查询复杂(需要很多的关联)，不适合在大数据环境下构建(1 查询复杂 2 存储很便宜)。
表结构：
sid为代表学号，sname为姓名，did为所在系，dname为系名称，location为系地址
● 范式建模-实体关系模型（ER）
简介：实体关系模型 （Entity-Relationship Model）是指提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。E-R方法是“实体-联系方法”（Entity-Relationship Approach）的简称。它是描述现实世界概念结构模型的有效方法。
优点：接近于人的思维，容易理解；与计算机无关，用户容易接受
缺点：只能说明实体间语义的联系，不能进一步说明详细的数据结构
E(汽车） —R(包含） --E(轮子） 1：N (外键） N:N (R表）
● 维度建模-星型模型
简介：星型模式是多维的数据关系，它事实表（Fact Table）和维表（Dimension Table）组成。每个维表中都会有一个维作为主键，所有这些维的主键结合成事实表的主键。事实表的非主键属性称为事实，它们一般都是数值或其他可以进行计算的数据
优点：
1、星型模型是非规范化的 ，这意味着应用于事务性关系数据库的常规规范化规则在星型模型设计和实现过程中被放宽。 星型模型非规范化的好处是：
2、更简单的查询 - 星型模型连接逻辑通常比从高度规范化的事务模型中检索数据所需的连接逻辑更简单。
3、简化的业务报告逻辑 - 与高度规范化的模型相比，星型模型简化了常见的业务报告逻辑，例如周期和报告。
4、查询性能提升 - 与高度规范化的模型相比，星型模型可以为只读报告应用程序提供性能增强。
5、快速聚合 - 针对星型模型的简单查询可以提高聚合操作的性能。
6、所有OLAP系统都使用提供多维数据集 - 星型模型来有效地构建专有的OLAP多维数据集 ; 事实上，大多数主要的OLAP系统都提供ROLAP操作模型，可以直接使用星型模型作为源，而无需构建专有的多维数据集结构。
缺点：
1、星型模型的主要缺点是数据完整性不能很好地实施，因为它处于高度非规范化状态。 一次性插入和更新可能导致数据异常，规范化模型旨在避免。 一般而言，星型模型通过批处理或近实时数据流以高度受控的方式加载，以补偿由归一化提供的缺乏保护。
2、星型模型在分析需求方面也不像标准化数据模型那样灵活。规范化模型允许执行任何类型的分析查询，只要它们遵循模型中定义的业务逻辑即可。 星型模型往往更专门针对特定的数据视图而构建，因此实际上不允许更复杂的分析。
3、星型模型不支持业务实体之间的多对多关系 - 至少不是很自然。 通常，这些关系在星型模型中被简化以符合简单的维度模型。
结构：
● 维度建模-雪花模型
简介： 雪花模型是多维数据库中的表的逻辑排列方式，使得实体关系图类似于雪花形状。雪花模型由连接到多个维度的集中式事实表组成。“Snowflaking”是一种在星型模型中规范化维度表的方法。 当它沿着所有维度表完全标准化时，结果结构类似于雪花，其中事实表位于中间。雪花背后的原理是通过删除低基数属性和形成单独的表来对维度表进行规范化。雪花模型类似于星型模型。 但是，在雪花模型中，维度被规范化为多个相关表，而星型模型的维度被非规范化，每个维度由单个表表示。当雪花模型的尺寸复杂，具有多级关系，并且子表具有多个父表（“道路中的叉”）时，会出现复杂的雪花形状。
优点：雪花模式是和星型模式类似的逻辑模型。实际上，星型模式是雪花模式的一个特例（维度没有多个层级）。某些条件下，雪花模式更具优势：
一些OLAP多维数据库建模工具专为雪花模型进行了优化。
规范化的维度属性节省存储空间。
缺点：雪花模型的主要缺点是维度属性规范化增加了查询的连接操作和复杂度。相对于平面化的单表维度，多表连接的查询性能会有所下降。但雪花模型的查询性能问题近年来随着数据浏览工具的不断优化而得到缓解。 和具有更高规范化级别的事务型模式相比，雪花模式并不确保数据完整性。向雪花模式的表中装载数据时，一定要有严格的控制和管理，避免数据的异常插入或更新。
结构：
● 维度建模-星座模型
简介：星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型。
优点：优点是多张事实表共用模型中的维度表，适用于比星型模型和雪花模型更复杂的场合， 这事实星座模式提供了更多的灵活性。
缺点：星座模型可明确分配给多个事实表维度表，星座模型的结构更加复杂和精密，它很难维持，聚合的数量在星座中很高。
结构：
● 数仓分层策略
简介：⼤数据下的数据仓库对数据进⾏了分层管理，分为ODS（原始数据层）、DWD（数据明细层），DWS（数据服务层），ADS（应用数据层）。
优点：
1、清晰的数据结构，每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解；
2、将复杂的问题简单化，将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的问题，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的地方开始修复；
3、减少重复开发，规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算；
4、屏蔽原始数据的异常，屏蔽业务的影响，不必改一次业务就需要重新接入数据；
5、数据血缘的追踪，最终给业务呈现的是一个能直接使用业务表，但是它的来源很多，如果有一张来源表出问题了，借助血缘最终能够快速准确地定位到问题，并清楚它的危害范围。
缺点：
1、 操作⿇烦、耗时；
2、 机器资源成本前期投⼊⼤；
3、 前期数仓不容易出成果，推⼴难度⼤；
4、 数仓的数据冗余度很⼤，是以空间换时间换取了时效上的优势，这是优点也是缺点。
2、 大数据架构
● 传统离线大数据架构
简介：由大数据组件与业务应用组成(离线的)
结构图：
优点：1.Hive支持SQL
2.早期处理大量的离线批量数据分析
缺点：不能处理实时数据分析场景(流式业务)
● Lambda架构（离线处理+实时链路）
简介：采用实时链路处理实时数据
结构图：
优点：能处理实时数据
缺点：重复开发多、实时链路烟囱式开发、数据不能被复用
● Lambda架构（离线数仓+实时数仓）
简介：采用实时数仓替换了实时链路
结构图：
优点：解决了实时链路数据不能被复用的问题
缺点：1.需要开发两套一样的代码
2.集群资源使用增多
3.在数据量不断增加的情况下，批量计算T+1可能会计算不完(在有限的时间内) 4.占用服务器存储空间大，相同的数据存储了两份
5.离线结果和实时结果不一致(实时与离线的计算时间点不同，离线是准确的)
● Kappa架构
简介：纯实时数仓的架构(尝试的，目前几乎无大公司用)
结构图：
优点：解决了实时和离线可能产生的数据结果不一样的问题
缺点：1.Kafka不支持SQL、其数据是追加的不支持数据的更新(update/upsert)(致命)
（例：当需要计算一个时间段内数据的结果时，由于网络延时存在部分数据超时达到，这时不能更新计算结果）
2.Kafka的数据存储有一定期限，不符合数仓存储数据的需求，无法支撑海量数据 的存储
3.Kafaka无法支持高效的OLAP
4.无法复用数据血缘管理体系
架构的选择：
- 刚上大数据或业务没实时场景：传统离线大数据架构
- 离线业务多、实时业务少：离线数仓+实时链路的Lambda架构
- 离线和实时业务都较多：离线数仓+实时数仓的Lambda架构
- 实时业务多、离线相对少：Kappa纯实时数仓架构
其中Lambda使用得多；
互联网公司-实时业务多：混合架构（绝大多数实时业务采用Kappa架构、关键核心业务(指标计算)使用离线全量计算方式(Lambda)）
● 批流一体(数据湖)
简介：
- 架构角度：可以处理批也可以处理流
- 计算框架处理角度：可以处理批数据也可以处理流数据（Flink）
- SQL支持角度：流数据和批数据都支持SQL
- 存储层面：做到实时和离线的存储统一
批数据：历史的大容量数据 流数据：实时的大数据
优点： - 支持海量的存储
- 支持SQL和实时更新问题
- 统一存储
- 减少运维的架构和组件
缺点：
● 湖仓一体
简介：数据湖构建的实时数仓
结构图：
优点：1.存储统一
2.解决了Kafka存储量小的问题
3.任意分层都可以进行OLAP数据分析
4.复用同一套相同的血缘关系
5.支持实时数据的更新
缺点：1. 数据湖技术较新、技术体系仍不完善（IceBerg）、存在较多的BUG
2.数据湖存储海量数据的速度不如Kafka快
顺丰的架构：
基于Lambda架构，采用Hudi吧Kafka的实时数据同步到Hive
腾讯架构：
滴滴架构：
自研的DDMQ，支持SQL
3、 关系型及其他数据库
● Mysql
简介：
MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。
- MySQL 是开源的，目前隶属于 Oracle 旗下产品。
- MySQL 支持大型的数据库。可以处理拥有上千万条记录的大型数据库。
- MySQL 使用标准的 SQL 数据语言形式。
- MySQL 可以运行于多个系统上，并且支持多种语言。这些编程语言包括 C、C++、Python、Java、Perl、PHP、Eiffel、Ruby 和 Tcl 等。
- MySQL 对PHP有很好的支持，PHP 是目前最流行的 Web 开发语言。
- MySQL 支持大型数据库，支持 5000 万条记录的数据仓库，32 位系统表文件最大可支持 4GB，64 位系统支持最大的表文件为8TB。
- MySQL 是可以定制的，采用了 GPL 协议，你可以修改源码来开发自己的 MySQL 系统。
优点： - 性能卓越,服务稳定,很少出现异常宕机;
- 开放源代码无版本制约,自主性及使用成本低;
- 历史悠久,社区和用户非常活跃,遇到问题及时寻求帮助;
- 软件体积小,安装使用简单且易于维护,维护成本低;品牌口碑效应;
- 支持多种OS,提供多种API接口,支持多种开发语言,对流行的PHP,JAVA很好的支持。
缺点： - MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户权限时才发生改变。
- MySQL的另一个主要的缺陷之一是缺乏标准的RI(Referential Integrity-RI)机制；Rl限制的缺乏(在给定字段域上的一种固定的范围限制)可以通过大量的数据类型来补偿。
- MySQL没有一种存储过程(Stored Procedure)语言，这是对习惯于企业级数据库的程序员的最大限制。
- MySQL不支持热备份。
● Oracle
简介：
Oracle数据库系统是世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小微机环境。它是一种高效率的、可靠性好的、适应高吞吐量的数据库方案。
优点：
- 兼容性：Oracle产品采用标准SQL，并经过美国国家标准技术所(NIST)测试。与IBM SQL/DS、DB2、INGRES、IDMS/R等兼容。
- 可移植性：Oracle的产品可运行于很宽范围的硬件与操作系统平台上。可以安装在多种大、中、小型机上；可在多种操作系统下工作。
- 可联结性：Oracle能与多种通讯网络相连，支持各种协议。
- 高生产率：Oracle产品提供了多种开发工具，能极大地方便用户进行进一步的开发。
- 开放性：Oracle良好的兼容性、可移植性、可连接性和高生产率使Oracle RDBMS具有良好的开放性。
缺点： - 对硬件的要求很高；
- 价格比较昂贵；
- 管理维护麻烦一些；
- 操作比较复杂，需要技术含量较高；
● PostgrepSQL
简介：
PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统（ORDBMS），是以加州大学计算机系开发的POSTGRES，4.2版本为基础的对象关系型数据库管理系统。POSTGRES的许多领先概念只是在比较迟的时候才出现在商业网站数据库中。PostgreSQL支持大部分的SQL标准并且提供了很多其他现代特性，如复杂查询、外键、触发器、视图、事务完整性、多版本并发控制等。同样，PostgreSQL也可以用许多方法扩展，例如通过增加新的数据类型、函数、操作符、聚集函数、索引方法、过程语言等。另外，因为许可证的灵活，任何人都可以以任何目的免费使用、修改和分发PostgreSQL。
优点：
1.PostgreSQL的特性覆盖了SQL-2/SQL-92和SQL-3/SQL-99，是目前世界上支持最丰富的数据类型的数据库。
2.PostgreSQL是全功能的自由软件数据库，PostgreSQL是唯一支持事务、子查询、多版本并行控制系统、数据完整性检查等特性的唯一的一种自由软件的数据库管理系统。
3.PostgreSQL采用的是比较经典的C/S(client/server)结构，也就是一个客户端对应一个服务器端守护进程的模式，这个守护进程分析客户端来的查询请求，生成规划树，进行数据检索并最终把结果格式化输出后返回给客户端。
4.PostgreSQL对接口的支持也是非常丰富的，几乎支持所有类型的数据库客户端接口。
缺点：
（1）最新版本和历史版本不分离存储，导致清理老旧版本时需要做更多的扫描，代价比较大但一般的数据库都有高峰期，如果合理安排VACUUM，这也不是很大的问题，而且在PostgreSQL9.0中VACUUM进一步被加强了。
（2）在PostgreSQL中，由于索引完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，不能直接从索引中返回所需的属性，还需要访问表，而Oracle与Innodb则可以。
(3)对于PostgreSQL这样的关系数据库来说，分区不是强项。如果需要水平扩展而不是垂直扩展（多个并行的数据库而不是单个强大的机器或集群），可能最好寻找别的解决方案。如果数据要求过于灵活，不是很容易融入关系数据库严格的数据模式要求，或者不需要一个完整的数据库功能带来的开销，需要进行非常大量的键值对读写操作，或只需要存储二进制大对象数据，那么其他的数据存储技术可能更好。
● GreenPlum
简介：
GP(GreenPlum)是业界最快最高性价比的关系型分布式数据库，它在开源的PG(PostgreSql)的基础上采用MPP架构（Massive Parallel Processing,海量并行处理），具有强大的大规模数据分析任务处理能力。
GP作为大数据融合存储平台中众多数据库之一，与其他数据库系统和文件系统一起，为OceanMind提供完整的OceanStorage大数据融合存储解决方案。
优点：
1、海量存储
GreepPlum支持50PB(1PB=1024TB)级海量数据的存储和管理，GreenPlum将来自不同源系统的、不同部门、不同平台的数据集成到数据库中集中存放，并且存放详尽历史的数据轨迹，业务用户不用再面对一个又一个信息孤岛，也不再困惑于不同版本数据导致的偏差，同时对于IT人员也降低管理维护工作的复杂度。
2、高并发
Greenplum提供资源管理功能 (workload managemnt)来管理数据库资源，利用资源队列管理可实现按用户组的进行资源分配，如 Session同时激活数、最大资源值等。通过资源管理功能，可以按用户级别进行资源分配和管理用户SQL查询优先级别，同时也能防止低质量SQL(如没有条件的多表join等)对系统资源的消耗。
3、高性价比
GreenPlum数据库软件系统节点基于业界各种开放式硬件平台，如SUN/HP/DELL等厂商的PC Sercer等，在普通的x86Sercer上就能达到很高的性能，因此性价比很高，相比于其他封闭式数据仓库的专用系统，Greenplum每TB的投资是前者的1/5甚至更低，同样，Greenplum产品的维护成本相比较于同类厂商也低很多。
4、系统易用
GreenPlum产品是基于流行的PostgreSql之上开发，几乎所有的Postgresql客户端工具及PostgreSQL应用都能运行在Greenplum平台上，在Internet上由着丰富的PostgreSQL资源供用户参考。
5、高可用性
Greenplum是高可用的系统，在已有案例中最多使用了96台机器的集群MPP环境。除了硬件级的Raid技术外， Greenplum还提供数据库层 Mirror机制保护，即每个节点数据在另外的节点中同步 镜像，单个节点的错误不影响整个系统的使用。
对于主节点， Greenplum提供 Master/Stand by机制进行主节点容错，当主节点发生错误时，可以切换到Stand by节点继续服务。
6、反应速度快
Greenplum通过准实时、实时的数据加载方式，实现数据仓库的实时更新，进而实现动态数据仓库(ADW)。基于动态数据仓库，业务用户能对当前业务数据进行BI实时分析-“Just In Time BI”，能够让企业敏锐感知市场的变化，加快决策支持反应速度
缺点：
- 主从双层架构，并非真正的扁平架构，存在性能瓶颈和SPOF单点故障。
- Master主控节点性能瓶颈，并发性能低，实际应用中无法支持超过30个并发。
- 并发能力很有限（受物理Master限制），性能随并发量增加而快速下降。
- 集群规模受物理Master限制，实际应用中很难超过20个物理节点。
- 无法支持数据压缩态下的DML操作，不易于数据的维护和更新。
- 主备双Master节点容灾方案，在切换事物日志到备用master时，如有数据操作，容易导致数据损坏、insert数据丢失、delete未删除成功等。
- 单个节点上的数据库没有并行和大内存使用能力，必须通过部署多个实列（segment servers）来充分利用系统资源，造成使用和部署很复杂。
- 本地化售后服务不足，实际项目中无法保障系统正常运维。
● ElasticSearch
简介：
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。
优点：
1 天然分片，天然集群
es 把数据分成多个shard，下图中的P0-P2，多个shard可以组成一份完整的数据，这些shard可以分布在集群中的各个机器节点中。随着数据的不断增加，集群可以增加多个分片，把多个分片放到多个机子上，已达到负载均衡，横向扩展。
在实际运算过程中，每个查询任务提交到某一个节点，该节点必须负责将数据进行整理汇聚，再返回给客户端，也就是一个简单的节点上进行Map计算，在一个固定的节点上进行Reduces得到最终结果向客户端返回。
2 天然索引
ES 所有数据都是默认进行索引的，这点和mysql正好相反，mysql是默认不加索引，要加索引必须特别说明，ES只有不加索引才需要说明。
而ES使用的是倒排索引和Mysql的B+Tree索引不同。
缺点：
1、 对于传统的关系性数据库对于关键词的查询，只能逐字逐行的匹配，性能非常差。
2、匹配方式不合理，比如搜索“小密手机” ，如果用like进行匹配， 根本匹配不到。但是考虑使用者的用户体验的话，除了完全匹配的记录，还应该显示一部分近似匹配的记录，至少应该匹配到“手机”。
● PG/GP
4、 数据采集体系技术
● SQOOP
简介：
Sqoop是一款开源的工具，主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql…)间进行数据的传递，可以将一个关系型数据库（例如 ： MySQL ,Oracle ,Postgres等）中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中。Sqoop专为大数据批量传输设计，能够分割数据集并创建Hadoop任务来处理每个区块。通过导入导出命令加配套参数控制操作。
优点：
1）sqoop在导入导出数据时，充分采用了map-reduce计算框架，根据输入条件生成一个map-reduce作业，在hadoop集群中运行。采用map-reduce框架同时在多个节点进行import或者export操作，速度比单节点运行多个并行导入导出效率高，同时提供了良好的并发性和容错性。
2）支持insert、update模式，可以选择参数，若内容存在就更新，若不存在就插入。
3）对国外的主流关系型数据库支持性更好。
4）sqoop是专门为hadoop而生，对hadoop支持度好。
缺点：
1）sqoop只可以在关系型数据库和hadoop组件之间进行数据迁移，而在hadoop相关组件之间，比如hive和hbase之间就无法使用sqoop互相导入导出数据，同时在关系型数据库之间，比如mysql和oracle之间也无法通过sqoop导入导出数据。
2）sqoop只支持官方提供的指定几种关系型数据库和hadoop组件之间的数据交换。
● DataX
简介：
DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现不同类型数据源（包含关系型数据库、分布式文件系统等）之间的数据同步，包括 MySQL、Oracle、HDFS、Hive、OceanBase、HBase、OTS、ODPS 等各种异构数据源之间高效的数据同步。DataX采用了框架 + 插件 的模式，目前已开源，代码托管在github。从应用的模式，DataX更适合ELT模式。
优点：
1）datax能够分别实现关系型数据库hadoop组件之间、关系型数据库之间、hadoop组件之间的数据迁移。
2）操作简单，只有2步，一是创建作业的配置文件（json格式配置reader,writer）；二是启动配置文件作业。
3）数据传输过程在单进程内完成，全内存操作，不读写磁盘，也没有IPC。
开放式的框架，开发者可以在极短的时间开发一个新插件以快速支持新的数据库/文件系统。
缺点：
1）datax仅仅在运行datax的单台机器上进行数据的抽取和加载，速度比sqoop慢了许多。
2）缺乏增量更新的支持，但可以自己写shell脚本等方式实现增量同步。
3）datax可能会出现不支持高版本hadoop的现象。
4）
● Kettle
简介：
Kettle 是一款国外开源的 ETL 工具，纯Java编写，提供强大的提取、转换和加载(ETL)功能，主要用来对不同数据库的数据、不同来源的数据进行处理；绿色无需安装，解压即可；可以运行在Windows、Linux等多个平台。
它允许你管理来自不同数据库的数据，通过提供一个图形化的用户环境来描述你想做什么，而不是你想怎么做，kettle 设计的核心概念是可视化的编程，以图形化的方式，定义复杂的ETL程序和工作流，可以简化数据仓库的创建、更新和维护，使用Kettle可以构建一套开源的ETL解决方案。
kettle 的核心概念：
1）转换：转换是 kettle 中最基础的、主要的部分；进行抽取数据、转换数据、加载数据、输出数据等等操作；
2）作业：由一个或者多个转换或者作业组成，作业运行时，按照自定义的顺序执行。
3）跳：是步骤之间的链接，定义了步骤之间的数据通路。
4）步骤：组成转换的基本部分，由一个或者多个步骤组成转换，步骤之间都是独立的线程，可以并发执行；
转换包含一个或者多个步骤，这些步骤可以通过跳来连接。转换里的步骤有多个，每个步骤都是独立的线程，所以一个转换里的全部步骤可以并发运行。
Kettle中有两种脚本文件，transformation和job，transformation完成针对数据的基础转换，job则完成整个工作流的控制。Kettle是一个组件化的集成系统，包括如下几个主要部分（核心组件）：
1）Spoon：图形化界面工具(GUI方式)，Spoon通过图形界面来设计Job和Transformation，是以拖拽图形化进行设计转换和作业。也可以直接在Spoon图形化界面中运行Job和Transformation。
2）Pan：Transformation执行器(命令行方式)，批量运行Spoon数据转换过程，Pan用于在终端执行Transformation，没有图形界面。
3）Kitchen：Job执行器(命令行方式)，Kitchen用于在终端执行Job，没有图形界面。
4）Carte：嵌入式Web服务，用于远程执行Job或Transformation，Kettle通过Carte建立集群。
Kettle的使用场景很多，不仅限于这些：在应用程序或数据库之间进行数据迁移；从数据库导出数据到文件；导入大规模数据到数据库；数据清洗；集成应用程序。
优点：
免费开源、易配置（绿色无需安装）、流程式设计方便易用、全面的数据访问支持、支持多平台、插件架构扩展性好、商业/社区支持、多种方式应用集成、数据抽取高效稳定。支持sql , 可以编写 js ,可以编写一些 java 代码，然后以工作流的形式流转。
缺点：面对特别复杂的业务逻辑，受制于组件的使用情况；通过定时运行，实时性较差。
● Maxwell
简介：
Maxwell 是由美国 zendesk 开源，用 java 编写的一个能实时读取MySQL二进制日志binlog，并生成 JSON 格式的消息，作为生产者发送给 Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。设计的初衷是实时采集MySQL数据到Kafka，Maxwell = MySQL + Kafka，它是Kafka的Producer。它的常见应用场景有ETL、维护缓存、收集表级别的dml指标、增量到搜索引擎、数据分区迁移、切库binlog回滚方案等。它的工作方式是伪装为Slave，接收binlog events，然后根据schemas信息拼装，可以接受ddl、xid、row等各种event。
优点：
1）部署非常方便，Maxwell即是服务端也是客户端，服务端和客户端是一体的。
2）Maxwell有一个bootstrap功能，可以直接引导出完整的历史数据用于初始化（支持 SELECT * FROM table 的方式进行全量数据初始化）。
3）支持自动断点还原（在主库发生failover后，自动恢复binlog位置(GTID)），出错好解决。
4）可以对数据进行分区，解决数据倾斜问题，发送到kafka的数据支持database、table、column等级别的数据分区。
5）maxwell相对于canal的优势是使用简单，它直接将数据变更输出为json字符串，不需要再编写客户端。
6）Maxwell比Canal更加轻量级，出错风险低。
7）Maxwell代码质量非常好，且社区更加的活跃。
缺点：
1） Maxwell 只支持 json 格式。
2） maxwell相对单一，定位就是mysql->kafka。
● Canal
简介：
canal 由Java开发的一个实现同步增量数据的中间件，分为服务端和客户端，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费，拥有众多的衍生应用，性能稳定，功能强大。
canal的工作原理就是把自己伪装成MySQL slave，模拟MySQL slave的交互协议向MySQL Mater发送 dump协议，MySQL mater收到canal发送过来的dump请求，开始推送binary log给canal，然后canal解析binary log，再发送到存储目的地，比如MySQL，Kafka，Elastic Search等等。
canal可以做：数据库镜像、数据库实时备份、索引构建和实时维护、业务cache(缓存)刷新、带业务逻辑的增量数据处理。
使用场景示例：使用Kafka，实现Redis与MySQL的数据同步架构图：
优点：
Canel数据格式自由，如果用Server+client模式的话，可以自定义格式。
支持HA。
缺点：
1）canal 只能抓取最新数据，对已存在的历史数据没有办法处理，即对于数据初始化来说，canal还不支持。
2）canal 需要自己编写客户端来消费canal解析到的数据。
canal与Maxwell的对比：
● Nifi
简介：
Apache NiFi 是一个易于使用、功能强大而且可靠的数据拉取、数据处理和分发系统，用于自动化管理系统间的数据流。它支持高度可配置的指示图的数据路由、转换和系统中介逻辑，支持从多种数据源动态拉取数据。NiFi原来是NSA(National Security Agency [美国国家安全局])的一个项目，目前已经代码开源，是Apache基金会的顶级项目之一。NiFi基于Web方式工作，后台在服务器上进行调度。用户可以为数据处理定义为一个流程，然后进行处理，后台具有数据处理引擎、任务调度等组件。
nifi的主要用途是对数据进行处理，可汇总、分流、过滤、筛选、组合…等等。
Nifi 的设计理念接近于基于流的编程。自企业拥有多个系统开始, 一些系统会有数据生成, 一些系统要消费数据, 而不同系统间的数据流通问题就出现了。简单的说, NiFi 就是为了解决不同系统间数据自动流通问题而建立的。
NiFi 架构：
Nifi是在主机操作系统上的JVM内执行。JVM上的Nifi主要组件如下:
1）网络服务器：Web服务器的目的是托管NiFi的基于HTTP的命令和控制API。
2）流控制器：流控制器是操作的大脑。它提供用于扩展程序运行的线程，并管理扩展程序接收资源以执行的时间表。
3）扩展：有各种类型的NiFi扩展在其他文档中描述。这里的关键是扩展在JVM中运行和执行。
4）FlowFile存储库：FlowFile存储库是NiFi跟踪目前在流程中活动的给定FlowFile的知识状态。
存储库的实现是可插拔的。默认方法是位于指定磁盘分区上的持久写入前端日志。
5）内容存储库：Content Repository是给定FlowFile的实际内容字节。存储库的实现是可插拔的。
默认方法是一个相当简单的机制，它将数据块存储在文件系统中。
可以指定多个文件系统存储位置，以便获得不同的物理分区，以减少任何单个卷上的争用。
6）源头存储库：Provenance Repository是存储所有来源的事件数据的地方。
存储库构造是可插入的，默认实现是使用一个或多个物理磁盘卷。
在每个位置内，事件数据被索引和可搜索。NiFi还能够在集群内运行。
NIFI面板：
优点：
1）nifi内部功能强大，它的一个优点就是大大减少了编程量！它有很多内置的处理模块，只需用户修改条件或变量便可实现其功能，此外还有一些模块可执行程序代码来进行更灵活的自定义的操作。
2）可视化的UI界面，各个模块组件之间高度可配置，且每个流程都有监控，可以通过界面直观的看到各个数据处理模块之间的数据流转情况，分析出程序性能瓶颈。
3）数据流可以在UI界面自由拖拽和拓展，各模块之间相互独立，互不影响。
4）可以在处理耗时的地方创建多个处理模块并行执行，提升处理速度。类似于代码中加入了多线程，但相对于修改代码，界面配置操作十分简单。
5）修改方便，任意模块都可以在数据流转过程中随时启停，任意处理模块都可以实现热插拔。数据流流向随时可变。
6）Nifi的对处理模块有对应的retry机制和错误分发机制，且可配置性强。
缺点：
各个步骤中间结果落地导致磁盘IO成为Nifi的瓶颈，这个缺点在数据冗余量越大的时候表现的越明显。
5、分布式存储技术
● 分布式文件系统HDFS
简介：
Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（Distributed File System）。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。
优点：
高容错
HDFS是可以由成百上千台服务器机器组成，每个服务器机器存储文件系统数据的一部分。HDFS中的副本机制会自动把数据保存多个副本，DataNode节点周期性地向NameNode发送心跳信号，当网络发生异常，可能导致DataNode与NameNode失去通讯，NameNode和DataNode通过心跳检测机制，发现DataNode宕机，DataNode中副本丢失，HDFS则会从其他DataNode上面的副本自动恢复，所以HDFS具有高的容错性。
流式数据访问
HDFS的数据处理规模比较大，应用程序一次需要访问大量的数据，同时这些应用程序一般都是批量的处理数据，而不是用户交互式处理，所以应用程序能以流的形式访问数据集，请求访问整个数据集要比访问一条记录更加高效。
支持超大文件
HDFS分布式文件系统具有很大的数据集，旨在可靠的大型集群上存储超大型文件(GB、TB、PB级别的数据)，它将每个文件切分成多个小的数据块进行存储，除了最后一个数据块之外的所有数据块大小都相同，块的大小可以在指定的配置文件中进行修改，在Hadoop2.x版本中默认大小是128M。
高数据吞吐量
HDFS采用的是“一次写入，多次读取”这种简单的数据一致性模型，在HDFS中，一个文件一旦经过创建、写入、关闭后，一旦写入就不能进行修改了，只能进行追加，这样保证了数据的一致性，也有利于提高吞吐量。
可构建在廉价的机器上
Hadoop的设计对硬件要求低，无需构建在昂贵的高可用性机器上，因为在HDFS设计中充分考虑到了数据的可靠性、安全性和高可用性
缺点：
高延迟
HDFS不适用于低延迟数据访问的场景，例如：毫秒级实时查询。
不适合小文件存取场景
对于Hadoop系统，小文件通常定义为远小于HDFS的数据块大小(128MB)的文件，由于每个文件都会产生各自的元数据，Hadoop通过NameNode来存储这些信息，若小文件过多，容易导致NameNode存储出现瓶颈。
不适合并发写入
HDFS目前不支持并发多用户的写操作，写操作只能在文件末尾追加数据
● 分布式数据库HBase
简介：
BigTable 是⼀个分布式存储系统，利⽤⾕歌提出的 MapReduce 分布式并⾏计算模型来处理海量数据，使⽤⾕歌分布式⽂件系统 GFS 作为提成数据存储，并采⽤ Chubby 提供协同服务管理，可以扩展到 PB 级别的数据和上前台机器，具备⼴泛应⽤型、可扩展性、⾼性能和⾼可⽤性等特点
总的来说，BigTable 具备以下特征：⽀持⼤规模海量数据、分布式并发数据处理效率极⾼、易于扩展且⽀持动态伸缩、适合于廉价设备、适合于读操作不适合写操作。
Hbase 是针对⾕歌 BigTable 的开源实现，是⼀个⾼可靠、⾼性能、⾼向列、可伸缩的分布式数据库，主要⽤来存储 半结构化 和 结构化的松散数据。HBase 的⽬标是处理⾮常庞⼤的表，可以通过⽔平扩展的⽅式，利⽤廉价计算机集群处理由超过 10 亿⾏数据和数百万列元素组成的数据表。
HBase 利⽤ Hadoop MapReduce 来处理 HBase 中的海量数据，实现⾼性能计算；利⽤ Zookeeper 作为协同服务，实现稳定服务和失败恢复；利⽤ HDFS 作为⾼可靠的底层存储，利⽤廉价集群提供海量数据存储能⼒。此外，Sqoop 为 HBase 提供⾼效、便捷的 RDBMS 数据导⼊功能，Pig 和 Hive 为 HBase 提供了⾼层语⾔⽀持。
优点：
HDFS有高容错，高扩展的特点，而Hbase基于HDFS实现数据的存储，因此Hbase拥有与生俱来的超强的扩展性和吞吐量。
HBase采用的是Key/Value的存储方式，这意味着，即便面临海量数据的增长，也几乎不会导致查询性能下降。
HBase是一个列式数据库，相对于于传统的行式数据库而言。当你的单张表字段很多的时候，可以将相同的列(以regin为单位)存在到不同的服务实例上，分散负载压力。
适合场景：单表超千万，上亿，且高并发！
缺点：
架构设计复杂，且使用HDFS作为分布式存储，因此只是存储少量数据，它也不会很快。在大数据量时，它慢的不会很明显！
Hbase不支持表的关联操作，因此数据分析是HBase的弱项。常见的 group by或order by只能通过编写MapReduce来实现！
Hbase部分支持了ACID
不适合场景：主要需求是数据分析，比如做报表。数据量规模不大，对实时性要求高！
● 分布式数据库仓库Hive
简介：
hive是基于Hadoop构建的一套数据仓库分析系统，它提供了丰富的SQL查询方式来分析存储在Hadoop分布式文件系统中的数据：可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能；可以将SQL语句转换为MapReduce任务运行，通过自己的SQL查询分析需要的内容，这套SQL简称Hive SQL，使不熟悉mapreduce的用户可以很方便地利用SQL语言查询、汇总和分析数据。而mapreduce开发人员可以把自己写的mapper和reducer作为插件来支持hive做更复杂的数据分析。它与关系型数据库的SQL略有不同，但支持了绝大多数的语句如DDL、DML以及常见的聚合函数、连接查询、条件查询。它还提供了一系列的工具进行数据提取转化加载，用来存储、查询和分析存储在Hadoop中的大规模数据集，并支持UDF（User-Defined Function）、UDAF(User-Defined AggregateFunction)和UDTF（User-Defined Table-Generating Function），也可以实现对map和reduce函数的定制，为数据操作提供了良好的伸缩性和可扩展性。 hive不适合用于联机(online)事务处理，也不提供实时查询功能。它最适合应用在基于大量不可变数据的批处理作业。hive的特点包括：可伸缩（在Hadoop的集群上动态添加设备）、可扩展、容错、输入格式的松散耦合。
优点：
简单容易上手：提供了类SQL查询语言HQL
可扩展：为超大数据集设计了计算/扩展能力（MR作为计算引擎，HDFS作为存储系统）
一般情况下不需要重启服务Hive可以自由的扩展集群的规模。
提供统一的元数据管理
延展性：Hive支持用户自定义函数，用户可以根据自己的需求来实现自己的函数
容错：良好的容错性，节点出现问题SQL仍可完成执行
缺点：
hive的HQL表达能力有限：迭代式算法无法表达，比如pagerank
数据挖掘方面，比如kmeans
hive的效率比较低：hive自动生成的mapreduce作业，通常情况下不够智能化
hive调优比较困难，粒度较粗
hive可控性差
● 数据湖技术Hudi
简介：
优点：
缺点：
● 数据湖技术Delta lake
简介：
优点：
缺点：
● 数据湖技术Iceberg
简介：
优点：
缺点：
6、数据处理技术体系
● 分布式计算框架 MapReduce
简介：
MapReduce是一种编程模型,是面向大数据并行处理的计算模型、框架和平台，是一个基于集群的高性能并行计算平台，是一个并行计算与运行的软件框架，是一个并行程序设计模型与方法。
优点：
1、 MapReduce 易于编程
它简单的实现一些接口，就可以完成一个分布式程序，这个分布式程序可以分布到大量廉价的机器上运行。也就是说你写一个分布式程序，跟写一个简单的串行程序是一模一样的。就是因为这个特点使得MapReduce编程变得非常流行。
2、 良好的扩展性
当你的计算资源不能得到满足的时候，你可以通过简单的增加机器来扩展它的计算能力。
3、 高容错性
MapReduce设计的初衷就是使程序能够部署在廉价的机器上，这就要求它具有很高的容错性。比如其中一台机器挂了，它可以把上面的计算任务转移到另外一个节点上运行，不至于这个任务运行失败，而且这个过程不需要人工参与，而完全是由Hadoop内部完成的。
4、 适合PB级以上海量数据的离线处理
可以实现上千台服务器集群并发工作，提供数据处理能力。
缺点：
1、 不擅长实时计算
MapReduce无法像MySQL一样，在毫秒或者秒级内返回结果。
2、 不擅长流式计算
流式计算的输入数据是动态的，而MapReduce的输入数据集是静态的，不能动态变化。这是因为MapReduce自身的设计特点决定了数据源必须是静态的。
3、 不擅长DAG（有向图）计算
多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出。在这种情况下，MapReduce并不是不能做，而是使用后，每个MapReduce作业的输出结果都会写入到磁盘，会造成大量的磁盘IO，导致性能非常的低下。
● 分布式计算框架 Spark
简介：
Spark是用于大规模数据处理的统一分析引擎。最初是由加州大学柏克莱分校AMPLab所开发。它提供了Scala，Java，Python和R中的高级API，以及优化的引擎，该引擎支持用于数据分析的通用计算图。它还支持一组丰富的高级工具，包括使用 SQL 处理结构化数据处理的 Spark SQL，用于机器学习的 MLlib，用于图计算的 GraphX，以及 Spark Streaming。
Spark的一个主要特点是能够在内存中进行计算，及时依赖磁盘进行复杂的运算，相对于Hadoop的MapReduce会在运行完工作后将中介数据存放到磁盘中来说，Spark依然比MapReduce更加高效。
优点：
1、 快速处理能力强，基于内存；
2、 易用性高，支持多种语言；
3、 通用：Spark提供了Spark RDD、Spark SQL、Spark Streaming、Spark MLlib、Spark GraphX等技术组件；
4、 支持SQL、HQL查询；
5、 兼容性强：Spark能够直接对HDFS进行数据读，既支持Standalone独立部署（Master and Slaver模式），也支持基于Yarn的混合模式。
6、 相较于MapReduce，开发代码简洁。
缺点：
1、 内存问题：不稳定，集群偶尔会挂掉。因为是基于内存运算的，因为确实与磁盘的I/O，如果数据量超出内存会出现挂掉的现象；
2、 分配不均匀：数据的分割，会导致集群中的各台机器上计算任务分配不均匀。
● 分布式计算框架 Flink
简介：
Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。
Flink 功能强大，支持开发和运行多种不同种类的应用程序。它的主要特性包括：批流一体化、精密的状态管理、事件时间支持以及精确一次的状态一致性保障等。Flink 不仅可以运行在包括 YARN、 Mesos、Kubernetes 在内的多种资源管理框架上，还支持在裸机集群上独立部署。在启用高可用选项的情况下，它不存在单点失效问题。事实证明，Flink 已经可以扩展到数千核心，其状态可以达到 TB 级别，且仍能保持高吞吐、低延迟的特性。世界各地有很多要求严苛的流处理应用都运行在 Flink 之上。
优点：
1、 同时支持高吞吐、低延迟、高性能
Flink 是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者于一身的分布式 流式数据处理框架。像 Apache Spark 也只能兼顾高吞吐和高性能特性，主要因为在 Spark Streaming 流式计算中无法做到低延迟保障；而流式计算框架 Apache Storm 只 能支持低延迟和高性能特性，但是无法满足高吞吐的要求。而满足高吞吐、低延迟、高 性能这三个目标对分布式流式计算框架来说是非常重要的。
2、 支持事件时间（Event Time）概念
在流式计算领域中，窗口计算的地位举足轻重，但目前大多数框架窗口计算采用的都是系统时间（Process Time），也是事件传输到计算框架处理时，系统主机的当前时 间。Flink 能够支持基于事件时间（Event Time）语义进行窗口计算，也就是使用事件 产生的时间，这种基于事件驱动的机制使得事件即使乱序到达，流系统也能够计算出精 确的结果，保持了事件原本产生时的时序性，尽可能避免网络传输或硬件系统的影响。
3、 支持有状态计算
Flink 在 1.4 版本中实现了状态管理，所谓状态就是在流式计算过程中将算子的中 间结果数据保存在内存或者文件系统中，等下一个事件进入算子后可以从之前的状态中 获取中间结果中计算当前的结果，从而无须每次都基于全部的原始数据来统计结果，这种方式极大地提升了系统的性能，并降低了数据计算过程的资源消耗。对于数据量大且 运算逻辑非常复杂的流式计算场景，有状态计算发挥了非常重要的作用。
4、 基于轻量级分布式快照（CheckPoint）实现的容错
Flink 能够分布式运行在上千个节点上，将一个大型计算任务的流程拆解成小的计 算过程，然后将 tesk 分布到并行节点上进行处理。在任务执行过程中，能够自动发现 事件处理过程中的错误而导致数据不一致的问题，比如：节点宕机、网路传输问题，或 是由于用户因为升级或修复问题而导致计算服务重启等。在这些情况下，通过基于分布 式快照技术的 Checkpoints，将执行过程中的状态信息进行持久化存储，一旦任务出现 异常停止，Flink 就能够从 Checkpoints 中进行任务的自动恢复，以确保数据在处理过 程中的一致性（Exactly-Once）。
5、 基于 JVM 实现独立的内存管理
内存管理是所有计算框架需要重点考虑的部分，尤其对于计算量比较大的计算场 景，数据在内存中该如何进行管理显得至关重要。针对内存管理，Flink 实现了自身管 理内存的机制，尽可能减少 JVM GC 对系统的影响。另外，Flink 通过序列化/反序列化 方法将所有的数据对象转换成二进制在内存中存储，降低数据存储的大小的同时，能够 更加有效地对内存空间进行利用，降低 GC 带来的性能下降或任务异常的风险，因此 Flink 较其他分布式处理的框架会显得更加稳定，不会因为 JVM GC 等问题而影响整个 应用的运行。
6、 Save Points（保存点）
对于 7*24 小时运行的流式应用，数据源源不断地接入，在一段时间内应用的终止 有可能导致数据的丢失或者计算结果的不准确，例如进行集群版本的升级、停机运维操 作等操作。值得一提的是，Flink 通过 Save Points 技术将任务执行的快照保存在存储 介质上，当任务重启的时候可以直接从事先保存的 Save Points 恢复原有的计算状态， 使得任务继续按照停机之前的状态运行，Save Points 技术可以让用户更好地管理和运 维实时流式应用。
缺点：
1、相较于Spark，Flink还不够成熟稳定。
7、OLAP生态体系
OLAP（On-Line Analytical Processing）：联机分析处理，OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
OLTP（on-line transaction processing）：联机事务处理，传统的关系型数据库的主要应用，主要是基本的、日常的事务处理。
● Kylin
简介：
Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表
工作原理：
Apache Kylin的工作原理本质上是MOLAP（Multidimensional Online Analytical Processing）Cube，也就是多维立方体分析。其工作原理就是对数据模型做Cube预计算，并利用计算的结果加速查询。过程如下：
（1）指定数据模型（目前支持星形模型和雪花模型），定义维度和度量。
（2）预计算Cube，计算所有Cuboid并将其保存为物化视图。
（3）执行查询时，读取Cuboid，进行加工运算产生查询结果。
优点：
● 可扩展超快OLAP引擎:
Kylin是为减少在Hadoop上百亿规模数据查询延迟而设计
● Hadoop ANSI SQL 接口:
Kylin为Hadoop提供标准SQL支持大部分查询功能
● 交互式查询能力:
通过Kylin，用户可以与Hadoop数据进行亚秒级交互，在同样的数据集上提供比Hive更好的性能
● 多维立方体（MOLAP Cube）:
用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体
● 与BI工具无缝整合:
Kylin提供与BI工具，如Tableau，的整合能力，即将提供对其他工具的整合
缺点：
● 需要创建 cube 的模型定义，即指定度量和维度以及一些附加信息
● kylin 强依赖于 HBase 的 coprocessor，所以需要在创建 HTable 为该表部署 coprocessor，这个文件会首先上传到 HBase 所在的 HDFS 上，然后在表的元信息中关联，这一步很容易出现错误，例如 coprocessor 找不到了就会导致整个 regionServer 无法启动
● Presto
简介：
Presto是Facebook开发的数据查询引擎，可对250PB以上的数据进行快速地交互式分析。Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。Worker节点负责实际执行查询任务。Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据
优点：
● PB级海量数据复杂分析，交互式SQL查询，⽀持跨数据源查询
● presto的查询速度比hive快5-10倍
缺点：
● presto取代不了hive，因为presto是基于内存的，多个大表的join操作，多张大表在内存里可能放不下
● presto不太支持存储过程，支持部分标准sql
● Druid
简介：
Apache Druid是一个分布式内存实时分析系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析的问题。Druid最常被当做数据库来用以支持实时摄取、高性能查询和高稳定运行的应用场景，同时，Druid也通常被用来助力分析型应用的图形化界面，或者当做需要快速聚合的高并发后端API，Druid最适合应用于面向事件类型的数据。
优点：
● 亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
● 实时的数据消费，真正做到数据摄入实时、查询结果实时。
● 高效的多租户能力，最高可以做到几千用户同时在线查询。
● 扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
● 极高的高可用保障，支持滚动升级。
缺点：
● 适用于宽表，不适用与join方式
● 适用于清洗好的数据，不需要更新操作，Druid支持流式插入，但不支持流式更新（更新操作是通过后台批处理作业完成）
● Impala
简介：
Impala是Cloudera公司推出，提供对HDFS、Hbase数据的高性能、低延迟的交互式SQL查询功能。兼顾数据仓库、具有实时、批处理、多并发等优点，是CDH平台首选的PB级大数据实时查询分析引擎。包含执行节点、存储状态、元数据三个组件。
Impala将相同的元数据，SQL语法（Hive SQL），ODBC驱动程序和用户界面（Hue Beeswax）用作Apache Hive，为面向批量或实时查询提供熟悉且统一的平台。与Apache Hive不同，Impala不基于MapReduce算法。 它实现了一个基于守护进程的分布式架构，它负责在同一台机器上运行的查询执行的所有方面。因此，它减少了使用MapReduce的延迟，这使Impala比Apache Hive快
优点：
● 基于Hive使用内存计算，兼顾数据仓库、具有实时、批处理、多并发等优点
● 基于内存进行计算，能够对PB级数据进行交互式实时查询、分析
● 无需转换为MR，直接读取HDFS及Hbase数据 ,从而大大降低了延迟
● 兼容HiveSQL
● 具有数据仓库的特性，可对hive数据直接做数据分析
● 支持Data Local
● 支持列式存储
● 支持JDBC/ODBC远程访问
缺点：
● 对内存依赖大
● 基于C++
● 完全依赖hive
● 实践过程中分区超过1w 性能严重下下降
● ClickHouse
简介：
ClickHouse 是俄罗斯的 Yandex 于 2016 年开源的用于在线分析处理查询（OLAP :Online Analytical Processing）MPP架构的列式存储数据库（DBMS：Database Management System），能够使用 SQL 查询实时生成分析数据报告。ClickHouse的全称是Click Stream，Data WareHouse。
优点：
● Clickhouse社区活跃度高、版本迭代非常快
● 基于shard+replica实现的线性扩展和高可靠
● 采用列式存储，数据类型一致，压缩性能更高
● 硬件利用率高，连续IO，提高了磁盘驱动器的效率
● 向量化引擎与SIMD提高了CPU利用率，多核多节点并行化大查询
缺点：
● 不支持事务、异步删除与更新
● 不适用高并发场景
● Phoenix
简介：
phoenix:构建在hbase上的一个SQL层，让我们可以用标准的JDBC APIs来创建表，插入数据和对HBase数据进程查询。你可以使用标准的JDBC API代替HBase客户端API来创建表，插入数据，查询你的HBase数据。
优点：
● 在Hbase上查询的性能超过了Hive和Impala
缺点：
● 只能查Hbase
● Kudu
简介：
Kudu是Cloudera开源的新型列式存储系统，是Apache Hadoop生态圈的成员之一(incubating)，专门为了对快速变化的数据进行快速的分析，填补了以往Hadoop存储层的空缺。
优点：
● 对数据扫描(scan)和随机访问(random access)同时具有高性能，简化用户复杂的混合架构
● 高CPU效率，使用户购买的先进处理器的的花费得到最大回报
● 高IO性能，充分利用先进存储介质
● 支持数据的原地更新，避免额外的数据处理、数据移动
● 支持跨数据中心replication
缺点：
● Doris
简介：
Apache Doris是一个现代化的MPP（大规模并行分析）分析型数据库产品。仅需亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。Apache Doris的分布式架构非常简洁，易于运维，并且可以支持10PB以上的超大数据集。
Apache Doris可以满足多种数据分析需求，例如固定历史报表，实时数据分析，交互式数据分析和探索式数据分析等
优点：
● 高并发高吞吐
● 动态分区，减少用户的使用负担
●
缺点：
● 应用不广
● 成熟度不足
8、方法论
● 离线数仓构建方法论
简介：
数据源通过离线方式导入离线数仓中，能完成周期性的分析，包括：日报，周报，月报数据，T+1后提供可用数据。解决数据量暴增问题。
优点：成熟架构
缺点：时效性差
● 实时数仓构建方法论
简介：
解决时效性问题，离线数仓+实时链路， 离线数仓+实时数仓，纯实时数仓。
优点：实时
缺点：复杂且技术不断变化
● 数据治理-数据质量管理
简介：数据质量框架包括定义需求、定义检查策略、定义度量和定义反映数据质量和绩效变化的监控措施。这些需求反映了业务数据预期的3个方面:
1、 将数据预期记录在业务规则中；
2、 在该维度上度量数据质量；
3、 定义一个可接受度的阈值；
用戴明环实现数据质量的提升。
优点：可获得高质量的数据
缺点：需要先建立和提升数据质量意识(O)
● 数据治理-元数据管理
简介：
元数据定义：元数据是指用来描述数据的数据，目录。分类：
业务元数据：业务数据定义,包括计算公式；业务规则和算法,包括层级；数据血缘和影响分析等。
技术和操作元数据：编码转换/参照表变换规则；清洗规则；物理数据模型,包括表名、键和索引等。
流程元数据：流程名称；流程顺序和计时等
数据管理制度元数据
优点：
帮助分析人员了解数据上下文
降低员工流失影响
弥合业务与IT之间的分歧
提高数据质量
缺点：
集中式元数据架构：使用 单独的元数据存储库，但 需要复杂的流程来确保将元数据来源的变更快速复制到存储库中。
分布式元数据架构：维护一个单一的访问点， 元数据获取引擎响应用户的需求，从元数据来源系统实时获取元数据，而不存在永久的元数据存储库。查询能力受制于相关元数据来源系统的可用，且不支持修改。
混合元数据架构：元数据依然从元数据来源系统进人存储库。但存储库的设计只考虑用户增加的元数据、高度标准化的元数据以及手工获取的元数据。
双向元数据架构：允许元数据在架构中的任何部分(如元数据来源、ETL、用户接口等)发生变化,然后通过存储库反馈到初始的元数据来源,存储库充当了变更的桥接器。包含此类功能的商用套装软件正在开发中，同时，相关标准仍在制定之中。
● 数据治理-数据安全管理
简介：
优点：
缺点：
● Kerberos
简介：Kerberos是一种计算机网络授权协议，用来在非安全网络中，通过密钥加密技术为客户端/服务器应用程序提供身份验证。
优点：
缺点：
● 数据中台构建方法论
简介：
优点：
缺点：
● 可视化：TCV，Superset，Hue，RDP
简介：
1、 腾讯云图 TCV（Tencent Cloud Visualization） - 大屏数据化展示平台
2、 Superset 是 Airbnb 开源的数据分析与可视化平台，同时也是由 Python 语言构建的轻量级 BI 系统。
3、Hue，使用Web图形界面的可视化的形式展示所查询出来的数据，展示的形式有表格、柱状图、折线图、饼状图、地图等等。
优点：
缺点：
9、集群调度体系
● 分布式调度Yarn
简介：Hadoop2.x引入了一个新的组件,Yarn，它作为hadoop集群中的资源管理模块，为各类计算框架提供资源的管理和调度。负责管理集群中的资源：CPU，内存，磁盘，网络IO等等（v3.1.1版本之后新增了对GPU资源的管理）以及调度运行在YARN之上的各种计算任务。
优点: 1)资源管理与任务调度解耦,一个集群的资源共享上层各个计算框架,按需分配,提高了资源利用率
2）运维成本下降
3）避免了单点故障
4）支持多种计算框架
缺点:
1）各个应用无法感知集群整体资源的使用情况，只能等待上层调度推送信息。
2）资源分配采用轮询、ResourceOffer机制（mesos)，在分配过程中使用悲观锁，并发粒度小。
3）缺乏一种有效的竞争或优先抢占的机制。
● 任务流调度oozie
简介：一个基于工作流引擎的开源框架，由Cloudera公司贡献给Apache，提供对Hadoop Mapreduce、Pig Jobs的任务调度与协调。Oozie需要部署到Java Servlet容器中运行。主要用于定时调度任务，多任务可以按照执行的逻辑顺序调度。是个web项目，需要部署到web容器。一个基于工作流引擎的开源框架，由Cloudera公司贡献给Apache，提供对Hadoop Mapreduce、Pig Jobs的任务调度与协调。Oozie需要部署到Java Servlet容器中运行。主要用于定时调度任务，多任务可以按照执行的逻辑顺序调度。是个web项目，需要部署到web容器。
优点：
1）Oozie与Hadoop生态系统紧密结合，提供做种场景的抽象。
2）Oozie有更强大的社区支持，文档。
3）Job提交到hadoop集群，server本身并不启动任何job。
4）通过control node/action node能够覆盖大多数的应用场景。
5）Coordinator支持时间、数据触发的启动模式。
6）支持参数化和EL语言定义workflow，方便复用。
7）结合HUE，能够方便的对workflow查看以及运维，能够完成workflow在前端页面的编辑、提交 能够完成workflow在前端页面的编辑、提交。
8）支持action之间内存数据的交互。
9）支持workflow从某一个节点重启。
缺点：
1）Oozie调度的Workflow只能使用XML文件配置
2）启动调度只能通过命令行
3）无法通过Oozie界面调试调度脚本
4）无法分组,权限管理等
● 任务流调度Azkaban
简介： Azkaban是由linkedin（领英）公司推出的一个批量工作流任务调度器，用于在一个工作流内以一个特定的顺序运行一组工作和流程。Azkaban使用job配置文件建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪你的工作流。
优点：
1）提供功能清晰，简单易用的Web UI界面
2）提供job配置文件快速建立任务和任务之间的依赖关系
3）提供模块化和可插拔的插件机制，原生支持command、Java、Hive、Pig、Hadoop
4）基于Java开发，代码结构清晰，易于二次开发
缺点：
1） 出现失败的情况：Azkaban会丢失所有的工作流，因为Azkaban将正在执行的workflow状态保存在内存中
2）操作工作流：Azkaban使用Web操作，不支持RestApi，Java API操作
3）Azkaban可以直接操作shell语句。在安全性上可能Oozie会比较好
● Ariflow
简介：
Airflow 是一个使用 Python 语言编写的 Data Pipeline 调度和监控工作流的平台。
Airflow 是通过 DAG（Directed acyclic graph 有向无环图）来管理任务流程的任务调度工具，不需要知道业务数据的具体内容，设置任务的依赖关系即可实现任务调度。
这个平台拥有和 Hive、Presto、MySQL、HDFS、Postgres 等数据源之间交互的能力，并且提供了钩子（hook）使其拥有很好地扩展性。除了使用命令行，该工具还提供了一个 WebUI 可以可视化的查看依赖关系、监控进度、触发任务等
优点：
1）提供了一个很好的UI，允许你通过代码/图形检查DAG（工作流依赖性），并监视作业的实时执行。
2）高度定制Airflow。
缺点：
1）部署几台集群扩容相对复杂及麻烦。
2）Airflow的调度依赖于crontab命令，调度程序需要定期轮询调度计划并将作业发送给执行程序。
3）定期轮询工作，你的工作不能保证准时安排。
4）当任务数量多的时候，容易造成卡死。
● 集群管理平台 cloudera Manager
简介：Cloudera Manager是cloudera公司的一个产品，着重于帮助大家管理自己的CDH集群，通过Cloudera Manager统一的UI界面来快速地自动配置和部署CDH和其相关组件，同时Cloudera Manager还提供了各种丰富的可自定义化的监视诊断和报告功能，集群上统一的日志管理功能，统一的集群配置管理和实时配置变更功能，多租户功能，高可用容灾部署功能和自动恢复功能等， 方便企业统一管理和维护自己的数据中心。它细分为免费的Express版本和功能完全并提供众多增值服务的收费版本Enterprise。
Cloudera Manager有四大功能：
（1）管理：对集群进行管理，如添加、删除节点等操作。
（2）监控：监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控。
（3）诊断：对集群出现的问题进行诊断，对出现的问题给出建议解决方案。
（4）集成：对hadoop的多组件进行整合。
优点：
1) 基于稳定版本Apache Hadoop，解决了组件不一样版本之间的冲突问题，并应用了最新Bug修复或Feature的patch，在兼容性、安全性、稳定性上有加强。
2) 默认优化了不少参数，如HDFS的snappy压缩。
3) 提供了部署、安装、配置工具，大大提升了集群部署的效率，能够在数个小时内部署好集群。
4) 第三方发行版一般都通过了大量的测试验证，有众多部署实例，大量的运行到各类生产环境。
5) 运维简单。提供了管理、监控、诊断、配置修改的工具，管理配置方便，定位问题快速、准确，使运维工做简单，有效。
缺点：
1) 免费社区版功能不全，非社区版服务收费。
2) 收费标准：按节点收费，Cloudera每一个节点一年4000美元，Hortonworks 每一个节点一年1250美元。
● Ambari
简介：Ambari是Hortonworks公司开源的Hadoop平台的管理软件，着重于帮助大家管理自己的HDP集群，具备Hadoop组件的安装、管理、运维等基本功能，提供Web UI进行可视化的集群管理，简化了大数据平台的安装、使用难度。
优点：
1) 各个组件彻底开源免费。数据库
2) 社区资源活跃。apache
3) 能够加深对各个组件的理解和掌握。
缺点：
1) 集群部署：集群部署、安装、配置耗时比较多，一般按照集群须要编写大量的配置文件，分发到每一台节点上，容易出错，效率低下。
2) 版本管理：组件的版本管理比较复杂，在Hadoop生态圈中，组件的选择、使用，好比Hive，Mahout，Sqoop，Flume，Spark，impala,Oozie等等，须要大量考虑兼容性的问题，版本是否兼容，组件是否有冲突，编译是否能经过等。常常会浪费大量的时间去编译组件，解决版本冲突问题。
3) 集群运维：对集群的监控，运维，须要安装第三方的其余软件，如ganglia，nagois等，运维难度较大，同时运维成本比较高。
10、数据挖掘体系相关
● python
数据分析相关包的介绍：
1、Numpy（一维）
Numpy是Python科学计算的基础包，它提供了很多功能:快速高效的多维数组对象ndarray、用于对数组执行元素级计算以及直接对数组执行数学运算的函数、用于读写硬盘上基于数组的数据集的工具、线性代数运算、傅里叶变换以及随机数生成等。NumPy在数据分析方面还有另外一个主要作用，即作为在算法和库之间传递数据的容器。
2、Pandas（数据的读取、处理和探索）
Pandas提供了快速便捷处理结构化数据的大量数据结构和函数。自从2010年出现以来,它助使Python成为强大而高效的数据分析环境。其中用得最多的Pandas对象是DataFrame,它是一个面向列的二维表结构，另一个是Series,一个-维的标签化数组对象。Pandas兼具Numpy高性能的数组计算功能以及电子表格和关系型数据库灵活的数据处理功能。还提供了复杂精细的索引功能，能更加便捷地完成重塑、切片和切块、聚合以及选取数据子集等操作。
3、matplotlib（图形化)
matplotlib是最流行的用于绘制图表和其他二维数据可视化的Python库。它最初由JohnD.Hunter(JDH)创建，目前由一个庞大的开发团队维护。它非常适合创建出版物上用的图表。虽然还有其他的Python可视化库,但matplotlib应用最为广泛。
4、SciPy
SciPy是一组专门解决科学计算中各种标准问题域的包的集合，它与Numpy结合使用，便形成了一个相当完备和成熟的计算平台，可以处理多种传统的科学计算问题。
5、scikit-learn(机器学习)
2010年诞生以来，scikit-learn成为了Python通用机器学习工具包。它的子模块包括:分类、回归、聚类、降维、选型、预处理等。依赖于 Numpy、 Scipy和 Matplotlib。与pandas、statsmodels和IPython一起，scikit-learn对于Python成为高效数据科学编程语言起到了关键作用。
6、statsmodels(数据的统计建模分析)
statsmodels是一个统计分析包，起源于斯坦福大学统计学教授，他设计了多种流行于R语言的回归分析模型。Skipper Seabold和Josef Perktold在2010年正式创建了statsmodels项目，随后汇聚了大量的使用者和贡献者。与scikit-learn比较，statsmodels包含经典统计学和经济计量学的算法。
● 多元线性回归
简介：回归分析（regression analysis)指的是确定两种或两种以上变量间相互依赖的定量关系的一种统计分析方法。回归分析按照涉及的变量的多少，分为一元回归和多元回归分析；按照自变量和因变量之间的关系类型，可分为线性回归分析和非线性回归分析。
● 逻辑归回
简介：逻辑回归是用来计算“事件=Success”和“事件=Failure”的概率。当因变量的类型属于二元（1 / 0，真/假，是/否）变量时，应该使用逻辑回归。
● 贝叶斯算法
简介：
正向概率:假设袋子里面有N个白球，M个黑球，你伸手进去摸一把，摸出黑球的概率是多大
逆向概率:如果我们事先并不知道袋子里面黑白球的比例，而是闭着眼睛摸出一个(或好几个)球，观察这些取出来的球的颜色之后，那么我们可以就此对袋子里面的黑白球的比例作出什么样的推测。
贝叶斯就是逆向概率的推算公式。
假设有随机事件A和B，它们的条件概率关系可以用以下数学公式表达：
其中，事件A是要考察的目标事件，P(A)是事件A的初始概率，称为先验概率，它是根据一些先前的观测或者经验得到的概率。
B是新出现的一个事件，它会影响事件A。P(B)表示事件B发生的概率。
P(B|A)表示当A发生时B的概率，它是一个条件概率
P(A|B)表示当B发生时A的概率（也是条件概率），它是我们要计算的后验概率，指在得到一些观测信息后某事件发生的概率。
● KNN算法
简介：knn是一种非参数的分类算法。邻接算法，或K近邻分类算法(kNN,k-NearestNeighbor)是数据挖掘中最简单的分类方法之一。称 K近邻，是表示最近邻居 k的近邻，表示每一个样本都能以其最接近 k的邻居表示。
在训练集中数据和标签已知的情况下，输入测试数据，将测试数据的特征与训练集中对应的特征进行相互比较，找到训练集中与之最为相似的前K个数据，则该测试数据对应的类别就是K个数据中出现次数最多的那个分类，其算法的描述为：
1）计算测试数据与各个训练数据之间的距离；
2）按照距离的递增关系进行排序；
3）选取距离最小的K个点；
4）确定前K个点所在类别的出现频率；
5）返回前K个点中出现频率最高的类别作为测试数据的预测分类。
● KMeans算法
简介：K-means 是我们最常用的基于欧式距离的聚类算法，其认为两个目标的距离越近，相似度越大。
优点:
简单,效果不错
缺点：
对异常值敏感
对初始值敏感
对某些分布聚类效果不好
● Kmeans++算法
简介：我们知道初始值的选取对结果的影响很大，对初始值选择的改进是很重要的一部分。在所有的改进算法中，K-means++ 最有名。
简单的来说，就是 K-means++ 就是选择离已选中心点最远的点。这也比较符合常理，聚类中心当然是互相离得越远越好。
但是这个算法的缺点在于，难以并行化。所以 k-means II 改变取样策略，并非按照 k-means++ 那样每次遍历只取样一个样本，而是每次遍历取样 k 个，重复该取样过程 log(n) 次，则得到 klog(n) 个样本点组成的集合，然后从这些点中选取 k 个。当然一般也不需要 log(n) 次取样，5 次即可。
● TF-IDF
简介：TF-IDF是Term Frequency - Inverse Document Frequency的缩写，即“词频-逆文本频率”。它由两部分组成，TF和IDF。
TF词频，统计文本中各个词的出现频率统计，并作为文本特征。
IDF，即“逆文本频率”，反应了一个词在所有文本中出现的频率，如果一个词在很多的文本中出现，那么它的IDF值应该低，比如上文中的“to”。而反过来如果一个词在比较少的文本中出现，那么它的IDF值应该高。比如一些专业的名词如“Machine Learning”。这样的词IDF值应该高。一个极端的情况，如果一个词在所有的文本中都出现，那么它的IDF值应该为0。
优点：理解简单，计算简单
缺点：
（1）没有考虑特征词的位置因素对文本的区分度，词条出现在文档的不同位置时，对区分度的贡献大小是不一样的。
（2）按照传统TF-IDF，往往一些生僻词的IDF(反文档频率)会比较高、因此这些生僻词常会被误认为是文档关键词。
（3）传统TF-IDF中的IDF部分只考虑了特征词与它出现的文本数之间的关系，而忽略了特征项在一个类别中不同的类别间的分布情况。
（4）对于文档中出现次数较少的重要人名、地名信息提取效果不佳。
● 决策树（Decision Tree）
简介：接近⼈的思维⽅式，可以产⽣可视化的分类规则，产⽣的模型具有可解释性（可以抽取规则）。树模型拟合出来的函数其实是分区间的阶梯函数。
20个问题的游戏，游戏的规则很简单：参与游戏的一方在脑海里想某个事物，其他参与者向他提问题，只允许提20个问题，问题的答案也只能用对或错来回答。问问题的人通过推断分解，逐步缩小待猜测事物的范围。
这是一种基于 if-then-else 规则的有监督学习算法，决策树的这些规则通过训练得到，而不是人工制定的。
特征选择
特征选择决定了使用哪些特征来做判断。在训练数据集中，每个样本的属性可能有很多个，不同属性的作用有大有小。因而特征选择的作用就是筛选出跟分类结果相关性较高的特征，也就是分类能力较强的特征。
在特征选择中通常使用的准则是：信息增益。
决策树生成
选择好特征后，就从根节点触发，对节点计算所有特征的信息增益，选择信息增益最大的特征作为节点特征，根据该特征的不同取值建立子节点；对每个子节点使用相同的方式生成新的子节点，直到信息增益很小或者没有特征可以选择为止。
决策树剪枝
剪枝的主要目的是对抗「过拟合」，通过主动去掉部分分支来降低过拟合的风险。
ID3 算法
ID3 是最早提出的决策树算法，他就是利用信息增益来选择特征的。
C4.5 算法
他是 ID3 的改进版，他不是直接使用信息增益，而是引入“信息增益比”指标作为特征的选择依据。
CART（Classification and Regression Tree）
这种算法即可以用于分类，也可以用于回归问题。CART 算法使用了基尼系数取代了信息熵模型。
优点
● 决策树易于理解和解释，可以可视化分析，容易提取出规则；
● 可以同时处理标称型和数值型数据；
● 比较适合处理有缺失属性的样本；
● 能够处理不相关的特征；
缺点
● 容易发生过拟合（随机森林可以很大程度上减少过拟合）；
● 容易忽略数据集中属性的相互关联；
● 对于那些各类别样本数量不一致的数据，在决策树中，进行属性划分时，不同的判定准则会带来不同的属性选择倾向；信息增益准则对可取数目较多的属性有所偏好（典型代表ID3算法），而增益率准则（CART）则对可取数目较少的属性有所偏好，但CART进行属性划分时候不再简单地直接利用增益率尽心划分，而是采用一种启发式规则）（只要是使用了信息增益，都有这个缺点，如RF）。
● ID3算法计算信息增益时结果偏向数值比较多的特征。
● 随机森林
简介：随机森林是由很多决策树构成的，不同决策树之间没有关联。
当我们进行分类任务时，新的输入样本进入，就让森林中的每一棵决策树分别进行判断和分类，每个决策树会得到一个自己的分类结果，决策树的分类结果中哪一个分类最多，那么随机森林就会把这个结果当做最终的结果。
缺点
- 随机森林已经被证明在某些噪音较大的分类或回归问题上会过拟合。
- 对于有不同取值的属性的数据，取值划分较多的属性会对随机森林产生更大的影响，所以随机森林在这种数据上产出的属性权值是不可信的