互联网行业数据仓库/数据平台的架构
互联网行业数据仓库、数据平台的用途
1) 整合公司所有业务数据，建立统一的数据中心；
2) 提供各种报表，有给高层的，有给各个业务的；
3) 为网站或 APP 运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
4) 为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
5) 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；
6) 开发数据产品，直接或间接为公司盈利；
7) 建设开放数据平台，开放公司数据；
上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库 / 数据平台有很好的稳定性、可靠性；
但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；
建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，
如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），
其它的业务一般都采用维度 + 宽表的方式来建立数据模型。 整体架构



逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看
数据采集
数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多： 网站日志：
作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署 flume agent ，实时的收集网站日志并存储到 HDFS 上； 业务数据库：
业务数据库的种类也是多种多样，有 Mysql 、 Oracle 、 SqlServer 等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到 HDFS 上的工具， Sqoop 是一种，但是 Sqoop 太过繁重，而且不管数据量大小，都需要启动 MapReduce 来执行，而且需要 Hadoop 集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的 DataX ，是一个很好的解决方案有资源的话，可以基于 DataX 之上做二次开发，就能非常好的解决。
当然， Flume 通过配置与开发，也可以实时的从数据库中同步数据到 HDFS 。 来自于 Ftp/Http 的数据源：
有可能一些合作伙伴提供的数据，需要通过 Ftp/Http 等定时获取， DataX 也可以满足该需求； 其他数据源：
比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；
数据存储于分析
毋庸置疑， HDFS 是大数据环境下数据仓库 / 数据平台最完美的数据存储解决方案。

离线数据分析与计算，也就是对实时性要求不高的部分，在我看来， Hive 还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的 ORC 文件存储格式；非常方便的 SQL 支持，使得 Hive 在基于结构化数据上的统计分析远远比 MapReduce 要高效的多，一句 SQL 可以完成的需求，开发 MR 可能需要上百行代码；

当然，使用 Hadoop 框架自然而然也提供了 MapReduce 接口，如果真的很乐意开发 Java ，或者对 SQL 不熟，那么也可以使用 MapReduce 来做分析与计算； 数据共享
这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和 NOSQL 数据库；
前面使用 Hive 、 MR 、 Spark 、 SparkSQL 分析和计算的结果，还是在 HDFS 上，但大多业务和应用不可能直接从 HDFS 上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；
和数据采集层到 HDFS 刚好相反，这里需要一个从 HDFS 将数据同步至其他目标数据源的工具，同样， Sqoop,DataX 也可以满足。
另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。
数据应用
业务产品
业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；
报表
同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；
即席查询
即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；
这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。
即席查询一般是通过 SQL 完成，最大的难度在于响应速度上，使用 Hive 有点慢，目前解决方案是 SparkSQL, Impala ，它的响应速度较 Hive 快很多，而且能很好的与 Hive 兼容。

OLAP
目前，很多的 OLAP 工具不能很好的支持从 HDFS 上直接获取数据，都是通过将需要的数据同步到关系型数据库中做 OLAP ，但如果数据量巨大的话，关系型数据库显然不行； 这时候，需要做相应的开发，从 HDFS 或者 HBase 中获取数据，完成 OLAP 的功能；
比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从 HBase 中获取数据来展示。
其它数据接口
这种接口有通用的，有定制的。比如：一个从 Redis 中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。

实时计算
现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架； Storm, JStorm ,Spark Streaming 等实时框架已经非常成熟了。

常见思路由 scribe 、 chukwa 、 kafka 、 flume 等开源框架在前端日志服务器上收集网站日志和广告日志，实时的发送给 Storm, JStorm ,Spark Streaming ，由实时计算框架完成统计，将数据存储至 Redis ，业务通过访问 Redis 实时获取。 任务调度与监控
在数据仓库 / 数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；
这就需要一个非常完善的任务调度与监控系统，它作为数据仓库 / 数据平台的中枢，负责调度和监控所有任务的分配与运行。
元数据管理
技术元数据与业务数据，开发元数据系统。