2019-04-17把年龄倒过来比如 28 岁 变成 82 来分片作者回复: 谢谢你的答案！这个答案很新颖啊，我觉得光从年龄这个问题上来讲，你的思路是可以把20多岁变成12、22、32、42等等。希望你能在以后遇到问题时也能保持这样创新思维，也希望你继续留言，我们一起学习进步！
1 179- Codelife 置顶2019-04-17我们最早采用的是哈希算法，后来发现增删节点泰麻烦，改为带虚拟节点的一致性哈希环开处理，稍微复杂点，但是性能还好
作者回复: 谢谢你的答案！应该是一个很有经验的高级工程师了吧。使用Consistent hashing是可以很好地解决平均分配和当机器增减后重新hashing的问题。
48 
王伟 置顶2019-04-17你好！我工作中遇到这样的场景：会员在我们平台注册，信息会保存在对应商家的商家库中，现在需要将商家库中的信息实时的同步到另一台服务的会员库中，商家库是按照商家编号分库，而且商家库和会员库没在同一台服务器部署。想请教一下，像这种我们如何做到实时同步？作者回复: 你好王伟！首先感谢你的提问！
我不确定你所说的实时同步是想表达Eventual Consistency还是Strong Consistency，那我就争对两个都说说自己的愚见吧。
因为会员信息都会保存在商家库中，所以这里我假设商家库的信息可以作为source of truth。
如果你指的是Eventual Consistency的话，可以在会员更新商家库的同时将会员信息利用Pub/Sub发送给会员库去更新。考虑到Pub/Sub中间有可能会丢包，我们可以再建立一个定时任务每隔一段时间将全部商家库中的信息扫描一遍再更新到会员库中。当然具体的实现可以再作优化，因为商家库是按商家编号分库的，我们可以记录下哪些商家编号的表最近有更新我们就只扫描那些表，而不用扫描全局的表。
如果你指的是Strong Consistency的话，我们可以在中间再创建一个State Machine，记录是否两个库都同时更新了。在读取会员信息的时候，我们需要查询这个State Machine，只有当两个库同时都更新的时候才将会员信息返回。根据第九讲的CAP理论，这样的做法其实会牺牲掉Availability，也就是你的服务可用性。
当然具体的需求你会比我更了解，所以相信你能够从中做出设计上的取舍。也欢迎你继续留言提问，我们可以一起讨论学习进步！ 19
alexgreenbar 置顶2019-04-17赞一个，几乎每问必答，无论是否小白问题，很务实，具备高手风范！作者回复: 😄 很多问题确实很有思考价值，我也学到了很多之前没考虑到的。
9- maye 置顶2019-04-17个人愚见：虽然MapReduce引擎存在性能和维护成本上的问题，但是由于Hive的封装使其适用性很广泛，学习成本很低，但是实际使用过程中和Spark等相比性能差太多了。不过对于计算引擎模型的理解方面，MapReduce还是一个很经典的入门模型，对于未来迁移到其他计算引擎也是有很大帮助的。
还有一个个人问题：不知道蔡老师对于流计算和批处理的关系是怎么看待的？流计算有可能完全取代批处理么？
关于思考题：问题的核心店在于Reducer Key是否倾斜，个人认为可以按照update_time之类的时间字段进行分片处理。作者回复: 你好Maye，谢谢你的留言与提问！
第一问我也说说我的愚见吧。关于流处理和批处理的关系我更倾向于批处理可以算是流处理的一个子集吧。我们可以这么抽象地看，流计算所处理的都是无限数据集，而我们从中按照时间窗口抽取一小段出来的话，这一小段有边界的数据集其实也就是批处理所处理的数据集了。所以说批处理算是流处理的一个子集吧。但是现在流计算中两大问题：1）Exactly once delivery 2）message order，还没有非常完美的解决方案，但是我相信可以攻克的。所以未来趋势还是趋于统一。现在Google所推出的Apache Beam项目其实也是想解决这样一个问题，统一批处理和流处理的编程接口。更详细的内容我会在后面的章节展开讲解。
思考题你也看到了问题的本质，就是能找到趋于平均分配的分片处理方式。
欢迎你继续留言提问，一起交流学习进步！ 9 - 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时每次都要计算环节点的时间复杂度肯定是不一样的。
希望这对你有所帮助，如果有所收获的话也欢迎你分享给朋友，谢谢！ 8 
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结果保存，但那样就更复杂了。
6
明翼 置顶2019-04-17一般用户信息表都存在一个id，有的是递增的数字id，有的是类似uuid随机字符串，对于递增的直接对机器数量取余，如果是字符串通过比较均衡的hash函数操作后再对机器数量取余即可。作者回复: 谢谢你的答案！这个答案不错。不过取余运算在机器有增减的时候会遇到麻烦，所有的用户必须重新取余运算一遍。Consistent Hashing可以很好地解决这个问题。欢迎你继续留言，我们一起学习进步！
6
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. 总结得不错。
欢迎你继续留言，我们一起学习进步！ 12
2019-04-17在评论在看到Consistent hashing，特地去搜索看了下，终于明白了。评论干货很多。。作者回复: 哈哈有收获就好
8- 2019-04-17MapReduce是从纷繁复杂的业务逻辑中，为我们抽象出了 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。
6 
2019-04-17我们公司现在还在使用hadoop streaming 的MapReduce，默认mapper 结果是按key sort 过得，在reducer 中借此实现join和group by的复杂操作，经常为了Join 一个table就要多写四个job作者回复: 是的，我觉得你总结的很好！
5
2019-04-17按照user_id哈希或者给user_id加一个随机数前缀作者回复: 是对的思路！随机前缀这个我在另一个回复上也提到了，“真”随机会影响错误重试，因为没法还原当时的随机数，比如分片2的任务全部失败，找不到哪些是分片2了。
4
2019-04-17给作者一百五十个赞👍 4- 2019-04-17现在写MapReduce job 开几百个worker经常有1，2个卡着不结束，基本都要在下班前赶着启动耗时长的任务。 我们分片用户是用的 country+username 的 hash，还是比较均匀的
作者回复: 看来你很有经验！确实是很经常出现的问题
4 - 2019-04-18如果我读Beam的文档没有理解错的话，Beam只是spark 和flink 的各种API的一个封装，本身并没有runner，该有的调优还得在spark 和flink上面做，所以除了google以外的公司用Beam的还是蛮少的
作者回复: 再次看到了你的留言，谢谢！
就像我之前的回答一样，Beam的诞生更多是想抽象出一个统一的编程模型来处理批处理和流处理，使不同的平台相互兼容，让开发者有能力在不同的平台中转移。无论是Spark还是Flink，它们都可以选择根据Dataflow Model来编写自己的底层实现。
关于调优的话Beam有根据不同平台来编写专门的API去编写配置。当然了，因为需要统一编程接口，你对底层的控制就没有原生Spark或者Flink那么好。
关于是否采用Beam的问题，历史因素也占了很大比重。很多时候进行平台的转移可能对开发者来说是一个overkill。就像我之前所说，现在越来越多的平台开始采用Dataflow Model来编写自己的底层实现。所以理论上，在未来开发者或者公司就可以不必过于担心转移数据处理平台时的迁移成本了
希望对你有帮助，如果有收获也请分享给朋友！ 3 
2019-04-17认同您说的MR的局限性，因此建立在MR之上的hive有用武之地。面对不断出现的新框架我们怎么快速掌握它的设计，尤其是即便看文档也会觉得模棱两可，这时候有必要深入到源码中吗，您在这后续课程中有没有相关的经验分享作者回复: 第一个问题hive和MR是apple and orange，不太好对比吧。hive更类似于SQL。
第二个问题恰恰是这个专栏的重点，会教会大家怎么解析框架的设计思路。 3
2019-04-17您好，学习周期有点长，能不能加快些进度。感谢！作者回复: 看到“30天速成”字样的资料可以直接扔掉
3- 2019-04-17我们组还在用Hadoop Streaming而没有使用spark的原因是spark 内存使用不加节制，经常新起的job把周期性job的内存吃光，导致他们有时会挂掉，不知道这个问题是否有很好的解决方法。我们还是在保守地使用hadoop streaming，麻烦得很
作者回复: 你的问题都很实际啊。job和job的互相抢占并不是spark独有的问题，都需要一些优先级系统，哪些job优先级高。还有异常处理，错误重试，任何数据处理系统都需要解决。这也是为什么这篇文章里提到多任务状态机，很多时候为了异常处理免不了这些系统以至于增加了复杂度。
3 
2019-04-17个人理解，对于已知数据分布情况的数据，我们大多数情况下能找到合适的一个分区策略对数据进行分片。但实际上这对于数据开发者来说，就需要知道整体数据的一个基本情况。而对于数据倾斜，基本分为分区策略不当导致的倾斜以及单热点key的倾斜，对于后者，无论用户设置什么分区策略，都无法对数据进行分割。
对于数据倾斜问题的话，spark 3.0版本计划合入的AE功能给出了一定的方案。对于倾斜的partition，在shuffleWrite阶段就可以统计每个map输出的各个分区信息，然后根据这些信息来调整下一个stage的并发度。进一步的话，对于两表join，一张表有存在热点key的话，可以广播另外一张表的该partition，最终与其他分区的join结果做union。基于这个思路的话，engine其实是能很灵活的处理数据倾斜类问题，而不用用户去花精力研究选择。作者回复: 这个思路看起来是做了很多课后研究了！希望后面也能继续参与讨论！
3