[Recap] 云栖大会 | 如何基于 Pulsar + Flink 构建下一代实时数据仓库

 

2019 年 9 月 25 至 27日，杭州如火如荼地举办了 2019 云栖大会。今年，大会以开发者为主角，聚焦数字经济为核心议题，汇集了各类技术大咖和开发爱好者。此外，还有妙趣横生的《程序员吐槽大会》专场，现场笑果满满。

 

此次活动，申毅杰也代表 StreamNative 参与了大数据生态模块，发表了主题为《基于 Apache Pulsar + Apache Flink 构建下一代实时数据仓库》的演讲，以下为本次演讲的回顾。 

---

• 无处不在的流数据：所有数据从本质上来讲都是流数据。

• 快速发掘数据价值：产生速度越来越快，规模量也越来越大。

• 计算引擎批流融合的趋势：从计算引擎层面，用同一套API/语义处理数据。

 

如需构建实时数仓，对数据存储层而言，还是存在一定难度这体现在云原生架构的兼容性和数据存储组织的复杂度。

 

1、Pulsar 是一个云原生的架构。Pulsar 内部分成两层，上层是无状态 Broker，下层是持久化的存储层 Bookie 集群，而且 Pulsar 存储是分片的，这种构架可以避免扩容时受限制。

 

2、Pulsar 的分层存储（tiered storage）无需用户显式迁移数据，减少存储成本并保持近似无限的存储。

 

3、Pulsar 提供内置 Schema，可以保持服务器端数据的一致性，也能直接接受和发送类型数据。

 

????????实时数仓的架构

 

在元数据服务层面，翻译层将 Pulsar 的元数据以数据库语义表达，同时提供对 Pulsar 元数据的查询和修改；而在基本映射层面，实现 Tenant/namespace → Database、Topic → Table、Topic Schema → Table Schema 的映射状态。

 

加上灵活的数据读取模式，Segment Read、Stream Read 和 Sub-Stream Read，实现最终的数仓构建。

 

StreamNative 已经开源了基于 Flink 1.9.0 和 Pulsar 2.4.0 的 Pular Flink Connector，实现了 exactly-once 语义的 Source 和 at-least-once 语义的 Sink。同时，基于 Pulsar 的内置 Schema 支持，提供了 Topic 内消息的自动序列化、反序列化。Pulsar Flink Connector 从本质上也是在利用 Pulsar Client API 操作 Pulsar，一些 connector 实现的相关思考可能同时对大家使用 Pulsar 有所帮助。

 

• 持久化、可重放的数据源

流处理过程中出现一些故障是无法避免的，Flink 借助 checkpoint 机制将 Task 从 故障中恢复。Pulsar broker 默认会删除所有被确认的消息，但在流处理的执行期，我们无法得知作业何时会出错，因此不能在读到消息后就直接确认。 通过维护一个作业级的订阅，Flink Pulsar Connector 在收到 Flink checkpoint 的完成通知后确认消息，同时避免消息被过早删除。

 

•  结构化数据存取

 

将 Pulsar topic 看作是一张有结构的表，在任务调度期获取表 Schema 定义。Pulsar Flink Connector 支持 avro/json/protobuf 的消息转换，同时将消息元数据转化为表的内部列。

 

•  Topic 和 Partition 发现

流处理作业是长时间运行的 ，在作业执行期间，topic 可能被添加或删除。因此，我们利用一个额外的监控线程阶段性检查 topic 的增加或删除，并为新增 topic 启动新的消费线程。

 

打造一个「分析友好的数据组织、访问」模式。

 

• 谓词下推 + 粗粒度索引

• 列形式组织 Segment

• 更灵活的数据消费模式

 

 

作者 | Sylvia 

---

 

 

Apache Pulsar 鼓励大家积极参与开源社区，欢迎大家提交 PR，我们会统计参与 Pulsar 的contributor ，后期还有礼品赠送鸭????。