最近要实现某个功能，我当时一听这个功能，说，这实现个毛啊．然后同事跟我说，这当然能实现，你知道Kylin吗?当时听他说完这句话，我默不作声．在想自己知道Kylin啊，但是怎样用Kylin来实现呢?
当时我甚至忘记了Kylin到底是干嘛用的．最近回过头来想这件事情，很可怕．我发现过去学习浅尝辄止的行为，其实并没有让我学到什么．特别是阅读一部大块头的书籍来学习一样东西的时候．
而我通过自己读源码，自己分析的事情，却记得很牢．
大学的时候，我也接触过很多新技术，可以说，当时报道的任何新技术，我基本上都尝试过，从前端，Android，Java，大数据到运维，Devops．除了大数据方面的，其它方面的基本上都知道这项新技术是为了解决什么痛点，该如何用．而大数据方面，当时由于并没有这个需求，所以只是稍微尝试了下，就忘记了．
而现在我发现，我看过一项新技术，却并不知道它是为了解决什么痛点，要如何用．
反思了一下，写成了这篇文章．
第一个原因，是学习新技术的时候，现在倾向于直接找跟这项技术相关的书籍，然后从头到尾过一遍，就觉得自己学会了．
因为觉得这样一本书里，肯定包含了跟这项技术相关的全部内容．所以啃一遍，就OK了．
我不知道跟我抱有相同想法的人多不多．但是现在我想说，这种想法是错误的．
首先，这样一本大块头里，确实包含了跟这项技术相关的所有内容．但是，其实我们现在只是为了了解它的功能，解决了哪些痛点，以后进行技术选型的时候可以有方向，以及如何简单的使用．而书中包含的原理等，我们现在其实并不需要．
而这些书中，往往组织结构都不是很好．往往会把用法放在中间的位置，而不是开头．像《ElasticSearch: The Definitive Guide》这本书，我们来看它的目录:
Chapter 1 You Know, for Search…
Installing Elasticsearch
Running Elasticsearch
Talking to Elasticsearch
Document Oriented
Finding Your Feet
Indexing Employee Documents
Retrieving a Document
Search Lite
Search with Query DSL
More-Complicated Searches
Full-Text Search
Phrase Search
Highlighting Our Searches
Analytics
Tutorial Conclusion
Distributed Nature
Next Steps
Chapter 2 Life Inside a Cluster
An Empty Cluster
Cluster Health
Add an Index
Add Failover
Scale Horizontally
Coping with Failure
Chapter 3 Data In, Data Out
What Is a Document?
Document Metadata
Indexing a Document
Retrieving a Document
Checking Whether a Document Exists
Updating a Whole Document
Creating a New Document
Deleting a Document
Dealing with Conflicts
Optimistic Concurrency Control
Partial Updates to Documents
Retrieving Multiple Documents
Cheaper in Bulk
这是前三章的目录，我们能看到，关于ElasticSearch的内部架构的事情，放到了第二章．即使作者确实是为我们好，想我们知道它的原理，但是把它放到后面其实更好．所以这本书我们阅读的时候，应该是跳读的方式，我是先读了Chapter1, Chapter3, Chpater 5, Chpater 6．这样子对它的用法熟悉了以后，再回过头来看它的内部架构，会有更深刻的认识，也更容易理解．
这种书中，还会包含很多我们并不需要的东西，比如，这本书中，还会包含跟运维相关的内容，而我们其实并不需要它．即使啃完了这部分，也没有丝毫帮助．
而且我们刚开始很可能会选择一本错误的书籍来学习这项新技术．我们很可能会选择一本关于这项新技术进阶的书籍，而不是给初学者入门用的书籍．这样的书籍，对初学者来说，一点用处没有，只会浪费时间．
学习一项新技术，很多人都是看的翻译过来的经典书籍．但是，我自己的感受是，书中很多地方不是翻译的不准确，让人不知所云，就是硬翻译，根本不顾及中英句法组织的区别．而且，有的书籍还翻译的有错误．我当时实习的时候，学习Hadoop.做第一个Sample，按照书上的来做，就是跑不起来，老是报错，检查了很多遍，跟书上没有区别．最后下载下来英文版的，发现翻译过来的这本书那个地方错了，还错的很严重．
我们啃一本技术书籍的时候，也倾向于不看目录和前言．至少以前我是这个样子．这是一个非常错误的做法．前言中往往非常清晰地说明了全书的结构，以及哪些章节我们可以跳过．按照作者提示的组织结构，以及按照目录，自己组织一个阅读顺序，阅读起来不仅更轻松，还会事半功倍．
关于如何阅读一本书，请参考我写的《如何阅读一本书》书评．如果不会阅读书，强烈建议读一下．
第二个原因是，没有做足够的练习．像大学的时候，接触的新技术很简单，我也会至少玩个两三天，知道它是干嘛的．然后再玩其它的．这些新技术，往往官网上的Tutorials上已经有足够的信息，告诉你如何入门了．而且我可以立刻就把这项新技术应用到我们的项目中．也就是有实践场景．
即使有的时候，官网上的Tutorials不够好，也大多数时候可以从Tutorialspoint这个网站上找到足够入门的教程．
可是现在学习的新技术，都是中间件，或者基础设施服务，往往也都是分布式的．搭建一套测试环境往往比较麻烦，官网的Tutorials往往也不够详细．
像Spark, MapReduce这种分布式数据处理框架，如果我们不做足够多的练习，根本就不知道怎么用它，它能帮我们解决哪些问题．
所以现在学习的东西，其实往往都需要更加深入的练习以及调试，才能了解它，而分布式系统其实是非常难调试的，也就大大提高了学习成本．不像大学的时候学习的东西，简单做个项目玩玩，或者敲两条命令，就会了．
对于这个方面，唯一的解决方法就是不怕困难，就是干．
第三个原因是，对技术有轻视之心．我之前看过Kylin以及Druid，但是现在我忘记了它们是干嘛的了．昨天翻了一遍一本跟Kylin相关的书，又了解了一下，才发现上面提到那个功能，用Kylin很容易实现．
为什么会轻视它呢？因为有些技术，其实从原理上来说，很简单．比如，Kylin就是做了预处理而已，我们做过类似的事情．而Druid我记得好像也是预计算，忘记了．这两天也翻一遍书来看看．
解决方法嘛，就是深入了解这项技术，对技术怀有敬畏之心．比如，Kylin的主要处理时间都是在离线预计算上，那么，如果维度很多，以及维度的属性值很多的情况下，Kylin会怎么做？这个预计算的时间有多长？
第四个原因是，没有嵌入到现有的架构体系中．学习新技术的时候，没有和现有的架构体系中的组件做对比，看到新技术的长处．比如当时看impala的时候，如果只是觉得，哦，它只不过是跟Hive一样的通过SQL查数据的东西而已．而没有认识到，由于架构不同，它比Hive快很多，就很容易忽略它．还有Presto和Impala，如果不是意识到Impala对Hive的map结构支持不好，也就不会在意Presto(其实我也不知道Presto支不支持Hive的map结构，因为我没用过Presto，只是同事用过．但是我觉得它应该能支持，所以就把它嵌入到架构体系中了)．
解决方法就是搜索一下相似的框架之间的区别，这个Google和StackOverflow上往往有很多．
第五个原因是，没有实践场景．我们学习了一项新技术，往往不能立刻用到项目中．但是，其实没什么关系．我们学习一项新技术的目的，至少目前只是为了技术选型而已，如果上面的都做好，我们只需要等到需要用到它了，再深入了解，用到项目中去就好了．而不至于两眼一抹黑，不知道该怎么走．
第六个原因是，读完一本技术书籍以后，并没有用自己的方式，把笔记记录下来．而这个总结回顾其实对于知识的吸收是很有用的．现在我已经在实践将读书笔记用自己的方式记录下来．
