Blink Connectors
总览
Connector 是连接外部数据和blink计算框架的桥梁，也是流计算的入口和出口。目前，blink支持了集团内部绝大多数的上下游（如下图)，详细的接入方法可以见官方文档，本文主要阐述connector设计和使用上需要注意的问题。
Source插件
1. source connector控制消费位点
blink读取上游数据时，会记录消费位点和控制消费速度。结合blink checkPoint机制，source connector会周期性的把当前消费位点存储到rocksDB中。在发生failover的时候，source connector会从上一次成功消费的位点开始重追数据，保证at least once或excatly once的计算语义(取决于任务配置)。这也要求上游插件能够支持从特定位点恢复读，否则将不能保证上游数据的完整性。
因此，blink来取metaq采用的也是pull模式，自己记录消费位点和控制消费，metaq控制台记录的消费进度和消息堆积也是不准确的，只需要关心blink source的delay指标和tps指标即可。
（blink source connector目前也支持notify，但由于notify不支持数据回溯的特性，在发生failover时不能保证数据的准确性，请尽量使用其它类型的上游存储插件。）
2. 上游分区变化时需要重启job
TT、metaQ、Sls、Datahub都存在分区的概念，blink在读取上游数据的时候，会记录每一个分区的消费进度。在上游分区发生变化时，blink会抛出异常，需要重新启动job(有时候还需要调整source的并发度)。
3. 字段解析
- 普通字段解析
Blink SQL用户目前在bayes平台只需要定义好读取的字段和数据类型，source connector便会自动地将源头数据转换成特定的数据类型，非常方便。并且，对于存在metaq中对象序列化的类型，可以定义为binary类型，blink支持通过自定义的source方式来解析。 - 属性字段获取
metaq等一些上游消息中，除了消息体外，还会存在特殊的标记信息，比如sls中带入的tag消息，metaq带入的messageId字段。不同于galaxy需要使用propety_get函数获取，在blink中，可以像普通字段一样定义property字段，只需要在后面加上header关键字即可。比如__ip__ varchar header即可拿到sls属性中对应的字段。
sink插件
1. 日志型和KV型下游
根据sink插件的性质，可以分为两类: 一类是像TT，SlS,Metaq这种没有key，不会更新已写入数据的日志型存储；另一类是像hbase、rds等，需要根据key进行插入和更新的KV型存储。
2. 基于主键去重和批量写
对于KV型存储，为了减少对下游系统的输出压力。blink默认会缓存一段时间或一定数量的数据后根据primary key字段进行去重（跟minibatch的思想也比较类似），然后再批量写入到下游系统。
比如定义了一张hbase表
create table hbase_output(
rk varchar,
rk1 varchar,
rk2 varchar,
f bigint,
PRIMARY KEY(rk)
) with (
type='alihbase',
zkQuorum='hbasetestmaster1.et2sqaxxxxxxx',
zkNodeParent='/hbase-et2sqa-perf',
columnFamily='cf',
tableName='blink_hbase_test',
bufferSize='1000', -- 定义来多少条数据时触发一次写入
batchSize='100', -- 每次写入时batch的大小
batchWriteTimeoutMs='2000' -- 定义过多久时间触发一次写入
);
当有一组数据到达同一个worker时，如
1,2,3,3
1,2,4,3
1,1,3,3
1,3,5,4
2,4,5,6
sink插件会把根据primary key和先后到达的顺序把数据聚合成两条
1,3,5,4
2,4,5,6
