认识达内从这里开始

我们在前几期的文章中给大家简单介绍了大数据技术应用的一些基础知识等内容，其中就包含了数据湖以及数据仓库的一些基础知识，而本文我们就再来了解一下，数据仓库发展与架构类型分析。

1、数据仓库的发展

数据仓库有两个环节：数据仓库的构建与数据仓库的应用。

早期数据仓库构建主要指的是把企业的业务数据库如ERP、CRM、SCM等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策(中长期策略型决策)。

随着业务和环境的发展，这两方面都在发生着剧烈变化。

随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站log，IoT设备数据，APP埋点数据等，这些数据量比以往结构化的数据大了几个量级，对ETL过程、存储都提出了更高的要求。

互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等(即既有中远期策略型，也有短期操作型);同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策，比如欺诈检测和用户审核。

2、离线大数据架构

数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取DM或加一层数据服务，比如MySQL或Redis。数据仓库从模型层面分为三层：

ODS，操作数据层，保存原始数据。

DWD，数据仓库明细层，根据主题定义好事实与维度表，保存细粒度的事实数据。

DM，数据集市/轻度汇总层，在DWD层的基础之上根据不同的业务需求做轻度汇总。

数仓存储是HDFS/Hive，ETL可以是MapReduce脚本或HiveSQL。

3、Kappa架构

Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn的JayKreps提出了Kappa架构。

Kappa架构可以认为是Lambda架构的简化版(只要移除lambda架构中的批处理部分即可)。

在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。

Kappa架构大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

4、实时数仓建设思路

计算框架选型：storm/flink等实时计算框架，强烈推荐flink，其『批量合一』的特性及活跃的开源社区，有逐渐替代spark的趋势。

数据存储选型：要考虑查询效率，其次是插入、更新等问题，可选择apachedruid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析，不同场景下hbase、redis等都是可选项。

实时数仓分层：为更好的统一管理数据，实时数仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细层写入druid等查询效率高的存储方便下游使用;轻度汇总层对数据进行汇总分析后供下游使用。

数据流转方案：实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据即可以写入数据湖用于批量分析，也可以实时处理，下游可以写入数据集市供业务使。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。