这是一个创建于 3436 天前的主题，其中的信息可能已经有所发展或是发生改变。
应用性能管理的本质就是通过对业务数据和 IT 系统性能数据的准确抓取和深度分析，为企业业务和 IT 的可持续发展提供平台支撑。而云智慧透视宝产品在得到越来越多客户认可的同时，业务数据也在急剧增加，无论是数据存储还是数据查询，都会给原有透视宝架构带来较大压力。
经过反复挑选，云智慧透视宝选择了用于大数据实时查询和分析的高容错、高性能开源分布式系统 Druid ，接下来就由透视宝开发工程师 lucky 为我们详细解读，云智慧是如何利用 Druid 实现数据聚合的。
大数据的挑战---
由于数据量的激增，云智慧透视宝后端数据处理系统主要面临两方面问题：
首先，在数据存储方面，因为系统需要保存所有原始数据，每天十几 TB ，甚至几十 TB 的数据量，直接导致了资源需求和运营成本的增加；
其次，在数据查询方面，如果查询是建立在所有原始数据集的基础上，那么对机器的 cpu 和内存要求就会非常高。
那么 Druid 会帮我们解决这些问题吗？！答案是肯定的，使用 Druid 对原始数据进行聚合，会显著的减少数据的存储，同时借鉴搜索架构的思想， Druid 创建不变的数据快照，为分析查询提供极优的数据结构来存储，这样会明显提高查询效率。
Druid 基本概念---
Druid 是一个为大型冷数据集上实时探索查询而设计的开源数据分析和存储系统，提供低延时(实时)的数据接入，灵活的数据探索以及高速的数据聚合(存储和查询)。
保存到 Druid 的数据由三部分组成：
Timestamp 列：数据的时间戳列，所有的查询都是以时间为中心。
Dimension 列：数据的维度列，用于过滤数据。
Metric 列：数据的聚合列，用于聚合数据，支持包括 sum ， count ， min 和 max 等计算。
接下来为大家介绍 Druid 的几个基本概念：
聚合：数据按照时间戳列、维度列、聚合列和聚合粒度进行归并的过程，称之为聚合。
聚合粒度：接收到多长时间的数据归并为一条，称之为聚合粒度。
Datasource ：数据源，相当于关系型数据库里面表的概念。
Segment ： Druid 用 Segment 文件保存数据， Segment 包含着某个 Datasource 一段时间内的数据。
Datasource 和 Segment 之间的关系： Segment=Datasource_interval_version_partitionNumber 。
从这个关系中不难发现 segment 也可以分区(partitonNumber)，就像 kafka 的 topic 一样。其实 segment 不仅可以分区，并且与 kafka 的 topic 一样，也有副本的概念。
下面结合透视宝的业务场景举个例子，消化一下上面的概念：我们在 Druid 上创建了一个叫做 cpu 的 datasource ，他的维度列是 account_id(用户唯一标识)和 host_id （主机唯一标识），聚合列是 cpuUser,cpuSys,cpuIdle 和 cpuWait ，聚合计算包括 sum 和 count,聚合粒度是 30 分钟。
按照如上的方式对 cpu 数据进行聚合后，每 30 分钟一组 account_id 和 host_id 只会对应一条数据，这条数据记录了我们每个聚合列的 sum 值和 count 值。这样，当我们在查询主机数-最近 1 天(7 天)的 cpu 数据时，可以在这个聚合结果的基础上再次进行聚合查询。元数据数据量大大减小了，查询效率是不是就提高了！
Druid 工作流程---
一个 Druid 集群有各种类型的节点（ Node ）组成，每种节点都被设计来做某组事情，这样的设计可以隔离关注并简化整个系统的复杂度。 Druid 包含如下节点： overlord 节点， middlemanager 节点， broker 节点， historical 节点和 coordinator 节点，在设计时充分考虑到了高可用性，各种节点挂掉都不会使 Druid 停止工作。
下面简单介绍下 Druid 不同节点的作用：
overlord 节点：接收和分发任务。上面说到了在 Druid 上创建了一个叫做 cpu 的 datasource ，其实暂时可以理解为创建了一个任务，目的是告诉 overlord 节点这个 datasource/任务处理的数据描述（模板）是什么，描述包括数据的维度列，聚合列，聚合粒度， segment 生成时间等等参数，任务会按照这个描述对接收到的数据进行聚合。 overlord 节点接到任务后并不会直接处理任务，而是分发给 middlemaanger 节点。
middlemanager 节点：管理任务。 middlemanager 接收到 overlord 分发给他的任务，会继续分发任务，分发给谁呢？分发给 peon ，这才是真正做聚合任务的同志。
从这张图可以看出 overlord 是如何分发任务给 middlemanager 的，通过 zookeeper （下面会提到， druid 的依赖，一些分布式服务都会依赖它， kafka ， hbase 等等）。 peon 完成数据聚合任务后，会生成一个 segment 文件，并且会将 segment 文件永久保存到 deepstorage ， deepstroage 也是 Druid 的一个依赖， Druid 依赖 deepstorage 对 segment 做永久存储，常用的 deepstorage 有 s3 和 hdfs 。
broker 节点：响应外部的查询请求。 broker 节点会根据请求参数（时间段参数等），决定从哪里获取数据。
historical 节点：存储历史数据。 broker 节点响应外部的查询请求，会从某个或者某些 historical 节点查询数据(如果没有，从 deepstorage 加载）。
coordinator 节点：管理集群中的 Segment 操作(下载，删除等)。
每个节点都提供了很多 api ，可以通过 api 查看各个节点的状态信息等，例如查看 overlord 节点的状态信息，如下图：
另外，还可以通过 overlord 节点提供的 web 页面查看任务的状态，以及 middlemanager 的数量，
和每个 middlemanager 可以容纳的 peon 数量等等。
下面是官方提供的 Druid 工作流程图：
这个流程图中没有画出 overlord 和 middlemaanger 节点，图中的 realtime 节点我们暂时没有用到，云智慧用的是 tranquility （ a high level data producer library for Druid ）。通过我们自己的程序，对数据进行清洗后，借助 tranquility 发送数据给 overlord ，看图：
上面对 Druid 节点做了一下大概的介绍，要想让 Druid 正常工作，除了运行 Druid 自身的这些节点外，还需要借助三个依赖。
deepstorage ：用来永久存储 segment 数据，一般是 s3 和 hdfs 。
zookeeper ：用来管理集群状态，保证集群内的数据统一。
metadata storage ：用来保存一些元数据，规则数据，配置数据等。
deepstorage 功能很单一不用多说，那么 zookeeper 和 metadata storage 在 Druid 工作流程中，起着什么样的作用呢？以聚合数据和查询数据简单介绍一下 zookeeper 和 metadata storage 在 Druid 中的工作。
聚合数据： peon 在做聚合任务的时候会周期性的告诉 zookeeper ，正在为哪个 datasource ，生成哪个时间段的数据，即生成哪个 segment ，当聚合任务执行完成后， peon 会将 segment 生成到 deepstroage ，同时会将生成的 segment 的描述信息保存到 metadata storage 中，并同时通知 zookeeper 。这
查询数据： broker 接收数据的查询请求后，会根据请求参数，通过 zookeeper 分析请求的 segment 在哪里：是在 peon 上(middlemaanger 中还没有完全生成一个 segment ，即热数据 /实时数据)，还是在某个或者某些历史节点中，分析出结果后分别向对应节点发出请求，获取数据。 broker 获取各个节点返回过来的数据，再次进行数据归并并最终返回给请求者。
metadata database 的作用又是什么呢？ peon 完成数据聚合后，首先将其保存到 deepstorage 中，同时会将聚合的产物 segment 描述信息(在 hdfs 中的保存路径)保存到 metadata database 中，并通知 zookeeper 。注意： Coordinator 和 historical 节点一直和 zookeeper 保持着连接， Coordinator 还和 metadata database 保持着连接。当 Coordinator 发现 zookeeper 上有一个新的 segment 生成后，会通知 historical 节点去加载这个数据，通知方式依然是借助 zookeeper 。
前文说到 Coordinator 节点管理 segment 的下载和删除，是发生在聚合数据的过程中， peon 完成数据聚合后会通知 zookeeper ，而 Coordinator 一直监控着 zookeeper ，当发现有一个新的 segment 生成后，会通过 zookeeerp 通知某个 historical 节点去下载 segment 。而删除是因为 Historical 节点容量是一定的（可配置的），如果超过了容量，他会删除过期数据或旧数据。
Druid 官方提供的流程图如下：
Druid 在透视宝的作用---
Druid 是如何从透视宝接入数据的呢？如下图所示：
目前，我们有两个服务，一个服务是连接 kafka 和 Druid ，即从 kafka 消费数据发送给 Druid 。一个是连接 broker ，并对外提供 api ，供前端查询数据做报表展示。通过使用 Druid ，大大节省了透视宝的数据存储的空间，提升了数据查询的效率，更好的满足客户大数据分析的需求。今天的分享也到此结束，希望能给你的工作带来一点帮助。
经过反复挑选，云智慧透视宝选择了用于大数据实时查询和分析的高容错、高性能开源分布式系统 Druid ，接下来就由透视宝开发工程师 lucky 为我们详细解读，云智慧是如何利用 Druid 实现数据聚合的。
大数据的挑战---
由于数据量的激增，云智慧透视宝后端数据处理系统主要面临两方面问题：
首先，在数据存储方面，因为系统需要保存所有原始数据，每天十几 TB ，甚至几十 TB 的数据量，直接导致了资源需求和运营成本的增加；
其次，在数据查询方面，如果查询是建立在所有原始数据集的基础上，那么对机器的 cpu 和内存要求就会非常高。
那么 Druid 会帮我们解决这些问题吗？！答案是肯定的，使用 Druid 对原始数据进行聚合，会显著的减少数据的存储，同时借鉴搜索架构的思想， Druid 创建不变的数据快照，为分析查询提供极优的数据结构来存储，这样会明显提高查询效率。
Druid 基本概念---
Druid 是一个为大型冷数据集上实时探索查询而设计的开源数据分析和存储系统，提供低延时(实时)的数据接入，灵活的数据探索以及高速的数据聚合(存储和查询)。
保存到 Druid 的数据由三部分组成：
Timestamp 列：数据的时间戳列，所有的查询都是以时间为中心。
Dimension 列：数据的维度列，用于过滤数据。
Metric 列：数据的聚合列，用于聚合数据，支持包括 sum ， count ， min 和 max 等计算。
接下来为大家介绍 Druid 的几个基本概念：
聚合：数据按照时间戳列、维度列、聚合列和聚合粒度进行归并的过程，称之为聚合。
聚合粒度：接收到多长时间的数据归并为一条，称之为聚合粒度。
Datasource ：数据源，相当于关系型数据库里面表的概念。
Segment ： Druid 用 Segment 文件保存数据， Segment 包含着某个 Datasource 一段时间内的数据。
Datasource 和 Segment 之间的关系： Segment=Datasource_interval_version_partitionNumber 。
从这个关系中不难发现 segment 也可以分区(partitonNumber)，就像 kafka 的 topic 一样。其实 segment 不仅可以分区，并且与 kafka 的 topic 一样，也有副本的概念。
下面结合透视宝的业务场景举个例子，消化一下上面的概念：我们在 Druid 上创建了一个叫做 cpu 的 datasource ，他的维度列是 account_id(用户唯一标识)和 host_id （主机唯一标识），聚合列是 cpuUser,cpuSys,cpuIdle 和 cpuWait ，聚合计算包括 sum 和 count,聚合粒度是 30 分钟。
按照如上的方式对 cpu 数据进行聚合后，每 30 分钟一组 account_id 和 host_id 只会对应一条数据，这条数据记录了我们每个聚合列的 sum 值和 count 值。这样，当我们在查询主机数-最近 1 天(7 天)的 cpu 数据时，可以在这个聚合结果的基础上再次进行聚合查询。元数据数据量大大减小了，查询效率是不是就提高了！
Druid 工作流程---
一个 Druid 集群有各种类型的节点（ Node ）组成，每种节点都被设计来做某组事情，这样的设计可以隔离关注并简化整个系统的复杂度。 Druid 包含如下节点： overlord 节点， middlemanager 节点， broker 节点， historical 节点和 coordinator 节点，在设计时充分考虑到了高可用性，各种节点挂掉都不会使 Druid 停止工作。
下面简单介绍下 Druid 不同节点的作用：
overlord 节点：接收和分发任务。上面说到了在 Druid 上创建了一个叫做 cpu 的 datasource ，其实暂时可以理解为创建了一个任务，目的是告诉 overlord 节点这个 datasource/任务处理的数据描述（模板）是什么，描述包括数据的维度列，聚合列，聚合粒度， segment 生成时间等等参数，任务会按照这个描述对接收到的数据进行聚合。 overlord 节点接到任务后并不会直接处理任务，而是分发给 middlemaanger 节点。
middlemanager 节点：管理任务。 middlemanager 接收到 overlord 分发给他的任务，会继续分发任务，分发给谁呢？分发给 peon ，这才是真正做聚合任务的同志。
从这张图可以看出 overlord 是如何分发任务给 middlemanager 的，通过 zookeeper （下面会提到， druid 的依赖，一些分布式服务都会依赖它， kafka ， hbase 等等）。 peon 完成数据聚合任务后，会生成一个 segment 文件，并且会将 segment 文件永久保存到 deepstorage ， deepstroage 也是 Druid 的一个依赖， Druid 依赖 deepstorage 对 segment 做永久存储，常用的 deepstorage 有 s3 和 hdfs 。
broker 节点：响应外部的查询请求。 broker 节点会根据请求参数（时间段参数等），决定从哪里获取数据。
historical 节点：存储历史数据。 broker 节点响应外部的查询请求，会从某个或者某些 historical 节点查询数据(如果没有，从 deepstorage 加载）。
coordinator 节点：管理集群中的 Segment 操作(下载，删除等)。
每个节点都提供了很多 api ，可以通过 api 查看各个节点的状态信息等，例如查看 overlord 节点的状态信息，如下图：
另外，还可以通过 overlord 节点提供的 web 页面查看任务的状态，以及 middlemanager 的数量，
和每个 middlemanager 可以容纳的 peon 数量等等。
下面是官方提供的 Druid 工作流程图：
这个流程图中没有画出 overlord 和 middlemaanger 节点，图中的 realtime 节点我们暂时没有用到，云智慧用的是 tranquility （ a high level data producer library for Druid ）。通过我们自己的程序，对数据进行清洗后，借助 tranquility 发送数据给 overlord ，看图：
上面对 Druid 节点做了一下大概的介绍，要想让 Druid 正常工作，除了运行 Druid 自身的这些节点外，还需要借助三个依赖。
deepstorage ：用来永久存储 segment 数据，一般是 s3 和 hdfs 。
zookeeper ：用来管理集群状态，保证集群内的数据统一。
metadata storage ：用来保存一些元数据，规则数据，配置数据等。
deepstorage 功能很单一不用多说，那么 zookeeper 和 metadata storage 在 Druid 工作流程中，起着什么样的作用呢？以聚合数据和查询数据简单介绍一下 zookeeper 和 metadata storage 在 Druid 中的工作。
聚合数据： peon 在做聚合任务的时候会周期性的告诉 zookeeper ，正在为哪个 datasource ，生成哪个时间段的数据，即生成哪个 segment ，当聚合任务执行完成后， peon 会将 segment 生成到 deepstroage ，同时会将生成的 segment 的描述信息保存到 metadata storage 中，并同时通知 zookeeper 。这
查询数据： broker 接收数据的查询请求后，会根据请求参数，通过 zookeeper 分析请求的 segment 在哪里：是在 peon 上(middlemaanger 中还没有完全生成一个 segment ，即热数据 /实时数据)，还是在某个或者某些历史节点中，分析出结果后分别向对应节点发出请求，获取数据。 broker 获取各个节点返回过来的数据，再次进行数据归并并最终返回给请求者。
metadata database 的作用又是什么呢？ peon 完成数据聚合后，首先将其保存到 deepstorage 中，同时会将聚合的产物 segment 描述信息(在 hdfs 中的保存路径)保存到 metadata database 中，并通知 zookeeper 。注意： Coordinator 和 historical 节点一直和 zookeeper 保持着连接， Coordinator 还和 metadata database 保持着连接。当 Coordinator 发现 zookeeper 上有一个新的 segment 生成后，会通知 historical 节点去加载这个数据，通知方式依然是借助 zookeeper 。
前文说到 Coordinator 节点管理 segment 的下载和删除，是发生在聚合数据的过程中， peon 完成数据聚合后会通知 zookeeper ，而 Coordinator 一直监控着 zookeeper ，当发现有一个新的 segment 生成后，会通过 zookeeerp 通知某个 historical 节点去下载 segment 。而删除是因为 Historical 节点容量是一定的（可配置的），如果超过了容量，他会删除过期数据或旧数据。
Druid 官方提供的流程图如下：
Druid 在透视宝的作用---
Druid 是如何从透视宝接入数据的呢？如下图所示：
目前，我们有两个服务，一个服务是连接 kafka 和 Druid ，即从 kafka 消费数据发送给 Druid 。一个是连接 broker ，并对外提供 api ，供前端查询数据做报表展示。通过使用 Druid ，大大节省了透视宝的数据存储的空间，提升了数据查询的效率，更好的满足客户大数据分析的需求。今天的分享也到此结束，希望能给你的工作带来一点帮助。
Select Language