SlipStupig

@yellowmarlboro

公司项目千万别给自己团队增加学习，稳定快速构建压倒一切。架构可以迭代的，这个不是问题。

ETL 部分是最复杂的，也是最繁琐的，由于我不知道你这边实际情况怎么样，所以我只能从最坏的场景假设，我推荐使用两段式 ETL，具体做法如下：
第一阶段：日志收集和清洗，将日志一些无效、异常和缺失的数据要么过滤，要么基于算法补全。这个可以用 filebeat+ELK 架构（ ES 可以设置 TTL，TTL 值可以设置一周），这个数据丢失其实并不影响，大不了重跑（这里有个风险点，有数据泄露风险，所以传输过程一定要强加密，这个一定要重视，数据安全无小事）

第二阶段阶段，可以基于定时任务每天定时处理前一天任务，这个时候业务会特别复杂，所以可以使用 celery 或者 airflow 进行定制化开发 pipelines，主要工作有：数据富化、字段对齐、字段标准化、字段含义统一(sip 和 source_ip 可能是同一个意思，这个时候需要用 tdidf 等相似度算法来计算字段，还有一些“无头数据”，通过正文内容预测字段含义)、数据格式统一（例如：日期到底是时间戳还是 UTC 时间），数据格式输出格式标准化（是用 JSON 还是 YAML 或 XML 等），建立 index_id 这个是一条数据的唯一标识，用于跟踪数据流转过程

切记一定要有日志，所有的数据生命周期内必须要能完整跟踪到一条数据整个流转过程，如果在发现无法跟踪的数据进入了系统，一定要删除掉！

@levelworm 留个联系方式，可以一起聊一下😊

TDD 能治好你的病

@levelworm 并不是 BI，数据勤杂工。。

千万不要相信用 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. 数据流转过程

门槛低是好事，说明有充足的就业机会，如果你去上班最少得清华的博士，而且要求父母年收入不能低于 500 万，身高不低于 180 这个时候你又会抱怨这些门槛不合理

@berforest
@owencodeing
万一被抓了，公司项目组岂不是被团灭了 2333