这几年来大数据非常的热门，到处都有大数据分析的演讲。 演讲内容通常是宣传各种大数据分析成功的案例。 但实际上大数据该怎么做呢？ 大部份的讨论似乎都仅止于怎么搜集大量的数据， 然后用个工具（hadoop/spark）后就会马上变出商机和钱来。


　　笔者是工程师而非技术或平台传教者，我想用务实一点的方式来看待大数据。 大数据技术最重要的核心在于如何设计可以高性能处理大量数据的程式 (highly scalable programs.)


　　目前大数据相关工作可以粗分几类。有资料系统串接者， 设计大数据演算法实做的人，以及管理大型丛集 (cluster) 的工程师。 很多人对大数据工程师的理解还停留在资料系统串接者的程度， 以为只要将资料汇入某个神奇系统，就能将自己想要的结果生出来。 但实际上数据量变得很大时，我们往往需要自己客制化自己的资料系统，并且撰写特殊的演算法处理之。 以台湾和美国业界而言，第二种工程师是最稀少也需求量最高的。 这本书的目的就是由浅入深的介绍如何成为此类型的工程师。


　　有些人可能会有点意外，为什么资料科学家不在其列？ 因为资料科学从一开始就是和大数据独立的概念。 而且一般而言大多数资料工程师处理的数据量也偏小，使用的演算法也多是 O(N2)以上的复杂度。 阅读本章之后，请不要再把「大数据分析」一词挂在口中了。 只有非常少数能同时精通大数据演算法设计及资料科学的人，才有资格用到这个字。


　　不知道在学习大数据的读者们有没有想过，超级电脑的发明是1960年代的事， 为什么直到近年大数据才红起来？任何科技及技术都有其历史脉络， 学习一点相关历史会让自己在追逐新科技时更清楚自己要解决的问题的定位在哪边。


　　传统上的丛集运算


　　大型丛集电脑设计其实从电脑诞生的年代就有了。 传统上的计算主流偏向科学计算（例如气候模拟、飞弹、流体力学）等 High Performance Computing。 这类型的演算通常用到大量的线性代数、大量的浮点数运算、但实际处理的资料多半不会太大。 事实上，在许多学术及军事机构中，还是有大量的这种超级电脑在进行演算以辅助研究。 它们从传统上就与新进的大数据佔有不同市场， 使用的语言也不同 (fortran还是目前最快的 high performance computing language)。


　　不过随著网路科技的演进，我们有了一个新的大型丛集运算的需求。 我们每天在网路上的各种行为，都会被记录下来：搜寻、逛页面、买东西、逛facebook、看到的广告等等。 将这些数据搜集起来并且拿来算钱，成了新的丛集运算新星。 处理这些数据时，和传统的HPC非常不同。HPC的数据量一般不大，但需要大量的浮点数计算； 大数据技术则反之，数据量很大，但计算相较简单。 与此相对的硬体设计也完全不同。HPC的硬体叫做blade，硬碟很小，但CPU、记忆体、主机板通通都是高档货； 大数据的硬体则通常要求每台主机都要有很大的硬碟，使得很多资料不需要在网路中传输，可以在本机计算就在本机计算。


　　大数据技术架构的起源


　　以下内容节录并翻译自 The history of hadoop 。 原作者有跟最早的hadoop开发者 Doug Cutting 求证过细节，而且得到他的背书！


　　一切源自于 Doug Cutting 在 1997 年开始的搜寻引擎专案 Lucene 。 Lucene 在 2000 年开放原始码，并在 2001 年变成 ASF (Apache Software Foundation)1 的专案。 直至今日，许多热门的搜寻引擎实做 Apache Solr, Elastic search 的底层都还是使用 Lucene 。 不过在一开始的时候 Lucene 只能搜寻很少的东西，而且也只能在一台机器上跑。


　　2001 年底， Doug Cutting 和 Mike Cafarell 将兴趣转向替网页建立搜寻索引， 并开启了一个新的专案名为 Apache Nutch 。 Nutch 是网路爬虫，使用 Nutch 爬下整个世界的网站，再使用 Lucene 建立索引进行搜寻。 如同大部份的开发专案，一开始 Cutting 与 Cafarella 只专注于将功能写出来，之后再最佳化。 但是当欲建档的网页是全世界的时候，无法处理大数据的技术瓶颈就出现了。 当年他们能建档的网页的上限是一亿 (100M)，而且只能在一台三千美金的机器上面跑。 如何处理大量的数据变成当时他们最迫切需要解决得问题。


　　HDFS (Hadoop Distributed File System) 诞生


　　为了使 Nutch 能够处理更多资料，Cutting 与 Cafarella 开始思考多台机器的储存方案。 这储存方案必须要符合以下的需求：


　　不需要传统资料库的 schema (鹰架)


　　一旦资料写入系统就不需要担心资料遗失 (durable)


　　如果有硬体坏掉，系统会自动处理好（备份、转移资料等）


　　自动平衡资料负载。不需要手动将资料从一台伺服器搬到另一台去。


　　他们花了几个月试图实做这些规格，不过就在 2003 年， Google 发表了一篇 Google File System paper 。 里面的描述恰恰好就符合他们要追求的档案系统。 于是在 2004 年，他们就依据这篇 paper 实做出了 Nutch Distributed File System (NDFS.)


　　读者可能会有疑问：为什么不去使用当时其他的分散式档案系统呢？ 当时已经有许多超级电脑的储存方案，为什麽不用这些方案呢？ 笔者目前找不出完整的原因（也许要访问 Doug Cutting吧） 但现有的 HDFS 比其他分散式储存系统便宜大约二十倍，而且性能更好。 而且传统的Xen/NAS等分散式储存系统还需要专门的硬体及机房， 如果当时他们使用这样的方案也许我们就不会看到大数据业蓬勃发展了。


　　Map Reduce


　　有了分散式储存技术还不够。 Cutting 等人当时苦思如何善用手上硬体来进行平行化计算。 尽管当年MPI等HPC平行计算技术已经成熟，但却主要用于小量快速资料传输。 在2004年 Google 又发表了一篇 Map Reduce 的 paper 。 这个平行计算的抽象化非常的通用，从网页的权重计算、字词分析、到网路流量的分析等都可以通用。 本书会以这个概念为主轴介绍如何设计出一系列的演算方式来解决大数据的问题。


　　2005 年七月， Cutting 宣布 Nutch 改写以 Map Reduce 作为其建档的计算引擎。


　　Hadoop 出生


　　2006 年六月， Cutting 将 NDFS 及 Map Reduce 从 Nutch 专案中抽出来， 放在 Lucene 的子专案下，并重新命名为 Hadoop。


　　大约在同时间， Yahoo! 以 Eric Baldeschwieler 为首的团队正在努力研究下一世代的 Yahoo 搜寻技术。 他们相中 Cutting 的 GFS/MapReduce 实做， 并且大胆的决定要以这个 prototype 在未来取代他们当年的搜寻引擎实做。 就在那年 Baldeschwieler 将 Cutting 纳入团队。


　　2007 及 2008 年有许多公司前仆后继的加入 hadoop 的开发，包括 Twitter, Facebook, LinkedIn 等等。而在 2008 年时 Hadoop 从 Lucene 专案中切开来，成为自己独立的专案。许多衍伸的专案也在 2008 年时加入 Hadoop 家族，如 Yahoo! pig, Facebook Hive, ZooKeeper, HBase 等等。


　　之后重要的 Hadoop 编年史：


　　2008 Cloudera 成立


　　2009 Amazon elastic MR 诞生


　　2010 Hortonworks 从 Yahoo! 拆分出来成为新公司


　　2010 UC Berkeley open sourced Spark


　　2012 YARN 诞生


　　2012 Yahoo! 宣布他们的丛集达到 42000 nodes，为当时最大的 Hadoop 丛集


　　2014 Spark 成为 ASF top level project。并开始获得大量的关注


　　Side note:


　　其实 Hadoop 其中一个很有价值的应用是做 BI (Business Intelligence)。 但它的设计架构一开始并不是针对BI起家的，而是更贴近于搜寻引擎建立索引这样的工作。 在 BI 中最关键的事是处理时间序列的资料，资料清理，以及资料整合 (data join)。 以笔者个公司来说，就必须客制非常多的架构来让它变得更适合 BI。 尽管 pig/hive 等上层工具一部分目的也是使其更容易操作 BI 。


　　大数据工程师的核心技能指标


　　看完前一章大数据的历史，读者有没有对产业的发展脉络稍微有概念一点了呢？ 笔者目前在美国工作，就笔者观察其实现在台湾美国都还有非常多大数据工程师的就业机会。 即使大数据这名词稍微退烧（或许是太多招摇撞骗的人吧）， 但随著软体业近年来负载量愈来愈大，对后端处理资料的需求其实也是变得愈来愈高。 无奈资料工程这技能学校不会教，因为没有学术价值。 在业界内除非进入资料团队，不然也不会接触到。 最糟的是，各家公司内部的资料团队素质也良莠不齐，要学到好的资料工程技术真的只能靠运气。 笔者的公司算得上是资料工程做得还不错的，以下为笔者认定的大数据核心技能


　　分析及设计高延展性 (highly scalable) 程式


　　能写出常见的 data operation 如 join, de-duplicate, group-by


　　能处理 data skew （资料过度集中在少数的 key）的问题


　　知道如何选择 map output key, 以及 secondary key sort 的排序设计


　　能验证资料正确性


　　设计 regression test system. 每次资料系统更新都能检验前后处理的差别


　　可以撰写工具检验大量的数据正确性


　　从一开始规划系统就让它具有高度的可验证性，以及严格的验证它


　　将资料工程自动化的能力


　　可以处理资料相依性问题


　　自动处理错误的策略


　　要能 revert & reprocess


　　使用 control table 去控制及追踪不同工做的 state


　　系统维护


　　透过 log & stacktrace 来 debug


　　知道基本的系统平台管理。JobTracker, HDFS 等指令要熟悉


　　了解各种 Map Reduce 参数，可以调校效能参数


　　实事求是的精神


　　做资料工程或分析，最忌讳的就是骗自己。永远不要用猜的，要用资料来验证自己的想法是否正确。


　　各种资料系统设计都有隐藏的代价，不要对这些代价视而不见。


　　挖掘问题先于寻找解决方案。只有完全了解自己的需求后，才能在多种方案中选择最适合自己的一个。


　　以上的技能集中在如何成为大数据工程师。资料科学的训练不记入其中，因为光是达到以上的技能就已经很花时间啦。 当这些技能都练得相当不错时，再跨足资料科学，其实也不太难。 不过通常是分工合作更简单一些，因为学资料科学的人远比资料工程多很多。


　　大数据工程技能树该如何点？


　　初级


　　学习目标：能独立开发 highly scalable 的程式及演算法。更高阶的资料系统设计不包含在内。


　　学习架构


　　建立开发环境


　　写最简易的 SQL operation


　　写中阶的 SQL operation


　　写 SQL 难以办到的功能


　　浅论资料工程架构 (dedup, join, aggregation)


　　开始有能力分析资料演算法的复杂度，以及了解 data skew 的处理策略


　　能透过 log & stack trace 找出自己程式哪里写错


　　高级


　　学习目标：学会许多更深入的技能，并且能规划高阶的资料系统设计。


　　serialization & data collection strategy


　　End to end trace data design


　　control table & automation design


　　lower level API (inputformat, outputformat, etc.)


　　advanced java tricks


　　analyze performance factor


　　MR network cost calculation, advanced MapReduce


　　初级的学习大概一两个月内可以精通。笔者当年就是花差不多的时间无师自通的。高级目标笔者则是经由跟比较年长的工程师学习而来，比较难评估学习时间。