技术选型 - OLAP大数据技术哪家强

Lambda架构的核心理念是“流批一体化”，因为随着机器性能和数据框架的不断完善，用户其实不关心底层是如何运行的，批处理也好，流式处理也罢，能按照统一的模型返回结果就可以了，这就是Lambda架构诞生的原因。现在很多应用，例如Spark和Flink，都支持这种结构，也就是数据进入平台后，可以选择批处理运行，也可以选择流式处理运行，但不管怎样，一致性都是相同的。

Kylin

Kylin的主要特点是预计算，提前计算好各个cube，这样的优点是查询快速，秒级延迟；缺点也非常明显，灵活性不足，无法做一些 探索 式的，关联性的数据分析。

适合的场景也是比较固定的，场景清晰的地方。

ClickHouse

Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。

Clickhouse最大的特点首先是快 ，为了快采用了列式储存，列式储存更好的支持压缩，压缩后的数据传输量变小，所以更快；同时支持分片，支持分布式执行，支持SQL。

ClickHouse很轻量级，支持数据压缩和最终数据一致性，其数据量级在PB级别。

另外Clickhouse不是为关联分析而生，所以多表关联支持的不太好。

同样Clickhouse不能修改或者删除数据，仅能用于批量删除或修改。没有完整的事务支持，不支持二级索引等等，缺点也非常明显。

与Kylin相比ClickHouse更加的灵活，sql支持的更好，但是相比Kylin，ClickHouse不支持大并发，也就是不能很多访问同时在线。

总之ClickHouse用于在线数据分析，支持功能简单。CPU 利用率高，速度极快。最好的场景用于行为统计分析。

Hive

Hive这个工具，大家一定很熟悉，大数据仓库的首选工具。可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能。

主要功能是可以将sql语句转换为相对应的MapReduce任务进行运行，这样可能处理海量的数据批量，

Hive与HDFS结合紧密，在大数据开始初期，提供一种直接使用sql就能访问HDFS的方案，摆脱了写MapReduce任务的方式，极大的降低了大数据的门槛。

当然Hive的缺点非常明显，定义的是分钟级别的查询延迟，估计都是在比较理想的情况。 但是作为数据仓库的每日批量工具，的确是一个稳定合格的产品。

Presto

Presto极大的改进了Hive的查询速度，而且Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询，支持包括复杂查询、聚合、连接等等。

Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。

Presto由于是基于内存的，缺点可能是多张大表关联 *** 作时易引起内存溢出错误。

另外Presto不支持OLTP的场景，所以不要把Presto当做数据库来使用。

Presto相比ClickHouse优点主要是多表join效果好。相比ClickHouse的支持功能简单，场景支持单一，Presto支持复杂的查询，应用范围更广。

Impala

Impala是Cloudera 公司推出，提供对 HDFS、Hbase 数据的高性能、低延迟的交互式 SQL 查询功能。

Impala 使用 Hive的元数据, 完全在内存中计算。是CDH 平台首选的 PB 级大数据实时查询分析引擎。

Impala 的缺点也很明显，首先严重依赖Hive，而且稳定性也稍差，元数据需要单独的mysql/pgsql来存储，对数据源的支持比较少，很多nosql是不支持的。但是，估计是cloudera的国内市场推广做的不错，Impala在国内的市场不错。

SparkSQL

SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成，可以将结构化数据作为 Spark 的 RDD 进行查询。

SparkSQL后续不再受限于Hive，只是兼容Hive。

SparkSQL提供了sql访问和API访问的接口。

支持访问各式各样的数据源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。

Drill

Drill好像国内使用的很少，根据定义，Drill是一个低延迟的分布式海量数据交互式查询引擎，支持多种数据源，包括hadoop，NoSQL存储等等。

除了支持多种的数据源，Drill跟BI工具集成比较好。

Druid

Druid是专为海量数据集上的做高性能 OLAP而设计的数据存储和分析系统。

Druid 的架构是 Lambda 架构，分成实时层和批处理层。

Druid的核心设计结合了数据仓库，时间序列数据库和搜索系统的思想，以创建一个统一的系统，用于针对各种用例的实时分析。Druid将这三个系统中每个系统的关键特征合并到其接收层，存储格式，查询层和核心体系结构中。

目前 Druid 的去重都是非精确的，Druid 适合处理星型模型的数据，不支持关联 *** 作。也不支持数据的更新。

Druid最大的优点还是支持实时与查询功能，解约了很多开发工作。

Kudu

kudu是一套完全独立的分布式存储引擎，很多设计概念上借鉴了HBase，但是又跟HBase不同，不需要HDFS，通过raft做数据复制；分片策略支持keyrange和hash等多种。

数据格式在parquet基础上做了些修改，支持二级索引，更像一个列式存储，而不是HBase schema-free的kv方式。

kudu也是cloudera主导的项目，跟Impala结合比较好，通过impala可以支持update *** 作。

kudu相对于原有parquet和ORC格式主要还是做增量更新的。

Hbase

Hbase使用的很广,更多的是作为一个KV数据库来使用，查询的速度很快。

Hawq

Hawq是一个Hadoop原生大规模并行SQL分析引擎，Hawq采用 MPP 架构，改进了针对 Hadoop 的基于成本的查询优化器。

除了能高效处理本身的内部数据，还可通过 PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。HAWQ全面兼容 SQL 标准，还可用 SQL 完成简单的数据挖掘和机器学习。无论是功能特性，还是性能表现，HAWQ 都比较适用于构建 Hadoop 分析型数据仓库应用。

olap是联机分析处理，是共享多维信息的、针对特定问题的联机数据访问和分析的快速软件技术。它通过对信息的多种可能的观察形式进行快速、稳定一致和交互性的存取，允许管理决策人员对数据进行深入观察。

前言 在事务处理系统中的数据 主要用于记录和查询业务情况 随着数据仓库（DW）技术的不断成熟 企业的数据逐渐变成了决策的主要依据 数据仓库是一种面向决策主题 由多数据源集成 拥有当前及历史总结数据 以读为主的数据库系统 其目的是支持决策 数据仓库要根据决策的需要收集来自企业内外的有关数据 并加以适当的组织处理 使其能有效地为决策过程提供信息 数据仓库中的数据是从许多业务处理系统中抽取 转换而来 对于这样一个复杂的企业数据环境 如何以安全 高效的方式来对它们进行管理和访问就变得尤为重要 解决这一问题的关键是对元数据进行科学有效的管理 元数据是关于数据 *** 纵数据的进程和应用程序的结构和意义的描述信息 其主要目标是提供数据资源的全面指南 元数据不仅定义了数据仓库中数据的模式 来源以及抽取和转换规则等 而且整个数据仓库系统的运行都是基于元数据的 是元数据把数据仓库系统中的各个松散的组件联系起来 组成了一个有机的整体 本文首先介绍了元数据的定义 作用和意义 然后讨论了数据仓库系统中元数据管理的现状和关于元数据的标准化情况 最后提出了建立元数据管理系统的步骤和实施方法 元数据 元数据的概念按照传统的定义 元数据（Metadata）是关于数据的数据 在数据仓库系统中 元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据 元数据是描述数据仓库内数据的结构和建立方法的数据 可将其按用途的不同分为两类 技术元数据（Technical Metadata）和业务元数据（Business Metadata） 技术元数据是存储关于数据仓库系统技术细节的数据 是用于开发和管理数据仓库使用的数据 它主要包括以下信息 &# ; 数据仓库结构的描述 包括仓库模式 视图 维 层次结构和导出数据的定义 以及数据集市的位置和内容 &# ; 业务系统 数据仓库和数据集市的体系结构和模式 &# ; 汇总用的算法 包括度量和维定义算法 数据粒度 主题领域 聚集 汇总 预定义的查询与报告 &# ; 由 *** 作环境到数据仓库环境的映射 包括源数据和它们的内容 数据分割 数据提取 清理 转换规则和数据刷新规则 安全（用户授权和存取控制） 业务元数据从业务角度描述了数据仓库中的数据 它提供了介于使用者和实际系统之间的语义层 使得不懂计算机技术的业务人员也能够 读懂 数据仓库中的数据 业务元数据主要包括以下信息 使用者的业务术语所表达的数据模型 对象名和属性名 访问数据的原则和数据的来源 系统所提供的分析方法以及公式和报表的信息 具体包括以下信息 &# ; 企业概念模型 这是业务元数据所应提供的重要的信息 它表示企业数据模型的高层信息 整个企业的业务概念和相互关系 以这个企业模型为基础 不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数 &# ; 多维数据模型 这是企业概念模型的重要组成部分 它告诉业务分析人员在数据集市当中有哪些维 维的类别 数据立方体以及数据集市中的聚合规则 这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式 &# ; 业务概念模型和物理数据之间的依赖 以上提到的业务元数据只是表示出了数据的业务视图 这些业务视图与实际的数据仓库或数据库 多维数据库中的表 字段 维 层次等之间的对应关系也应该在元数据知识库中有所体现 元数据的作用在数据仓库系统中 元数据机制主要支持以下五类系统管理功能 （1）描述哪些数据在数据仓库中 （2）定义要进入数据仓库中的数据和从数据仓库中产生的数据 （3）记录根据业务事件发生而随之进行的数据抽取工作时间安排 （4）记录并检测系统数据一致性的要求和执行情况 （5）衡量数据质量 与其说数据仓库是软件开发项目 还不如说是系统集成项目[ ] 因为它的主要工作是把所需的数据仓库工具集成在一起 完成数据的抽取 转换和加载 OLAP分析和数据挖掘等 如图 所示 它的典型结构由 *** 作环境层 数据仓库层和业务层等组成 其中 第一层（ *** 作环境层）是指整个企业内有关业务的OLTP系统和一些外部数据源 第二层是通过把第一层的相关数据抽取到一个中心区而组成的数据仓库层 第三层是为了完成对业务数据的分析而由各种工具组成的业务层 图中左边的部分是元数据管理 它起到了承上启下的作用 具体体现在以下几个方面 &# ; 便于集成&# ; 提高系统的灵活性&# ; 保证数据的质量&# ; 帮助用户理解数据的意义 数据仓库元数据管理现状 元数据管理的主要任务有两个方面 一是负责存储和维护元数据库中的元数据 二是负责数据仓库建模工具 数据获取工具 前端工具等之间的消息传递 协调各模块和工具之间的工作 由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的 灵魂 正是由于元数据在整个数据仓库生命周期中有着重要的地位 各个厂商的数据仓库解决方案都提到了关于对元数据的管理 但遗憾的是对于元数据的管理 各个解决方案都没有明确提出一个完整的管理模式 它们提供的仅仅是对特定的局部元数据的管理 当前市场上与元数据有关的主要工具见图 如图 所示 与元数据相关的数据仓库工具大致可分为四类 数据抽取工具 把业务系统中的数据抽取 转换 集成到数据仓库中 如Ardent的DataStage CA（原Platinum）的Decision Base和ETI的Extract等 这些工具仅提供了技术元数据 几乎没有提供对业务元数据的支持 前端展现工具 包括OLAP分析 报表和商业智能工具等 如MicroStrategy的DSS Agent Cognos的PowerPlay Business Objects的BO 以及Brio等 它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图 进而对数据仓库中的数据进行多维分析 这些工具都提供了业务元数据与技术元数据相对应的语义层 建模工具 为非技术人员准备的业务建模工具 这些工具可以提供更高层的与特定业务相关的语义 如CA的ERwin Sy ase的PowerDesigner以及Rational的Rose等 元数据存储工具 元数据通常存储在专用的数据库中 该数据库就如同一个 黑盒子 外部无法知道这些工具所用到和产生的元数据是如何存储的 还有一类被称为元数据知识库（Metadata Repository）的工具 它们独立于其它工具 为元数据提供一个集中的存储空间 包括微软的Repository CA的Repository Ardent的MetaStage和Sybase的WCC等 元数据管理的标准化 没有规矩不成方圆 元数据管理之所以困难 一个很重要的原因就是缺乏统一的标准 在这种情况下 各公司的元数据管理解决方案各不相同 近几年 随着元数据联盟MDC（Meta Data Coalition）的开放信息模型OIM（Open Information Model）和OMG组织的公共仓库模型CWM（Common Warehouse Model）标准的逐渐完善 以及MDC和OMG组织的合并 为数据仓库厂商提供了统一的标准 从而为元数据管理铺平了道路 从元数据的发展历史不难看出 元数据管理主要有两种方法 ( ) 对于相对简单的环境 按照通用的元数据管理标准建立一个集中式的元数据知识库 ( ) 对于比较复杂的环境 分别建立各部分的元数据管理系统 形成分布式元数据知识库 然后 通过建立标准的元数据交换格式 实现元数据的集成管理 下面我们分别介绍数据仓库领域中两个最主要的元数据标准 MDC的OIM标准和OMG的CWM标准 MDC的OIM存储模型MDC成立于 年 是一个致力于建立与厂商无关的 不依赖于具体技术的企业元数据管理标准的非赢利技术联盟 该联盟有 多个会员 其中包括微软和IBM等著名软件厂商 年 月MDC接受了微软的建议 将OIM作为元数据标准 OIM的目的是通过公共的元数据信息来支持不同工具和系统之间数据的共享和重用 它涉及了信息系统（从设计到发布）的各个阶段 通过对元数据类型的标准描述来达到工具和知识库之间的数据共享 OIM所声明的元数据类型都采用统一建模语言UML（Universal Modeling Language）进行描述 并被组织成易于使用 易于扩展的多个主题范围（Subject Areas） 这些主题范围包括 &# ; 分析与设计（Analysis and Design） 主要用于软件分析 设计和建模 该主题范围又进一步划分为 UML包（Package） UML扩展包 通用元素（Generic Elements）包 公共数据类型（Common Data Types）包和实体关系建模（Entity Relationship Modeling）包等 &# ; 对象与组件（Object and Component） 涉及面向对象开发技术的方方面面 该主题范围只包含组件描述建模（Component Description Modeling）包 &# ; 数据库与数据仓库（Database and Warehousing） 为数据库模式管理 复用和建立数据仓库提供元数据概念支持 该主题范围进一步划分为 关系数据库模式（Relational Database Schema）包 OLAP模式（OLAP Schema）包 数据转换（Data Transformations）包 面向记录的数据库模式（Record Oriented Database Schema）包 XML模式（XML Schema）包和报表定义（Report Definitions）包等 &# ; 业务工程（Business Engineering） 为企业运作提供一个蓝图 该主题范围进一步划分为 业务目标（Business Goal）包 组织元素（Organizational Elements）包 业务规则（Business Rules）包 商业流程（Business Processes）包等 &# ; 知识管理（Knowledge Management） 涉及企业的信息结构 该主题范围进一步划分为 知识描述（Knowledge lishixinzhi/Article/program/Oracle/201311/18587

OLTP(on-linetransactionprocessing)翻译为联机事务处理。OLAP(On-LineAnalyticalProcessing)翻译为联机分析处理。

OLTP主要用来记录某类业务事件的发生，如购买行为，当行为产生后，系统会记录是谁在何时何地做了何事，这样的一行（或多行）数据会以增删改的方式在数据库中进行数据的更新处理 *** 作，要求实时性高、稳定性强、确保数据及时更新成功，像公司常见的业务系统如ERP，CRM，OA等系统都属于OLTP。

当数据积累到一定的程度，我们需要对过去发生的事情做一个总结分析时，就需要把过去一段时间内产生的数据拿出来进行统计分析，从中获取我们想要的信息，为公司做决策提供支持，这时候就是在做OLAP了。

因为OLTP所产生的业务数据分散在不同的业务系统中，而OLAP往往需要将不同的业务数据集中到一起进行统一综合的分析，这时候就需要根据业务分析需求做对应的数据清洗后存储在数据仓库中，然后由数据仓库来统一提供OLAP分析。所以我们常说OLTP是数据库的应用，OLAP是数据仓库的应用，下面用一张图来简要对比。

以上就是关于技术选型 - OLAP大数据技术哪家强全部的内容，包括:技术选型 - OLAP大数据技术哪家强、什么是olap、数据仓库和元数据管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！