凤豪_个人页_阿里云开发者社区

阿里云数据库 ClickHouse 云原生版产品解析

点击申请云原生版试用资格ClickHouse 介绍ClickHouse 是一款当前非常流行的开源在线分析型数据库。ClickHouse 主要应用于实时数仓构建、大数据加速分析、宽表日志分析等通用场景，服务于流量漏斗分析，用户行为分析，人群圈选，用户画像，广告投放人群评估、ABTest 、大促分析，CDP/DMP 等业务场景，在电商平台，新零售、游戏、广告、社交应用，在线旅游，本地生活，交通物流等行业都有广泛典型的应用案例，国内大厂阿里，字节，腾讯，快手，携程，京东，小红书等都有大规模的业务使用。ClickHouse 开源关注度增长非常迅速，在 DBEngine 网站公布的2021年RDBMS 产品类目产品关注度排行榜上，ClickHouse 年度关注度排名提升30名，整体排名28位。以下是当前在线分析数据库/实时数仓领域的几款高热度产品的流行关注度趋势，ClickHouse 和 Greenplum 为开源产品，其他几款为闭源商业产品。ClickHouse 之所以得到这么高的关注度，个人认为两个核心的因素决定: 一是市场驱动。当前企业客户整体业务数量规模增大，而业务实时分析决策的需求明显，触发了对在线分析型数据库/实时数仓的需求增强；二是产品选型，流量和用户的竞争激烈的大环境下，促使业务行为和决策更有时效性，从而提高留存率和转化，因此对数据分析引擎的性能响应要求越来越高。同时业务分析维度增多，分析数据来源多，分析数据规模膨胀，对成本控制的需求也非常明显。ClickHouse 基于列式存储，向量化执行引擎和SIMD（单指令多数据流），稀疏索引，分布式计算，多核并行等核心技术以及优秀的工程实现，实现了高压缩比数据存储，高效的数据写入吞吐和亿级记录95%查询秒级返回的优异性能。社区官网公布的性能测试结果显示。ClickHouse 相比 MySQL 在分析性能上有500倍以上的提升，相较于 Greenplum 等分析引擎在聚合分析场景也有 20倍以上的性能提升。（PS：想了解更多 ClickHouse 的原理和架构以及开发实践，可以看往期我们在阿里云开发者社区陆续发布的ClickHouse 内核解析系列文章。ClickHouse 内核解析和开发实践文档系列。）自建ClickHouse 使用问题我们可以看到 ClickHouse 凭借其卓越优异的性得到广大开发者关注，并在头部的互联网企业得到了比较多的应用。但实际上从我们调研了解到，企业自建ClickHouse 在非超大型企业里生产环境普遍没有大规模使用，觉得大多数情况是在小规模创新型业务场景验证，或者还在调研测试阶段。这种情况归结起来主要是以下三类主要原因造成。内核稳定性问题 ClickHouse 社区迭代的非常快，版本迭代可以保持每个月一个二级版本发布，多个版本同时迭代，新版本的发布除了新feature的发布以外，通常包含大量的 bugfix ，同时这两类的功能更新也会带来大量新的bug ，导致生产环境高频的遇到功能性的bug ，而社区版本bug修复的时间又不可预期， 存在稳定性隐患，因此用户在生产环境不会轻易进行大规模的应用。缺乏实践经验ClickHouse 提供了非常丰富的表引擎类型。支持数据链路类的引擎如： Kafka 引擎，HDFS 外表擎。也有不同的主键聚合逻辑的引擎，支持不同的业务场景如支持主键替换的 ReplacingMergeTree，支持基于主键字段求和的 SummingMergeTree，支持自定义函数聚合的 AggregatingMergeTree 等等。这些引擎功能丰富的同时，也增加了使用的复杂度，需要根据业务需求来选型引擎。同时ClickHose 具有一些隐含的异步操作，在数据实时性和一致性有要求时需要通过特定的强制合并逻辑和定时处理来实现实时性和一致性的要求。这些经验在社区沉淀的较少，高水平的专家实践指导优化资料比较少，那么导致缺失实践经验，自建开发成本高和业务落地周期长。运维成本ClickHouse 开源版运维支撑比较弱。遇到稳定性的问题，需要有专业的团队进行内核bug 的修复， 其次ClickHouse 作为数仓类产品需要和上下游的各个数据链路进行打通，开源版只提供基础的数据链路对接能力，链路稳定性维护的成本也随之增加，而组建独立ClickHouse 开发运维团队成本非常高。特别要提到的是 ClickHouse 扩容问题。ClickHouse 分布式模式是基于shard 分片，如下图所示，单个shard节点包含计算资源和存储资源，计算资源和存储资源耦合绑定在同一个shard节点。水平扩展会遇到两个问题： 如果遇到某个shard 节点的磁盘打满或者计算资源不足的时候，需要通过增加计算节点，分担数据存储和计算负载。基于开源版本架构设计，需要单独进行计算扩容或者存储扩容时，因为存储和计算的耦合，那么必须计算资源和磁盘存储一起扩容，而这样就会造成一定程度资源浪费，资源利用率降低。另外一个问题是，进行水平扩容后，由于增加了shard 节点，为了保持资源查询负载的均衡，那么需要将原有的shard节点的数据按在扩容后在所有的shard 节点上进行 Rebalance 。 Rebalance的过程需要进行历史数据进行迁移和重新写入，数据量大的情况下迁移周期长，影响正常业务数据写入，业务侵入性太高。以上三方面的问题会导致不具备大规模运维系统构建和内核修复能力的企业来说，使用自建 ClickHouse的ROI 将会非常低。云数据库ClickHouse 社区兼容版架构图阿里云数据库ClickHouse 云原生版本阿里云数据库 ClickHouse 云原生版是在开源内核版本基础上，基于云的基础设施进行架构和能力升级。集成云企业级运维能力，增强易用性，降低运维成本；并进行资源解耦，提供更细粒度的资源使用控制，并提高资源的利用率和弹性效率，实现实时企业分析场景的降本增效，提高决策效率和业务收益。云原生版运维能力云原生版提供全面运维能力，满足企业客户 ClickHouse 运维需求，部分能力如下：PAAS级服务，免部署轻运维，开箱即用。企业级数据链路对接。包含离线的 OSS，ODPS ，HDFS ，HIVE ,MaxCompute 以及实时的MySQL，Kafka ，Flink 数据源对接。生产级MaterializedMySQL ，增强支持表级实时数据同步，增强容错处理和数据一致性保证。支持 DataWorks ，Spark ，SeaTunnel ,DataX 等企业级和开源数据集成和调度平台。数据安全性全面提升，支持存储加密，HTTS/SSL 存储加密，数据备份恢复。监控告警体系支持，提供资源层和数据库引擎层的监控告警和慢SQL的监控处理企业级资源管理能力，支持实时升降配和扩容，支持Terraform 等。内核稳定性支持，bug 发现后及时修复，保证稳定性。专家服务支持，给予稳定性保障和最佳实践的支持云原生版优势特性云原生版本进一步实现资源解耦，实现存储计算资源解耦，提高性价比和弹性效率。具体特性如下【存算分离】云原生版本采用存储计算解耦架构，可以根据生产需求独立进行计算或者存储计算的扩缩容，资源管控粒度更细，整体成本更加可控。【缓存加速+共享存储】计算层加入ESSD缓存层，缓存层加速写入和查询，根据业务负载需求可弹性扩展缓存层，保证实时查询效率。持久化数据存储使用更低成本的存储介质，按照30%的缓存和持久化存储配比，整体缓存+持久化存储成本下降60%。【存储使用】持久化存储使用低成本存储介质，按小时统计实际使用量，无需容量规划，存储资源使用率达到100%，更具性价比。【计算资源池化】云原生版本计算资源采用计算组资源服务化模式，直接根据需求选择计算组规格，无需关心计算组内部节点规格和节点数量，依据业务需要进行资源扩缩容，更简单。【高效弹性】云原生版本采用 ShareDisk 模式，计算资源扩容无持久化数据迁移过程，扩容稳定性提升，扩容效率提升10倍以上。云原生版的实例购买和使用方式第一步：选择计算资源，含内存和CPU资源。云原生版对计算资源进行的封装，用户无需选择节点规格和节点数量，只需选择整体依赖的计算资源即可。第二步：选择缓存资源。缓存加速写入和查询，根据写入量和查询性能表现选择，实例创建后可以根据性能调节缓存大小。第三步：进行数据写入和访问。存储资源无需提前购买，按需使用，根据实际数据写入量动态计量。云原生版实例购买模式示例云原生版本的几个疑问在云原生推出的过程中，收集到几个客户关心的问题，分享给大家。问题1 ：云原生版本缓存和社区兼容版冷热分层的热数据层有什么区别？答： 云原生版本和社区兼容版冷热数据分层都有数据分层逻辑。区别在于云原生版本的持久化层数据为全量数据， 缓存为部分数据，按照实际查询结果自动选择缓存数据。而冷热分层及多盘是预设存储分层，根据用户根据业务规则预先将数据划分为冷数据和热数据，冷热数据都是非全量数据，业务定义为冷数据的存储在冷数据层，不会根据查询热度自动转变为热数据，冷热数据转换需要修改数据定义规则或者手工搬运分区数据。问题2：ClickHouse 使用大数据量的低成本的存储 ，能做到实时分析吗？答：云原生版本增加了缓存层，使用ESSD盘作缓存。数据写入过程先写入到缓存层，保证写入效率，而后写入到全量的数据持久层存储。查询依赖数据也会缓存到缓存层，提高查询速度。缓存层根据特定的算法进行数据有效性控制和淘汰的机制。缓存层资源可以基于资源使用率监控和查询效率进行手动的扩缩容操作，整体保证查询效率。云原生版本未来的演进计划阿里云数据库ClickHouse 云原生的版本后续的产品将朝着提高资源利用率，提高性能，智能运维三个指标方向进行迭代。一是全面 Serverless ，实现无需进行计算资源的预设 ，根据负载实时进行动态资源的调整，充分提高资源利用率。二是进一步资源解耦，精细化资源使用粒度，资源配比的动态调整，实现不同业务场景对不同计算资源维度的差异化需求。三是自动化智能运维，逐步从人工定位问题到自动巡检，人工优化到自动报告建议，部分实现智自动诊断和自优化，提高智能诊断优化的问题拦截率和满意度。邀测申请方式阿里云数据库ClickHouse 云原生已经发布上线，并开启试用申请，欢迎您申请体验。点击或扫描二维码填写公测表单等待测试资格审核；收到测试资格审核通过通知后，发放测试代金券，创建实例并测试试用支持区域：华北2（北京），华东2（上海），华东1（杭州），华南1（深圳）。

TSQL：让监控分析更简单更高效

1. 前言阿里时序时空数据库TSDB最新推出TSQL，支持标准SQL的语法和函数。用户使用熟悉的SQL，不仅仅查询更简单易用，用户还可以利用SQL强大的功能，实现更加复杂的计算分析。 2. 为什么需要用SQL做时序查询？ 2.1 SQL拥有广泛用户基础 SQL作为一个诞生于上世纪70年代的编程语言已经存在几十年了。这是一个相对而言较“古老”的编程语言，但又是一个有着广泛用户基础的语言。在跟踪主要编程语言的流行程度的TIOBE index[1]中，SQL在2019年4月份的排名是第8。而如果把排名列在11-20之间的SQL的两个“兄弟”PL/SQL, Transact-SQL也合并进来的话，SQL的流行度应该更高。根据stackoverflow网站的调查 [2]，SQL在最流行的编程语言榜上排在第4位。无论TIOBE index还是stackoverflow的编程语言排行榜，都从一个侧面反映了SQL的广泛用户基础。作为一个查询语言，SQL是用户和数据库系统交互的(直接或间接)主要方式。支持一个拥有广泛用户基础的查询语言，对于推广数据库系统来说，是非常重要的。 2.2 用户学习成本最近几年出现的几个主要面向时序场景的数据库，除了TimescaleDB是在Postgres基础上所以支持PG生态包括SQL语言支持，其他几个比如InfluxDB, OpenTSDB, Prometheus都有各自不同的查询语言和接口：InfluxDB有InfluxQL，OpenTSDB有自己的Restful API, 而Prometheus有PromQL。每一个系统都可以声称自己的语言是独一无二的，更适合时序查询这样的场景；但不可否认的事实是用户需要去花时间去学习一种新的语言，并且如果这个语言为了功能完善，还在不断演进中，这样的学习成本对用户来说，尤其显得高了。举个例子，InfluxDB的InfluxQL并不支持Join，Subqueries, 以及SQL中很常见的UDF等功能，这意味着用户并不能在不同数据之间进行关联分析计算，也不能在系统函数基础上进行扩展开发。InfluxDB设计者在听到社区的意见后，做了一个很有“创意”的事情：在新版本里支持Join，UDF等功能，但并不是让InfluxQL变得更加接近于SQL，而是在一个全新的Flux(一个新的functional scripting language)里支持 [3]。用户想要做InfluxQL不能做的事情，那就再来学习一个新语言吧。一个很有意思的事情，10多年前开始出现的NoSQL系统，比如MapReduce/Hadoop, BigTable,Casandra，HBase等，一开始也是以各自不同的查询语言出现的。在经历了多年用户推广之后，NoSQL开始拥抱SQL，变成了NotOnlySQL或者NewSQL。时序数据库这样一个新兴的数据库领域，也有可能重复这样的历史。原因很简单，用户学习一个新语言的成本越高，越会阻碍一个系统被推广到大众接受的程度。 2.3 BI工具生态支持时序数据库提供SQL的查询支持，一个很重要的原因是将时序数据库的应用场景扩展到商业分析(BI/Business Analysis)，商业决策这样高附加值领域。当前几个主要的时序数据库，包括InfluxDB, OpenTSDB和Prometheus，主要侧重于基础性能监控这样的场景，利用Grafana这样的可视化工具，实现监控报警这一类基本功能。另一方面，监控报警还没有充分利用挖掘时序数据的商业价值。进一步的功能，需要充分利用现有SQL生态系统中的商业分析工具，比如Tableau, Qlik，Oracle BI, IBM Cognos等。这些BI工具，往往是以SQL的方式同后端数据库交互。从这个角度来说，时序数据库的SQL支持对于对接BI生态系统中的各种工具，尤为重要。 2.4 TSQL面向的用户群在阿里时序数据库TSDB支持的兼容OpenTSDB查询协议之上推出的TSQL查询引擎，主要是面向以下两类用户：时序数据库TSDB的新应用开发者：这类用户往往以前使用关系数据库，因为关系数据库本身处理时序数据的性能和可扩展性的局限，而转而使用TSDB。这些新应用开发者，希望TSDB在提供比关系数据库更好的时序性能和扩展性的同时，能够用他们以前熟悉的查询语言进行应用开发，而不是去学习一个新的查询语言。数据分析师：这类用户并不开发应用，他们的工作是利用已有的商业分析工具，对时序数据进行进一步的查询分析。他们本身并不直接使用SQL，但所使用的工具以SQL作为和时序数据库TSDB交互的查询语言。 3. 现有时序数据库系统SQL查询能力比较这里简单对比时序数据库系统中提供SQL查询，或SQL-like查询能力的InfluxDB, TimescaleDB, 阿里云TSDB。 4. TSQL系统架构上图是TSQL的总体架构以及和TSDB引擎和存储之间的协调工作关系。简单来讲，TSQL是一个典型的MPP的SQL分析引擎，通过Connector同TSDB引擎和存储进行数据交换。Connector支持MetaAPI和DataAPI。 TSQL是在两个Apache开源项目基础上演进开发的： Apache Calcite作为SQL的解析器和计划生成和优化器。 Apache Drill提供分布式的SQL执行层。 Apache Calcite作为一个扩展性好，支持标准SQL语法和语义的SQL计划生成器，已经被很多数据处理相关的开源项目使用[6]，包括大数据ETL的Apache Hive, HBase上的SQL解决方案Apache Phoenix, 也有流数据处理框架Apache Fink (阿里的Blink)和Apache Beam等。 TSQL使用Calcite作为SQL计划生成器，可以在兼容标准SQL方面，充分利用开源社区已有的成果。 4.1 时序数据Schema管理 InfluxDB, OpenTSDB和Prometheus都采用的是一种Schema-on-write的方式，也就是用户并不需要明确定义metric的schema, 而是将schema的信息隐藏在数据中，在数据写入的时候，同时管理着schema。这样做的好处是更高的灵活性：在写入数据的时候，用户不需要事先必须用Create Table DDL来创建table；在时序数据tag set出现变化的时候，用户不需要事先用Alter Table来修改table的schema。TimeScaleDB从PG上扩展而来，所以是采用的是严格的Schema的管理方式。在使用灵活性方面，不如上面其他3个时序数据库。 Calcite作为一个SQL计划生成器，很适合时序数据库这样的比较松散的Schema管理方式。 Calcite的Schema Adapter，可以支持动态的Schema 发现，任意一个数据集，只要实现Schema管理中的接口API, 就可以在计划解析生成阶段被当成一个Table来处理。 TSQL在Calcite的Schema Adapter基础上，利用TSDB引擎中新增加的MetaAPI，来完成SQL计划解析和生成。这免去了用户必须事先在一个集中式的catalog中预先定义Table DDL等繁琐工作，给用户带来了很多的灵活性。 4.2 时序数据查询执行 TSQL的执行层，利用了Apache Drill的runtime execution。Drill的runtime execution，具备以下特点利用off-heap内存作为计算内存，减少Java heap内存GC所带来的延迟问题基于Columnar格式的ValueVector (Apache Arrow的前身)，提升查询执行效率动态代码生成和编译UDF支持 5. TSQL时序查询功能我们以一个基础性能监控场景来举例说明TSQL能完成的时序查询功能。利用一个时序数据库业界公开的时序性能Benchmark[5] 生成的模拟数据，按照DevOps这样的场景，产生了cpu相关的10不同的metric。每个metric对应了机房(datecenter)，主机(hostname)，rack等标签下所采集的服务器cpu相关的指标数据。 5.1 元数据查询可以用下面的方式查询TSDB中所有的metric/table SHOW TABLES FROM tsdb 如果我们希望列出所有以cpu为前缀的metric/table，可以在上面的查询基础之上添加附带过滤条件. show TABLES from tsdb where TABLE_NAME like 'cpu%' 下图给出了命令的部分输出: 在获得metric/table 名字后，我们可以进一步用SQL中的'DESCRIBE'命令来查询这个metric/table的schema信息 describe tsdb.`cpu.usage_user` 下图显示了上面的'describe'命令的部分结果： 5.2 时序数据简单查询用下面的SQL查询可以获得指定时间段内的'cpu.usage_user'的指标值，时间戳，以及对应的标签值。 select * from tsdb.`cpu.usage_user` where `timestamp` between '2019-05-01 16:00:00' and '2019-05-01 18:00:00' 这里，将被转换成 metric/table下所有的列，包括指标值，时间戳，所有的标签列。可以以具体的列名的一个列表来代替。作为对比，如果把上面的查询转化成OpenTSDB协议来查询，相对应的查询如下： { "start": "1556726400000", "end": "1556733600000", "queries": [ { "aggregator": "none", "metric": "cpu.usage_user", "rate": null, "downsample": null, "filters": [] } ] } 可以在时间戳的过滤条件基础上，增加指标列上的条件。下面的查询，列出指定时间段内，3台主机上的指标值，并且使用limit, 把查询结果限制在100行。 select * from tsdb.`cpu.usage_user` where `timestamp` between '2019-05-01 16:00:00' and '2019-05-01 18:00:00' and hostname in ('host_1', 'host_5', 'host_10') limit 100 可以在查询中使用标准SQL中丰富的数值计算函数，字符串函数或时间戳函数。下面的SQL，我们分别使用了数值运算函数sqrt, 时间戳函数extract 和字符串lower。 5.3 时序降精度，聚合运算如果我们要计算两小时之内，每台主机上每5分钟的指标cpu.usage_user的最大值，最小值，以及数据采样点的个数。这样的查询，代表了在时间维度上的降精度，并且在标签hostname上进行的聚合运算。用TSQL来表示这样的查询： select hostname, tumble(`timestamp`, interval '5' minute) ts, max(`value`) maxV, min(`value`) minV, count(`value`) cnt from tsdb.`cpu.usage_user` where `timestamp` between 1556726400000 and 1556733600000 and hostname in ('host_8','host_5','host_6') group by hostname, ts 如果用OpenTSDB的协议来查询: { "start": "1556726400000", "end": "1556733600000", "queries": [ { "aggregator": "max", "metric": "cpu.usage_user", "downsample": "5m-max", "tags":{ "hostname":"host_8|host_5|host_6" } }, { "aggregator": "min", "metric": "cpu.usage_user", "downsample": "5m-min", "tags":{ "hostname":"host_8|host_5|host_6" } }, { "aggregator": "sum", "metric": "cpu.usage_user", "rate": null, "downsample": "5m-count", "tags":{ "hostname":"host_8|host_5|host_6" } } ] } 可以看到，相比较原来Restful API的查询，TSQL能够用更简洁的方式来表示相同的查询语义；并且，如果用户本来就熟悉SQL的使用方法，节省用户去学习Restfule API里JSON各个字段的含义。从降低用户学习成本，增加易用性这个角度，TSQL带来了较明显的价值。TSQL不仅仅带来查询简洁，用户易用的优点，并且，更重要的是，用TSQL能够表达Restful API里不能直接表达的查询语义。在TSDB引入TSQL之前，如果用户需要进行这样的查询计算，则用户必须通过自己的应用程序，在Restful API获得数据后，再进行后计算，来满足业务需要。在自己的应用程序中进行后计算，往往需要付出很大的应用开发代价。 5.4 聚合后计算，过滤，排序下面的例子，计算2个小时内，3台机器上每5分钟内，cpu.usage_user指标值的最大值和最小值的差异超过10.0的时段和hostname, 并按照差异值从大到小排序：在上面的例子中个，在获得最大值和最小值后，进一步计算两者的差异值，并根据差异值进行过滤和排序。这样的聚合后计算处理，无法用OpenTSDB的查询协议表示；用户如果要表达这样的语义，就必须在应用程序中计算。 select hostname, tumble(`timestamp`, interval '5' minute) ts, max(`value`) - min(`value`) as diffV from tsdb.`cpu.usage_user` where `timestamp` between '2019-05-01 16:00:00' and '2019-05-01 18:00:00' and hostname in ('host_1', 'host_5', 'host_10') group by hostname, ts HAVING diffV > 10.0 order by diffV DESC 5.5 任意复杂的条件表达式 TSDB的Restful API对于只提供有限的几种filter, 而并不支持任意filter通过AND/OR的组合。比如下面的例子，是一个TSQL业务中使用的查询。其中WHERE条件部分是并不能用Restful API来表示的，因为Restful下的filters是只有AND, 而OR只有在相同tag上通过'value1|value2|vale3'这样的形式来表达。 where ( (obj_id='ems30_NA62_183249003' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or (obj_id='ems30_NA62_183249746' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or (obj_id='ems30_NA62_183246962' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or (obj_id='ems30_NA62_183248143' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or (obj_id='ems30_NA62_183249191' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or (obj_id='ems30_NA62_183249964' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') or (obj_id='ems30_NA62_183247148' and obj_type='ems30_NA62_20204' and room='ems30_NA62_C-T01.NA62' and building='ems30_NA62_C') ) and `timestamp` between '2019-04-25 18:20:21' and '2019-04-25 18:20:31' ... 支持任意组合的AND/OR的条件表达式，对于应用开发是很有意义的。在集团基础监控业务(raptor-pro)中，一个突出的亮点是“定制化监控报警”：允许业务方的用户来定制查询条件，并且查询条件可以是任意的AND/OR组合。TSQL为"定制化监控报警"的功能实现，提供了有力的技术保障。 5.6 多个metric之间join 这个查询，把cpu.usage_system和cpu.usage_idle在hostname和timestamp上做等值join, 然后计算每5分钟两个度量值之和的sum。 select t1.hostname, tumble(t1.`timestamp`, interval '5' minute ) ts, sum(t1.`value` + t2.`value`) as sumV from tsdb.`cpu.usage_system` t1, tsdb.`cpu.usage_idle` t2 where t1.`timestamp` >='2019-05-01' and t1.`timestamp` <= '2019-05-01 01:00:00' and t1.hostname = t2.hostname and t1.`timestamp`= t2.`timestamp` group by t1.hostname, ts 上面的查询，如果我们采用TSDB的多值模型，把cpu.usage_system和cpu.usage_idle处理成一个metric的不同的field, 则不需要join就可以完成。但如果我们需要在分组聚合后的结果上再做join, 多值模型也无法解决问题。 5.7 分组聚合后join计算下面的查询，分别对cpu.usage_system和cpu.usage_idel按照5分钟计算聚合函数sum(), 再通过join, 对齐，计算相对应的比例。并且，每个子查询的Where条件，除了包括在tag上和时间戳上的条件，还包括值上的过滤条件。类似这样的查询，是无法直接在TSDB的RestAPI来实现的；用户只能在自己的应用程序中实现，增加了应用开发成本。 select f0.hostname, f0.ts, f0.sumV / f1.sumV as resultValue from ( select hostname, tumble(`timestamp`, interval '5' minute) ts, sum(`value`) as sumV from tsdb.`cpu.usage_system` where hostname in ('host_0', 'host_5', 'host_10') and `timestamp` between '2019-05-01 00:00:00' and '2019-05-01 01:00:00' and `value`<=50 group by hostname, ts ) as f1 join ( select hostname, tumble(`timestamp`, interval '5' minute ) ts, sum(`value`) as sumV from tsdb.`cpu.usage_idle` where hostname in ('host_0', 'host_5', 'host_10') and `timestamp` between '2019-05-01 00:00:00' and '2019-05-01 01:00:00' and `value`<=30 group by hostname, ts ) as f0 on f1.hostname = f0.hostname and f1.ts = f0.ts 5.8 UDF扩展功能使用UDF来扩展功能，对于时序数据库这样聚焦特定领域的数据库来说，是非常必要的，因为往往SQL标准中定义的函数，并不能完全满足需要。TSQL有一个完善的UDF的体系，用户只要按照约定的接口，用Java语义就可以实现扩展。比如，我们在TSQL中引入的把时间戳分割成不重合的窗口的函数tumble，其实现就是由下面不到15行代码完成。用户可以用Java实现不同的scalar UDF或者aggregate UDF, 并把编译后的jar加入到TSQL的系统类库目录，就可以自行扩展TSQL的查询计算功能了。 @FunctionTemplate(name = "tumble", scope = FunctionTemplate.FunctionScope.SIMPLE, nulls = FunctionTemplate.NullHandling.NULL_IF_NULL) public static class Tumble implements DrillSimpleFunc { @Param TimeStampHolder timeStamp; @Param IntervalDayHolder interval; @Output TimeStampHolder out; @Override public void setup() { } @Override public void eval() { long intervalMs = interval.days * org.apache.drill.exec.vector.DateUtilities.daysToStandardMillis + interval.milliseconds; out.value = timeStamp.value - timeStamp.value % intervalMs; } } 6 TSQL可视化查询阿里云TSDB已经提供了TSQL可视化交互式开发功能，通过web页面可以方便的进行TSQL的测试和开发，如下图Demo所示，。点击了解阿里云时序数据库

凤豪_个人页

个人介绍

擅长的技术

阿里云数据库 ClickHouse 云原生版产品解析

分析型数据库 AnalyticDB for PostgreSQL 推出学习型小规格实例

快60倍！分析型数据库 AnalyticDB for PostgreSQL 版 6.0 启动商用。

权威发布！阿里云分析型数据库AnalyticDB 荣膺中国信通院大数据产品评测双料认证

分析型数据库(PostgreSQL版)正式推出 Greenplum 6.0 兼容版

分析型数据库(PostgreSQL版)正式推出 Greenplum 6.0

MPP架构实时大数据平台，分析性数据库 PostgreSQL 6.0 邀您公体验！

DBengine 排名第一，云数据库 InfluxDB 版正式商业化！

再不懂时序就 OUT 啦！，DBengine 排名第一时序数据库，阿里云数据库 InfluxDB 正式商业化！

TSQL：让监控分析更简单更高效

阿里云数据库 ClickHouse 云原生版产品解析

分析型数据库 AnalyticDB for PostgreSQL 推出学习型小规格实例

快60倍！分析型数据库 AnalyticDB for PostgreSQL 版 6.0 启动商用。

权威发布！阿里云分析型数据库AnalyticDB 荣膺中国信通院大数据产品评测双料认证

分析型数据库(PostgreSQL版)正式推出 Greenplum 6.0 兼容版

分析型数据库(PostgreSQL版)正式推出 Greenplum 6.0

MPP架构实时大数据平台，分析性数据库 PostgreSQL 6.0 邀您公体验！

DBengine 排名第一，云数据库 InfluxDB 版正式商业化！

再不懂时序就 OUT 啦！，DBengine 排名第一时序数据库，阿里云数据库 InfluxDB 正式商业化！

TSQL：让监控分析更简单更高效

AnalyticDB和HybridDB区别

AnalyticDB的持久化存储是放在ECU本地？还是放在远端飞天的HDFS？

AnalyticDB使用不了

分析型数据库AnalyticDB for MySQL支持数据源，多模吗？

针对复杂SQL查询，AnalyticDB和关系型数据库相比，性能有多大提升？

阿里云的greenplum支持6了吗？

想问下各位大佬，存储传感器数据，用cassandra做时序数据库性能怎么样

分析型数据库mysql 新增分区

AliSQL性能优化与功能突破的演进之路【精品问答集锦】

适合做大型评论系统的分布式数据库？nosql 合适不？

使用阿里云的数据库，但是不懂读写分离配置

分布式数据库的具体实现和框架没有介绍啊

消息队列 ons 如何保证顺序

MQ，可以用在移动端吗

MQ 使用 HTTP接入，如何保证不收到重复的消息

mns 消息服务和 mq 消息队列在使用上有什么区别？

请问阿里云MQ+Spring怎么整合

批量手动安装EDAS Agent(非vpc环境)

EDAS同步ECS问题

hsf跟dubbo应该怎么选择？