业务数据背景
我所在的公司处理的数据主要是游戏过程数据，用户行为数据，游戏币消费数据还有其他业务部门维护的例如用户优惠数据，游戏活动等业务数据。其中对于业务系统DBMS中的数据，基本按照“天”作为时间粒度来采集到数据仓库中，对于实时性要求较强的游戏数据，则是需要采用埋点实时采集和处理的。需求的多样化和复杂性，运营人员希望做到精细化运营和数据指标的实时响应, 这要求数据仓库具有提供高效明细数据能力,也能随时提供最新的数据调取，为了满足不同层次的数据提出和分析, 就要求着数据仓库在设计之初，就要考虑到要同时支持离线和实时的情况。
数据仓库架构理念
设计数据仓库架构之初，我们大数据工程组团队开会讨论的第一件事就是：Who is the User of Data in Data Warehouse？
这件事情还是很重要的，弄清楚了这件事，对于接下来架构设计和数仓数据主题的确定都是有影响的，其中对于架构设计来说，这决定了我们架构上层需要提供哪些接口，对接不同的业务系统，我们应该设计怎样的查询和索引，不同的使用者，能够接受的数据粒度或者是数据响应时间，整个数据仓库的数据流大致应该怎样流向，这都与使用用户有关。在架构设计方面，基本上都是由下到上的去设计，但是呢，也不妨从上层需求开始，向下层实现设计开始✌️
架构图
架构层次&技术选型
数据源
由于公司各业务部门的数据都由运维DBA统一管理和做权限控制，RDBMS中的数据的采集，需要由运维部门给出备库URL，避免直接来取主库数据，对线上业务产生影响。
这部份的数据采集，主要涉及Sqoop，NIFI，Spark 这三个工具。
Sqoop
在上一版的数据仓库中，Sqoop是作为RDBMS -> HDFS中主要的搬运工。主要原因是开发成本小，数据量小，使用简单。但是随着数仓原始层数据量激增了原来的三倍，Sqoop计算能力就捉襟见肘了，每天的第一个任务就是拉取原始层数据，如果继续使用Sqoop，会严重影响接下来其他例行任务的按时进行。所以，我们决定抛弃这个使用MapReduce作为计算框架的数据同步工具。
Spark
提升数仓原始数据层拉取速度，就要选择合适的拉去工具。面对拉去原始数据，基本上不需要对任何数据字段进行清洗，基本上直接下 select columns就可以满足要求， 所以选用Spark SQL， read jdbc -> dataframe -> writeInto -> Hive。这样运行的速度相对Sqoop来说，提升了四倍✌️
NIFI
NIFI这个工具，并没有作为主要的数据工具来使用，起初只是作为团队的技术调研对象，在几次的分享会上，大家对NIFI都比较感兴趣，可能是大家都想解放双手，用拖拽的形式来拒绝写代码 哈哈哈哈。就这样，NIFI作为一个技术储备，承担了test库中测试数据的同步，等以后团队人手充足了，有维护多框架的能力时可以考虑发挥NIFI的更多用处。
另外对于埋点数据，产品方会将数据打到运维的kafka中，随后我们会使用fluentd将运维kafka中的数据实时转发到我们大数据平台中的kafka中，做接下来的处理
Fluentd
运维的kafka中，会收集这我们想要的日志数据和埋点数据，埋点数据一般为json格式，将数据解析和打到大数据平台kafka的这一段中，我们在Logstash,Fluentd
两个工具中进行选择，Logstash是非常出名的ELK中的 ‘L’ , 成熟度和稳定性不用说。Fluentd则是我们第一次接触，我们并没有亲自对Fluentd和Logstash进行效率和资源消耗上做测试，但是根据网上几篇对比测评文章，Fluentd的支持度虽没有Logstash那么完整，但是Fluentd中的插件完全能满足我们的开发需求，最重要的，Fluentd在CPU和内存上的消耗，都要优于Logstash。所以最后我们选择了Fluentd
Flink & Spark Streaming
Flink，Spark Streaming这两个实时计算框架就不多介绍了，家喻户晓。在这里说一下，在实时计算的这一层面，团队为什么选择了两个计算框架。主要是因为对待不同的需求，使用更适合的工具，团队成员对Spark Streaming更加熟悉，在对实时性要求更高的项目中，例如游戏监控系统，对于数据状态管理，watermark的需求都是有要求的，在这方面，Flink的实现就是要比Spark Streaming好。
数据存储层
Hive
Hive是Hadoop的一个数据仓库工具，底层存储为HDFS，可以将我们按照主题设计好的结构化数据映射成表，提供SQL接口来分析数据。
从存储层到共享层中，大部分的计算任务，都是在Hive表中，使用Spark作为计算框架，ETL将数据清洗到HBase,MySQL等结果库中。
HBase&Elasticsearch&Grafana
HBase
HBase的用途基本上是存储流式ETL后的结果数据，或者是直接存入原始数据作为备份
Elasticsearch
ES的用途基本上是搭配Fluentd和Kibana，组成EFK，做数据展示，多数情况下会存储日志数据，做详情的检索。还有一个常用的功能就是结合HBase做二级索引，会在ES索引里面存储一个hbase的关键字rowkey，根据查询条件定位到某个rowkey，直接去hbase里面get数据，秒级返回
Grafana
Grafana是团队后期引入的，主要是被Grafana的UI所吸引，Grafana和Kibana对比起来，UI展示要强大的很多，对于Grafana，我们正在调研，使用Grafana来做数据质量的监控，等使用成熟了，也会分享出来。
数据共享层
共享层的数据，都是经过ETL清洗的，都是即拿即用的。
业务系统 ，对接数据仓库的，都是通过GoApi结构进行调取的。
报表数据 ，工程师会通过Spark写成CSV文件，提供给运营人员
即席查询 ，我们还开放了Presto接口（presto的查询速度比hive快5-10倍），同时对数据仓库做了仅查权限控制，希望业务分析人员可以自主的通过presto进行数据调取，但是理想是丰满的，现实是骨感的。根本没人用 哈哈哈哈哈哈哈
数据应用层
数据用户层
略
