oracle查询一天内的数据_基于特定数据集的Oracle、ClickHouse、ES测试报告

本文对比了Oracle、ClickHouse及ElasticSearch在特定数据集上的表现,包括数据存储量和查询速度。结果显示,ClickHouse在数据压缩和查询速度方面表现出色。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

d490306036a521f2b71e09eb27c8eaba.png

基于特定数据Oracle、ClickHouse、ES存储比较

edd71aa65631dcbe5c4ac75b745048d6.pngd490306036a521f2b71e09eb27c8eaba.pngd490306036a521f2b71e09eb27c8eaba.png

笔者在工作中遇到一种情况,有一批数据需要和其他表进行各种复杂计算、并表操作,输出统计值。一般情况,类似场景都会使用Oracle视图进行处理。但本次场景发现做关联和计算后,使用视图查询效率非常低,甚至达到了无法忍受的地步(有时1min以上)。于此同时,现在OLAP数据库比较火,所以就特定场景从效率和存储上选取Oracle、ClickHouse、ElasticSearch做了一次简单的对比。

edd71aa65631dcbe5c4ac75b745048d6.pngedd71aa65631dcbe5c4ac75b745048d6.png

01

测试集说明与准备

由于本身业务场景是一个并表操作,使用的测试数据集有一个特点,即首先有近30列,其次每行数据基本上只有个别字段有差异,多数列重复度比较高。数据集是1000条原始数据,通过视图构建初350w条数据。

数据样例(类似只有个别几列数据不相同)

1aaa......11.5
2aaa......13
3aaa......12
4bbb......130
5bbb......112

测试主机配置

均是虚拟机 4c 8g 500G

2e1244193ece398d345f50ee2cda58bd.png

02

测试步骤

一、Oracle 测试

1、数据准备

从vw_test_list视图中导入数据到实体表test_detail中。

Insert into test_detail select * from vw_test_list t ; 

2、查看存储大小

select * from 

(select t.segment_name, t.segment_type, sum(t.bytes / 1024 / 1024) "占用空间(M)"

from dba_segments t   

where t.segment_type='TABLE' 

group by OWNER, t.segment_name, t.segment_type) t

where t.segment_name='test_detail'

3、测试查询速度

select * from test_detail t where t.test_title like '%测试数据集AAA%'

87387ef9e7545851add0082d5c807c00.png

二、ClickHouse测试

1、构建数据表

注意点:

1、clickhouse客户端对回车敏感,所以如果在文本中编辑完成后,需要替换掉’\n’

2、Clickhouse使用mergetree引擎时需要指定一个date类型的字段定义主键。

2、数据加载

从oracle中导出数据,使用click-client进行数据导入

cat data.csv | clickhouse-client --format_csv_delimiter="|" --query="INSERT INTO test_detail FORMAT CSV";

3、查看占用空间

select table as "表名",sum(rows) as "总行数",formatReadableSize(sum(data_uncompressed_bytes)) as "原始大小",formatReadableSize(sum(data_compressed_bytes)) as "压缩大小",round(sum(data_compressed_bytes) / sum(data_uncompressed_bytes) * 100, 0) "压缩率" from system.parts where table in('test_detail') group by table;

4、测试查询效率

SQL与Oracle一致

90461913020f06431abcb8e533df092a.png

三、ElasticSearch测试

1、数据导入

使用Logstash进行数据导入

2、查看占用空间

使用 Get 请求

http://localhost:9200/_cat/indices?v

3、测试查询效率

使用Get请求

http://localhost:9200/dwzq/_search?pretty=true&size=2000

param:

{

    "query": {

        "match": {

            "WARNING_TITLE": "%测试数据集AAA%"

        }

    }

}

2e1244193ece398d345f50ee2cda58bd.png

03

结果比较

整体对比数据存放量与查询速度:                                                            

OracleClickHouseElasticSearch
数据存放量1.5g45m1.1g
查询速度12.219s0.527s0.298s

04

结论与总结

本次测试只是针对特定数据集进行测试,不具备普遍性,且也没有对这oracle、clickhouse、es做特定优化,所以只能大致反应出一些结论。整体面对大宽表,clickhouse的数据压缩能力还是很强大的。同时查询速度也可以接受。在测试过程中发现,clickhouse占用机器内存比较多。

clickhouse号称分析能力杠杠的,后期会将原oracle上的分析、并表操作迁移至clickhouse并进一步对比分析。

2e1244193ece398d345f50ee2cda58bd.png
<think>我们正在设计一个大数据平台底座,需要集成多个组件以满足达美乐公司的需求。以下是一个分层的设计思路,确保高效、可扩展、可监控和可维护。###1.基础设施层-**硬件资源**:使用云服务器或物理机,建议采用分布式架构,至少3个节点起步(可根据规模扩展)。- **资源调度**:-**YARN**:负责集群资源管理和作业调度。YARN支持动态资源分配,适合批处理和实时计算任务。- **Kubernetes(可选)**:如果需要更灵活的容器化部署,可考虑K8s,但YARN在Hadoop生态中更成熟。###2.数据存储层-**HDFS**:作为核心分布式文件系统,存储原始数据、中间数据和结果数据。支持高吞吐量的批处理场景。- **对象存储(可选)**:如S3、OSS,用于存储备份或冷数据,降低成本。 -**分布式数据库**:- **HBase/Kudu**:适用于随机读写和实时查询的场景(如订单状态更新)。-**TiDB (可选)**:如果需要强一致性的分布式关系型数据库,可替代部分MySQL场景。 ###3.数据计算层- **批处理**:-**Spark**:高性能批处理,支持SQL、机器学习等。与HDFS/YARN深度集成。- **实时流处理**:- **Flink**:低延迟、高吞吐的流处理引擎,支持事件时间处理、状态管理,适用于实时监控、实时ETL等。 -**交互式查询**:-**ClickHouse/StarRocks**:用于OLAP分析,支持高并发快速查询。StarRocks在复杂查询和多关联上性能更优。 ###4.数据同步层-**批量数据同步**:-**DataX**:支持异构数据源(如MySQL到HDFS/Hive)。-**Sqoop**:专为Hadoop设计的关系型数据库同步工具(如Oracle到Hive)。 -**实时数据同步**:-**Flink CDC**:基于Flink的Change DataCapture,实时捕获数据库变更(如MySQLBinlog)。-**Canal/Maxwell**:也可用于实时数据同步,但需配合Kafka传输。 ###5.任务调度层- **DolphinScheduler**(优先选择):-优势:可视化DAG、多租户、支持多种任务类型(Shell、SQL、Spark、Flink、DataX等)、高可用、易扩展。-部署:支持Master/Worker分离,通过Zookeeper协调。 -**Oozie** (作为备选或特定场景):-优势:与Hadoop生态紧密集成,适合简单的定时任务链。-缺点:配置复杂,可视化差。 >**建议**:以DolphinScheduler为主,Oozie仅用于遗留任务兼容。###6.OLAP分析层-**ClickHouse**:列式存储,适合单聚合查询,写入速度快。- **StarRocks**:新一代MPP架构,支持高并发、复杂查询(多Join、子查询),兼容MySQL协议。 -**向量数据库** (非结构化数据检索):-**Milvus/FAISS**:用于存储和检索向量数据(如图片、文本嵌入),支持相似度搜索。 ###7.监控与运维层-**监控**:- **Prometheus+Grafana**:实时监控集群资源(CPU、内存、磁盘)、服务状态(YARN、HDFS、Flink等)。-**Zabbix**:补充监控硬件和网络指标。- **日志**:- **ELK(Elasticsearch,Logstash,Kibana)**:集中收集和分析各组件日志。- **元数据数据治理**:-**ApacheAtlas**:管理数据血缘、元数据,支持审计和合规。- **安全**:- **Kerberos +Ranger**:实现身份认证和细粒度权限控制。###8.可扩展性设计- **水平扩展**:-存储层: HDFS/Kudu支持动态添加DataNode。-计算层:Spark/Flink任务可随YARN资源池动态扩容。- OLAP层: StarRocks支持动态增删节点。 -**组件解耦**:-通过Kafka作为数据总线,解耦生产者和消费者(如实时数据流)。-使用微服务架构部署管理组件(如DolphinScheduler)。###9.部署架构示例```+-----------------++--------------++-----------------+|数据源|----->|数据同步层|----->|数据存储层|| (MySQL,日志等)|| (DataX,FlinkCDC)|| (HDFS, HBase)|+-----------------++--------------++-----------------+|v+-----------------++--------------++-----------------+|任务调度层|<---->|计算引擎|----->| OLAP分析层| |(DolphinScheduler)|| (Spark,Flink)|| (StarRocks,CH)| +-----------------++--------------++-----------------+|v+-----------------++--------------+|向量数据库|<-----|非结构化处理| |(Milvus)|| (Flink/模型)| +-----------------++--------------+ ```###10.关键注意事项1. **版本兼容性**:确保各组件版本兼容(如Hadoop3.x支持Flink1.14+)。 2. **高可用**:- HDFS NameNode HA、YARNResourceManagerHA。-DolphinScheduler多Master+多Worker。3.**数据一致性**:-批处理用Spark确保Exactly-Once。-实时流用FlinkCheckpoint机制。4.**成本优化**:-冷热数据分离(HDFS分层存储)。-自动伸缩集群(根据负载动态调整YARN节点)。>**总结**:该设计覆盖了从数据接入到分析的全流程,且通过分层和组件化保证了可扩展性。下一步可细化各模块配置和性能调优。 §§相关问题§§1.如何确保HDFS和YARN的高可用配置? 2. DolphinScheduler和Oozie在混合调度环境中的协同工作策略是什么?3.Flink实时流处理如何与StarRocks高效集成?4.向量数据库(如Milvus)如何集成到现有大数据平台中?</think>### 大数据平台底座设计方案 为支持达美乐门店扩张和多样化数据需求,设计一个分层、模块化的大数据平台底座,核心思路如下: --- #### **一、架构分层与组件集成** 1. **资源管理层** - **核心组件**:`YARN`(统一资源调度) + `Kubernetes`(容器化扩展) - **功能**: - 通过YARN管理Hadoop生态资源(CPU/内存),支持动态扩容[^1]。 - 使用K8s部署无状态服务(如Flink、ClickHouse),实现跨集群扩展。 2. **数据存储层** - **结构化数据**: - `HDFS`(主存储):原始数据、批处理中间结果。 - `TiDB`(事务型数据):门店订单、库存等ACID场景[^1]。 - **实时分析**: - `ClickHouse`:高并发聚合查询(如销售报)。 - `StarRocks`:替代ClickHouse处理多关联查询[^1]。 - **非结构化数据**: - **向量数据库**(如`Milvus`):存储门店图像/文本特征向量,支持相似性检索。 3. **数据同步层** - **批量同步**: - `DataX`:异构数据源迁移(MySQL → HDFS)[^4]。 - `Sqoop`:关系型数据库与Hadoop间数据传输(Oracle → Hive)[^2]。 - **实时同步**: - `Flink CDC`:捕获数据库变更流(如MySQL Binlog),写入Kafka/HBase。 4. **计算引擎层** - **批处理**:`Spark SQL`(复杂ETL、机器学习)。 - **流处理**:`Flink`(实时监控门店订单流、库存预警)。 - **交互式查询**:`Presto`(跨HDFS/Hive/ClickHouse即席查询)。 5. **任务调度层** - **主调度器**:`DolphinScheduler`(核心优势): - 可视化DAG编排,支持Spark/Flink/DataX等任务类型[^3][^4]。 - 多租户+资源隔离,保障门店任务优先级。 - **辅助调度器**:`Oozie`(兼容遗留Hive任务)。 - **协同策略**:DolphinScheduler调用Oozie作业,统一监控日志。 6. **监控运维层** - **基础设施监控**:`Prometheus`(实时指标)+ `Grafana`(仪盘)。 - **任务审计**:`Apache Atlas`(元数据血缘追踪)[^1]。 - **日志管理**:`ELK`(集中采集分析)。 --- #### **二、关键设计原则** 1. **可扩展性** - 存储层:HDFS通过添加DataNode水平扩展;TiDB分片扩容。 - 计算层:YARN队列按门店业务划分,资源按需分配。 2. **高可用保障** - HDFS NameNode HA + Zookeeper选主。 - DolphinScheduler多Master+多Worker,避免单点故障[^4]。 3. **效率优化** - **数据湖加速**: - 使用`Hudi`/`Iceberg`管理增量数据,支持Spark/Flink高效更新。 - **OLAP查询**: - StarRocks物化视图预计算门店指标。 4. **安全与治理** - `Kerberos`认证 + `Ranger`权限控制(HDFS/Hive访问策略)。 - DolphinScheduler对接LDAP实现用户统一认证[^3]。 --- #### **三、部署架构示例** ```mermaid graph LR A[数据源] -->|DataX/Sqoop/FlinkCDC| B(HDFS + TiDB) B --> C{计算引擎} C -->|批处理| D[Spark] C -->|流处理| E[Flink] D & E --> F[OLAP存储] F --> G[ClickHouse/StarRocks] F --> H[向量数据库] I[DolphinScheduler] -.->|调度| C I -.->|调度| A J[Prometheus/Grafana] -->|监控| C K[Atlas] -->|血缘追踪| F ``` --- #### **四、实施建议** 1. **分阶段迁移**: - 先部署HDFS+YARN+DolphinScheduler+Spark基础层,再扩展Flink+StarRocks。 2. **性能压测**: - 模拟千家门店并发写入,验证TiDB和Kafka吞吐量。 3. **灾备方案**: - HDFS数据定期同步至对象存储(如S3)。 > **总结**:该设计通过模块化组件和分层解耦,满足高吞吐批处理、实时分析、非结构化检索需求,且DolphinScheduler为核心调度器显著提升运维效率[^3][^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值