大规模数据处理实战
蔡元楠
硅谷资深工程师
41608 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
大规模数据处理实战
15
15
1.0x
00:00/00:00
登录|注册

01 | 为什么MapReduce会被硅谷一线公司淘汰?

动态分片技术的引入
MapReduce的性能优化配置复杂性
实际商业MapReduce场景的复杂度
复杂的MapReduce系统
Apache Beam
FlumeJava
时间性能达不到用户期待
高昂的维护成本
蒸汽机时代
青铜时代
蒸汽机时代
青铜时代
石器时代
思考题
下一代数据处理技术
MapReduce被淘汰的原因
MapReduce的发展历程
超大规模数据处理的技术发展分为三个阶段
蔡元楠分享的主题
为什么MapReduce会被硅谷一线公司淘汰
文章主题

该思维导图由 AI 生成,仅供参考

你好,我是蔡元楠。
今天我要与你分享的主题是“为什么 MapReduce 会被硅谷一线公司淘汰”。
我有幸几次与来 Google 参观的同行进行交流,当谈起数据处理技术时,他们总是试图打探 MapReduce 方面的经验。
这一点让我颇感惊讶,因为在硅谷,早已没有人去谈论 MapReduce 了。
今天这一讲,我们就来聊聊为什么 MapReduce 会被硅谷一线公司淘汰。
我们先来沿着时间线看一下超大规模数据处理的重要技术以及它们产生的年代。
我认为可以把超大规模数据处理的技术发展分为三个阶段:石器时代,青铜时代,蒸汽机时代。

石器时代

我用“石器时代”来比喻 MapReduce 诞生之前的时期。
数据的大规模处理问题早已存在。早在 2003 年的时候,Google 就已经面对大于 600 亿的搜索量。
但是数据的大规模处理技术还处在彷徨阶段。当时每个公司或者个人可能都有自己的一套工具处理数据。却没有提炼抽象出一个系统的方法。

青铜时代

2003 年,MapReduce 的诞生标志了超大规模数据处理的第一次革命,而开创这段青铜时代的就是下面这篇论文《MapReduce: Simplified Data Processing on Large Clusters》。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

MapReduce技术曾是超大规模数据处理的重要技术,但在硅谷一线公司逐渐被淘汰。文章从技术发展历程出发,将超大规模数据处理的技术发展分为石器时代、青铜时代和蒸汽机时代。MapReduce逐渐被取代的原因主要包括高昂的维护成本和时间性能无法满足用户期望。使用MapReduce需要严格遵循分步的Map和Reduce步骤,构建复杂的处理架构时需要协调多个任务,增加了整个系统的复杂度。实际商业场景中,每一个MapReduce任务都有可能出错,需要重试和异常处理的机制,使得协调这些任务变得复杂困难。文章通过详细案例阐述了MapReduce系统的复杂度,强调了其在实际商业场景中的极端复杂性。这些因素导致了MapReduce技术在硅谷一线公司逐渐被淘汰,标志着蒸汽机时代的开始。文章还提到了下一代数据处理技术雏型FlumeJava,它解决了MapReduce的短板,并带来了更好的可测试性和可监控性。在后续章节中,将深入解析Apache Beam(FlumeJava的开源版本),揭开MapReduce继任者的神秘面纱。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《大规模数据处理实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(120)

  • 最新
  • 精选
  • SpanningWings
    置顶
    还想到一个问题有关consistent hashing的。map reduce下层的GFS也没有采用consistent hashing来控制分片,这又是为什么?老师有空回答下吗?

    作者回复: 再次看到了你的提问,感谢! 以下纯属个人愚见。 无论是MapReduce的partitioning,还是GFS的chunkservers,它们的设计思想都是将文件分割成固定大小的chunks来维护,而每一个chunk都会有一个deterministic的64位唯一标识符。这种设计思想是和consistent hashing不一样的,可以称为是Central Coordinator。 而历史原因也是存在的,GFS和MapReduce是分别在2003年和2004年公开论文的,而Distributed Hash Table这种思想,也就是Consistent hashing,是在2007年Amazon发表了Dynamo: Amazon's Highly Available Key-value Store这篇论文后被大家所广泛认同的。 最后我想说的是,设计一个通用架构给所有开发者使用和根据自身应用场景所设计出来的架构,它们的侧重点会有所不同。如果只是自身业务需要并且不需要太考虑时间复杂度,那当然可以自己去实现consistent hashing,毕竟hashing后取模和consistent hashing时每次都要计算环节点的时间复杂度肯定是不一样的。 希望这对你有所帮助,如果有所收获的话也欢迎你分享给朋友,谢谢!

    2019-04-18
    16
  • alexgreenbar
    置顶
    赞一个,几乎每问必答,无论是否小白问题,很务实,具备高手风范!

    作者回复: 😄 很多问题确实很有思考价值,我也学到了很多之前没考虑到的。

    2019-04-17
    13
  • cricket1981
    置顶
    如果不需要按某些字段做聚合分析,只是普通数据处理的话,直接用Round Robin分片即可。我想了解什么是“动态分片”技术?即使不用MR,其他大数据处理框架也需要用到“分片”,毕竟大数据的处理是“分而治之”,如何分才能分得好是关键。日常工作中经常遇到数据倾斜问题,也是由于分片不合理导致的。如果对于待处理的数据你了解到好办,知道用哪些字段作分片最合适,但如果遇到不熟悉的数据你又该如何分片?而不是等到出现数据倾斜问题的时候才发现,进行分片修改再重跑呢?谢谢老师指教!

    作者回复: Round robin确实能保证均匀但是有个很大的问题是没有容错。因为在分布式处理的时候数据处理顺序是“随机”的,可能是shard 1/2/3也可能是 shard 1/3/2,如果发现shard 2所有任务挂了(机器坏了)需要重试,如果有确定的sharding function很容易找出shard 2的任务,round robin的话就无法还原shard 2任务了。当然你可以说我再搞个数据库把round robin结果保存,但那样就更复杂了。

    2019-04-17
    10
  • Codelife
    置顶
    我们最早采用的是哈希算法,后来发现增删节点泰麻烦,改为带虚拟节点的一致性哈希环开处理,稍微复杂点,但是性能还好

    作者回复: 谢谢你的答案!应该是一个很有经验的高级工程师了吧。使用Consistent hashing是可以很好地解决平均分配和当机器增减后重新hashing的问题。

    2019-04-17
    68
  • maye
    置顶
    个人愚见:虽然MapReduce引擎存在性能和维护成本上的问题,但是由于Hive的封装使其适用性很广泛,学习成本很低,但是实际使用过程中和Spark等相比性能差太多了。不过对于计算引擎模型的理解方面,MapReduce还是一个很经典的入门模型,对于未来迁移到其他计算引擎也是有很大帮助的。 还有一个个人问题:不知道蔡老师对于流计算和批处理的关系是怎么看待的?流计算有可能完全取代批处理么? 关于思考题:问题的核心店在于Reducer Key是否倾斜,个人认为可以按照update_time之类的时间字段进行分片处理。

    作者回复: 你好Maye,谢谢你的留言与提问! 第一问我也说说我的愚见吧。关于流处理和批处理的关系我更倾向于批处理可以算是流处理的一个子集吧。我们可以这么抽象地看,流计算所处理的都是无限数据集,而我们从中按照时间窗口抽取一小段出来的话,这一小段有边界的数据集其实也就是批处理所处理的数据集了。所以说批处理算是流处理的一个子集吧。但是现在流计算中两大问题:1)Exactly once delivery 2)message order,还没有非常完美的解决方案,但是我相信可以攻克的。所以未来趋势还是趋于统一。现在Google所推出的Apache Beam项目其实也是想解决这样一个问题,统一批处理和流处理的编程接口。更详细的内容我会在后面的章节展开讲解。 思考题你也看到了问题的本质,就是能找到趋于平均分配的分片处理方式。 欢迎你继续留言提问,一起交流学习进步!

    2019-04-17
    14
  • mgxian
    置顶
    把年龄倒过来比如 28 岁 变成 82 来分片

    作者回复: 谢谢你的答案!这个答案很新颖啊,我觉得光从年龄这个问题上来讲,你的思路是可以把20多岁变成12、22、32、42等等。希望你能在以后遇到问题时也能保持这样创新思维,也希望你继续留言,我们一起学习进步!

    2019-04-17
    2
    246
  • 明翼
    置顶
    一般用户信息表都存在一个id,有的是递增的数字id,有的是类似uuid随机字符串,对于递增的直接对机器数量取余,如果是字符串通过比较均衡的hash函数操作后再对机器数量取余即可。

    作者回复: 谢谢你的答案!这个答案不错。不过取余运算在机器有增减的时候会遇到麻烦,所有的用户必须重新取余运算一遍。Consistent Hashing可以很好地解决这个问题。欢迎你继续留言,我们一起学习进步!

    2019-04-17
    7
  • 王伟
    置顶
    你好!我工作中遇到这样的场景:会员在我们平台注册,信息会保存在对应商家的商家库中,现在需要将商家库中的信息实时的同步到另一台服务的会员库中,商家库是按照商家编号分库,而且商家库和会员库没在同一台服务器部署。想请教一下,像这种我们如何做到实时同步?

    作者回复: 你好王伟!首先感谢你的提问! 我不确定你所说的实时同步是想表达Eventual Consistency还是Strong Consistency,那我就争对两个都说说自己的愚见吧。 因为会员信息都会保存在商家库中,所以这里我假设商家库的信息可以作为source of truth。 如果你指的是Eventual Consistency的话,可以在会员更新商家库的同时将会员信息利用Pub/Sub发送给会员库去更新。考虑到Pub/Sub中间有可能会丢包,我们可以再建立一个定时任务每隔一段时间将全部商家库中的信息扫描一遍再更新到会员库中。当然具体的实现可以再作优化,因为商家库是按商家编号分库的,我们可以记录下哪些商家编号的表最近有更新我们就只扫描那些表,而不用扫描全局的表。 如果你指的是Strong Consistency的话,我们可以在中间再创建一个State Machine,记录是否两个库都同时更新了。在读取会员信息的时候,我们需要查询这个State Machine,只有当两个库同时都更新的时候才将会员信息返回。根据第九讲的CAP理论,这样的做法其实会牺牲掉Availability,也就是你的服务可用性。 当然具体的需求你会比我更了解,所以相信你能够从中做出设计上的取舍。也欢迎你继续留言提问,我们可以一起讨论学习进步!

    2019-04-17
    35
  • 木卫六
    年龄是值域在0-120(假定)之间的数值,难以分片的原因正是因为年龄的十位数权重过大,所以我觉得一切有效降低十位数权重的哈希算法应该都是可行的。 1.对于年龄ABC,比如倒置CBA,或(C*大质数1+B*较小质数+C)%numPartitions,这类方法应该可以明显改善分布不均,但是对某些单一热点无解,比如25岁用户特别多; 2.随机分区,可做到很好均衡,对combine,io等优化不友好 3. 先采样+动态合并和拆分,实现过于复杂,效果可能不稳定 这是我的想法,请老师指正。

    作者回复: 谢谢你的答案!你在每个答案里都分别给出这个答案所存在的不足,这一点我是非常赞赏的。在开发设计中没有哪个答案是特别完美的,我们能做的是分析哪一个才是最符合自身应用需求,进而改善。 1. 是的,倒置年龄的digit可以改善均分的问题,但是也存在hot spot的问题。 2. 我在其它的留言也回复过,随机分区的话还有一个缺点是当分区任务失败需要重新分区的时候,分区结果不再是deterministic的。 3. 总结得不错。 欢迎你继续留言,我们一起学习进步!

    2019-04-17
    14
  • TKbook
    在评论在看到Consistent hashing,特地去搜索看了下,终于明白了。评论干货很多。。

    作者回复: 哈哈有收获就好

    2019-04-17
    10
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部