数据仓库与数据集市 - 白话数据架构

数据仓库与数据集市 - 白话数据架构

架构在一定基准之上, 受业务驱动演进在满足业务基础上，技术（底层）架构部分应该是可扩展，易运维的同类产品能解决80%以上的相关问题

图1： 目前常见数仓形态

提问: 为什么要有数仓

1.1 我们假设没有数据仓库，想用到证券业务数据

图2： 数据孤岛形态

如果我想同时用到三个库的数据，会经历（见图3）如下：

跨部门沟通，临时库申请，建立，销毁数据模型构建数据和标准不可复用

我们会尝试构建流程，规范，建立标准，这时候可能会发现数据仓库是个不错的解决方案

图3   使用多部门数据-无数仓

​1.2 使用数据仓库

数据在数仓中被 重构数据模型，规范化，标准化，可被复用

比如我们券商的数据报送业务，我们就可以直接以数仓或者数据集市为起点

或者这样

1.3 数仓与数据集市

你没看错，早期对数仓的定义就是包含了数据集市。

传统数仓本来就是在关系型数据库中，主题是按照业务建模。对比现在庞大的日志数据，第三方数据，联邦数据（横向与纵向），很多采用如hive这种大数据为基础的数据仓库，而数据集市最重要的是：

满足业务人员的查询需求。支持快速响应，有完整且正确的数据用于分析，有易于理解的数据结构等。

所以我们现在对数据集市的理解，是与数仓是上下游的关系，而不是包含关系。

说个实际场景，我们在使用BI基于presto，不理解后台的人会感觉速度很慢。如果日常使用的报表数据被抽离成数据集市放在某个数据库中，会明显提升查询速度，用户也不会抱怨。

显然，数据集市的合理使用会带来明显的收益，而我们建立数据集市的过程，还有些不尽人意。  公司常见的是以手动配置ETL调度完成数据集市的建立，逐渐优化为平台或者API的方式建立自动化ETL。

曾经在研究数据湖的时候，调研过kylo，做到了接近理想的场景：通过平台生成新的数据集（可以定义为数据集市），转移成数据血缘流程，以及生成调度，定期更新数据集市。

数据仓库和数据集市存在的问题

前面说了为什么需要数据仓库和数据集市，但这种解决方案，我们实际使用中总会遇到些问题，

3.1 数据分析人员需要漫长的过程才能够使用的数据

数据仓库通常会遇到数据规范，标准的大量建设，而数据分析人员经常遇到目前所使用的数据还未建立标准，这样需要等待。而数据分析人员对底层数据的探查本身有一定限制，且并不能一次描述清楚要构建怎样的数据模型，且不知道如何使用源数据去构建理想的数据模型。

3.2 我们的数据集市总是变得大而全，更像是数据仓库的一个子集。

如上，数据分析人员要使用数据集市，却不能描述所需的源数据，数据开发人员一般会采用一个全集来满足数据分析人员的使用。

另一种解决方案： 数据湖与数据治理

2011年数据湖的概念被提出，2012到2015年期间经历了各种非议，顽强生长。  做过数据治理的人都会发现，数据治理和数据湖总是成对出现，因为单纯说数据湖，感觉就是一个骗子，而早期的大数据人员理解数据湖就是HDFS，数据治理提出的数据质量，数据血缘，数据共享，让数据湖变得有意义了，那为什么要提出数据湖呢？因为数据湖我们理解错了！（下面文章讲）

先说，两个解决方案有个共同的理念，数据质量很重要

​​atlas​​​和​​kylo​​，我们当时选择了kylo，平台化的实现了数据治理的理念，且易用性极强。 缺点是，大而全。 这里我也要吐槽一下impala，很多的底层理念，性能优势，却因为内存管理策不足，对普通人适配性差（就是体验差），使得presto成为主流。

ETL 到 ELT 的阵痛

最早听到ELT的时候，一片群嘲，来回凹概念，有什么意思！

市场上几位先驱提出ETL+ELT的方案，可想而知，水花都没有溅起来

直到数据湖引擎的进入大众的视野，我也想给大家讲讲ELT的故事，吃饭了，下篇文章写吧

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。