![](https://img-blog.csdnimg.cn/20201014180756923.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
大规模数据处理
文章平均质量分 94
大规模数据处理
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
38 | 大规模数据处理在深度学习中如何应用?
今天要与你分享的主题是“大规模数据处理在深度学习中如何应用?“深度学习”这个词,既是一个人工智能的研究领域,也概括了构建人工神经网络的技术方法。2012 年的 AlexNet,2015 年的 Google Inception V3 级数式地打破 ImageNet 计算机视觉比赛的最高纪录,2017 年亮相的 AlphaGo 更是掀起了全球的深度学习风暴。在 Google,深度学习系统被应用在预测广告的点击率、推荐用户可能喜爱的视频、生成更接近人类的机器发声、自动生成邮件回复等几乎所有产品线。原创 2024-07-12 19:19:36 · 682 阅读 · 0 评论 -
37 | 5G时代,如何处理超大规模物联网数据
物联网(Internet of Things)应该是一个你经常听说的名词,不过,你真的了解它吗?让我先来简要介绍一下什么是物联网吧。你可以将物联网的功能看作“使用嵌入在物理环境中的网络连接设备,来改进现有流程,或启用以前无法实现的新场景”。这些设备或事物连接到网络后,可以提供它们使用传感器从环境中收集的信息,或允许其他系统通过执行器连接,并作用于现实世界。原创 2024-07-12 11:22:20 · 1002 阅读 · 0 评论 -
36 | Facebook游戏实时流处理Beam Pipeline实战(下)
在上一讲中,我们一起对怎样实现一个简易的游戏积分排行榜展开了讨论,也一起研究了如何使用批处理计算的方式在 Beam 中构建出一个数据流水线来得出排行榜结果。我们知道,虽然批处理计算可以得到一个完整的结果,但是它也存在着自身的不足,比如会有一定的延时,需要额外的 crontab 来管理定时任务,增加了维护成本等等。所以在上一讲的末尾,我们提出了使用实时流处理来改进这些不足,而其中就需要用到窗口、触发器和累加模式这几个概念。原创 2024-07-12 10:31:17 · 643 阅读 · 0 评论 -
35 | Facebook游戏实时流处理Beam Pipeline实战(上)
今天要与你分享的主题是“Facebook 游戏实时流处理 Beam Pipeline 实战”。Facebook 这个社交平台我相信你一定早有耳闻。它除了能够让用户发送消息给好友,分享自己的动态图片和视频之外,还通过自身的 App Center 管理着各式各样的小游戏。许多游戏开发商借助 Facebook 的好友邀请机制让自己的 App 火了一把。曾经有一段时间,在 Facebook 上有一款名为糖果传奇(Candy Crush Saga)的游戏风靡了整个北美。原创 2024-07-11 10:56:09 · 440 阅读 · 0 评论 -
34 | Amazon热销榜Beam Pipeline实战
今天要与你分享的主题是“Amazon 热销榜 Beam Pipeline 实战”。亚马逊(Amazon)宣布将关闭中国国内电商业务的消息你一定还记忆犹新。虽然亚马逊遗憾离场,但它依然是目前全球市值最高的电商公司。作为美国最大的一家网络电子商务公司,亚马逊的总部位于华盛顿州的西雅图。类似于 BAT 在国内的地位,亚马逊也是北美互联网 FAANG 五大巨头之一,其他四个分别是 Facebook、Apple、Netflix 和 Google。亚马逊的热销商品系统就如下图所示。原创 2024-07-10 11:18:07 · 848 阅读 · 0 评论 -
33 | 横看成岭侧成峰:再战Streaming WordCount
今天要与你分享的主题是“横看成岭侧成峰:再战 Streaming WordCount”。在上一讲中,我们学习了 Beam 窗口(Window)的概念。当时,我们提到窗口技术的产生是因为我们想要根据时间戳去分组处理一个 PCollection 中的元素。我们也提到了在“统计莎士比亚文集词频”这个例子中,如果莎士比亚穿越到了现代,成了一名专栏作家,我们就可能需要根据他文章的写作时间来统计词频了。举个具体的例子的话,就是我们能不能灵活地得到莎士比亚在 2017 年 9 月使用的高频词汇?原创 2024-07-09 11:09:42 · 900 阅读 · 0 评论 -
32 | Beam Window:打通流处理的任督二脉
今天要与你分享的主题是“Beam Window:打通流处理的任督二脉”。在上一讲中,我们一起用 Beam 编写了第一个完整的 WordCount 项目,我们所用的例子是统计莎士比亚的文集中最常使用到的一些单词。这里我们所用到的“莎士比亚文集”这种类型的数据集是一个静态的数据集。也就是说,我们在生成输入数据集的时候,就已经知道了这个数据集是完整的,并不需要再等待新的数据进来。根据前面的内容,我们可以把这种数据集归类为有界数据集(Bounded Dataset)。原创 2024-07-08 11:21:11 · 733 阅读 · 0 评论 -
31 | WordCount Beam Pipeline实战
今天要与你分享的主题是“WordCount Beam Pipeline 实战”。前面我们已经学习了 Beam 的基础数据结构 PCollection,基本数据转换操作 Transform,还有 Pipeline 等技术。你一定跃跃欲试,想要在实际项目中使用了。这一讲我们就一起学习一下怎样用 Beam 解决数据处理领域的教科书级案例——WordCount。WordCount 你一定不陌生,在第 18 讲中,我们就已经接触过了。WordCount 问题是起源于 MapReduce 时代就广泛使用的案例。原创 2024-07-05 14:47:53 · 718 阅读 · 0 评论 -
30 | Apache Beam实战冲刺:Beam如何run everywhere?
今天要与你分享的主题是“Apache Beam 实战冲刺:Beam 如何 run everywhere”。你可能已经注意到,自第 26 讲到第 29 讲,从 Pipeline 的输入输出,到 Pipeline 的设计,再到 Pipeline 的测试,Beam Pipeline 的概念一直贯穿着文章脉络。那么这一讲,我们一起来看看一个完整的 Beam Pipeline 究竟是如何编写的。原创 2024-07-05 11:53:44 · 593 阅读 · 0 评论 -
29 | 如何测试Beam Pipeline?
今天要与你分享的主题是“如何测试 Beam Pipeline”。在上一讲中,我们结合了第 7 讲的内容,一起学习了在 Beam 的世界中我们该怎么设计好对应的设计模式。而在今天这一讲中,我想要讲讲在日常开发中经常会被忽略的,但是又非常重要的一个开发环节——测试。你知道,我们设计好的 Beam 数据流水线通常都会被放在分布式环境下执行,具体每一步的 Transform 都会被分配到任意的机器上面执行。如果我们在运行数据流水线时发现结果出错了,那么想要定位到具体的机器,再到上面去做调试是不现实的。原创 2024-07-05 11:06:57 · 620 阅读 · 0 评论 -
28 | 如何设计创建好一个Beam Pipeline?
今天要与你分享的主题是“如何设计创建好一个 Beam Pipeline”。这一讲我们会用到第 7 讲中介绍过的四种常见设计模式——复制模式、过滤模式、分离模式和合并模式。这些设计模式就像是武功的基本套路一样,在实战中无处不在。今天,我们就一起来看看我们怎么用 Beam 的 Pipeline 来实现这些设计模式。原创 2024-07-05 09:33:13 · 714 阅读 · 0 评论 -
27 | Pipeline I/O: Beam数据中转的设计模式
自定义的 I/O 连接器并不是说一定要设计得非常通用,而是只要能够满足自身的应用需求就可以了。实现自定义的 I/O 连接器,通常指的就是实现 Read Transform 和 Write Transform 这两种操作,这两种操作都有各自的实现方法,下面我以 Java 为编程语言来一一为你解释。我们知道 Beam 可以读取无界数据集也可以读取有界数据集,而读取这两种不同的数据集是有不同的实现方法的。原创 2024-07-05 08:59:35 · 853 阅读 · 0 评论 -
26 | Pipeline:Beam如何抽象多步骤的数据流水线?
今天要与你分享的主题是“Pipeline:Beam 如何抽象多步骤的数据流水线”。在上两讲中,我们一起学习了 Beam 是如何抽象封装数据,以及如何抽象对于数据集的转换操作的。在掌握了这两个基本概念后,我们就可以很好地回答 Beam 编程模型里的 4 个维度 What、Where、When、How 中的第一个问题——What 了。也就是,我们要做什么计算?想得到什么样的结果?这个时候你可能已经跃跃欲试,开始想用 PCollection 和 Transform 解决我们平常经常会使用到的批处理任务了。原创 2024-07-04 17:54:04 · 910 阅读 · 0 评论 -
25 | Transform:Beam数据转换操作的抽象方法
今天要与你分享的主题是“Beam 数据转换操作的抽象方法”。在上一讲中,我们一起学习了 Beam 中数据的抽象表达——PCollection。但是仅仅有数据的表达肯定是无法构建一个数据处理框架的。那么今天,我们就来看看 Beam 中数据处理的最基本单元——Transform。下图就是单个 Transform 的图示。之前我们已经讲过,Beam 把数据转换抽象成了有向图。PCollection 是有向图中的边,而 Transform 是有向图里的节点。原创 2024-07-04 15:46:21 · 761 阅读 · 0 评论 -
24 | PCollection:为什么Beam要如此抽象封装数据?
今天要与你分享的主题是“为什么 Beam 要如此抽象封装数据”。很多人在刚开始接触 Apache Beam 的时候,都会觉得这里面的概念太抽象了。什么 PCollection、PValue、Transform……这都是些什么?尤其是 PCollection,完全和先前的技术知识找不到对应。确实如此。同样作为数据的容器,PCollection 却并不像 Python/Java 的 List 或者 C++ 的 vector。PCollection 是无序的。原创 2024-07-04 14:46:57 · 834 阅读 · 0 评论 -
23 | 站在Google的肩膀上学习Beam编程模型
今天要与你分享的话题是“站在 Google 的肩膀上学习 Beam 编程模型”。在上一讲中,带你一起领略了 Apache Beam 的完整诞生历史。通过上一讲,你应该对于 Apache Beam 在大规模数据处理中能够带来的便利有了一定的了解。而在这一讲中,让我们一起来学习 Apache Beam 的编程模型,帮助你打下良好的基础以便应对接下来的 Beam 实战篇。希望你在以后遇到不同的数据处理问题时,可以有着 Beam 所提倡的思考模式。现在让我们一起进入 Beam 的世界吧。原创 2024-07-04 11:24:17 · 1049 阅读 · 0 评论 -
22 | Apache Beam的前世今生
今天要与你分享的主题是“ Apache Beam 的前世今生”。从这一讲开始,我们将进入一个全新的篇章。在这一讲中,我将会带领你了解 Apache Beam 的完整诞生历程。让我们一起来感受一下,Google 是如何从处理框架上的一无所有,一直发展到推动、制定批流统一的标准的。除此之外,我还会告诉你,在 2004 年发布了 MapReduce 论文之后,Google 在大规模数据处理实战中到底经历了哪些技术难题和技术变迁。原创 2024-07-04 10:44:47 · 701 阅读 · 0 评论 -
21 | 深入对比Spark与Flink:帮你系统设计两开花
Flink 中最核心的数据结构是 Stream,它代表一个运行在多个分区上的并行流。在 Stream 上同样可以进行各种转换操作(Transformation)。与 Spark 的 RDD 不同的是,Stream 代表一个数据流而不是静态数据的集合。所以,它包含的数据是随着时间增长而变化的。而且 Stream 上的转换操作都是逐条进行的,即每当有新的数据进来,整个流程都会被执行并更新结果。这样的基本处理模式决定了 Flink 会比 Spark Streaming 有更低的流处理延迟性。原创 2024-07-03 17:19:32 · 673 阅读 · 0 评论 -
20 | 流处理案例实战:分析纽约市出租车载客信息
今天的数据集是纽约市 2009~2015 年出租车载客的信息。每一次出行包含了两个事件,一个事件代表出发,另一个事件代表到达。每个事件都有 11 个属性,它的 schema 如下所示:这部分数据有个不太直观的地方,那就是同一次出行会有两个记录,而且代表出发的事件没有任何意义,因为到达事件已经涵盖了所有必要的信息。现实世界中的数据都是这样复杂,不可能像学校的测试数据一样简单直观,所以处理之前,我们要先对数据进行清洗,只留下必要的信息。原创 2024-07-03 16:46:36 · 668 阅读 · 0 评论 -
19 | 综合案例实战:处理加州房屋信息,构建线性回归模型
为了完成今天的综合案例实战,使用的是美国加州 1990 年房屋普查的数据集。数据集中的每一个数据都代表着一块区域内房屋和人口的基本信息,总共包括 9 项:1. 该地区中心的纬度(latitude)2. 该地区中心的经度(longitude)3. 区域内所有房屋屋龄的中位数(housingMedianAge)4. 区域内总房间数(totalRooms)5. 区域内总卧室数(totalBedrooms)6. 区域内总人口数(population)7. 区域内总家庭数(households)原创 2024-07-03 15:46:23 · 1308 阅读 · 0 评论 -
18 | Word Count:从零开始运行你的第一个Spark应用
今天我们来从零开始运行第一个 Spark 应用。我们先来回顾一下模块三的学习路径。首先,我们由浅入深地学习了 Spark 的基本数据结构 RDD,了解了它这样设计的原因,以及它所支持的 API。之后,我们又学习了 Spark SQL 的 DataSet/DataFrame API,了解到它不仅提供类似于 SQL query 的接口,大大提高了开发者的工作效率,还集成了 Catalyst 优化器,可以提升程序的性能。这些 API 应对的都是批处理的场景。原创 2024-07-03 15:06:34 · 724 阅读 · 0 评论 -
17 | Structured Streaming:如何用DataFrame API进行实时数据分析?
上一讲中,我们介绍了 Spark 中的流处理库 Spark Streaming。它将无边界的流数据抽象成 DStream,按特定的时间间隔,把数据流分割成一个个 RDD 进行批处理。所以,DStream API 与 RDD API 高度相似,也拥有 RDD 的各种性质。在第 15 讲中,我们比较过 RDD 和 DataSet/DataFrame。你还记得 DataSet/DataFrame 的优点吗?你有没有想过,既然已经有了 RDD API,我们为什么还要引入 DataSet/DataFrame 呢?原创 2024-07-03 11:26:34 · 795 阅读 · 0 评论 -
16 | Spark Streaming:Spark的实时流计算API
今天要与你分享的内容是“Spark Streaming”。通过上一讲的内容,我们深入了解了 Spark SQL API。通过它,我们可以像查询关系型数据库一样查询 Spark 的数据,并且对原生数据做相应的转换和动作。但是,无论是 DataFrame API 还是 DataSet API,都是基于批处理模式对静态数据进行处理的。比如,在每天某个特定的时间对一天的日志进行处理分析。在第二章中你已经知道了,批处理和流处理是大数据处理最常见的两个场景。原创 2024-07-03 10:54:11 · 928 阅读 · 0 评论 -
15 | Spark SQL:Spark数据查询的利器
上一讲中,介绍了弹性分布式数据集的特性和它支持的各种数据操作。不过在实际的开发过程中,我们并不是总需要在 RDD 的层次进行编程。就好比编程刚发明的年代,工程师只能用汇编语言,到后来才慢慢发展出高级语言,如 Basic、C、Java 等。使用高级语言大大提升了开发者的效率。同样的,Spark 生态系统也提供很多库,让我们在不同的场景中使用。今天,让我们来一起探讨 Spark 最常用的数据查询模块——Spark SQL。原创 2024-07-03 09:53:13 · 577 阅读 · 0 评论 -
14 | 弹性分布式数据集:Spark大厦的地基(下)
上一讲我们介绍了弹性分布式数据集(RDD)的定义、特性以及结构,并且深入讨论了依赖关系(Dependencies)。今天让我们一起来继续学习 RDD 的其他特性。原创 2024-07-02 17:11:11 · 590 阅读 · 0 评论 -
13 | 弹性分布式数据集:Spark大厦的地基(上)
弹性分布式数据集是英文直译的名字,乍一看这个名字相信你会不知所云。RDD 表示已被分区、不可变的,并能够被并行操作的数据集合。这个定义很不直观,我认识的很多 Spark 初学者在查阅了很多资料后还是对 RDD 一头雾水,很难理解这个抽象的概念。接下来,让我们一起来对这个晦涩的概念抽丝剥茧,见其真义。在上述定义以及 RDD 的中文译名中,我们不难发现,RDD 有以下基本特性:分区、不可变和并行操作。接下来让我分别讲解这些特点。原创 2024-07-02 16:28:31 · 722 阅读 · 0 评论 -
12 | 我们为什么需要Spark?
今天我要与你分享的主题是“我们为什么需要 Spark”。也许你之前没有做过大规模数据处理的项目,但是 Spark 这个词我相信你一定有所耳闻。Spark 是当今最流行的分布式大规模数据处理引擎,被广泛应用在各类大数据处理场景。2009 年,美国加州大学伯克利分校的 AMP 实验室开发了 Spark。2013 年,Spark 成为 Apache 软件基金会旗下的孵化项目。而现在,Spark 已经成为了该基金会管理的项目中最活跃的一个。原创 2024-07-02 14:42:02 · 629 阅读 · 0 评论 -
11 | Kappa架构:利用Kafka锻造的屠龙刀
今天要分享的主题是 Kappa 架构。同样身为大规模数据处理架构,Kappa 架构这把利用 Kafka 锻造的“屠龙刀”,它与 Lambda 架构的不同之处在哪里呢?上一讲中,讲述了在处理大规模数据时所用到经典架构,Lambda 架构。先来带你简要回顾一下。Lambda 架构结合了批处理和流处理的架构思想,将进入系统的大规模数据同时送入这两套架构层中,分别是批处理层(Batch Layer)和速度层(Speed Layer),同时产生两套数据结果并存入服务层。原创 2024-07-02 11:28:40 · 654 阅读 · 0 评论 -
10 | Lambda架构:Twitter亿级实时数据分析架构背后的倚天剑
今天要与你分享的主题是 Lambda 架构。通过这一讲,你可以了解什么是 Lambda 架构,以及它为什么能够成为 Twitter 亿级实时数据分析架构背后的“倚天剑”。在学习了架构师的必备技能后,你是否已经摩拳擦掌,跃跃欲试地想要上手一个实际项目了呢?没问题,我们一起来看一个我的架构经历里的真实项目。情况是这样的,我们正运行着广告精准投放业务,并且拥有海量的用户网站访问行为。我们需要进行用户行为分析来建立一个模型,然后根据这个模型来投放用户喜好的广告。你可能想到了批处理架构。原创 2024-07-02 10:20:41 · 558 阅读 · 0 评论 -
09 | CAP定理:三选二,架构师必须学会的取舍
今天要与你分享的主题是 CAP 定理。在分布式系统的两讲中,我们一起学习到了两个重要的概念:可用性和一致性。而今天,想和你讲解一个与这两个概念相关,并且在设计分布式系统架构时都会讨论到的一个定理——原创 2024-07-02 09:04:38 · 715 阅读 · 0 评论 -
08 | 发布/订阅模式:流处理架构中的瑞士军刀
今天想要与你分享的是在处理大规模数据中十分流行的一种设计模式:发布 / 订阅模式(Publish/Subscribe Pattern),有些地方也称它为 Pub/Sub。在了解发布 / 订阅模式之前,我想先简单介绍几个基础概念——消息(Message)和消息队列(Message Queue)。原创 2024-07-01 17:37:53 · 563 阅读 · 0 评论 -
07 | Workflow设计模式:让你在大规模数据世界中君临天下
今天要与你分享的主题是“Workflow 设计模式”。在上一讲中,我们一起学习了大规模数据处理的两种处理模式——批处理和流处理。利用好这两种处理模式,作为架构师的你就可以运筹帷幄,根据实际需求搭建出一套符合自己应用的数据处理系统。然而,光是掌握了这两种数据处理模式就足够自如应对大规模数据世界中的需求挑战吗?从我的实战经验中看来,其实未必。我们每个人在最开始学习大规模数据处理的时候,可能都是以 WordCount 作为教学例子来进行学习的。原创 2024-07-01 16:25:37 · 837 阅读 · 0 评论 -
06 | 如何区分批处理还是流处理?
今天,将会带领你一起学习在进行大规模数据处理时,无论如何也绕不开的两个处理模式:批处理(Batching Processing)和流处理(Streaming Processing)。在我看来,大规模的视频流系统、大规模物联网(IoT)数据监控系统等各种现代大规模数据系统的出现,已经成为了一种必然的历史潮流。无论你是在从事哪一种开发方向,都不可避免地要与这些海量数据打交道。如何能既满足实际应用场景的需求,又高效地处理好大规模数据,在整个项目开发架构中都是非常重要的一个环节。原创 2024-07-01 15:38:31 · 601 阅读 · 0 评论 -
05 | 分布式系统(下):架构师不得不知的三大指标
上一讲中,我们学习了如何用服务等级协议(SLA)来评估我们设计的分布式系统,并了解了几个常见的 SLA 指标。今天我们继续来探索分布式系统的另外几个重要基础概念。原创 2024-07-01 14:32:29 · 845 阅读 · 0 评论 -
04 | 分布式系统(上):学会用服务等级协议SLA来评估你的系统
从今天开始,我们进入专栏的第二模块。通过这一模块的学习,带你一起夯实大规模数据处理的基础。首先,我将结合硅谷顶尖科技公司的(Best Practice) ,和你一起分享在设计分布式系统架构时,我们有可能会碰到哪些雷区?又有哪些必备的基础知识?在硅谷一线大厂所维护的系统服务中,我们经常可以看见 SLA 这样的承诺。例如,在谷歌的云计算服务平台 Google Cloud Platform 中,他们会写着“99.9% Availability”这样的承诺。那什么是“99.9% Availability”呢。原创 2024-07-01 11:50:02 · 546 阅读 · 0 评论 -
03 | 大规模数据处理初体验:怎样实现大型电商热销榜?
今天要与你分享的主题是“怎样实现大型电商热销榜”。在 Google 面试过很多优秀的候选人,应对普通的编程问题 coding 能力很强,算法数据结构也应用得不错。可是当我追问数据规模变大时该怎么设计系统,他们却说不出所以然来。这说明他们缺乏必备的规模增长的技术思维(mindset of scaling)。这会限制这些候选人的职业成长。因为产品从 1 万用户到 1 亿用户,技术团队从 10 个人到 1000 个人,你的技术规模和数据规模都会完全不一样。原创 2024-07-01 10:54:28 · 830 阅读 · 0 评论 -
02 | MapReduce后谁主沉浮:怎样设计下一代数据处理技术?
在上一讲中,我们介绍了 2014 年之前的大数据历史,也就是 MapReduce 作为数据处理的默认标准的时代。重点探讨了 MapReduce 面对日益复杂的业务逻辑时表现出的不足之处,那就是:1. 维护成本高;2. 时间性能不足。同时,我们也提到了 2008 年诞生在 Google 西雅图研发中心的 FlumeJava,它成为了 Google 内部的数据处理新宠。那么,为什么是它扛起了继任 MapReduce 的大旗呢?原创 2024-07-01 10:18:29 · 582 阅读 · 0 评论 -
01 | 为什么MapReduce会被硅谷一线公司淘汰?
今天我要与你分享的主题是“为什么 MapReduce 会被硅谷一线公司淘汰”。我有幸几次与来 Google 参观的同行进行交流,当谈起数据处理技术时,他们总是试图打探 MapReduce 方面的经验。这一点让我颇感惊讶,因为在硅谷,早已没有人去谈论 MapReduce 了。今天这一讲,我们就来聊聊为什么 MapReduce 会被硅谷一线公司淘汰。我们先来沿着时间线看一下超大规模数据处理的重要技术以及它们产生的年代。我认为可以把超大规模数据处理的技术发展分为三个阶段:石器时代,青铜时代,蒸汽机时代。原创 2024-07-01 09:44:52 · 792 阅读 · 0 评论