大规模数据处理实战
蔡元楠
Google Brain资深工程师
立即订阅
8443 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从这里开始,带你走上硅谷一线系统架构师之路
免费
模块一 | 直通硅谷大规模数据处理技术 (3讲)
01 | 为什么MapReduce会被硅谷一线公司淘汰?
02 | MapReduce后谁主沉浮:怎样设计下一代数据处理技术?
03 | 大规模数据处理初体验:怎样实现大型电商热销榜?
模块二 | 实战学习大规模数据处理基本功 (8讲)
04 | 分布式系统(上):学会用服务等级协议SLA来评估你的系统
05 | 分布式系统(下):架构师不得不知的三大指标
06 | 如何区分批处理还是流处理?
07 | Workflow设计模式:让你在大规模数据世界中君临天下
08 | 发布/订阅模式:流处理架构中的瑞士军刀
09 | CAP定理:三选二,架构师必须学会的取舍
10 | Lambda架构:Twitter亿级实时数据分析架构背后的倚天剑
11 | Kappa架构:利用Kafka锻造的屠龙刀
模块三 | 抽丝剥茧剖析Apache Spark设计精髓 (10讲)
12 | 我们为什么需要Spark?
13 | 弹性分布式数据集:Spark大厦的地基(上)
14 | 弹性分布式数据集:Spark大厦的地基(下)
15 | Spark SQL:Spark数据查询的利器
16 | Spark Streaming:Spark的实时流计算API
17 | Structured Streaming:如何用DataFrame API进行实时数据分析?
18 | Word Count:从零开始运行你的第一个Spark应用
19 | 综合案例实战:处理加州房屋信息,构建线性回归模型
20 | 流处理案例实战:分析纽约市出租车载客信息
21 | 深入对比Spark与Flink:帮你系统设计两开花
模块四 | Apache Beam为何能一统江湖 (8讲)
22 | Apache Beam的前世今生
23 | 站在Google的肩膀上学习Beam编程模型
24 | PCollection:为什么Beam要如此抽象封装数据?
25 | Transform:Beam数据转换操作的抽象方法
26 | Pipeline:Beam如何抽象多步骤的数据流水线?
27 | Pipeline I/O: Beam数据中转的设计模式
28 | 如何设计创建好一个Beam Pipeline?
29 | 如何测试Beam Pipeline?
模块五 | 决战 Apache Beam 真实硅谷案例 (7讲)
30 | Apache Beam实战冲刺:Beam如何run everywhere?
31 | WordCount Beam Pipeline实战
32 | Beam Window:打通流处理的任督二脉
33 | 横看成岭侧成峰:再战Streaming WordCount
34 | Amazon热销榜Beam Pipeline实战
35 | Facebook游戏实时流处理Beam Pipeline实战(上)
36 | Facebook游戏实时流处理Beam Pipeline实战(下)
模块六 | 大规模数据处理的挑战与未来 (4讲)
37 | 5G时代,如何处理超大规模物联网数据
38 | 大规模数据处理在深度学习中如何应用?
39 | 从SQL到Streaming SQL:突破静态数据查询的次元
40 | 大规模数据处理未来之路
专栏加餐 | 特别福利 (4讲)
FAQ第一期 | 学习大规模数据处理需要什么基础?
加油站 | Practice makes perfect!
FAQ第二期 | Spark案例实战答疑
FAQ第三期 | Apache Beam基础答疑
结束语 (1讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

02 | MapReduce后谁主沉浮:怎样设计下一代数据处理技术?

蔡元楠 2019-04-19
你好,我是蔡元楠。
在上一讲中,我们介绍了 2014 年之前的大数据历史,也就是 MapReduce 作为数据处理的默认标准的时代。重点探讨了 MapReduce 面对日益复杂的业务逻辑时表现出的不足之处,那就是:1. 维护成本高;2. 时间性能不足。
同时,我们也提到了 2008 年诞生在 Google 西雅图研发中心的 FlumeJava,它成为了 Google 内部的数据处理新宠。
那么,为什么是它扛起了继任 MapReduce 的大旗呢?
要知道,在包括 Google 在内的硅谷一线大厂,对于内部技术选择是非常严格的,一个能成为默认方案的技术至少满足以下条件:
经受了众多产品线,超大规模数据量例如亿级用户的考验;
自发地被众多内部开发者采用,简单易用而受开发者欢迎;
能通过内部领域内专家的评审;
比上一代技术仅仅提高 10% 是不够的,必须要有显著的比如 70% 的提高,才能够说服整个公司付出技术迁移的高昂代价。就看看从 Python 2.7 到 Python 3 的升级花了多少年了,就知道在大厂迁移技术是异常艰难的。
今天这一讲,我不展开讲任何具体技术。
我想先和你一起设想一下,假如我和你站在 2008 年的春夏之交,在已经清楚了 MapReduce 的现有问题的情况下,我们会怎么设计下一代大规模数据处理技术,带领下一个十年的技术革新呢?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(51)

  • mjl 置顶
    Unify platform和批流统一已经是主要趋势了,而我个人目前只对spark、flink有一定的了解。对于spark来说,无疑是很优秀的一个引擎,包括它的all in one的组件栈,structured streaming出来后的批流api的统一,目前在做的continues Mode。而flink,的确因为阿里的运营,在国内火了。但也展现了它的独有优势,更加贴近dataflow model的思想。同时,基于社区以及阿里、华为小伙伴的努力,flink的table/sql 的api也得到的很大的增强,提供了流批统一的api。虽然底层然后需要分化为dataset和datastream以及runtime层的batchTask和StreamTask,但是现在也在rethink the stack,这个point在2019 SF 的大会也几乎吸引了所有人。但就现状而言,flink的确有着理念上的优势(流是批的超集),同时也有迅猛上升的趋势。

    作者回复: 谢谢你的留言!感觉活捉了一只技术大牛呢。

    是的,Spark的话虽然原生Spark Streaming Model和Dataflow Model不一样,但是Cloudera Labs也有根据Dataflow Model的原理实现了Spark Dataflow使得Beam可以跑Spark runner。

    而对于Flink来说的话,在0.10版本以后它的DataStream API就已经是根据Dataflow Model的思想来重写了。现在Flink也支持两套API,分别是DataStream版本的和Beam版本的。其实data Artisans一直都有和Google保持交流,希望未来两套Beam和Flink的API能达到统一。

    最后赞一点批处理是流处理的子集,这个观点我在第一讲留言也提到过。

    如果觉得有收获,欢迎分享给朋友!同时也欢迎你继续留言交流,一起学习进步!

    2019-04-19
    32
  • AF
    1. DAG是将一系列的转换函数连接起来,最后调用真正的计算函数
    2. 番茄炒鸡蛋,炒牛腩这个例子,说明不要进行重复计算,要复用之前的计算。而且在计算之前过滤掉不必要的数据,最大限度的减少计算量。

    现在使用的数据处理技术遇到的问题就是在两个大表进行关联的时候,没有太多的优化手段,自己能想到的就是增加计算资源(但是条件不允许),然后过滤掉两个表中不必要的数据,但其实优化之后还是会很慢。

    希望老师能分享一下大表和大表join的优化手段!
    2019-04-19
    13
  • 段斌
    Q:你现在在使用的数据处理技术有什么问题,你有怎样的改进设计?

    A:简单介绍下我自己的背景,以前有RDBMS时期的数据仓库经验,后来没有跟上Hadoop发展的节奏,逐渐转向了前台业务部门。现在在一家sdk行为数据采集与分析厂商做解决方案,但是公司有很多技术栈:storm+es,flink,spark,还有最新的kudu+carbandata,学习起来非常吃力。

    基于本期的课程,我有几个问题:
    1. storm+es实时大数据平台的出现是解决什么问题?优势是什么,未来是否会被其他技术栈取代?
    2. 我们客户在用这个技术栈的产品,反馈查错成本很高,不知道在sdk采集时候数据没有收上来,还是在collector,或者是后面丢失。我想问数据监控是大数据普遍问题吗?业内是怎么解决的?
    3. 咱们是否会介绍Apache Carbondata,这个技术栈的优势是什么?你怎么看待它的发展?
    2019-04-19
    8
  • 孙稚昊
    Flink在国内也是刚刚兴起火热起来,而Apache Beam也就是Google内部FlumeJava的开源版本早早就被设计出来。国内现在讲实时数据处理,批流统一还是比较推崇Flink和阿里的自主设计的Blink系统,接受Beam可能还需要几年的时间
    2019-04-19
    6
  • 流殇忘情
    我说说我们在线上遇到过的实际问题,我们是做内容的,当内容产生view数的时候会发送用户行为日志,这个时候通过消费消息队列中的数据为用户进行收益的计算,但是这个数据是有有效期的,曾经出现过由于bug产生一些数据没有及时消费,就需要手动进行补救,看完今天的文章,我觉得可以对有时效性的数据进行标注,如果没有成功消费,系统也可以方便的找到进行自动修复。

    作者回复: 你说的很好啊

    2019-04-19
    6
  • fy
    虽然看的不是很懂,毕竟没搞过这方面的,但是每篇文章的知识点逻辑很清楚,学习中,这里尊称一句蔡老师,被老师的回复学者的留言给感动了。期待老师后面精彩的专栏

    作者回复: 谢谢肯定。期待你后面的留言。

    也欢迎推荐给朋友!

    2019-04-20
    5
  • Milittle
    讲真,这个思路太清晰了。讲到有向图那里,还没看到tf那段,我脑子里第一蹦出来的就是深度学习里面的符号式计算图,可以在图编译的时候进行优化。然后在计算时可以加速运算,还有就是,这里的计算图用拓扑排序结合优先级队列来执行计算。
    我还是个学生,有不对的地方请指教,没在真实场景中体验过,但是感觉这些都是通用的,学会了,处处可以用到。期待后续课程给更多的启发,谢谢(*°∀°)=3

    作者回复: 你理解的很多!期待你后面的分享

    2019-04-20
    4
  • wmg
    现在使用较多的是hive和sparkSql,这两种技术多使用的都是类似关系数据库的数据模型,对于一些复杂的对象必须要通过建立多张表来存储,查询时可能需要多张表进行join,由于担心join的性能损耗,一般又会设计成大宽表,但这样又会浪费存储空间,数据一致性也得不到约束。想问一下老师,有没有支持类似mongodb这样的文档型数据模型的大数据处理技术?

    作者回复: 数据的索引查询和这里的数据处理是两个话题。关于怎么提高数据系统的查询效率,我在考虑要不要开一个存储系统高性能索引专栏。

    我不知道你的查询有多复杂,简单处理的话,可以先试试建一些常见查询路径的索引表。写的时候往两张表写或者再做一些专门的建索引的数据处理系统。

    2019-04-19
    4
  • 大王叫我来巡山
    经历了mapreduce到spark, 从最具欺骗性的wordcount开始到发现很多业务本身并不适合mapreduce编程模型,一直做日志处理,现在在政府某部门同时处理批处理任务和流处理任务,老师的课太及时了,感觉对我们的业务模型革新会产生很大的影响,前两篇没有涉及技术,已经感觉醍醐灌顶了。

    作者回复: 你说的对,WordCount就像helloworld,真实业务场景肯定会复杂很多。

    2019-04-19
    4
  • 文洲
    老师讲的很明白,有个疑问,现在都说flink是下一代实时流处理系统,这里按老师的对比来看,它还比不上spark,可否理解为flink主要还是专注实时流处理而spark有兼具批处理和流处理的优势

    作者回复: 并没有说flink比不上spark。。。这篇没有展开比较。只是带了一句话flink的流处理批处理api不一样。

    2019-04-19
    4
  • Codelife
    我们是做车联网业务的,目前实时处理采用的storm,批处理采用的是MR,和您的文章中描述的一样,业务场景和算法中经常出现实时和批处理共存的情况,为了保证实时性,通常是定时执行MR任务计算出中间结果,再由storm任务调用,这样的坏处是MR任务并不及时,而且维护起来很麻烦,效果并不理想。希望能够从apache beam中学到东西

    作者回复: 谢谢你的留言!我在第十讲中所讲解到的Lambda Architecture应该会对你们的架构设计有所帮助。希望能在那时继续看到你的留言。

    2019-04-19
    1
    3
  • 小辉辉
    看完前三讲,让我对大数据又有一个更新的认识

    作者回复: 谢谢你的肯定!同时也欢迎你把专栏分享给朋友。

    2019-04-21
    2
  • monkeyking
    老师,啥叫dataflow?从字面上来看好像和dag差不多,不知道我理解的是否正确,还请老师指正

    作者回复: 谢谢你的提问!在留言区里的Dataflow指的是Google在2015发表的Dataflow Model数据处理模型。

    2019-04-20
    2
  • 电光火石
    我们做风控的,现在每天收的数据比较多,现在都是先通过spark streaming落地hive,然后每天批量跑任务做模型训练和分析,因为现在模型训练还是集中在离线训练,在线训练约束比较大,所以使用场景还比较小,训练处理的模型在通过导出到pmml在线预测,整个作为一个闭环。不知道google在这方面试怎么处理的?谢谢!

    另外,老师有个理念很新颖(从处理的数据范围来看批处理和实时计算,批处理的数据是有界的,实时计算的数据是无界的),我一直从处理的间隔来看批处理和实时计算,觉得实时计算是批处理的一种,就是不断的把离线任务处理频率做个极限,就变成了实时计算。

    作者回复: 专栏里提到了这种应用在google有1000个,所以很难概括说这类应用google怎么处理的。你的方法既然能解决问题就好了。

    关于流处理批处理后面的章节还会深入讨论。

    2019-04-20
    2
  • 来碗绿豆汤
    蔡老师好,看到您那么认真的回复读者问题,果断决定买了,跟着您一起学习。我们最近在打算重构一个项目,想听听您的建议。系统的输入是将近1TB的数据文件(好多个文件,不是一个大文件),内容就是一条条记录,描述了某个实体的某个属性。我们要做的就是把属于同一个实体的属性整合到一起,然后将数据按实体id排序输出,没100万个实体写一个文件。我现在的思路就是:第一步,把文件重新按照实体id切块,然后排序写成小文件,这一步可以是一个程序;第二步,对id属于某个范围内的(如1-100w)文件,归并排序,这一步一个程序;第三步,对排好序的文件按指定格式输出。因为以前没接触过大数据相关技术,所以现在是用java实现的demo版本,就像你课程里面所示,担心将来各个进程,线程之间,交互通信,异常处理,log处理,等一系列问题都需要自己维护会比较麻烦,想听听您的建议。

    作者回复: 这个是很典型的问题。后面学到了一些框架之后可以很方便用groupBy进行处理。

    2019-04-20
    2
  • 明翼
    老师我补充下我的三个问题:
    1.这种两个流都是大数据量的一般业界用什么样计算模型去做匹配,目前我们是用spark写的匹配?
    2.由于一个流(假设名字为A流)的数据时间跨度比较大,比如几天前的数据,这就要求另外一个流(假设为B流)必须有缓存,而从缓存中抽取B流数据时候,会根据时间和Ip的hash原一批数据和A流匹配,那这个缓存用什么比较好那?我们原来用Hbase后发现数据量大scan比较慢,改hdfs直接存储了,勉强可以用。
    3.我们最终结果数据一天也有几百亿条,目前存Es里面的,业务要求查询性能分钟级别就可以接受,我们查询性能够了,但是索引数据存储空间占用大,入索引性能一般,我们想换个高压缩性能分钟级的存储系统,目前考虑用列式存储➕ SQL引擎来做,这种没经验是否合适?

    谢谢老师耐心看完,有空指点下谢谢

    作者回复: 似乎和本篇内容并不相关。general的技术咨询我看看能不能让平台拉群讨论

    2019-04-20
    2
  • 王二
    老师您好:
    1.如您所说flink在批流处理上的不统一,目前社区各个厂商也在努力的实现这种基于SQL或其他引擎的一些统一,这块在您看来有什么好的建议。
    2.后面文章使用spark举例,这里是用他的struct streaming还是spark streaming呢.
    3.感同身受,流系统难的不在开发,在于监控,如何处理背压,如何根据负载动态调整资源,除过开源框架自带的一些监控外,后续在任务流监控这块是否有什么好的建议推荐。

    作者回复: 都是很好的问题

    1 SQL 就是一个统一的用户界面,后面的引擎可以是hive也可以是自己实现的别的
    2 看到spark部分就知道了 :)
    3 的确,监控部分我可以看看是否在后面的部分增加章节

    2019-04-19
    2
  • dylan
    有没有这么一个问题,mapreduce在大规模数据处理时,由于每个计算阶段都会落盘,所以计算比较慢,但是数据完整,不会丢失;spark基于内存计算,会有数据丢失的风险?

    作者回复: 容错性是很重要的问题,两个的容错性设计方案是不同的。

    2019-04-19
    2
  • 退而结网
    在极客时间订阅了几个专栏了,有些专栏留言的问题很少得到专栏老师的回复,看了下蔡老师的留言回复,基本上都是有问必答。这两节专栏的内容真的很多干货,同学们的留言也给了我很多启发。作为大数据处理的半入门汉,希望能在这门课程中得到更多的收获,祝愿和大家共同进步!

    作者回复: 谢谢,欢迎把专栏分享给朋友

    2019-04-20
    1
  • :)
    期待更新!
    2019-04-20
    1
收起评论
51
返回
顶部