本期我们带大家回顾一下六六同学的直播分享《ChunJun数据传输模块介绍》。

ChunJun数据类型转换

大家一听到「ChunJun数据类型转换」这个概念，可能会联想到上下游之间进行数据交互时会涉及到的隐式转换。如果上游和下游数据类型一致，则不需要对数据进行任何干预，直接进行下发即可。

但是大多数情况下会涉及到两个问题，一是上游的数据源类型和下游的数据源类型不一致。比如MySql的varchar类型要写到HdfsOrc文件里的string类型的话，在上游的表示是varchar，在下游的表示是string，但实际上中间段java的类型都是string。

另外一种情况则是，上下游之间不止数据源类型不一样，数据类型也不一样，除了要做类型的映射之外，还需要对数据本身进行改动。比如，MySql的date类型要写到下游timestamp类型，我们需要进行的操作是把date中的毫秒级的时间戳拿出来，转换成timestamp的类型，再往下游去写。

这样就引出了一个问题，如何建立所有数据源类型之间的映射/转换关系？下面将为大家解答这个问题。

ChunJun目前支持的数据类型映射关系图如下：

以Timestamp为例，如果要写入到Long类型的话，根据上文展示的ChunJun数据类型映射关系图，最终映射到TimestampColumn中，具体流程如下图：

上面这个例子描述的是一个单独的字段，正常情况下，会处理多个字段，这时的类型映射详解情况如下图：

as方法就是数据类型转换的方法。使用这个机制之后，在下游可以只关心需要的数据类型，增加开发效率。

ChunJun数据传输过程

了解完ChunJun数据类型转换后，我们来为大家分享ChunJun的数据传输过程。

在ChunJun中进行同步作业，有两种情况，一是算子链打开的情况，上游的Source和下游的Sink会被合并成一个task，有同一个线程去做调度；二是把算子链进行关闭，Source和Sink各自形成一个task，也有各自的线程去进行调度。

在算子链打开的情况下，上下游数据传输方式可分为两种，对象重用和拷贝。

算子链的好处是可以减少序列化的操作，那么为什么我们还要引入序列化呢？因为ChunJun的特殊性。ChunJun同步作业的话，只有上下游两个算子，且都对接了正式的数据源，读写的时候会导致线程堵塞。因此上限由网络io决定，如果断开算子链，cpu会在一端线程阻塞的时候切换到另外一端。在序列化的性能较高时，线程上下文切换带来的性能下降完全可以被弥补。

经过测试，序列化的性能比对象重用和拷贝高30%左右。

知道要做序列化后，会产生一些思考，带着这些疑问，接着往下看。

下图是ChunJun在进行序列化操作时的数据传输链路图：

同样是序列化一个int对象，对kryo来说，首先需要知道它的类型，然后从高位到低位依次去写入。

DataOutputView则是直接调用一个writeInt的方法，写一句关键代码即可：

UNSAFE.putInt(

this.buffer, 

BASE_OFFSET + this.position, v);

ChunJun序列化实现

ColumnRowData序列化过程采取标志位+实际数据的方式，具体流程如下图：

相对于kryo的序列化来说：

因为数据区一格只占8个字节，且每个index只能占到一位，所以肯定存在一些没法存储在8字节范围之内的数据，可变长度部分就是用来存放数据区无法存放的数据。

看到上文的null值判断区，有些同学可能会好奇这是什么，又是怎么进行操作的。下图将对一个下标为11的数据去做setnull操作，进行简单介绍：