从使用的角度看 ByConity 和 ClickHouse 的差异

自 ClickHouse Inc 宣布其重要新功能仅在 ClickHouse Cloud 上开放以来,一些关注 ByConity 开源的社区小伙伴也来询问 ByConity 后续开源规划。为回答社区疑问,我们将之前分享的关于 ByConity 与 ClickHouse 相关功能对比的 webinar 整理为文章,并更新 ByConity 0.2.0 所发布最新功能与 ClickHouse 对比内容,帮助社区小伙伴了解 ByConity 开源社区规划与进展。

ByConity & ClickHouse 使用视角对比

我们整理了一些从实用角度看 ClickHouse & ByConity 的异同点,与大家分享:

  1. 技术架构和核心组件看两者各自特点
  2. 数据库的基本操作差异:库表创建、数据导入、数据查询等方面两者有什么异同
  3. ByConity 的分布式事务
  4. ByConity 特殊的表引擎及其优势

架构和组件

ClickHouse 的架构及组件

ClickHouse 是典型的 MPP 架构,节点对等,所有的功能都被放在 ClickHouse server 组件中。当部署 ClickHouse 集群时,主要是把 ClickHouse server 部署在一组物理机上。

分布式表 & 本地表

ClickHouse 提出了分布式表的概念,当 Client 做查询时,首先连接节点找到分布式表,通过 sharding key 的定义以及集群的配置知道分布式表对应的本地表及分布节点。再通过两阶段的执行,先到节点上做本地表的查询,再把查询结果汇聚到分布式表,然后再返回给客户端。

Replicas

ClickHouse 提供数据复制的能力,通过对每一个本地表配置 Replica 进行数据复制。不管是分布式的执行,还是数据的复制,都需要 Coordinator 进行节点之间的通信,包括任务的分发等。

Zookeeper & ClickHouse Keeper

ClickHouse 之前通过 Zookeeper 提供 Coordinator 能力,部署一个 ClickHouse 集群需要同时部署一个 Zookeeper 集群来承担对应的工作。后来发现 Zookeeper 集群存在很多局限性,在大规模分析型数据查询中会碰到很多性能瓶颈和使用问题,因此进行了一定改进,用 C++ 和 raft 协议实现了 ClickHouse Keeper 组件。ClickHouse Keeper 提供两种部署方式,既可以像 Zookeeper 一样作为单独的集群去部署,也可以放在 ClickHouse server 里跟 ClickHouse server 一同部署。

ByConity 的架构及组件

ByConity 是存算分离的架构,整体架构主要分为三层:服务接入层、计算层和云存储层。

服务接入层

由一组 server 和共享的服务组件组成,包括 TSO、Daemon Manager、Resource Manager。

  • Server
  • 服务接入层的 server 是做所有查询的入口,当 Client 连接 server 时,server 会先做查询的前处理,包括 SQL 解析、查询优化,生成 Query Plan。每个 Query Plan 由多个 PlanSegment 组成,server 负责把 PlanSegment 下发给 worker 做具体计算。
  • 查询过程中会涉及到元数据的管理,比如需要知道库表、字段的定义及统计信息,如 Part 的信息等等,server 就会跟元数据的存储交互。元数据在 ByConity 目前采用 Foundation DB 来实现。
  • TSO:TSO(Timestamp oracle)是提供全局唯一单调递增的时间戳。在分布式事务的时候非常有用。在后面的事务部分将会介绍。
  • Daemon Manager:用来调度和管理任务。ByConity 的分层架构涉及到管理节点,对应提出了后台任务的概念,如 merge、实时数据导入时 Kafka 的 consumer 等,都作为后台任务来进行。后台任务的集中管理和调度都由 Daemon Manager 来实现。
  • Resource Manager :顾名思义用来管理资源。计算层的 Virtual Warehouse 以及 worker 都由 Resource Manager 管理,分配查询和数据写入应该由哪个 worker 执行;Resource Manager 同时做一定的服务发现,如有新的 worker 加入或新的 Virtual Warehouse 创建时,Resource Manager 能够发现。

计算层

  • 计算层由一个或者多个 Virtual Warehouse (计算组)构成,执行具体的计算任务。一个 Virtual Warehouse 由多个 worker 构成。
  • 计算层为无状态的一层,为了查询的某些性能,这里会有 Disk 的参与,把一些数据缓存在 worker 本地做 disk_cache。在 ByConity 的查询中有冷查(第一次查询)和热查的区别,冷查需要从远端的云存储把数据拉到 disk_cache,后续查询可以直接重用 disk_cache 的数据,查询速度更快。

云存储层

  • 采用 HDFS 或 S3 等云存储服务作为数据存储层,用来存储实际数据、索引等内容。

ByConity 的部署要求

在部署 ByConity 时,不同的组件有不同的硬件要求。对一些共享服务,如 TSO、Daemon Manager 和 Resource Manager,其资源需求相对较低且比较固定;server 和 worker 所需资源相对较多,尤其是 worker,需要根据不同的查询场景部署到不同的硬件规格上。

ByConity 社区推荐使用 Kubernetes 来部署,可通过官方提供的工具和脚本来实现自动化操作,集群后期的运维管理也更方便。具体的部署方式可在文档中查看:https://byconity.github.io/zh-cn/docs/deployment/deploy-k8s

由于部署 ByConity 也包括元数据以及远端的存储,即使部署测试环境也有前置要求,即 HDFS 和 Foundation DB。如本身已有环境,可直接进行配置使用。如果没有,可参考对应的部署文档进行设置。

ByConity 的架构特性

ByConity 的架构演进源于字节在使用 ClickHouse 过程中所遇到的痛点。ByConity 的组件虽然比较复杂,但设计这些组件有其对应的优势。

资源隔离

资源隔离是一个业务高速发展中集群环境变复杂的过程中不可避免的问题。资源隔离有多个层面。

  • 租户隔离,在 ToB 的业务上指多租户;在企业内部一般指各个业务线之间在共享集群上的业务隔离。不同的业务线之间通常希望独占部分系统资源,在进行分析、查询这些工作时可以相互不影响。这里必然也伴随着计算资源的隔离
  • 读写分离,由于读操作和写操作对硬件的要求、发生的时间以及热点都不一样,通常希望读写之间也不要互相影响,能够分开用不同规格的资源去跑。
  • 冷热分离,一般指冷数据和热数据的存储能够用不同的硬件资源分离,一方面可以减少成本,另一方面也可以让冷热不同的查询之间不受影响。比如说如果有缓存的话,冷查询不会冲掉热查询的缓存,进而对热查询造成性能影响。

ClickHouse 的资源隔离

ClickHouse 没有在架构层面对资源隔离做专门的设计,因此 ClickHouse 在做上述这些资源隔离时需要单独的方案。

读写分离可以通过精准配置 replica(部分专门负责读,部分专门负责写),结合 load balance 策略以及集群的部署方式做一定的区分。但此方案有一定局限性,一是运维成本较高,需要手动精准控制。二是读写分离的资源不方便重用,专门用来负责写的 replica,在读请求高峰时无法 serve 读请求。

冷热分离可以通过 TTL,TO DISK,TO VOLUME 的功能,把冷数据和热数据分别指定不同的存储介质去存储。存储方面能够带来成本节约的好处,但是在计算层面依然使用同样的资源,无法做到分离。

ByConity 的资源隔离

ByConity 可以通过 Virtial Warehouse 部署和使用实现多级资源隔离。由于 Virtial Warehouse 是无状态的,可以针对不同业务、不同场景按需创建。Virtial Warehouse 的创建操作是无感的,所包含的 worker 的创建也比较灵活。不同的 Virtial Warehouse 之间资源独占,可以比较轻松地实现上述隔离。

  • 租户隔离:不同的业务线可以根据各自需求创建不同的 Virtial Warehouse,对计算资源可以天然做到物理隔离。计算资源也可以在计算热点不同时做调整,实现成本控制和节省。
  • 读写分离:ByConity 的设计要求用户在部署时指定好读和写操作分别使用哪个 Virtial Warehouse,系统会自动地根据不同的读写请求把计算转发到不同的 Virtial Warehouse 中,其天然具备读写分离的能力。
  • 冷热分离:从存储上来讲,因为 ByConity 存算分离,所有的数据都会落在远端存储中,不需要做数据冷存介质和热存介质之间的区分,所有的数据都会有完整的一份在远端存储中。由于 disk_cache 的存在,热数据有缓存加速,且所有热数据的载入不需要用户介入,都是自动计算的过程,可以根据查询把所需要的热数据载入到 worker 本地。

集群扩缩容

扩缩容是在业务不断增长的场景中必须要考虑的话题。业务在爆发式增长的过程中,可能每两周就需要对集群进行一次扩容,每次扩容都需要伴随很多操作,带来很多的成本。因此扩缩容不得不考虑。

ClickHouse 的扩缩容

ClickHouse 架构层面未专门考虑扩缩容。ClickHouse 的扩缩容需要通过一定手段来实现:

  • 扩容副本,通过使用新的节点来部署新的 ClickHouse server,并把副本转移到新的节点上。但是副本扩容之后需要一定的时间进行复制,并且需要对复制的成功率及结果进行校验。这些操作都需要运维手动去做,没有专门的功能支持。
  • 扩容分片,通过增加 Shard 把新的分片部署到新的节点。这种方式会导致数据无法再均衡,即老的数据依然落在老的分片上,在进行具体查询时不同节点上的数据分布不均,需要进行数据再均衡。而数据再均衡的过程在 ClickHouse 中无法自动实现。

ByConity 的扩缩容

ByConity 是基于存算分离的无感弹性扩缩容,通过 Virtial Warehouse 和 worker 来实现。

  • 业务隔离:Virtial Warehouse 可以根据不同的业务线去创建,其创建和销毁均无感。
  • 负载隔离:每个 Virtial Warehouse 可以根据业务量的变化调整 worker 的数量。具体来说:一些组件如 Resource Manager 可以自动发现新增加到集群中的 worker,并自动实现数据再均衡。

数据库的基本操作

库表创建

ClickHouse

  1. SQL 标准:ClickHouse 的 SQL 标准为 ClickHouse SQL,它从 ANSI SQL 演化而来,但有很多项不符合 ANSI SQL 标准,如果从其他的数据库迁移到 ClickHouse 需要有较多修改。
  2. 支持协议:ClickHouse 支持的协议主要是 TCP 和 HTTP,client 和 driver 使用 TCP 协议,也有一些工具和专门的 driver 使用 HTTP。
  3. 客户端:ClickHouse 本身就有 ClickHouse client,同时对于不同的语言也会有驱动性,比如 clickhouse-jdbc,clickhouse-go。
  4. 表引擎:在创建库表的时候,ClickHouse 有 MergeTree 家族表引擎,要为每一个表去指定所用的表引擎,用得最多是 MergeTree 以及 MergeTree 衍生出来的 MergeTree 家族,如 replacing MergeTree,aggregated MergeTree 等。

ByConity

  1.  SQL 标准: ByConity 能够兼容 ClickHouse 原生的 SQL 标准,在 SQL 标准上提供了 dialect 的配置。除了可以使用 ClickHouse 原生的 SQL,ByConity 还提供了 ANSI SQL 的方式。ANSI SQL 不是严格意义上完全符合 ANSI 标准的 SQL,考虑到 ClickHouse SQL 与 ANSI 有比较多的 gap,ByConity 会把一些不符合标准的地方尽量做到符合 ANSI SQL 标准。ANSI 的 dialect 可以看作是比 ClickHouse SQL 更加符合标准的 SQL 方式。
  2. 支持协议:ByConity 原生支持 ClickHouse 的 TCP 和 HTTP 协议。
  3. 客户端:除了 ClickHouse 支持的客户端以及驱动器,ByConity 有专门的客户端用于支持自己的配置和参数。
  4. 表引擎:ByConity 提供了合一的表引擎 CnchMergeTree,分布式的执行过程都封装在里面,可以替代 ClickHouse 原生 MergeTree 家族多个 MergeTree 的能力,如 by default 的 MergeTree、replacing MergeTree,包括支持唯一键也在 CnchMergeTree 中封装。
  5. Virtial Warehouse 及计算组配置:创建 ByConity 库表有专门的设置,可以通过 DDL 为库表的读和写指定默认的 Virtial Warehouse。读写分离也是通过此操作实现的。

数据导入

ClickHouse

ClickHouse 的数据导入包括基础的 insert 操作,外部文件的导入 insert into … infile… 。 另外 ClickHouse 提供了很多的外表引擎,可以利用这些外表引擎创建外表,通过 insert select 从外表把数据导入 ClickHouse。ClickHouse 多用在实时数仓场景,在 ClickHouse 的数据导入中,实时数据导入是一个比较重要的话题。ClickHouse 专门的表引擎—— ClickHouse Kafka 在 ClickHouse 中用得非常多。

ByConity

ByConity 对于基础 insert、外部文件导入以及外表数据导入与 ClickHouse 相同,语法上也一样。此外,ByConity 提供了更多的数据导入方式,包括一个数据导入工具,PartWriter。

PartWriter

可以集成在 Spark 的流程处理中,不通过 ByConity 的表引擎,直接将数据文件转换为 ByConity 能够识别的的 parts 文件。

后台任务

在数据导入时有很多后台任务需要管理,如数据导入之后的 merge 和 mutate 任务,Kafka 表引擎实时消费任务等。通过操作语句跟后台任务进行交互,监控后台任务的执行情况及系统表的性能指标,能够实现对后台任务的精准控制。

实时数据消费

ClickHouse 的 Kafka 表引擎

ClickHouse 做 Kafka 的数据导入会创建以下几个部分:

  • 用 Kafka 表引擎创建 Kafka 外表,指定从哪个 Kafka 的集群消费数据,整个 consumer 如何配置
  • 定义一个 ClickHouse 的 MergeTree 表,作为数据真正写入的表
  • 定义一个 Materialized View,把上述两个部分连接起来

Kafka 的数据导入在创建以上三个部分之后会在后台运行,之后不停地把数据从 Kafka 消费出来写入到目标表。

ByConity 的 Kafka 表引擎

ByConity 从基本用法跟 ClickHouse 一致,从 Kafka 消费数据也是创建外表、CNCH MergeTree,并创建一个 Materialized View 把两部分连接起来。但是 ByConity 在具体操作中跟 ClickHouse 存在差异。

Kafka 消费模式方面的差异:

  • ClickHouse 在 Kafka 消费时使用 High Level 的消费方式。这是一种自动化程度更高的消费方式,可以动态分配 Kafka 的 Partition 到 Consumer 的 instance。当发现有 Consumer 挂掉或有新的 Consumer 加入时,可以自动 Rebalance,把 Partition 进行重分配。ClickHouse其 MPP 的架构更加适合 High Level 消费方式,可利用 Kafka 进行 Rebalance。但是这种方式很难保证 Exactly Once,因为在 Rebalance 过程当中会由失败引起数据的重复消费,如果这些重复消费在目标表中没有去重手段,肯定会造成数据重复,无法保证 Exactly Once。
  • 在此消费方式下,Partition 经常 Rebalance 到不同的 Consumer 节点,在 ClickHouse 中则会 Rebalance 到不同的 ClickHouse shard,一方面运维排查比较困难,另一方面很难控制 Partition 具体会落到哪些 shard 上。

如何保证 Exactly Once

ByConity 采用 Low Level 的消费模式:Kafka 消费当中的 assign 静态地分配 Partition 到具体的 consumer instance,这也是 ByConity 多层架构的便利性,可以由 server 控制 Partition 的分发,由worker 执行真正的 consumer instance 的消费操作。

本身具有调度能力的产品更倾向于用 Low Level 的消费方式,如 Flink 和 Spark streaming。此方式的一个最大的好处是不会造成数据重复,尽量保证 Exactly Once,精准控制哪个 Partition 由哪个 consumer 消费。同时在提交 offset 时,也会让数据写入和 offset 的提交有事务保证。在线上运维排查及数据审计时也更加方便,Partition 不会乱飘,如发现 Partition 有比较大的 LAG 也有迹可循,直接从 server 上找到具体的 worker,进而找到具体失败的原因。

数据查询

ClickHouse

ClickHouse 对复杂查询的支持并不完整,它采用两阶段聚合的方式,即分布式表和本地表。在分布式表把查询分发到本地表,在本地表做第一个阶段的聚合之后再聚合到分布式表做第二阶段的聚合,也称为scatter/gather 的模式。

ClickHouse 提供了 GLOBAL JOIN 和 GLOBAL IN,类似于 Broadcast Join 的方式。在一个大表去 join 小表的时候,可以让小表的数据先一步被计算出来,然后分发到大表去做 local 的 join。ClickHouse 对复杂查询支持有限,多表 join 一直是 ClickHouse 的痛点。使用 ClickHouse 需要在前期尽量把数据打平成大宽表。

ByConity

ByConity 的复杂查询通过优化器来实现,优化器对复杂查询有非常大的性能提升,推荐默认打开。ByConity 引入了多阶段的查询,首先由优化器生成执行计划并分派到各个 worker,进而支持比较复杂的查询,如节点之间有数据的消费能力的查询。

优化器的工作需要统计信息支撑,因为它里面有 CBO,需要去手动地维护统计信息。ByConity 提供了对统计信息操作的手段,包括 create Stats,drop stats,以及去查看统计信息的手段。具体内容可以参考优化器的分享:ByConity Monthly Webinar-20230321-优化器原理解析与性能差异_哔哩哔哩_bilibili

分布式事务

为什么要支持事务

在分布式系统中,不同的系统对事务支持程度不同,一般考虑 ACID 四个特性。OLTP 数据库对事务的要求较高,一般支持多种事务的隔离级别,且会支持比较高的级别,如 Serializable。但是一些 NO SQL 的数据库,为了达到极致性能,会把 ACID 的部分特性做得相对较弱。

OLAP 的环境中很多时候并不特别强调事务的重要性。但在真正的业务中,即使对 OLAP 系统,事务也是非常重要的。其中一个关键是保证数据的准确性,有些系统虽然能够保证最终的一致性,但在过程中会出现数据不准确的情况。对实时性要求比较高的系统,数据不准确会带来不好的用户体验。

此外在使用 OLAP 系统时,因为数据不都是一次性导入的,经常会有数据的增量更新,在这种需求里面也需要事务操作。

ClickHouse

ClickHouse 虽然有分布式的查询,但是并不支持分布式事务,本地事务支持目前仅针对单次写入在 max_insert_block_size 以内的数据有事务保证。

此种事务保证对于大部分在 ClickHouse 里面真正跑的查询是不够的,ClickHouse 社区目前正在实现事务增强,如提供 MVCC 和 RC 的隔离级别,支持多 insert 和多 select 组成的交互性事务。此功能还目前还在 experimental 阶段,需要特殊配制才能使用。即使最终完全实现也还是一个 local 的事务,只针对本地表有事务保证,无分布式事务的规划。

ByConity

ByConity 进行了比较完整的分布式事务实现,其 ACID 的特性保证如下:

  1. 原子性(Atomicity):ByConity 在各种情况下都会保证原子性,包括掉电,错误和宕机等各种异常情况。
  2. 一致性(Consistency ):保证数据库只会从一个有效的状态变成另外一个有效的状态,不会有中间状态被看到,任何数据的写入必须遵循已经定义好的规则。
  3. 隔离性(Isolation ):ByConity 为用户提供的是 read committed(rc)隔离级别的支持。未完成的事务写入对于其他事务是不可⻅的
  4. 持久性(Durability ):ByConity 采取的存储计算分离结构,利用了成熟的高可用分布式文件系统或者对象存储,保证成功事务所提交数据的高可用。

另外,ByConity 通过两个比较重要的组件来进行事务保证。

  • Foundation DB:通过 Foundation DB 的能力做事务中的必要操作。Foundation DB 本身具有的原子性操作及CAS的操作在事务的执行过程中有帮助。
  • Timestamp Oracle(TSO):通过 Timestamp Oracle 提供全局唯一时间戳,时间戳是单调递增的,可以用来做事务的 ID。

在事务的具体实现中,这是一个典型的两阶段提交的实现。第一个阶段写入事务记录,包括写 undo buffer,远端存储,提交元信息等。第二个阶段真正提交事务,并更新事务记录的提交时间。在事务成功和失败的时候,用 undo buffer 去做一些清理。

特殊的表引擎

Unique 表引擎

很多分析型数据库有 Upsert 的需求,如果表中存在已有数据,希望覆盖掉前面的重复数据,因此需要唯一键的保证来进行判读。ClickHouse 很难保证数据插入的唯一性。ClickHouse 提供的 replacing MergeTree 可以在一定程度上达到此效果,但 replace MergeTree 不保证键一定是唯一的,因为它是异步,要在 merge 时才能做数据的覆盖。如果 merge 一直不做或者做得比较晚则会出现重复数据的状态,而这种状态在很多场景下不允许出现。因此需要一个能够保证键的唯一性的场景来做 Upsert 的支持。

ByConity 的实现方式

ByConity 对 Upsert 支持中,行级的 update 操作被转换成 delete + insert。行级 delete 通过 DeleteBitmap 实现,DeleteBitmap 存放了该 part 中所有被删除的行的行号。具体的增删改查都会围绕 DeleteBitmap 操作,比如 insert 时修改 Bitmap 对比版本信息;在 select 之后,根据 DeleteBitmap 当中的标识去 filter 数据。

为了加速执行,ByConity 对 Unique Key 创建了 index。因为在 Bitmap 中放的是行号,从 key 到行号需要索引,通过 Unique Key Index 可以实现 Key 到行号的快速定位。

唯一性的保证也需要控制写冲突的发生。在并发的情况下,如果有不同的写请求过来,需要加锁去保证写冲突不会发生。从上可知,Unique 表引擎需要一定代价,是在真正需要此场景的表里才会需要用到的表引擎。

Bucket 表

Snowflake 提出了 cluster table 的概念,即当一个表的数据量比较大时能够对表的数据进行再分片。即使是同一个 Partition 中的数据,也希望能够再分片,增加整个系统的并行度,并利用分片的 key 做性能优化。

Bucket 表在 ByConity 中需要以下语句来实现:

  1. 在 DDL 指定 cluster key,以及把表建成多少个 Bucket

CREATE TABLE t(...)

CLUSTER BY (column, expression, ...) INTO 32 BucketS

  1. Bucket 后期可通过 ALTER TABLE修改

ALTER TABLE t CLUSTER BY (column, expression, ...) INTO 64 BucketS

  1. 也可以把 Bucket 表整个 drop 掉

ALTER TABLE t DROP CLUSTER

需要使用 Bucket 表的场景

首先表的数据要足够大,一个 Partition 的数据要产生足够多且比较大的 Parts,⾄少需要显著多于 worker 的数量,不至于产生很多的小文件。另外要有一些性能优化的场景,有助于查询中性能的提升。

使用 Bucket 表的收益

  • 针对 cluster key 的点查可以过滤掉大部分数据,降低 ΙΟ 量以获得更短的执⾏时间和更⾼的并发QPS
  • 针对 cluster key 聚合计算,计算节点可以在数据子集进行预计算,实现更小的内存占用和更短的执行时间
  • 在两张表或多张表 join 时,针对 cluster key 可以获得 co-located join 的优化,极大程度上降低 shuffle 的数据量并得到更短的执行时间,提升查询效率。

Cluster key 的选择

用 Bucket 表的时候,需要注意 cluster key 的选择,选择的时候要尽量去选在查询条件中经常会用到的组合的 column、经常需要聚合的 column,以及 join 时的一些 join key。

分桶数量的选择

分桶数量可以参考 worker 的数量。做 Bucket 表一定程度上的目的是能够尽量发挥多个 worker 的计算能力去进行并行计算。所以在分桶数量选择上可以尽量地去选 worker 的倍数,比如 1 倍或者 2 倍。

Recluster

分桶指定好了可以改变,但是改变需要一定的代价,需要数据的重新分配。因此建议尽量在必要的时候才进行 recluster 的操作。

数据湖支持

ClickHouse 支持以外表的形式读取 Hive 以及 Hudi/Iceberg 等格式。这些外表都是以本地单机表的形式存在,因此性能并不能令人满意。且实现上较为割裂,使用起来较为不便。目前 Hive 仅能支持读取 HDFS 上数据,Hudi/Iceberg 仅能支持读取S3上的数据。

ByConity 通过统一的 Multi-catalog 的架构,极大增强了使用外表的便捷性。

ByConity Multi-Catalog

Multi-Catalog 的设计允许用户在同一个 Hive 实例中同时连接多个不同的存储和元数据服务,而不必为每个存储创建单独的 Hive 实例。这简化了数据管理和查询的复杂性,使组织能够更好地管理和利用其多样化的数据资源。目前已经支持的外部 Catalog 有:Hive,Apache Hudi,AWS Glue。

用户可以使用创建一个基于 Hive 和 S3 存储的 Catalog

create external catalog hive_s3properties type='hive', hive.metastore.uri = 'thrift://localhost:9083';

然后使用三段式的命名来直接访问 Hive 外表

select * from hive_s3.tpcds.call_center;

也可以使用 query 来查看 external catalog 相关的信息

-- display information releated to hive_s3show create external catalog hive_s3;-- show databases in hive_s3show databases from hive_s3;-- show tables in tpcds database in hive.show tables from hive_s3.tpcds;

ByConity Hive 外表

ByConity CnchHive 可以充分使用 Virtual Warehouse 的计算资源执行查询。支持 HDFS 和 S3 文件系统。为了优化性能,ByConity Hive 外表支持统计信息集成优化器,它可以根据数据的统计信息自动选择最佳的执行计划。统计信息集成优化器可以在 benchmark 中显著提高查询性能。目前ByConity Hive 外表不仅能完整跑通 TPC-DS 基准测试,同时在性能方面表现出色。

CREATE TABLE tpcds_100g_parquet_s3.call_centerENGINE = CnchHive('thrift://localhost:9083', 'tpcds', 'call_center')SETTINGS vw_default = 'vw_default';

ByConity Hudi 外表

ByConity 实现了对 Apache Hudi Copy-On-Write 表的进行快照查询。在开启 JNI Reader 后可以支持 Merge-On-Read 表的读取。Hudi 支持同步 HiveMetastore,因此 ByConity 可以通过 HiveMetastore 感知 Hudi 表。

CREATE TABLE hudi_tableENGINE = CnchHudi('thrift://localhost:9083', 'hudi', 'trips_cow')SETTINGS vw_default = 'vw_default';

总结

下表总结了 ClickHouse 和 ByConity 之间的一些不同点,帮助大家有一个比较清晰的了解。除此之外,ByConity 还有很多特性。欢迎关注更多相关的内容分享。

Github: https://github.com/ByConity

分享视频:从使用的角度看 ByConity 和 ClickHouse 的差异_哔哩哔哩_bilibili

PPT 获取:https://bytedance.feishu.cn/file/X43Nb8Ec5o0kHcxIzdGcf880nSh?from=from_copylink

加入社区

对于一个开源项目,引入更多参与者、让社区往多元化方向发展往往是重要目标之一,ByConity 也不例外。我们积极与社区成员共同探讨和解决大家在试用过程中遇到的问题,团队有耐心、也有信心,更是非常期待未来能够与更多开发者和合作伙伴一起共建共享,激发更多创造力。欢迎加入 ByConity 社区,与我们共建~返回搜狐,查看更多

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/132574.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

AI 编程界的扛把子

大家好,我是伍六七。 全国最大 AI 社群《AI 破局俱乐部》初创合伙人。8 年 Java 经验,干过开发,也做过管理。目前在某互联网大厂从事 Java 开发,业余时间研究 AI 编程。 我从 2022 年底,ChatGPT 问世,就密…

【第28例】IPD体系进阶 | 需求管理:需求实现过程

目录 简介 内容详解 CSDN学院相关推荐 作者简介 简介 继续 IPD 体系中的需求管理相关的专题。 先来看看整个需求管理涉及的过程内容: 需求管理流程主要包含五个阶段: 需求收集; 需求分析; 需求分发/分配;

【Python报错合集】Python元组tuple、张量tensor(IndexError、TypeError、RuntimeError……)~持续更新

文章目录 IndexError1. tuple index out of rangea. 示例代码b.报错原因c.解决方案 TypeError1. len() of a 0-d tensora. 示例代码b.报错原因c.解决方案 RuntimeError1. output with shape … doesnt match the broadcast shape …a. 示例代码b.报错原因c.解决方案 2. Cant ca…

npm install:sill idealTree buildDeps

执行npm install,卡在 sill idealTree buildDeps PS D:\workspace-groovy\attendance-india-web> npm install -g cnpm --registryhttps://registry.npm.taobao.org [..................] / idealTree:node_global: sill idealTree buildDeps[.................…

Web3游戏的十字路口:沿用传统IP还是另起炉灶?

人们经常问我对 Web3 游戏有什么看法。因此,我想以书面形式概述一下我目前的想法。 让我先澄清一下:我不是专家。这不是一篇深入探讨游戏世界精细指标如 MAU 或 D14 等的全面分析。请把这看作是我根据个人交流和研究,这反映我在游戏领域关注…

响应式建筑房地产开发企业网站模板源码带后台

模板信息: 模板编号:5635 模板编码:UTF8 模板颜色:红色 模板分类:基建、施工、地产、物业 适合行业:房地产类企业 模板介绍: 本模板自带eyoucms内核,无需再下载eyou系统&#xff0…

每天一点python——day61

#第61天 #字符串的驻留机制字符串:python中基本数据类型,是一个不可变的序列【目前我们学了两个:元组、字符串】 可以使用单引号,双引号,三引号来定义#定义字符串 apython#用单引号,双引号,三引…

如何解决msvcp140.dll文件丢失问题,msvcp140.dll丢失的解决方法

在使用电脑时,有时我们可能会遇到一些错误提示,比如“找不到msvcp140.dll文件”。这是因为某些程序需要依赖于msvcp140.dll文件才能正常运行。这个问题是可以解决的,大家不需要担心,而且其解决的方法是有很多种的,今天我们就来给大…

数据库系统原理与实践 笔记 #7

文章目录 数据库系统原理与实践 笔记 #7数据库设计和E-R模型(续)转换为关系模式具有简单属性的实体集的表示复合属性多值属性联系集的表示模式的冗余—合并 实体-联系设计问题设计问题联系属性的布局 扩展的E-R特性特化概化属性继承特化/概化的设计约束聚集E-R图表示方法总结E-…

利用Graviton2和S3免费套餐搭建私人网盘

网盘是一种在线存储服务,提供文件存储,访问,备份,贡献等功能,是我们日常中不可或缺的一种服务。很多互联网公司都为个人和企业提供免费的网盘服务。但这些免费服务都有一些限制,比如限制下载速度&#xff0…

网络运维Day06

文章目录 磁盘空间管理一块硬盘的“艺术”之旅识别磁盘分区规划分区模式MBR(主启动记录模式)GPT分区 使用GPT分区方案分区 格式化与挂载使用格式化挂载使用 实现开机自动挂载实验 光盘挂载交换空间 总结 磁盘空间管理 磁盘空间管理 扇区默认512字节 一块硬盘的“艺术”之旅 …

领星ERP如何无需API开发轻松连接OA、电商、营销、CRM、用户运营、推广、客服等近千款系统

领星ERP(LINGXING)是一款专业的一站式亚马逊管理系统,帮助卖家构建完整的数据化运营闭环。,致力于为跨境电商卖家提供精细化运营和业财一体化的解决方案。 官网:https://erp.lingxing.com 集简云无代码集成平台&…

[NLP] LlaMa2模型运行在Mac机器

本文将介绍如何使用llama.cpp在MacBook Pro本地部署运行量化版本的Llama2模型推理,并基于LangChain在本地构建一个简单的文档Q&A应用。本文实验环境为Apple M1 芯片 8GB内存。 Llama2和llama.cpp Llama2是Meta AI开发的Llama大语言模型的迭代版本,…

02-React组件与模块

组件与模块 前期准备 安装React官方浏览器调试工具,浏览器扩展搜索即可 比如红色的React就是本地开发模式 开启一个用React写的网站,比如美团 此时开发状态就变成了蓝色 组件也能解析出来 何为组件&模块 模块,简单来说就是JS代…

系统架构设计师(第二版)学习笔记----层次式架构设计理论与实践

【原文链接】系统架构设计师(第二版)学习笔记----层次式架构设计理论与实践 文章目录 一、层次式体系结构概述1.1 软件体系结构的作用1.2 常用的层次式架构图1.3 层次式体系可能存在的问题点 二、表现层框架设计2.1 MVC模式2.1.1 MVC三层模式2.1.2 MVC设…

Zookeeper3.7.1分布式安装部署

上传安装文件到linux系统上面 解压安装文件到安装目录 [zhangflink9wmwtivvjuibcd2e package]$ tar -zxvf apache-zookeeper-3.7.1-bin.tar.gz -C /opt/software/3. 修改解压文件名 [zhangflink9wmwtivvjuibcd2e software]$ mv apache-zookeeper-3.7.1-bin/ zookeeper-3.7…

用HTML + javaScript快速完成excel表格信息除重并合并

今天突然接到一个工作,要把两个存储在.xls的主体信息表,除重后合并成一个主体信息表,并且补充主体类型和所在县区这两列信息。 完成这项工作的方法有很多,如果信息表中的信息量不大的话,手工处理一下也行,如…

Go语言用Colly库编写的图像爬虫程序

下面是一个使用Colly库编写的Go语言图像爬虫程序,该程序会爬取news.qq上的图片,并使用proxy_host:duoip和proxy_port:8000的爬虫IP服务器进行抓取。 package mainimport ("fmt""net/http""github.com/crawlab-collective/go-co…

top和jstack分析堆栈问题

1.top 在服务器上,我们可以通过top命令查看各个进程的cpu使用情况,它默认是按cpu使用率由高到低排序的 由上图中,我们可以找出pid为21340的java进程,它占用了最高的cpu资源 2. top -Hp pid 通过top -Hp 21340可以查看该进程下&…

AMEYA360荣获“国际潜力之星分销商”奖!

由全球电子技术领域知名媒体集团ASPENCORE主办的“全球电子元器件分销商卓越表现奖"颁奖典礼于2023年11月3日晚在深圳大中华喜来登酒店圆满结束! 全球电子元器件分销商卓越表现奖创办于2001 年,迄今已成功举办20年,此奖项旨在表彰支持电子产业发展的…