建设实时数仓之前的思考与方案

栏目: IT技术 · 发布时间: 4年前

内容简介:点击上方蓝色字关注置顶我们!

点击上方蓝色字关注置顶我们!

建设实时数仓之前的思考与方案

相关推荐: 实时数仓介绍与阿里实时数仓案例

导读 本文由作者LittleMagic总结分享授权发布,主要阐述建设实时数仓之前的思考与方案记录。详细分为以下几个方面:

  1. 动机背景

  2. 指导思想

  3. 技术选型

  4. 架构分层

  5. 元数据管理

  6. SQL作业管理

  7. 数据质量

☞ 关注 公众号『数据仓库与 Python 大数据』 ,获取更多优质资源与干货文章。

作者:LittleMagic

编辑: 紫霞仙子

前言

建设实时数仓之前的思考与方案

随着这次新冠疫情带来的机遇,业务数据规模飞速增长,实时数仓的建设已经提上了日程。虽然还没有正式开始实施,但是汲取前人的经验,做好万全的准备总是必要的。

最后一波!Flink/Kylin/数据分析(湖)...100减50!更多满减低至4折!

本文简单地记录一下建设实时数仓之前的一些思考和方案想法,不涉及维度建模方法论的事情。如果有兴趣请移步: 系列 | 漫谈数仓第二篇NO.2 数据模型(维度建模)

一、动机背景

随着业务快速增长,时效性越显重要,传统离线数仓的不足暴露出来:

  • 运维层面——所有调度任务只能在业务闲时(凌晨)集中启动,集群压力大,耗时越来越长;

  • 业务层面——数据按T+1更新,延迟高,数据时效价值打折扣,无法精细化运营与及时感知异常。

实时数仓即离线数仓的时效性改进方案,从原本的小时/天级别做到秒/分钟级别。底层设计变动的同时,需要尽力保证平滑迁移,不影响用户(分析人员)之前的使用习惯。

实时数仓的建设应早日提上日程,未来企业对数据时效性的要求会越来越高( 如实时大屏、实时监控、实时风控等 ),实时数仓会很好的解决该问题。

二、指导思想:Kappa架构

一图流,可品

建设实时数仓之前的思考与方案

参考大数据数据仓库架构演进:

建设实时数仓之前的思考与方案

关于数仓架构,可回顾我们之前分享的文章,更多请移步: 系列 | 漫谈数仓第一篇NO.1『基础架构』

三、计算/存储技术选型

3.1 计算引擎

硬性要求:

  1. 批流一体化——能同时进行实时和离线的操作;

  2. 提供统一易用的SQL interface——方便开发人员和分析人员。

可选项: Spark、Flink

较优解: Flink

  • 优点:

  1. 严格按照Google Dataflow模型实现;

  2. 在事件时间、窗口、状态、exactly-once等方面更有优势;

  3. 非微批次处理,真正的实时流处理;

  4. 多层API,对table/SQL支持良好,支持UDF、流式join等高级用法。

建设实时数仓之前的思考与方案
  • 缺点:

  1. 生态系统没有Spark强大(不太重要);

  2. 1.10版本相比1.9版本的改动较多,需要仔细研究。

低至4折!Flink/Kylin/数据分析(湖)...100减50!更多满减低至4折!

3.2 底层(事实数据)| 存储引擎

  • 硬性要求:

1. 数据in-flight——不能中途落地,处理完之后直接给到下游,最小化延迟;

2. 可靠存储——有一定持久化能力,高可用,支持数据重放。

  • 可选项: 各种消息队列组件(Kafka、RabbitMQ、RocketMQ、Pulsar、...)

  • 较优解: Kafka

    1. 吞吐量很大;

    2. 与Flink、Canal等外部系统的对接方案非常成熟,容易操作;

    3. 团队使用经验丰富。

3.3 中间层(维度数据)| 存储引擎

  • 硬性要求:

  1. 支持较大规模的查询(主要是与事实数据join的查询);

  2. 能够快速实时更新。

  • 可选项: RDBMS(MySQL等)、NoSQL(HBase、 Redis 、Cassandra等)

  • 较优解 :HBase

  • 优点:

  1. 实时写入性能高,且支持基于时间戳的多版本机制;

  2. 接入业务库MySQL binlog简单;

  3. 可以通过集成Phoenix获得 SQL 能力。

3.4 高层(明细/汇总数据)| 存储/查询引擎

据不同的需求,按照业务特点选择不同的方案。

当前已大规模应用,可随时利用的组件:

  • Greenplum——业务历史明细、BI支持、大宽表MOLAP

  • Redis——大列表业务结果(PV/UV、标签、推荐结果、Top-N等)

  • HBase——高并发汇总指标(用户画像)

  • MySQL——普通汇总指标、汇总模型等

当前未有或未大规模应用的组件:

  • ElasticSearch(ELK)——日志明细,也可以用作OLAP

  • Druid——OLAP

  • InfluxDB/OpenTSDB——时序数据

四、实时数仓分层架构

参照离线数仓分层,尽量扁平,减少数据中途的lag。

建设实时数仓之前的思考与方案

image1

建设实时数仓之前的思考与方案

image2

五、元数据管理

5.1 必要性

Kafka本身没有Hive/GP等传统数仓组件的metastore,必须自己维护数据schema。
(Flink 1.10开始正式在Table API中支持Catalog,用于外部元数据对接。)

5.2 可行方案

  1. 外部存储(e.g. MySQL) + Flink ExternalCatalog

  2. Hive metastore + Flink HiveCatalog(与上一种方案本质相同,但是借用Hive的表描述与元数据体系)

  3. Confluent Schema Registry (CSR) + Kafka Avro Serializer/Deserializer

建设实时数仓之前的思考与方案

CSR是开源的元数据注册中心,能与Kafka无缝集成,支持RESTful风格管理。producer和consumer通过Avro序列化/反序列化来利用元数据。

六、SQL作业管理

6.1 必要性

实时数仓平台展现给分析人员的开发界面应该是类似Hue的交互式查询UI,即用户写标准SQL,在平台上提交作业并返回结果,底层是透明的。
但仅靠Flink SQL无法实现,需要我们自行填补这个gap。

6.2 可行方案

AthenaX(由Uber开源)

该项目比较老旧,是基于Flink 1.5构建的,预计需要花比较多的时间精力来搞二次开发。

建设实时数仓之前的思考与方案

6.3 流程

用户提交SQL → 通过Catalog获取元数据 → 解释、校验、优化SQL → 编译为Flink Table/SQL job → 部署到YARN集群并运行 → 输出结果

重点仍然是元数据问题:如何将AthenaX的Catalog与Flink的Catalog打通?

需要将外部元数据的对应到Flink的TableDescriptor(包含connector、format、schema三类参数),进而映射到相应的TableFactory并注册表。

建设实时数仓之前的思考与方案 外还需要控制SQL作业对YARN资源的占用,考虑用YARN队列实现,视情况调整调度策略。

七、数据质量

7.1 性能监控

使用Flink Metrics,主要考虑两点:

  • 算子数据吞吐量(numRecordsInPerSecond/numRecordsOutPerSecond)

  • Kafka链路延迟(records-lag-max)→ 如果搞全链路延迟,需要做数据血缘分析

其他方面待定(术业有专攻,可专业搞监控系统的同学支持)

7.2 数据质量

  • 手动对数——旁路写明细表,定期与数据源交叉验证

  • 自动监控——数据指标波动告警,基线告警,表级告警 etc.

建设实时数仓之前的思考与方案

你也「在看」吗?:point_down:


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

降维打击

降维打击

杨 健 / 北京时代华文书局 / 2016-10 / 68

“降维打击”出自中国科幻作家刘慈欣的小说《三体》,而笔者在这本书中试图把“降维打击”的思维引入到企业经营管理的实战中,总结出一套“降维打击”的商业理论。 按照笔者的理解,企业竞争力可以体现在若干个维度的累加上,具有高维度思维的企业,主动将竞争对手的某一核心维度的竞争力降为零,并跟对手在自己更具竞争优势的维度内进行竞争,从而实现以小博大、以弱灭强的商业竞争结果,这就是企业竞争中的“降维打击”。......一起来看看 《降维打击》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

在线进制转换器
在线进制转换器

各进制数互转换器

URL 编码/解码
URL 编码/解码

URL 编码/解码