画像数据的产出、画像平台工程化实现都会涉及OLAP技术领域，本节先介绍一下OLAP是什么以及相关技术的发展历程。
OLAP与OLTP对比
提到OLAP，必然会涉及OLTP，那两者有什么区别？
- OLAP（Online Analytical Processing，联机分析处理）：数据仓库系统的主要应用方式，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。一般以大数据量的查询为主，修改和删除的操作较少。
- OLTP（Online Transaction Processing，联机事务处理）：传统的关系型数据库的主要应用方式，支持基本的、日常的事务处理能力，一般都应用在高可用的在线系统中，比如银行交易。表1-1给出了OLTP与OLAP的对比说明。
表1-1 OLTP与OLAP对比说明
OLTP | OLAP | |
用户 | 功能操作人员 | 数据分析师、决策人员 |
目的 | 支持基本业务运行 | 发现和分析问题、支持决策 |
特点 | 处理大量支持事务的任务 | 对大量数据进行复杂查询 |
查询类型 | 简单的、标准化的查询 | 复杂查询 |
数据操作 | 频繁的增删改操作；读取数据量不大 | 很少修改和删除操作；以读为主，读取数据量大 |
时间要求 | 实时性要求高 | 实时性要求不严格 |
存储格式 | 修改操作频繁，通常是行存储 | 查询数据量大，通常是列式存储 |
主要应用 | 数据库 | 数据仓库 |
模型设计 | 规范化的数据模型，至少满足第三范式 | 非规范化的数据模型 |
并发要求 | 高并发 | 低并发 |
事务要求 | 支持事务 | 没有要求 |
技术典范 | MySQL、Oracle、SQL Server | SQL-On-Hadoop |
OLAP场景关键特征
- 根据ClickHouse官网所述，OLAP场景有如下一些关键特征：
- 绝大多数是读请求。
- 数据以相当大的批次（ >1000行）更新，而不是单行更新或者没有更新。
- 已添加到数据库的数据很少修改。
- 对于读取，从数据库中提取相当多的行，但只提取小部分列数据。
- 宽表，即每个表包含着大量的列。
- 查询相对较少（通常每台服务器每秒查询数百次或更少）。
- 对于简单查询，允许延迟大于50毫秒。
- 列中的数据相对较小：数字和短字符串。
- 处理单个查询时需要高吞吐量（每台服务器每秒可达数十亿行）。
- 事务不是必需的。
- 对数据一致性要求低。
- 查询结果明显小于源数据。数据经过过滤或聚合后，数据量比较小。
OLAP的3种建模类型
OLAP按建模类型主要划分为3种：MOLAP（Multidimensional OLAP，多维OLAP）、ROLAP（Relational OLAP，关系型OLAP）、HOLAP（Hybrid OLAP，混合OLAP）。表1-2给出了OLAP 3种模型的对比，包括典型代表、优缺点及适用场景等。
表1-2 OLAP 3种建模类型对比
MOLAP | ROLAP | HOLAP | |
典型代表 | Druid、Kylin | Hive、Spark SQL、Presto、Impala、ClickHouse、Elasticsearch | - |
优点 | 一般会根据用户定义的数据维度、指标在数据写入时生成预聚合数据；避免了查询时大量的即时计算，提升了查询性能 | 整个过程都是即时计算，不需要进行数据预处理，支持灵活查询，有很强的可扩展性 | 很好地结合了MOLAP和ROLAP的优势 |
缺点 | 需要预先定义维度进行预计算，如果业务发生需求变更，需要重新进行建模和预计算。 不支持明细数据的查询。 所有计算都在构建多维数据集时执行，多维数据集中包含数据量有限 | 基于大量数据进行即时查询，响应速度较慢，影响用户的查询体验。 当数据量较大或查询较为复杂时，查询性能不稳定，可用性也会降低 | 需要同时支持MOLAP和ROLAP，本身的体系结构非常复杂 |
适用场景 | 适用于查询场景相对固定并且对查询性能要求非常高的场景。如广告投放平台中广告投放报表分析功能 | 适用于对查询模式不固定、查询灵活性要求高的场景。如数据分析类产品，因为预先不能确定分析内容，所以需要更高的查询灵活性 | 复合类应用场景，即对查询性能有要求，又支持很好的查询灵活性 |
OLAP相关技术发展历程
OLAP场景往往涉及大量的数据，其实现依赖大数据相关技术，其发展过程也与大数据技术的演进密切相关，本节主要介绍可用于OLAP场景下的主流大数据分析引擎的发展历程。
源于Google的三驾马车
Google在2004年前后发表了三篇论文，论文内容涉及分布式文件系统 GFS、大数据分布式计算框架MapReduce和NoSQL数据库系统BigTable。Lucene项目的创始人Doug Cutting阅读了Google的论文后，根据论文原理初步实现了类似GFS的分布式文件系统HDFS以及大数据计算引擎MapReduce，也就是今天大家使用的Hadoop。2008年Hadoop正式成为 Apache 的顶级项目，为了运营Hadoop商业化版本，Cloudera成立并大力支持Hadoop的商业化建设。
提高MapReduce开发效率
Yahoo的一些人在使用MapReduce的过程中，发现进行大数据编程太麻烦，于是便开发了Pig。Pig使用类SQL的语法，经过编译后会生成MapReduce程序，然后便可以在Hadoop上运行。使用Pig需要学习新的脚本语法，有一定的学习成本，Facebook在2010年发布了Hive，Hive可以把SQL语句转化成MapReduce的计算程序。后来Hive发展迅速，目前已经成为构建数据仓库的标准组件。Pig和Hive的出现，都是为了简化MapReduce的编写过程，编写常见的SQL语句便可以实现大数据处理，这极大降低了大数据分析和处理的门槛。
MapReduce比较慢，需要提速
MapReduce运行非常稳定，但是其计算效率较低，为了解决这一问题，在2012年左右集中出现了几款查询性能卓越的数据引擎。Facebook工程师为了实现大数据快速查询发明了Presto。UC伯克利AMP实验室马铁博士发现使用MapReduce进行机器学习计算时性能非常差，于是发明了Spark，2012年Spark开始被业界熟悉并逐渐流行起来，目前基本已经替代MapReduce在企业应用中的地位。Cloudera公司同年也开发了新型查询系统Impala，其能够基于HDFS和HBase进行PB级大数据处理，而且对SQL支持较好。2014年，eBay上海分公司研发了Kylin并开源，这是一款由国人主导的基于MOLAP模型的大数据分析引擎。
离开Hadoop生态实现OLAP引擎
ClickHouse是由俄罗斯IT公司Yandex为Yandex.Metrica网络分析服务开发的，该系统以高性能为目标而且支持对实时更新类数据进行分析。自2016年6月开源以来ClickHouse受到了各大互联网公司青睐，国内阿里、腾讯、头条、快手等对其均有大量的应用。2011年Metamarkets公司开发了Druid，并于2012年开源，Druid是一款基于MOLAP思路构建的大数据引擎，目前在业界使用也比较广泛。Doris是百度大数据部研发的产品，来自百度Palo项目，2018年贡献给了Apache社区，在OLAP领域有一定的影响力。以上三个引擎已经脱离了Hadoop生态，简单部署便可以支持超大规模数据的分析处理。
OLAP引擎不断进化
为了解决OLAP引擎不适合做数据修改和删除的问题，Cloudera研发了Apache Kudu并于2016年开源，其可以同时提供低延迟的随机读写和高效的数据分析能力。TiDB是PingCAP公司自主设计研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理的融合型分布式数据库产品，也是国人贡献的一款比较前沿的大数据引擎。
除了上述大数据引擎，在OLAP及画像领域还经常用到Elasticsearch。Elasticsearch提供了一个分布式、支持多租户的全文搜索引擎，擅长查询简单且高QPS的场景。上述各类引擎处理的业务场景都被称作批处理计算，而在大数据领域，有些应用场景需要对实时产生的数据进行即时计算，被称为实时数据处理，Flink主要用于该类计算场景。目前Flink的一个主要发展方向是流批一体，后续大数据离线处理和实时处理便可借助一套引擎来实现。
