数据库与数据仓库

数据库与数据仓库：
简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。
数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。
单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。
数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。
补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。
1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。
2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。
3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。

数据建模：
很多人一听到数据建模，就觉得高不可攀，觉得是很高深难以理解的东西，其实简单来说，数据建模就是搞清楚每个表都有哪些字段、表之间有什么联系，然后根据需要添加字段或度量值、建立关系的过程。
字段值、字段类型、表与表之间的关系，都是数据模型的一部分，在PowerBI中，建立的度量值同样是模型的一部分。
数据建模不难理解，也并不代表数据建模就很简单，当表比较少并且结构简单的时候，数据建模确实不难，但当表的数据达到上百个，关系错综复杂的时候，想建立好一个模型并不是那么简单的，你需要掌握的不仅是建模知识，更要深入了解业务之间的内在联系，并通过建立关系的方式，将业务的内在联系可视化。

数据仓库的整理架构，各个系统的元数据通过ETL同步到操作性数据仓库ODS中，对ODS数据进行面向主题域建模形成DW（数据仓库），DM是针对某一个业务领域建立模型，具体用户（决策层）查看DM生成的报表。

例如：
主题：某年某月某一地区的汽车销售情况

数据源：商业部门、工业部门
数据归集：客户信息、车辆信息、零售信息、经销商、保险、保修、延保、批量信息、维修信息、潜客等

广菲克的报告按部门分：市场部、销售部、网络部、售后部。还有管理层报告
销售里的主题有：建档、订单、批售、扫票、零售、库存主题
市场不分主题：主要看整个营销漏斗，指标有：线索，到店，订单，零售，以及之间的转化率
售后主题：产值/客单价。在此基础上扩展出的，根据客户返厂维修保养批次区分出来的活跃客户，忠诚客户，准流失客户，流失客户。零件库存分析、出库金额分析等
网络部主要是对4S店的软硬件，以及上述的市场、销售、售后部门的核心KPI指标进行考核，对经销商经销商打分。

构建整个BI报表平台大概分为几个环节：数据源、数据采集抽取、数据存储、数据建模分析、数据展示；
本次项目需实现信息监测应用、客户统一视图应用、管理驾驶舱应用、管理层战略大屏以及其他查询分析应用；

通过针对不同应用场景使用不同的算法进行数据建模，数据建模分析的主要要求如下表所示，包含但不限于：

数仓的数据来源是哪些？数据的目的地有哪些？
数据来源： 日志采集系统、业务系统数据库、爬虫系统、财务系统、OA系统等
日志采集系统：采集用户在网站的停留时间，搜索的关键字以及喜好，数据存在file日志文件中，数据量可以很大
业务系统数据库：比如电商网站的一些主要的业务数据，支付数据，订单数据等，存在mysql等数据库中，数据量有限
爬虫系统：爬取的其他企业的一些商品信息数据
数据目的地：
报表系统（最基本的数据输出），用户画像，推荐系统，机器学习，风控系统等

输入系统：埋点产生的用户行为数据、JavaEE后台产生的业务数据、个别公司有爬虫数据。
输出系统：报表系统、用户画像系统、推荐系统

1 数仓概念总结
1）数据仓库的输入数据源和输出系统分别是什么？
输入系统：埋点产生的用户行为数据、JavaEE后台产生的业务数据。
输出系统：报表系统、用户画像系统、推荐系统
2 项目需求及架构总结
2.1 集群规模计算
2.1.1 如何确认集群规模？（假设：每台服务器8T磁盘，128G内存）
1）每天日活跃用户100万，每人一天平均100条：100万*100条=10000万条
2）每条日志1k左右，每天一亿条：100000000*1k/1024/1024=约100G
3）半年内不扩容服务器来算：100G*180天=约18T
4）保存3副本：18T*3=54T
5）预留20%~30%buf=54T/0.7=77T
6）算到这：77T/8T=约10台这样的服务器。
2.1.2 如果考虑数仓分层？
服务器将近再扩容1-2倍。
2.2 框架版本选型
1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）
2）CDH：国内使用最多的版本，但CM不开源，但其实对中、小公司使用来说没有影响（建议使用）
3）HDP：开源，可以进行二次开发，但是没有CDH稳定,国内使用较少
2.3 服务器选型
服务器使用物理机还是云主机？
1）机器成本考虑：
（1）物理机：以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，单台报价4W出头，需考虑托管服务器费用。一般物理机寿命5年左右
（2）云主机，以阿里云为例，差不多相同配置，每年5W
2）运维成本考虑：
（1）物理机：需要有专业的运维人员
（2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松

更多内容：数仓学习总结_chaoshuaili的博客-CSDN博客