美团大数据分析报告美团大数据架构

转载

archangle 2023-11-10 21:04:46

文章标签 美团大数据分析报告数据数据仓库数据库 文章分类 数据分析人工智能

美团的技术架构图

美团大数据分析报告美团大数据架构_数据库

flume

可以采集文件，socket数据包等各种形式源数据，又可以将采集到的数据输出到HDFS、hbase、hive、kafka队列等众多外部存储系统中,一般的采集需求，通过对flume的简单配置即可实现,Flume针对特殊场景也具备良好的自定义扩展能力，因此，flume可以适用于大部分的日常数据采集场景

美团大数据分析报告美团大数据架构_数据库_02

sqoop

sqoop是apache旗下一款“Hadoop和关系数据库服务器之间传送数据”的工具。

导入数据：MySQL，Oracle导入数据到Hadoop的HDFS、HIVE、HBASE等数据存储系统；

导出数据：从Hadoop的文件系统中导出数据到关系数据库

美团大数据分析报告美团大数据架构_数据仓库_03

数据仓库

数据仓库，英文名称Data Warehouse，简写为DW。数据仓库顾名思义，是一个很大的数据存储集合，出于企业的分析性报告和决策支持目的而创建，对多样的业务数据进行筛选与整合。它为企业提供一定的BI（商业智能）能力，指导业务流程改进、监视时间、成本、质量以及控制。

数据仓库的输入方是各种各样的数据源，最终的输出用于企业的数据分析、数据挖掘、数据报表等方向。

美团大数据分析报告美团大数据架构_数据_04

那么，数据仓库都有什么特点呢？

1.主题性

不同于传统数据库对应于某一个或多个项目，数据仓库根据使用者实际需求，将不同数据源的数据在一个较高的抽象层次上做整合，所有数据都围绕某一主题来组织。

这里的主题怎么来理解呢？比如对于滴滴出行，“司机行为分析”就是一个主题，对于链家网，“成交分析”就是一个主题。

2.集成性

数据仓库中存储的数据是来源于多个数据源的集成，原始数据来自不同的数据源，存储方式各不相同。要整合成为最终的数据集合，需要从数据源经过一系列抽取、清洗、转换的过程。

3.稳定性

数据仓库中保存的数据是一系列历史快照，不允许被修改。用户只能通过分析工具进行查询和分析。

4.时变性

数据仓库会定期接收新的集成数据，反应出最新的数据变化。这和特点并不矛盾。

数据仓库的数据要通过ETL来产生，详细请见

ETL(Extraction-Transformation-Loading)

ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。 ETL是BI项目重要的一个环节。通常情况下，在BI项目中ETL会花掉整个项目至少1/3的时间,ETL设计的好坏直接关接到BI项目的成败。

数据仓库和ODS的区别

数据仓库存储是一个面向主题的，反映历史变化数据，用于支撑管理决策。

ODS

操作型数据存储，存储的是当前的数据情况，给使用者提供当前的状态，提供即时性的、操作性的、集成的全体信息的需求。

ODS作为数据库到数据仓库的一种过渡形式，与数据仓库在物理结构上不同，能提供高性能的响应时间,ODS设计采用混合设计方式。

ODS中的数据是"实时值",而数据仓库的数据却是"历史值"，一般ODS中储存的数据不超过一个月，而数据仓库为10年或更多.

Data Mart

为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。

DSS(decision-support system)决策支持系统：

用于支持管理决策的系统。通常，DSS包括以启发的方式对大量的数据单元进行的分析，通常不涉及数据更新。

参考一：

(本部分为转)我在公司的数据部门工作，每天的订单类数据处理流程大致如下：

删除分析数据库的历史订单数据
全量更新订单数据到分析数据库。（由于订单核心数据不大，所以经受得起这么折腾）
将数据简单清洗，并生成数据集市层
分析处理，产出报表。当然还有其他的数据也是这么处理的（比如产品的数据、景区的数据、票种的数据、供应商的数据等等）

还有日志类的数据，这里不是重点，就不介绍了！这么干了一年，发现有如下问题：

业务变化很快，比如业务数据表经常变化字段含义、增加各种逻辑数据等
业务数据源越来越多，随着品类越来越多，新部门逐步成立，数据源也就越来越多样化
需求越来越多，越来越复杂，以前只有大佬想我们要战略数据，可是现在所有的产品和运营都向我们要各种各样的用户行为数据、订单分析数据和竞对优势数据
数据的实时行要求越来越高，这到不是说秒级别就看见结果，而是早晨提出个新业务数据需求，晚上就要！

数据毕竟是为了市场服务的，所以需求我们要跟上它的节奏，这就对数据系统提出了很大的挑战，导致数据质量下降、生产效率下降！该怎么解决哪？在解决这个问题的过程中，逐步发现了一点苗头：发现我们建立的数据仓库与它的定义不太符合。下面是数据仓库的定义：

数据仓库（Data Warehouse）：是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

很明显我们并不符合相对稳定的和反应历史变化的两个条件，因为类似订单类数据，每天全量更新（原因是同一个订单状态随着时间会变化，比如今天买了，明天退货了）。这就明显不符合想对稳定这一概念了，更别说反应历史变化了！经过最近的思考，发现自己搭建的系统更符合ODS的定义：

ODS：是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。

那么大家可能会问ods和数据仓库的区别是什么哪？答：ods是短期的实时的数据，供产品或者运营人员日常使用，而数据仓库是供战略决策使用的数据；ods是可以更新的数据，数据仓库是基本不更新的反应历史变化的数据，还有很多，这里就不一一列举了。

讲到这里问题就明晰了，如何能搭建一个体系，既能支持战略决策使用的数据仓库数据，又能兼容业务快速的变化和运营产品人员日常需求的ODS数据哪？

数据仓库和ODS并存方案

经过调研，发现大体上有三种解法：

1、业务数据－ ODS －数据仓库

美团大数据分析报告美团大数据架构_数据库_05

优点：这样做的好处是ODS的数据与数据仓库的数据高度统一；开发成本低，至少开发一次并应用到ODS即可；可见ODS是发挥承上启下的作用，调研阿里巴巴的数据部门也是这么实现的。

缺点：数据仓库需要的所有数据都需要走ODS，那么ODS的灵活性必然受到影响，甚至不利于扩展、系统的灵活性差

2、OB － ODS

优点：结构简单。一般的初创数据分析团队都是类似的结构，比如我们部门就应该归结到这一范畴

缺点：这样所有数据都归结到ODS，长期数据决策分析能力差，软硬件成本高，模块划分不清晰，通用性差

3、数据仓库和ODS并行

美团大数据分析报告美团大数据架构_数据_06

可见这个模型兼顾了上面提高的各自优点，且便于扩展，ODS和数据仓库各做各的，形成优势互补！可以解决现在互联网公司遇到的快速变化、快速开发等特点！特别是对于那些刚刚创建数据团队，数据开发人员紧缺的公司，可以尝试使用这个数据架构解决问题！

参考2

背景知识：在当今这样一个信息技术发展迅速的时代，数据量也在不断的增长，面临这样的压力，总是会有大神提出一些解决方案。比如高层管理人员希望能查看整个公司的发展业绩，数据仓库(Data Warehouse, DW)正是解决该问题的主要方案，随之DW就这样产生了。可是时代在变，需求也会随着改变，比如保险公司的员工希望提高自己的业绩，拿更多的工资，那么他首先希望的就是能把更多的客户挖进来，其实这其中是有很多方法的。最基本的例子，比方说某保险公司的一个客服希望能够以最高的成功率向客户推荐相关的业务，一旦客户来电，客服可以立刻从数据库中调出该客户的相关的一连串信息，从而可以根据这些信息有针对性的向客户推荐相关的业务了，显然，这样的推荐方式明显可以提高成功率。那么问题就来了，怎么解决这样的问题呢？随之，操作型数据存储(Operational Data Store, ODS)的诞生给此类问题提供了良好的解决方案。从理论上讲，这两种解决方案到底有什么区别呢？现在进入正题。

ODS与DW的区别主要有以下几点：

1、数据的当前性

ODS包括的是当前或接近当前的数据，ODS反映的是当前业务条件的状态，ODS的设计与用户或业务的需要是有关联的，而DW则是更多的反映业务条件的历史数据。

2、数据的更新或加载

ODS中的数据是可以进行修改的，而DW中的数据一般是不进行更新的。ODS的更新是根据业务的需要进行操作的，而没有必要立即更新，因此它需要一种实时或近实时的更新机制。另外，DW中的数据是按照正常的或预先指定的时间进行数据的收集和加载的。

3、数据的汇总性

ODS主要是包括一些细节数据，但是由于性能的需要，可能还包括一些汇总数据，如果包括汇总数据，可能很难保证数据的当前性和准确性。ODS中的汇总数据生命周期比较短，所以可称作为动态汇总数据，如果细节数据经过了修改，则汇总数据同样需要修改。而DW中的数据可称为静态的汇总数据。

4、数据建模

ODS是站在记录层面访问的角度而设计的，DW或DM则是站在结果集层面访问的角度而设计的。ODS支持快速的数据更新，DW作为一个整体是面向查询的。

5、查询的事务

ODS中的事务操作比较多，可能一天中会不断的执行相同的事务，而DW中事务的到达是可以预测的。

6、用途

ODS用于每一天的操作型决策，是一种短期的；DW可以获取一种长期的合作广泛的决策。ODS是策略型的，DW是战略型的。

7、用户

ODS主要用于策略型的用户，比如保险公司每天与客户交流的客服；而DW主要用于战略型的用户，比如公司的高层管理人员。

8、数据量（主要区别之一）

ODS只是包括当前数据，而DW存储的是每一个主题的历史快照；

美团大数据分析报告美团大数据架构_数据库_07

OLTP与OLAP的介绍

数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

OLTP与OLAP之间的比较：

美团大数据分析报告美团大数据架构_数据库_08

  OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
（1）CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上，逻辑读总量等于单个语句的逻辑读乘以执行次数，如果单个语句执行速度虽然很快，但是执行次数非常多，那么，也可能会导致很大的逻辑读总量。设计的方法与优化的方法就是减少单个语句的逻辑读，或者是减少它们的执行次数。另外，一些计算型的函数，如自定义函数、decode等的频繁使用，也会消耗大量的CPU时间，造成系统的负载升高，正确的设计方法或者是优化方法，需要尽量避免计算过程，如保存计算结果到统计表就是一个好的方法。
（2）磁盘子系统在OLTP环境中，它的承载能力一般取决于它的IOPS处理能力. 因为在OLTP环境中，磁盘物理读一般都是db file sequential read，也就是单块读，但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其IOPS的时候，就会出现大的性能问题。
OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术，Cache决定了很多语句不需要从磁盘子系统获得数据，所以，Web cache与Oracle data buffer对OLTP系统是很重要的。另外，在索引使用方面，语句越简单越好，这样执行计划也稳定，而且一定要使用绑定变量，减少语句解析，尽量减少表关联，尽量减少分布式事务，基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高，批量更新时要分批快速提交，以避免阻塞的发生。
OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的系统。对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL来说，尽可能使用变量绑定技术来达到SQL重用，减少物理I/O 和重复的SQL 解析，从而极大的改善数据库的性能。
这里影响性能除了绑定变量，还有可能是热快（hot block）。当一个块被多个用户同时读取时，Oracle 为了维护数据的一致性，需要使用Latch来串行化用户的操作。当一个用户获得了latch后，其他用户就只能等待，获取这个数据块的用户越多，等待就越明显。这就是热快的问题。这种热快可能是数据块，也可能是回滚端块。对于数据块来讲，通常是数据库的数据分布不均匀导致，如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的，对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。
  OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。
在OLAP系统中，常使用分区技术、并行技术。
分区技术在OLAP系统中的重要性主要体现在数据库管理上，比如数据库加载，可以通过分区交换的方式实现，备份可以通过备份分区表空间实现，删除数据可以通过分区进行删除，至于分区在性能上的影响，它可以使得一些大表的扫描变得很快（只扫描单个分区）。另外，如果分区结合并行的话，也可以使得整个表的扫描会变得很快。总之，分区主要的功能是管理上的方便性，它并不能绝对保证查询性能的提高，有时候分区会带来性能上的提高，有时候会降低。
并行技术除了与分区技术结合外，在Oracle 10g中，与RAC结合实现多节点的同时扫描，效果也非常不错，可把一个任务，如select的全表扫描，平均地分派到多个RAC的节点上去。
在OLAP系统中，不需要使用绑定（BIND）变量，因为整个系统的执行量很小，分析时间对于执行时间来说，可以忽略，而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引，物化视图，对于大的事务，尽量寻求速度上的优化，没有必要像OLTP要求快速提交，甚至要刻意减慢执行的速度。
绑定变量真正的用途是在OLTP系统中，这个系统通常有这样的特点，用户并发数很大，用户的请求十分密集，并且这些请求的SQL 大多数是可以重复使用的。
对于OLAP系统来说，绝大多数时候数据库上运行着的是报表作业，执行基本上是聚合类的SQL 操作，比如group by，这时候，把优化器模式设置为all_rows是恰当的。而对于一些分页操作比较多的网站类数据库，设置为first_rows会更好一些。但有时候对于OLAP 系统，我们又有分页的情况下，我们可以考虑在每条SQL 中用hint。如：
Select a.* from table a;
分开设计与优化
在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。
如分区技术，假设不是大范围地使用分区关键字，而采用其它的字段作为where条件，那么，如果是本地索引，将不得不扫描多个索引，而性能变得更为低下。如果是全局索引，又失去分区的意义。
并行技术也是如此，一般在完成大型任务时才使用，如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度。如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了。
位图索引也是一样，如果用在OLTP环境中，很容易造成阻塞与死锁。但是，在OLAP环境中，可能会因为其特有的特性，提高OLAP的查询速度。MV也是基本一样，包括触发器等，在DML频繁的OLTP系统上，很容易成为瓶颈，甚至是Library Cache等待，而在OLAP环境上，则可能会因为使用恰当而提高查询速度。
对于OLAP系统，在内存上可优化的余地很小，增加CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方法，当然这也意味着系统成本的增加。
比如我们要对几亿条或者几十亿条数据进行聚合处理，这种海量的数据，全部放在内存中操作是很难的，同时也没有必要，因为这些数据快很少重用，缓存起来也没有实际意义，而且还会造成物理I/O相当大。所以这种系统的瓶颈往往是磁盘I/O上面的。
对于OLAP系统，SQL 的优化非常重要，因为它的数据量很大，做全表扫描和索引对性能上来说差异是非常大的。
其他
  Oracle 10g以前的版本建库过程中可供选择的模板有：
Data Warehouse （数据仓库）
General Purpose （通用目的、一般用途）
New Database
Transaction Processing （事务处理）
  Oracle 11g的版本建库过程中可供选择的模板有：
一般用途或事务处理
定制数据库