精选留言(120)

• 
  mgxian

  置顶

  2019-04-17

  把年龄倒过来比如 28 岁 变成 82 来分片

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

  共 2 条评论

  244
• 
  Codelife

  置顶

  2019-04-17

  我们最早采用的是哈希算法，后来发现增删节点泰麻烦，改为带虚拟节点的一致性哈希环开处理，稍微复杂点，但是性能还好

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

  

  67
• 
  王伟

  置顶

  2019-04-17

  你好！我工作中遇到这样的场景：会员在我们平台注册，信息会保存在对应商家的商家库中，现在需要将商家库中的信息实时的同步到另一台服务的会员库中，商家库是按照商家编号分库，而且商家库和会员库没在同一台服务器部署。想请教一下，像这种我们如何做到实时同步？

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

  

  35
• 
  SpanningWings

  置顶

  2019-04-18

  还想到一个问题有关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时每次都要计算环节点的时间复杂度肯定是不一样的。 希望这对你有所帮助，如果有所收获的话也欢迎你分享给朋友，谢谢！

  

  16
• 
  maye

  置顶

  2019-04-17

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

  展开

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

  

  14
• 
  alexgreenbar

  置顶

  2019-04-17

  赞一个，几乎每问必答，无论是否小白问题，很务实，具备高手风范！

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

  

  13
• 
  cricket1981

  置顶

  2019-04-17

  如果不需要按某些字段做聚合分析，只是普通数据处理的话，直接用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结果保存，但那样就更复杂了。

  

  9
• 
  明翼

  置顶

  2019-04-17

  一般用户信息表都存在一个id，有的是递增的数字id，有的是类似uuid随机字符串，对于递增的直接对机器数量取余，如果是字符串通过比较均衡的hash函数操作后再对机器数量取余即可。

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

  

  7
• 
  木卫六

  2019-04-17

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

  展开

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

  

  14
• 
  TKbook

  2019-04-17

  在评论在看到Consistent hashing，特地去搜索看了下，终于明白了。评论干货很多。。

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

  

  10
• 
  JensonYao

  2019-04-17

  MapReduce是从纷繁复杂的业务逻辑中，为我们抽象出了 Map 和 Reduce这样足够通用的编程模型。 缺点： 1、复杂度高 当你构造更为复杂的处理架构时，往往进行任务划分，而且每一步都可能出错。而且往往比认为的复杂的多。 2、时间性能达不到用户要求 Google500 多页的 MapReduce 性能优化手册 1PB的排序从12小时优化到0.5小时花了5年 思考题：如果你在 Facebook 负责处理例子中的用户数据，你会选择什么分片函数，来保证均匀分布的数据分片? 由于没有过相关的经验，从网上查了下资料，常见的数据分片有1、hash 2、consistent hash without virtual node 3、consistent hash with virtual node 4、range based 文章中使用的方法就是range based方法，缺点在于区间大小固定，但是数据量不确定，所以会导致不均匀。 其他三种方法都可以保证均匀分布的数据分片，但是节点增删导致的数据迁移成本不同。 1、hash函数节点增删时，可能需要调整散列函数函数，导致大量的数据迁移 　　consistent hash是将数据按照特征值映射到一个首尾相接的hash环上，同时也将节点映射到这个环上。对于数据，从数据在环上的位置开始，顺时针找到的第一个节点即为数据的存储节点 2、consistent hash without virtual node 增删的时候只会影响到hash环上响应的节点，不会发生大规模的数据迁移。但是，在增加节点的时候，只能分摊一个已存在节点的压力；同样，在其中一个节点挂掉的时候，该节点的压力也会被全部转移到下一个节点 3、consistent hash with virtual node 在实际工程中，一般会引入虚拟节点（virtual node）的概念。即不是将物理节点映射在hash换上，而是将虚拟节点映射到hash环上。虚拟节点的数目远大于物理节点，因此一个物理节点需要负责多个虚拟节点的真实存储。操作数据的时候，先通过hash环找到对应的虚拟节点，再通过虚拟节点与物理节点的映射关系找到对应的物理节点。引入虚拟节点后的一致性hash需要维护的元数据也会增加：第一，虚拟节点在hash环上的问题，且虚拟节点的数目又比较多；第二，虚拟节点与物理节点的映射关系。但带来的好处是明显的，当一个物理节点失效是，hash环上多个虚拟节点失效，对应的压力也就会发散到多个其余的虚拟节点，事实上也就是多个其余的物理节点。在增加物理节点的时候同样如此。 引用blog：http://www.cnblogs.com/xybaby/p/7076731.html 所以这样看具体采用何种方式要结合其他的因素（显示场景，成本？），如何抉择我也不是很清楚。

  展开

  作者回复: 线下做了研究了很好啊。这三个看起来都可以吧。一般场景我觉得可以选择复杂度低的第一种，后面的对于普通场景可能都有点overkill。

  

  8
• 
  牛冠群

  2019-04-17

  您好，学习周期有点长，能不能加快些进度。感谢！

  作者回复: 看到“30天速成”字样的资料可以直接扔掉

  

  6
• 
  monkeyking

  2019-04-17

  按照user_id哈希或者给user_id加一个随机数前缀

  作者回复: 是对的思路！随机前缀这个我在另一个回复上也提到了，“真”随机会影响错误重试，因为没法还原当时的随机数，比如分片2的任务全部失败，找不到哪些是分片2了。

  共 2 条评论

  6
• 
  张德

  2019-04-17

  给作者一百五十个赞👍

  

  5
• 
  孙稚昊

  2019-04-17

  我们公司现在还在使用hadoop streaming 的MapReduce，默认mapper 结果是按key sort 过得，在reducer 中借此实现join和group by的复杂操作，经常为了Join 一个table就要多写四个job

  作者回复: 是的，我觉得你总结的很好！

  

  5
• 
  aof

  2019-04-17

  MR的劣势刚好对应了Spark的优势 1. 通过DAG RDD进行数据链式处理，最终只有一个job，大大降低了大数量MR的维护成本 2. 优先基于内存计算的Spark相对于基于磁盘计算的MR也大幅度提高了计算性能，缩短计算时间 个人觉得，这两点可以作为MR和Spark的主要区别。

  展开

  作者回复: 谢谢你的留言！我认同你的观点，MR确实在每一步都需要经过磁盘的数据读取和结果的写入，速度上也就比不上Spark了。希望后面能继续看见你留言，一起学习进步！

  

  5
• 
  王昊

  2019-04-24

  老师您好，我现在正在读研究生(专业计算机技术)，喜欢数据科学，编写过简单的MR，谢谢您高屋建瓴地述说其历史发展，想请教您比如很多学生应该怎么学习，如何成长为优秀的工程师，是应该从头从MR学起还是直接学高级的技术？

  作者回复: 谢谢你的提问！任何“高级”的技术都离不开底层的支持，而万变不离其宗，底层思想其实在各个数据处理平台中都是相通的。我觉得如果是刚开始学习的话是需要把基本的思想先学明白，例如可以读一读MapReduce的论文："MapReduce: Simplified Data Processing on Large Clusters"。而后自己的动手实践当然也是少不了的。如果还有时间的话，可以听一听工业界上大公司的技术演讲，看看在实际应用场景中它们是如何搭建自己的技术栈的。希望这些对你有所帮助。

  

  4
• 
  孙稚昊

  2019-04-17

  现在写MapReduce job 开几百个worker经常有1，2个卡着不结束，基本都要在下班前赶着启动耗时长的任务。 我们分片用户是用的 country+username 的 hash，还是比较均匀的

  作者回复: 看来你很有经验！确实是很经常出现的问题

  

  4
• 
  mjl

  2019-04-17

  个人理解，对于已知数据分布情况的数据，我们大多数情况下能找到合适的一个分区策略对数据进行分片。但实际上这对于数据开发者来说，就需要知道整体数据的一个基本情况。而对于数据倾斜，基本分为分区策略不当导致的倾斜以及单热点key的倾斜，对于后者，无论用户设置什么分区策略，都无法对数据进行分割。 对于数据倾斜问题的话，spark 3.0版本计划合入的AE功能给出了一定的方案。对于倾斜的partition，在shuffleWrite阶段就可以统计每个map输出的各个分区信息，然后根据这些信息来调整下一个stage的并发度。进一步的话，对于两表join，一张表有存在热点key的话，可以广播另外一张表的该partition，最终与其他分区的join结果做union。基于这个思路的话，engine其实是能很灵活的处理数据倾斜类问题，而不用用户去花精力研究选择。

  展开

  作者回复: 这个思路看起来是做了很多课后研究了！希望后面也能继续参与讨论！

  

  4
• 
  旭东(Frank)

  2019-04-17

  区分热点数据（占用）大的数据，以及关联性大的数据。应该有个数据抽样分析，再做具体分片策略

  作者回复: 这个点不错，可以先分析一下数据分布

  

  4