Druid之旅-大数据实时分析数据存储框架

合集下载

大数据技术与应用基础-第11、12章事件流OLAP之Druid、事件数据流引擎Flink

安装ZooKeerper
前几章以讲过，此处不赘述。
启动Druid：首先进入到Druid的根目录，执行bin/init。 Druid会自动创建一个var目录，内含两个目录。一个是druid，用于存放本地环境下Hadoop的临时文件、缓存和任务的临时文件等。另一个是tmp用于存放其他临时文件。
四、Druid单机环能不同的节点组成的。
内容导航
CONTENTS
Druid简介
Druid应用场所 Druid集群
Druid单机环境
四、Druid单机环境
安装Druid
下载并安装Druid，命令如下： curl -O http://static.druid.io/artifacts/releases/druid0.9.1.1-bin.tar.gz tar -xzvf druid-0.9.1.1-bin.tar.gz –C /hadoop/ cd /hadoop/druid-0.9.1.1
内容导航
CONTENTS
Druid简介
Druid应用场所
Druid集群
Druid单机环境
三、Druid集群
Druid集群是由很多功能不同的节点组成的。
三、Druid集群
Druid集群是由很多功能不同的节点组成的。
Historical Nodes：Historical Nodes可以看做是Druid集群的脊椎，它将segment固化到本地，供集群查询时使用。 Broker Nodes：Broker Nodes 是客户端和相关应用从 Druid集群上查询数据的节点，它的职责是对客户端过来的查询做负载，聚集和合并查询结果。 Coordinator Nodes：Coordinator Nodes用来管理Druid 集群放在Historical Nodes上的segment。 Real-time Processing：实时数据处理可以在单点实时节点或者索引服务(indexing service)完成 Overload Nodes：主要是用于批量索引服务。 ZooKeeper：用于集群内部通讯。 Metadata Storage：用户存储segment，configuration等的metadata信息

druid 连接池原理

druid 连接池原理Druid连接池原理Druid是一种高性能的开源连接池，用于管理数据库连接的资源。

它是阿里巴巴开源的项目，被广泛应用于Java开发中。

本文将介绍Druid连接池的原理和工作机制。

1. 连接池的基本概念连接池是一种用于管理数据库连接的技术，通过预先创建一定数量的数据库连接并将其保存在连接池中，应用程序可以从连接池中获取连接、使用连接、释放连接，从而提高数据库访问的效率和性能。

2. Druid连接池的特点Druid连接池相比其他连接池，具有以下几个特点：- 高性能：Druid连接池采用了一系列优化措施，如使用高效的数据结构、多线程并发访问等，使得连接的获取和释放效率更高。

- 安全可靠：Druid连接池内置了多项安全特性，如防止SQL注入、防火墙等，增强了应用程序对数据库的保护。

- 监控功能：Druid连接池提供了强大的监控功能，可以实时统计连接的使用情况、执行的SQL语句、慢查询等，方便开发人员进行性能分析和优化。

- 扩展性强：Druid连接池支持自定义扩展，可以根据具体需求对连接池进行定制化的配置和功能扩展。

Druid连接池的工作原理可以简单分为以下几个步骤：3.1 初始化连接池应用程序启动时，Druid连接池会根据配置参数初始化一定数量的数据库连接对象，并将这些连接对象保存在连接池中。

3.2 连接获取和分配当应用程序需要与数据库进行交互时，会从连接池中获取一个可用的连接。

Druid连接池采用了一种高效的算法来管理连接的分配和归还，保证连接的均衡分配和高效利用。

3.3 连接的使用应用程序通过获取到的连接对象，执行SQL语句或事务操作，并处理数据库返回的结果。

3.4 连接的释放应用程序在使用完连接后，需要将连接释放回连接池。

这样其他应用程序就可以继续使用该连接，而无需重新创建新的连接，提高了连接的复用率。

3.5 连接的销毁当连接池中的连接长时间没有被使用，或者连接出现异常情况时，连接池会对连接进行销毁，保证连接池中的连接始终是可用状态。

Druid（准）实时分析统计数据库——列存储+高效压缩

Druid（准）实时分析统计数据库——列存储+⾼效压缩Druid是⼀个开源的、分布式的、列存储系统，特别适⽤于⼤数据上的（准）实时分析统计。

且具有较好的稳定性（Highly Available）。

其相对⽐较轻量级，⽂档⾮常完善，也⽐较容易上⼿。

Druid vs 其他系统Druid vs Impala/SharkDruid和Impala、Shark 的⽐较基本上可以归结为需要设计什么样的系统Druid被设计⽤于：1. ⼀直在线的服务2. 获取实时数据3. 处理slice-n-dice式的即时查询查询速度不同：Druid是列存储⽅式，数据经过压缩加⼊到索引结构中，压缩增加了RAM中的数据存储能⼒，能够使RAM适应更多的数据快速存取。

索引结构意味着，当添加过滤器来查询，Druid少做⼀些处理，将会查询的更快。

Impala/Shark可以认为是HDFS之上的后台程序缓存层。

但是他们没有超越缓存功能，真正的提⾼查询速度。

数据的获取不同：Druid可以获取实时数据。

Impala/Shark是基于HDFS或者其他后备存储，限制了数据获取的速度。

查询的形式不同：Druid⽀持时间序列和groupby样式的查询，但不⽀持join。

Impala/Shark⽀持SQL样式的查询。

Druid vs ElasticsearchElasticsearch(ES) 是基于Apache Lucene的搜索服务器。

它提供了全⽂搜索的模式，并提供了访问原始事件级数据。

Elasticsearch还提供了分析和汇总⽀持。

根据研究，ES在数据获取和聚集⽤的资源⽐在Druid⾼。

Druid侧重于OLAP⼯作流程。

Druid是⾼性能（快速聚集和获取）以较低的成本进⾏了优化，并⽀持⼴泛的分析操作。

Druid提供了结构化的事件数据的⼀些基本的搜索⽀持。

Segment: Druid中有个重要的数据单位叫segment，其是Druid通过bitmap indexing从raw data⽣成的（batch or realtime）。

druid数据库连接池使用手册

Druid是一种Java语言编写的高效、可扩展的数据库连接池。

以下是Druid 数据库连接池的一些基本使用步骤。

请注意，这只是一个简要的介绍，更详细和具体的配置和使用细节需要根据你的具体项目和需求进行调整。

### 1. 引入Druid依赖在你的项目中引入Druid的依赖，可以通过Maven、Gradle等构建工具实现。

Maven:<dependency><groupId>com.alibaba</groupId><artifactId>druid</artifactId><version>1.2.6</version></dependency>### 2. 配置数据源在项目的配置文件中配置Druid数据源，通常是在`application.properties` 或`application.yml` 文件中添加以下配置：spring:datasource:url: jdbc:mysql://localhost:3306/your_databaseusername: your_usernamepassword: your_passworddriver-class-name: com.mysql.cj.jdbc.Drivertype: com.alibaba.druid.pool.DruidDataSource# Druid配置druid:initial-size: 5min-idle: 5max-active: 20max-wait: 60000time-between-eviction-runs-millis: 60000validation-query: SELECT 1 FROM DUALtest-while-idle: truetest-on-borrow: falsetest-on-return: falsepool-prepared-statements: truemax-pool-prepared-statement-per-connection-size: 20filters: stat,wall,log4jconnection-properties:druid.stat.mergeSql=true;druid.stat.slowSqlMillis=500这是一个基本的Druid数据源配置，其中包括了连接池的一些基本参数。

druid配置详解

配置缺省值说明name 配置这个属性的意义在于，如果存在多个数据源，监控的时候可以通过名字来区分开来。

如果没有配置，将会⽣成⼀个名字，格式是："DataSource-" + System.identityHashCode(this)jdbcUrl 连接数据库的url，不同数据库不⼀样。

例如：MYSQL : jdbc:mysql://10.20.153.104:3306/druid2 ORACLE : jdbc:oracle:thin:@10.20.149.85:1521:ocnautousername连接数据库的⽤户名password连接数据库的密码。

如果你不希望密码直接写在配置⽂件中，可以使⽤ConfigFilter。

详细看这⾥：driverClassName根据url⾃动识别这⼀项可配可不配，如果不配置druid会根据url⾃动识别dbType，然后选择相应的driverClassName initialSize0初始化时建⽴物理连接的个数。

初始化发⽣在显⽰调⽤init⽅法，或者第⼀次getConnection时maxActive8最⼤连接池数量maxIdle8已经不再使⽤，配置了也没效果minIdle最⼩连接池数量maxWait 获取连接时最⼤等待时间，单位毫秒。

配置了maxWait之后，缺省启⽤公平锁，并发效率会有所下降，如果需要可以通过配置useUnfairLock属性为true使⽤⾮公平锁。

poolPreparedStatements false 是否缓存preparedStatement，也就是PSCache。

PSCache对⽀持游标的数据库性能提升巨⼤，⽐如说oracle。

在mysql5.5以下的版本中没有PSCache功能，建议关闭掉。

作者在5.5版本中使⽤PSCache，通过监控界⾯发现PSCache有缓存命中率记录，该应该是⽀持PSCache。

maxOpenPreparedStatements-1要启⽤PSCache，必须配置⼤于0，当⼤于0时，poolPreparedStatements⾃动触发修改为true。

Druid简单使用配置及其介绍资料

2
Guanping.Li
Druid介绍
三、优秀特性：
1、ExceptionSorter。当一个连接产生不可恢复的异常时，例如Oracle error_code_28 session has been killed,必须立刻从连接池中逐出,否则会产生大量错误.目前只有Druid和JBoss DataSource实现了ExceptionSorter. 2、PSCache内存占用优化对于支持游标的数据库(Oracle、SQL Server、DB2等，不包括MySql),PSCache 可以大幅度提升SQL执行性能。一个PreparedStatement对应服务器一个游标，如果PreparedStatement被缓存起来重复执行，PreparedStatement没有被关闭，服务器端的游标就不会被关闭，性能提高非常显著。在类似 “SELECT * FROM T WHERE ID = ?”这样的场景，性能可能是一个数量级的提升。但在Oracle JDBC Driver中，其他的数据库连接池（DBCP、JBossDataSource）会占用内存过多，极端情况可能大于1G。Druid调用 OracleDriver提供管理PSCache内部API。 3、LRU(Least Recently Used近最少使用)是一个性能关键指标，特别Oracle，每个Connection对应数据库端的一个进程，如果数据库连接池遵从LRU，有助于数据库服务器优化，这是重要的指标。Druid、DBCP、 Proxool、JBoss是遵守LRU的。BoneCP、C3P0则不是。BoneCP在mock环境下性能可能还好，但在真实环境中则就不好了。
一、强大的监控特性：
通过Druid提供的监控功能，可以清楚知道连接池和SQL的工作情况。 1、监控SQL的执行时间、ResultSet持有时间、返回行数、更新行数、错误次数、错误堆栈信息。 2、SQL执行的耗时区间分布。什么是耗时区间分布呢？比如说，某个SQL执行了1000次，其中0~1毫秒区间50次，1~10毫秒800次，10~100 毫秒100次，100~1000毫秒30次，1~10秒15次，10秒以上5次。通过耗时区间分布，能够非常清楚知道SQL的执行耗时情况。 3、监控连接池的物理连接创建和销毁次数、逻辑连接的申请和关闭次数、非空等待次数、PSCache命中率等。

druid数据库连接池工作原理

druid数据库连接池工作原理Druid数据库连接池工作原理在当今的软件开发中，数据库连接池扮演着至关重要的角色。

它们可以有效地管理数据库连接，提高应用程序的性能和响应速度。

而Druid数据库连接池作为一种优秀的数据库连接池实现，其工作原理更是备受关注。

让我们来了解一下Druid数据库连接池的基本结构。

Druid数据库连接池由几个主要组件组成，包括连接池管理器、连接对象、连接池监控和连接池状态等。

其中，连接池管理器负责管理连接对象的创建、分配和释放，连接对象则表示与数据库的实际连接。

连接池监控用于监控连接池的状态和性能指标，以便及时调整连接池的配置参数。

Druid数据库连接池的工作原理可以概括为以下几个步骤：1. 初始化连接池：在应用程序启动时，Druid连接池会根据配置参数初始化一定数量的数据库连接，并将它们存放在连接池中。

2. 请求连接：当应用程序需要与数据库交互时，它会向连接池请求一个数据库连接。

连接池会从连接池中选择一个空闲的连接对象分配给应用程序，并将其标记为“繁忙”。

3. 数据库操作：应用程序使用连接对象进行数据库操作，如查询、更新等。

一旦操作完成，应用程序需要及时释放连接对象，以便连接池可以重新利用该连接。

4. 连接归还：当应用程序释放连接对象时，连接池会将该连接对象重新标记为“空闲”，并使其可供其他应用程序使用。

5. 连接监控：Druid连接池会定期检查连接对象的状态，包括连接是否超时、是否空闲等。

如果发现异常连接，连接池会及时进行回收或重新创建，以确保连接池的稳定运行。

总的来说，Druid数据库连接池通过有效地管理数据库连接对象，实现了连接的复用和性能的优化。

它可以根据应用程序的需求动态调整连接池的大小，提高数据库访问效率，并且通过连接池监控功能，能够及时发现和处理连接池中的问题，确保应用程序的稳定运行。

在实际应用中，合理配置Druid数据库连接池的参数是非常重要的。

通过调整连接池的最大连接数、最小空闲连接数、连接超时时间等参数，可以有效地提高数据库访问性能，避免连接泄漏和性能瓶颈。

滴滴业务实时监控系统架构介绍

Partition 0 输入流 Partition 1 Partition 2 本地状态存储 (RocksDB)
Container 1
Task 0
Task 1
Task 2
Container 2
job
Checkpoint Stream
输出流
Changelog Stream
Samza的高可用性
Kafka Log A Log B Log C Log D
➢ Liquid ：停止当前实时计算任务，修改Offset后，重启任务
druid是针对时间序列数据提供低延时的数据写入以及快速交互式查询的的分布式olap数据库druid的数据存储方式主要根据时间对segment文件进行分片存储segment包含的三种列类型时间戳列作为数据分发存储查询的依据维度列支持过滤和分组使用字典编码压缩使用bitmap索引压缩指标列用来聚合计算使用lz4压缩druid的数据处理流程介绍实时流数据离线数据客户端请求segements查询元数据druid节点外部依赖缓存缓存lambda架构druidkafkaindexingservice介绍overlordmiddlemanagersmiddlemanagermiddlemanagermiddlemanagerkafkapartition0partition1topic1partition0partition1topic2kafka中每个partiton的消息是严格有序追加写入不可改变控制流数据流druid支持近似统计算法基于yahoo开发的datasketches使用thetasketch近似算法支持集合操作并集交集差集druid支持地理查询包含在druid092版本滴滴实时订单热力图为何选用samza
Task1

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

THE JOURNEY OF DRUID,A BIG DATA ANALYTICS DATA STOREERIC TSCHETTER,CREATOR OF DRUIDDEMO“”REQUIREMENTSREQUIREMENTS•Data Ingestion Rate•Ingest data and make it queryable in real-time •Arbitrary Drill-Downs, Slice-n-Dice •Arbitrary boolean ﬁlters•Availability•Downtime is evil“”WHAT WE TRIEDWHAT WE TRIED I. RDBMS - Relational DatabaseI. RDBMS - THE SETUP •Star Schema•Aggregate Tables•Query CachingI. RDBMS - THE RESULTS •Queries that were cached•fast•Queries against aggregate tables •fast to acceptable•Queries against base fact table •generally unacceptableI. RDBMS - PERFORMANCESelect COUNT(*) scan rate~5.5M rows / second / core 1 day of summarized aggregates60M+ rows1 query over 1 week, 16 cores~5 secondsPage load with 20 queries over a weeklong timeof dataI. RDBMS - Relational DatabaseI. RDBMS - Relational Database II. NoSQL - Key/Value Store•Pre-aggregate all dimensional combinations (truncate time) •Store results in a NoSQL store II. NOSQL - THE SETUP ts !gender agerevenue 1M 18$0.151F25$1.032F 18$0.01Key Value 1revenue=$1.191,M revenue=$0.151,F revenue=$1.041,18revenue=$0.161,25revenue=$1.031,M,18revenue=$0.151,F ,18revenue=$0.011,F ,25revenue=$1.03II. NOSQL - THE RESULTS •Queries were fast•range scan on primary key•Inﬂexible•not aggregated, not available •Not continuously updated •aggregate ﬁrst, then display •Processing scales exponentiallyII. NOSQL - PERFORMANCE •Dimensional combinations => exponential increase •Tried limiting dimensional depth•still expands exponentially•Example: ~500k records•11 dimensions, 5-deep•4.5 hours on a 15-node Hadoop cluster•14 dimensions, 5-deep•9 hours on a 25-node Hadoop clusterI. RDBMS - Relational Database II. NoSQL - Key/Value StoreI. RDBMS - Relational Database II. NoSQL - Key/Value Store III. ???•Problem with RDBMS: scans are slow •Problem with NoSQL: computationally intractable•Problem with RDBMS: scans are slow •Problem with NoSQL: computationally intractable!•Tackling RDBMS issue seems easier“”INTRODUCING DRUIDDRUID – KEY FEATURES1.Real-Time Ingestion (Indigestion?)2.Slicing-n-Dicing Drill Down Fruit Ninjas3.AvailableRealtime NodesQuery APIQuery API a Historical Nodes Realtime NodesQuery API Hand Off DataQuery API a Historical Nodes Broker Nodes Realtime NodesQuery APIQuery API Query RewriteScatter/GatherHand Off DataDATA!timestamp publisher advertiser gender country ... click price! 2011-01-01T00:01:35Z Male USA 0 0.65! 2011-01-01T00:03:63Z Male USA 0 0.62! 2011-01-01T00:04:51Z Male USA 1 0.45! 2011-01-01T01:00:00Z Female UK 0 0.87! 2011-01-01T02:00:00Z Female UK 0 0.99! 2011-01-01T02:00:00Z Female UK 1 1.53! ...COLUMN COMPRESSION - DICTIONARIES•Create ids• -> 0, -> 1•Store•publisher -> [0, 0, 0, 1, 1, 1]•advertiser -> [0, 0, 0, 0, 0, 0] timestamp publisher advertiser gender country ... click price !2011-01-01T00:01:35Z Male USA 0 0.65!2011-01-01T00:03:63Z Male USA 0 0.62!2011-01-01T00:04:51Z Male USA 1 0.45!2011-01-01T01:00:00Z Female UK 0 0.87!2011-01-01T02:00:00Z Female UK 0 0.99!2011-01-01T02:00:00Z Female UK 1 1.53!...BITMAP INDEXEStimestamp publisher advertiser gender country ... click price! 2011-01-01T00:01:35Z Male USA 0 0.65! 2011-01-01T00:03:63Z Male USA 0 0.62! 2011-01-01T00:04:51Z Male USA 1 0.45! 2011-01-01T01:00:00Z Female UK 0 0.87! 2011-01-01T02:00:00Z Female UK 0 0.99! 2011-01-01T02:00:00Z Female UK 1 1.53! ...• -> [0, 1, 2] -> [111000]• -> [3, 4, 5] -> [000111]•Compress•CONCISE (http://ricerca.mat.uniroma3.it/users/colanton/concise.html)FAST AND FLEXIBLE QUERIESJUSTIN BIEBER ![1, 1, 0, 0]KE$HA ![0, 0, 1, 1]JUSTIN BIEBER !OR KE$HA ![1, 1, 1, 1]Rows POETS0JUSTIN(BIEBER1JUSTIN(BIEBER2KE$HA3KE$HAAVAILABILITY•Fault-tolerant•Rolling deployments/restarts•3 years, no downtime for update •Grow == start processes •Shrink == kill processesEXTENSIBLE•Extensibility model allows for signiﬁcant customizability •Deep Storage•Service Discovery•Extra queries•Extra aggregations•Extra column types/storage formats•Scan speed•~53M rows / second / core•Realtime ingestion rate•~20k events / second / node on “real” data•Highest benchmark so far: 250k/second on toy data •http://druid.io/blog/2014/03/17/benchmarking-druid.html•Metamarkets cluster•~10 trillion events (impressions, bids, etc.) •>200 TB•175 machines•90% query latency < 1s, 95% < 2s•300k/s event ingestion sustained“”DRUID IS OPEN SOURCEUSE CASES•Interactive dashboards of!•KPIs•Page Views, Impressions, Uniques, Revenue •Server Metrics•Request latency, etc•Network Metrics•Packets, bytes, etcUSE CASES•If you ever say the following, investigate Druid•“I wish I could slice and dice into this data”•“I just did X, I wish I could see if it was working in real-time” •“I wish I could see this data with more ﬁne-grained granularity” •“I wish I didn’t have to use pre-canned drill downs”DRUID IS OPENURL: http://druid.ioLanguage: JavaLicense: GPLv2!Used by ~10 companies in production Contributions from 40 people。