大数据解决方案FAQ-OLAP组件介绍
【摘要】 OLAP基本概念什么是OLAP？On Line Analysis Processing，通过对过往历史数据(数据量通常会大)的分析，获取数据的价值，支撑业务发展的决策。分析什么数据？用户行为数据、运营数据、财务数据等等，通常来讲会根据OLAP支撑的业务场景来分成不同的主题数据进行分析。给谁用？数据分析人员、运营人员、业务主管、老板Online是什么含义？On Line的直接含义就是指OLAP...
| OLAP基本概念 | 什么是OLAP？ | On Line Analysis Processing，通过对过往历史数据(数据量通常会大)的分析，获取数据的价值，支撑业务发展的决策。 | ||
| 分析什么数据？ | 用户行为数据、运营数据、财务数据等等，通常来讲会根据OLAP支撑的业务场景来分成不同的主题数据进行分析。 | |||
| 给谁用？ | 数据分析人员、运营人员、业务主管、老板 | |||
| Online是什么含义？ | On Line的直接含义就是指OLAP引擎的计算任务通常是在人机交互的场景下发生的，通常是需要在用户可忍受的时间内返回结果的。 | |||
| 常见相似概念的关系？ | 交互式查询、Ad-hoc：即席查询，通常是指通过手写SQL来完成一些临时的数据的探索分析需求。“即席查询”在很多语境下跟OLAP是等同的，因为OLAP的特点就是即席。他们之间细微的差别在于，OLAP的“即席查询”有些情况下是不能支持特别灵活的自定义条件的，比如像kylin这样的OLAP引擎，通常它的“即席查询”条件会被固定在它事先建立好的Cube上。而Ad-hoc通常会偏向指可以提供更加灵活的查询条件的“即席查询”。 数仓：数仓的说法一般有两种语境，一种是“逻辑概念”，指用“分层建模方法”来建立的“数据仓库”；另一种是指“数据仓库引擎”，比如DWS服务，比如传统常见的Teradata、Greenplum、Oracle、Vertica、A3的ADB等等。一般“数据仓库引擎”都属于常说的“OLAP引擎”。 SQL on hadoop：是指在hadoop的数据和计算引擎上实现类sql语言的能力。但实现了sql on hadoop并不代表就是OLAP的引擎了，比如hive和sparksql通常就不认为是OLAP引擎，而是大数据的批处理引擎；反过来，OLAP也并没有限制必须支持sql的引擎才叫OLAP引擎。 |
|||
| OLAP跟大数据是什么关系？ | OLAP这个场景基本上是大数据领域里必备的一个场景，通常说的“大数据分析”中的分析，主要指的就是“OLAP”这个场景。而在OLAP之前，通常还会有一个“大数据处理”的过程。 可以简单的理解一个典型大数据处理过程通常会有如下几个过程：采集->处理（hive、spark做ETL处理）->分析（impala、clickhouse、doris、kylin等）->应用（BI）。 所以，通常OLAP引擎“分析”的数据应该是“处理”后的“数据”，一般是聚合后的主题层数据；它的特点是经过处理或汇聚之后，数据量已经没有原始数据那么大了，同时形成了基于某些业务维度的“主题数据”，这样在这些数据机上就容易做更高性能的交互式分析和查询。 |
|||
| 在华为云大数据方案里，提供的OLAP服务有哪些？ | MRS-Impala/Presto/ClickHouse、DLI-Spark/Hetu（尚未上线）、DWS。参见右图。 | |||
| OLAP组件对比 | 组件 | 优势 | 劣势 | 常见场景 |
| Hive/SparkSQL | 成熟度最高，通用性最强。 | Hive的性能基本不能满足OLAP的性能需求；Spark在多数情况下也难以满足，只有少量对交互性能要求不高的情况下会用spark来做OLAP分析。 | Hive基本不会用在OLAP场景，Spark也很少，他们主要用在离线批处理场景。 | |
| Presto | Hadoop原生态的OLAP方案，可以直接读取hive表数据。 | 性能上有劣势，一般多表关联的查询都在秒级-分钟级。 | 通常用在数据量不是很大，同时业务场景有较多的基于明细数据做探索的需求。 | |
| Impala（on hive） | ||||
| Impala（on kudu） | 基于kudu存储引擎，可以做秒级的数据接入，和update的数据接入。 性能比impala on hive优秀。 |
成熟度、稳定性不如Presto和Impala on hive。 Kudu的分区管理需要较高的经验和技术成本。 |
当客户的业务场景有实时的数据入湖和update数据入湖的情况下，可以选择kudu。 但当前更倾向于使用hudi+presto的方案来做这个场景。 |
|
| Durid | 支持实时数据接入，支持高并发，适合指标的实时计算和分析。 | 配置和查询复杂，不支持类sql语言，使用门槛高。 | 不少互联网公司使用durid做监控指标的实时统计和分析。通常跟prometheus配合。 | |
| Kylin | 基于HBase的预聚合方案，最终的查询性能好，成熟度高，业界应用广泛。 | 是cube与计算的思想，因此有几个缺点： 1、预计算消耗资源多，会消耗原大数据集群的hive资源，运维成本高。 2、cube的设计导致有新的运营分析需求时，应对和响应成本较高。 |
多用在相对固定的报表分析场景，kylin提供一些预设计cube的维度的快速分析和查询，通常可以直接对接BI工具提供可视化报表。 | |
| DorisDB/StarRocks | mpp架构，重新设计的存储，支持实时数据接入和数据更新，支持bitmap索引，支持较高的并发能力，支持mysql语法，OLAP性能较impala、presto更加优秀。 | 成熟度一般，单表查询和聚合性能相比ClickHouse稍差。 | 目前应用场景逐渐增多，不少互联网客户都开始使用dorisdb做实时数仓和高并发数仓。 | |
| ClickHouse | 列存储分析型数仓，单机、单表聚合查询性能非常优秀。 | 只适合大宽表的单表查询和聚合分析，多表关联性能差。 需要自管理分区，运维成本高。 对实时数据的导入支持有限，适合微批的入库。 |
当客户需要基于明细数据做灵活的ad-hoc查询和分析，希望支持灵活的自助分析和自助报表能力的时候，可以考虑使用ClickHouse。前提是要设计好大宽表。 | |
| 华为云DWS服务 | 完整的事务支持；性能优秀，绝大部分场景下可以pk掉友商ADB，部分场景可以pk掉ClickHouse；完整的关系型数据库事务支持；完整的ANSI SQL语法支持（PG语法）；高扩展性，支持上千节点。 | 成本较高，特别是相对友商ADB和Hologres来说，配置方案没有那么灵活。 | 在华为云上的大数据解决方案里，通常推荐使用DWS与Hadoop生态大数据服务（MRS、DLI）配合，形成完整大数据方案。（MRS/DLI做数据ETL处理，DWS做主题数据的分析，对接BI支持报表应用） 除非客户无法接受DWS成本，或PG语法。 |
|
服务伙伴相关技术问题可至☞服务伙伴知识库论坛问题求助专区提问
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）