大数据介绍

作为想要从事大数据，或已是大数据从业者但非大数据开发人员，我们如何理解和学习大数据平台的技术知识呢？

本文将以作为数据产品经理的角色来写写自己的理解思路，希望对大家有所帮助。

一、大数据平台介绍

首先，先解释下大数据的5V特征：

• 数据量大：一般以P（1000个TB）、E（100万个TB）或Z（10亿个TB）为计量单位
• 数据类型繁多：包括结构化、半结构化和非结构化的数据，数据来源多样，文本、日志、视频、图片、地理位置等；
• 价值密度低：大数据所具备的巨大体量，使其所包含信息较少。因此需要利用通过数据分析与机器学习更快速的挖掘出有价值的数据，带来更多的商业价值。
• 速度快：数据增长速度快、并要求处理速度快、对时效性要求也高，海量数据的处理需求不再局限在离线计算当中。
• 真实性：数据的真实性和可信赖度差异较大，因此数据分析的精确度也有所不同。

大数据平台本质上就是对海量数据从采集、存储、计算、应用、管理、运维的多方位、多维度的组合研究设计，从而建设合理、高效的大数据平台架构。

二、大数据存储计算

1. 那我们先讲讲最核心的大数据存储和计算吧。

这里就不得不引入Hadoop这个框架。Hadoop是大数据存储和计算的鼻祖了，现在大多开源的大数据框架都依赖Hadoop或者与它能很好的兼容。

关于Hadoop，我们需要了解他们是什么、什么原理、使用场景、如何使用：

• HDFS、MapReduce
• NameNode、DataNode
• JobTracker、TaskTracker
• Yarn、ResourceManager、NodeManager

2. 对于大数据的处理，我们必须了解和会使用的就是SQL。

使用SQL处理分析Hadoop上的数据，方便、高效、易上手、更是趋势。不论是离线计算还是实时计算，越来越多的大数据处理框架都在积极提供SQL接口。

而Hive则是数据仓库工具。通过Hive命令行可以对数据进行创建表、删除表、往表中加载数据、分区、将表中数据下载到本地等操作。

至此，通过上面的知识学习，我们已经了解到，HDFS是Hadoop提供的分布式存储框架，它可以用来存储海量数据，MapReduce是Hadoop提供的分布式计算框架，它可以用来统计和分析HDFS上的海量数据，而Hive则是SQL On Hadoop，Hive提供了SQL接口，开发人员只需要编写简单易上手的SQL语句，Hive负责把SQL翻译成MapReduce，提交运行。

此时我们认知中的关于大数据平台架构至少包含以下部分：

Hive把MapReduce作为执行引擎，会发现其实执行会有些慢，所以很多SQL on Hadoop的框架越来越多，目前主流的开源OLAP计算引擎包括：Sparksql、Presto、Kylin、Impala、Druid、Clickhouse 等。因此这几个框架也扩充了数据计算层的多样性。

三、大数据采集

那我们如何将数据存储到HDFS上呢？这里就需要涉及数据的采集、转化、加载了。我们知道数据的来源多种多样，结构化的、半结构化和非结构化的，不同数据源也就会有不同的采集工具。例如：

• • Hadoop框架自带的命令：HDFS PUT命令、HDFS API
  • Sqoop：是一个主要用于Hadoop/Hive与传统关系型数据库Oracle/MySQL/SQLServer等之间进行数据交换的开源框架。就像Hive把SQL翻译成MapReduce一样，Sqoop把你指定的参数翻译成MapReduce，提交到Hadoop运行，完成Hadoop与其他数据库之间的数据交换。
  • Flume：是一个分布式的海量日志采集和传输框架，因为“采集和传输框架”，所以它并不适合关系型数据库的数据采集和传输。Flume可以实时的从网络协议、消息系统、文件系统采集日志，并传输到HDFS上。因此，如果你的业务有这些数据源的数据，并且需要实时的采集，那么就应该考虑使用Flume。
  • Data X：阿里开源的关系性数据库采集交换数据的工具

此时我们认知中关于大数据平台架构会包含：

四、大数据应用

以上我们已经了解了大数据从采集、存储、计算的技术架构和原理了，接下来我们就可以将计算好的数据同步和应用到其他系统中去。而这一步反向数据输出的技术工具可以是和我们数据采集转换时使用的工具是一样的，也可以是计算层的使用的框架。
而对于数据的应用，根据不同的业务属性和场景，大致会分为BI平台、应用系统、数据开发平台、数据分析挖掘等。具体数据应用的细分可以参考：Amy随笔记：应用数据产品合集

至此，大数据架构就会包含：

五、实时和离线

关于大数据的应用场景，我们知道有时候需要离线数据就可以了，但有些时候也需要实时的数据，所以我们在大数据的存储、计算时，同样也需要离线和实时的两套方案。

关于离线数据存储，我们就主要会依赖数仓分层建模的方式进行数据存储，详细细节可参考：Amy随笔记：数仓分层建模

关于实时数据传输，目前比较主流的就是使用Kafka框架，它是一种分布式发布订阅消息的系统，用来处理流数据。这种架构下，将数据分为生产者和消费者。实时的场景下，Kafka充当着将数据从生产者流通到消费者的管道角色，借此吞吐量大的优势，以此实现数据及时获取和传输。离线的场景下，HDFS也可以作为数据其中消费者，通过Kafka将数据同步到HDFS。

而对于实时的数据计算，其实也分为绝对实时和准实时两种场景。绝对实时的延迟要求一般在毫秒级，准实时的延迟要求一般在秒、分钟级。对于需要绝对实时的业务场景，用的比较多的是Storm，对于其他准实时的业务场景，可以是Storm，也可以是Spark Streaming、Flink。至此，大数据平台架构演变成了：

六、大数据任务调度

以上你会发现大数据平台的任务越来越多了，不仅仅是分析任务，数据采集、数据交换同样是一个个的任务。这些任务中，有的是定时触发，有的则需要依赖其他任务来触发。当平台中有几百上千个任务需要维护和运行时候，仅仅靠crontab这样简单的脚本执行任务是远远不够了，这时便需要一个调度监控系统来完成这件事。调度监控系统是整个数据平台的中枢系统，类似于AppMaster，负责分配和监控任务。像这样的框架常用的就有Apache Oozie、Azkaban㩐。这时数据架构就会包含：

七、大数据监控和管理

截止当前，我们了解了大数据从采集、存储、计算、应用的整个过程。但在这个过程中，程序任务是可能会出现很多问题的，例如：

1. 需要知道在数据流水线的任何步骤中数据都不会丢失。因此，你需要监控每个程序正在处理的数据量，以便尽快检测到任何异常;

2. 需要有对数据质量进行测试的机制，以便在数据中出现任何意外值时，你接收到告警信息;

3. 需要监控应用程序的运行时间，以便每个数据源都有一个预定义的ETA，并且会对延迟的数据源发出警报;

4. 需要管理数据血缘关系，以便我们了解每个数据源的生成方式，以便在出现问题时，我们知道哪些数据和结果会受到影响;

5. 需要系统自动处理合法的元数据变更，并能够发现和报告非法元数据变更;

6. 需要对应用程序进行版本控制并将其与数据相关联，以便在程序更改时，我们知道相关数据如何相应地更改。

就此我们发现，我们需要对数据进行全方位的管理，包括数据监控、数据质量检测、元数据管理、血缘关系管理、异常处理、版本控制。

这里涉及到监控预警的平台例如grafana、promethus等；

保证数据质量，数据治理是比不可少的，这里涉及元数据管理、血缘关系管理、数据标准管理等的数据治理平台例如Altas、Data Hub等，当然各企业也可以是自研的管理平台和工具。

就此，数据架构就会包含如下：

八、大数据安全

除此之外，数据的安全是必不可少的，仅包含用户访问权限、数据资源权限管理、审计等。目前市面上也有这样的框架，例如Apache Ranger、Sentry等

九、云基础架构

随着业务的发展，各种大数据应用程序或任务被添加到大数据系统中后，你会发现配置机器和设置生产部署的过程非常繁琐，并且有很多的坑要踩。这个时候可能就需要考虑一下云计算平台了。通过在统一框架中运行，利用云计算易于配置和部署，弹性扩展，资源隔离，高资源利用率，高弹性，自动恢复等优势，它们将大大降低复杂性并提高运行效率。例如云基础架构K8S。此时，大数据平台架构就变成了：

总结

本文仅仅是简明的串讲了从采集、存储、计算、应用、管理、运维等多方位的大数据平台架构中应该包含的模块和常见的技术框架，对于某些技术细节理解可能不太准确，欢迎大家讨论，及时纠正～