大数据动态之2015Q4

Cloudera

Hortonworks

Hortonworks DataFlow 1.1 Released
http://hortonworks.com/blog/hortonworks-dataflow-1-1-released/

MapR

Top 10 Big Data Trends in 2016 for Financial Services
https://www.mapr.com/blog/top-10-big-data-trends-2016-financial-services
Apache Spark vs. Apache Drill
https://www.mapr.com/blog/apache-spark-vs-apache-drill
Turning Data Into Value with Hadoop and Spark – Infographic
https://www.mapr.com/blog/turning-data-value-hadoop-and-spark-infographic
Apache Apex: OSS Incubator Project for Batch and Stream Processing
https://www.mapr.com/blog/apache-apex-oss-incubator-project-batch-and-stream-processing
Mesos and YARN: A tale of two clusters
https://www.mapr.com/blog/mesos-and-yarn-tale-two-clusters
Comparing SQL Functions and Performance with Apache Spark and Apache Drill
https://www.mapr.com/blog/comparing-sql-functions-and-performance-apache-spark-and-apache-drill
MapReduce Design Patterns Implemented in Apache Spark
https://www.mapr.com/blog/mapreduce-design-patterns-implemented-apache-spark
Introduction to Apache Spark with Examples and Use Cases
https://www.mapr.com/blog/introduction-apache-spark-examples-and-use-cases
Distributed Stream and Graph Processing with Apache Flink
https://www.mapr.com/blog/distributed-stream-and-graph-processing-apache-flink
A Quick Guide to Spark Streaming
https://www.mapr.com/blog/quick-guide-spark-streaming

参考

JVM监控与调优

题外话

本文当前的范围是Java 8之前的虚拟机,因为Java 8之后虚拟机的架构有比较大的调整,存储类的元数据信息的永久代被删除了,而是放在虚拟机的元空间。
JDK 7及之前的版本中永久代有如下的特点:

  1. 永久代和堆在内存分配上是相连的;
  2. 永久代的垃圾回收和老年代的垃圾回收是绑定的,一旦其中一个区域被占满,这两个区都要进行垃圾回收;
  3. 永久代一段连续的内存空间,在32位机器默认的永久代的大小为64M,64位的机器则为85M;当然,在JVM启动之前可以通过设置-XX:MaxPermSize的值来控制永久代的大小;

Java虚拟机

Java虚拟机的架构如下图,其中和性能调优相关的组件有三个:Heap,JIT compiler 和 Garbage Collector。
这是一张图片

针对内存堆heap中创建的Java对象,采用的是垃圾回收机制进行处理。垃圾回收在Oracle官网叫 Automatic Garbage Collection,其目的寻找确定堆内存中哪些对象在使用,哪些不在使用,并且删除销毁那些不在使用的对象。
垃圾回收分为三步:

  1. 标记,Marking
    这个阶段识别出哪些对象正在使用,哪些对象不再使用,不再使用的对象标记为可回收的对象,在使用的对象标记为不可回收。在标记阶段需要对所有的对象进行全扫描来做决策。
    这是一张图片
  2. 清除,Normal Deletion
    这个阶段移除那些没有被引用的Java对象,并释放内存空间。
    这是一张图片
  3. 压缩,Deletion with Compacting
    为了更好的性能,需要对不可回收依然使用的对象进行压缩,就是把这一类对象迁移在一起,使得新内存的分配变得的更容易和更快。
    这是一张图片

分代垃圾回收(Generational Garbage Collection)

由于标记和压缩堆内存中所有的对象是十分低效的,并且随着越来越多的对象被分配,垃圾回收的时间也会变得越来越长,因此引入引入了如下的回收策略:按着对象存活的时间窗口采用不同的垃圾回收机制,即是 Minor collections 和 Major collections。如下图:
这是一张图片
其中Y轴标识已分配的字节数,X轴标识随着时间已经被分配内存并且处于使用状态的字节数的情况。从这张图可以看出,只有很少的对象能够长时间需要保留下来,大部分对象只有很短的生命周期。

Java Hotspot Heap结构:
这是一张图片
Hotspot内存由三部分组成:

  1. 持久代,Permanent Generation:存储类和对象元数据的数据的地方,包括类的层级信息,方法数据和方法信息(如字节码,栈和变量大小),运行时常量池,已确定的符号引用和虚方法表。
  2. 年轻代,Young Generation:分为三个区,一个Eden区,两个Survivor区。新生代主要是存放新生成的Java对象,新生代的垃圾回收称为 minor garbage collection。
  3. 年老代,Old Genration: 即是Tenured区,存放在年轻代经过多次垃圾回收依然存活的对象的区域,年老代的垃圾回收称为 major garbage collection。

垃圾回收触发时机

Minor Collection
在Eden空间已满,新对象申请空间失败时,就会触发Minor Collection,对Eden区域进行GC,清除非存活对象,并把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行,不会影响到年老代。因为大部分对象都是从Eden区开始的,同时Eden区不会分配的很大,所以Eden区的GC会频繁进行。因而,一般在这里需要使用速度快、效率高的算法,使Eden去能尽快空闲出来。

Major Collection(Full GC)
对整个堆进行整理,包括Young、Tenured和Perm。Major Collection因为需要对整个对进行回收,所以比Minor Collection要慢,因此应该尽可能减少Full GC的次数。在对JVM调优的过程中,很大一部分工作就是对于Major Collection的调节。有如下原因可能导致Full GC:

  1. 年老代(Tenured)被写满;
  2. 持久代(Perm)被写满;
  3. System.gc()被显示调用;
  4. 上一次GC之后Heap的各域分配策略动态变化;

Garbage Collector

经过发展,Java已有如下的垃圾回收器:

  1. Serial收集器/SerialOld收集器
    Serial收集器/Serial Old收集器,是单线程的,使用“复制”算法。当它工作时,必须暂停其它所有工作线程。特点:简单而高效。对于运行在Client模式下的虚拟机来说是一个很好的选择。
    串行收集器并不是只能使用一个CPU进行收集,而是当JVM需要进行垃圾回收的时候,需要中断所有的用户线程,知道它回收结束为止,因此又号称“Stop The World” 的垃圾回收器。
    Serial收集器默认新旧生代的回收器搭配为Serial+ SerialOld

  2. ParNew收集器
    ParNew收集器其实就是多线程版本的Serial收集器,同样有
    Stop The World的问题,他是多CPU模式下的首选回收器(该回收器在单CPU的环境下回收效率远远低于Serial收集器,所以一定要注意场景哦),也是Server模式下默认的新生代收集器。除了Serial收集器外,目前只有它能与CMS收集器配合工作。

  3. ParallelScavenge/ParallelOld收集器
    ParallelScavenge又被称为是吞吐量优先的收集器,也是使用“复制”算法的、并行的多线程收集器。这些都和ParNew收集器一样。但它关注的是吞吐量(CPU用于运行用户代码的时间与CPU总消耗时间的比值),而其它收集器(Serial/Serial Old、ParNew、CMS)关注的是垃圾收集时用户线程的停顿时间。
    Parallel Old收集器是Parallel Scavenge收集器的老年代版本。

  4. CMS
    CMS(Concurrent Mark Sweep))又称响应时间优先(最短回收停顿)的回收器,使用并发模式回收垃圾,使用”标记-清除“算法,CMS对CPU是非常敏感的,它的回收线程数=(CPU+3)/4,因此当CPU是2核的实惠,回收线程将占用的CPU资源的50%,而当CPU核心数为4时仅占用25%。
    CMS收集器分4个步骤进行垃圾收集工作:
    a. 初始标记(CMS initial mark)
    b. 并发标记(CMS concurrent mark)
    c. 重新标记(CMS remark)
    d. 并发清除(CMS concurrent sweep)

  5. GarbageFirst(G1)
    G1(Garbage First)收集器,基于“标记-整理”算法,可以非常精确地控制停顿。其实这是一个新的垃圾回收器,既可以回收新生代也可以回收旧生代,SunHotSpot 1.6u14以上EarlyAccess版本加入了这个回收器

监控命令

JDK自带的性能调优监控工具,包括:VisualVM、jConsole、jps、jstack、jmap、jhat、jstat、hprof等。
jstack 主要用于查看Java进程内的线程堆栈信息。
例子:

1
2
3
4
5
# jps
6923 HelloWorld
14009 Jps

# jstack -m 6923

jmap 主要用于查看堆内存的使用情况。
例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# jmap -heap 6923 
Attaching to process ID 6923, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.65-b04

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 25769803776 (24576.0MB)
NewSize = 2147483648 (2048.0MB)
MaxNewSize = 2147483648 (2048.0MB)
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 85983232 (82.0MB)
G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 1932787712 (1843.25MB)
used = 1216988784 (1160.6109466552734MB)
free = 715798928 (682.6390533447266MB)
62.96546570759655% used
Eden Space:
capacity = 1718091776 (1638.5MB)
used = 1210401768 (1154.3290786743164MB)
free = 507690008 (484.1709213256836MB)
70.45035573233545% used
From Space:
capacity = 214695936 (204.75MB)
used = 6587016 (6.281867980957031MB)
free = 208108920 (198.46813201904297MB)
3.068067389966804% used
To Space:
capacity = 214695936 (204.75MB)
used = 0 (0.0MB)
free = 214695936 (204.75MB)
0.0% used
concurrent mark-sweep generation:
capacity = 23622320128 (22528.0MB)
used = 9615124536 (9169.697319030762MB)
free = 14007195592 (13358.302680969238MB)
40.703556991436265% used
Perm Generation:
capacity = 64733184 (61.734375MB)
used = 39187912 (37.37250518798828MB)
free = 25545272 (24.36186981201172MB)
60.537593825139204% used

11258 interned Strings occupying 1021928 bytes.

jstat 主要用于查看Java进程的统计信息。

例子1:

1
2
3
4
5
6
7
# jstat -gc 6923 2000 200000
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
209664.0 209664.0 83598.2 39179.8 1677824.0 1677824.0 23068672.0 10786771.2 64496.0 38947.4 21541 11322.520 6 35.315 11357.835
209664.0 209664.0 0.0 48833.8 1677824.0 502293.9 23068672.0 10787056.8 64496.0 38947.4 21541 11325.066 6 35.315 11360.380
209664.0 209664.0 0.0 48833.8 1677824.0 1013386.7 23068672.0 10787056.8 64496.0 38947.4 21541 11325.066 6 35.315 11360.380
209664.0 209664.0 0.0 48833.8 1677824.0 1515312.1 23068672.0 10787056.8 64496.0 38947.4 21541 11325.066 6 35.315 11360.380
209664.0 209664.0 79664.9 0.0 1677824.0 363216.4 23068672.0 10787062.6 64496.0 38947.4 21542 11325.180 6 35.315 11360.494

显示结果标题栏字段含义:
S0C:Survivor 0区容量(Capacity)。
S1C:Survivor 1区容量(Capacity)。
S0U:Survivor 0区使用量(Used)。
S1U:Survivor 1区使用量(Used)。
EC: Eden区容量。
EU: Eden区使用量。
OC: Old区容量。
OU: Old区使用量。
PC: Perm区容量。
PU: Perm区使用量。
YGC: Young GC次数。
YGCT:Young GC耗时。
FGC: Full GC次数。
FGCT:Full GC耗时。
GCT: GC总耗时。

例子2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# jstat -gcutil 6923 2000 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
1.73 0.00 70.22 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.22 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.22 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.22 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.22 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.36 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.36 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.36 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.39 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.42 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.80 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 70.80 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 71.04 40.62 99.85 2764 125.732 0 0.000 125.732
1.73 0.00 71.17 40.62 99.85 2764 125.732 0 0.000 125.732

GC 日志输出参数配置

  • 打开 -verbose:gc 开关可显示GC的操作内容,包括最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。
  • 打开 -xx:+printGCdetails 开关,可以详细了解GC中的变化。
  • 打开 -XX:+PrintGCTimeStamps 开关,可以了解这些垃圾收集发生的时间,自JVM启动以后以秒计量。
  • 打开 -xx:+PrintHeapAtGC 开关了解堆的更详细的信息。
  • 打开 -XX:+PrintTenuringDistribution 开关了解获得使用期的对象权。
  • 打开 -Xloggc:/var/log/gclogs/gc.log gc日志产生的路径
  • 打开 -XX:+PrintGCApplicationStoppedTime 输出GC造成应用暂停的时间
  • 打开 -XX:+PrintGCDateStamps GC发生的时间信息

GC 日志输出样例

Minor GC日志:

1
2015-05-08T15:50:10.113+0800: 5.930: [GC2015-05-08T15:50:10.113+0800: 5.930: [ParNew: 174706K->16932K(184320K), 0.0309770 secs] 201085K->43310K(1028096K), 0.0311100 secs] [Times: user=0.14 sys=0.00, real=0.03 secs]

  • 表示发生一次Minor GC,ParNew是新生代的gc算法,174706K表示Eden区的存活对象的内存总和,16932K表示回收后的存活对象的内存总和,184320K是整个eden区的内存总和。0.0309770 secs表示minor gc花费的时间。
  • 201085K->43310K(1028096K) 表明这个JVM Heap从 201085K 降低到了 43310K。
  • [Times: user=0.14 sys=0.00, real=0.03 secs]表明这次GC的user time是0.14,而real time是0.03秒;( user/sys/real 的解释参见:http://stackoverflow.com/questions/556405/what-do-real-user-and-sys-mean-in-the-output-of-time1 )

Full GC日志:

1
2015-04-08T17:31:19.816+0800: 8317.639: [Full GC2015-04-08T17:31:19.816+0800: 8317.639: [CMS: 603725K->464743K(843776K), 0.6577700 secs] 788045K->464743K(1028096K), [CMS Perm : 40447K->40446K(67100K)], 0.6579650 secs] [Times: user=0.54 sys=0.00, real=0.65 secs]

  • 最前面的数字 8317.639 代表GC发生的时间,是从Java虚拟机启动以来经过的秒数;
  • 表示发生了一次Full GC,有Full说明发生了Stop-The-World,,如果是调用system.gc()方法所触发的收集,将显示(System);
  • 整个JVM都停顿了 0.6577700 秒,输出说明同上。只是 CMS: 603725K->464743K(843776K), 0.6577700 secs 表示的是Old区。788045K->464743K(1028096K) 表示的是整个Heap区。
  • CMS Perm表示GC发生的区域,名称是由收集器决定的。

参考:

http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/generations.html
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
http://www.infoq.com/cn/articles/Java-PERMGEN-Removed
http://docs.oracle.com/cd/E21764_01/web.1111/e13814/jvm_tuning.htm#PERFM169
http://blog.csdn.net/ning109314/article/details/10411495
http://jbutton.iteye.com/blog/1569746
http://buddie.iteye.com/blog/1824937
http://www.cnblogs.com/ggjucheng/p/3977384.html
http://blog.csdn.net/historyasamirror/article/details/6233007
http://sargeraswang.com/blog/2014/02/03/la-ji-shou-ji-qi-yu-nei-cun-fen-pei-ce-lue/

大数据动态之201509

Apache Kylin
Apache Kylin v1.0 发布,分布式分析引擎
http://www.oschina.net/news/65938/apache-kylin-1-0-released

Apache Calcite
Apache Calcite:Hadoop中新型大数据查询引擎
http://www.infoq.com/cn/articles/new-big-data-hadoop-query-engine-apache-calcite

Apache Flink
http://flink.apache.org/

Cloudera
新的快数据存储Hadoop组件,Kudu:
http://blog.cloudera.com/blog/2015/09/kudu-new-apache-hadoop-storage-for-fast-analytics-on-fast-data/
Hadoop细粒度的安全增强组件,RecordService:
http://blog.cloudera.com/blog/2015/09/recordservice-for-fine-grained-security-enforcement-across-the-hadoop-ecosystem/
HDFS Erasure Coding特性
http://blog.cloudera.com/blog/2015/09/introduction-to-hdfs-erasure-coding-in-apache-hadoop/
Spark测试基础库
http://blog.cloudera.com/blog/2015/09/making-apache-spark-testing-easy-with-spark-testing-base/
如何使用Impala对非结构化数据进行分析:
http://blog.cloudera.com/blog/2015/09/how-to-prepare-unstructured-data-in-impala-for-analysis/
BI场景下Impala测试结果
http://blog.cloudera.com/blog/2015/09/how-impala-scales-for-business-intelligence-new-test-results/
揭秘Apache Hadoop YARN:
http://blog.cloudera.com/blog/2015/09/untangling-apache-hadoop-yarn-part-1/
http://blog.cloudera.com/blog/2013/11/migrating-to-mapreduce-2-on-yarn-for-users/
http://blog.cloudera.com/blog/2013/11/migrating-to-mapreduce-2-on-yarn-for-operators/
Impala支持shell执行的动态进度报告(Impala’s debug webpages (http:::25000)):
http://blog.cloudera.com/blog/2015/09/dynamic-progress-reports-in-the-impala-shell/
Cloudera One Platform:
http://vision.cloudera.com/one-platform/

Hortonworks
Microsoft Azure HDInsight对Ubuntu Linux支持,可以支持到Hadoop 2.6:
http://hortonworks.com/blog/microsoft-azure-hdinsight-on-linux-choice/
HDP 2.3 Sandbox在Microsoft Azure Gallery上线:
http://hortonworks.com/blog/hortonworks-sandbox-with-hdp-2-3-is-now-available-on-microsoft-azure-gallery/
Impala与Hive性能对比
http://hortonworks.com/blog/impala-vs-hive-performance-benchmark/
HDP迁移案例:
http://hortonworks.com/blog/migration-to-hdp-as-easy-as-1-2-3-without-downtime-or-disruption/

MapR
Spark on YARN资源分配配置
https://www.mapr.com/blog/resource-allocation-configuration-spark-yarn#.VfoRrSWqqko
https://spark.apache.org/docs/latest/running-on-yarn.html
https://spark.apache.org/docs/latest/job-scheduling.html#dynamic-resource-allocation
SAP HANA与Mapr DP混合架构
https://www.mapr.com/blog/sap-hana-vora-and-mapr-data-platform#.VfoRsCWqqko
Spark Streaming with HBase
https://www.mapr.com/blog/spark-streaming-hbase#.VfoR0SWqqko
MapR对Docker的支持
https://www.mapr.com/blog/how-create-instant-mapr-clusters-docker#.VfoR2CWqqko
https://www.mapr.com/blog/my-experience-running-docker-containers-on-mesos#.Vfoc_yWqqkp

Databricks
Spark Survey 2015调查结果:
https://databricks.com/blog/2015/09/24/spark-survey-results-2015-are-now-available.html
Spark代码调试:实时进度条和Spark UI
https://databricks.com/blog/2015/09/23/easier-spark-code-debugging-real-time-progress-bar-and-spark-ui-integration-in-databricks.html
新版本Spark 1.5上LDA算法的性能提升:
https://databricks.com/blog/2015/09/22/large-scale-topic-modeling-improvements-to-lda-on-spark.html
Spark 1.5 DataFrame API:
https://databricks.com/blog/2015/09/16/spark-1-5-dataframe-api-highlights-datetimestring-handling-time-intervals-and-udafs.html
Spark 1.5发布,在性能、可用性、运维、Data Science API等方面有重大改进:
https://databricks.com/blog/2015/09/09/announcing-spark-1-5.html
http://www.csdn.net/article/2015-09-29/2825825
http://www.csdn.net/article/2015-09-10/2825669

MongoDB
MongoDB性能优化五个简单步骤:
http://www.csdn.net/article/2015-09-30/2825833
MongoDB开发版本3.1.8发布
http://www.csdn.net/article/2015-09-17/2825734
分布式文档数据库MongoDB开发版本3.1.7发布
http://www.csdn.net/article/2015-09-01/2825599-mongodb-317-is-released

参考
逆水行舟,看前行中的Spark
http://www.csdn.net/article/2015-09-21/2825754
微店的大数据平台建设实践与探讨
http://www.csdn.net/article/2015-09-21/2825756
打造数据驱动的组织:第二年
http://zhuanlan.zhihu.com/donglaoshi/20205116
揭开 Growth Hacking 的神秘面纱(上篇)
http://zhuanlan.zhihu.com/qinchao/20190015
京东大数据基础架构和实践—王彦明
http://share.csdn.net/slides/9138
京东数据仓库海量数据交换工具—张侃
http://share.csdn.net/slides/9137
京东大数据分析与创新应用
http://share.csdn.net/slides/9139
LinkedIn架构这十年
http://engineering.linkedin.com/architecture/brief-history-scaling-linkedin
http://colobu.com/2015/07/24/brief-history-scaling-linkedin/
LinkedIn是如何优化Kafka的
http://www.infoq.com/cn/articles/linkedIn-improving-kafka
http://engineering.linkedin.com/apache-kafka/how-we%E2%80%99re-improving-and-advancing-kafka-linkedin
阿里CDN从自建到服务
http://share.csdn.net/slides/8319
系统架构设计-负载均衡和高可用
http://share.csdn.net/slides/12338
OSTC2015-朱照远(叔度)阿里开源经验分享
http://share.csdn.net/slides/13730
Voidbox
http://dongxicheng.org/mapreduce-nextgen/voidbox-docker-on-hadoop-hulu/
深入理解Spark Streaming执行模型
http://www.csdn.net/article/2015-09-13/2825689
Apache Spark 1.5新特性介绍
http://www.csdn.net/article/2015-09-10/2825669
盘点大数据生态圈,那些繁花似锦的开源项目
http://www.csdn.net/article/2015-09-11/2825674
Redis整合Spring项目搭建实例
http://www.csdn.net/article/2015-09-01/2825600
MongoDB开发版本3.1.8发布
http://www.csdn.net/article/2015-09-17/2825734
分布式并行数据库将在 OLTP 领域促进去“Oracle”
http://www.csdn.net/article/2015-09-11/2825678
Gartner 2015新兴技术发展周期简评:大数据实用化、机器学习崛起
http://www.csdn.net/article/2015-09-06/2825620
Hortonworks收购Onyara,启动数据流自动化
http://www.csdn.net/article/2015-09-02/2825612

学习《Impala vs. Hive Performance Benchmark》

原文:http://hortonworks.com/blog/impala-vs-hive-performance-benchmark/
学习如下:

本文是Yahoo! JAPAN针对自己的场景需求进行设计书选型,对Impala和Hive(Tez on YARN)所做的评测。
场景数据和要求:

  1. 数据格式为 Text 或者 gz ;
  2. 每天新增数据文件为10G,数据记录为13亿行;
  3. 数据留存(retention)周期为13个月,共有数据6000G,共有4500亿行;
  4. 每个小时需要生成 15000 个报表(reporting);
  5. 查询条件包含少量的的 grouping ,grouping的条件主要是地区(region)或者性别(gender);
  6. 没有过滤条件查询;
  7. 绝大部分基于时间的报表(report)生成都是周期性的,除了小时报表,还有天报表和周报表;

技术选型:

  1. Cloudera Impala,没提到所评估的版本,估计为最近的版本。当前Impala的最新版本为。
  2. Hortonworks HDP 2.2, Apache Hive-0.14, Apache Tez。

考虑Impala

  1. Imapa查询耗时比较少,一般在几秒到几十秒之间;
  2. 当一次查询的响应时间为15秒,每小时能够执行240次查询;
  3. 针对单位时间内处理量的不断增加,需要考虑通过增加单位时间内的并行查询数量来提升查询的数量;使用Impala遇到的问题是,随着查询并行度的增加,Impala查询的响应时间线性增加;因此,在每天数据更新之后Impala无法自动处理完成所有的批量查询。

考虑Hive和Tez on YARN
Hadoop-2.x, YARN有更好粒度的并行执行控制,Tez引擎能大幅度的降低MapReduce的延时。
YARN和Tez大幅度的增加处理能力,每小时需要处理超过15000个任务。之前的Hadoop 1.0集群,每天已经能够处理100000个任务。

测试验证

测试条件

  1. 计划模拟真实业务场景测试执行近2000个SQL;
  2. 绝大部分查询返回的结果少于 1000 行数据;
  3. 少数查询返回的结果超过100000行数据;
  4. 执行近2000个SQL的并发请求为32;

这是一张图片

测试结果

  1. Hive请求的大部分请求在20秒以内返回,随着返回结果集数据的增加查询时间也随之增加,最长返回时间为70秒;
  2. Impala请求的大部分请求返回在30秒~60秒之间,最长返回时间为10分钟,随着返回结果集数据的增加查询时间大幅度显著的增加;
  3. 在一些低负载(low load)条件的查询中,Impala能够达到毫秒(milliseconds)级返回;如果没有SQL并行化的处理需求,Impala是有效的选择。
  4. 对于要求批处理,并且SQL并行化是必须的场景中,Hive on Tez是更好的选择。

这是一张图片

Hive的并发性
对于单个的HiveServer2实例,我们测试验证多少个并行查询可以被执行,多少并行度的处理是最有效的。
我们以16作为SQL并发执行的提升倍数,衡量的指标是SQL执行的处理时间。
在并发达到64之前查询的吞吐量快速增加,在这点之后开始下降,因此在当前环境下64是最好的并发数。

这是一张图片

结论
对于Hive on Tez,单个SQL执行时间一般为15秒,会随着并行度的提升而增加。(并行度的限制主要依赖于集群的大小和性能。)
在低负载状态下Impala有非常快的响应时间,但并不适合于SQL并行度非常高的场景。
最后的结论是测试者最后选择了Hive on Tez,因为测试者的场景是每小时至少处理15000个SQL请求。

Hortonworks HDP 2.3.0

HDP 2.3 相对于 HDP 2.2.6

  1. HBase版本变化比较大,HBase 1.1.1;
  2. 新增加了一些组件;
  3. Ambari在配置、监控等方面有较大的升级;

新增加的组件:

1. Apache Atlas 0.5.0
2. Apache Calcite 1.2.0
3. Apache Solr 5.2.1
4. Cascading 3.0.1
5. Cloudbreak 1.0
6. SmartSense

版本升级的组件:

1. Apache Ambari 2.1
2. Apache Hadoop 2.7.1
3. Apache HBase 1.1.1
4. Apache Spark 1.3.1
5. Apache Hive 1.2.1
6. Apache Kafka 0.8.2
7. Apache Phoenix 4.4.0
8. Apache Pig 0.15.0
9. Apache Sqoop 1.4.6
10. Apache Oozie 4.2.0
11. Apache Knox 0.6.0
12. Apache Ranger 0.5.0
13. Apache Falcon 0.6.1
14. Slider 0.80.0
15. Tez 0.7.0
16. Storm 0.10.0

Ambari 2.1新特性:

1. 通过Ambari参数配置UI优化;
2. 各项服务Metrics可以进行监控指标添加,通过添加Widgets就可以;
3. 支持Hive, Pig, Files, Capacity Scheduler的User Views界面,可以通过UI执行Hive、Pig语句;
4. 配置 Capacity Scheduler 支持图形化了,更加方便;
5. 支持 SQL User View;
6. 支持机架感应(Rack Awareness)配置:通过Ambari来配置;
7. 支持 Cloudbreak;
8. 支持 SmartSense;

系统要求:

1. Red Hat Enterprise Linux (RHEL) v6.x 或者 Red Hat Enterprise Linux (RHEL) v7.x
2. Oracle JDK 1.8 64-bit (minimum JDK 1.8_40) (default) 或者 Oracle JDK 1.7 64-bit (minimum JDK 1.7_67)

参考:
http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_HDP_RelNotes/content/ch_relnotes_v230.html
http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.2.6/bk_HDP_RelNotes/content/ch_relnotes_v226.html

Oozie:入门概述

Oozie能做什么(What Oozie Does)

Oozie是一个Java Web应用,用于Apache Hadoop的任务(jobs)调度。Oozie顺序的合并多个任务(jobs)成为一个可工作的逻辑单元。其主要是集成了Hadoop技术栈,包括YARN等,支持Apache MapReduce, Apache Pig, Apache Hive, Apache Sqoop等。Oozie使得用户能够通过Java应用或者Shell脚本的方式调度任务。
Oozie任务有两种基本类型

* Oozie Workflow jobs:这种任务是一个有向无环图(DAG, Direct Acyclical Graph),并按着规则顺序的执行,即上一个Action运行完成后才能运行下一个Action。所以其经常不得不等待。
* Oozie Coordinator jobs:这种任务是重复性的工作流,一般被时间或者数据达到可用会被触发。

Oozie Bundle提供一个复合的方式,将多个Workflow jobs和Coordinator jobs打包合并在一起并能对它们的生命周期进行管理。

Oozie如何工作(How Oozie works)

一个Oozie Workflow是一系列编排成有向无环图(DAG)的Action集合。控制节点定义job时间,设置开始和结束workflow的规则(rules)。这样,Oozie通过decision,fork和join节点控制工作流的执行路径。Action节点触发任务的执行。
Oozie触发工作流的action操作,实际上由Hadoop MapReduce去执行。Oozie利用Hadoop技术栈来均衡负载和处理失败。
Oozie通过回调(callback)和轮询(polling)来检测任务的是否完成。当Oozie开始一个任务(task),它的提供了一个唯一的可以回调的HTTP URL,当这个任务完成的时候就通知这个URL。如果任务失败就调用回调URL,Oozie可以设置任务完成。
经常有这种需求,在规则的时间间隔内运行Oozie workflow,处理那些无法预期的有效数据或者时间。在这些情况下,Oozie Coordinator允许你根据、时间或者事件的条件对工作流触发的时机进行建模。在这些条件得到满足之后,工作流任务就就开始启动。
Oozie Coordinator也可以管理多个工作流,是依赖于子工作流的输出结果。子工作流程的输出将会成为下一个工作流的输入。这条链被称为“数据应用管道”(data application pipeline)。

工作流定义

定义一个Oozie工作流,两个配置文件是必须的,job.properties和workflow.xml。
job.properties的环境变量如下:
nameNode hdfs://mycluster:8020 HDFS地址
jobTracker localhost:8034 jobTracker地址
queueName default Oozie队列
examplesRoot examples 全局目录
oozie.usr.system.libpath true 是否加载用户的lib库
oozie.libpath share/lib/user 用户lib库
oozie.wf.application.path ${nameNode}/user/${user.name}/ Oozie流程所在的HDFS地址

workflow.xml示例如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->

<workflow-app xmlns="uri:oozie:workflow:0.2" name="map-reduce-wf">
<start to="mr-node"/>
<action name="mr-node">
<map-reduce>
<job-tracker>${jobTracker}</job-tracker>
<name-node>${nameNode}</name-node>
<prepare>
<delete path="${nameNode}/user/${wf:user()}/${examplesRoot}/output-data/${outputDir}"/>
</prepare>
<configuration>
<property>
<name>mapred.job.queue.name</name>
<value>${queueName}</value>
</property>
<property>
<name>mapred.mapper.class</name>
<value>org.apache.oozie.example.SampleMapper</value>
</property>
<property>
<name>mapred.reducer.class</name>
<value>org.apache.oozie.example.SampleReducer</value>
</property>
<property>
<name>mapred.map.tasks</name>
<value>1</value>
</property>
<property>
<name>mapred.input.dir</name>
<value>/user/${wf:user()}/${examplesRoot}/input-data/text</value>
</property>
<property>
<name>mapred.output.dir</name>
<value>/user/${wf:user()}/${examplesRoot}/output-data/${outputDir}</value>
</property>
</configuration>
</map-reduce>
<ok to="end"/>
<error to="fail"/>
</action>
<kill name="fail">
<message>Map/Reduce failed, error message[${wf:errorMessage(wf:lastErrorNode())}]</message>
</kill>
<end name="end"/>
</workflow-app>

实战命令

上传example目录到hdfs用户oozie根目录(/user/oozie)下:

1
2
3
su - oozie
cd /usr/hdp/current/oozie-server/doc
hdfs dfs -put example example

启动任务命令:

1
oozie job -oozie http://localhost:11000/oozie -config examples/apps/map-reduce/job.properties -run

停止任务命令:

1
oozie job -oozie http://localhost:11000/oozie -kill 0000002-150914143759473-oozie-oozi-W

Oozie Web UI效果图:

这是一张图片
这是一张图片
这是一张图片

参考:
http://hortonworks.com/hadoop/oozie/
http://oozie.apache.org/
http://hortonworks.com/hadoop/oozie/#blog
http://hortonworks.com/hadoop/oozie/#forums
http://hortonworks.com/blog/introducing-availability-of-hdp-2-3-part-3/
https://github.com/yahoo/oozie
书籍:
《Apache Oozie: The Workflow Scheduler for Hadoop》
http://book.douban.com/subject/26348732/

大数据技术百度指数201508

关于大数据技术点的搜索指数,这里只关注一下百度指数的结果。

  1. 当前最热的依次是:Hadoop、Redis、MongoDB、Spark、Storm。可以看到国内Redis、MongoDB的用户很多,有时候比HBase都热,可见热度之高。
  2. 从趋势来看,Spark是最强劲的,Hadoop、Redis表现都很不错。
  3. 从搜索热词看,当前主要表现在入门介绍、安装、教程的需求量非常大。对于使用中的问题、优化议题还不多,对于监控更少。
  4. 当前搜索热词来源Top5的城市:北京、上海、深圳、广州、南京。北京、珠三角、长三角,同时整体上中部IT发展的相对不错。
  5. 用户人群的年龄主要是30~39之间,几乎达到50%,其次是20~29,几乎40%,其他年龄段的人很少。

首先是意外的收获,就是发现Redis和MongoDB在国内这么火,热词竟然超过了Hadoop了,也许是两个比较简单易用,不像Hadoop如今已经发展成为了一个大家族了。
第二个意外是,发现Cloudera、Hortonworks、CHD、HDP尽然不是指数热词,看来一般印象的大数据技术等于Hadoop真的是偏见啊。
第三个意外,发现中部城市IT整体发展的不错,除了上海、南京,还包括:成都、重庆、武汉、长沙、西安、郑州。

趋势研究
这是一张图片
这是一张图片

需求图谱
这是一张图片
这是一张图片
这是一张图片
这是一张图片
这是一张图片
这是一张图片
这是一张图片
这是一张图片
这是一张图片
这是一张图片

人群画像
这是一张图片
这是一张图片
这是一张图片

大数据动态之201508

Cloudera:
Cloudera Navigator路线图
http://blog.cloudera.com/blog/2015/08/whats-next-for-apache-hadoop-data-management-and-governance-cloudera-navigator-roadmap/
NoSQL性能测试开放标准套件YCSB加入Cloudera实验室项目中
http://blog.cloudera.com/blog/2015/08/ycsb-the-open-standard-for-nosql-benchmarking-joins-cloudera-labs/
Spark在TripAdvisor的机器学习应用案例
http://blog.cloudera.com/blog/2015/08/using-apache-spark-for-massively-parallel-nlp-at-tripadvisor/
CDH支持Mesos
http://blog.cloudera.com/blog/2015/08/how-to-run-apache-mesos-on-cdh/
HBase开始支持HBase-Spark模块
http://blog.cloudera.com/blog/2015/08/apache-spark-comes-to-apache-hbase-with-hbase-spark-module/
Navigator Encrypt开始支持YARN Container安全
http://blog.cloudera.com/blog/2015/08/how-to-secure-yarn-containers-with-cloudera-navigator-encrypt/
基于Kafka和HBase的近实时集成架构案例: Santanders
http://blog.cloudera.com/blog/2015/08/inside-santanders-near-real-time-data-ingest-architecture/

Hortonworks:
Microsoft Azure Gallery开始支持HDP 2.3
http://hortonworks.com/blog/hortonworks-sandbox-with-hdp-2-3-is-now-available-on-microsoft-azure-gallery/
Microsoft Azure支持Spark
http://hortonworks.com/blog/microsoft-and-hortonworks-do-spark-in-the-cloud/
Storm的容错Nimbus架构
http://hortonworks.com/blog/fault-tolerant-nimbus-in-apache-storm/

MapR
Spark Streaming with HBase
https://www.mapr.com/blog/spark-streaming-hbase
Apache Drill Architecture: The Ultimate Guide
https://www.mapr.com/blog/apache-drill-architecture-ultimate-guide
HBase架构深度剖析
https://www.mapr.com/blog/in-depth-look-hbase-architecture
HBase Schema设计指导
https://www.mapr.com/blog/guidelines-hbase-schema-design
如何利用Spark进行机器学习的并行与交互处理
https://www.mapr.com/blog/parallel-and-iterative-processing-machine-learning-recommendations-spark

Databricks
Spark 1.5发布,包含Tungsten,其利用代码生成技术和Cache感知算法,大幅度提升运行时的性能:
https://databricks.com/blog/2015/08/18/spark-1-5-preview-now-available-in-databricks.html
https://databricks.com/blog/2015/04/28/project-tungsten-bringing-spark-closer-to-bare-metal.html

mongoDB
mongoDB 2.x版本发布了2个,3.x发布了3个:
http://blog.mongodb.org/post/128063809158/mongodb-306-rc2-is-released
http://blog.mongodb.org/post/127802855483/mongodb-317-is-released
http://blog.mongodb.org/post/126436298628/mongodb-2611-is-released
http://blog.mongodb.org/post/126436227873/mongodb-306-rc0-is-released
http://blog.mongodb.org/post/125850939688/mongodb-2611-rc0-is-released

Redis

参考:
NoSQL大数据分类
http://www.nosql-database.org/
Autodesk基于Mesos的通用事件系统架构
http://www.csdn.net/article/2015-08-27/2825550
QingCloud推出Spark即服务
http://mt.sohu.com/20150826/n419752360.shtml
Spark大数据分析框架的核心部件
http://my.oschina.net/u/2306127/blog/489024?p=1
Hadoop和大数据:60款顶级开源工具
http://os.51cto.com/art/201508/487936.htm
【微信分享】QingCloud周小四:Spark学习简谈
http://www.csdn.net/article/2015-08-07/2825404
【微信分享】李滔:搜狐基于Spark的新闻和广告推荐实战
http://www.csdn.net/article/2015-07-31/2825353
【微信分享】王团结:七牛是如何搞定每天500亿条日志的
http://www.csdn.net/article/2015-07-30/2825342
对七牛云存储日志处理的思考
http://hadoop1989.com/2015/08/02/Think-QiNiu-Cloud/
STORM在线业务实践-集群空闲CPU飙高问题排查
http://daiwa.ninja/index.php/2015/07/18/storm-cpu-overload/
Spark与Flink:对比与分析
http://www.csdn.net/article/2015-07-16/2825232
一共81个,开源大数据处理工具汇总(上)
http://www.36dsj.com/archives/24852
一共81个,开源大数据处理工具汇总(下)
http://home.hylanda.com/show_26_11558.html

总结:

1. Cloudera和Hortonworks都开始注重数据管理和数据治理,Cloudera是通过增强Cloudera Navigator来实现,Hortonworks通过引入Informatic组件Fabric来实现。
2. Spark 1.5发布;
3. HBase、Cassandra是Column Families/Wide Column Store;
4. MongoDB是Document Store;
5. Redis是Key Value/Tuple Store;
6. Neo4J是Graph Databases;

SparkOnHBase(Cloudera)

2014年2月4日,Cloudera宣布CDH支持Spark,在CDH 4.4中引入Spark 0.9。
http://vision.cloudera.com/apache-spark-welcome-to-the-cdh-family/
在引入的时候强调了三点:

1. Machine Learning
2. Spark Streaming
3. Faster Batch

2014年7月,在github上创建了Apache HBase与Spark的集成项目SparkOnHBase
http://blog.cloudera.com/blog/2014/12/new-in-cloudera-labs-sparkonhbase/
https://github.com/cloudera-labs/SparkOnHBase
当前SparkOnHBase主要集中在这几个方面的功能改进:

1. 在MR的map或者reduce阶段对HBase的全量访问(Full Access);
2. 支持bulk load3. 支持get, put, delete等bulk操作(bulk operation);
4. 支持成为SQL engines

2015年8月SparkOnHBase项目有了里程碑似的进展,被提交到HBase的主干(trunk)上,模块名为HBase-Spark Module,HBASE-13992 。
http://blog.cloudera.com/blog/2015/08/apache-spark-comes-to-apache-hbase-with-hbase-spark-module/
https://issues.apache.org/jira/browse/HBASE-13992
HBase-Spark module相比于SparkOnHBase在架构上没有什么变化:
这是一张图片
在具体实现上当前有三点改进:

1. 使用了全新的HBase 1.0+的API;
2. 从RDD和DStream functions操作HBase的直接支持;
3. 简化 foreach 和 map functions;

计划工作有两项:

1. Spark-HBase Module支持bulkload;
2. Spark-HBase Module支持Spark DataFrame DataSource;

https://issues.apache.org/jira/browse/HBASE-14150
https://issues.apache.org/jira/browse/HBASE-14181

实际上集成Spark作为计算引擎的项目还有Hive和Pig:
http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/spark.html
http://blog.cloudera.com/blog/2015/02/download-the-hive-on-spark-beta/
http://blog.cloudera.com/blog/2014/09/pig-is-flying-apache-pig-on-apache-spark/

参考:
http://blog.cloudera.com/blog/2015/08/apache-spark-comes-to-apache-hbase-with-hbase-spark-module/
https://github.com/cloudera-labs/SparkOnHBase
http://blog.cloudera.com/blog/2013/11/putting-spark-to-use-fast-in-memory-computing-for-your-big-data-applications/

学习《Hadoop生态技术在阿里全网商品搜索实战》

资料参见文档:http://wenku.it168.com/d_001428550.shtml
版本:

1. Hadoop: 基于 Hadoop 2.2 的阿里定制版
2. HBase: 基于 HBase 0.94 的阿里定制版

部署方式:

1. 服务总数近1000台,分2个集群;
2. Hadoop/HBase共同部署;

分析:服务器数量可能是2014年初的数据;HBase部署方式可能是RS和DN部署在同一个节点上。
服务器配置:

1. CPU:24/32 Cores
2. Memory:48G/96G
3. Disk:12 * 1T SATA Disk 或者 12 * 2T SATA Disk

分析:服务器配置计算能力比较强,内存和磁盘配置都不是很高。
大数据组件:

1. HDFS + YARN
2. HBase
3. MR
4. iStream
5. Spark
6. HQueue
7. Phoenix
8. OpenTSDB
9. Zookeeper

这是一张图片
分析:

* 对于基于HBase的HQueue是一个创新,当前没有看到更多的资料,无法和Kafka对比。(在性能和TPC上可能Kafka更强大,但通过对HBase的复用做出Queue,很赞。)
* iStream是一个Steaming on YARN的产品,从架构上看很类似storm的设计理念。

这是一张图片
HBase
HBase应用

1. Phoenix(SQL on HBase)
2. OpenTSDB(Metrics on HBase)
3. HQueue(Queue on HBase)

分析:

* 在HBase集群上运行了Phoenix、OpenTSDB、HQueue三种应用,因此HBase具有作为一种数据存储的基础设施的能力。

HBase网页库存储方案

1. 版本从0.25、0.26、0.90、0.92、0.94、0.98逐步升级的。
2. HBase集群规模从30多台持续升级到300多台。
3. HBase Region个数从 1K 增长到 20K。
4. 网页数量从 十亿 增长到 百亿。

存储业务数据的CF如下:
这是一张图片
在HBase/Hadoop的I/O上的优化如下:

1. Compression:Snappy/Gzip
2. Block Encoding:Diff
3. Block Size:64KB - 1MB
4. Block Cache:InMemory
5. Bloom Filter:ROW

这是一张图片
HBase Coprocessor应用
在网页库中使用了三种Coprocessor:

1. Trace Coprocessor
2. Clone Coprocessor
3. Incremental Coprocessor

这是一张图片
分析:

* 如果HBase集群就是两个集群中的一个,那么裸存储容量最大为:12 * 2T * 300 = 7200T = 7.2P,如果考虑到压缩、复制因子、数据冗余、容量冗余,可以存储有效数据约为:8P 数据。 
* 平均每台服务器运行的Region个数:20K/300 = 67 个,这个数字比较符合HBase官方推荐的值。
* Compression方法用了snappy和gzip两种。CF访问频繁,使用snappy,速度快;Raw CF访问较少,使用gzip,压缩比高。
* Block Encoding使用Diff,0.98后改用PrefixTree;
* Block Size的大小为 64KB - 1MB 

实时处理架构
这是一张图片
分析

* Metrics实时采集的流程大约是:HBase -> HQueue -> iStream -> OpenTSDB on HBase
* 流处理的全流程:HBase -> HQueue -> iStream -> HQueue -> iSearch/iStream
* 参见前文分析,猜测iStream是一个类似Storm的YARN框架。

关于阿里搜索自研的iStream的架构与文档参加如下:
这是一张图片
这是一张图片

http://www.infoq.com/cn/news/2014/09/hadoop-alibaba-yarn
http://club.alibabatech.org/resource_detail.htm?topicId=140