江苏龙网

  1. 首页 > 资讯 > 资讯 > >

业务|滴滴基于 Flink 的实时数仓建设实践( 四 )


4.3 基于数据梦工厂的实时数据源元数据化
将 topic 引入成实时表，metastore 统一管理元数据，实时开发中统一管理 DDL 过程。对实时数仓来说，通过元数据化，可以沉淀实时数仓的建设成果，使数仓建模能更好的落地。
目前数据梦工厂支持的元数据化实时数据源包括 Postgre、DDMQ、MySQL、Druid、ClickHouse、Kylin、Kafka。
5. 面临的挑战和解决方案思考
虽然目前滴滴在实时数仓建设方面已初具规模，但其面临的问题也不容忽视。
5.1 实时数仓研发规范
问题：为了快速响应业务需求，同时满足数仓的需求开发流程，迫切需要建设一套面向实时数据开发的规范白皮书，该白皮书需要涉及需求对接、口径梳理、数据开发、任务发布、任务监控、任务保障。
目前解决方案：目前由数据 BP 牵头，制定了一套面向实时数据指标的开发规范：
常规流程：需求方提出需求，分析师对接需求，提供计算口径，编写需求文档。之后由数仓 BP 和离线数仓同学 check 计算口径，并向实时数仓团队提供离线 Hive 表，实时数仓同学基于离线 Hive 表完成数据探查，基于实时数仓模型完成实时数据需求开发，通过离线口径完成数据自查，最终交付给分析师完成二次校验后指标上线。
口径变更--业务方发起：业务方发起口径变更，判断是否涉及到实时指标，数仓 BP 对离线和实时口径进行拉齐，向离线数仓团队和实时数仓团队提供更口口径和数据源表，实时数仓团队先上测试看板，验收通过后切换到正式看板
存在的不足：
当针对某个业务进行新的实时数据建设时，会有一个比较艰难的初始化过程，这个初始化过程中，会和离线有较多耦合，需要确定指标口径，数据源，并进行大量开发测试工作
在指标口径发生变更的时候，需要有一个较好的通知机制，目前还是从人的角度来进行判断。
5.2 离线和实时数据一致性保证
目前解决办法：由业务、BP、离线数仓共同保证数据源、计算口径与离线一致，数据加工过程，逐层与离线进行数据比对，并对指标结果进行详细测试，数据校验通过并上线后，根据离线周期进行实时和离线数据的校验。
待解决的问题：结合指标管理工具，保证指标口径上的一致性，扩展数据梦工厂功能，在指标加工过程中，增加实时离线比对功能，降低数据比对成本。
6. 未来展望：批流一体化
虽然 Flink 具备批流一体化能力，但滴滴目前并没有完全批流一体化，希望先从产品层面实现批流一体化。通过 Meta 化建设，实现整个滴滴只有一个 MetaStore，无论是 Hive、Kafka topic、还是下游的 HBase、ES 都定义到 MetaStore 中，所有的计算引擎包括 Hive、Spark、Presto、Flink 都查询同一个 MetaStore，实现整个 SQL 开发完全一致的效果。根据 SQL 消费的 Source 是表还是流，来区分批处理任务和流处理任务，从产品层面上实现批流一体化效果。


推荐阅读


上一篇： 公司|女子上班吃了2颗葡萄，被辞退！

下一篇： 澜沧江|在澜沧江搜救4天后，知名旅游博主遗体被找到！