本篇文章给大家分享的是有关如何基于 Pulsar + Flink 构建下一代实时数据仓库，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
如需构建实时数仓，对数据存储层而言，还是存在一定难度这体现在云原生架构的兼容性和数据存储组织的复杂度。
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 启动新的消费线程。
以上就是如何基于 Pulsar + Flink 构建下一代实时数据仓库，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
原创文章，作者：kepupublish，如若转载，请注明出处：https://blog.ytso.com/230643.html
