大数据开发需要了解的几种语言

  • Hadoop
  • Spark
  • Storm

大数据平台应用六大知识点

一、 大数据中的数据仓库和Mpp数据库如何选型?

在Hadoop平台中,一般大家都把hive当做数据仓库的一种选择,而Mpp数据库的典型代表就是impala,presto。Mpp架构的数据库主要用于即席查询场景,暨对数据查询效率有较高要求的场景,而对数据仓库的查询效率要求无法做大MPP那样,所以更多地适用与离线分析场景。
Hadoop已经是大数据平台的实时标准,其中Hadoop生态中有数据仓库Hive,可以作为大数据平台的标准数据仓库,
对于面向应用的MPP数据库,可以选择MYCAT(mySql的分布式架构)或是impala(基于Hive和Hbase),包括对称式和非对称式两种分布式模式。

二、 大数据分析中的实时推荐是如何实现的?

实时推荐需要使用实时处理框架结合推荐算法,从而做到对数据的实时处理和推荐。实时处理框架有Storm、Flink、SparkStreaming,组件可以对接Kafka,获取实时流数据,在实时框架内部实现对数据的处理过程。
1、 实时推荐需要借助实时计算框架例如Spark或是Strom技术
2、 数据采集采用Flume+Kafka作为数据缓存和分发作用
3、 同时还需要有非常适合的实时推荐算法,例如基于用户画像的实时推荐,或是基于用户行为的实施推荐、或是对商品相识度的实施推荐等不同的算法

三、 对于数据治理,有何高效的处理方法或工具?

数据治理没有具体的工具和方法,这是一项浩大的工程,可能牵扯到每个部门,既有技术人员参与,又要有业务人员参与,关键时刻还要有领导进行决策。每个公司的数据情况不同,处理方法也不尽相同,基本的方法是有的,暨通过对数据的梳理(元数据、主数据),发现数据质量问题,再通过质量标准或组织协调的方式,对数据进行标准化处理的。

四、 大数据分析中针对日志分析的框架如何选型?

elk 常用组件, 上层业务封装还需要求其他组件完成
日志分析 elk + redis + mysql 热点数据 , 热点分析
等等, 看你的业务是什么模式和 开发人员偏好
现在免费且主流的均已采用Elastic公司的ELK框架,均为轻量级组件,且简单易用,从采集到界面展示几乎用不了多少时间即可搭建完毕,Kibana界面效果优异,包含地图、报表、检索、报警、监控等众多功能。

五、 请问在大数据平台搭建过后,大数据平台的运维监控主要关注哪些?

大数据平台的运维监控主要包括硬件和软件层面,具体如下:
1、 主机、网络、硬盘、内存、CPU等资源。
在拥有几十台以上的集群环境中,大量的数据计算对硬件尤其是硬盘的损耗是较大的,在大量计算中,网络也往往会成为一个瓶颈,这些都需要时刻关注。
2、 平台层面
主要监控平台各个组件的状态、负载情况,有异常及时报警。
3、 用户层面
大数据平台建设是为了服务公司内部广大用户的,所以资源既是共享的,又需要是隔离的,所以需要对用户对平台资源的使用情况做好监控,及时发现异常使用情况,防止对其他用户产生不良影响,影响正常业务开展。
大数据平台搭建后,运维监控的主要内容包括
1、 分布式架构的底层虚拟机的运行情况(CPU、内存、网络、硬盘等)
2、 各个组件(HDFS 、MR、 SPark 、Hive 、Hbase、 IMpla、FLume、 Spooq等)的运行状态和告警信息

六、 数据量大,数据类型繁杂的情况下,如何做性能保障?

如何保障大数据平台的处理性能,关键还是看应用场景和业务需求,不是每种业务都需要高性能。

1、 在类OLTP场景下,大数据平台有像HBase一样的组件,保证数据读写具有极高的性能和吞吐量。
2、 在OLAP场景下,大数据平台有像Impala、Kudu、Kylin、Druid这样引擎,通过内存或预计算的方式保证查询性能。
3、 在离线分析场景,有像Hive、Spark、Mapreduce这样的引擎,分布式处理海量数据,在这种场景下,性能和响应时间已无法做到保证。
1、 大数据的底层全部都是分布式架构,分布式架构具有很强的横向扩展能力,而且是使用廉价的PC服务器即可组件分布式架构,只有增加服务器数据,性能也可以横向扩展,
2、 另外大数据平台在数据处理方面也均是采用分布式处理技术(例如 MR、 Hive、 Hbase 、 HDFS)
3、 另外还有一些是基于内存的数据计算和处理架构Spark技术,大数据平台下对性能的要求没有和传统的交互式的响应不太一样,大数据分为实时和离线计算,实时计算要求响应时
间,离线计算对于响应时间没有太高的要求。

大数据的关键名词

Kafka 消息系统

https://zhuanlan.zhihu.com/p/163836793 Kafka是Apache旗下的一款分布式流媒体平台,Kafka是一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。 它最初由LinkedIn(领英)公司发布,使用Scala语言编写,与2010年12月份开源,成为Apache的顶级子项目。 它主要用于处理消费者规模网站中的所有动作流数据。动作指(网页浏览、搜索和其它用户行动所产生的数据)。
消息系统分类
我们知道常见的消息系统有Kafka、RabbitMQ、ActiveMQ等等,但是这些消息系统中所使用的消息模式如下两种:
Peer-to-Peer (Queue)
简称PTP队列模式,

  • Publish/Subscribe(Topic)
    简称发布/订阅模式。例如我微博有30万粉丝,我今天更新了一条微博,那么这30万粉丝都可以接收到我的微博更新,大家都可以消费我的消息。
  • Publish/Subscribe(Topic)
hadoop

hadoop有三个主要的核心组件:HDFS(分布式文件存储)、MAPREDUCE(分布式的计算)、YARN(资源调度),现在云计算包括大数据和虚拟化进行支撑。

Apache Hive Apache HBase

Apache Hive是一个构建在Hadoop基础设施之上的数据仓库。通过Hive可以使用HQL语言查询存放在HDFS上的数据。HQL是一种类SQL语言,这种语言最终被转化为Map/Reduce. 虽然Hive提供了SQL查询功能,但是Hive不能够进行交互查询–因为它只能够在Haoop上批量的执行Hadoop。
Apache HBase是一种Key/Value系统,它运行在HDFS之上。和Hive不一样,Hbase的能够在它的数据库上实时运行,而不是运行MapReduce任务。Hive被分区为表格,表格又被进一步分割为列簇。列簇必须使用schema定义,列簇将某一类型列集合起来(列不要求schema定义)。例如,“message”列簇可能包含:“to”, ”from” “date”, “subject”, 和”body”. 每一个 key/value对在Hbase中被定义为一个cell,每一个key由row-key,列簇、列和时间戳。在Hbase中,行是key/value映射的集合,这个映射通过row-key来唯一标识。Hbase利用Hadoop的基础设施,可以利用通用的设备进行水平的扩展。

两者的共同点:

1.hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储
两者的区别:
2.Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统,HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。
3.想象你在操作RMDB数据库,如果是全表扫描,就用Hive+Hadoop,如果是索引访问,就用HBase+Hadoop 。
4.Hive query就是MapReduce jobs可以从5分钟到数小时不止,HBase是非常高效的,肯定比Hive高效的多。
5.Hive本身不存储和计算数据,它完全依赖于HDFS和MapReduce,Hive中的表纯逻辑。
6.hive借用hadoop的MapReduce来完成一些hive中的命令的执行
7.hbase是物理表,不是逻辑表,提供一个超大的内存hash表,搜索引擎通过它来存储索引,方便查询操作。
8.hbase是列存储。所以Hbase可以对数据进行增改删等操作,但Hive是行的,只能追加数据。
9.hdfs作为底层存储,hdfs是存放文件的系统,而Hbase负责组织文件。
10.hive需要用到hdfs存储文件,需要用到MapReduce计算框架。

HDFS

Hadoop的核心组成部分HDFS文件系统

Spark

spark是一个用来实现快速,通用的集群计算平台
spark适用于各种各样原先需要多种不同的分布式平台的场景,包括批处理,迭代算法,交互式查询,流处理。通过在一个统一的框架下支持这些不同的计算,spark使我们可以简单而低耗地把各种处理流程整合在一起。
2.spark的用途
(1):数据科学任务
具备 SQL、统计、预测建模(机器学习)等方面的经验,以及一定的python,matlab,R语言能力的数据科学家对数据进行分析,以回答问题或发现一些潜在规律。
(2):数据处理任务
Spark 的另一个主要用例是针对工程师的。在这里,我们把工程师定义为使用 Spark 开发
生产环境中的数据处理应用的软件开发者。这些开发者一般有基本的软件工程概念,比如
封装、接口设计以及面向对象的编程思想,他们通常有计算机专业的背景,并且能使用工
程技术来设计和搭建软件系统,以实现业务用例。
Spark 为开发用于集群并行执行的程序提供了一条捷径。通过封装,Spark不需要开发者关注如何在分布式系统上编程这样的复杂问题,也无需过多关注网络通信和 程序容错性。
Spark已经为工程师提供了足够的接口来快速实现常见的任务,以及对应用 进行监视、审查和性能调优。其
3.spark简史
Spark 是由一个强大而活跃的开源社区开发和维护的,社区中的开发者们来自许许多多不 同的机构。如果你或者你所在的机构是第一次尝试使用
Spark,也许你会对 Spark 这个项 目的历史感兴趣。Spark 是于 2009 年作为一个研究项目在加州大学伯克利分校 RAD 实验
室(AMPLab 的前身)诞生。实验室中的一些研究人员曾经用过 Hadoop MapReduce。他 们发现 MapReduce
在迭代计算和交互计算的任务上表现得效率低下。因此,Spark 从一开
始就是为交互式查询和迭代算法设计的,同时还支持内存式存储和高效的容错机制。 2009 年,关于 Spark 的研究论文在学术会议上发表,同年
Spark 项目正式诞生。其后不久, 相比于 MapReduce,Spark 在某些任务上已经获得了 10 ~ 20 倍的性能提升。
2011 年,AMPLab 开始基于 Spark 开发更高层的组件,比如 Shark(Spark 上的 Hive)1 和 Spark
Streaming。这些组件和其他一些组件一起被称为伯克利数据分析工具栈(BDAS,
https://amplab.cs.berkeley.edu/software/)。 Spark 最早在 2010 年 3 月开源,并且在
2013 年 6 月交给了 Apache 基金会,现在已经成了 Apache 开源基金会的顶级项目。

4.spark的存储层次
Spark 不仅可以将任何 Hadoop 分布式文件系统(HDFS)上的文件读取为分布式数据集,
也可以支持其他支持 Hadoop 接口的系统,比如本地文件、亚马逊 S3、Cassandra、Hive、
HBase 等。我们需要弄清楚的是,Hadoop 并非 Spark 的必要条件,Spark 支持任何实现
了 Hadoop 接口的存储系统。Spark 支持的 Hadoop 输入格式包括文本文件、SequenceFile、
Avro、Parquet 等

5.spark核心概念简介
每个 Spark 应用都由一个**驱动器程序(driver program)**来发起集群上的各种并行操作。驱动器程序包含应用的 main 函数,并且定义了集群上的分布式数据集,还对这些分布式数据集应用了相关操作。驱动器程序通过一个 SparkContext 对象来访问 Spark。这个对象代表对计算集群的一个连接。shell 启动时已经自动创建了一个 SparkContext 对象,是一个叫作 sc 的变量。我们可以通过例 2-3 中的方法尝试输出 sc 来查看它的类型。

一旦有了 SparkContext,你就可以用它来创建 RDD。
要执行这些操作,驱动器程序一般要管理多个执行器(executor)节点。

除了交互式运行之外,Spark 也可以在 Java、Scala 或 Python 的独立程序中被连接使用。这与在 shell 中使用的主要区别在于你需要自行初始化 SparkContext。

spark与flink的区别

(1)设计理念
  1、Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。
  
  2、Flink是基于事件驱动的,是面向流的处理框架, Flink基于每个事件一行一行地流式处理,是真正的流式计算. 另外他也可以基于流来模拟批进行计算实现批处理。
(2)架构方面
  1、Spark在运行时的主要角色包括:Master、Worker、Driver、Executor。
  2、Flink 在运行时主要包含:Jobmanager、Taskmanager和Slot。

(3)任务调度
1、Spark Streaming 连续不断的生成微小的数据批次,构建有向无环图DAG,根据DAG中的action操作形成job,每个job有根据窄宽依赖生成多个stage。
  2、Flink 根据用户提交的代码生成 StreamGraph,经过优化生成 JobGraph,然后提交给 JobManager进行处理,JobManager 会根据 JobGraph 生成 ExecutionGraph,ExecutionGraph 是 Flink 调度最核心的数据结构,JobManager 根据 ExecutionGraph 对 Job 进行调度。

(4)时间机制

1、Spark Streaming 支持的时间机制有限,只支持处理时间。使用processing time模拟event time必然会有误差, 如果产生数据堆积的话,误差则更明显。

2、flink支持三种时间机制:事件时间,注入时间,处理时间,同时支持 watermark 机制处理迟到的数据,说明Flink在处理乱序大实时数据的时候,更有优势。

(5)容错机制

1、SparkStreaming的容错机制是基于RDD的容错机制,会将经常用的RDD或者对宽依赖加Checkpoint。利用SparkStreaming的direct方式与Kafka可以保证数据输入源的,处理过程,输出过程符合exactly once。

2、Flink 则使用两阶段提交协议来保证exactly once。

(6)吞吐量与延迟

1、spark是基于微批的,而且流水线优化做的很好,所以说他的吞入量是最大的,但是付出了延迟的代价,它的延迟是秒级;

2、而Flink是基于事件的,消息逐条处理,而且他的容错机制很轻量级,所以他能在兼顾高吞吐量的同时又有很低的延迟,它的延迟能够达到毫秒级;

storm简介、原理、概念

  1. 什么是storm
    Storm是Twitter开源的分布式实时大数据处理框架,被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍,比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等,大数据实时处理解决方案(流计算)的应用日趋广泛,目前已是分布式技术领域最新爆发点,而Storm更是流计算技术中的佼佼者和主流。

按照storm作者的说法,Storm对于实时计算的意义类似于Hadoop对于批处理的意义。Hadoop提供了map、reduce原语,使我们的批处理程序变得简单和高效。同样,Storm也为实时计算提供了一些简单高效的原语,而且Storm的Trident是基于Storm原语更高级的抽象框架,类似于基于Hadoop的Pig框架,让开发更加便利和高效。

  1. storm应用场景
    推荐系统(实时推荐,根据下单或加入购物车推荐相关商品)、金融系统、预警系统、网站统计(实时销量、流量统计,如淘宝双11效果图)、交通路况实时系统等等。
  2. storm的一些特性
  • 适用场景广泛: storm可以实时处理消息和更新DB,对一个数据量进行持续的查询并返回客户端(持续计算),对一个耗资源的查询作实时并行化的处理(分布式方法调用,即DRPC),storm的这些基础API可以满足大量的场景。
  • 可伸缩性高: Storm的可伸缩性可以让storm每秒可以处理的消息量达到很高。扩展一个实时计算任务,你所需要做的就是加机器并且提高这个计算任务的并行度 。Storm使用ZooKeeper来协调集群内的各种配置使得Storm的集群可以很容易的扩展。
  • 保证无数据丢失: 实时系统必须保证所有的数据被成功的处理。 那些会丢失数据的系统的适用场景非常窄, 而storm保证每一条消息都会被处理, 这一点和S4相比有巨大的反差。
  • 异常健壮: storm集群非常容易管理,轮流重启节点不影响应用。
  • 容错性好:在消息处理过程中出现异常, storm会进行重试
  • 语言无关性: Storm的topology和消息处理组件(Bolt)可以用任何语言来定义, 这一点使得任何人都可以使用storm.
  1. storm集群结构
    Nimbus 和Supervisors 之间所有的协调工作是通过 一个Zookeeper 集群。Nimbus进程和 Supervisors 进程是无法直接连接,并且是无状态的; 所有的状态维持在Zookeeper中或保存在本地磁盘上。意味着你可以 kill -9 Nimbus 或Supervisors 进程,而不需要做备份。这种设计导致storm集群具有令人难以置信的稳定性,并且无耦合。
  2. storm工作原理
    Nimbus 负责在集群分发的代码,topo只能在nimbus机器上提交,将任务分配给其他机器,和故障监测。
    Supervisor,监听分配给它的节点,根据Nimbus 的委派在必要时启动和关闭工作进程。 每个工作进程执行topology 的一个子集。一个运行中的topology 由很多运行在很多机器上的工作进程组成。
    在Storm中有对于流stream的抽象,流是一个不间断的无界的连续tuple,注意Storm在建模事件流时,把流中的事件抽象为tuple即元组
    Storm认为每个stream都有一个源,也就是原始元组的源头,叫做Spout(管口)
    处理stream内的tuple,抽象为Bolt,bolt可以消费任意数量的输入流,只要将流方向导向该bolt,同时它也可以发送新的流给其他bolt使用,这样一来,只要打开特定的spout再将spout中流出的tuple导向特定的bolt,bolt又对导入的流做处理后再导向其他bolt或者目的地。
    可以认为spout就是水龙头,并且每个水龙头里流出的水是不同的,我们想拿到哪种水就拧开哪个水龙头,然后使用管道将水龙头的水导向到一个水处理器(bolt),水处理器处理后再使用管道导向另一个处理器或者存入容器中。
    为了增大水处理效率,我们很自然就想到在同个水源处接上多个水龙头并使用多个水处理器,这样就可以提高效率。
    这是一张有向无环图,Storm将这个图抽象为Topology(拓扑),Topo就是storm的Job抽象概念,一个拓扑就是一个流转换图
    图中每个节点是一个spout或者bolt,每个spout或者bolt发送元组到下一级组件。
    而Spout到单个Bolt有6种流分组策略。
  3. Topology
    Storm将流中元素抽象为tuple,一个tuple就是一个值列表value list,list中的每个value可以是任意可序列化的类型。拓扑的每个节点都要说明它所发射出的元组的字段的name,其他节点只需要订阅该name就可以接收处理。
  4. storm相关概念
    Streams:消息流
    消息流是一个没有边界的tuple序列,而这些tuples会被以一种分布式的方式并行创建和处理。 每个tuple可以包含多列,字段类型可以是: integer, long, short, byte, string, double, float, boolean和byte array。 你还可以自定义类型 — 只要你实现对应的序列化器。
    Spouts:消息源
    Spouts是topology消息生产者。Spout从一个外部源(消息队列)读取数据向topology发出tuple。 消息源Spouts可以是可靠的也可以是不可靠的。一个可靠的消息源可以重新发射一个处理失败的tuple, 一个不可靠的消息源Spouts不会。
    Spout类的方法nextTuple不断发射tuple到topology,storm在检测到一个tuple被整个topology成功处理的时候调用ack, 否则调用fail。
    storm只对可靠的spout调用ack和fail。
    Bolts:消息处理者
    消息处理逻辑被封装在bolts里面,Bolts可以做很多事情: 过滤, 聚合, 查询数据库等。
    Bolts可以简单的做消息流的传递。复杂的消息流处理往往需要很多步骤, 从而也就需要经过很多Bolts。第一级Bolt的输出可以作为下一级Bolt的输入。而Spout不能有一级。
    Bolts的主要方法是execute(死循环)连续处理传入的tuple,成功处理完每一个tuple调用OutputCollector的ack方法,以通知storm这个tuple被处理完成了。当处理失败时,可以调fail方法通知Spout端可以重新发送该tuple。
    流程是: Bolts处理一个输入tuple, 然后调用ack通知storm自己已经处理过这个tuple了。storm提供了一个IBasicBolt会自动调用ack。
    Bolts使用OutputCollector来发射tuple到下一级Blot。
    一组形象的对比:

大数据需要了解的东西:

场景一、业务系统交互都需要依赖于数据库来进行数据存储,常见数据库有:

1、关系型数据库

关系型数据库,是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型数据库这一系列的行和列被称为表,一组表组成了数据库。常用关系型数据库有:Oracle,SQLServer,DB2,Mysql,TiDB

TiDB: 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP)的融合型分布式数据库产品

2、非关系型数据库

NoSQL最常见的解释是“non-relational”, “Not Only SQL”也被很多人接受。NoSQL仅仅是一个概念,泛指非关系型的数据库,区别于关系数据库,它们不保证关系数据的ACID特性,常见的有四种数据存储类型:

键值对存储(key-value),如Redis,整个数据库系统加载是在内存中进行,每秒可以进行10W次的读写操作,最常用来做缓存使用,但是价格一般比较贵。

文档存储(document store),典型的是MongoDB,MongoDB是一个基于分布式文件存储 的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案,常用来存储用户点评文本、文档文件

基于列的数据库(column-oriented),Hbase,基于列的数据库会将每一列分开单独存放,当查找一个数量较小的列的时候其查找速度是很快的。

图形数据库(graph database),应用图形理论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系,常见的图形数据库有Neo4j,HugeGraph,应用场景以数据血缘关系、知识图谱为主。

场景二、产品功能上线后,老板问你新版本功能上线后用户使用情况如何?你可能有分析师帮忙输出分析报告、或者有现成的数据产品可以直接查数据,你知道数据是怎么来的吗?

要拿到产品上线后的结果数据,首先要有埋点,否则是巧妇难为无米之炊,产品埋点后由Nginx服务器进行日志数据采集,再由Flume进行数据文件转发,到其他存储器,比如HDFS、HBASE,或Kafka,经过离线或实时ETL后,才可以被查询使用。数据采集环节主要用到:

3、Nginx

Nginx是一个http服务器(web服务器)Nginx是一款高性能的http服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,常用做静态内容服务和反向代理服务器,直面外来请求转发给后面的应用服务

4、Flume

是一个分布式、可靠、和高可用的海量日志聚合的系统,支持在系统中定制各类数据发送方,通过监控整个文件目录或者某一个特定文件,用于收集数据;同时Flume也 提供数据写到各种数据接受方(可定制)的能力,用于转发数据。Flume 的易用性在于通过读取配置文件,可以自动收集日志文件,在大数据处理及各种复杂的情况下,flume 经常被用来作为数据处理的工具。

场景三、数据分析和处理一般不会直接操作线上业务库,因为会影响线上服务的稳定性,通常是先把业务从库的数据同步到数仓后,再进行ETL清洗加工应用。此外,对于订单状态实时变更数据同步,会采用消息队列进行数据传输,

5、 数据集成

数据集成是把不同来源、格式数据在逻辑上或物理上有机地集中,实现异构数据源之间的数据同步和传输,是后期数据处理应用的前序步骤

6、 Sqoop

sqoop是连接关系型数据库和hadoop的桥梁,主要有两个方面(导入和导出):

A. 将关系型数据库的数据导入到Hadoop 及其相关的系统中,如 Hive和HBase

B. 将数据从Hadoop 系统里抽取并导出到关系型数据库

7、 ETL

英文Extract-Transform-Load的缩写,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL一词较常用在数据仓库,但其对象并不限于数据仓库

8、 数据仓库

Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合,为数据分析性报告和决策支持、数据智能应用而创建,按照数据时效可分为实时数仓和离线数仓。通常数仓解决方案是基于Hadoop组件构建。

9、 消息队列

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合、异步消息、流量削峰等问题。目前在生产环境,使用较多的消息队列有Kafka、MetaMQ、RocketMQ、Turbo Mq等。

10、 Kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。

场景四、数据加工处理完成后,会进行SQL查询、拖拽分析或可视化应用,这一过程主要是基于Hadoop生态各个组件构建的大数据解决方案来实现。

11、 Hadoop

Hadoop是在分布式服务器集群上存储海量数据并运行分布式分析应用的开源框架,是最常用的大数据软件架构,由一系列组件搭建而成。其核心部件是HDFS与MapReduce。

12、 HDFS

Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统(Distributed File System)。HDFS是一个高度容错性的系统,适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用,是大数文件存储工具。

13、 MapReduce

MapReduce是面向大数据并行处理的计算模型、框架和平台,是一个基于集群的高性能并行计算平台(Cluster Infrastructure)。它允许用市场上普通的商用服务器构成一个包含数十、数百至数千个节点的分布和并行计算集群。是利用SQL语句查询存储在HDFS文件系统上的计算查询引擎,可以处理超大数据量,缺点是执行map和reduce过程性能会比较慢。

14、 Hive

Hive是基于Hadoop构建的数据仓库分析系统,它提供了丰富的SQL查询方式来分析存储在HDFS中的数据:可以将结构化的数据文件映射为一张数据库表,并提供完整的SQL查询功能;可以将SQL语句转换为MapReduce任务运行,通过自己的SQL查询分析需要的内容,这套SQL简称Hive SQL

15、 Spark

Spark 是专为大规模数据处理而设计的快速通用的计算引擎。和Hadoop MapReduce类似的通用并行框架,Spark拥有Hadoop MapReduce所具有的优点,但不同于MapReduce的是——Job中间输出结果可以保存在内存中,从而不再需要读写HDFS,因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。换句话说,Spark 启用了内存分布数据集,内存计算下,Spark 比 Hadoop 快100倍。

16、 Presto

Presto是由 Facebook 推出的一个基于Java开发的开源分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。Presto本身并不存储数据,但是可以接入多种数据源,并且支持跨数据源的级联查询。

17、 Kudu

KUDU 是一个列式存储的存储引擎, kudu是一款介于hdfs和hbase之间的高速分布式列式存储数据库。兼具了hbase的实时性、hdfs的高吞吐,以及传统数据库的sql支持。作为一款实时、离线之间的存储系统。定位和spark在计算系统中的地位非常相似,是实时数仓建设的常用组件。

18、 YARN

Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一种新的 Hadoop 资源管理器,它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

19、 ZooKeeper

ZooKeeper是一个分布式的应用程序协调服务,是Hadoop和Hbase的重要组件。提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

20、 Kylin

Kylin为了解决大数据系统中TB级别数据的数据分析需求,它提供Hadoop/Spark之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,它能在亚秒内查询巨大的Hive表。其核心是预计算,计算结果存在HBase中。
场景五、数据可视化平台需要每日监控营收KPI指标趋势,并可以在页面进行维度切换选择,即时获取最新数据,这个时候虽然数据是T+1(今天可以查询昨天及更早数据),但页面响应需要秒级响应。通常用于可视化页面数据查询的引擎有:MySQL、Greenplum、ClickHouse、Kylin等

21、GreenPlum

Greenplum属于OLAP。是基于低成本的开放平台基础上提供强大的并行数据计算性能和海量数据管理能力。这个能力主要指的是并行计算能力,是对大任务、复杂任务的快速高效计算,可以处理的数据量比MySQL大

22、Clickhouse

ClickHouse开源列式数据库,主要用于数据分析(OLAP)领域,可以支持任意指标、任意维度并秒级给出反馈的大数据Ad-hoc查询,ClickHouse比Spark快了近10倍。适合海量数据实时导入实时查询,多维聚合分析
场景六、对于大促活动、例如淘宝双十一实时数据监控大屏,T+1的数据已经不能满足需求了,需要数据的实时处理,实时展示,这个时候会用到Storm、Flink,实时处理Kafka传输的业务数据。

23、 Storm

Storm是Twitter开源的分布式实时大数据处理框架,被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍,比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等

24、 Flink

Flink核心是一个流式的数据流执行引擎,其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制,优点是可以支持批流一体。
场景七、除了报表分析,产品和运营需要针对实时访问产品的用户,实时判断用户是否下过订单,针对新客派发大礼包,老客引导复购。此时会用到API接口,数据加工处理后,会推送到ES,或Kafka,提供API供业务拉取、或直接Kafka输出。

25、 Elasticsearch

Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用Elasticsearch的水平伸缩性,能使数据在生产环境变得更有价值