大数据开发：实时数仓架构层次设计

在大数据实时计算处理领域，数据仓库提供重要的支持，从传统的离线数仓到实时数仓，大数据带动了相应的市场需求，而从架构层次来说，实时数仓也有新的值得挖掘的技术点。今天的大数据开发学习分享，我们就主要来讲讲大数据实时数仓架构设计的问题。

大数据实时数仓架构，通常来说，分为数据接入、数据计算、数据存储三个大的层次。

1、数据接入（source）

流量日志

流量数据天然就是流式的，具有实时性，主要是如何采集的问题。流量数据对应着流量数据域，binlog往往是其它数据域，比如交易域，营销域等，以流量日志为例，打点日志上报到nginx服务器，使用flume进行数据采集，sink进kafka，目前kafka只保留最近三天的数据，考虑到流量日志的数据量大，并且也没有保留多天的意义，保留三天，可以预留重刷历史数据的机会，如果是要查看多天以前的数据情况，完全可以用离线的。所以整套实时数仓体系建设都是为了保障近一天的数据分析。

关系型数据库

目前大多数互联网公司使用的生产数据库都是mysql，以mysql为例，mysql发生任意变更都会产生binlog，使用开源的canal解释原生二进制的数据，然后将解释完的数据sink进kafka，在将kafka作为flink source进行消费。这里值得一提的是，关系型数据库的数据往往是用于构建除流量域以外的数据域使用的。

2、数据计算（transform）

ods层

该成属于明细层，主要担任的职责是对数据进行清洗，解析，规范化处理，拿流量日志来说，使用flink sql对接kafka，使用自定义的udtf函数解析kafka当中的原始log，产生结构化数据，并且在次写入kafka的另一个topic当中，这就是我们的实时ods层数据了。当然关系型数据库相对来得简单一点，因为我们已经使用canal解析好了，直接使用flink sql读取kafka源就好了。

隐藏的校验层

为了校验实时数据的准确性（不管是流量数据还是binlog数据），还需要将存于kafka的ods层数据，写入hdfs上，使用hive和hdfs的文件进行映射，产生实时的hive表（目前是小时级别），该hive表可用于和离线hive表进行数据校正。

dwd层

dwd层的数据是从ods层读取，然后根据需求进行逻辑处理，包括关联相应的维度表（维度表的建设后续会提及），即进行降维操作。

DM层

DM层存储的是一些按照一定粒度进行聚合的值，我们之所以选择将DM层的数据存于hbase，原因在于hbase集群可扩展，支持巨量数据，并且根据rowkey查找，性能也很感人（前提是使用得当），最关键的是hbase的rowkey是天然唯一的，刚好符合聚合的模式，我们只需要将聚合的字段作为rowkey的因子，在用MD5加密一下，就是rowkey了。

APP/RPT层

该层对应着离线的应用层/报表层，这一层跟业务是紧密耦合的，但是这一层产出的数据来源离不开我们底层的建设。

3、数据存储（sink）

目前是将实时维度表和DM层数据存于hbase当中，实时公共层都存于kafka当中，并且以写滚动日志的方式写入HDFS（主要是用于校验数据）。其实在这里可以做的工作还有很多，kafka集群，flink集群，hbase集群相互独立，这对整个实时数据仓库的稳定性带来一定的挑战。

关于大数据开发学习，实时数仓架构层次设计，以上就为大家做了初步的介绍了。在现有的大数据实时计算体系下，实时数仓架构，涉及到主流的框架组件，都是需要去一一掌握的。