一、 文看懂大数据的技术生态

大数据时代这个词被提出已经10年有余，特别是最近几年风风火火的贵州贵阳。乘着时代的风口和国家的有力支撑，已被称之为“中国数谷”。大数据的力量如此巨大，难免让人好奇不已。那么到底什么是大数据呢？

大数据的概念、大数据技术、大数据平台，一条龙服务，尽在下文！！！

1 大数据

大数据(Big Data)本身是个很宽泛的概念，根据字面理解，可知是很大很大的数据。数据大到了极限，造成传统技术已经无法处理。

专业术语：大数据指的是传统数据处理应用软件，不足以处理（存储和计算）它们，大而复杂的数据集。可以理解为一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库，软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低。总而言之，大数据就是指数据很大，传统技术无法高效的处理该数据。

四大特征：大量，多样，高速，低价值密度。

(1) 大量：数据容量大。从TB级别，跃升到PB级别。 海量的数据，可谓是数据的海洋。

(2) 多样：数据类型的多样性，包括文本，图片，视频，音频。 相对于以往便于存储的以文本为主的结构化数据，非结构化数据越来越多，包括网络日志、音频、视频、图片、地理位置信息等。

传统技术的处理多类型的数据已经不堪重任，因此对于数据的处理能力提出了更高要求。

(3) 高速：指获得数据的速度以及处理数据的速度，数据的产生呈指数式爆炸式增长，处理数据要求的延时越来越低。

(4) 价值密度低：价值密度的高低与数据总量的大小成反比。以视频为例，一部1小时的视频，在连续不间断的监控中，会产生大量的数据，但是有用数据可能仅有一二秒。

价值密度低，就好比一整部电影，无数个镜头，然而仅有一两个镜头较为经典。

2 大数据核心技术

我们知道了大数据的特点之后，就要改变传统的数据处理模式。解决，海量数据的存储和计算问题，因此引进了新处理模式，大数据技术。大数据的概念比较抽象，而大数据技术栈的庞大程度将让你叹为观止。来吧，我们一起漂进大数据技术的海洋，从此一去不复返！！！

这些就是大数据生态圈的技术组件，可谓是眼花缭乱，应接不暇（好吧，其实是杂乱无章）。那么，大数据生态圈的技术组件(技术栈)，又是如何解决海量数据的存储和计算问题呢 ？

先放大数据技术生态圈的一个大致组件分布图，之后我们一步步的进行分解组合。

我们可以看到，已经把之前杂乱的大数据组件摆放的规规矩矩，有条有序的。

看着由杂乱无章到仅仅有条的大数据生态圈有点舒服。似乎有点像家里修建房屋一样，一层一层，往上拔高，逐渐精彩。那么我们接下来就一起把大数据生态圈这栋房子开始修建。

2.1 HDFS分布式文件系统

既然要把大数据生态圈这栋房子修建，那么我们首先要进行的就是打建地基。

地基不稳，地动山摇。HDFS分布式文件系统就好比我的地基。我们知道传统的文件系统是单机的，不能横跨不同的机器。HDFS分布式文件系统的设计本质上是为了大量的数据能横跨成百上千台机器。简而言之，把多台机器存储的数据，用一个软件进行统一管理，执行增删改查操作。

万事开头难，我们终于有了HDFS分布式文件系统作为房屋的地基，此刻我们的大数据生态圈房屋是这样的。

此刻，已经有了房屋的地基HDFS，也就是可以进行数据的存储。

吐一口气，算是解决了海量大数据的存储问题。那么既然有了数据，我就应该去解决海量大数据的计算问题。因此，开始了我们房屋的第一层修建。

2.2 MapReduce计算引擎

当把海量数据存储于HDFS分布式文件系统之后，就开始考虑怎么处理数据。

虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。在一台服务器读取TP级别的海量数据（比如整个东京热有史以来所有高清电影的大小甚至更大）。是需要消耗非常多的时间，比如微博要更新24小时热博，它必须在24小时之内处理完海量的数据，显然单机服务器的计算能力是无法完成的。

但是如果我们用很多台服务器，利用这些机器的资源进行分布式处理数据，那么就可以大大的提高执行效率，这就是MapReduce的功能，一种分布式并行处理框架。到此，我们第一层，计算引擎MapReduce算是正式修建完毕。此时，我们的大数据生态圈房屋是这样的。

2.3 Hive数据仓库

有了MapReduce分布式处理框架之后我们发现MapReduce的程序写起来很麻烦，对于不懂程序开发的人非常不友好。

希望简化这个过程，能有个更高层更抽象的语言层来描述算法和数据处理流程。就好比，虽然MapReduce这层房可以住，但是它并不好住，不是喜欢的风格。我们希望能在它基础上进行修改成我们喜欢的style。于是就有了Hive，开发人员只需要编写简单易上手的SQL语句，它就把SQL语言翻译成MapReduce程序，让计算引擎去执行，从而让你从繁琐的MapReduce程序中解脱出来，用更简单更直观的语言去写程序了。

我们的第二层，Hive数据仓库层算是正式修建完毕。此时，我们的大数据生态圈房屋是这样的。

2.4 快一点吧 Spark/Flink

其实大家都已经发现Hive后台使用MapReduce作为执行引擎，实在是有点慢。Spark/Flink应运而生，它是用来弥补基于MapReduce处理数据速度上的缺点，它的特点是把数据装载到内存中计算而不是去读硬盘。

Spark/Flink支持批处理和流处理，是非常先进的计算引擎。就好比，当我们修建好MapReduce和Hive层后，过了很多年，发现已经过时了。我们需要该基础上，保留原来风格的同时，进行翻修。于是得到了Spark/Flink。此时，我们的大数据生态圈楼房已经进化成了这样。

2.5 Oozie / Azkaban任务调度

在大数据生态圈楼房中，我们已经修建好了计算引擎层，这层每天都需要清洁阿姨定时打扫。于是我们联系了一个家政的阿姨进行每天处理计算引擎层的卫生。Oozie / Azkaban任务调度组件，就相当于家政阿姨，它需要根据我们设定的时间执行任务。Oozie / Azkaban任务调度组件只针对于离线批处理任务。

此时，你的大数据生态圈楼房继续升级

2.6 yarn资源管理器

yarn资源管理器，就好比我们修建大数据生态圈时候的房屋的楼层使用说明，哪一层是干嘛的，这些楼层的使用顺序都是规定安排好的，不然那么多层随便使用，会杂乱无章的，有了yarn我们就在大数据生态圈，互相尊重而有序的使用这些楼层。

简而言之，可以把yarn理解为，相当于一个分布式的操作系统平台，而mapreduce等运算程序则相当于运行于操作系统之上的应用程序，Yarn为这些程序提供运算所需的资源（内存、cpu）。我们的大数据生态圈楼房继续升级。

2.7 数据采集 Sqoop / Flume / DataX/Kafka

大数据生态圈楼房，所有的楼层和楼层使用顺序设计都已经完成后，我们此时差不多就已经完成了修建。是时候安排人员入住了。那么我们通过什么方式去邀请人来入住呢？

这里的人，就相当于数据，只有有了数据，整个大数据生态圈才有意义。

因此我们就有了Sqoop/Flume/DataX/Kafka。通过这些工具去采集数据到HDFS文件系统，进而处理数据。大数据生态圈楼，继续升级

此时，我们的大数据生态圈楼房，基本的建设可以说是完成。剩余的工作就是一些装饰和家具了。从以上所述，我们可以知道，大数据生态圈的技术栈多而杂乱，只有让它们有序的组合一起工作。才能解决海量数据的存储和计算。

3 从0到1搭建大数据平台

在我们很清晰明白了大数据生态圈的技术栈各个功能，以及技术栈组件的分布图之后。那么我们就可以进一步来设计属于自己的大数据平台！！！进一步对大数据平台架构深入认识。首先给出一个通用化的大数据处理框架，主要分为下面几个方面：数据采集与预处理、数据存储、数据清洗、数据查询分析和数据可视化。

数据采集：这是大数据处理的第一步，数据来源主要是两类，第一类是各个业务系统的关系数据库，通过Sqoop或者Cannal等工具进行定时抽取或者实时同步；第二类是各种埋点日志，通过Flume进行实时收集。

数据存储：收集到数据后，下一步便是将这些数据存储在HDFS中，实时日志流情况下则通过Kafka输出给后面的流式计算引擎。

数据处理：这一步是数据处理最核心的环节，包括离线处理和流处理两种方式，对应的计算引擎包括MapReduce、Spark、Flink等，处理完的结果会保存到已经提前设计好的数据仓库中，或者HBase、Redis、RDBMS等各种存储系统上。

数据应用：包括数据的可视化展现、业务决策、或者AI等各种数据应用场景。

通过上述的内容，我们看到了大数据技术组件的组合使用，形成了一个大数据平台。解决大量数据的存储和计算问题。

二、从0到1搭建大数据平台之开篇

1 架构总览

在之前的一期「一文看懂大数据的技术生态」中，我们对大数据的技术栈组件。充分了解之余，更多的是对如此庞大的生态圈叹为观止。不过，我想你一定不满足于此。在之前，我们已经把大数据生态圈这栋楼房已经完美竣工。我在给它买了家具和装饰之后，就完美变形成一个通用大数据平台。

看，这大数据平台框架，真高啊，总共有8楼(真是要费不少钱)。一层一层，往上拔高，逐渐精彩。每一层都功能各异，但是又互相依赖，兄弟姐妹关系，你中有我，我中有你。接下来，我们通过通用大数据平台框架进行数据流程设计。来吧，我带着你，一步一个脚印，向前迈进。

2 数据来源层

数据来源：这是最原始的一步，巧妇难为无米之炊，没有数据，又谈何处理。

我们已经知道了大数据的特点之一是数据种类多样性。具体而言，可以分为以下几种类型。

结构化数据：可以用二维数据库表来抽象，抽取数据规律。以数据库数据和文本数据为结构化数据。

半结构化数据：介于结构化和非结构化之间，主要指XML、HTML、JSON文档、Email等等，也可称非结构化。

非结构化数据：指信息没有一个预先定义好的数据模型或者没有以一个预先定义的方式来组织，不可用二维表抽象，比如图片，图像，音频，视频等 。

那么这种类型的数据又是从何处获取呢，我想这是大家心里想的第一个问题吧。

一般来说，数据来源主要是两类。

1、各个业务系统的关系数据库，可以称之为业务的交互数据。主要是在业务交互过程中产生的数据。比如，你去大保健要用支付宝付费，淘宝剁手购物等这些过程产生的相关数据。一般存储在DB中，包括Mysql，Oracle。

2、各种埋点日志，可以称之为埋点用户行为数据。主要是用户在使用产品过程中，与客户端进行交互过程产生的数据。比如，页面浏览、点击、停留、评论、点赞、收藏等。简而言之，夜深人静的时候，你躲在被子里，用快播神器看不知名的大片这些行为，都会产生数据被捕获。

既然小伙伴们，知道了数据来源，那么我们的数据流程设计第一步：

3 数据传输层

当我们知道了数据的种类，以及数据是如何而来的。那么，紧接着就是用大数据技术组件去获取数据，搞到数据。数据传输层也可称之为，数据采集。

目前业界较为主流的数据采集工具有Flume、Datax、Sqoop、Kafka、Camel等。又是一堆眼花缭乱的大数据采集组件，那么如何进行选型呢？带着疑问，我们接着往下走。

一般来说，采集数据是根据数据来源，来确定决定我们要使用的大数据采集组件。

1、针对各个业务系统的关系数据库(业务的交互数据)的采集，这类数据通常的存放在关系型数据库里，可以通过Sqoop或者Datax等大数据技术组件进行定时抽取。

2、针对各种埋点日志(埋点用户行为数据)的采集，这类数据通常是存放在日志服务器里，源源不断的增加，通过Flume进行实时收集到Kafka消息队列。

此时，我们的数据流程设计第二步。

第一条线：从Web浏览器/App业务交互产生的数据，通过java微服务对数据的规则化，解析，存入Db数据库，之后通过异构数据采集大数据组件Datax\Sqoop进行采集。

第二条线：从Web浏览器/App埋点数据，通过java微服务把数据收集到日志服务器里，之后通过Flume分布式日志收集组件进行初步采集，最后放置kafka消息队列。

4 数据存储层

在数据采集这里，我们知道了两条数据线的大致流程。那么通过大数据技术组件采集到的数据又是如何存储呢。别着急，待我细细道来。当我们收集到数据后，便是将这些数据进行存储。

第一条线，针对的是业务的交互数据，一般通过采集存储于分布式文件系统HDFS。属于离线数据。

第二条线，针对埋点用户行为数据，采集之后的存储分为两种情况。

1、离线：该日志数据通过Flume进行收集，先是放置在kafka消息队列，之后再次利用Flume存储于分布式文件系统HDFS。

2、实时 ：该日志数据通过Flume进行收集，先是放置在kafka消息队列，之后直接提供给流式计算引擎Spark/Flink进行处理，最后存储于Hbase。

此时，我们的数据流程设计如下所示：

5 资源管理层

资源管理：通过字面进行理解，就可以知道，该层是进行服务器资源管理的。

所谓的资源，即是服务器的CPU、内存等。我们在「一文看懂大数据的技术生态」中，知道大数据技术主要是解决海量数据的存储和计算。

在数据存储层已经解决了海量数据的存储，那么接着就要进行数据的处理计算。处理计算能力，是需要调用服务器的资源的。资源管理层中的yarn，就是管理和调度资源的大数据技术组件。

简言之，相当于一个分布式的操作系统平台，而Mapreduce等运算程序则相当于运行于操作系统之上的应用程序，yarn为这些程序提供运算所需的资源（内存、cpu）。

yarn好比大功率电池，给机器提供能量。

6 数据计算层

数据处理：这一步是数据处理最核心的环节。包括离线处理和流处理两种方式。对应的计算引擎包括MapReduce、Spark、Flink等。处理完的结果会保存到已经提前设计好的数据仓库中，或者HBase、Redis、RDBMS等各种存储系统上。

在这层中，我们终于解决了海量数据的存储计算。此时，我们的数据流程设计为

离线处理：当数据存储到HDFS后，利用Mapreduce/Hive/SparkSQL大数据技术组件，根据业务需求，对数据进行处理计算。

实时处理：当数据放置于Kafka消息队列时，利用Spark/Flink，根据业务指标需求，对数据进行实时计算。

7 任务调度层

任务调度：在离线处理阶段，我们会对数据进行定时处理。因此，任务调度的大数据组件Oozie / Azkaban/airflow 会服务于离线处理任务。满足我们定时调度的需求，通常离线处理任务的定时调度时间，大多数是设置到晚上凌晨进行执行。

我们小组一直在用的是airflow大数据定时调度组件，它的依赖能力是非常强的，社区人群也比较活跃，对python开发人员非常友好。

小伙伴们，这里我总结了三种调度神器的介绍，给大家一个简单的介绍。

8 多维分析层

多维数据分析是一种非常先进的数据分析理念。在这层，大数据计算组件kylin/presto/impala组件，提供即席查询功能。

所谓即席查询是指用户根据自己的需求，灵活的选择查询条件，系统根据用户的选择生成相应的统计报表。我们可以这么理解：即席查询就是一种快速的执行自定义SQL。此时，我们的数据流程设计继续升级。

9 应用层

应用：应用应用，有数据就应用。可以这么理解，该层是把经过离线和实时处理并且存入数据库里的数据进行使用。包括数据的可视化展现、业务决策、或者AI等各种数据应用场景。此时，我们的数据流程已经粗略的设计完成。

三、 从0到1搭建大数据平台之数据采集

1 大数据采集之预热

在之前「从 0 到 1 搭建大数据平台之开篇」，我们详细分析了大数据平台框架。

一步一个脚印向前迈进，一层到八层，贼高贼高。似乎有点恐高。

小伙伴们选择大数据平台，想必是传统的关系型数据库无法满足业务的存储计算要求，面临着海量数据的存储和计算问题。

那么要使用大数据平台的计算能力，首先要做的就是进行数据的集成。

简言之，把需要处理的数据导入大数据平台，利用大数据平台计算能力，对数据进行处理。

2 大数据采集之来源

「从 0 到 1 搭建大数据平台之开篇」中，我们知道了大数据的特性。

海量的数据： 大而复杂的数据集。

复杂的数据：数据类型的多样性，包括文本，图片，视频，音频。

高速的数据：数据的产生呈指数式爆炸式增长，要求处理数据的速度越来越高。数据种类大致分为结构化数据、半结构化数据、非结构化数据。

数据采集，就是根据海量数据的种类不同，选择合适的采集工具，实施数据集成到大数据平台的过程。一般而言，数据来源主要是两类。

1、各个业务系统的关系数据库，可以称之为业务的交互数据。主要是在业务交互过程中产生的数据。比如，你去大保健要用支付宝付费，淘宝剁手购物等这些过程产生的相关数据。一般存储在 DB 中，包括 Mysql，Oracle。

2、各种埋点日志，可以称之为埋点用户行为数据。主要是用户在使用产品过程中，与客户端进行交互过程产生的数据。比如，页面浏览、点击、停留、评论、点赞、收藏等。简而言之，夜深人静的时候，你躲在被子里，用快播神器看不知名的大片这些行为，都会产生数据被捕获。

其实，还有一种数据来源，就是爬虫爬取的数据。有很多外部数据，比如天气、IP 地址等数据，我们通常会爬取相应的网站数据存储。

总结：大数据采集的数据来自于日志、数据库、爬虫。

2.1 日志采集

2.1.1 浏览器页面日志

浏览器页面日志采集，主要分为两大类。

页面浏览(展现)日志采集： 页面浏览日志是指当 一个页面被浏览器加载呈现时采集的日志。此日志主要价值在于两大基本指标：页面浏览量(PV)和访客数(UV)的统计。

页面交互日志采集：也就是用户行为数据的采集，主要是用户在使用产品过程中，与客户端进行交互过程产生的数据。

2.1.2 无线客户端 App 日志采集

众所周知，日志来集多是为了进行后续的数据分析。

移动端的数据采集。

一是为了服务于开发者，协助开发者分析各类设备信息；

二是为了帮助各 APP 更好地了解自己的用户，了解用户在 APP 上的各类行为，帮助各应用不断进行优化，提升用户体验。

一般来说，App 日志采集采用采集 SDK 来完成。但是，它的采集又与浏览器日志的采集方式有所不同，移动端的日志采集 根据不同的用户行为分成不同的事件，“事件”为无线客户端日志行为 的最小单位。

2.2 多源异构数据的采集

业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据。

如 MySQL、Oracle、DB2, SQL Server 等：也有来源于非关系型 数据库的非结构化数据，如 HBase、 MongoDB 等，这类数据通常存储在数据库表中。

还有一类以文件的形式进行数据的存储，如：文件系统 FTP,阿里云对象存储等。针对这些不同源的数据进行采集，利用采集工具将数据源的数据读取出来，转换为中间状态，并在目标数据系统中将中间状态的数据转换为对应的数据格式后写入。

2.3 大数据采集之工具

上文已经说过，对于不同的数据来源，所选取的大数据采集组件是不同。

正所谓，好马配好鞍。面对，如此多的数据来源，我们如何选取大数据采集技术栈呢？

我们已经知道了大数据采集的数据来自于日志、数据库、爬虫。接下来，针对每种数据来源使用的工具进行讲解。

2.3.1 日志采集工具

目前广泛使用的日志收集工具有，Flume、Logstash、Filebeat、Fluentd。

我们知道了针对日志数据进行采集所使用的工具。那么这么几款日志收集工具，小伙伴一定会说。自己有选择困难症。要如何选取，也是一个问题。

Flume: Cloudera 提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，它支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume 提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。

Logstash: 一个开源数据收集引擎，具有实时管道功能。Logstash 可以动态地将来自不同数据源的数据统一起来，并将数据标准化到你所选择的目的地。

Filebeat: 一个轻量级的日志传输工具，监视指定的日志文件或位置，收集日志事件，并将它们转发到 Elasticsearch 或 Logstash 进行索引。

Fluentd: 一个针对日志的收集、处理、转发系统。通过丰富的插件系统，可以收集来自于各种系统或应用的日志，转化为用户指定的格式后，转发到用户所指定的日志存储系统之中。

大数据日志采集工具，有很多种，小伙伴们可以根据自己的业务需求，进行合适选择。

2.3.2 多源异构数据的采集工具

目前公司项目，离线数据的集成与同步，利用大数据采集技术栈进行多源异构数据的导入导出的使用比较多。

多源异构数据采集的大数据技术栈，目前广泛的是 Sqoop、Datax。

1、Sqoop: SQL–to–Hadoop。正如 Sqoop 的名字所示，主要用于在 Hadoop、Hive 与传统的数据库(MySql)间进行数据的传递，可以将一个关系型数据库中的数据导进到 Hadoop 的 HDFS 中，也可以将 HDFS 的数据导进到关系型数据库中。

其架构如下所示

Sqoop 工具接收到客户端的 shell 命令或者 Java api 命令后，通过 Sqoop 中的任务翻译器将命令转换为对应的 MapReduce 任务，而后将关系型数据库和 Hadoop 中的数据进行相互转移，进而完成数据的拷贝。

2、Datax：阿里巴巴开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle 等)、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能。

DataX 本身作为离线数据同步框架，采用 Framework + plugin 架构构建。将数据源读取和写入抽象成为 Reader/Writer 插件，纳入到整个同步框架中。

其架构如下所示：

DataX 在设计之初就将同步理念抽象成框架+插件的形式.框架负责内部的序列化传输，缓冲，并发，转换等而核心技术问题，数据的采集(Reader)和落地(Writer)完全交给插件执行。

Read 数据采集模块，负责采集数据源的数据，将数据发送至 FrameWork。

Writer 数据写入模块，负责不断的向 FrameWork 取数据，并将数据写入目的端。

FrameWork 用于连接 reader 和 write，作为两者的数据传输通道，处理缓冲，流控，并发，转换等核心技术问题。

以上为最常用的异构数据源采集工具，至于小伙伴们要选择哪个技术栈都是根据自己的业务需求的。

小结：Sqoop依赖于Hadoop生态对HDFS、Hive支持友善，在处理数仓大表的速度相对较快，但不具备统计和校验能力。

DataX无法分布式部署，可以在传输过程中进行过滤，并且可以统计传输数据的信息，因此在业务场景复杂(表结构变更)更适用，同时对于不同的数据源支持更好。且DataX的开源版本目前只支持单机部署，需要依赖调度系统实现多客户端，同时不支持自动创建表和分区。

2.3.3 外部数据之爬虫

简单的来说，网络爬虫就是自动从互联网中定向或不定向的采集信息的一种程序。

目前常用的爬虫工具是Scrapy，它是一个爬虫框架，提供给开发人员便利的爬虫API接口。开发人员只需要关心爬虫API接口的实现，不需要关心具体框架怎么爬取数据。Scrapy框架大大降低了开发人员开发速率，开发人员可以很快的完成一个爬虫系统的开发。

至此，我们就已经通过大数据采集技术栈把不同来源的海量数据采集至大数据平台。

四．从0到1搭建大数据平台之数据存储

1. 前言

我们都知道，采集数据之后，得到数据是原始的和杂乱的，必须经过专门的清洗、 关联、规范化和精心的组织建模，而且要通过数据质量检测后才能进行后续的数据分析或用于提供数据服务，而这就是数据平台构建的关键环节–>数据存储处理而我们今天要聊的是大数据平台是如何去存储海量数据呢？

在之前一期：从0到1搭建大数据平台之开篇

我们聊过，大数据的数据采集并存储的数据流程，如下图所示：

在整个大数据生态圈里，数据存储可以分为两大类：

1、是直接以文件形式存放在分布式文件系统上，处理工具可以直接读写 (Hive 和SparkSQL 都是这类)。

2、通过kafak存储实时数据，经过实时计算框架最后把指标数据利用NoSQL数据库来存储和管理数据(NOSQL数据库Hbase之类)。

2 数据存储的发展

2.1 传统数据存储

互联网时代各种存储框架层出不穷，眼花缭乱，比如传统的OLTP关系型数据库Oracle、MySQL。之前进行业务指标的统计分析都是基于传统的事务型数据库，传统的事务型数据库主要面对单一的业务系统，实现的是面向事务的增删改查。随着业务的不断发展，产生的海量数据，面对复杂的数据分析指标，单一的事务性数据库已经不能满足数据分析的场景。

最根本的原因在于：数据分析通常需要访问大量的数据，单条数据的分析没有任何意义。 它不仅需要访问大量的数据，还要对其进行频繁的统计和查询。

1、大量访问数据，这些请求占用了大量数据库的资源，严重到影 响生产系统的性能。

2、大量的数据访问通常需要全表扫描，频繁而且通常又是并发地全表扫描会造成事务型数据库响应异常缓慢甚至宕机。这促使数据仓库概念的出现。

2.2 数据仓库

在 1991 年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义，他认为：

数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

1、所谓主题：要把不同业务系统的数据同步到一个统一的数据仓库中，然后按照主题域方式组织数据。主题可以把它理解为数据仓库的一个目录。

2、所谓集成：是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。

3、所谓随时间变化：是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

简而言之，它综合多个业务系统数据，主要用于历史性、综合性和深层次数据分析。在了解数据仓库之后，不得不提下经典的两个数仓建模技术。

比尔·恩门（Bill Inmon）和 金博尔（Kimball）

恩门提出的建模方法自顶向下（这里的顶是指数据的来源，在传统数据仓库中，就是各个业务数据库），基于业务中各个实体以及实体之间的关系，构建数据仓库。

举个例子：

在一个最简单的买家购买商品的场景中，按照恩门建模的思维模式，首先你要理清这个业务过程中涉及哪些实体。买家、商品是一个实体，买家购买商品是一个关系。所以，模型设计应该有买家表，商品表，和买家商品交易表三个模型。

金博尔建模与恩门正好相反，是一种自底向上的模型设计方法，从数据分析的需求出发，拆分维度和事实。那么用户、商品就是维度，库存、用户账户余额是事实。

总结这两种数仓建模技术：

这两种方法各有优劣，恩门建模因为是从数据源开始构建，构建成本比较高，适用于应用场景比较固定的业务，比如金融领域，冗余数据少是它的优势。金博尔建模由于是从分析场景出发，适用于变化速度比较快的业务，比如互联网业务。由于现在的业务变化都比较快，所以我更推荐金博尔的建模设计方法。

2.3 数据湖

传统数据仓库，第一次明确了数据分析的应用场景应该用单独的解决方案去实现，不再依赖于业务的数据库。

在模型设计上，提出了数据仓库模型设计的方法论，为后来数据分析的大规模应用奠定了基础。

但是进入互联网时代后，最为重要的两个变化：

1、数据规模前所未有，传统的数据仓库难于扩展，根本无法承担如此规模的海量数据。 2、数据类型变得异构化，不仅有结构化数据，还有半结构化，非结构数据。而传统的数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。

因总总的限制，导致传统数据仓库无法支撑互联网时代的数据挖掘。随着大数据技术普及，数据湖概念被提出。

数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。

其构建组件基于Hadoop进行存储。简而言之，数据湖原始数据统一存放在HDFS系统上，引擎以Hadoop和Spark,Flink开源生态为主，存储和计算一体。

通俗总结：数据仓库和数据湖

数据仓库存储结构化数据(先处理后存储)。

数据湖存储原始数据(先存储后处理)。

这里可以用一个做菜的场景做一个类比。以前数据仓库的时候，好比把原材料都加工好了，比如土豆清洗，去皮，切片，这样炒土豆片的时候直接炒就可以了。数据湖的时候呢，直接把土豆存储进来，这样以后想炒土豆片就切片，想炒土豆丝就切丝。增加了灵活性的同时，省去了前期头都处理的费用。

3 批处理的数据存储

3.1 HDFS分布式文件系统

Hadoop Distributed File System，简称HDFS，是一个分布式文件系统。它是谷歌的Google File System ( GFS）提出之后， Doug Cutting 受Google 启发而开发的一种类GFS 文件系统。

它有一定高度的容错性，而且提供了高吞吐量的数据访问，非常适合大规模数据 集上的应用。

HDFS提供了一个高容错性和高吞吐量的海量数据存储解决方案。

在Hadoop 的整个架构中， HDFS在MapReduce 任务处理过程中提供了对文件操作和存储等的支持， MapReduce 在HDFS基础上实现了任务的分发、跟踪和执行等工作，并收集结果，两者相互作用，共同完成了Hadoop 分布式集群的主要任务。

HDFS分布式文件架构如下所示：

离线数据一般基于HDFS分布式文件系统作为数据仓库。

4 实时处理的数据存储

实时处理的数据为无界流数据，因此分为原数据存储和数据处理后的存储。

4.1 原数据存储

实时数据处理通常还会有从某历史时间点重启以及多个实时任务都要使用同一源头数据的需求，因此通常还会引人消息中间件Kafka来作为缓冲，从而达到实时数据采集和处理的适配。

Kafka是最初由Linkedin公司开发，是一个分布式、可分区、多副本，基于zookeeper协调的分布式消息系统。

场景：在实时数仓中，以 Kafka 为支撑，将所有需要实时处理的相关数据放到 Kafka队列中来实现贴源数据层(ODS)。

4.2 实时处理之后的数据存储

1、HBase的NOSQL数据库

HBase 是一种构建在HDFS 之上的分布式、面向列族的存储系统。 在需要实时读写并随机访问超大规模数据集等场景下， HBase 目前是市场上主流的技术选择。 HBase 技术来源于Google 论文《Bigtable ：一个结构化数据的分布式存储系统》。

如同Bigtable 利用了Google File System 提供的分布式数据存储方式一样， HBase 在HDFS 之上提供了类似于Bigtable 的能力。

HBase解决了传统数据库的单点性能极限。

实际上，传统的数据库解决方案，尤其是关系型数据库也可以通过复制和分区的方法来提高单点性能极限，但这些都是后知后觉的，安装和维护都非常复杂。 而HBase从另一个角度处理伸缩性问题， 即通过线性方式从下到上增加节点来进行扩展。

场景： 对于数据在线服务（即数据使用方传入某个业务ID，然后获取到所有此ID 的相关字段），通常放在HBase内。

2、关系型数据库

实时数据经过实时计算引擎Flink、Spark处理后，可以存储于Mysql或者Oracle等关系型数据库。

场景：对于实时数据大屏，通常放在某种关系数据库（如MySQL）内。

3、 缓存数据库

经过实时计算引擎Flink、Spark处理后的数据，同时也可以存储在Redis里，作为缓存数据。

场景：为了提高性能并减轻对底层数据库的压力，还会使用缓存数据库（如Redis）等。

五．从0到1搭建大数据平台之数据计算

之前有说过「从0到1搭建大数据平台之数据存储」，想必小伙伴还有印象。

既然大数据平台有了数据存储，那么针对数据的计算必不可少。

我们都知道大数据计算平台都是围绕着Hadoop生态圈发展的，以HDFS分布式文件系统作为数据存储。分离线批处理和实时处理两条路线走天下。

在讲解Hadoop的大数据计算之前，我们应该首先了解的是它为何而来。

下面由我带着大家，一步一步，逐渐精彩。

1 传统的数据计算

没有大数据之前，我们的业务数据计算平台基本是依赖于数据库。比如：微软的SQLServer，甲骨文的Oracle IBM的DB2等。也就是通常所说的OLTP数据库。

这类数据库主要用来进行事务处理，比如新增一个订单、修改一个订单、查询一个订单和作废一个订单等。其核心是高效对单条数据进行处理。

但是，随着互联网的迅速发展，业务数据已经呈现指数型的增长。面对如此海量的数据，传统的OLTP数据库，访问通常需要全表扫描，频繁而且通常又是并发地全表扫描会造成OLTP数据库响应异常缓慢甚至宕机。也许你会说：可以通过增加CPU，内存，磁盘等方式提高处理能力。

但是 这类集中式的数据库很难满足海量数据对计算能力的巨大需求，同时传统数据库架构对高端设备的依赖，无疑将直接导致系统成本的大幅度增加，甚至可能会导致系统被主机和硬件厂商所“绑架”，不得不持续增加投入成本。

因此必须有新的理论支撑和技术突破才能够满足这些海量数据分析请求。于是就有了Hadoop的闪亮登场。

2 Hadoop的崛起

随着互联网行业的发展，特别是移动互联网的快速发展。

短短几年发生了翻天覆地的变化：

一个是数据规模前所未有，一个成功的互联网产品日活可以过亿，就像你熟知的头条、抖音、快手、网易云音乐，每天产生几千亿的用户行为。传统数据库难于扩展，根本无法承载如此规模的海量数据。

另一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的。传统数据库对数据模型有严格的要求，在数据导入到数据库前，数据模型就必须事先定义好，数据必须按照模型设计存储。

紧接着经典的三大论文的出现，提出了一种新的，面向数据分析的海量异构数据的统一计算、存储的方法。

在2005年，Hadoop应运而生，大数据技术开始普及。相较于传统的数据库主要有两个优势：

1 完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；

2 弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数据存储分离，数据在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。

因此，越来越多的企业选择基于Hadoop来存储计算海量数据。以下计算组件更为详细的原理在之后细说，先知其表，后知其里。

3 离线计算

离线数据处理，数据计算频率主要以天（包含小时、周和月）为单位。

例如：按天进行数据处理，每天凌晨等数据采集和同步的数据到位后，相关的数据处理任务会被按照预先设计的ETL （抽取、转换、加载，一般用来泛指数据清洗、关联、规范化等数据处理过程〉逻辑以及ETL任务之间的拓扑关系依次调用，最终的数据会写入离线数据仓库中。

在这个数据计算过程中最频繁使用的是Hadoop生态圈的MapReduc和Hive。

3.1 MapReduce

MapReduce 是Google 公司的核心计算模型，它将运行于大规模集群上的复杂并行计算过程高度抽象为两个函数： map 和reduce。

其核心思想：分而治之，先分后和：将一个大的、复杂的工作或任务，拆分成多个小的任务，并行处理，最终进行合并。

map: 将数据进行拆分，即把复杂的任务分解为若干个“简单的任务”来并行处理。可以进行拆分的前提是这些小任务可以并行计算，彼此间几乎没有依赖关系。

reduce: 对数据进行汇总,即对map阶段的结果进行全局汇总。

3.2 Hive

Hive：它是由 Facebook 开源用于解决海量结构化日志的数据统计。它是基于大数据生态圈 hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张表，并提供类 SQL 查询功能。

其本质是将 HQL 转化成 MapReduce 程序。

从图示可以看出，Hive 从某种程度上讲就是很多“SQL—MapReduce”框架的一个封装，可以将用户编写的 Sql 语言解析成对应的 MapReduce 程序，最终通过 MapReduce 运算框架形成运算结果提交给 Client。

3.3 SparkSQL

尽管MapReduce 和Hive 能完成海量数据的大多数批处理工作，并且在大数据时代成为企业大数据处理的首选技术，但是其数据查询的延迟一直被诣病，而且也非常不适合选代计算和DAG （有向无环图）计算。

因此，我们需要更为强大的强大的计算引擎。

于是Spark也登上了舞台，它有可伸缩、基于内存计算等特点，且可以直接读写Hadoop上任何格式的数据，较好地满足了数据即时查询和迭代分析的需求，因此变得越来越流行。

同时基于内存的Spark计算速度大约是基于磁盘的HadoopMapReduce的100倍。

也许会说，还有Presto,kylin等。但是这些组件一般用于即席查询，就是针对一个业务想快速测试的统计分析指标，其指标没有经过需求分析讨论的。而Mapreduce、Hive这些用于经过讨论确定的业务指标计算流程。

4实时计算

实时计算对时效性的要求非常高，是相对于离线计算而言。计算频率达到秒级别。每来一条数据，就立马进行处理。

4.1 Spark Streaming

SparkStreaming是一套框架，是Spark核心API的一个扩展，可以实现高吞吐量的，具备容错机制的实时流数据处理。

其原理是将实时流数据分成小的时间片断（秒或者几百毫秒），以类似Spark 离线批处理的方式来处理这小部分数据。

4.2 Flink

在数据处理领域，批处理任务与实时流计算任务一般被认为是两种不同的任务。一个数据项目一般会被设计为只能处理其中一种任务，例如Spark Streaming只支持流处理任务，而Map Reduce、 Hive 只支持批处理任务。 那么两者能够统一用一种技术框架来完成吗？

批处理是流处理的特例吗？

带着这两个疑问，是时候登场—>Flink。

Flink 是一个同时面向分布式实时流处理和批量数据处理的开源计算平台够，其基于同一个Flink 运行时（Flink Runtime），提供支持流处理和批处理两种类型应用的功能。

Flink在实现流处理和批处理时，与传统的一些方案完全不同，它从另一个视角看待流处理和批处理，将二者统一起来。

Flink完全支持流处理，批处理被作为一种特殊的流处理，只是它的输入数据流被定义为有界的而已。

基于同一个Flink 运行时， Flink 分别提供了流处理和批处理API，而这两种API 也是实现上层面向流处理、批处理类型应用框架的基础。

总结

离线处理和批处理是大数据计算中，非常必要的两条腿。也是大数据平台的核心所在。因此，学好大数据计算组件的重要性不言而喻。

由于工作原因，一直在接触flink的流批一体计算建设，所以我在自己的大数据平台研发中，思考过是否用flink来完成流批一体的数据开发模块。

六 从0到1搭建大数据平台之调度系统

大数据平台核心之一在于数据计算，分为离线计算和实时计算任务。

然而任务是离不开调度的。比如：我们要进行定时抽取业务数据库 的数据，定时跑hive/spark任务，定时推送日报、月报指标数据等。因而调度系统是大数据平台不可或缺的，正如闹钟对于日常生活的重要性一样。

首先上一个通用型的大数据平台框架：

由此而见，无论是离线任务或者实时任务，都是需要工作流的调度系统。

1原始任务调度

传统的crontab是linux系统自带的调度工具，使用crontab可以在指定的时间执行一个shell脚本或者一系列Linux命令。

实例：

实例 1：每 1 分钟执行一次 command

命令：

*/1 * * * * command

可见，crontab的使用是非常方便的，配置也极其简单。但是在任务量较少的时候，是非常nice。然而随着任务越来越多，就会出现了

1 任务不能在原来计划的时间完成，出现了上级任务跑完前，后面依赖的任务已经起来了，这时候没有数据，任务就会报错，或者两个任务并行跑了，出现了 错误的结果。

2 排查任务错误原因越来麻烦，各种任务的依赖关系越来越复杂，最后排查任务问题就行从一团乱麻中，一根一根梳理出每天麻绳。

3 成千上万的任务，管理起来是非常麻烦的，无穷无尽的痛苦。

总而言之，crontab虽然配置简单易上手，但是随着任务越来越多，任务之间的依赖越来越复杂，那么它是无法满足我们的需求，去解决任务之间的复杂依赖。

2 调度系统

调度系统，关注的首要重点是在正确的时间点启动正确的作业，确保作业按照正确的依赖关系及时准确的执行。资源的利用率通常不是第一关注要点，业务流程的正确性才是最重要的。（但是到随着业务的发展，ETL任务越来越多，你会发现经常有任务因为资源问题没有按时启动！）

实际调度中，多个任务单元之间往往有着强依赖关系，上游任务执行并成功，下游任务才可以执行。

比如 上游任务1结束后拿到结果，下游任务2、任务3需结合任务1的结果才能执行，因此下游任务的开始一定是在上游任务成功运行拿到结果之后才可以开始。

而为了保证数据处理结果的准确性，就必须要求这些任务按照上下游依赖关系有序、高效的执行，最终确保能按时正常生成业务指标。

那么在大数据平台中，调度系统的应用场景又是什么呢？

比如：在离线场景中，需要每天0点后，依次要执行数据采集、数据清洗、数据计算按照顺序依次执行。

• job1首先进行数据采集任务。
• job2则等待job1执行完成之后，则开始执行。
• job3、job4、job5指标计算，需要job2执行完，则开始执行。
• 因此大数据中，可以把调度系统的作用说明为：定时调度和依赖调度。

3 大数据工作流调度框架

• Apache Oozie
• Azkaban
• Airflow
• DolphinScheduler

（1）Oozie

Oozie是一个用来管理Hadoop生态圈job的工作流调度系统。由Cloudera公司贡献给Apache。

Oozie是运行于Java servlet容器上的一个java web应用。

目的：是按照DAG(有向无环图)调度一系列的Map/Reduce或者Hive等任务。

应用场景：Hadoop 自带的开源调度系统，使用方式比较复杂，适合大型项目场景，但是它使用XML配置，oozie任务的资源文什都必颈放在HDFS文什系统上，配置不方便，同时也只用于Hadoop。

（2）Azkaban

Azkaban是由Linkedin开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。

应用场景：一个开源调度系统，使用方式比较简单，适合中小型项目场景，但是它使用java properties文件维护任务依赖关系，任务资源文件需要打包成zip,azkaban部署不是很方便。

（3） Airflow

Airf1ow是一款开源的，分布式任务调度框架，它将一个具有上下级依赖关系的工作流，组装成一个有向无环图。

利用Python的可移植性和通用性，快速的构建的任务流调度平台，实现依赖调度、定时调度。

它具有自己的web任务管理界面，dag任务创建通过python代码，可以保证其灵活airflow性和适应性。

（4） Apache DolphinScheduler

Apache DolphinScheduler是一个分布式、去中心化、易扩展的可视化DG工作流任务调度系统，其致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。

它很好与Spark和Flink整合集成，进行离线批处理任务和实时流计算调度与监控预警。

4 调度框架比较

给小伙伴们总结下这几个调度框架：

总体而言，海豚调度DolphinScheduler， 算是后起之秀。它因为出来得晚，自然就会集成了以往调度框架的优点，万千优点于一身。但是，不管如和去选择自己的调度框架，都是根据需求去综合分析的，比如我而言，对Airflow比较熟悉，所以项目中习惯用它。

七 从0到1搭建大数据平台之监控系统

大数据平台设计中，监控系统尤为重要。它时刻关乎大数据开发人员的幸福感。试想如果半夜三更，被电话吵醒解决集群故障问题，那是多么的痛苦！！！

但是不加班是不可能的，因此就要避免无效的集群报警对我们造成影响，完善我们的监控预警系统，经过精细化监控指标项、对异常进行自动化处理、告警收敛等一系列操作，相信你也可以睡一个安稳觉。

1 监控系统

小伙伴们都知道，搭建一个大数据平台不是目的，稳定的使用才是核心。大数据平台的日志和监控可以说是数据开发人员的两只眼睛。然而大数据平台涉及的组件比较多，因此一个统一的集群和平台监控必不可少。一般而言，我们主要以：监控粒度、监控指标完整性、监控实时性作为评价监控系统是否优秀的三要素。我们将监控系统分为三层：

• 系统层

顾名思义，系统层主要监控我们大数据平台所依赖的服务器。

通过对服务器的监控，可以实时的掌握服务器的工作状态、内存消耗、健康状态等，以保证服务器的稳定运行。

监控指标： 内存、磁盘、CPU、网络流量、系统进程等系统级别指标。

• 应用层

应用层的监控可以理解为，对部署在服务器上的各种应用进行监控。包括但是不限于Hadoop集群、调度服务和大数据平台应用等等。

比如说，Hadoop集群的某个节点出现了故障，我们能够快速定位，并处理该问题。

对应用的整体运行状况进行了解、把控，确保服务的状态正常，服务的运行性能正常。

监控指标： JVM堆内存、GC、CPU使用率、线程数、吞吐量等。

• 业务层

业务层算是最贴近系统用户的，同时可以反馈系统及应用层的问题。业务系统本质目的是为了达成业务目标，因此监控业务系统是否正常最有效的方式是从数据上监控业务目标是否达成。对业务数据进行监控，可以快速发现程序的bug或业务逻辑设计缺陷。

比如说，我们会监控调度服务的执行情况、Datax数据集成的抽取情况等等。

2 常用大数据平台开源监控组件

常用的开源监控组件比较多，这里以比较常用的三种。

Zabbix

基于Web界面提供分布式系统监视及网络监视功能的企业级开源解决方案。

它易于入门，能实现基础的监控，但是深层次需求需要非常熟悉Zabbix并进行大量的二次定制开发，难度较大；此外，系统级别报警设置相对比较多，如果不筛选的话报警邮件会很多；并且自定义的项目报警需要自己设置，过程比较繁琐。

OpenFalcon

小米开源的面向互联网企业的监控产品。它是一款企业级、高可用、可扩展的开源监控解决方案，提供实时报警、数据监控等功能。可以非常容易的监控整个服务器的状态，比如磁盘空间，端口存活，网络流量等。

Prometheus

它是一套开源的监控、报警和时间序列数据库组合。也是最近比较流行的开源监控工具~深受广大小伙伴的喜欢。作为新一代的云原生监控系统，其最大的优点在于：

易管理性	Prometheus核心部分只有一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储
高效性	单一Prometheus可以处理数以百万的监控指标；每秒处理数十万的数据点
易于伸缩性	可以对Prometheus进行扩展，形成一个逻辑集群
丰富的看板	多种可视化图表及仪表盘支持
针对容器监控	对docker,k8S监控有成熟解决方案

总而言之， 以上三种是现在较为流行的监控工具，在这里我进一步对他们进行方案对比：

	Zabbix	OpenFalcon	Prometheus
可扩展性	可扩展能力强	可扩展能力强	可扩展能力强
监控数据采集	推送、拉取	推送、拉取	推送、拉取
监控数据存储	mysql/psql	归档RRD,存储mysql+redis+opentsdb	自带时序数据库存储方案, 类似于OpenTSDB
自定义指标	c++/python	go/python/shell	go/python/shell
告警功能	支持	支持	支持
使用场景	大中型企业、私有云	大中型企业、私有云	大中型企业、私有云

3 大数据平台监控体系构建

3.1 概况

研发的大数据平台，修改了前端登陆界面，对于一个大数据开发人来说，前端的学习真的非常痛苦，感觉好难。

不过也是逐渐上手了。

其监控体系是基于基于开源：xxx_exporter+promethues+grafana的构建监控系统，方案如下：

其中

exporter

一般是使用来采集各种组件运行时的指标数据。

promethues

构建指标时序数据库。

grafana

构建指标显示面板。

目前已有各种docker容器方便的构建各种监控体系

3.2 构建过程

详细的xxx_exporter+promethues+grafana搭建过程，直接参考百度，较为详细。针对于大数据组件繁多，因此对于监控json的配置也需要一一对应。

(也可以私聊我)

构建之后的效果

以grafana指标展示界面，嵌入大数据平台里作为监控系统。

效果图主要是在grafana里对每个组件进行编辑，小伙伴们可以自行设计想要的效果。

八 从0到1搭建大数据平台之数据可视化

在当今信息爆炸的时代，企业积累了大量的数据资源，如何从这些海量数据中提取有价值的信息，并以直观易懂的方式呈现给决策者和业务人员成为了一个挑战。因此，越来越多的企业开始构建数据中台，并运用开源技术来实现强大且灵活的可视化分析。本文将介绍数据中台可视化及其所使用的开源技术。

大数据平台的可视化技术是指通过图表、仪表盘等形式将数据呈现给用户，帮助他们更好地理解和分析数据。在数据中台建设过程中，可视化技术起着至关重要的作用，它可以提供直观、易于理解的数据展示方式，帮助用户快速获取信息并做出决策。

1、数据中台可视化技术

（1）数据报表：利用报表工具和技术，将数据以表格形式展示出来。报表可以包含各种指标和维度，并支持排序、筛选、汇总等功能。通过灵活的设置，用户可以自定义展示所需的数据内容，并进行交互式操作。

（2）仪表盘：仪表盘是一种集成多个关键指标和图表的实时监控工具。它通常以图形化界面呈现，可以根据用户需求自定义显示内容，并提供实时更新和交互功能。仪表盘能够直观地展示企业关键业务指标的趋势和状态，使用户能够及时发现问题并采取相应措施。

（3）地理信息系统（GIS）：GIS结合地理位置和空间分析技术，在地图上展示与位置相关的数据。通过地图覆盖区域、标记点位、区域热力图等方式，可以直观地展示数据在空间上的分布和关联。GIS可用于各种领域，如物流分析、市场覆盖评估等。

（4）可视化大屏：可视化大屏是将数据以图表或仪表盘的形式展示在大型显示设备上。它通常被用于监控中心、会议室、指挥调度中心等环境，可以实时展示重要业务指标和运营状态，并支持交互操作和预警功能。

（5）自助式报告与查询工具：为用户提供自主生成报告和查询数据的工具。用户可以根据需要选择指标、维度和时间范围来生成报告，并进行灵活的筛选和排序。这样，用户不再依赖开发人员来获取特定的数据报告，能够更加高效地进行自主分析。

下面是对这几种可视化技术进行比较的一些要点：

技术	描述	适用场景
报表	以表格形式呈现数据，提供详细而全面的信息	需要展示结构化、静态数据，以及需要导出和打印功能的场景
数据可视化	将数据转化为图表、图形等可视元素，通过编码手段传达信息	需要直观地展示大量数据，并帮助用户发现模式和关联的场景
仪表盘	在一个界面上集成多个指标和图表，显示关键业务指标的状态和趋势	需要实时更新数据并快速了解整体业务情况的监控与分析场景
地理信息系统	结合地图和空间数据，支持在地图上分析、查询和比较空间数据	需要对地理位置进行分析和展示的领域，如物流、房地产等

总结来说，在选择使用哪种技术时需要考虑到需求类型、数据特征以及用户交互需求。报表适合展示结构化且静态的信息；数据可视化能够直观而灵活地呈现大量数据；仪表盘提供综合分析与监控；GIS则适用于地理位置相关的业务场景。

2、开源技术

可视化用到的开源技术 在构建数据中台可视化方案时，常使用以下几种开源技术：

• Apache Superset: 一个功能强大且易于使用的BI工具，它支持多种数据库连接，并提供了交互式图表和仪表板设计。
• Apache ECharts: 一个基于JavaScript的开源可视化库，提供了丰富的图表类型和交互功能，适用于在Web应用中展示数据。
• Tableau Public: 一个免费使用的可视化工具，它可以将数据直接导入并创建各种交互式报表和仪表板。
• D3.js: 一个强大而灵活的JavaScript图形库，可以根据自己的需求定制各种复杂的可视化效果。
• Grafana: 一个专注于时序数据分析和监控展示的开源工具，它支持多种数据源，并提供了丰富的仪表盘设计能力。
• dataease：一个开源的可视化工具，帮助用户快速分析数据并洞察业务趋势，从而实现业务的改进与优化。DataEase 支持丰富的数据源连接，能够通过拖拉拽方式快速制作图表，并可以方便地与他人分享。（比较火）

数据平台可视化实践案例 以下是一些企业在构建数据中台可视化方面取得成功的实践案例：

• 网易有数：网易旗下大数据分析平台，通过集成Superset、ECharts等技术，在用户数量上亿级别、日请求量上千万级别情况下实现了高性能、高稳定性及个性化定制等要求。
• Dropbox：利用Tableau Public构建了一套针对内部团队和外部合作伙伴共享文件和信息安全管理系统，并以直观方式呈现给用户。

3、民间可视化

这里的民间可视化，其实就是我们研发大数据平台时候，对数据价值的展现，基本是和前端有很大的关系。

一个优秀的前端工程，对数据的展现是非常炫酷的。

当我们的海量数据经过计算框架进行处理之后，就会把结果数据存储于数据库里，数据可视化的展现都是基于该结果数据库（如：mysql，oracle，redis，hbase）进行数据提供给前端展示。

提供一个非常全：超炫150套❤vue+Echarts❤ 大屏可视化数据平台实战项目分享 (附源码)

4、总结

随着企业对数据洞察力和决策支持的需求不断增加，数据中台可视化成为了推动企业数字化转型的关键工具之一。开源技术提供了丰富多样的选择，使得构建强大且灵活的可视化分析变得更加容易。然而，在实践过程中仍需根据企业特点和需求进行合适的选择与定制。未来，随着人工智能、大数据等新技术的发展，数据中台可视化将进一步提升用户体验和决策效能。