分享

数据中台系列(二):浅谈数据引擎及其应用场景

 昵称37263053 2019-03-23

曾在阿里从事过DBA、数仓、数据解决方案,主要经历了阿里去IOE和集团数据中台的研发落地,目前在数澜从事解决方案相关工作。

作为数据中台系列的入门科普篇,在上一讲中,我们着重帮各位同学厘清楚,究竟什么样的企业才真正需要数据中台?(需要补课的同学可以点击此处直达)而在今天的文章中,我们有必要先简单介绍下目前存在的数据引擎,便于大家对理解之后所讲的数据中台建设中的相关技术,提供一些基础。

以下内容摘录自互联网:

Hive(Hadoop 生态组件)

Hive 可以被认为是 MapReduce 的一个封装、包装。它的意义就是在业务分析中将用户容易编写、会写的 Sql 语言转换为复杂难写的 MapReduce 程序,从而大大降低 Hadoop 学习的门槛,让更多的用户可以利用 Hadoop 进行数据挖掘分析。

Spark

Spark 是基于内存计算的大数据并行计算框架。它基于内存计算,提高了在大数据环境下数据处理的实时性,同时保证了高容错性和高可伸缩性,允许用户将 Spark 部署在大量的廉价硬件之上,形成集群。

Spark 诞生于加州大学伯利克分校 AMPLab,AMPLab 开发以 Spark 为核心的 BDAS 时提出的目标是:One stack to rule them all,也就是说在一套软件栈内完成各种大数据分析任务。Spark 是 MapReduce 的替代方案,而且兼容 HDFS、Hive 等分布式存储层,可融入 Hadoop 的生态系统,以弥补缺失 MapReduce 的不足。

SparkSQL(Spark 生态组件)

SparkSQL 的前身是 Shark。为了给熟悉 RDBMS 但又不理解 MapReduce 的技术人员提供快速上手的工具,Hive 应运而生,它是当时唯一运行在 Hadoop上 的 SQL-on-Hadoop 工具。但是 MapReduce 计算过程中大量的中间磁盘落地过程消耗了大量的 I/O,降低的运行效率,为了提高 SQL-on-Hadoop 的效率,Shark 应运而生,但又因为 Shark 对于 Hive 的太多依赖(如采用 Hive 的语法解析器、查询优化器等等),2014 年 Spark 团队停止对 Shark 的开发,将所有资源放 SparkSQL 项目上。

Hive on Spark(Spark 生态组件)

Hive on Spark 是由 Cloudera 发起,由 Intel、MapR 等公司共同参与的开源项目,其目的是把 Spark 作为 Hive 的一个计算引擎,将 Hive 的查询作为 Spark 的任务提交到 Spark 集群上进行计算。通过该项目,可以提高 Hive 查询的性能,同时为已经部署了 Hive 或者 Spark 的用户提供了更加灵活的选择,从而进一步提高 Hive 和 Spark 的普及率。

Spark Streaming(Spark 生态组件)

Spark 是一个类似于 MapReduce 的分布式计算框架,其核心是弹性分布式数据集(RDD),提供了比 MapReduce 更丰富的模型,可以在快速在内存中对数据集进行多次迭代,以支持复杂的数据挖掘算法和图形计算算法。Spark Streaming 是一种构建在 Spark 上的实时计算框架,它扩展了 Spark 处理大规模流式数据的能力。

Apache Flink

一个面向数据流处理和批量数据处理的可分布式的开源计算框架,它基于同一个 Flink 流式执行模型(Streaming execution model),能够支持流处理和批处理两种应用类型。由于流处理和批处理所提供的 SLA(服务等级协议)完全不相同, 流处理一般需要支持低延迟、Exactly-Once 保证,而批处理需要支持高吞吐、高效处理,所以在实现的时候通常是分别给出两套实现方法,或者通过一个独立的开源框架来实现其中每一种处理方案。比较典型的:实现批处理的开源方案有 MapReduce、Spark;实现流处理的开源方案有 Storm;Spark 的 Streaming 其实本质上也是微批处理。

Flink 在实现流处理和批处理时,与传统的一些方案完全不同,它从另一个视角看待流处理和批处理,将二者统一起来:Flink 是完全支持流处理,也就是说作为流处理看待时输入数据流是无界的;批处理被作为一种特殊的流处理,只是它的输入数据流被定义为有界的。

Impala

Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互 SQL 大数据查询工具。Impala 没有再使用缓慢的 Hive MapReduce 批处理,而是通过使用与商用并行关系数据库中类似的分布式查询引擎(由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成),可以直接从 HDFS 或 HBase 中用 SELECT、JOIN 和统计函数查询数据,从而大大降低了延迟。其架构如图 1所示,Impala 主要由 Impalad,State Store,Impala Catalog Service 和 CLI 组成。

Phoenix

是构建在 HBase 之上的关系型数据库层,作为内嵌的客户端 JDBC 驱动用以对 HBase 中的数据进行低延迟访问。Apache Phoenix 会将用户编写的 Sql 查询编译为一系列的 scan 操作,最终产生通用的 JDBC 结果集返回给客户端。数据表的元数据存储在 HBase 的表中被会标记版本号,所以进行查询的时候会自动选择正确的 Schema。直接使用 HBase 的 API,结合协处理器(Coprocessor)和自定义的过滤器的话,小范围的查询在毫秒级响应,千万数据的话响应速度为秒级。

(以上内容摘录于互联网)


有了基本的概念,我们用一张图来熟悉下什么是实时计算离线计算即席查询(Ad Hoc)和实时查询

备注:即席查询(Ad Hoc)是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计数据。

总结一下:

下面列举典型的两个场景:


场景一
报表相关需求

需求:BI 报表需求,需要从多个业务库抽取数据清洗加工成指标,最终利用可视化工具进行展示,每天早上能看到昨天的数据即可。

离线计算 实时查询:如 Hive 和 Mysql 是最常见的搭配。


需求:在以上基础上,需要动态调整查询条件,从而动态展示满足条件的报表数据。

离线计算 即席查询(动态条件) 实时查询(无动态条件):如 Hive、Impala 是比较常见的搭配。


需求:在以上的基础上,需要对多个指标的更新做到准实时

实时计算 离线计算 即席查询(动态条件) 实时查询(无动态条件):如Spark/Flink 、Hive、Impala是比较常见的搭配。


场景二
画像相关需求

需求:用户个人画像需求,需要从多个业务库抽取数据清洗加工成标签,最终由决策类工具透出使用,用户规模在几亿级别。

离线计算 实时查询:如Hive Phoenix ,如果具备 Mysql 分库分表中间件,Hive Mysql(分库分表中间件)。


需求:在以上基础上,需求根据条件自由圈定人群,然后定时推送到通知中心。

离线计算 实时查询 即席查询:如 Hive Phoenix Impala


需求:在以上基础上,需求对指定人群(运营人员上传)做人群透视需求。

离线计算 实时查询 即席查询:如 Hive Phoenix Impala


以上两个场景是企业大数据建设当中常见的需求,从这里可以看出,仅是熟悉各个组件,把数据流程串起来就已经非常费劲了,更不用说在此基础上去做好数据治理(元数据,数据血缘和数据质量等)。

所以,企业需要一个统一的平台来满足离线/实时计算需求,各种查询需求(实时查询和 ad hoc),同时,在将来新数据引擎(更快的计算框架,更快的查询响应)出现时,又不需要重构目前的大数据建设。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多