OLTP和OLAP的区别
OLTP（on-line transaction processing）翻译为联机事务处理， 或者在线交易处理系统数据库
OLAP（On-Line Analytical Processing）翻译为联机分析处理，或者在线分析系统网络
从字面上来看OLTP是作事务处理，OLAP是作分析处理。从对数据库操做来看，OLTP主要是对数据的增删改，OLAP是对数据的查询。架构
区别：性能
OLTP主要用来记录某类业务事件的发生，如购买行为，当行为产生后，系统会记录是谁在什么时候何地作了何事，这样的一行（或多行）数据会以增删改的方式在数据库中进行数据的更新处理操做，要求实时性高、稳定性强、确保数据及时更新成功，像公司常见的业务系统如ERP，CRM，OA等系统都属于OLTP。大数据
当数据积累到必定的程度，咱们须要对过去发生的事情作一个总结分析时，就须要把过去一段时间内产生的数据拿出来进行统计分析，从中获取咱们想要的信息，为公司作决策提供支持，这时候就是在作OLAP了ui
由于OLTP所产生的业务数据分散在不一样的业务系统中，而OLAP每每须要将不一样的业务数据集中到一块儿进行统一综合的分析，这时候就须要根据业务分析需求作对应的数据清洗后存储在数据仓库中，而后由数据仓库来统一提供OLAP分析。因此咱们常说OLTP是数据库的应用，OLAP是数据仓库的应用，下面用一张图来简要对比。搜索引擎
多维分析中的经常使用操做：spa
下面介绍数据立方体中最多见的五大操做：切片，切块，旋转，上卷，下钻。翻译
下钻（Drill-down）：在维的不一样层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，好比经过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度四、五、6每月的消费数据，如上图；固然也能够钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。设计
上卷（Roll-up）：钻取的逆操做，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。
切片（Slice）：选择维中特定的值进行分析，好比只选择电子产品的销售数据，或者2010年第二季度的数据。
切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，好比选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。
旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中经过旋转实现产品维和地域维的互换。
在调研了市面上主流的开源OLAP引擎后发现，目前尚未一个系统可以知足各类场景的查询需求。其本质缘由是，没有一个系统能同时在数据量、性能、和灵活性三个方面作到完美，每一个系统在设计时都须要在这三者间作出取舍。
MPP架构的系统（Presto/Impala/SparkSQL/Drill等）有很好的数据量和灵活性支持，可是对响应时间是没有保证的。当数据量和计算复杂度增长后，响应时间会变慢，从秒级到分钟级，甚至小时级都有可能。
MPP即大规模并行处理（Massively Parallel Processor ）。 在数据库非共享集群中，每一个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特色划分到各个节点上，每台数据节点经过专用网络或者商业通用网络互相链接，彼此协同计算，做为总体提供数据 库服务。非共享数据库集群有彻底的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优点。
缺点：性能不稳定
搜索引擎架构的系统（Elasticsearch等）相对比MPP系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能作到亚秒级响应。可是对于扫描聚合为主的查询，随着处理数据量的增长，响应时间也会退化到分钟级。
缺点：性能不稳定
预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
缺点：不太灵活
MPP和搜索引擎系统没法知足超大数据集下的性能要求，所以很天然地会考虑预计算系统。而Druid主要面向的是实时Timeseries数据，咱们虽然也有相似的场景，但主流的分析仍是面向数仓中按天生产的结构化表，所以Kylin的MOLAP Cube方案是最适合做为大数据量的引擎。