学习，是一个循序，渐进的过程。很意外我能接触到如此有高度的大数据教程，也很意外我终于亲自接触到了如此优秀的软件工程师。
1、引子
我已经记不太清我是从哪里得到李智慧老师在极客时间上的这门课程的信息的了。反正我平时是几乎不上这个网站去找学习资料的，但现在，这个网站将是我未来很长一段时间里的知识宝库！李智慧老师开设的这门《从零开始学大数据》刷新了我的认知，包括技术上的、学习上的、职业规划上的甚至有些是人生价值上的。花了一周时间粗略地学习了一下这套教材，现简单做个总结。
1.1、为什么要学习大数据技术
大数据技术说白了就是用于大量数据场景下的一种数据处理或分析的工具或手段。
计算机的出现在本质上是将人类现实世界中的业务操作转移到另一种场景来处理，利用计算机快速的计算性能以及便捷的网络通信特性来提升我们处理业务的效率。但，时至今日，单台计算机的性能提升已经越来越困难了，并且提升单机性能所花费的成本也越来越大。而大数据技术在本质上是协调多台计算机的性能来处理一个需求，就是分布式计算模式。俗话说：三个臭皮匠，赛个诸葛亮。分布式是人类进一步提升计算机性能的最佳手段。在计算机性能的提升之路上，纵向发展虽然受阻，横向发展却方兴未艾。
数据中所蕴含着的价值是巨大的，甚至数据于某些企业就是护城河一般的存在。随着时间的推移，各大企业所积累的数据规模也愈发庞大。随之而来的各种大数据处理技术也越来越成熟。由大数据处理技术衍生的各种智能推荐、数据挖掘甚至是人工智能技术等都备受瞩目。在未来，大数据编程技术将会越来越简单，软件工程师只需要花很少的时间在编写代码与调试上，剩余的精力将会花费在设计架构以及梳理业务上。甚至于在未来相关行业的非软件开发人员都需要懂点大数据编程技术，因为它是如此的易上手。如今的大数据技术已经相当成熟了，而大数据技术的应用场景却仍处于起步阶段。未来将会有越来越多的行业搭上大数据技术的快车。毫无疑问下一个互联网主题就是大数据。
1.2、大数据技术的前世今生
大数据技术公认的开山始祖是 Google 在十几年前先后发表的三篇论文
- 分布式文件系统 GFS
- 大数据分布式计算框架 MapReduce
- NoSQL 数据库系统 BigTable
这三篇论文说白了就一个是文件系统，一个是计算引擎，还有一个是数据库。这三套系统合并起来正好可以构建一个完整的大数据技术生态。
当年 Google 在发表这三篇论文时，其内部就已经在应用着他们论文中论述的软件框架了，但遗憾的是这三套 Google 自研的软件是闭源的。但很快，对应着这三篇论文的开源软件框架就发布了。GFS 对应的开源框架是 Hadoop ，Google MapReduce 对应的开源框架是 Hadoop MapReduce ，BigTable 对应的开源框架是 HBase。
这三套开源框架问世的时间并不一致，并且老实说，这三套框架的问世并没有立即让业界 “陷入疯狂”，对于 Hadoop 的 HDFS 和 HBase 还好，就是这个 MapReduce 并不是很方便。不过也正是因为 MapReduce 的这个不足，才导致后续衍生出一系列简化其编程模型的框架出来，诸如 Pig、Impala、Hive、YARN 等。其实大数据技术软件框架之间 “争夺天下” 的历史还是挺复杂的，很不幸我们错过了这个早期阶段，同时又很幸运，我们刚好错开了这段混沌历史时期。
百度和阿里早在 2007 年的时候就用上了 Hadoop 了。有的时候你不得不承认，大公司就是大公司，不仅技术一流，思想还很开放包容与前卫。
在 2012 年的时候，也有一个大数据计算引擎逐渐进入到人们的视野 -- Spark。Spark 与 MapReduce 的功能是一样的，所不同的是，它充分发挥了计算机内存的特性，相较于对硬盘依赖程度很高的 MapReduce ，同样繁重的计算任务，Spark 的速度要远高于 MapReduce 。于是，Spark 很快就成为了大数据界的 “网红”，并在很多场景下替代了 MapReduce 。但替代并不代表着取代，只是二者各有应用场景而已。既是是现如今 MapReduce 在大数据计算领域也还发挥着至关重要的作用。
MapReduce、Spark 这类计算引擎主要用于处理离线数据，被称为 “批处理”。而与之相对的又有专门处理实时数据的计算引擎，这类计算引擎被称为 “流处理”。目前的代表计算引擎有 Spark Streaming、Storm、Flink。就目前而言，Storm 已经逐渐被淘汰了。Flink 正变的越来越重要。
目前而言，我们所讨论的大数据技术主要有以下三个应用场景
- 数据分析
- 数据挖掘
- 机器学习
数据分析门槛较低，需要掌握 SQL、数仓建模等知识。数据挖掘对数学与算法要求较高。机器学习这块我了解的很少，但它是人工智能的基础。
2、技术篇
2.1、Hadoop
Hadoop 可以细分为 HDFS 和 MapReduce 两套框架。其中 HDFS 专门负责存储文件，它就是一个分布式版的文件系统。Google 在 2004 年的时候发布了大数据分布式存储 GFS 论文，Hadoop 于 2006 年推出，历经 13 年，HDFS 凭借着它的特性仍然能够稳坐大数据存储技术的交椅。
HDFS 是一个可靠的、可扩展的、容错的分布式文件系统，它的全称是 Hadoop distributed file system。HDFS 的模式是串联多台计算机的内存、磁盘与 CPU 资源。对于终端用户而言，它就是一台计算机，不管你背后的集群规模有多么庞大。
2.1.1、HDFS 如何保证可靠性？
可靠性就是 HDFS 可以确保存储在其中的文件不会丢失。同时，个人还认为系统的高可用性也要算在可靠性的范畴以内。什么是高可用性呢？就是 HDFS 的能让终端用户在任意时刻都能获取到 HDFS 的正常服务的能力。
首先，HDFS 确保文件不丢失的机制很简单，就是 “分布式存储”。
HDFS 允许你设定一个 “副本因子”，副本因子就是同一个文件在这个集群中要保存多少份。默认是 3 份。HDFS 分布式存储文件也是有规则的。一份副本会被保存在写入数据的那台机器上，另一份副本会被保存在本机架内的另一台机器上，最后一份副本则保存在另一个机架的任意一台机器上。
关于第一份副本会被保存在写入数据的那台机器上，这是什么意思呢？这是在我们的 HDFS 上，终端用户可以连接任意一台数据节点来读写数据，所以我们要存储一个文件时，连接的是哪一台数据节点，那就在哪个数据节点中存储一份副本，毕竟本地存储的成本是最低廉的。那第二、第三份副本存储时提到的机架是什么呢？在分布式集群中，每台计算机都被称为是一个 “节点”。当节点数量较多时，为了防止网络服务中断导致的 HDFS 服务中断，通常会将这些节点划分为不同的机架，简单说，就是一批电脑接这个路由器，另一批电脑接那个路由器。当然在生产环境中，这个 “不同的路由器” 一般是指不同的网络服务提供商。
HDFS 分布式存储文件副本的形式能够极大地保证存储在其上的文件不会丢失。毕竟同一个文件我有多个备份，一台机器宕机了，我还可以从另一台机器上得到这个文件完整备份。但这种副本机制所带来的代价也是巨大的，这份代价主要就体现在磁盘空间与网络 IO 上，不过对于数据的可靠性而言，这种代价也显得不是那么重要了。
其次，HDFS 确保高可用的方式是将管理节点设置为 “双机热备” 模式。双机热备是指同时运行两台计算机来扮演同一种功能的节点，但在集群中同一时刻只能有一个节点提供服务，另一台节点以备份节点的形式实时同步主节点中的数据。当主节点宕机时，能够迅速接替工作对外提供服务，从而保证集群的服务不至于中断。在 HDFS 中，这个 “工作接替” 的过程是很短暂的，通常在数秒至数分钟的时间里就能完成。
2.1.2、HDFS 如何实现可扩展性？
HDFS 的扩展性指的是我们可以在不停服的情况下给我们的集群新增、删减节点的特性。
这种特性可牛 X 了，当市场上出现更强更廉价的设备以后，我们可以通过这种扩展性，逐步为我们的集群换上新硬件，退下老旧设备来，这一过程对用终端用户来说是完全 “无感” 的。这种特性可以让我们的集群 “永葆青春”。
HDFS 在配置文件中有两种配置项：白名单与黑名单。通过将对应节点的机器名称添加到这两份名单中，就可以达到 “优雅地” 服、退役节点目的。新节点服役时，集群会做一个 “负载均衡” 操作以保证集群整体性能被均衡发挥。
2.1.3、HDFS 如何保证容错性？
硬件设备总是会老化的，没有任何一个存储介质敢声称自己所保存的数据不会出现差错。HDFS 实现容错性的方式是通过校验机制与其副本机制。
文件在首次存入 DataNode 时会计算出校验和（checksum）一并存储。在有客户端读取数据时，读取完成后会再次计算校验和，并与已存储起来的校验和作对比，当结果不一致时，则认为该数据块已损坏。这时，会从其它节点中尝试读取这份数据，直到读到正确的数据为止。
2.1.4、HDFS 的系统架构
HDFS 的系统架构中主要有两种角色
- NameNode
- DataNode
NameNode
很多教材将 NameNode 直译为 “名称节点”。虽然这种翻译各种没毛病，但我就是不怎么喜欢，我更喜欢称它为 “管理节点”。
既然 HDFS 是一个文件系统，那么它就必然涉及到要管理每一个文件的 “名称与路径” 以及 “实际数据块”，当然还有最重要的 “每个文件名与其对应数据块的映射关系”。NameNode 负责除了 “实际数据块” 以外的所有数据的管理工作。
DataNode
毫无疑问 DataNode 就是负责管理 “实际数据块” 的咯。
在 HDFS 中，NameNode 只有少数几台，通常的生产环境中会有两台 NameNode 以构建一个高可用的 HDFS 集群服务。Hadoop 目前还提供了一种被称为 “HDFS 联邦” 的机制，允许在一个集群中有多个 NameNode 的存在，不过这种场景不在本篇文章的讨论范围之内。DataNode 的数量通常都很多。
在 HDFS 集群中，NameNode 是至关重要的，只有 NameNode 知道我们的集群中有哪些文件，以及这些文件分别保存在哪台机器的哪个硬盘地址上，这也是我更喜欢将 NameNode 翻译成管理节点的重要因素。
2.1.5、MapReduce
MapReduce 既是编程模型又是计算框架。
说 MapReduce 是编程模型，是因为它的核心思想是将数据的处理拆分为 map 阶段和 reduce 阶段。map 阶段可以简单理解为将数据从外部文件或流中读取进来，并将它们处理成 Key-Value 对的形式以作进一步处理。reduce 阶段可以简单翻译成 “归并” 处理，但其实，归不归并，还得看你怎么编写的程序，我们甚至可以取消 reduce 阶段只执行 map 阶段。
从编程的角度看，MapReduce 就是一套 “编程协议”，只要我们遵循这套协议，就能从头到尾一条龙的客制化我们的大数据处理程序。因此，我们说 MapReduce 是一种编程模型。
说 MapReduce 是计算框架，是因为它不仅能编写大数据处理模型程序。还能运行我们写好的程序。我们在写好程序以后，将它编译打包，然后再通过命令提交到 MapReduce 中去就可以执行了。所以我们也说 MapReduce 是一种计算框架。
总得来说，MapReduce 是一种既简单又强大的框架。说它简单，是因为任何计算需求在它这里只有 map 和 reduce 两个阶段，甚至有些作业仅有一个 map 阶段。说它强大，是因为它几乎可以实现大数据领域所有的计算需求。
2.2、Hive
MapReduce 的功能虽然强大，但是它的开发过程确实是有点繁琐了。当年在 Hadoop 刚发布的时候，多数互联网企业的大数据处理需求都是用于数据分析。而分析师们都对 SQL 很熟，但却鲜有也熟悉 Java 开发的。为了解决这个问题，Facebook 推出了 Hive。Hive 支持使用一种类 SQL 的语言来开发 MapReduce 程序，这种语言被称为 Hive QL，简称 HQL。
HQL 与 SQL 大体上来说是一样的，只是有部分的 SQL 语法在 HQL 上没有而已，但总体来说，影响不大，毕竟 Hive 一经推荐，就迅速得到追捧。
Hive 的工作模式就是将 HDFS 上的数据以特定的数据库表的形式映射在 Hive 上，然后通过 SQL 语句操作这些数据表，Hive 的 HQL 解析引擎会将这些 HQL 语句自动转化成 MapReduce 作业并提交给 MapReduce 运行。说白了就是 Hive 是一个中介，我告诉你相关的 SQL 语句，你帮我把它翻译成 MapReduce 程序来帮我执行运算而已。
2.3、Spark
Spark 也是一种大数据处理框架，它的作用与 MapReduce 是一样的。不过，Spark 的速度可比 MapReduce 要快多了。因为 MapReduce 在作业运行过程中的中间产物都是保存在磁盘上的，而 Spark 则将中间产物直接保存在内存中。磁盘的 IO 速度和内存的 IO 速度岂是有可比性的？于是，在 Spark 推出以后，就立即得到了业界的青睐。
Spark 所使用的编程语言是 Scala，相对于 Java 来说，这是一门比较小众的语言，所以其学习成本会高一点。不过，Scala 真的是一门很简洁的编程语言。当你熟悉了 Scala 的语法以后，你会发现使用 Scala 编程简直就像在和计算机聊天一样。实现同样的功能，Scala 的代码量要远少于 Java。
Spark 的 “野心” 远不止于做一个优秀的批处理框架。在 Spark 的生态系统中，还有Spark SQL、Spark Streaming、Machine Learning、GraphX。Spark SQL 是直接对标 Hive 的。Spark Streaming 则定位于流处理，不过 Spark Streaming 的流处理模式是通过 “微批处理” 的形式来模拟实时流处理的，这在根本上还不是真正的实时流处理，但对于很多企业来说，也已经够了，至少在当下，它够了。Machine Learning 就是机器学习咯，关于这个和 GraphX ，我就不再说什么了。
2.4、HBase
HBase 是当年 Google 三篇论文中的最后一篇 BigTable 的开源实现。它是一种 NoSQL，Not only SQL。它的出现是为了解决传统关系型数据库解决不了的海量数据存储问题的。
HBase 与传统的关系型数据库最大的区别在于它完全不管 “业务”。传统的关系型数据库或多或少都会将一部分业务逻辑包含在内，而 HBase 则是做到了完全不管业务逻辑的地步，数据库就只是用来存储数据的。
HBase 依赖于 HDFS，就本质上来说，HBase 中的数据最终还是要存储在 HDFS 上，HBase 仅仅管理一个数据库中的元数据信息而已。什么是元数据信息？就是名称啊、路径啊、存储位置啊等等等等。是不是感觉和 HDFS 本身很像？是的！
HBase 是按列存储的数据库。就是在一张表中，同一列的数据会被保存在一起。而传统的关系型数据库则是按行存储的。HBase 还有一个优点就是如果某个字段的值为空时，它不会占用存储空间。这个特性就厉害了，因为在很多数据库中，经常会遇到字段值为空的情况，RDBMS 对于空值，也会占用空间来存储 “空值”。在大数据时代，HBase 这一特性可以为企业大大降低存储成本。
HBase 中的数据表可以动态地增加列。HBase 对于列唯一的限定就是必须在建表时指定 “列族”。列族可以创建任意多个，一旦指定，便不可再更改。而列则可以在任意时刻进行增减。这种动态增减列的方式是 HBase 实现其扩展性的重要依据。
HBase 还有一个很重要的特性就是不管你当前操作的表中有多少数据，它总是能做到快速的读写操作。读我们暂且不去讨论，HBase 是如何实现海量数据下机械磁盘的高速写操作的呢？这得归功于它特殊的存储机制，HBase 内部维护了一个 WAL 文件，写请求产生时，首先将数据保存到这个小文件的日志里，然后再将数据放到内存中，在这个时候，HBase 就会告诉发起写请求的客户端：我已经将你发过来的数据保存好了。对于一个小文件的写操作以及内存中的写操作，其速度当然快了，而且还完全不受现有数据规模的影响。HBase 在后面会通过异步的方式将内存中的数据保存到磁盘中，真正实现数据的持久化存储。这就是它写入速度如此快速的原因。
2.5、Zookeeper
Zookeeper 在分布式系统中很常用。它专用于对分布式系统中的各节点做协同服务，说人话就是用于在各计算机之间同步数据用的。
那么，Zookeeper 是如何为分布式集群提供协同服务的呢？其实答案非常简单，集群中各有需要的节点都统一向 Zookeeper 汇报自己的状态，由 Zookeeper 来 “仲裁”。最终集群中各个有需要的节点以 Zookeeper 公布的结果为准来执行各自应该做的任务。
Zookeeper 既然是要提供这种协同服务的，那么就必须要求它的反应速度要非常快，至少要快到不能让 Zookeeper 成为制约集群性能的因素的地步。关于这个要求，Zookeeper 的解决方案就两点：1、限量；2、基于内存。限量是指每个 Zookeeper 的节点只能保存极其有限的数据量，小数据量的 IO 将会非常轻松，同时也由于数据量非常有限，也迫使集群只能将最重要的信息交由 Zookeeper 托管。第 2 点基于内存想必就没什么好说的。
同时，Zookeeper 还必须也得是高可用的，不然，它的协同服务会让人非常没有安全感。Zookeeper 实现高可用的方式是通过 ZAB 算法来实现的，即 Zookeeper atomic broadcast。这里不对 ZAB 算法展开讨论，我们知道 ZAB 算法能够有效保证 Zookeeper 集群的高可用就行了。
2.6、流处理
以 MapReduce、Spark 为代表的大数据处理技术被称为批处理技术，即离线处理。一般常见的场景是在凌晨的时候执行大数据分析作业，在早上分析师、高管们上班后，就可以看到关于昨天的情况分析报告了。
但离线处理终究只能是人类社会发展进程中的一个小阶段，实时数据处理才是人类追逐的目标，也只有实时数据处理才能跟上人类社会发展的进程。毕竟谁也不希望我要到明天才能知道我的钱包在今天掉了。
目前的实时流处理框架主要有三种
- Spark Streaming
- Storm
- Flink
Storm 已经被淘汰。Spark Streaming 本身的模式注定它不适用于未来的场景需求。Flink 才是大势所趋。如果你对实时流处理有兴趣，那一定要着重学习 Flink。毕竟现在已经有越来越多互联网巨头往 Flink 上迁移了。跟着大部队走，虽然不敢保证你也能成功，但至少不会错。
3、职场篇
3.1、如何获取大数据？
技术是通用的，算法也是公开的，唯有数据需要自行采集。业界比较常见的几种采集数据的手段主要有以下几种
- 外部数据库导入
- 日志文件
- 前端埋点
- 爬虫
外部数据库是一个重要的数据来源。尤其电商平台对这种数据来源渠道非常常用。用于 HDFS 和外部数据库中导入导出数据的工具比较常用的是 Sqoop。
日志文件也是一个非常常用的数据来源。而用于自动化迁移日志文件到 HDFS 上的工具是 Flume。
前端埋点是指在前端系统中将用户的一些动作行为部分或者全部上传到后台以供分析使用的。用户在前端的某些操作是不会被记录到传统日志中，更不会被保存到后台数据库中的。但这些动作行为往往又代表着用户的心理状态，对于分析用户行为与刻画用户画像而言还是非常有参考价值的。为了得到这些数据，就有了前端埋点的操作。
爬虫获取数据的方式通常只会出现在某些特定性质的企业里。
另外，社会上其实还有一些企业他们本身就拥有大量数据，并且他们会将部分数据开放出来，供全社会使用。这就是所谓的 “大数据开放平台”。
3.2、如何搭建大数据平台？
大数据平台通常是指一整套用于大数据分析的软件系统。它通常包含以下 3 个模块
- 数据采集系统
- 数据处理系统
- 数据展示系统
数据采集系统包括任何能产生并收集数据的平台与工具，如 App 端应用、Web 应用、原始数据库、原始日志管理系统等。
数据处理系统就是指 Hadoop 生态圈中的那些软件框架了。现阶段 Hadoop 生态圈中的框架能够满足任何业务处理场景要求。工程师们根据实际需求选择并搭建相关大数据处理系统即可。
数据展示系统则是直接面向公司高管的。上一步中处理出来的结果仍然是保存在 HDFS 上的，而工程师们当然不可能直接让公司领导们去访问 HDFS 系统来查询结果。所以我们通常会引入很精美的报表系统，将结果数据导出到外部数据库中，再通过这些专业的报表展示系统展示出来，以供领导层查看。除了公司内部查看用的报表系统外，还有一种 “监控大屏” 在现今也很流行，比如每年双十一阿里巴巴直播时使用的实时监控大屏就是一个数据结果展示应用场景。
除此之外，由于一套数据分析作业流程通常都比较复杂。有些作业还要依赖于前面阶段的执行结果。因此，作业调度也是大数据工程师日常工作中的重要环节。对于某些简单的作业系统，可能直接使用 Shell 脚本加 crontab 就能满足要求了。而复杂一些的，就要用到专业的任务调度框架了。在大数据领域比较常见的任务调度框架有 Oozie、Azkaban。
当然，不是每家公司都有这个精力与金钱来自己动手搭建一套如此庞大的大数据平台的。且不说前期搭建时的投入成本，就是后期的运维成本也许一般规模的公司都难以承受。于是，这些商业嗅觉灵敏的老家伙们就开启了大数据计算服务商业化的时代。
大数据计算服务商业化主要有以下几种类型的服务
- 大数据平台商业化服务
- 大数据云计算商业化服务
- 大数据 SaaS 商业化服务
第 1 种商业化服务是指购买相应的大数据软件框架。提供这种商业服务的公司会将你所需要的软件框架 “打包” 好，让你以一种 “即插即用” 的形式来搭建自己的大数据平台系统。如果不购买这种商业服务的话，我们公司内部的工程师就得自己上 Apache 官网，自行选择对应版本的软件，然后下载、安装、配置并部署运行。由于这些软件框架数量众多，自己来搭建的话，也需要一笔不小的成本。业界比较知名的大数据平台商业化服务公司有 Cloudera、HortonWorks、星环科技等。这些商业化公司除了提供软件外，还会提供相应的技术支持服务。
第 2 种则是将计算环境商业化的模式。上面第 1 种模式中，我们除了不用费心于软件问题外，还是要自行去购买设备，搭建自己的硬件环境。那这种模式，就可以让我们连硬件环境都帮我们解决了。云计算商业化公司比较知名的有亚马逊、Google、阿里巴巴等公司咯。一般而言提供这种服务的公司都会再顺便销售大数据平台软件。采用这种模式的公司，只需要投入软件工程师去开发对应的数据分析程序即可。其它的基础环境问题花点钱，会有专业的人帮你解决的。
第 3 种则是最省心的一种了。我们在讨论到上面第 2 种时，公司还需要投入软件工程师去开发软件。而 SaaS 商业化公司则是连数据分析软件都能帮你解决掉。你只需要将待分析的数据上传到云端，点击一下 “运行” 按钮，坐等分析结果就好了。
3.3、大数据技术都有哪些应用场景？
不知从什么时候开始，大数据这个概念经常萦绕在我们耳边。有的时候就感觉，大数据这个行业是必然会随着时间的推移而出现的。因为不论哪个行业，其积累的数据只会越来越多。数据量的增加，其价值密度也会越来越低，但偏偏其所蕴含的价值又是巨大的，谁能将数据中的价值全部挖掘出来，谁就一定能成为行业翘楚。
目前大数据技术的应用领域主要有以下几个
- 医疗健康领域
- 教育领域
- 社交媒体领域
- 金融领域
- 新零售领域
- 交通领域
无论哪个领域，都可以从大量的历史数据当中找出规律进行相关的 “预测” 操作，从而实现 “智能化” 的目的。由此可见，大数据技术在未来可以有两条路。一条是作为公司内部的数据分析利器，另一条则是为人工智能技术提供坚实后盾。
3.4、大数据行业的软件工程师该何去何从？
在未来，不敢说所有软件行业，至少大数据软件开发行业，其编程难度一定会越来越低。即使是现在都已经如此了。整个大数据分析项目跑下来，要写的代码还真没多少行。大数据开发行业，其重点就不在编码上，而在于系统架构的设计、业务逻辑的梳理之上。
这样一来，大数据行业的软件工程师，除了编码能力，更多的还应将精力放在综合能力的提升上面。如果未来想继续走技术方向，那么就应该多提升下系统架构能力。如果未来想升管理层，想往商业方向发展，那就应该多关注下自己公司的业务，熟悉每个项目的整体运行流程。不管你要选择哪一条道路，一定不要忘记坚持学习，要知道，我们的能力并是随着工作年限的增加就会自动提升的。能力的提升最重要的来源在于我们的思考与总结。而学习，能给我们提供源源不断的思考与总结的机会。
结语
说好只是简单写写总结的，没想到写到这儿时，已经洋洋洒洒大几千字了。自己到目前为止虽然马上就满三年的工作经验了，但我却丝毫不对自己的这个 “三年经验” 头衔满意，因为我前面两年多的时光简直就是白白浪费掉的。那时后的我不懂学习的重要性，每天除了工作就是等待再次工作，导致个人能力停滞不前。现在每每想起从前这段时光，我都无比悔恨。
不过亡羊补牢，为时未晚。在我坚持学习这大半年时间里，我真的感受到了自己尤如蜕变般的变化。尤其这段时间再接触到诸如李智慧老师这般优秀的软件工程师，在为我解惑的同时还激起了我更深入学习的斗志。
李智慧老师说的没错，任窗外时光荏苒，我们必须在学习的道路上大步前行，让时间不仅仅只是日历上的数字，让时光因为我们的付出而更加厚重，而我们如今的这些付出，又会给我们的未来增加无限的可能。
大象正在飞奔，我们身处象背，借助着大象飞奔的初速度发起冲刺，相信我们一定能比以往取得更好的成绩。
为那个在未来更强大的我们而努力！
