OLAP是英文Online Analytical Processing的缩写,中文称为联机分析处理。它是一种基于多维数据模型的分析处理技术,用于从不同的角度进行数据挖掘和分析,以帮助用户快速发现数据之间的相关性和趋势。
OLAP技术通常涉及到预计算、缓存和查询优化等方面的技术,可用于构建在线分析系统(OLAP系统)。该系统将大量的数据按照多个维度进行组织和展示,并提供灵活的查询和聚合功能,以用于支持决策制定、业务分析和报告生成等应用场景。
与传统的关系数据库管理系统(RDBMS)相比,OLAP系统具有更高的查询速度和更丰富的分析功能。它可以在秒级别内查询数千万、甚至数亿条记录,并支持多维度聚合、钻取、切片和切块等功能。因此,OLAP技术在商业智能(BI)和大数据分析领域得到了广泛的应用。
那什么又是OLTP呢?
OLTP是联机事务处理(Online Transaction Processing)的英文缩写,它是一种用于管理业务交易的数据库技术。OLTP系统通常支持高并发的数据插入、更新、删除和查询操作,以保证业务的实时性和准确性。
与OLAP不同,OLTP系统的主要目标是对业务数据进行快速的增删改查操作。因此,OLTP系统需要具有高度的可用性、事务性和数据完整性等特性,以满足业务处理的要求。此外,OLTP系统还需要具有良好的性能和扩展性,以应对高并发访问和大规模数据存储的需求。
OLTP系统通常使用关系型数据库管理系统(RDBMS)实现,例如MySQL、Oracle、Microsoft SQL Server等。这些数据库提供了严格的事务控制和ACID特性,以确保业务数据的一致性和可靠性。同时,它们还提供了丰富的查询和索引功能,以支持各种复杂的业务查询和报表生成。
下面是OLAP和OLTP在不同方面的对比:
特性 | OLAP | OLTP |
---|---|---|
主要使用场景 | 数据分析、决策支持 | 业务交易处理 |
涉及数据量 | 大规模数据(TB或PB级别) | 中等规模数据(GB或TB级别) |
事务和数据完整性 | 不涉及事务,侧重于数据的一致性和准确性 | 需要严格的事务控制和ACID特性,以保证数据的一致性和可靠性 |
功能使用需求 | 多维度查询、聚合、切片、钻取等 | 插入、更新、删除、查询等基本业务操作 |
并发要求 | 读写比较平均,相对较低的并发请求 | 高并发的数据插入、更新、删除和查询操作 |
技术实现方案 | 基于多维度数据模型的处理引擎(如Kylin、Palo等) | 关系型数据库管理系统(RDBMS)(如MySQL、Oracle等) |
可用性要求 | 强调冷热数据分离、容错性等,但非高可用性 | 强调高可用性、故障恢复、备份和灾备等 |
数据模型/规约 | 多维度数据模型,支持OLAP Cube等 | 关系型数据模型,支持SQL查询等 |
技术典范 | Hadoop、Spark、Hive等大数据技术栈 | MySQL、Oracle、Microsoft SQL Server等传统数据库技术栈 |
数据读写特征
查询特征
性能特征
OLAP与OLTP的区别特征
类型 | 描述 | 优点 | 缺点 |
---|---|---|---|
ROLAP(关系型OLAP) | 基于关系型数据库实现OLAP的技术。 | 灵活性高,可以处理大量数据、各种不同类型的查询操作;易于管理和维护;适合实时查询和分析。 | 性能相比MOLAP较弱;难以支持复杂的多维关系;需要专门的存储设备和软件环境来保证其高性能。 |
MOLAP(多维OLAP) | 基于多维存储模型实现OLAP的技术。 | 性能高,可以快速处理复杂的多维查询和分析操作;提供丰富的数据可视化功能,方便用户观察和理解数据;支持离线分析和数据挖掘。 | 数据量大时占用空间较大;对数据修改操作有一定限制;不适合并发访问和实时查询。 |
HOLAP(混合OLAP) | 结合ROLAP和MOLAP的特点,使用两种技术共同构建一个OLAP系统。 | 兼具ROLAP和MOLAP的优点,灵活性和性能都较高;支持复杂的多维查询和分析操作,同时也可以处理实时查询。 | 需要较高的技术水平来实现和维护;在处理大量数据时,性能可能会受到影响。 |
Others(其他OLAP) | 包括HOLAP以外的其他不同类型的OLAP技术,如WOLAP、SOLAP等。 | 扩展性好,可以适应各种不同的数据存储和查询需求;提供特定的功能和工具,支持各种不同的数据分析操作。 | 可能需要额外的硬件和软件环境来保证其高性能;在处理大量数据时,性能可能会受到影响;需要针对不同类型的OLAP技术进行专门的培训和学习。 |
OLAP系统通常可以分为三类:
多维OLAP(Multi-dimensional OLAP,MOLAP)是一种以多维数组或称为多维数据立方体(multidimensional cube)为基础的OLAP系统,它以多个维度来表示和存储数据,并提供了快速的多维数据分析和查询功能。
在多维OLAP系统中,数据通常是按照事实表和维度表的方式组织和存储的。事实表包含了各种业务数据以及与之相关的度量(measures),如销售额、库存量等;而维度表则包含了各种描述性的属性信息,如时间、地理位置、产品类别等。通过将事实表和维度表联接起来,就形成了一个多维数据立方体,可以方便地进行各种数据分析和查询操作。
多维OLAP系统的优点在于它具有快速响应、高性能、易于使用等特点,能够支持各种复杂的多维数据分析和查询操作,例如:对不同维度的数据进行切片和钻取、同时对多个维度进行分析、按照时间趋势进行分析等。此外,多维OLAP系统还具有灵活性和可扩展性,支持动态添加新的维度和度量等。
因为我这篇文章会把涉及到的比较流行的OLAP的框架都总结进来,所以会把下面要做分类的框架与这个放到前面的总结进行清晰划分。
OLAP引擎中常见操作的内容:
操作 | 描述 |
---|---|
上卷/Roll Up | 选定某些维度,根据这些维度来聚合事实。例如:SELECT dim_a, aggs_func(fact_b) FROM fact_table GROUP BY dim_a |
下钻/Drill Down | 选定某些维度,将这些维度拆解出小的维度(如年拆解为月,省份拆解为城市),之后聚合事实 |
切片(Slicing、Dicing) | 选定某些维度,并根据特定值过滤这些维度的值,将原来的大Cube切成小cube。例如:dim_a IN (‘CN’, ‘USA’) |
旋转/Pivot/Rotate | 维度位置的互换 |
Impala、Presto、ClickHouse、Doris、Druid、TiDB这6个开源OLAP引擎的对比总结:
引擎 | 开源情况 | 优点 | 缺点 | 易用性 | 自身存储 |
---|---|---|---|---|---|
Impala | Apache项目 | 支持Hive元数据,可以兼容 Hive SQL 使用 MPP 架构,响应速度快 | 不支持 Array 类型 部分 Hadoop 生态系统内缺少集成 | 较易上手,但配置较为复杂 | 依赖于 HDFS 或 Kudu 存储 |
Presto | Facebook开源 | 支持多种数据源和格式,可拓展性强 | 处理海量数据时,性能下降明显 | 查询语言支持 ANSI SQL | 依赖于外部存储(如 HDFS、S3 等) |
ClickHouse | Yandex开源 | 为列式存储设计,查询速度快,压缩率高,扩展性好 | 仅支持 SQL92 标准的语法,不支持 JSON、XML等非结构化数据 | 容易上手,学习资料丰富 | 列式存储系统 |
Doris | Apache项目 | 采用基于列的存储结构,处理千亿行数据,查询速度快,易于扩展 支持多写,易于扩展,提供 RESTFUL API, 技术支持较好 | 对于复杂结构的查询不友好,缺少开发文档 | 支持 MySQL 协议,易于上手 | 基于 HDFS 存储 |
Druid | Apache项目 | 支持超快速的聚合查询和实时数据摄取,可拓展性强 易于安装、配置和使用,社区活跃度高 | 对时间序列数据表现优异,对非时间序列数据支持不足 | 无需外部存储,自身存储能力强 | 自身存储 |
TiDB | PingCAP开源 | 优秀的分布式事务处理能力,支持 SQL 和 NoSQL 数据模型 | 对大数据集查询性能稍逊,单机版性能不理想 | 支持 MySQL协议,易于上手 | 分布式 NewSQL 数据库 |
希望这份总结能够对您有所帮助。需要注意的是,以上信息可能随着引擎版本的更新而发生变化,请以官方文档或最新资料为准。
先来点开胃小菜,先把即将进一步深入分析的OLAP框架进行下简单总结,先在头脑里留下的印象。
Impala是Cloudera开发并开源的,是一种SQL on Hadoop解决方案。与Hive类似,但抛弃了MapReduce,使用MPP数据库技术提高查询速度。Impala可以直接查询存储在HDFS和HBase中的数据,并且支持与现有存储无缝对接。需要单独安装,公司内PAAS主推。提供JDBC接口和SQL执行引擎,易于与现有系统集成。
Presto是Facebook开源的大数据查询引擎,旨在解决Hive查询速度慢的问题。使用Java编写,所有数据均在内存中处理。原生集成了Hive、HBase和关系型数据库。提供JDBC接口和SQL执行引擎,易于与现有系统集成。
Druid采用预计算的方式来解决基于时序的数据进行聚合查询的问题。数据可以实时摄入,并立即可查,同时数据几乎不可变。通常基于时序的事实事件进入Druid,外部系统就可以对该事实进行查询。需要预计算,将数据存储在Druid的Segment文件中,占用一定存储资源。对SQL支持不友好,需要使用Druid自己的方言书写。无需外部存储,自身存储能力强。
Kylin是一种OLAP数据引擎,通过预计算的方式将用户设定的多维度数据立方体(cube)缓存起来,达到快速查询的目的。应用场景是针对复杂SQL join后的数据缓存。需要预计算,将数据构建成cube存储到HBase中。提供JDBC接口和REST服务,易于与现有系统集成。
Redis可以将要分析的数据同步到Redis并在其中快速查询。可以在分析前将本月数据同步到Redis。
并发能力对比:
简单查询
复杂查询
并发能力对比:
查询延迟对比:
执行模型对比:
Hive是一个分布式SQL on Hadoop方案,可在底层MapReduce计算模型上执行分布式计算。它擅长处理长时间运行的离线批处理,数据量越大,其优势越明显。因此,Hive在数据量大且数据驱动需求强烈的互联网大厂中很受欢迎。
然而,在过去两年中,随着Clickhouse逐渐流行,某些总数据量不超过百PB级别的互联网数据仓库需求已经有多家公司改用Clickhouse的方案。相比Hadoop/Hive,Clickhouse拥有以下优势:
因此,对于需要查询速度更快、结构更简单的较小规模大数据仓库的公司,Clickhouse可能是更好的选择。
在大部分场景下,Hive的计算速度过慢。即使对于企业内部产品、运营、数据分析师的ad-hoc查询,也会经常抱怨Hive执行太慢。更不用说对外在线服务的高QPS、低查询延迟的需求了。这些痛点推动了MPP内存迭代和DAG计算模型的诞生和发展,例如Spark SQL、Flink SQL、Presto等技术,目前在企业中非常流行。
相比Hive,Spark SQL和Flink SQL的执行速度更快,编程API丰富,同时支持流式计算与批处理,并且具有流批统一的趋势,从而使得大数据应用变得更加简单。因此,在需要高性能、低延迟的场景下,Spark SQL和Flink SQL可能是更好的选择。
对于MPP架构的数据库,例如Presto、Apache Drill和Apache Impala和Greenplum等,它们都具有以下特点:
总之,MPP架构的数据库具有分布式计算、SQL支持、横向扩展和实时查询等特点。这些特点使得它们非常适合处理海量数据和高并发访问的应用场景,如实时日志分析、电商推荐、搜索和人工智能等领域。
Elasticsearch、Druid、Kylin和MPP架构的数据库都是目前流行的大数据处理和分析解决方案。它们之间存在以下不同之处:
除了架构模式、适用场景、数据处理能力和技术门槛等因素,还需要考虑ad-doc和QPS等性能指标。
关于Elasticsearch、Druid、Kylin和MPP架构的数据库在延迟和数据源特征方面进行总结。
Elasticsearch是一个开源的搜索和分析引擎,主要用于全文检索和实时日志分析等领域。它支持实时数据处理和交互式查询,可以在毫秒级别内返回查询结果。Elasticsearch的查询响应时间通常在几百毫秒内,对于实时日志分析等场景可达到毫秒级别的查询响应速度。Elasticsearch可以支持海量数据的实时搜索,并且具有良好的水平扩展性和负载均衡能力。同时,Elasticsearch还可以与各种数据源进行整合,例如MySQL、Oracle、MongoDB等。
使用案例:
Druid是一个面向OLAP分析的开源数据存储和查询系统,采用了列式存储和多维聚合查询等技术。在处理简单的聚合查询时,Druid的查询响应时间通常在几十毫秒到几百毫秒之间。Druid主要适用于基于事件的数据源和时间序列数据源,可以在高吞吐量的实时数据流中进行在线数据分析和处理。同时,Druid也支持以批处理方式加载静态数据,如从Hadoop集群中读取日志。
使用案例:
Kylin是一个开源的分布式OLAP引擎,可以将大规模数据保存到Hadoop中,并支持多维度聚合查询和快速过滤。在处理复杂的多维聚合查询时,Kylin的查询响应时间通常在几秒钟到几十秒之间。Kylin需要较长的预计算和构建时间,同时也对数据源的要求比较严格。Kylin适用于面向行的数据源,主要作用是实现OLAP分析。
使用案例:
MPP架构的数据库是一种高性能的分布式数据库系统,具有良好的水平扩展和负载均衡能力。MPP架构的数据库适用于大规模数据仓库和企业级应用。它能够处理各种类型的数据源,包括结构化、半结构化和非结构化数据。同时,MPP架构的数据库也支持与多个数据源进行互操作,如Hadoop、NoSQL、RDBMS等。
使用案例:
在选择大数据处理和分析解决方案时,还需要考虑数据源的特征。以下是这四种解决方案适用的不同数据源类型:
Elasticsearch适用于文本、日志、指标和其他结构化或半结构化数据。它支持实时索引,可以快速存储、搜索和分析大量文档数据。同时,Elasticsearch也可以与各种数据源进行整合,例如MySQL、Oracle、MongoDB等。
使用案例:
Druid适用于基于事件的数据源和时间序列数据源。它支持多维聚合查询和快速过滤,可以在高吞吐量的实时数据流中进行在线数据分析和处理。同时,Druid也支持以批处理方式加载静态数据,如从Hadoop集群中读取日志。
使用案例:
Kylin适用于面向行的数据源,其主要作用是实现OLAP分析。它需要预计算和缓存处理大量的聚合数据,并通过ETL工具将数据从各种数据源(如Hive、HBase、MySQL、PostgreSQL等)加载到Kylin中。
使用案例:
MPP架构的数据库适用于大规模数据仓库和企业级应用。它能够处理各种类型的数据源,包括结构化、半结构化和非结构化数据。同时,MPP架构的数据库也支持与多个数据源进行互操作,如Hadoop、NoSQL、RDBMS等。
使用案例:
ClickHouse是近年来备受关注的开源列式数据库,主要用于数据分析(OLAP)领域。目前国内社区火热,各个大厂纷纷跟进大规模使用。
ClickHouse从OLAP场景需求出发,定制开发了一套全新的高效列式存储引擎,并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。
ClickHouse部署架构简单,易用,不依赖Hadoop体系(HDFS+YARN)。它比较擅长的地方是对一个大数据量的单表进行聚合查询。Clickhouse用C++实现,底层实现具备向量化执行(Vectorized Execution)、减枝等优化能力,具备强劲的查询性能。目前在互联网企业均有广泛使用,比较适合内部BI报表型应用,可以提供低延迟(ms级别)的响应速度,也就是说单个查询非常快。
但是Clickhouse也有它的局限性,在OLAP技术选型的时候,应该避免把它作为多表关联查询(JOIN)的引擎,也应该避免把它用在期望支撑高并发数据查询的场景,OLAP分析场景中,一般认为QPS达到1000+就算高并发,而不是像电商、抢红包等业务场景中,10W以上才算高并发,毕竟数据分析场景,数据海量,计算复杂,QPS能够达到1000已经非常不容易。例如Clickhouse,如果如数据量是TB级别,聚合计算稍复杂一点,单集群QPS一般达到100已经很困难了,所以它更适合企业内部BI报表应用,而不适合如数十万的广告主报表或者数百万的淘宝店主相关报表应用。Clickhouse的执行模型决定了它会尽全力来执行一个Query,而不是同时执行很多Query。
我博客里写了很多有关Elasticsearch的文章,因为它是脱胎于lucene,Lucene众所周知是个搜索引擎框架。依托于Lucene的倒排序索引结构,加之支持文本分词,所以搜索领域可以说是独占鳌头。而且性能也很高,基本上三个节点的集群,支撑个1000+的qps轻轻松松。你以为它的强大就只适用于搜索场景了?其实并不是,它提供着强大的聚合(aggregation)功能,虽然是json结构的,但是与传统的sql是可以互相转化的。
举例:
Elasticsearch Aggregation 语句:
{
"aggs": {
"orders_per_month": {
"date_histogram": {
"field": "order_date",
"interval": "month"
},
"aggs": {
"total_sales": {
"sum": {
"field": "order_total"
}
},
"average_sales": {
"avg": {
"field": "order_total"
}
}
}
}
}
}
以上聚合查询语句的含义是,按月份(interval: month)分组计算订单总数(total_sales)和平均销售额(average_sales),并在每个月份中显示。
SQL 查询语句:
使用Impala的SQL查询语言将上述Aggregation语句转换为SQL查询语句,大致如下所示:
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(order_total) AS total_sales,
AVG(order_total) AS average_sales
FROM
my_table
GROUP BY
month;
以上SQL查询语句的含义是,按月份(DATE_TRUNC函数)分组(GROUP BY子句)计算订单总数(SUM函数)和平均销售额(AVG函数),并显示每个月份的结果。
Elasticsearch的查询执行引擎基于Scatter-Gather MapReduce模型,下面是它们之间的关系说明:
Elasticsearch可以理解成为最简单的Scatter-Gather MapReduce模型,Elasticsearch能够高效地处理大量的数据查询请求。具体而言,该模型具有以下优点:
这样的结构特点,也决定了它适用的业务范围,由于节点上数据交换是基于内存,而不会像MapReduce那次每次shuffle都要先落盘。而Lucene的倒排序的数据结构实际是一种行列混存模式,并且在做查询的时候又能通过FPS和跳表等来加快数据的查询,所以在数据量不大的时候,性能还是很高的。但是如果只是单机部署,那么这种基于提高QPS理念的设计就会导致执行特别慢,这也是部署时候应该注意的。
Elasticsearch作为OLAP引擎存在以下一些劣势:
举个例子:将Elasticsearch作为电商网站的商品搜索引擎,实现在线交易处理(Online Transaction Processing)。
在这个例子中,Java应用程序可以使用Elasticsearch进行以下操作:
具体而言,Java应用程序可以使用Elasticsearch提供的Java API,通过HTTP协议与Elasticsearch集群通信,实现上述操作。这段Java代码会演示如何使用Elasticsearch的Java API向索引中添加文档:
RestHighLevelClient client = new RestHighLevelClient(
RestClient.builder(new HttpHost("localhost", 9200, "http")));
IndexRequest request = new IndexRequest("my_index");
request.id("1");
String jsonString = "{" +
"\"name\":\"John\"," +
"\"age\":30," +
"\"city\":\"New York\"" +
"}";
request.source(jsonString, XContentType.JSON);
IndexResponse response = client.index(request, RequestOptions.DEFAULT);
System.out.println(response.getResult());
RestHighLevelClient连接到Elasticsearch集群,创建一个名为"my_index"的索引,并将一条包含姓名、年龄和城市信息的文档添加到该索引中。
Impala:
另外,再从数据兼容类型的角度,Impala也具有一些优势:
总之,Impala是一个可以直接查询HDFS和HBase中的数据,与Hive无缝集成的分布式SQL查询引擎,同时还提供了JDBC和ODBC连接器,支持Parquet和Avro等文件格式。通过这些功能,Impala提供了非常广泛和灵活的数据访问能力,可以与Hadoop生态系统中的其他组件(例如Apache Zeppelin、Tableau等)无缝集成。同时,Impala基于内存的列式存储引擎和优化查询算法,使得它能够快速、高效地处理大规模数据,并且具有极低的延迟。
#include <impala/client.h>
using namespace impala;
int main() {
// 创建Impala客户端连接
boost::shared_ptr<ImpalaClient> client(new ImpalaClient("localhost", 21050));
// 执行SQL查询
TExecResult result;
client->Exec("SELECT * FROM my_table", &result);
// 处理查询结果
if (result.__isset.data) {
for (int i = 0; i < result.data.size(); ++i) {
// 处理每行记录
}
}
}
import java.sql.*;
public class ImpalaDemo {
public static void main(String[] args) throws SQLException {
Connection connection = null;
Statement statement = null;
ResultSet resultSet = null;
try {
// 连接Impala
Class.forName("org.apache.hive.jdbc.HiveDriver");
connection = DriverManager.getConnection("jdbc:hive2://localhost:21050/default", "", "");
statement = connection.createStatement();
// 执行SQL查询
String sql = "SELECT * FROM my_table";
resultSet = statement.executeQuery(sql);
// 处理查询结果
while (resultSet.next()) {
// 处理每行记录
}
} finally {
// 关闭连接
resultSet.close();
statement.close();
connection.close();
}
}
}
要说Kylink就不得不提一个概念,就是MOLAP系统。
MOLAP(多维在线分析处理)是一种基于多维数据存储和查询的数据仓库技术。它将数据按照不同的维度组织,并使用聚合计算以提高查询性能。MOLAP通常具有以下特点:
MOLAP Cube是MOLAP中最重要的概念之一,它是多维数据的物理表示,由多个维度和指标构成。MOLAP Cube具有以下特点:
MOLAP Cube通常包含以下组成部分:
适合Kylin的场景包括:
简单来说,Kylin中数据立方的思想就是以空间换时间,通过定义一系列的纬度,对每个纬度的组合进行预先计算并存储。有N个纬度,就会有2的N次种组合。所以最好控制好纬度的数量,因为存储量会随着纬度的增加爆炸式的增长,产生灾难性后果。
Druid是一款快速、灵活的开源数据存储、查询和分析引擎,支持实时和批处理,并可扩展到PB级别的数据量。
Druid广泛用于以下领域:
实时监控可以说是Druid的拿手好戏了,所以在Spring开发中,你会发现有很多公司把它直接集成到一些业务内做埋点,完成对数据的监控,如果想在Spring中使用Druid来做监控,该怎么做呢?
Java Spring Framework集成Druid进行数据访问层(DAO)监控的示例代码:
<dependencies>
<!-- druid spring boot starter -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid-spring-boot-starter</artifactId>
<version>${druid.version}</version>
</dependency>
<!-- mysql connector java -->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysql.version}</version>
</dependency>
</dependencies>
spring.datasource.url=jdbc:mysql://localhost:3306/test
spring.datasource.username=root
spring.datasource.password=root
# Druid configuration
spring.datasource.druid.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.druid.initial-size=5
spring.datasource.druid.min-idle=5
spring.datasource.druid.max-active=20
spring.datasource.druid.max-wait=60000
spring.datasource.druid.time-between-eviction-runs-millis=60000
spring.datasource.druid.min-evictable-idle-time-millis=300000
spring.datasource.druid.validation-query=SELECT 1 FROM DUAL
spring.datasource.druid.test-while-idle=true
spring.datasource.druid.test-on-borrow=false
spring.datasource.druid.test-on-return=false
spring.datasource.druid.filters=stat,wall
spring.datasource.druid.connection-properties=druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000
public class User {
private Long id;
private String username;
private String password;
// getters and setters
}
@Mapper
public interface UserMapper {
@Select("SELECT id, username, password FROM user WHERE id=#{id}")
User selectById(Long id);
}
@Repository
public class UserMapperImpl implements UserMapper {
@Autowired
private JdbcTemplate jdbcTemplate;
public User selectById(Long id) {
return jdbcTemplate.queryForObject("SELECT id, username, password FROM user WHERE id=?", new Object[]{id}, new BeanPropertyRowMapper<>(User.class));
}
}
@RestController
public class UserController {
@Autowired
private UserMapper userMapper;
@GetMapping("/users/{id}")
public User getUserById(@PathVariable Long id) {
return userMapper.selectById(id);
}
}
通过以上步骤,就可以在Java Spring Framework中集成Druid进行数据访问层(DAO)监控了。