开篇词 从这里开始，带你走上硅谷一线系统架构师之路
你好，我是蔡元楠。目前是Google Brain的软件工程师。
在接下来的4个月时间里，我会与你一起探索大规模数据处理的世界。
在开始我们的系统性学习之前，我想先和你分享两个我亲历的故事，借此告诉你，我为什么要开这个专栏。
2014年，我刚开始在美国找工作，在一次面试中，面试官让我解释一下C++的smart pointer和string view。我完全回答不上来。
当时我面露难色怀疑人生，难道我的前半生学的是“假的”C++吗？
回想学习经历，虽然我在一个还可以的高校里学习了C++课程，考试成绩也是90分以上。但我的学习资料只有按C++ 98标准编写的教材，和当时流行的CSDN论坛文章。
而当时的教材里根本没有提到过smart pointer和string view。
没想到工业界早就进入了C++ 0x/11标准甚至是C++ 17（当时是试验标准）。我后悔没有学习紧跟时代的最新技术，而信息的不对称就会造成巨大的认知偏差。
那学习“最新技术”一定就是好事情吗？我想通过第二个故事来回答这个问题。
2017年，我帮Google Ventures（Google的风险投资基金，会寻找并帮助优秀初创公司）在投的初创公司做导师，那时候经常参加一些对方公司的技术架构评审。
一次评审中，对方的技术VP眉飞色舞地介绍他们的技术框架和××大厂一样，罗列了Kylin和Tornado等一些时髦的技术名词。
因为我并不了解提到的几个技术，就好奇地问为什么Kylin适合他们团队，Kylin为他们解决了哪些独特的问题？
他当时的回答并没能说服我和别的同事：“因为××大厂也在用，这就是未来的技术方向”。
看得出来，这位技术VP还没有真的搞清楚使用一个技术的原因。
学会用一个技术只是第一步，最重要的是要追问自己：
- 这个技术解决了哪些痛点？
- 别的技术为什么不能解决？
- 这个技术用怎样的方法解决问题？
- 采用这个技术真的是最好的方法吗？
- 如果不用这个技术，你会怎样独立解决这类问题？
如果没有这些深层次的思考，你就永远只是在赶技术的时髦而已，不会拥有影响他人的技术领导力。
事实上在Google，类似这样的“灵魂追问”每天都在发生。
这里敢于打碎任何权威，所有的技术设计都是从问题出发。每一个工程师都会独立思考究竟什么是最佳方案，而不是照搬现有结论。
正如乔布斯所说，过去的点最终会连成线。这两个经历让我深感有使命去帮助更多技术同行，比如第一个故事里的我，或者是第二个故事里的初创公司VP。我想设计一个专栏，去解决故事里的问题。
第一，我想要介绍硅谷最前沿技术和真实的案例。
比如，在大规模数据处理领域，MapReduce或者Apache Storm的不少设计理念已经无法胜任最新的挑战。
所以，我会介绍最新的知识，例如框架层面的前后端分离理念，和批处理流处理统一的思想。
第二，我不想只停留在照本宣科的层面。
正如上文所说，学会用一个或者两个技术是不够的。
更重要的是，我会剖析技术框架产生的原因和它们解决的问题。这样当下一次你再碰到相似的问题时，就不用照搬别人的方法。
为什么写大规模数据处理？
为什么会选择大规模数据处理这个主题呢？并不是因为我觉得这个主题受众多、销量好，相反，我认为大部分人都还没有正确理解数据处理技术，常常见到的误区有如下几种。
第一，低估了数据处理的重要性。
因为我在Google Brain的AI应用领域工作，切身感受到过，没有高质量的数据处理的话，人工智能是只有人工没有智能的。
Google也曾在很长的一段时间里低估过数据处理。
例如，在语义理解上，Google认为自己有最多的搜索文本数据，最好的算法，那就一定能把语义理解做的最好。
可是到2016年左右，一个名不见经传的德国小公司却一举超过了Google，大家都很惊讶。后来发现原来他们凭借的是高质量的数据标注和处理。
第二，低估了数据处理工程师在组织架构上的重要性。
许多工程师都喜欢自嘲自己的工作是“搬砖”，事实也正是如此。
包括我在内，很多人的工作内容都避不开数据的搬运和处理。把数据从这个格式处理成那个格式，把数据从这个数据库搬到那个数据库，这个服务器搬到那个服务器，这个客户端搬到那个客户端。
可能连你自己都还没有意识到，即使是一个写前端的工程师，他的很多工作还是数据处理。
大数据领域泰斗级人物Jesse Anderson曾做过一项研究，一个人工智能团队的合理组织架构，需要4/5的数据处理工程师。很不幸，很多团队没有认识到这一点。
第三，低估了数据处理规模变大带来的复杂度。
我把这个专栏定位在“大规模”数据处理，因为我想着重在数据规模变大时需要的技术思想。
很多人可能还没有遇到过“大规模”数据的问题，容易把问题想简单了。
我在Google面试过很多优秀的候选人，应对普通的编程问题，他们能够用算法和数据结构解决得很好。可是当我追问数据规模变大时怎么设计系统，他们的回答却并不让人满意。
当你的产品从1万用户到1亿用户，技术团队从10个人到1000个人，之前的方法还能奏效吗？
第四，高估了上手数据处理的难度。
一方面我们需要认识到大规模的数据处理是有复杂的因素的。但另一方面，我想在这个专栏里教会你，有了正确的工具和技术理念，现在上手数据处理并不困难。
在Google，我见到很多应届生来了半年后也能轻松应对上亿的数据量。
我给开篇词起名为《从这里开始，带你走上硅谷一线系统架构师之路》，就是为了给你设计切实可操作的学习路径，让你比别人更准确深入地掌握实用的大规模数据处理技术，最终通往硅谷一线系统架构师的水平。
因此，我们的学习路径会是这样的。
第一部分，先会用原汁原味最实际的硅谷一线大厂的案例，向你解释MapReduce为什么不能应对最新的技术挑战。然后我会从实际的问题出发，从头开始引导你怎样从顶层设计一个数据处理框架。
第二部分，同样是结合实战案例，来讲解在数据处理框架的使用和设计中必需的一些基础知识。这些案例紧贴应用，可能就是你的团队明天会碰到的问题。
第三、第四部分深入拆解了Apache Spark和Apache Beam。不仅会用实际的案例教会你如何使用，还要教会你为什么它们这么设计。你会发现它们的设计其实大致和第一部分的顶层设计是一致的。下一次，即使这个世界一无所有，你也能构建类似的框架解决一系列问题。
第五部分按Google T6级别设计，是带着代码的真枪实弹的架构设计。毫不夸张地说，能完整掌握第五部分的思想精髓，你就能比肩硅谷一线大规模数据处理架构师。
第六部分着重培养你的技术远见。因为，是否能现在就开始准备应对10年后人类社会的技术挑战，是你拉开与别人差距的重要一站。
在刚开始动笔写专栏的时候，我就在设想，什么样的人会是这个专栏的目标读者呢？
直到专栏快上线，我写下这篇开篇词，我才真正定义读者的标签——应该就是跟我一样渴望成长的人。是的，我和你一样，都渴望成长——渴望知识的成长，渴望经验的成长，渴望财富的成长。
所以我想把这个专栏设计成一份共同的成长规划，而不是一本死板的教材。
正如我在开头的小故事里所说的，这个世界没有谁是绝对的权威。
我希望你每一期都能在留言栏里质疑、提问和讨论。这些互动能帮助我和别的同学一起提高。
最后，我期待和你一起开始学习，共同成长！
- 珅剑 👍（10） 💬（1）
我是一个蹉跎了多年的三流程序员，目前放弃了一切在脱产学习大数据，过程很辛苦，但我渴望成长，很幸运遇到了蔡老师，希望能跟随您的轨迹，通过这段时间的学习达到自己新的高度，to get my life back！
2019-04-17 - 钱 👍（15） 💬（1）
这个技术解决了哪些痛点？ 别的技术为什么不能解决？ 这个技术用怎样的方法解决问题？ 采用这个技术真的是最好的方法吗？ 如果不用这个技术，你会怎样独立解决这类问题？ 做了太多的CRUD，越来越觉得自己没什么核心竞争力，好的问题解决思路都具有通用性，希望跟着牛人走上一程，随便聊聊涨涨见识也好。 大数据多大算大？ 处理量大的思路，感觉主要就是分治的思想？ 需要多台机器来扛，如果单台机器没有容量和性能局限是不是就不需要各种大数据的处理思想了？ 我不是从事大数据工作的，只是好奇，之前面试时也遇到过类似处理大量数据存储的问题，存起来容易，一台机器容量不够，就两台，两台不行就继续加，不过怎么查询？怎么统计分析就费劲了？ 希望，听到不一样的声音喝令人惊叹的文婷姐姐思路。
2019-04-16 - 暮光之城 👍（24） 💬（1）
老师你好，你上文提到的AI落地的基础是大规模的数据和高质量的标注，目前能满足的这个条件是否只有一些超大规模的一线互联网公司。那是否意味着大数据处理也只有在这些公司中才能发挥真正的价值，那对于在小型互联网公司工作的程序员，学习大数据处理的意义在哪里呢？
2019-04-16 - 风之伤 👍（32） 💬（2）
学习这专栏需要什么基础知识
2019-04-15 - hua168 👍（6） 💬（1）
老师，学习这个需要什么知识为提前？
2019-04-15 - 大王叫我来巡山 👍（49） 💬（1）
很多时候公司淘汰一个人的原因不是因为他年龄大了，而是他的技术没有随着年龄增长
2019-04-16 - Sapph 👍（21） 💬（1）
高效的数据处理和高质量的标注是数据分析的前提，在AI战场厮杀的不仅仅是复杂的算法，还要依托于背后的大数据处理能力。看了目录，内容很干货。 话说，这又是一个亲身上阵自己录音频的老师，作者本人读出来的文章是有灵魂的~
2019-04-15 - coder 👍（17） 💬（2）
请问老师Google T6是什么概念？
2019-04-15 - 听水的湖 👍（12） 💬（1）
又是一个Google大佬，大佬是南方人吧。带着耳机听的，专栏用作者本人的声音真是很良心了，更有代入感。不过感觉有点难度，希望文章内容有深度的同事能兼顾一下宽度……学渣倒地不起……
2019-04-15 - paradox 👍（11） 💬（1）
灵魂追问需要通过阅读文档和源码，并加上自己实践和思考才能够回答。
2019-04-15 - 而立斋 👍（7） 💬（1）
听起来老师很安静，喜欢您的分享。鼓励自己多留言
2019-04-15 - 3SKarl 👍（6） 💬（1）
元楠老师，您好！请问在阅读开源框架（如hadoop，hive...)的源码方面有没有什么经验可以说说呢？我有以下疑惑： 1. 当我打开一个类开头就是二三十个变量的时候就不知该怎么读下去 2. 有些方法看着有几百行代码，当我从头到尾都弄明白每一段的逻辑之后感觉并没有学到什么，阅读源码的意义究竟是为了什么呢 3. 想请教正确的阅读源码的方式是怎样的
2019-04-18 - kylin 👍（6） 💬（1）
目前在一家外包公司写hive，做批处理。很想了解一下大数据处理的全部过程。目前国内对于技术名词的操作让我迷失了方向，像elasticsearch做即席查询，flink一统流处理和批处理，而且很多写hive的工程师写习惯了sql，也不想用编程语言写框架提供的各种算子。请问老师，做大数据处理，应该更关注哪些方面，目前写了1个多月的hive，感觉都是按照业务分层处理，我这边是DWD层，无法了解到很全面的业务流程，有些迷茫。感谢老师
2019-04-16 - 渡码 👍（6） 💬（1）
您觉得研究Mapreduce或者hdfs框架有必要吗
2019-04-16 - 李 👍（6） 💬（1）
深度拷问灵魂中技术的本质，做一个有技术远见的工程师
2019-04-15