博客

  • Spark上可用的自然语言处理框架JSL NLP

    Spark上可用的自然语言处理框架JSL NLP

    Spark ML Pipeline是一个非常方便的结构,只需要提供其中相应的部件就可以做出很多可以重用的Pipeline。官方自带的ML包中包含了很多常用部件,但是唯独缺少对于自然语言处理的支持。今天群友介绍了一款专门处理自然语言的Spark支持库John Snow Labs NLP。

    John Snow Labs NLP和Spark一样,遵循Apache协议。而且一开始定位就是基于Spark的,没有其他第三方依赖。所有组件都是基于Spark ML Pipeline API的,使用上也没有问题。

    主要的内容包括:

    1. Tokenizer
    2. Normalizer
    3. Stemmer
    4. Lemmatizer
    5. Entity Extractor
    6. Date Extractor
    7. Part of Speech Tagger
    8. Named Entity Recognition
    9. Sentence boundary detection
    10. Sentiment analysis
    11. Spell checker

    这些组件有部分功能和Spark自带的有重复,比如Stop Word Remover,但是多一份选择不是坏处。

     …

  • WebJars中依赖的来源

    相比起后端,前端工作的工具生态可以说是相当丰富。如果你工作在一个前后端分离的项目,那么大家各司其职,也没啥问题。

    如果项目是一个混合项目,即前后端在一个代码库中,那么使用WebJars就是一个相当有吸引力的选项。WebJars可以帮助我们管理客户端所需的前端依赖,而且使用的是我们熟悉的JVM-base工具,比如Maven,Gradle或者SBT。

    通过访问http://www.webjars.org/就可以搜索现有的依赖,并使用它们。如果遇到需要的依赖,但是WebJars并不包含的时候我们就需要自己做点工作的。

    总的来说WebJars中依赖的来源总共分三种:

    1. NPM
    2. Bower
    3. Classic

    如果依赖来自于NPM或者Bower,那么直接点击Add WebJars,然后输入名字选择版本就可以了。

    如果不是通过NPM或者Bower,那么就需要手动去创建ticket等待响应了。

    也可以参考贡献指南(http://www.webjars.org/contributing)自己去提交相关的内容物。唯一需要注意的就是路径,内容物的路径应该在META-INF/resources/webjars/

    我个人体验来说WebJars其实和Jitpack很像,都是自动系统,都是为了方便管理。…

  • 阿里云幸运券

    阿里云幸运券

    最近一个同事想买阿里云,可能是新用户的原因吧。。。价格便宜的令人发指。2核4G内存的机器一年才825元。

    恍惚间记得阿里云是有推荐码的,可以九折,找了半天还是没有看到。。。

    结果一番搜索原来改成幸运券,还是可以优惠一点的,有需要的随意取用吧。

    https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=f8r7ewjo&utm_source=f8r7ewjo

  • 使用Docker多阶段构建生成更小的镜像

    使用Docker多阶段构建生成更小的镜像

    在将源码直接打为Docker镜像的时候,经常纠结的一个问题就是如何获得更小的镜像。

    以一个java项目为例,因为java编译的时候需要jdk,而运行的时候只需要jre,明显jre的大小更有优势。同时由于各种构建工具的存在(比如gradle,maven),下载的构建用的文件也很多,不光是maven的依赖,还有wrapper和一些临时文件。

    之前的做法一直是使用两个Dockerfile,其中一个使用jdk构建出需要的jar文件,然后第二个使用jre直接将jar文件复制进去。虽然效果不错,但是还是觉得麻烦。

    今天使用Daocloud的时候看到了安全构建这个选项(本质就是两段构建),就突然想到Docker会不会已经有了。结果一搜索还真有,亏我还用多Dockerfile构建了很长时间。

    大概使用如下:

    FROM openjdk:8 AS build-env
    ADD . /java/src/app
    WORKDIR /java/src/app
    RUN gradlew build
    
    FROM openjdk:jre
    RUN apk add -U tzdata
    RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai  /etc/localtime
    COPY --from=build-env /java/src/app/build/libs/target.jar /usr/local/bin/app-server
    EXPOSE 8080
    CMD ["app-server"]

    Docker支持的是多阶段构建,所以如果有需要的话,可以从多个不同的构建中获得生成物。…

  • 在Openshift中配置Selenium-Grid

    在Openshift中配置Selenium-Grid

    通过Selenium-Grid我们可以使用一个更灵活的环境,同时还能得到在不同机器的不同浏览器上执行测试的功能。

    Selenium-Grid由一个中心(Hub)和一到多个节点(Node)组成。两者都是通过 selenium-server.jar 启动。如果是手动安装需要先启动Hub,然后再启动Node,Node会通过启动时的配置连接注册到Hub中。

    Docker明显是一个更好的选择,使用这个docker-compose就可以快速启动一个拥有两个节点的Grid。

    hub:
      image: selenium/hub
      ports:
        - "4444:4444"
    firefox:
      image: selenium/node-firefox
      links:
        - hub
    chrome:
      image: selenium/node-chrome
      links:
        - hub

    Docker自然是方便,但是因为有Openshift,所以更希望直接在Openshift上启动一个Grid。这里就需要额外的yaml文件来办了。

    从Github上找到两个可以用的,这是Hub

    apiVersion: v1
    kind: Template
    metadata:
      name: selenium-hub
      annotations:
        description: "A Selenium Grid"
        iconClass: "icon-selenium"
        tags: 
  • 在Openshift Origin 3上运行Spring Boot应用

    在Openshift Origin 3上运行Spring Boot应用

    Openshift Origin是开源的PAAS平台,如果只是为了单机体验,还可以使用minishift。

    我之前使用过Openshift 2, 还在上面运行了一些Spring Boot应用。最近又要开始接触Openshift新版本,所以想着用这个练练手,先迁移旧应用过来一下。

    在Openshift 2时代,我们需要处理cartridge,它定义了一些基本的东西,比如Tomcat,Cron任务等等,如果你需要的不在这之中,还可以使用Diy。也就是说你需要在代码库中提供action hooks,包括start和stop。我当时是自定义了这两个脚本,然后运行了spring boot应用。

    然后到了Openshift Origin 3,我发现我找不到名为Diy的模板了。一番研究才发现居然没有 cartridge,改成images了。当然原因有很多,官方也给出了一篇详细的说明,但是我并不是很关心,我只想知道怎么迁移。

    为了方便的从源代码生成Docker用镜像,Openshift Origin 3使用了s2i,大致原理如下:

    1. 将源代码注入构建用镜像中
    2. 必要的构建步骤
    3. 将构建结果提交并设置启动入口

    我们用Spring Boot应用来举个例子,大概步骤如下:

    1. 将源代码注入构件用镜像,该镜像包含Java(也可以包含Maven和Gradle,我自建了一个包含不同版本的Maven Wrapper和Gradle Wrapper的镜像)
    2. 运行构建脚本生成jar包
    3. 将jar包提交并设置入口为java -jar <jar path> <other args>

    对于具体的脚本名称,s2i又有如下约定

    1. assemble 构建打包
    2. run 运行应用
    3. save-artifacts 提交构建物
    4. usage 使用说明
  • 用Spark MLlib 2.X来驱动你的机器学习工作流

    Spark的机器学习模块在2.x版本正式移动到ml包下,也就是说旧有的包只做维护不在添加新的功能。新的ml包中最大的改变就是使用用统一的工作流模型来囊括所有机器学习相关的东西。主要是以下三个大的目标:

    1. 线性可扩展
    2. 容错
    3. 内建所有的常用算法

    我们的最终产物当然还是模型本身,也就是数学函数。工作流本身只是概念上的东西,并没有影响到本质。如果你喜欢,你也可以把工作流的所有东西拆开使用。

    我们经常说学术界和工业界有很大的区别,比如你看到的ML Pipeline(文档或者文献)大部分长这个样子

    然而真实世界更为复杂,比如长这样

    这之中的主要区别在于数据来源,你在文档中看到的更多是完美的数据输入,干净的数据,一次性的运行,而工业界的数据来源完全不能保证。

    所以更多的时候我们把数据工作分为数据科学和数据工程。数据科学使用R或者Python去构建原型系统,而数据工程使用Java重写对应的实现。

    Spark MLlib 2.x的一个重大改动就是对于模型序列化的优化,也就是说Python或者R输出的模型可以直接被Java载入。

    ML Pipeline的另外一个好处就是隐藏了ML本身的代码,只要内建了足够的常用算法,或者模型能够不同语言通用,那么关于机器学习的核心代码其实是可以被Pipeline组合并隐藏掉具体的实现。

    而工业界还有很多活需要干,比如配置,数据来源,可视化,应用健康监控等等。机器学习确实很酷,但是关注点是不同。

    如果在两边在工作室都遵循工作流模型,并且尽可能重用内建的算法,那么渐渐的工程中就可以集中在数据抽取和最终的输出上。同时最开始输出的原型系统也能够和最终上线的产品系统有一个更高的一致性。…

  • Spring Cloud Function简化函数式编程的开发和部署

    Spring Cloud Function是基于Spring Boot的函数框架,它提供了很大程度上的抽象除了函数编程本身之外的东西,如果你的业务逻辑由多个独立函数提供,那么就可以使用Spring Cloud Function。

    这个是官方的例子

    @SpringBootApplication
    public class Application {

    @Bean
    public Function<Flux<String>, Flux<String>> uppercase() {
    return flux -> flux.map(value -> value.toUpperCase());
    }

    public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
    }
    }

    其中的Function uppercase使我们暴露的函数,默认会直接暴露一个路径为uppercase的API。

    因为Spring Cloud Function是Spring …

  • Spring Boot项目生成器支持Kotlin

    Kotlin因为之前Android宣布正式支持之后成为了Android世界的Swift,也是大火了一把。

    今天使用Spring Boot Initializr生成一个新项目时,突然发现选择的语言中也出现了Kotlin。

    感觉试验一下看一下具体长啥样。

    首先看看buildscript中多了两个插件,一个是kotlin-gradle-plugin,另外一个是kotlin-allopen。前者是语言支持插件,而后者是专门针对Spring AOP等特性应用的插件,它可以把Kotlin把类和字段变成final的。

    对应的插件使用方法为

    apply plugin: 'kotlin'
    apply plugin: 'kotlin-spring'

    而配置Java语言等级的方法也要使用Kotlin的

    compileKotlin {
    	kotlinOptions.jvmTarget = "1.8"
    }
    compileTestKotlin {
    	kotlinOptions.jvmTarget = "1.8"
    }

    其他的变化不大,毕竟是JVM语言,稍微了解一下语法就可以看懂,比如main函数是

    package com.huangyunkun.kotlin
    
    import org.springframework.boot.SpringApplication
    import org.springframework.boot.autoconfigure.SpringBootApplication
    
    @SpringBootApplication
    class KotlinApplication
    
    fun main(args: Array<String>) 
  • Heroku和国内的PAAS服务商

    写完这篇博客,发现一个问题,这里比较的其实本质是App engine而不是PAAS平台。相对的其实应该是Azure的App Service,AWS的AWS Elastic Beanstalk。

    有很多应用目前是放在Heroku上的。Heroku的功能自然没得说,好用简单,各种第三方服务可以很轻易的集成。但是Heroku从中国大陆访问问题很严重,基本处于不可访问的状态,所以就需要找个国内的类似的服务商或者外国服务商但是从中国大陆访问速度可以接受的。

    Paas这种生意一般都是大厂在做,然后比较一番,其实也没有多少,阿里云之前有个ACE后面死掉了,AWS中国还在测试,京东容器服务也是在内侧中,算来算去,功能上和Heroku接近的只有百度云应用引擎,新浪SAE。

    我关注的点主要在于代码能否自动构建,支持语言,绑定域名和价格

    名称 代码自动构建 Java Python Node 绑定域名 价格(Java 512M) 数据库 其他第三方服务
    Heroku 支持 支持 支持 支持 支持 35 支持
    百度云应用引擎 不支持 支持 支持 支持 支持 21 支持 基本没有
    新浪SAE 不支持 支持 支持