Oozie 的 ShareLib 内部已经发生变化，从 CDH 5.0.0 开始，以下是你需要知道的

在一年前的这篇博客，我介绍了如何在 CDH 4 中使用的 Apache Oozie ShareLib。但是 ShareLib 在 CDH 5 发生了变化，尤其是目录结构，之前提及的一些内容现在已经过时了(这些变动在 OOZIE-1619 可以看到)。

目录结构变化

在 CDH 4.x 中，ShareLib 的目录结构类似下面：

1
2
3

/user/oozie/share/lib/distcp/*.jar
/user/oozie/share/lib/hive/*.jar
/user/oozie/share/lib/...

但是在 CDH 5.x 中，目录新增了一个层级，包含了一个时间戳

1
2
3

/user/oozie/share/lib/lib_20140311155426/distcp/*.jar
/user/oozie/share/lib/lib_20140311155426/hive/*.jar
/user/oozie/share/lib/lib_20140311155426/...

ShareLib 的位置仍然像之前那样通过 oozie.service.WorkflowAppService.system.libpath 配置参数指定。lib_<timestamp> 目录会被创建在该目录下，如上面示例所示。

环境

• CDH 5.15.2

问题描述

由 Sqoop 从 DB 导入的一张数据表，在 Hive 中能够正常查询。但是将数据导到 Impala 并使用 Impala 进行查询时，若涉及到数据表中的某个列，如 select regip from xxx where xxx , select * from xxx where xxx ,会出现上图的异常。异常的大概意思是 Schema 不兼容，列数据的类型为 STRING， 但数据类型为 int32。

    不经意间已经12月份了，又到了一年的尾巴，忙完一周的工作能在周末暖暖的被窝里睡个懒觉，真的是舒服得不要不要的。转眼已经毕业离开学校快半年，在现在的公司从实习到正式工作也有一年多了，而自写下第一行代码到现在也有四年多了吧，真的不得不感概时间过得真快。回想起来，成为一名程序员也算是机缘巧合，在大学之前从没接触过也没打算过从事程序员这行。当年高考完，哈哈，可能也是出于理科生的缘故吧，与大多数童鞋一样报的不是机械就是土木专业，不过因为分数不够就只能到软件工程了。要说没有失望那是不存在的，毕竟当时我完全不知道软件工程是怎么样的一个专业（其实我对填报的其他志愿也没什么概念，大学前还真的是只会做题啊），反正当时脑海里仅有的一点认识就是百度里面宽泛的定义#摊手。就这样我也算跟 coding 就结上了，不过大学时从 C 语言，Java 语言到计算机网络、数据库理论、编译原理、操作系统等等的学科，在当时看上去似乎比不上什么编程框架来得有用，但现在看来却是真真切切的影响了我。

启动器(Launcher)是一个 Oozie 进程，用于运行工作流(workflow)中的单独一个 Action 的客户端

介绍

启动器是 Oozie 执行模型中非常关键的一部分，下面的架构图向我们展示了 Oozie action 是如何工作的。

JVM Agent 设计实现

在上一篇文章中已经对 JVM 性能监控 Agent 所涉及的技术和 API 做了简单的介绍，接下来第二部分将探讨 JVM 性能监控 Agent 的设计实现以及一些问题的解决思路

最简单的 JVM Agent 实现

通过对 Java Agent 以及相关 API，我想大家应该想到一种 JVM Agent 的设计方案，基本思路就是利用 Java Agent 的先于 main 方法执行而且无需修改应用程序源代码的特性，实现一个 Java Agent 的 premain 方法，并且在 premain 中启动一个独立线程，该线程负责定时通过 java.lang.management 包提供的 API 收集 JVM 的性能数据并打包上报，如下图所示：

前言：如标题所示，接下来我要介绍的是一个用于监控 JVM 性能的工具(JVM Agent)，JVM 是每一个 Java 开发工程师或多或少都有所接触了解的，不管是在求职面试的过程中，日常的 Coding 中，还是在处理 Memory Leak 或者 GC 等问题时。目前公司随着业务发展，一个对外的服务可能运行于众多台 JVM 实例之上，如何及时发现处理集群中的JVM出现的问题成了棘手的问题，这就是 JVM 监控工具出现的现实意义。

本文将分为两部分

第一部分: 将简单介绍 JVM 性能监控工具以及所涉及的技术和API，为之后的设计实现部分准备基础

第二部分: 将探讨性能监控工具的设计实现以及 ClassNotFoundException 等问题的处理

简单认识 JVM 监控

可能部分读者对 JVM 监控还没有基本的概念和认识，所以本节我先简单聊聊 JVM 性能监控工具（JVM Agent）的开发背景，对监控工具的要求以及借助这个工具能干些什么。

前言：对于跨域请求，很早之前就有去了解过，但因为一直关注的都是服务器后端开发，故也就仅仅停留在概念的理解上而没有机会在实际开发场景中接触得到。最近在公司的开发任务中，需要接触到 Ajax 跨域请求，由于之前没有遇到过类似的问题，在开发过程中遇到不少困难，也查阅了不少资料和博客。在这过程中收获了不少，故特意写下以下文章总结，如果文章有什么不足之处，还望各位指出。

什么是跨域请求

概述

​ 在 HTML 中，<a>, <form>, <img>, <script>, <iframe>, <link> 等标签以及 Ajax 都可以指向一个资源地址，而所谓的跨域请求就是指：当前发起请求的域与该请求指向的资源所在的域不一样。这里的域指的是这样的一个概念：我们认为若协议 + 域名 + 端口号均相同，那么就是同域。

​ 举个例子：假如一个域名为aaa.cn的网站，它发起一个资源路径为aaa.cn/books/getBookInfo的 Ajax 请求，那么这个请求是同域的，因为资源路径的协议、域名以及端口号与当前域一致（例子中协议名默认为http，端口号默认为80）。但是，如果发起一个资源路径为bbb.com/pay/purchase的 Ajax 请求，那么这个请求就是跨域请求，因为域不一致，与此同时由于安全问题，这种请求会受到同源策略限制。

前言：在之前的文章中我已经对如何使用 CORS 处理跨域请求进行了介绍，在本文中，我将介绍如何在 CORS 跨域的情况下设置和获取 Cookie，以及在处理跨域 Cookie 中可能遇到的问题：The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*'

CORS 跨域中的 Cookie

概述

​ 基于安全方面的考虑，在浏览器中无法获取跨域的 Cookie 这一点时永远不变的。但是我们处理跨域请求时有可能会遇到这样的情况：一个网页与域为bbb.cn的服务器正常发送请求和接收响应，同时这个网页也需要跨域访问aaa.cn服务器。

​ 众所周知，浏览器会在准备发送的请求中附上所有符合要求的Cookie，故在上面的情况中浏览器会自动处理网页与域为bbb.cn的服务器之间的 Cookie；但是在 CORS 跨域中，浏览器并不会自动发送 Cookie，也就是说，浏览器不会处理网页与aaa.cn服务器之间的 Cookie。

前言：众所周知，出于安全考虑，XMLHttpReqeust 对象发起的 HTTP 请求必须满足同源策略（same-origin policy）的规定，否则浏览器将会对该请求进行限制。虽然同源策略的实现带来的Web安全的提升，但是却为一些正规的跨域需求带来不便，故此衍生出了若干种绕开同源策略的跨域方案，其中 JSONP 就是使用的比较多的方案，但 JSONP 是一个非官方的跨域协议同时也只支持 GET 请求，而后来 W3C 推出 CORS 协议相比 JSONP 支持更多的方法也允许使用普通 XMLHttpRequest 发送请求，所以我们有理由使用更加现代的跨域方案。关于 CORS 的详细内容可以阅读文章HTTP访问控制（CORS） 。

下面我将介绍如何在 Spring MVC 中实现 CORS 跨域方案，但由于 Spring MVC 在 4.2 版本中才开始原生支持CORS ，故我将介绍两种实现方法，一种是借助 Servlet Filter 实现，而另一种则是直接使用 Spring MVC 的 @CrossOrigin 注解实现。

引言：由于前阵子有点时间，再加上一点点兴趣，于是就用 Python 语言写了一个爬虫对平时经常浏览的社区——知乎的用户信息进行抓取，并最终成功抓取 70 W 左右的用户信息。尽管在 fix bugs 和完善优化的过程中收获不少，但是让这 70W 条记录烂在数据库终归不合适，所以作为一名非数据挖掘、大数据分析方向的普通准 Java Developer，我就只能对这部分的用户信息进行简单的分析。

注：由于数据样本仅有 70W 左右，获取方式是从一个核心用户开始获取其所关注的用户，以此类推。所以下面的的数据分析并不能保证准确，但是趋势应该大致相符。