企业官网建设流程全解析

免费ppt模板的网站,网上商城怎样推广,fireworks做网站,图片交易网站源码前言 上文提到最近在搭建ClickHouse#xff0c;基本上可以正常使用了#xff0c;不过各项指标还得观察一段时间#xff0c;毕竟硬盘资源虽然相对便宜用多了也扛不住#xff0c;在选择将打点数据进行迁移的时候#xff0c;主要有 ClickHouse 和 Hive 两个备选项#xff0…前言上文提到最近在搭建ClickHouse基本上可以正常使用了不过各项指标还得观察一段时间毕竟硬盘资源虽然相对便宜用多了也扛不住在选择将打点数据进行迁移的时候主要有ClickHouse和Hive两个备选项在查询各自的特点后选择了ClickHouse碰巧得知自己最近刚接触的那个后台也是用的ClickHouse看来自己选的还不赖下面将一些对比信息进行展示或许在你用到时有更好的判断这里面涉及到一些专业词汇我都是边读边查尽量补充完整吧。各项对比一句话总结ClickHouse 实时 / 近实时 OLAP 查询引擎追求极致查询性能Hive离线数仓SQL on Hadoop追求超大规模数据的批处理能力OLAP 是 Online Analytical Processing 的缩写中文一般叫 联机分析处理主要用于数据分析、报表统计、多维度聚合查询、决策支持BI、数据仓库等读多写少通常是批量导入大量复杂 SELECT GROUP BY多数 OLAP 面向列存储只读取需要的列更适合聚合计算更高压缩率。常见 OLAP 引擎如下系统特点ClickHouse实时分析、列存、极快Hive基于 Hadoop离线分析ImpalaMPP低延迟 SQLDoris / StarRocks实时 OLAPGreenplum传统 MPP OLAPSnowflake云原生 OLAP一、整体定位对比维度ClickHouseHive核心定位实时 / 交互式分析离线批处理数据仓库OLAP / OLTPOLAPOLAP偏离线查询延迟毫秒 ~ 秒级秒 ~ 分钟级典型用途实时报表、监控、用户行为分析数仓建模、ETL、离线统计OLTP 是 Online Transaction Processing 的缩写主要是指业务交易高频 INSERT / UPDATE如 MySQL 订单表二、架构设计ClickHouseMPP 架构自带执行引擎 存储引擎无依赖 Hadoop 生态常见形态单机分片 副本ZooKeeper / ClickHouse Keeper架构简单查询路径短极致性能MPP 架构 是 Massively Parallel Processing大规模并行处理 的缩写是一种通过多节点并行执行同一条查询来提升性能的数据库 / 数据仓库架构。HiveSQL 抽象层本身不执行计算依赖底层引擎MapReduce最慢基于“Map映射”和“Reduce归约”的批处理模型依赖HDFS读写中间结果Tez基于DAG有向无环图的计算框架优化MapReduce任务链减少中间I/OSpark现在最常用基于内存计算和DAG执行引擎的通用框架支持批处理、流处理、SQL查询、机器学习等多种范式存储依赖 HDFS / 对象存储架构重扩展性极强查询启动成本高Hive本身不存储基础数据只存 元数据Metadata它不等于数据库只是SQL 解析 元数据管理 任务调度的集合存储和计算都依赖外部系统Hive 是“数据的管理员 翻译官”不是“仓库管理员”三、查询性能对比项ClickHouseHive单表扫描非常快列式向量化慢聚合 / GROUP BY极快中等Join快内存 Join较慢并发能力高适合 BI低不适合高并发启动开销几乎没有高任务调度实时查询ClickHouse 完胜超大离线计算Hive 更稳四、数据规模与扩展性维度ClickHouseHive单表规模TB ~ PBPB ~ EB横向扩展可以非常强成本偏高机器偏低HDFS 离线Hive 更适合「便宜地存很多数据」五、SQL 能力对比维度ClickHouseHiveSQL 标准非标准偏定制接近标准 SQL窗口函数支持但有限制支持全面子查询支持支持UDF有但不如 Hive 灵活非常成熟事务不支持有限不支持Hive 更“SQL 化”ClickHouse 更“性能化”六、存储格式 数据组织维度ClickHouseHive存储模型列式列式 / 行式常见格式MergeTree 系列ORC / Parquet索引稀疏索引、跳数索引分区 ORC 索引数据更新不擅长不擅长两者都不适合高频 UPDATE / DELETE七、数据写入能力维度ClickHouseHive实时写入非常适合不适合批量导入快快流式写入Kafka / HTTP一般ClickHouse 非常适合 日志 / 埋点 / 实时数据八、运维复杂度维度ClickHouseHive部署简单复杂依赖组件少多HDFS/YARN/Metastore成本偏高偏低运维门槛中高九、生态与集成维度ClickHouseHiveHadoop 生态弱强BI 工具非常友好一般实时分析强弱数仓体系可做明细 / ADSDWD / DWS / ADS十、典型应用场景ClickHouse 适合实时报表用户行为分析监控指标日志分析BI 查询高并发Hive 适合离线数仓数据清洗 / ETL历史全量分析低频、大规模统计十一、是否可以一起用最佳实践非常推荐组合使用典型架构数据采集 ↓ ODSHDFS / Hive ↓ 离线加工Hive / Spark ↓ 结果同步 ↓ ClickHouse对外查询 / BIHive 做「数据工厂」ClickHouse 做「查询引擎」十二、选型建议快速决策需求选择实时查询ClickHouse离线数仓HiveBI 报表ClickHouse超大规模历史数据Hive高并发分析ClickHouse低成本存储Hive使用ClickHouse的一点小记录配置文件主配置文件/etc/clickhouse-server/config.xml用户与权限配置/etc/clickhouse-server/users.xml数据目录/var/lib/clickhouse/ # ClickHouse 数据根目录由 path 指定 ├── data/ # 逻辑数据目录库/表路径通常是到 store 的软链接 ├── metadata/ # 表、视图、数据库的元数据.sql 建表语句 ├── metadata_dropped/ # 被 DROP 的表元数据暂存用于延迟清理 ├── store/ # 实际数据存储目录MergeTree 表的真实数据 ├── tmp/ # 查询/写入临时目录排序、聚合、INSERT 中间文件 ├── user_files/ # file() 表函数、INTO OUTFILE 可访问的目录 ├── dictionaries_lib/ # 外部字典使用的动态库.so 文件 └── access/ # RBAC 权限数据用户、角色、权限定义查询每个数据库占用的总空间SELECTdatabase,formatReadableSize(sum(total_bytes))AStotal_sizeFROMsystem.tablesGROUPBYdatabaseORDERBYsum(total_bytes)DESC;更详细的占用包含未压缩大小、索引大小等SELECTdatabase,formatReadableSize(sum(data_compressed_bytes))AScompressed_size,formatReadableSize(sum(data_uncompressed_bytes))ASuncompressed_size,formatReadableSize(sum(primary_key_bytes))ASprimary_key_sizeFROMsystem.partsGROUPBYdatabaseORDERBYsum(data_compressed_bytes)DESC;data_compressed_bytes真实磁盘占用data_uncompressed_bytes未压缩大小primary_key_bytes主键索引大小确认是哪些表占用了大空间SELECTdatabase,table,formatReadableSize(total_bytes)ASsizeFROMsystem.tablesWHEREdatabasesystemORDERBYtotal_bytesDESC;最近发现批量导入数据后system数据库比我的业务数据库都大查询后显示trace_log表特别大据说可以直接删TRUNCATE TABLE system.trace_log;这一点我还在实践中结论ClickHouse 是接近实时 OLAP 的查询引擎追求极致查询性能Hive通常作为离线数仓SQL on Hadoop追求超大规模数据的批处理能力选择合适的工具做合适的事你就是一个巧匠选择合适的人做合适的事你就是一个领导 反爬链接请勿点击原地爆炸概不负责人生若只如初见何事秋风悲画扇。等闲变却故人心却道故人心易变。