Rec:一个项目的诞生

Rec是一个用来验证和转换数据文件的Java应用。从第一行代码到v1版本成形,仅仅经历了一个半月的时间,作为一个开源项目,在很多方面都有着各种各样的纠结。

需求

Rec的需求源自于我们团队所做项目的特殊性:遗留系统迁移。在工作中,我们需要跟各种团队打交道,每天处理各种来自ETL(Extract、Transform、Load)过程中的数据和程序问题,而整个ETL程序运行起来过于笨重,并且还要考虑准备后端数据和各种验证问题,非常不方便。

其实在此之前,只要有一些简单的程序跑起来、能够进行一些简单的检查,比如唯一性(uniqueness)、关联关系等等,就可以在很大程度上减少我们在ETL过程中花费的时间。并且,这半年多来的实践也证实了这一点。

最初,同事的建议是写一个脚本文件来解决这个问题,这对于程序员来说当然不是什么大问题。但随着使用次数的增加,我渐渐发现一套Python脚本并不能胜任:一方面,面对复杂的业务场景,很难有一套灵活的模式去匹配所有的数据格式;另一方面,随着数据量的增长,性能也成了一个大问题。

于是我开始着手设计和实现Rec。

设计

Rec第一个可用版本的设计共花了七天的时间,基本上具备了我期望的各种能力:

  • 可以自定义数据格式
  • 能够进行简单的唯一性和关联关系验证
  • 支持一些扩展的查询语法:比如,可以验证多字段组合的唯一性
  • 性能上基本能够胜任

Rec面向的数据文件格式是类CSV的文件,包括其他的一些使用分号(;)或者竖线(|)来做分隔符的文件。出于习惯,文件的Parser并没有选取现成的库,而是我自己按照Wikipedia和RFC4180的规范写出来的,基本上能够解析所有类似的文件。而且还有一个意外的发现:用空格做分隔符的文件(比如,某些日志)也是可以支持的。

对于每一条数据,Rec提供了两部分组件,一部分是数据本身,另一部分是该数据的访问器(accessor)。访问器提供把字段名转换成对应数据项下标的功能:跟Spring Batch中的FieldSetMapper很像,当然在其之上还多了一层语法糖。

一个典型的accessor format如下:

first name, last name, {5}, phone, …, job title,{3}

其中,“…”表示中间的字段全部可以忽略,{3}和{5}是占位符,表示在这些字段之间有如此多个字段也是可以忽略的。而由“…”分割成的两部分也是有差异的:在其后的字段使用的是类似Python的负数下标;换句话说,我并不需要知道本来的数据有多少个字段,只需要知道我要获取的倒数第几个是什么就可以了。

Rec的验证规则也是从简设计。由于最初的需求只有唯一性检查和关联关系检查,所以第一个版本里面就只加入了这两个功能,语法如下:

unique: Customer[id]
unique: Order[cust_id, prod_id]
exist: Order.prod_id, Product.id

每一行表示一个规则,冒号前面是规则的名字,后面是规则所需要验证的数据查询表达式。对于查询表达式,这里需要提一点,本来是设计了更多的功能,比如过滤和组合等等,在后面扩展的时候发现在语法上很难实现得更直观而且方便使用,于是就决定改用嵌入脚本引擎的方式来解决。

另外Rec第一个版本发布只有Kotlin运行时的依赖,所以完整的Jar文件只有2MB。同时,只要给对应的数据文件提供.rec格式的描述文件,再在同一目录创建一个default.rule来加入各种检验规则,就可以运行、然后得到你想要的结果了。

扩展

Rec的第一个版本在某些方面是达到预期结果了的。但在那之后就发现了一些很重要的问题:首先,我们另一层的需求并没有得到满足:Rec能够帮我们验证并且找到有问题的数据,但是不能够按需来选择我们想要的内容;其次,在检查数据的同时,我们也隐含地有集成和转换数据的需求,Rec也不能够满足。

于是第一个星期以后我开始考虑对Rec进行扩展。首先是在同事的建议下把乱成一坨的代码分成多个module;其次考虑加入前面提到的过滤和格式转换的功能。

第一个步骤勉强算是完成了,但是卡在了第二步上:对于转换的规则,要不要和验证的规则放在一起?如何对这两种规则做区分?如何在过滤器中设计变量引用等细节?每一个问题都让我纠结了很多,直到最后决定放弃这一步,直接通过引入脚本引擎来实现:从最初hack Kotlin编译器的嵌入版,到决定用JavaScript,到放弃Nashorn转而用Rhino,中间虽然辗转几次又遭遇了不少坑,但毕竟有成熟的社区经验辅以指导,还是顺利地走了下来。

Test Driven Development vs Test Driven Design

其实直到现在Rec的测试也只有少量的一些。而且在拆分模块的时候,因为测试代码之间的依赖比较多,并没有做拆分,所以基本上还是集中在一个模块中。当然这也是很多时候我自己做项目时的一个习惯:并不会完全以TDD的方式来开发,而是把单元测试作为一个验证设计思路的手段。因为很多时候思路转变的太突然,不实现的话估计下一秒钟就完全变了。而且,作为一个简单的工具类程序,并不需要重度面向对象的设计,如何规划和设计流畅易用的接口就成了必须考虑的一个问题。这个时候测试的设计性变得更明显。

另外,对于Parser这种东西,测试是必不可少的,但是要TDD一个Parser出来,基本上就是在给自己找活干了。所以这种时候,我会先加一些基本的case,来确保能够正常的实现功能,然后再引入一些比较corner的case来确保实际的可用性。对我来说,这是完全没有问题的:当然后面的实践验证了这一点,Rec没在解析文件方面出现过任何问题。

Kotlin vs Java(Script)

最初采用Kotlin就是因为它有很多优点,而且这些优点也确实影响了Rec的设计,但是因为各种原因,还是被替换了两次。首先迟迟不发布的1.1版本和编码兼容性的诸多问题,导致我决定用原生Java换掉Kotlin。当然,这也导致了不得不强行舍弃很多好用的编译期检查和语法糖,以及一个用来做bean mapping的组件。

至于采用JavaScript,则是另外一个问题。

众所周知,JSR223定义了一套JVM平台的脚本引擎规范,但是作为一个强静态类型的编译型语言,Kotlin想要契合这套规范还是很困难的,于是无论是官方的实现还是Rec的解决方法,都不是很好:

首先你要启动一个JVM来执行这个脚本的动作;在这个动作里面,启动第二个JVM要调用Kotlin的编译器来将该脚本编译成class;然后这个编译器会再去利用自定义的classloader来加载和执行这个class文件。当所有的功能都集中在一个Jar文件里面的时候,每次都要选择指定classpath等选项,实现非常复杂。而且,由于第二次执行的Kotlin编译器是识别不到你已引入的kotlin-reflect类库的(因为已经统一包装到rec的jar包里面去了),就会导致脚本中bean mapper的一些功能根本不能使用。万般无奈,选择采用更成熟的JS引擎。

当然选择JS带来的一个好处就是,有更多人可以拿来就用了,而且,最新的Rhino提供了CommonJS扩展,能够顺手require所需的JS文件,在复用和模块化方面也能够有不少提升。

技术抉择

除了部分Parser相关的代码外,Rec采用的基本都是不可变的数据结构:一方面是因为使用Kotlin;另一方面,在整个模型里面并没有特别的需求会涉及更改数据。唯一的担心是内存占用,但是后来发现这部分担心也是不必要的,因为所有内存的瓶颈只在数据文件的Parser上,项目中的数据条目动辄数十个数据项,几十万条数据,再加上每次parse都会把一个字符串分割成多个,最后再合并到一个大的集合里面,在最开始设计的时候没有考虑这一点,轻轻松松就爆了JVM堆。这也是后期需要着重优化的一个方面。

另外一个点是关于异常处理。对于Java应用来说这是个巨坑:异常本身并没有问题,但是由于checked和unchecked的区分以及众多设计哲学的不同,所以就成了争议点所在。在这里我参考了Joe Duffy的做法。对于严重的不可重试的错误,比如文件找不到,空指针异常,下标错误等,直接让程序die(没错,就是PHP中的那个die),至于数据格式错误等问题,更多的做法是做一条记录然后选择继续。当然这一套东西并不依赖Java的异常系统,只是作为一个设计原则来应用,毕竟这不是一个App server,并不需要高可用的保障,相反这种fail fast的直接反馈更有助于发现和解决问题。

在类型系统上,最初实现Rec的语言是Kotlin,它提供了一套比Java略微高级一些的类型系统。当然主要的点还是在于nullable:在功能上,nullable与Java 8的Optional类似,用来容纳可以为空的值,同时能够有效避免空指针异常;在实现上,比Java略微高出了一点的是,非nullable的对象必须被初始化并且不容许为null。这直接解决了Optional对象为空的尴尬问题。

当然,由于运行时的依赖还是无法避免地使用JVM,而且没有自定义值类型的支持,在使用Kotlin,特别是跟Java标准库和其他框架结合使用的时候,还是会遇到空指针的坑。但是在这一点上,Kotlin给我们开了个好头,比如在后面convert到Java的过程中,我也尽量保证各种对象都是final并且被非空初始化了的。

结语

当然也许很多人会说,Unix那套工具用的很顺手的话,上面说的这些都不是问题,其实Rec本来的思路也是来自于它们:accessor来自于awk的列操作模式,scripting中的过滤器来自于sed和grep,链式调用源于管道。Rec也只是在这些思路之上加了一些方便的操作而已。但是对于我个人来说,这种折腾其实是在检验我自己的理论和思考,更别说还提升了项目的生产力。也许哪一天实在受不了了,还可以拿C++和Lua重写了呢。毕竟,生命不息,折腾不止。

硬广的最后,欢迎来贡献文档、issue、PR、星星和转发分享: https://github.com/rec-framework/rec-core


更多精彩洞见,请关注微信公众号:思特沃克

Share

后现代的系统编程语言——C++

C++作为一门经典的编程语言,从上世纪八十年代起至今一直被广泛应用在系统开发和高性能计算领域。近几年来随着各种编程语言和范式的兴起,C++的身影渐渐淡出了人们的视野。但是作为一个仍在不断进步的语言,C++在最近几年飞速发展,已经具备了现代语言应有的特性,而且也有了许多已有的和正在进行的新的拓展。

经典的C++

作为C语言的超集,一方面,C++集成了C在系统编程优点,能够精确的控制内存中的每一个bit;另一方面,提供了丰富的抽象机制和编程范式,引入了面向对象、泛型编程和函数式编程等风格。因为这一点,C++拥有了与C媲美的运行时性能,另一方面,也简化了C语言带来的领域建模的难度。但是因为C++的整体设计结合了多种风格,几乎相当于嵌套了几个小语言的一个庞大的系统,这也使得C++的整体易学性和易用性上有些差劲。同时,由于标准库更新跟不上需求,在诸如Concurrency/Network等应用层的软件设计方面逐渐被Java等后来者取代。而且,各个C++厂商对编译器的实现并没有完全参考ISO标准,也造成了很多跨平台可移植性和兼容性问题。

现代C++

C++在最近几年进行了几次探索和蜕变,让整个语言变得更具备现代化的特色。

资源管理

RAII(Resource Aquiration is Initialization,资源获取即初始化)作为C++的特色之一,被广泛地应用到C++的程序中。RAII通过堆对象的生命周期来控制资源(包括堆内存、文件句柄、网络连接等)的生命周期,使得资源管理变得更加自动化,同时也避免了引入垃圾回收带来的运行时负担。但这种模式有一个很重要的问题,就是当需要对资源进行共享时,需要做更多额外的工作来进行检查和同步等工作。

作为更现代的资源管理方式,C++11中引入了两种智能指针,std::shared_ptrstd::unique_ptr。前者拥有线程安全的引用计数,后者则是通过所有权(owenrship)转移来控制资源的生存周期。C++11中也引入了右值引用和移动语义,来避免资源传递的过程中的不必要的复制。

与Rust中的生命周期(Lifetime)和所有权(Ownership)的概念类似,C++的std::unique_ptr在每一次值传递的时候将自身持有的资源转移到赋值的目标,同时结合移动语义,将赋值过程进一步地优化。

Lambda

Functor作为C++ STL的一个重要组件,也是C++中被使用很多的一个功能。一个Functor其实就是一个重载了operator()的类的实例对象,这种对象配合C++模版的行为,可以被简单看成一个函数来调用,所以被称为Functor(函子)。但是,由于C++对于匿名类和内部类支持并不够好,使用Functor必须提前进行设计。一方面不方便使用,另一方面,定义和使用分离,对代码的组织和理解也造成了一定的困难。

首先,lambda作为Functor的替代品,解决了不能即时定义并使用的问题。配合STL中的容器和算法,lambda也能将C++的函数式风格发挥到极致。其次,出于C++一贯对性能和抽象的考虑,引入了lambda capture的概念,使得对象的生命周期能够绑定到lambda表达式,也就能够构建出闭包对象(closure)。另外,C++14中加入的generic lambda,增强了lambda的类型推导算法,在不损失类型安全特性的基础上,让组合式编程(Combinatorbased Programming)更加易于实现。

并发

C++设计的初期,并发并未作为核心的语言特性考虑在内。并且,线程等并发模型在不同平台之上也有各种不同的实现,构建一个统一的并发模型也很困难。

C++11中重新设计了C++的内存模型,在保持原有兼容性的基础之上加入了并发的内容。同时标准库中也加入了线程(<thread>)、信号量(<condition_variable>)、互斥锁(<mutex>)和原子操作(<atomic>)等内容。同时也在此基础上封装了future/promise模式和async等操作。

元编程

C++自身对元编程提供了良好的支持。作为主要组件之一的模版,提供了编译时的数值计算和类型计算。但一方面由于使用模版减慢编译速度,另一方面,在使用模版的时候,非常难以调试和排错,这让很多人望而却步,甚至对基于模版的STL组件也有一种畏惧感。

C++11中对元编程支持做了加强。首先是把type traits作为标准库引入,能够给模版提供一套直观的约束,也让类型作为C++中的第一类值(first-class value)存在;另外constexpr的引入简化了编译时的值运算,配合用户自定义字面量(user-defined literals)以及可变参数模版(varadic template/parameter pack)等特性,让C++能够更方便地定义内部DSL。

Bright Future

作为一门经典的编程语言,C++至今还在不断地更新着。即将到来的C++17中,正在筹备着这些重要的特性:

-更丰富的标准库:C++中对File System、Network等重要的组件进行了标准化的支持,

-Module TS:模块化提案,用于替代继承自C语言的头文件,简化C++的编译模型和模块依赖,

-Concepts TS:用于增强类型约束和类型推导,同时也简化模版的用法,

-Reflection TS:提供编译期静态反射的支持,简化和增强type traits,提供更丰富的元编程功能。

Conclusion

可以看到C++发展至今一直都走在时代的前列线上。一方面,增加了更多适合应用和系统开发的组件,另一方面,通过语言特性的扩充来简化抽象复杂度。作为这样一个兼具新生特性和历史责任的编程语言,足以预见其应用的广度;同样,更多的系统级开源项目,像Mesos等,也选择C++作为主要的编程语言。有足够的理由让我们相信,C++正在重获新生。

Share