目前大数据计算通常分为两大类:以Storm为代表的实时计算和以MapReduce为代表的离线计算。实时计算对数据处理时间有着较高的要求,对于延迟阈值大数据界一直没有统一标准,默认是秒级(严格来说实时系统必须保证在某个时间边界内响应,通常是毫秒级或亚秒级,但无论是Spark Streaming还是Storm都只能保证计算时间较低,因此应该属于近实时系统)。离线计算对数据处理时间不太敏感,通常只要求在N+1的时间内看到结果。
谈谈分布式计算中的join
Join操作是数据处理中必不可少的一部分,传统关系型数据库经历多年对高效率join的研究和技术沉淀,已经非常成熟。然而在分布式环境下,数据存在不同程度的异构并缺乏索引等机制,使得传统的join优化技术难以应用。更重要的join是一个全局操作,一台物理机器需要大量网络IO获取join计算需要的记录,而网络却正是分布式计算最为珍贵的资源。以上种种原因导致分布式join与传统关系型join有着较大的差别(当然这仅仅是目前的状况,分布式计算也在不断借鉴关系型数据库的经验)。
分布式计算中的join大部分基于MapReduce计算模型,根据join操作实现的阶段可以分为reduce join和map join两大类,其余都是在该基础上进行优化。
MultipleOutputs实现MapReduce多个输出
在默认的情况下,MapReduce在HDFS上新建一个目录作为输出目录。目录结构如下:
- _SUCCESS
- part-r-00000
- part-r-00001
其中_SUCCESS是一个空文件,表示任务成功,其他是输出文件。输出文件的文件名有三个部分:part是固定的,r表示是reduce的输出,最后的5位数表示是第几个reduce。每个reduce的输出都是独立的,利用这点可以实现将记录分类输出到不同文件。具体方式是将用于分类的字段放到map output的key中,并实现partitioner按照自己设定的规则分类。
没有好平台如何成长?
前段时间Spenser有篇文章,大意是平台就是本事,因为环境在绝大多数人的成长中起到决定性作用,好的平台可以给你带来机会、圈子和背书。
我基本上赞同。从统计学角度说,在好的环境成长能力更强也是理所当然。如果你本来就在好平台,那么你只需要不犯错误就能利用马太效应逐渐积累优势。然而,好平台也是相对的,比如一线互联网公司可以算得上好平台,但公司内不同部门也千差万别,在鹅厂做电商和做游戏是几乎不能比的。所以更加有价值的是,如何在坏环境下减少负面影响?
Hive使用递归子目录作为partition
一般情况下,使用add partition语句为Hive表新增partition:
其中Location默认为最低层目录,如果该目录仍包含子目录,Hive就会报错。
如何估算Flume需要的内存
Spark on YARN两种部署方式的不同
在Spark三种常见的资源调度器,YARN、Mesos和Standalone中,最受欢迎的莫过于YARN。YARN与Hadoop原生集成,可以支持不同计算框架在Hadoop集群上的调度,这使得Spark on YARN无需改变配置就可以与MapReduce共享同一个资源池,避免了资源浪费,节省了开发成本。
Flume Avro source 解压异常的解决方法
最近接入一个新的日志,需要导入历史数据。数据分析师跟我说的时候我爽快地答应了,不就是ETL么,没想到在调用flume接口上卡了一个星期,今天查flume源码终于才搞定。虽然周末都花费在debug上,不过第一次算是解决了一个jira上的issuse(尽管已经关闭),还是很开心的啦。
[译]Spark调优教程中文版
最近用到Spark比较多,于是打算深入学习下Spark的调优。我谷歌下发现网上调优的经验还是比较散乱,所以决定将官方文档翻译下,为国内开源社区贡献一点力量。另外不得不吐槽翻译真是个体力活,90%的时间都花费在IO上了。
记一次排查Spark thrift server OOM错误的经历
平时spark thrift server多用来做探索性的查询,比如验证下数据格式或count一下某天数据数量,都是轻量级的查询,查询效率也比较满意。没想到最近要真正用起来的时候,却遭遇各种瓶颈。