1.OLAP技术介绍与选型OLAP，On-LineAnalyticalProcessing，主要用于支持企业决策管理分析。不同于OLTP，On-LineTransactionProcessing，联机事务处理。OLTP主要用于记录某类业务事件的发生，如交易行为。当行为发生时，数据库会记录谁做了什么，何时，何地，这样一行（或几行）数据将被（增、删、改）更新和处理数据库中的数据，这对真实性要求很高时间性能和稳定性强，确保数据及时更新成功。常见的业务系统如商城系统、ERP、客服系统、OA等系统都是基于OLTP开发的A系统。当业务发展到一定程度，积累了一些数据后，就会产生对过去发生的事情进行总结分析的需求。这类需求往往需要对过去一段时间内产生的数据进行统计分析并从中获取。我们想要的信息为公司的决策提供支持。我们称这种场景为OLAP。OLAP的优点：丰富的数据展示方式，高效的数据查询，多视图多层次的数据分析。我们常说OLTP是数据库的应用，OLAP是数据仓库的应用。两者的主要区别如下：1.1基本OLAP操作OLAP的多维分析操作包括：Drill-down、Roll-up、Slice、Dice、Pivo??t。★钻取：维度层级变化，从粗粒度到细粒度，从汇总数据向下钻取到详细数据。例：通过季度销售数据钻取月销售数据★Rollup：钻取的逆向，向上钻取。从细粒度到粗粒度，细粒度数据到不同维度层次的汇总。eg：通过月度销售数据汇总季度和年度销售数据★切片：具体维度数据（剩余两个维度）。例：只选择电子产品销售数据★切片：维度区间数据（剩余三个维度）。eg：一季度到二季度的销售数据★Rotate：交换维度位置（数据行列交换）。eg：旋转得到不同视角的数据1.2OLAP分类OLAP根据内存的数据存储格式分为ROLAP（RelationalOLAP）、MOLAP（Multi-dimensionalOLAP）和HOLAP（HybridOLAP）。MOLAP，一种基于多维数组的存储模型，也是OLAP的原始形态。它的特点是预先计算数据，以空间换取效率，将详细和聚合的数据存储在立方体中。但是生成立方体需要大量的时间和空间。MOLAP的优势在于，由于对数据进行了多维度的预处理，分析中数据计算的效率高。主要缺陷是数据更新存在一定延迟。ROLAP完全基于关系模型存储数据，不需要预先计算，可以按需即时查询。详细数据和摘要数据都存储在关系数据库事实表中。ROLAP最大的优势在于可以实时从源数据中获取最新的数据更新，维护实时数据。缺点是计算效率比较低，用户等待响应时间长。HOLAP，混合模型，细节数据存储在ROLAP中，聚合数据存储在MOLAP中。这种方法相对灵活，效率更高。1.3主流OLAP特性及适用场景分析DruidDruid采用预计算。主要解决方案是聚合和查询大量基于时间序列的数据。Druid提供实时的流式数据分析和高效的实时写入，进入Druid后可立即查看，数据几乎不可变。通常它是基于时间序列的事实事件。fact发生后进入Druid，外部系统可以查询fact。优点：查询延迟低，并发性好，完美的多租户设计。适用场景：QPS高的预聚合查询，不适用于明细查询，典型适用场景：用户行为分析，网络流量分析。Kylinkylin是一个MOLAP系统。多维立方体（MOLAPCube）的设计，使用户可以在麒麟中为超过百亿的数据集定义数据模型，构建立方体进行数据预聚合。支撑大数据生态的数据分析业务，主要是将用户设置的多维数据立方体（cube）通过预计算缓存起来，达到快速查询的目的。应用场景应该是复杂sqljoin后的数据缓存。优点：主要是对hive中的数据进行预计算。用户只需要预先定义好查询维度即可。Kylin会帮助我们计算并将结果存储在HBase中，为海量数据的查询和分析提供亚秒级的回报。.适用场景：适用于数据量大，查询维度多，但业务变化不频繁的场景。DorisDoris是MPP架构的查询引擎。整体架构非常简单。只有两种服务，FE和BE。FE负责SQL解析、规划和元数据存储，BE负责SQL-Plan的执行和数据存储。整体运行不依赖任何第三方三方系统的功能也非常丰富，支持丰富的数据更新模型、MySQL协议、智能路由等，不仅可以在子系统内获取查询结果第二响应时间，有效支持实时数据分析，同时也支持PB级别的大数据集，对业务线的部署、运维和使用非常友好。优点：支持标准的SQL语法，支持细化和聚合的高并发查询，支持多表连接和在线schema变更。适用场景：适用于高并发明细、多表关联聚合查询。典型场景：高并发分析报表、即席查询、大屏实时播报。ClickHouseClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备等丰富功能复制等，以上功能共同奠定了ClickHouse极速分析性能的基础。但Clickhouse也有其局限性。在选择OLAP技术时，应避免将其用作多表关系查询（JOIN）的引擎，也应避免将其用于希望支持高并发数据查询的场景。Clickhouse的执行模型决定了它会尽量去执行一个Query，而不是同时执行很多query。因此更适合对时效性要求高，QPS小于1000的内部BI报表等应用，而不是几十万的广告主报表或者百万级的淘宝店主。优点：向量化SQL查询引擎，强大的单表查询性能，灵活的基于明细数据的聚合查询。适用场景：QPS中等的详细查询和聚合查询，不适合QPS高的场景，也不适合多表join场景。典型适用场景：交易数据分析、业务数据分析。二、应用场景及整体解决方案一是日常交易、售后业务等业务板块的自助数据分析。运营业务端，需要实时统计订单销量和商品库存相关指标，判断订单量和增速是否达到策略预期效果，库存异常波动原因，及时调动补货库存等，售后客服端需要根据实时指标对日常工作进行评估，以更好地开展管理工作。另一个场景是大促期间的实时看板展示。大促期间，需要整个供应链和销售的实时数据，从用户流量到用户转化再到订单、产品、库存等漏斗分析，让运营方可以根据当前的数据来使用及时调整活动策略，提高转化率。大促期间的指标分析，也是一个典型的多维分析过程。OLAP平台要满足每天上万次的查询调用，查询延迟要保证在100毫秒级别。在选择OLAP平台的时候，我们对公司多个业务团队的需求进行了调研。综上所述，大家会比较关注以下几点，比如大数据规模的支持。单个数据源每天可能有数十亿条数据。需要输入的数据量；查询延迟必须保证在毫秒级到秒级；实时数据，很多业务条线明确提出了实时数据分析的需求；此外，还有高并发查询、平台稳定性等。根据用户调研和不同场景下各种OLAP应用的对比，我们绘制了如下OLAP分析架构图：3.OLAP使用优化实践3.1Druid优化物化视图What是物化视图，假设一个数据源的原始维度有十列。通过分析查询请求，发现group1中的三个维度和group2中的三个维度经常同时出现，其余四个维度的查询频率可能很低。更严重的是其中一个未查询的维度列有一个高基维度，也就是一个计数区值很大的维度，比如Userid。这样的话，就会有很大的查询性能问题，因为基础维度高会影响Druid的数据预聚合效果，而聚合效果不好会导致索引文件变大，从而导致查询时读IO增加，整体查询性能变差。针对本例的优化，我们会分别为group1和group2的维度建立一个预聚合索引。那么当收到新的查询请求时，系统首先会分析请求中的查询维度集。如果查询维度集是新建的专用索引维度集的一个子集，则可以直接访问新建的索引而不是访问原来的聚合索引，查询性能会得到显着提升。这是物化视图的一个设计思路，也是典型的以空间换时间的方案。缓存查询为了提高整体的查询速度，我们引入了Redis作为缓存。如果我们简单的缓存每次查询的SQL结果，就会有问题。不同用户每次查询的时间段不一致，导致命中缓存率低，查询性能提升不是很明显。为了提高缓存复用率，我们需要增加一种新的缓存机制：我们按照拆表的最细时间粒度，按天、按小时缓存数据。当用户的查询结果只有部分时间跨度命中redis时，只会查询没有命中的时间跨度，然后将查询结果和redis中的缓存数据拼接回给用户，从而提高查询效率。通过配置各节点的数据分布策略，冷热数据分层，让高频查询的数据尽可能分散在不同的broker中，降低单个节点的查询压力，调整History的配置参数节点。#集群分片，不写默认_default_tierdruid.server.tier=hot#查询优先级，不写默认0，_default_tier分片的两个节点都为0，热节点全部改为100。这样，热点数据只会检查热点节点的机器。druid.server.priority=100#processing.buff，默认1Gprocessing.buff=4G#processing.numThreads：默认是core-1忙的时候做process，剩下1个process和zk通信，拉seg等.druid.processing.buffer.sizeBytes=1073741824druid.processing.numThreads=303.2clickhouse优化分布式分布式聚合查询在ClickHouse的聚合查询中，每台机器都会将自己聚合的中间状态返回给分布式节点，也就是说，即使你只是想要Top100，每台机器都会将自己拥有的所有枚举值返回给分布式节点进一步聚合。ClickHouse的聚合过程大致如下：启用分布式查询优化后的执行图，如图所示，可以提前进行数据过滤，提高查询效率：hopindexclickhouse数据库是一个列式数据库，本身没有传统关系型数据库中所指的二级索引，clickhouse提供了一种适合列存检索的跳索引算法来替代二级索引。跳数索引类型minmax是一种不需要参数的轻量级索引类型。它存储每个块的索引表达式的最小值和最大值（如果表达式是元组，则单独存储元组元素的每个成员的值）。这种类型非常适合倾向于按值松散排序的列。这种类型索引的开销在查询处理过程中通常是最小的。set这种轻量级索引类型接受单个参数max_size，即每个块的值集（0允许无限数量的离散值）。此集合包含块中的所有值（如果值的数量超过max_size，则为空）。此索引类型适用于在每组颗粒中具有低基数（本质上“聚集在一起”）但具有高总体基数的列。布隆过滤器类型布隆过滤器是一种数据结构，它允许以轻微误报为代价对集合成员进行有效的存在性测试。在hopindex的使用场景中，falsepositive不是什么大问题，因为唯一的问题就是读取了一些不需要的block。潜在的误报意味着索引表达式应该为真，否则可能会跳过有效数据。在生产中，bloom_filterhopcount只对orderid、commodityid等枚举值较多的字段进行索引，其他索引没有使用，因为bloom_filter的索引文件不是太大，也可以起到一个具有更多值的列的角色。更好的过滤效果。避免使用finalClickHouse。我们可以使用ReplacintMergeTree去重数据。当数据的主键相同时，该引擎可以根据指定的字段保留一条数据。替换MergeTree只是在一定程度上解决了数据重复的问题。由于自动分区合并机制在后台是定时执行的，所以不能完全保证数据不重复。我们需要在查询结束时执行final关键字。最后执行会导致后台数据合并。如果有最终查询，效率会极低。我们应该避免使用final查询，这样我们可以通过自己写SQL查询而不使用final输出想要的数据，例如：createtablet_replacing_table(idUInt8,nameString,ageUInt8)engine=ReplacingMergeTree(age)orderbyid;insertintot_replacing_tablevalues(1,'张三',18),(2,'李四',19),(3,'王舞',20);insertintot_replacing_tablevalues(1,'张三'',20),(2,'李四',15);#自己写SQL实现去重数据的查询，避免使用final查询，提高效率SELECTid,argMax(name,age)ASnamex,max(age)ASagexFROMt_replacing_tableGROUPBYid4.总结本文主要介绍了OLAP分析架构Model的选择与实践，通过Druid和Clickhouse的引入，解决了公司在当前场景下的多维分析需求。但是OLAP目前能够支持的场景还是比较有限，对高并发自助分析场景和多表关联分析的支持还不够友好。未来希望做一个可以支持细化、聚合分析、关联场景的。OLAP平台进一步提升了公司的实时OLAP分析能力。
