02 | MapReduce后谁主沉浮：怎样设计下一代数据处理技术？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
大数据处理技术正迎来新的发展时代。本文讨论了MapReduce的不足之处，并提出了设计下一代大规模数据处理技术的思路。首先，通过使用有向无环图（DAG）来抽象表达多步骤数据处理，解决了维护协调多个步骤的数据处理问题。其次，自动进行性能优化是关键，通过自动发现和合并重复的数据处理流程，以及弹性的计算资源分配，提高了数据处理任务的效率。另外，将数据处理的描述语言与运行引擎解耦合开来，实现前后端分离，以及统一批处理和流处理的编程模型，使得开发者只需学习一套API，无论是批处理还是流处理，都能够应对业务需求的变化。这些设计思路将有助于引领下一个十年的技术革新。 在大规模数据处理系统中，异常处理和数据监控是关键挑战。文章指出，在复杂的数据处理系统中，异常处理是一个巨大的挑战，而数据监控能力则至关重要。文章提出了设计一套基本的数据监控能力，对数据处理的每一步提供自动的监控平台，以便帮助用户快速找到可能出错的环节。 总的来说，本文提出了下一代大规模数据处理技术的设计思路，并强调了异常处理和数据监控的重要性。这些思路将对未来的大数据处理技术发展产生深远影响。
《大规模数据处理实战》，新⼈⾸单¥59
全部留言(55)
- 最新
- 精选
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-19260- fy虽然看的不是很懂，毕竟没搞过这方面的，但是每篇文章的知识点逻辑很清楚，学习中，这里尊称一句蔡老师，被老师的回复学者的留言给感动了。期待老师后面精彩的专栏
作者回复: 谢谢肯定。期待你后面的留言。 也欢迎推荐给朋友！
2019-04-206 
Milittle讲真，这个思路太清晰了。讲到有向图那里，还没看到tf那段，我脑子里第一蹦出来的就是深度学习里面的符号式计算图，可以在图编译的时候进行优化。然后在计算时可以加速运算，还有就是，这里的计算图用拓扑排序结合优先级队列来执行计算。 我还是个学生，有不对的地方请指教，没在真实场景中体验过，但是感觉这些都是通用的，学会了，处处可以用到。期待后续课程给更多的启发，谢谢(*°∀°)=3作者回复: 你理解的很多！期待你后面的分享
2019-04-206
大王叫我来巡山经历了mapreduce到spark, 从最具欺骗性的wordcount开始到发现很多业务本身并不适合mapreduce编程模型，一直做日志处理，现在在政府某部门同时处理批处理任务和流处理任务，老师的课太及时了，感觉对我们的业务模型革新会产生很大的影响，前两篇没有涉及技术，已经感觉醍醐灌顶了。作者回复: 你说的对，WordCount就像helloworld，真实业务场景肯定会复杂很多。
2019-04-196
文洲老师讲的很明白，有个疑问，现在都说flink是下一代实时流处理系统，这里按老师的对比来看，它还比不上spark，可否理解为flink主要还是专注实时流处理而spark有兼具批处理和流处理的优势作者回复: 并没有说flink比不上spark。。。这篇没有展开比较。只是带了一句话flink的流处理批处理api不一样。
2019-04-1925
wmg现在使用较多的是hive和sparkSql，这两种技术多使用的都是类似关系数据库的数据模型，对于一些复杂的对象必须要通过建立多张表来存储，查询时可能需要多张表进行join，由于担心join的性能损耗，一般又会设计成大宽表，但这样又会浪费存储空间，数据一致性也得不到约束。想问一下老师，有没有支持类似mongodb这样的文档型数据模型的大数据处理技术？作者回复: 数据的索引查询和这里的数据处理是两个话题。关于怎么提高数据系统的查询效率，我在考虑要不要开一个存储系统高性能索引专栏。 我不知道你的查询有多复杂，简单处理的话，可以先试试建一些常见查询路径的索引表。写的时候往两张表写或者再做一些专门的建索引的数据处理系统。
2019-04-194
monkeyking老师，啥叫dataflow？从字面上来看好像和dag差不多，不知道我理解的是否正确，还请老师指正作者回复: 谢谢你的提问！在留言区里的Dataflow指的是Google在2015发表的Dataflow Model数据处理模型。
2019-04-203
来碗绿豆汤蔡老师好，看到您那么认真的回复读者问题，果断决定买了，跟着您一起学习。我们最近在打算重构一个项目，想听听您的建议。系统的输入是将近1TB的数据文件（好多个文件，不是一个大文件），内容就是一条条记录，描述了某个实体的某个属性。我们要做的就是把属于同一个实体的属性整合到一起，然后将数据按实体id排序输出，没100万个实体写一个文件。我现在的思路就是:第一步，把文件重新按照实体id切块，然后排序写成小文件，这一步可以是一个程序；第二步，对id属于某个范围内的（如1-100w）文件，归并排序，这一步一个程序；第三步，对排好序的文件按指定格式输出。因为以前没接触过大数据相关技术，所以现在是用java实现的demo版本，就像你课程里面所示，担心将来各个进程，线程之间，交互通信，异常处理，log处理，等一系列问题都需要自己维护会比较麻烦，想听听您的建议。作者回复: 这个是很典型的问题。后面学到了一些框架之后可以很方便用groupBy进行处理。
2019-04-203- Codelife我们是做车联网业务的，目前实时处理采用的storm，批处理采用的是MR,和您的文章中描述的一样，业务场景和算法中经常出现实时和批处理共存的情况，为了保证实时性，通常是定时执行MR任务计算出中间结果，再由storm任务调用，这样的坏处是MR任务并不及时，而且维护起来很麻烦，效果并不理想。希望能够从apache beam中学到东西
作者回复: 谢谢你的留言！我在第十讲中所讲解到的Lambda Architecture应该会对你们的架构设计有所帮助。希望能在那时继续看到你的留言。
2019-04-1923 
小辉辉看完前三讲，让我对大数据又有一个更新的认识作者回复: 谢谢你的肯定！同时也欢迎你把专栏分享给朋友。
2019-04-212
