导读:
-
<李>
李> <李>
李> <李>
李> <李>
李> <李>
李> <李>
李> <李>
李> <李>
李> <李>
李>
一直想整理一下这块内容,既然是漫谈,就想起什么说什么吧。我一直是在互联网行业,就以互联网行业来说。
先大概列一下互联网行业数据仓库,数据平台的用途:
-
<李>
整合公司所有业务数据,建立统一的数据中心;
李> <李>提供各种报表,有给高层的,有给各个业务的;
李> <李>为网站运营提供运营上的数据支持,就是通过数据,让运营及时了解网站和产品的运营效果;
李> <李>为各个业务提供线上或线下的数据支持,成为公司统一的数据交换与提供平台;
李> <李>分析用户行为数据,通过数据挖掘来降低投入成本,提高投入效果,比如广告定向精准投放,用户个性化推荐等;
李> <李>开发数据产品,直接或间接为公司盈利;
李> <李>建设开放数据平台,开放公司数据;
李> <李>……
李>上面列出的内容看上去和传统行业数据仓库用途差不多,并且都要求数据仓库/数据平台有很好的稳定性、可靠性;但在互联网行业,除了数据量大之外,越来越多的业务要求时效性,甚至很多是要求实时的,另外,互联网行业的业务变化非常快,不可能像传统行业一样,可以使用自顶向下的方法建立数据仓库,一劳永逸,它要求新的业务很快能融入数据仓库中来,老的下线的业务,能很方便的从现有的数据仓库中下线;
其实,互联网行业的数据仓库就是所谓的敏捷数据仓库,不但要求能快速的响应数据,也要求能快速的响应业务;
建设敏捷数据仓库,除了对架构技术上的要求之外,还有一个很重要的方面,就是数据建模,如果一上来就想着建立一套能兼容所有数据和业务的数据模型,那就又回到传统数据仓库的建设上了,很难满足对业务变化的快速响应。应对这种情况,一般是先将核心的持久化的业务进行深度建模(比如:基于网站日志建立的网站统计分析模型和用户浏览轨迹模型,基于公司核心用户数据建立的用户模型),其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。
,
下面的图是我们目前使用的数据平台架构图,其实大多公司应该都差不多:
逻辑上,一般都有数据采集层,数据存储与分析层,数据共享层,数据应用层。可能叫法有所不同,本质上的角色都大同小异。
我们从下往上看:
<编辑> ,,,,,华丽的分割线:您可以关注, lxw的大数据田地 ,,或者, 加入邮件列表 ,,随时接收博客更新的通知邮件。 编辑> <人力资源/>数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上,期间有可能会做一些简单的清洗。
数据源的种类比较多:
-
<李>
<强> 网站日志: 强>
李>作为互联网行业,网站日志占的份额最大,网站日志存储在多台网站日志服务器上,
一般是在每台网站日志服务器上部署水槽代理,实时的收集网站日志并存储到HDFS上;
-
<李>
<强> 业务数据库: 强>
李>业务数据库的种类也是多种多样,有Mysql, Oracle等状态"置疑",这时候,我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具,Sqoop是一种,但是Sqoop太过繁重,而且不管数据量大小,都需要启动MapReduce来执行,而且需要Hadoop集群的每台机器都能访问业务数据库;应对此场景,淘宝开源的DataX,是一个很好的解决方案(可参考文章《 异构数据源海量数据交换工具淘宝DataX下载和使用 》),有资源的话,可以基于DataX之上做二次开发,就能非常好的解决,我们目前使用的DataHub也是。