逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
借图发挥：
- 信息采集
- 数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
- 网站日志
- 业务数据库
- 来自于Ftp/Http的数据源
- 其他数据源
- 监控报警：
系统信息collectd除运维外其他很少会用到。
各平台信息(hadoop、spark、stom)的指标可以通过自身的监控系统。
主要是应用程序的监控报警、任务打点的监控报警。
- 数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
- 数据存储与分析
- Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上
- 实时计算
实时计算使用Spark Streaming以及部分Java程序消费Kafka中收集的日志数据，实时计算结果大多保存在Redis中 - 数据共享
- 这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；
- 数据应用
- 业务产品(业务产品所使用的数据，已经在数据共享层，他们直接访问数据共享层即可)
- 报表
数据可视化，es,kylin - 即席查询
- OLAP(phenix，zeeplin，presto;这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。)
- 其他数据接口(这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。)
- 任务调度与监控
- 元数据管理
字典系统、etl系统 - 总结
架构，并不是技术越多越新越好，而是在可以满足需求的情况下，简单、稳定。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。