多源数据融合，建数仓，数据统计分析一般有哪些架构和技术？区别是什么？

[yellowmarlboro]

问题源于一个需求：把很多不同业务的数据融合（各种类型，日志、营收、监控以及物联网设备等所有数据），需要对所有数据做统计分析以提供决策支持，有一些情况如下

• 数据来源杂，不同区域不同机构不同业务，现有数据各个部门自己采集存储，所以使用的库种类多；
• 所有目前积累数据总大小目前估算是 100TB+，大约 5 年；按业务情况说，数据产生速度会越来越快，具体快多少不知道；
• 最终的统计会涉及实时监控预警，历史数据各种指标，以及有一部分数据挖掘的想法；
• 当然做成了之后也可能会有其它需求

对这方面了解不多，对于 Hadoop,Spark,流处理批处理，数据仓库，数据集市之类的，虽然之前间接接触过，不过毕竟没有动过手，动手的只是其中小部分，其它的也只是了解大概。

心里大概有个模糊的流程和架构，但是具体可以采用哪些框架，流程是如何，为什么用这个或那个，还不定。有没有人大概讲解一下！ thx ！

#学习中#

[pengqiuyuan]

Elasticsearch

[luozic]

一个去看各个公有云和做数据湖的吹水 ppt ； 实际真大部分开源还有不少大厂都一样用的，ElasticSearch。
真直接根据 spark hadoop newsql… 等定制，你公司估计先得养一个不小的团队来做很多外围工作。

[liprais]

谁用 ElasticSearch 简直脑子抽抽了

[Zackkkk]

我们的做法，所有源数据放在 Hive(数仓)上，查询要求不高的，直接通过 Presto 引擎查询 Hive 数据，TB 级别的复杂查询会在分钟级。
需要比较实时高效的查询分析，把 hive 数据导到 Clickhourse/Druid，或者直接上报到 Clickhourse/Druid，查 Clickhourse/Druid 数据。

[18258226728]

大数据这块不太懂，不过和我们公司差不多
我们公司是有离线数据仓库和实时数据仓库。
离线数据仓库一般 T+1 做数据分析，具体的框架不太清楚，好像是 hdfs+hive，数据量大就是机器要管够
实时数仓支持做数据决策，一般是计算指标，框架好像是用的 flume

数据集市那些是数仓对数据的分层，百度很多介绍的

[wangyzj]

数据全进 hadoop
热数据可以考虑 es

[zhiguang]

同问,公司最近也要重构,求一些大数据的书,特别后台报表,有大佬分享下吗

[levelworm]

背景：BA，不过和 BI 经常接触所以知道一些。

第一部分：数据仓库（纯听说加总结）
多数据来源融合的话，我估计你需要的是数据直接进数据仓库。要做的就是写 ETL 进某个数据仓库，100TB 的话我觉得目前市场上常见的都没问题，甚至本地的 PostgreSQL 应该都可以，毕竟你数据仓库里头主要需要的是聚合表。

数据仓库的建立可以看看 Data Modelling 的书，因为你数据来源比较繁杂，所以可能需要分别写 ETL，总之感觉比较麻烦的样子。我们公司数据来源比较单一，主要就是 APP 内部的 telemetry，走 Kafka 到 parser 然后到数据库，最后聚合到数据仓库。你们估计没有这么强的实时性需求。

另外看起来你们应该是需要很多数据仓库的样子，比如说监控和营收肯定是不同的数据仓库。

第二部分：可视化和分析
这块我比较熟悉，Power BI 和 Tableau 都做过，虽然经验都不超过一年。这块其实技术上都没啥难度（除非你准备做数据科学的活），大多数应该都是监控和简单的分析，所以最主要的是数据仓库的架构和需求的分析。这个要看具体了，但是你们必须先和 Business 商量好每件事情的 KPI。

最重要的，其实我觉得还是得从一开始就让业务介入，每次开会都必须要让业务清楚的知道，他想要你们做什么，然后你们是如何把他的需求转化成技术，最后是如何让业务那边的分析（或者你们自己做这块也可以）用你们的技术，出业务需要的报表。重复一下，业务必须深度介入，否则这件事情没法搞。我觉得比较理想的情况是，每一个业务分支都有自己的分析，并且熟悉 SQL, 或者愿意学习 SQL，这样你们就只需要做监控和自动化报表就可以了。能够自动化的全部自动化。数据挖掘什么的留给他们就行，当然除非你也想做，但是估计你精力跟不上。数据仓库这种东西需要经常维护的。

还有一点，这肯定是个很长期的过程，所以需要你们领导知道这点，不是几个礼拜的事情，而是几个月的事情。所以这个事情得有个比较牛逼的人做架构，定好里程碑，不然又是乱七八糟。架构弄不好，整个公司都吃亏。如果需求是在紧张，可以让大领导拍板挑一个最急需的业务线出来，做一个 Data Mart 作为示范。

[levelworm]

技术上我说不了太多，因为作为 BA 我只是消费者，不是生产者，虽然努力争取转 BI。

但是流程上，大体上我们公司是这样：（注意这是在数据仓库已经建好、ETL 已经稳定的情况下）

1. 业务出 Feature 设想，召集各部门的人开会 （ Server/Client 程序员、BI、BA 都有人参加）

2. 前几次会议主要是固定需求，以及和程序员确定技术上都可行，然后划定需要几个 Sprint

3. 接下来业务会和 BI 以及 BA 讨论这个 feature 需要几个 KPI，然后 BI 和 BA 把 KPI 划分成 Dashboard 和 Analysis，一般是 BI 负责 Dashboard，BA 负责 Analysis，不过也有重合的情况。Dashboard 偏重监控，analysis 偏重分析。

4. 接下来 BI、BA 和 Server/Client 讨论需要什么样的 telemetry （在我们这里，就是说 JSON 里头应该包括哪些 field, 什么格式，等等）

因为我自己是 BA，所以技术上我在这段之后就不进行追踪了，但是据我所知，BI 接下来应该就是准备 ETL 和建表或者仓库（小的 feature 建表甚至加列就够了，大的 feature 需要建新的仓库）。ETL 是有专人做好的 Python + Airflow + Kafka，然后进 Vertica 和 Databricks，BI 写好 scheme， 让 server 出数据测试成功之后就可以用了。

基本上小 Feature 3-4 个 JIRA （ 6-8 周），大 Feature 5-6 个 JIRA （ 10-12 周），估计比国内是要慢一些，但是我们同时会有几个 Feature 在进行，所以每个 BI 同时都要追踪 3 个左右的 feature。

等到 feature 出来前后，BI 还需要做 Tableau Dashboard，然后上传到 Tableau Server。但是报表这块可用的工具很多，Server 监控的话 Grafana 也不错。

[SlipStupig]

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

[levelworm]

@SlipStupig 好羡慕你们这些有机会做 BI 的。。。

[SlipStupig]

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

[levelworm]

@SlipStupig 我这做 BA 挤破头想做 BI。。。

[SlipStupig]

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

[yellowmarlboro]

多谢 456 楼，我就不一一 at 了。
@levelworm 多谢关于数仓的建议，包括书以及经验。至于可视化和分析，虽然现在我们是一些基础的，但非常同感这件事需要业务深度参与。另外整个流程的描述实在是对我太有帮助了！ thx
@SlipStupig 我现在就在做 2.数据调研 部分。3 和 4 的具体了我对这两部分的认识。关于 5 架构 我们项目大部分是 python 的 （虽然各位对 java 有兴趣，但新学也是压力）。所以 如果是 python，只考虑语言的话，有哪些可选项？ thx
另外，我很羡慕你们两位 -.-！

[xiazhiisgood]

@SlipStupig 可以搞个 BI 群交流一下

[levelworm]

@SlipStupig 微信号 Et-tu-Brute 多谢啦！还要多多请教

[monsterxx03]

写过在 aws 上构建 data infra 的经过: https://blog.monsterxx03.com/2018/02/23/glow-infra-evolution/

- 一般需要选型一个支持 columnar storage 的 OLAP 数据库, 开源的比如 greenplum, 或者 hadoop 系的方案, 数据表存成 parquet, 上面接 spark.
- 考虑 ETL 方式, 如何把各种数据源的数据导入数据库, 更新延迟接受多久, 这个取决你的业务
- 考虑存储成本的话，看你业务需求，是否能对业务数据分层存储, 最近几个月的存 SSD, 年前的存 HDD, 或者像 hive 那样支持 external table, 老数据存外部 object storage, 数据库内建立引用, 这样对使用方透明.
......

那个说 ES 做数仓的就算了吧...

[SlipStupig]

@yellowmarlboro

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

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

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

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

[cco]

数据仓库工具箱这本书也可以看看。。。。一般都是 hadoop 做存储，hive 做统计分析，到集市层要么 hbase，要么 es，其他的也有。根据业务来。

[levelworm]

@cco +1 KIMBALL 的书都可以看看

[fff333]

@levelworm 写的很棒

[levelworm]

@fff333 技术方面还是看 @SlipStupig 的帖子，我那个是流程的。。。