千万不要相信用 ES 去做数据仓库，Elasticsearch 不是数据库，而是一个搜索引擎，只是很多人把它当做数据库使用，ES 不适合数据仓库的原因有如下几点：

- 数据在一些统计聚合方面便利性和性能都不够（按时间维度进行复杂聚合用 ES 简直是灾难）
- 由于 ES 特性，如果你想保证数据不丢失就需要更多副本，那么就需要更多的资源开销，主要体现在几个方面
- 当数据崩溃后需要恢复的时间很长，我手里面用的 SAS RAID5 的盘，有 1T 数据恢复时间大概需要 5 分钟
- ES 想要稳定的运行那么就需要海量的内存，更多的硬盘空间，这块成本会增加很多

---

作为一个踩过数据仓库神坑的过来人，分享一点点经验可供参考。

1. 为什么要建立数据仓库？建立之后可以带来什么收益？（这点看上去是废话，实际上非常重要，很多企业建立数仓目标都不清楚，主要是看 BAT 都在弄，自己也得弄）
2. 数据调研
2.1 设计一个访谈表格（ eg：数据时间范围，业务来源等业务相关的东西）
2.2 对数据相关负责人进行了解业务模式和特点
2.3 设计数据交互标准（ eg：什么时候提交，什么格式，什么时间提交，什么方式等等，这个根据 2.1 和 2.3 来定）

3. ETL 方案确立
3.1 定义清洗方案（ eg：字段缺失，字段含义统一、无效标准等等）
3.2 数据转换，转换成标准格式或进行进一步富化
3.3 数据脱敏，对于关键数据传输要进行脱敏

4. 数据建模
4.1 确定维度表和事实
4.2 确定使用的数据仓库模型（ eg: 雪花型、星型还是星座型）
4.3 确定 index key

5. 确定整体技术架构
5.1 先确定自身项目数据容量和未来增长率
5.2 留好一个万能可扩展接口（哪怕未来实现扩展非常狼狈也要留出来，关键时候可以避免架构推倒重来）
TIPS: 没有万能的方案，需要考虑自身实际情况，比如你的项目人员都是 python 开发人员，那么千万别使用 Hadoop 生态，还有自身硬件和数据条件浙西都应该去考虑

6. 数据工厂

- 根据业务进行数据产品加工抽象方法（需要定义一套完整的 dataflow，eg：A 数据和 B 数据，根据 uid 进行 merge 然后产生 C 数据，形成新的事实表）
- 提供基础访问 API 接口，比如：支持一个 SQL 查询
TIPS:千万不要提供业务相关的 API，不仅不能很好的满足，而且会拖累整体质量

7. 数据审计
1. QOS
2. 权限管理
3. 数据流转过程