干货，OLAP数仓从百万到百亿级数据量实时分析.docxVIP

干货，OLAP数仓从百万到百亿级数据量实时分析 温正湖 2021-01-23 点击上方 关注,?星标或置顶一起成长 免费送 1024GB 精品学习资源? 一、有哪些类型的OLAP数仓？ 1.按数据量划分 对一件事物或一个东西基于不同角度，可以进行多种分类方式。对数仓产品也一样。比如我们可以基于数据量来选择不同类型的数量，如下图所示：  本系列文章次要关注的是数据量处于百万到百亿级别的偏实时的分析型数仓，Cloudera的Impala、Facebook的Presto和Pivotal的GreenPlum均属于这类系统；假如超过百亿级别数据量，那么一般选择离线数仓，如使用Hive或Spark等（SparkSQL3.0看起来功能提升很明显）；对于数据量很小的情况，虽然是分析类应用，也可以直接选择一般的关系型数据库，比如MySQL等，“宰鸡焉用牛刀”。 2.按建模类型划分 下面我们次要关注数据量中等的分析型数仓，聚焦OLAP系统。依据维基百科对OLAP的引见，一般来说OLAP依据建模方式可分为MOLAP、ROLAP和HOLAP 3品种型，下面分别进行引见并分析优缺点。 （1）MOLAP 这应当算是最传统的数仓了，1993年Edgar F. Codd提出OLAP概念时，指的就是MOLAP数仓，M即表示多维（Multidimensional）。大多数MOLAP产品均对原始数据进行估计算得到用户可能需要的全部结果，将其存储到优化过的多维数组存储中，可以认为这就是上一篇所提到的“数据立方体”。 由于全部可能结果均已计算出来并长久化存储，查询时无需进行简单计算，且以数组方式可以进行高效的免索引数据访问，因而用户发起的查询均能够稳定地快速响应。这些结果集是高度结构化的，可以进行压缩/编码来削减存储占用空间。 但高功能并不是没有代价的。首先，MOLAP需要进行估计算，这会花去很多时间。假如每次写入增量数据后均要进行全量估计算，明显是低效率的，因而支持仅对增量数据进行迭代计算格外重要。其次，假如业务发生需求变更，需要进行预定模型之外新的查询操作，现有的MOLAP实例就无能为力了，只能重新进行建模和估计算。 因而，MOLAP适合业务需求比较固定，数据量较大的场景。在开源软件中，由eBay开发并贡献给Apache基金会的Kylin即属于这类OLAP引擎，支持在百亿规模的数据集上进行亚秒级查询。 其架构图较直观得反映了基于cube的估计算模型（build），如下所示： （2）ROLAP 与MOLAP相反，ROLAP无需估计算，直接在构成多维数据模型的现实表和维度表上进行计算。R即表示关系型（Relational）。明显，这种方式相比MOLAP更具可扩展性，增量数据导入后，无需进行重新计算，用户有新的查询需求时只需写好正确的SQL语句既能完成猎取所需的结果。 但ROLAP的不足也很明显，尤其是在数据体量巨大的场景下，用户提交SQL后，猎取查询结果所需的时间无法精确?????预知，可能秒回，也可能需要花费数格外钟甚至数小时。本质上，ROLAP是把MOLAP估计算所需的时间分摊到了用户的每次查询上，确定会影响用户的查询体验。 当然ROLAP的功能能否能够接受，取决于用户查询的SQL类型，数据规模以及用户对功能的预期。对于相对简约的SQL，比如TPCH中的Query响应时间较快。但假如是简单SQL，比如TPC-DS中的数据分析和挖掘类的Query，可能需要数分钟。 相比MOLAP，ROLAP的使用门槛更低，在完成星型或雪花型模型的构建，创建对应schema的现实表和维度表并导入数据后，用户只需会写出符合需求的SQL，就可以得到想要的结果。相比创建“数据立方体”，明显愈加便利。 有分析表明，虽然ROLAP的功能比如MOLAP，但由于其机警性、扩展性，ROLAP的使用者是MOLAP的数倍。 （3）HOLAP MOLAP和ROLAP各有优缺点，而且是互斥的。假如能够将两者的优点进行互补，那么是个更好的选择。而HOLAP的消灭就是这个目的，H表示混合型（Hybrid），这个想法很朴实直接。对于查询频繁而稳定但又耗时的那些SQL，通过估计算来提速；对于较快的查询、发生次数较少或新的查询需求，像ROLAP一样直接通过SQL操作现实表和维度表。 目前好像没有开源的OLAP系统属于这个类型，一些大数据服务公司或互联网厂商，比如HULU有类似的产品。信任将来HOLAP可能会得到进一步进展，并获得更大规模的使用。 （4）HTAP 从另一个维度看，HTAP也算是一种OLAP类型的系统，是ROLAP的一个扩展，具备了OLAP的力量。最新进展显示，有云厂商在HTAP的基础上做了某种妥协，将T（transaction）弱化为S（Serving），朝HSAP方向演进。关于