架构在一定基准之上, 受业务驱动演进
在满足业务基础上，技术（底层）架构部分应该是可扩展，易运维的
同类产品能解决80%以上的相关问题图1： 目前常见数仓形态
- 提问: 为什么要有数仓
1.1 我们假设没有数据仓库，想用到证券业务数据
图2： 数据孤岛形态
用户编号 | 业务日期 | |
投顾业务 | userid | logdate |
资管业务 | usercode | service_date |
经纪业务 | usernum | bizdate |
如果我想同时用到三个库的数据，会经历（见图3）如下：
- 跨部门沟通，
- 临时库申请，建立，销毁
- 数据模型构建
- 数据和标准不可复用
我们会尝试构建流程，规范，建立标准，这时候可能会发现数据仓库是个不错的解决方案
图3 使用多部门数据-无数仓
1.2 使用数据仓库
数据在数仓中被 重构数据模型，规范化，标准化，可被复用
比如我们券商的数据报送业务，我们就可以直接以数仓或者数据集市为起点
或者这样
1.3 数仓与数据集市
你没看错，早期对数仓的定义就是包含了数据集市。
传统数仓本来就是在关系型数据库中，主题是按照业务建模。对比现在庞大的日志数据，第三方数据，联邦数据（横向与纵向），很多采用如hive这种大数据为基础的数据仓库，而数据集市最重要的是：
满足业务人员的查询需求。支持快速响应，有完整且正确的数据用于分析，有易于理解的数据结构等。
所以我们现在对数据集市的理解，是与数仓是上下游的关系，而不是包含关系，如下
- 为什么要有数据集市
数据集市一个概念层
我们不是总能对数据仓库完整索引的建设；当我们的用户有自己的习惯和要求（比如即席查询）， 而业务对于数据仓库过于基础的数据结构需要大量的学习成本。 业务人员更关心的是一个宽表或者约定业务数据模型来做查询， 这种时候可能是oracle,mysql, 也可能是elasticsearch,clickhouse, mongodb， 甚至excel
说个实际场景，我们在使用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的故事，吃饭了，下篇文章写吧
