自我在美国开始开发 hadoop 相关程式已经一年多
最近开始想把一些所学整理并回馈给台湾的版众
鉴于我当data engineer的时间并没有很长，如果有缺漏的还请高手指点
先简介一下我现在待的公司 OpenX
我们是一家线上广告公司，每天平均流量有TB等级
production data cluster 有三百台机器
storage data cluster 也有两百五十台机器
目前我负责开发并维护production data cluster，以及担任release engineer
不过我还很资浅，也只有接触到整个hadoop生态系当中的一小部分而已就是了
一般提到 Hadoop 时，都是指整套环绕着HDFS, Hadoop map reduce API相关的生态系
诸如高阶语言pig, hive, NoSQL 如 hbase, log batch processing 的 flume 等
现在有些人还会将storm, kafka, spark等近亲也包含进去
一开始接触时，免不了会觉得眼花缭乱
在实务上，基本上上面一个技术就需要一个人来维护
如果你的team没有很大，那请慎选自己的stack
这些技术擅长的面向都不同
HDFS 是大资料储存的架构，通常会需要一个SRE(site reliability engineer)
来维护HDFS还有整个丛集的健康。这个工程师最好有丛集管理及架设的经验
而且会设定及管理监视的程式如nagios
hadoop map reduce API 这是我们这组主要在开发的部分。
如果hadoop是你资料处理的一个环节，而最后产生的报表是要收费的
那我会建议这部分的逻辑还是用hadoop原生的API来开发比较有效率也比较能
保证正确性。我在前东家还有OpenX都是这么做的
pig 这是一个相对高阶的语言。一般来说是用来做ETL(extract, transform, load)
如果你处理的资料对效能要求不高，或是对系统的稳定性要求不高
那这在资料批次处理上是相当方便的选择
hive 相对起pig, hive是更着重于query的语言。它有实做JDBC的沟通接口
所以许多资料呈现软件现在都有跟Hive连结来提取资料。
hbase 以储存大数据为设计精神的NoSQL
我们公司并没有纳入hbase，因为这适合数据储存及query
却不适合data processing (process and update rocords)
Oozie, azkaban, 这两个是hadoop生态系中处理排程的程式
flume, 将 log 批次处理并存入 HDFS
Mahout hadoop中的machine learning framework。前东家和现在公司都没用
我并非data scientist所以不熟:P
Storm, kafka, 这两个是stream processing的程式（虽然略微不同）
spark, tek, 这两个是in memory map-reduce，但都需要大量的内存才会有好效果
以上的介绍都是非常简略，而且网络上可以查的到的结果
很多人做了一些功课后，就会想截长补短
又能处理实时资料，又能储存大数据，还要能即时query(impala, spark) etc.
还要有很好的稳定性且出错时能自己修复等等...
这样是行不通的，这不是堆积木
在选择stack之前，要先了解自己的应用属于哪种类型才行
以下是我经手或是透过认识的人所了解的应用类型
1. 资料批次处理，并透过产生的报表收费
2. 资料储存
3. 透过机器学习来发展策略
4. 实时的资料处理
5. 透过资料收费，但尺度是中小规模
1. 是我在前东家及现在单位在处理的事情
这类型的资料处理，对于资料正确性的要求最高
每一行资料都是要拿来收费的，一个很小的误差，也有可能造成收入或客户信用的丧失
基本上，所有握有大数据的公司都一定会有这一块业务
因为养服务器还有撑起大数据流量的服务是很贵的
没办法让business根据data来收费，怎么可能让business scale
很奇怪的是，那些宣传大数据的人或书都忽略掉这最基础的一块...
处理这种要收费的资料，不太可能实时处理，多半都是批次
这样才能够在系统出问题时，能够roll back或是暂停服务
前面也提过，我在前后公司都是用hadoop map-reduce API来开发
很多时候我们真的需要这种程度的掌控
之后的文章我应该会以如何设计map-reduce的算法来完成一些复杂的计算为主
2. 资料储存
资料批次处理完之后，我们会将原始资料压缩归档
以利其他部门分析研究
这部分我们是将资料转成hive能读的资料型式
3. 机器学习及资料探勘
大数据被大规模宣传的就是属于这个范畴啦
不过，这部分的工程师不一定真的要会写hadoop，很多时候是用hive把资料捞出来
然后再跑python来计算
除非公司特别有钱，不然一般资料储存及探勘的硬件都会比production system差
就人力市场来说，属于3的工程师远比第一种好找的多
在我们公司内的比例大概是10:1 |||orz
4. 实时资料处理
这块我就真的很不熟了。一般来说实时资料处理使用的data store必须要有比较高
的读写速度。而hadoop的核心模组全都是low latency的设计。
如果公司的数据是属于中尺度，视business model可以选SQL or NoSQL
也有超强大的公司如twitter要在大数据尺度上也要玩实时
如果你公司名气大且有钱可以聘请到够多的强工程师，要这样玩也可以...
5. 中小尺度的资料处理
我的前东家其实资料量是属于中小尺度的
原本是用postgreSQL来搞定全部
但是有一些特定的ETL用SQL算真的太慢，还有一些大型join有了index还是不够快
因此把这部分拆出来用hadoop来算
速度差别有多大呢？大约是从四个小时变成三十分钟
我在前东家就发现很多东西不用map reduce写根本没办法算
所以很早就弃hive/pig了
写了这么多关于java的反而很少，几乎都是domain knowledge
我在大数据里面接触的也只有特定面向
这篇文章希望能抛砖引玉，吸引更多强者来分享经验