一文入门大数据和数仓（概念篇）

云计算、大数据和人工智能简称为 CBA，三者经常会被放在一起提及，分别代表着算力、分析和应用。从企业的信息化到数字化，大数据的应用越来越广。无论是个性化推荐、精细化运营、数据中台，还是数据埋点、用户画像等等，我们耳能详熟的名词，往往都离不开大数据的支持。

很多时候，我们谈到大数据也是知其然不知其所以然，了解 Hadoop，但是不知道是什么，能干什么。刚好因为学习数仓的缘故，深入了解了下大数据生态。本文作为总结，如有遗漏之处，还请斧正，这里从以下几个方面介绍：

1. 大数据定义与历史
2. 大数据与 Hadoop
3. 数据仓库和中台
4. 互联网大厂大数据架构赏析

01、大数据定义与历史

在维基百科中，大数据指的是在传统数据处理应用软件不足以处理的大或复杂的数据集的术语。其中，具有 4V 特征，分别Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）。

人类发展的一大拐点是“社会分工”，没有分工，就没有交易和交换。“社会分工”的本质是让专业人干专业事，最终使平均社会劳动时间缩短。而计算机技术的发展，无不也在遵循着“分工”的大规律。

云计算颠覆了 IT 基础设施格局的依据也在于此。

而数据的价值在于流转，容量和效率成为了关键词。要聊大数据，就得从数据库开始。

计算机诞生之初，传统的文件系统难以应对数据增长的挑战,也无法满足多用户共享数据和快速检索数据的需求，研究者们将结构化数据从应用程序中独立出来并进行集中管理，于是诞生了网状数据库。但是网状数据库在数据独立性和抽象级别有较大不足，于是后来又诞生了迄今扔占据主流的关系数据库，其意义在于在统一数据抽象层和使用标准化查询语言 SQL 简化数据存储和处理。

数据库最开始都是单机存在的，也能满足当时的业务。但是随着互联网时代的到来，数据爆炸增长，给数据库带来了新的挑战：越来越多的数据，多到单机已经无法存储和处理。

在这时即 2004 年前后，Google在后发表了三篇技术论文，即大数据技术的“三驾马车”，分别是文件系统GFS、计算框架MapReduce、NoSQL数据库系统BigTable：

• 分布式文件系统GFS：解决了数据大规模存储的问题，让数据可以几乎无限的增长下去；
• 大数据分布式计算框架MapReduce：解决了数据大规模计算的问题，让大规模数据处理成为可能；
• NoSQL 数据库系统BigTable： 解决了在线实时查询的问题，即使数据量很大，用户也能很快的查询到数据。

然而，谷歌仅仅只是发表了论文，提供了理论，揭开了大数据的帷幕。此后，根据三篇论文的理论诞生的 Hapdoop 框架 。

由于开源和降低了应用门槛（使用多台普通服务器即可）等特性，Hadoop对企业大数据应用推广起到了决定性作用。

02、大数据与 Hadoop

Hadoop 真正开启了行业大数据时代，产品的核心理念，就是可以使用一堆廉价的服务器进行稳定的可靠的计算和存储，这也使大数据“飞入寻常百姓家”。

现如今，谈大数据时，由于Hadoop的应用广泛性，往往都指的是Hadoop。无数号称新一代、下一代的大数据技术无不构建在 Hadoop 生态基石之上。

经过了十几年的发展，如今的 Hadoop 生态，已经发展为拥有几十个组件的大家伙，甚至近几年，还产生了如 Flink、Spark 等更好的替代原生的组件。

无需了解细节，只要知道能用来用途即可。

HDFS（分布式文件系统）

定义：解决文件的海量存储问题，利用廉价的普通服务器作为其存储，组建一个大规模存储集群。

组成：文件最终是以数据块的形式存储，数据块大小默认为 64MB。由一个元数据（NameNode）和很多个数据节点（Datanode）组成：元数据管理文件系统的元数据，而数据节点存储了实际的数据。

优点：支持横向弹性扩容，支持多副本冗余，提供数据一致性保障。

缺点：一次写入，多次读出，导致不支持文件的修改，不适合反复修改数据的场景。数据块的存储模式导致不适合低时延的应用和小文件存储。

MapReduce（分布式离线计算框架）

定义：解决了分布式计算的问题，以一种可靠容错的方式并行处理上T级别的数据集。

组成：map 函数用于组织和分割数据；reduce 函数主要负责在分布式节点上的数据运算。

优点： 易于编程、高容错性、适合PB级以上海量数据的离线处理

缺点：不擅长实时计算(Spark擅长)、流式计算（Spark Stream擅长）和DAG（有向图）计算。

Hive（数据仓库工具）

定义：MapReduce编程十分繁琐，仅有少部分程序员能够驾驭。2010 年，Facebook 开源了 Hive，其能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。

优点：使用 SQL 就能查询数据和分析数据，像笔者这种大数据渣也能使用 SQL 玩转数据。还提供统一的元数据管理，可扩展性好，支持自定义函数（UDF）。

缺点：Hive 不支持实时查询和行级更新，不适用于在线事务处理。

HBase（分布式数据库）

定义：NoSQL 数据库，利用 HDFS 作为底层存储，海量存储架构，主要适用于海量明细数据（十亿、百亿）的随机实时查询，如日志明细、交易清单、轨迹行为等。

优点：实时计算，客户端通过 API 直接访问 HBase，实现实时计算。列式存储，适用于在线分析处理（OLAP），面向列的数据库设计的宽表。容量大性能高，支持高并发的读写操作。

缺点：不能支持条件查询，只支持按照Row key来查询，也不适合于大范围扫描查询。

Spark（通用分析引擎）

定义：基于内存计算的大数据并行计算框架，提高了在大数据环境下数据处理的实时性。它是MapReduce的替代方案，而且兼容HDFS、Hive、等分布式存储层，可融入Hadoop的生态系统，以弥补缺失MapReduce的不足。
优点：

• 基于内存运算，比 MapReduce要快100倍以上，而基于磁盘的运算也要快10倍以上。
• 支持访问各种不同的数据源，比如 HDFS、HBase、Hive、Cassandra.
• 且支持 API 方式调研，提供了多种解决方案，如Spark可以用于批处理、交互式查询（通用Spark SQL）、实时流处理（通过Spark Streaming）、机器学习（通过Spark MLlib）和图计算（通过Spark GraphX）。

缺点：虽然提供了，但是并不适合迭代计算(如机器学习、图计算等)，交互式处理(数据挖掘) 和流式处理(点击日志分析)。

Spark（通用分析引擎）

Flink（分布式流处理引擎）

定义：一个框架和分布式处理引擎，用于在无边界（实时数据）和有边界数据流（历史数据）上进行有状态的计算。

优点：支持毫秒级别的流计算，Spark 的流计算只能支持秒级别，支持迭代计算。

缺点：社区建设相对于Spark、Storm 缺失。

Storm（分布式实时流计算系统）

定义：开源的分布式实时计算系统，可以简单、可靠的处理大量的数据流。和 Flink 类似，经常被相互比较。

优点：最老的流处理框架，技术成熟可靠。社区也很活跃。

缺点：无状态，需用户自行进行状态管理。Flink 框架本身性能优于 Storm，美团技术团队出品的一篇 Flink 和 Storm 测评结果显示，Flink 吞吐约为 Storm 的 3-5 倍，满吞吐时的延迟约为 Storm 的一半。

按照时间来算，Storm > Spark > Flink。

Flume（大式日志采集系统）统）

定义：一个分布式、可靠、和高可用的海量实时日志采集、聚合和传输的系统。

优点：支持各种接入资源数据的类型以及接出数据类型，可以采集文件，socket数据包、文件、文件夹、kafka等各种形式源数据，又可以将采集到的数据(下沉sink)输出到HDFS、Hbase、Hive、Kafka等众多外部存储系统中。

缺点：无法监控文件内容的变化，只能监控文件的增加，如果修改了文件名，flume会报错。

Kafka（分布式发布订阅消息系统，简称消息队列）

定义：分布式的消息缓存系统，用于日志处理的分布式消息队列。消息队列除了 Kafka，还有RocketMQ、RabbitMQ，主要都用来“削峰填谷”，但是 Kafka 是专为大数据而生的消息中间件，单机写入TPS约在百万条/秒，RocketMQ 则一般用于秒杀，阿里双11就用的这个。

优点：吞吐量大，支持使用多台廉价服务器部署，可以支持日志缓存，一般是Flume + Kafka

缺点：可能会重复消费数据，消息会乱序，需要配合zookeeper进行元数据管理。

系统组件

其中，还有一些 Hadoop 的原生组件，这里只作简单介绍：

• Yarn（资源调度和管理框架）：Hadoop1.x 是MapReduce包含资源调度，在Hadoop2.x引入拆分出了新组件，为各类计算框架提供资源的管理和调度。负责管理集群中的资源：CPU，内存，磁盘，网络IO等等。
• ZooKeeper（分布式协作服务）：为分布式奇数集群服务实现协作服务。

03、数据仓库和数据中台

在前面中介绍中的数据仓库工具Hive，由于其极低的使用门槛，在 Facebook 开源 Hive 后，迅速得到了市场的认可和追捧。

一直谈大数据，谈 Hadoop。实际上，还有不可或缺的数据仓库(Data Warehouse，DW)。

比尔·恩门（Bill Inmon）于1990年提出数据仓库的概念，大概意思就是将业务系统的数据联机事务处理(OLTP)经过清理、转换、分类后进入联机分析处理(OLAP)，辅助并支持如决策支持系统(DSS)，最终实现商业智能（BI）。

数据仓库是来自一个或多个不同源的集成数据的中央存储库，将当前和历史数据存储在一起。具备四个特征：

• 面向主题的（Subject Oriented）：将相同意义归类至相同的主题区。
• 集成的（Integrate）：数据来源于数据联机事务处理(OLTP)系统。
• 相对稳定的（Non-Volatile）：一旦确认写入后是不会被取代或删除的。
• 反映历史变化（Time Variant）：数据的变动，在数据仓库中是能够被纪录以及追踪变化的，简单来说，数仓中包含了所有的数据和变化。

一定程度上讲，大数据的发展，也是数据仓库的变迁。业务的发展带来数据量变得越来越大，数据格式越来越多。原始时代的数仓，关系型数据库承载数据仓库的基础能力。最终，到大数据时代，数仓存储在 hadoop平台的 HDFS 中，一般采用列式存储。

Hadoop + Hive 是现如今的主流离线数仓方案， 即将数据存储在 Hadoop，然后利用 Hive 或 Presto 进行查询（非分析）。题外话，Presto 由于基于内存运算，所以平均性能是 Hive 的10倍，是 Facebook 在 2013 开源的，但是 Presto 不适合连表查，如果大量连表可能就直接报错了，所以和 Hive 分别适用不同的场景。

然而，正如前文说的，大数据发展至今，衍生了许多的组件。从离线到实时，从批处理，到流处理，而这些，也对应着大数据体系下的数仓变革。

storm的创始人推出了数仓方案的 Lambda 架构，实际上，现如今许多公司也是采用的这种方案。简单来说，离线的专门做离线数据处理（例如使用hive，impala，presto，sparkSQL等各种OLAP的技术框架），实时的就专门使用实时处理技术（例如storm，sparkStreaming，flink流处理程序等）。

也正是因为实时和离线分开，容易导致实时与批量计算结果不一致引起的数据口径问题。另外一方面，这种架构会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。

也因此，Kappa架构诞生了，简单来说就是通过改进流计算系统来解决数据全量处理的问题，而数据存储则放在Kafka这样的临时存储区。

当然，Kappa架构的缺点也显而易见，虽然只用无需维护两套代码，但是流式处理对于很早的历史数据处理却显得力不从心。

实际上，业务决定架构。在真实的场景中，很多可能是两者架构的结合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。

前面阐述如此多关于数据仓库的概念，并不是偏题，也不是忘记数据中台概念。实在是因为，数据中台从某个意义来说是属于数仓的一种，建立在数据仓库之上。核心理念是OneData，即融合整个企业的全部数据，打通数据之间的隔阂，消除数据标准和口径不一致的问题。但是，两者目标以及数据应用的方向都存在很大差异。

对于传统数据仓库而言，更多的价值体现提供所有类型数据支持决策制定过程，而对于数据中台而言，是面向业务的升级，解决了数据“汇管用”的问题。即将共性的数据需求（商品推荐、信息推送等）去重和沉淀，提供统一的数据服务接口，六字方针：收集、管理、智能。最终实现数据业务化。

当然，对于数据中台而言，技术和理念并不复杂，难的是组织理念。

04、互联网大厂大数据架构赏析

美团

阿里

参考资料

《数据仓库发展、架构与趋势》

《关于数据仓库建设，了解这7点就够了》

《流计算框架 Flink 与 Storm 的性能对比 – 美团技术团队》