技术场景
大数据技术可分类如下：
- 存储
- 计算
- 资源管理
HDFS
最基本的存储技术。日常应用把通过各种渠道得到的数据，如关系数据库、日志、埋点、爬虫数据都存储到HDFS，供后续使用。
HBase
NoSQL英杰，可划分到存储类别，它的底层存储也用到HDFS。
主要用途
某些场景代替MySQL数据存储访问，利用可伸缩特性，存储比MySQL多得多的数据量。
比如滴滴司机每隔几s就将当前GPS数据上传，而滴滴司机数量号称千万，每天会产生数百亿GPS数据，滴滴选择将这样海量的数据存储在HBase，当订单行程结束时，会从HBase读取订单行程期间的GPS轨迹数据，计算路程和车费。
大数据计算框架最早MapReduce，目前Spark用的最多。但直接写MapReduce或Spark程序机会不多，通常用Hive或Spark SQL大数据仓库工具进行大数据分析和计算。
MapReduce、Spark、Hive、Spark SQL主要解决离线大数据计算，针对历史数据进行计算分析，比如针对一天的历史数据计算，一天的数据是一批数据，也叫批处理计算。
Storm、Spark Streaming、Flink这类的大数据技术是针对实时的数据进行计算，比如摄像头实时采集的数据、实时的订单数据等，数据实时流动进来，也叫流处理大数据技术。
批处理、流处理计算都需庞大计算资源，需要将计算任务分布到一个大规模的服务器集群上。如何管理这些服务器集群的计算资源，如何对一个计算请求进行资源分配，这就是大数据集群资源管理框架Yarn的主要作用。各种大数据计算引擎，不管是批处理还是流处理，都能通过Yarn来资源分配，运行在一个集群中。
所以上面所有这些技术在实际部署的时候，通常会部署在同一个集群中，也就是说，在由很多台服务器组成的服务器集群中，某台服务器可能运行着HDFS的DataNode进程，负责HDFS的数据存储；同时也运行着Yarn的NodeManager，负责计算资源的调度管理；而MapReduce、Spark、Storm、Flink这些批处理或者流处理大数据计算引擎则通过Yarn的调度，运行在NodeManager的容器（container）里面。至于Hive、Spark SQL这些运行在MapReduce或者Spark基础上的大数据仓库引擎，在经过自身的执行引擎将SQL语句解析成MapReduce或者Spark的执行计划以后，一样提交给Yarn去调度执行。
这里相对比较特殊的是HBase，作为一个NoSQL存储系统，HBase的应用场景是满足在线业务数据存储访问需求，通常是OLTP（在线事务处理）系统的一部分，为了保证在线业务的高可用和资源独占性，一般是独立部署自己的集群，和前面的Hadoop大数据集群分离部署。
人生感悟
王小波说：“我活在世上，无非想要明白些道理，遇见些有趣的人，做一些有趣的事。倘能如我所愿，我的一生就算成功。”不一定要出人头地才叫成功，我能把自己的一生过得有趣、好玩，就算没白活。
但是如果简单的把好玩、有趣理解成自得其乐、不思进取，这样的生活肯定是有问题的。看王小波的其他文章就会明白，这个好玩、有趣也不是一件容易的事，没有一定的知识、见识，没有有深度的思考，没有经历过足够的困难、挫折，就根本不能理解哪些是真正好玩、有趣的人和事。
所以你必须还是要努力拼搏、锐意进取，然后在这个过程中才能真正明白一些道理，并且会遇到一些有趣的人。“我只愿蓬勃生活在此时此刻，无所谓去哪，无所谓见谁。那些我将要去的地方，都是我从未谋面的故乡。以前是以前，现在是现在。我不能选择怎么生，怎么死；但我能决定怎么爱，怎么活。”
想通了这一点后，就不再纠结自己是不是足够的优秀，能够成就什么样的事业。我只要每天都有一点点进步，明白一点点道理，生活就是值得的。所以毕业以后我觉得编程好玩，就去自学编程；觉得自己学得差不多了，就去找了一份程序员的工作；觉得缺乏创造、不断重复的程序员工作并不好玩，就去考计算机专业的研究生；后来又去北京、杭州、上海不同的城市生活；去阿里巴巴、Intel、创业公司等不同的公司去工作；期间遇到过很多有趣的人，跟很多聪明的人合作，明白了一些道理，也做过一些有趣的事。
能不能把这些技巧提炼出来，让大家一起用，所以看到《敏捷软件开发：原则、模式与实践》这本书的时候，非常激动。《敏捷软件开发》这本书把设计模式上升到设计思想的高度，书中说“软件设计不应该是面向需求设计，而应该是面向需求变更设计”，也就是说在设计的时候，主要要考虑的是当需求变更的时候，如何用最小的代价实现变更。优秀的工程师不应该害怕需求变更，而应该欢迎需求变革，因为优秀的工程师已经为需求变更做好了设计，如果没有需求变更，那就显示不出自己和只会重复的平庸工程师的区别。这就非常有意思了。
因为比较关注设计，并且后来又做了一些架构设计、框架和工具开发的工作，也因此我看到《企业应用架构模式》这本书的时候特别震撼。当时自己觉得能够做框架、工具的开发很了不起，能够做架构设计、指导其他工程师开发挺厉害，但是看了《企业应用架构模式》这本书，才发现我做的这些事情只不过是在更大的领域解决方案、架构模式里非常小的一个部分，同类的东西还有很多。当时我感觉自己真的是坐井观天、夜郎自大，也非常羞愧。
如果感觉《敏捷软件开发》的作者Bob大叔、《企业应用架构模式》的作者Martin Fowler比自己牛太多还没有太多感觉，因为毕竟隔得太远、没有交集，所以触动还不是特别大，那么后来在工作中遇到被高手全方位碾压的时候，就真正的感受到：生活还真是有意思呢。
如果你也有和我一样有过类似的困惑，不知该如何面对理想和现实之间的差距，希望我的经验可以给你一些启发。人类的进步是因为人们对美的不懈追求，而有趣也是美的一种，追逐有趣就是在追求进步，而一点一滴的进步终会引领我们实现自己的人生价值和目标。
淘宝高级技术专家李鼎聊过流式业务架构重构的心得体会
数据流是久经考验的典型思路，在网络协议(如TCP)、数据平台这样场景，早就应用多年习以为常了。淘宝业务的应用架构升级可以认为是把这样思路应用到了业务系统开发中，把「流g作为业务表达上的一等概念和手段，并在业务架构/系统能力优化提升。简单地说，因为业务面向数据流来编写，一方面业务逻辑表达可以自然接近业务流程;另一方面逻辑运行可以是全异步有很好的性能提升，一核心后端应用在双11线.上，单机QPS提升30%，RT下降40%。流程的表达与异步/同步执行方式是分离的(如果了解过像RxJava，这句会容易理解: )。
另外,流也为业务系统的保护提供新的一些方法，在思路上其实和流计算平台是一样
的，这对业务大型系统的稳定性来非常重要。当然，业务的流式架构，在业务编写上有些
FP风格(简单地说比如充分使用了Lambda),平时我们大家业务，上主要是用命令式顺序平铺方式来表达，会有要个熟悉过程，虽然不见得有多难:)
其他的一些思考
比如机器学习，可能有很多人和我有同感，基本上是从入门到放弃。我自己也思考了
原因。主要是恐惧心态，因为数学差，恐惧那些数学公式，而现在又崇尚几十天学会xxx,
这会让人更加焦虑，更不能静下心学习。所以我认为解决问题主要根本也就是调整心态，想
象学数学公式就像谈恋爱，从陌生到熟悉，再到走入婚姻的殿堂，不是一蹴而就，罗马不是一天建成的。所以公式一遍看不懂就看两遍，三遍，刻意练习，逃离舒适区。念念不忘，必
有回响!
很多人还是”面向工具“学习，对层出不穷的”工具“，感到困惑。但归根结底，这些工具本身还是计算机科学中很多基础概念的具象化，因此，”面向思想“学习应
该是更好的一种做法。先对一种最原始的实现透彻的研究，理解其背后的思想和设计理念，然后再逐步学习后期更为先进的技术，这种学习路径应该更为有效。
工作中，一个新的方案出现时，如果它在某个或某些方面优于当前最好方案，我- -定会
去思考它的catch(另一面)是什么?比如新方案更快，我就大概会看看它的空间使用率、可
维护度、全面度。一般都会发现一些问题。生活里也是如此，对表面.上只有好处而无需付出或者代价很低的东西永远保持警惕。说白了,世上没有免费的午餐，都是权衡利弊的结果。
常见的产品经理：
- 经常说，这是客户的要求必须马上改，用客户来压制研发
- 比较以自我为中心，把自己的观点等同于用户的观点。常常想当然，结果用户一看不是我想要的。结果就是开发人员一次次的从坑里刚爬上来，又被产品一脚踹下去。
不管解决技术问题，还是设计产品都需要深刻的洞察力。遇到问题先猫在后面(虽然这种方式比较猥琐)，冷静思考，暗中观察，从别人的方案或者错误中总结发现规律，然后顺势而为。
