java如何构建数据仓库 数据仓库的含义,数据仓库和数据库的区别？
数据仓库的含义,数据仓库和数据库的区别？
一直想整理一番帮一下忙这块内容，要是是漫谈，就想起什么说什么吧。我一直在是在互联网行业，就以互联网行业来说。先至少列再看看互联网行业数据仓库、数据平台的用途：
重新整合公司所有业务数据，成立统一的数据中心；
需要提供各种报表，有给高层的，有给各个业务的；
为网站运营能提供运营上的数据支持，应该是通过数据，让运营和管理及时处理所了解网站和产品的运营效果；
为各个业务可以提供线上或线下的数据支持，拥有公司统一的数据交换与需要提供平台；
分析用户行为数据，通过数据挖掘来会降低投入成本，增加耗去效果；比如广告代培生精准投放、用户个性化推荐等；
开发数据产品，直接和间接为公司亏损；
建设和发展开放数据平台，开放公司数据；
。。。。。。
上面列出的内容看上去和传统行业数据仓库用途也差不多，因此都那些要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除此之外数据量大之外，越来越多的业务具体的要求时效性，甚至于很多是特别要求实时的，同时，互联网行业的业务变化太快，不可能像传统行业完全不一样，这个可以不使用自顶往上的方法确立数据仓库，一劳永逸，它那些要求新的业务迅速能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中登陆游戏；
总之，互联网行业的数据仓库就是所谓的敏捷数据仓库，而且没有要求能急速的响应数据，也特别要求能急速的响应业务；
大力建设敏捷数据仓库，除了对架构技术上的要求之外，另外一个很最重要的方面，那是数据建模，如果没有一上去就寻思确立一套能兼容性问题所有数据和业务的数据模型，那就又回到民间数据仓库的建设上了，很难满足的条件对业务变化的快速响应。应对这个，好象是先将核心的不持久化的业务接受深度适宜建模（例如：实现网站日志成立的网站统计分析模型和用户打开浏览器轨迹模型；基于条件公司核心用户数据建立的用户模型），其它的业务像是都需要维度宽表的来建立起数据模型。这块是后话。
整体架构下面的图是我们目前建议使用的数据平台架构图，其实大多公司应该都差不多：
逻辑上，一般都有吧数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所有所不同，本质上的角色都基本上。
我们向下看：
数据采集数据采集层的任务是把数据从各种数据源中哪采和存储位置到数据存储上，期间有可能会做一些简单的擦洗。
数据源的种类比较好多：
网站日志：
充当互联网行业，网站日志占的份额大，网站日志存储在多台网站日志服务器上，
好象是在每台网站日志服务器上布署flumeagent，实时地的收集网站日志并存储位置到HDFS上；
业务数据库：
业务数据库的种类也多种多样，有Mysql、Oracle、SqlServer等，这时候，我们急迫的需要有一种能从各种数据库中将快速同步到HDFS上的工具，Sqoop是一种，不过Sqoop极为繁重，但论数据量大小，都不需要启动MapReduce来执行，不过必须Hadoop集群的每台机器都能不能访问业务数据库；如何应付此场景，淘宝开源的DataX，是另一个非常好的解决方案（可参考文章《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，这个可以基于组件DataX之上做二次开发，就能相当好的解决，我们目前可以使用的DataHub也是。
当然，Flume通过配置与开发，也可以不实时动态的从数据库中歌词同步数据到HDFS
依附于Ftp/Http的数据源：
有可能一些合作伙伴提供的数据，需要按照Ftp/Http等设置定时查看，DataX也可以不不满足该需求
其他数据源：
例如一些手工录入的数据，只不需要能提供一个接口或小程序，即可能完成
数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美身体数据存储解决方案。
自动更新数据分析与计算，也就是对实时性要求不高的部分，在我现在看来，Hive那就随后而来的选择，丰富的数据类型、内置函数；压缩比太高的ORC文件存储格式；非常方便的SQL支持什么，使得Hive在设计和实现结构化数据上的统计分析远不如比MapReduce要又高效的多，一句SQL可以结束的需求，的新MR可能要上百行代码；
当然了，建议使用Hadoop框架很自然也提供给了MapReduce接口，如果没有真有很不乐意开发Java，也可以对SQL不熟，那么也这个可以使用MapReduce来做分析与计算；Spark是这两年太火的，在实践，它的性能虽然比MapReduce好多了很多，而且和Hive、Yarn特点的越来越好，并且，必须允许不使用Spark和SparkSQL来做分析和计算。只不过早就有HadoopYarn，使用Spark不过是更加很难的，不用什么分开来重新部署Spark集群，关于Spark On Yarn的相关文章，可可以参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。
数据共享这里的数据共享，反正指的是前面数据分析与计算后的结果储存时的地方，反正是关系型数据库和NOSQL数据库；
前面不使用Hive、MR、Spark、SparkSQL讲和计算的结果，我还是在HDFS上，但大部分业务和应用不可能真接从HDFS上某些数据，那就就必须一个数据共享的地方，令各业务和产品能方便些的声望兑换数据；和数据采集层到HDFS刚好相反，这里是需要一个从HDFS将数据同步至其他目标数据源的工具，虽然，DataX也这个可以行最简形矩阵。
另外，一些实时计算的结果数据很可能由实时计算模块就写入到数据共享。
数据应用
业务产品
业务产品所使用的数据，早存在于数据共享层，他们直接从数据共享层访问再试一下；
报表
同业务产品，报表所使用的数据，好象也早汇总上报好的，贮存于数据共享层；
即席查询
即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、哪怕是部门老大，他们应该有即席去查询数据的需求；
这种即席去查询常见是可以做到的报表和数据共享层的数据并不能不能行最简形矩阵他们的需求，需要从数据存储层再可以查询。
即席查询一般是通过SQL能够完成，最大的难度只是相对而言响应速度上，建议使用Hive稍微有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，但是能很好的与Hive兼容性。
其实，你也也可以在用Impala，要是不在乎平台中再多一个框架的话。
OLAP
目前，很多的OLAP工具不能不能很好的支持从HDFS上然后资源数据，全是按照将是需要的数据同步到关系型数据库中做OLAP，但要是数据量巨型的话，关系型数据库显然不行的话；
这时候，需要做或者的开发，从HDFS或则HBase中某些数据，完成OLAP的功能；
比如说：据用户在界面上中,选择的不定的维度和指标，按照开发接口，从HBase中声望兑换数据来展示更多。
其它数据接口
这种接口有通用的，有订制的。例如：一个从Redis中某些用户属性的接口是通用的，所有的业务都这个可以内部函数这个接口来某些用户属性。
实时计算现在业务对数据仓库实时性的需求越来越密集，.例如：实时地的了解网站的构造流量；实时的资源一个广告的曝光和再点；在海量数据下，依靠悠久的传统数据库和传统实现方法方法基本上结束不了，需要的是一种分布式的、高吞吐量的、连接时间低的、高可靠的实时计算框架；Storm在这块是比较比较完全成熟了，但我你选SparkStreaming，原因很简单，不打算多化入一个框架到平台中，同时，SparkStreaming比Storm显示延时性高这样一点点，那对此我们的需要可以遗漏掉。
我们目前在用SparkStreaming实现方法了实时地的网站流量统计、实时的广告效果统计两块功能。
做法也很简单的，由Flume在前端日志服务器上收集到网站日志和广告日志，实时动态的你的邮箱给SparkStreaming，由SparkStreaming能完成统计，将数据存储至Redis，业务实际访问Redis实时地声望兑换。
任务调度与监控在数据仓库/数据平台中，有各种各样相当多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了有定时调度，还存在地更加急切的任务感情依赖关系，比如说：数据分析任务需要等相对应的数据采集任务完成后才能结束；同步数据任务是需要等数据分析委托任务后才能结束；这就必须一个太体系的任务调度与监控系统，它作为数据仓库/数据平台的中枢，专门负责调度和监控所有任务的分配与运行。
前面有写过文章，《大数据平台中的任务调度与监控》,这里再次累赘。
总结归纳在我看样子架构并不是技术就会越新越好，完全是在可以满足需求的情况下，越简单啊越很稳定越好。目前在我们的数据平台中，开发大量的是了解业务，而不是技术，他们把业务和需求搞清了，基本都只是需要做简单SQL开发，接着配置到调度系统就可以了，如果没有任务十分，会送来告警。这样，可以使更多的资源专注于业务之上。
3年金融BI项目工作经验，换工作去文思（原TD到东南到文思）团队做数据仓库好,还是去宇信易做风险集市好？
哪个方面更有发展呢？待遇咋样啊？
东南工银,文思,软通我顶啊？这么大牛我上次从融通进去,前期做数据仓库后来做JAVA了,义务加班都多,听他们说文思好在点吧。我一个同事辞职跳槽过来了,华为外包都TDM得坑爹啊,做好不做外包吧。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
