点击上方“蓝字”可以关注我们哦
卞昊穹
中国人民大学博士
嘉宾简介：
中国人民大学博士研究生，研究方向为数据库系统和实时数据分析，从事SQL-on-Hadoop系统测试和开发。在HDFS列存储优化、高性能数据索引和装载、分布式等值连接算法、海量知识库扩充等方面的研究成果发表在SIGMOD、CIKM等国际顶级学术会议上。
宽表列存储在大数据分析中的应用与优化
目前在很多企业的数据分析任务中，常见几百上千列的宽表数据。这些宽表通常数据量巨大、存储在HDFS等分布式文件系统中。HDFS上宽表存储优化重要且具有挑战。宽表在数据分析中的可以避免一些频繁的连接操作，在用户画像、数据挖掘负载中，宽表也是一种高效的数据存取方式。对于宽表上的分析型负载，列存储可以有效减少不必要的I/O、提高数据压缩效果。HDFS上也已经有RC File、ORC、Parquet等成熟的列存储格式，但这些存储格式的设计只考虑了传统的数据分析负载，并没有针对宽表做深入的研究和优化。本工作介绍了HDFS上宽表列存储的特征和优化方法。该工作已在微软Bing日志分析产品中应用，并发表在SIGMOD 17上。
■议题详解
品读之后，
愿享同感。
by.数据库技术大会

                

这里写目录标题
概述
优势特性
缺点特性
性能
安装
测试
创建表
导入数据
查询数据


ClickHouse，是一个快速，开源，OLAP的数据库管理系统。ClickHouse是列式存储的，支持实时使用SQL的查询生成分析报告。

什么场景下使用ClickHouse

分析干净，结构合理且不可变的事件或日志流。 建议将每个这样的流放入具有预连接维度的单个宽事实表中。特别是以下场景：


网络和应用分析
广告网络和实时出价
电信
电子商务和金融
信息安全
监控和遥测
时间序列
商业智能
网络游戏
物联网

概述
优势特性

真正的面向列的存储

不存储额外的数据，支持恒定长度存储。其他系统也可以列式存储，但是他们侧重点不同，无法有效处理OLAP分析查询，包括HBase，BigTable，Cassandra和HyperTable。这些系统支持每秒10W行的吞吐量，但是ClickHouse支持每秒亿行的吞吐量。而且Clickhouse还是一个数据库管理系统，支持运行时创建数据库和数据表，运行时加载数据、执行查询，不需要重新配置和启动服务器。
数据压缩

部分列式存储数据库不使用数据压缩。但是数据压缩在提升性能方便有很大空间，除了通用的权衡磁盘空间和CPU消耗的编码解码其外，ClickHouse还对于特定的数据类型提供了专门的压缩解码器。
磁盘存储

通过按照主键对数据进行物理排序，提高在查询特殊值或者某一值区间时的效率，通常小于几十毫秒。某些面向列的数据库只能在RAM中工作，需要更多的成本，Clickhouse多数在常规的磁盘上工作，成本较低；但是ClickHouse也可以充分利用SSD和额外的RAM。
多核并行处理

执行数据量大的查询时，自动并行查询，占用当前服务器上所有可用的、必须要使用资源。
多台服务器上分布式处理

大多数列式存储的RDBMS都不支持分布式查询处理，ClickHouse支持分片，数据可以存在ClickHouse不同的分片上，每个分片都是可以用于容错的一组副本，所有分片都可以并行执行查询。
支持标准SQL

ClickHouse支持基于声明式查询语言的SQL，和ANSI SQL标准相同。支持 group By，order By，from，join子句，in运算符和标量子查询中的子查询。

-**向量计算引擎 **

数据不仅按照列存储，而且通过向量进行处理，从而实现较高的cpu效率。
实时数据更新

Click House支持表主键，为了在主键的某一范围内进行快速查询，使用Merge Tree对数据进行增量排序，因此可以将数据增量的添加到表中，提取数据时不进行任何锁定。
主键索引

通过主键对数据进行物理排序，可以在提取特定值，特定范围内的值的数据时，将时间优化到几十毫秒的量级。
二级索引

与其他数据库不同，ClickHouse的二级索引不指向特定行或行范围。而是，通过二级索引，ClickHouse知道某些数据部分的所有行不符合查询过滤条件，然后根本不读取这些数据，所以ClickHouse的二级索引又叫数据跳过索引。
适用于在线查询

大多数的OLAP数据库的初衷都不是亚秒级别的在线查询，在替代系统中认为，数十秒或者几分钟的报告构建时间是可以接受的。有时甚至需要强制离线准备报告。而ClickHouse支持压秒级别的报告查询。
支持近似计算

ClickHouse提供了多种方式来提高性能，包括近似计算。Aggregate  function用来计算不重复值，中位数，分位数的数量。根据部分样本数据运行结果来计算近似结果，在这种情况下，从磁盘读取数据的比例将大大减少，对有限的随机数据执行聚合，而不是所有数据，在确定条件下数据在整个数据中的分布，会在使用较少资源的情况下得到一个合理准确的结果。
自适应连接表算法

在需要表连接时，ClickHouse自适应的选择表的连接算法，包括hash-join算法，如果有多个打标则退回merge-join算法
数据复制和数据完整性支持

ClickHouse使用异步多主节点复制，在数据写入任何可用的副本后，所有其余的副本在后台同步数据，系统在不同的副本上维护相同的数据，大多数故障发生后的恢复是自动执行的，或者在复杂情况下半自动执行恢复。
基于角色的访问控制

ClickHouse使用SQL查询管理用户账户，并允许基于角色的访问控制，类似于ANSI SQL标准和流行的关系数据库管理系统中可以找到的配置。

缺点特性

没有成熟的事务支持
缺乏以高速率低延迟插入数据的能力。有批量删除和更新可用于清理和修改数据，以符合GDPR
稀疏索引使得ClickHouse不能有效的通过主键去查询单行数据

性能
根据Yandex内部测试结果，在同类型系统中可以比较的操作场景中ClickHouse展现出了最佳性能（包括高吞吐量的长查询，低延迟的短查询）。

单个大查询的吞吐量

吞吐量可以以每秒的行数和每秒的兆字节数衡量，如果数据在页面缓存中，一个不是太复杂的查询，在现在硬件设备上，单节点数据未压缩的情况下，执行的速率大概为2G——10G每秒（对于最简单的情况可以达到30G每秒）。如果没有将数据放在缓存中，则速率取决于磁盘和数据压缩率，例如如果磁盘子系统允许以400M每秒读取数据，且压缩率为3，则预期速度为1.2G每秒。要获得以每秒行数为单位的速率，则以每秒字节数为单位的速率除以查询中使用的列的字节数总和。例如，提取10个字节，则速度有望达到100-200w行每秒。

对于分布式处理，处理速率以线性增加，但前提是聚合和排序得到的行数不太大。

处理大量端查询是的吞吐量

在相同条件下，ClockHouse可以在一台服务器上处理每秒处理数百个短查询（最佳情况下上千个），由于这种情况在数据分析型的DBMS中并不常见，因此建议每秒最多100个查询。

插入数据性能

建议数据插入，一次传输至少1000行、或每秒一个请求的数据包中。从制表符分隔的数据转储插入到MergeTree表时，插入可以为50MB—200MB每秒。如果插入的行大小约为1KB，则速度位每秒5w至20w行。如果行很小，每秒的行数可以更高。为了提高性能，可以并行进行多个Insert查询，这些查询可以线性扩展。
安装
CentOS
sudo yum install yum-utils
sudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
sudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/clickhouse.repo
sudo yum install clickhouse-server clickhouse-client

sudo clickhouse start
clickhouse-client

Ubantu & Debian
sudo apt-get install apt-transport-https ca-certificates dirmngr
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv E0C56BD4

echo "deb https://repo.clickhouse.tech/deb/stable/ main/" | sudo tee \
    /etc/apt/sources.list.d/clickhouse.list
sudo apt-get update

sudo apt-get install -y clickhouse-server clickhouse-client

sudo service clickhouse start
clickhouse-client

登录之后，和MySQL终端比较像，包括DDL，DQL，DML都类似。

日志目录在
/var/log/clickhouse-server/

测试
创建表
ClickHouse中数据库和数据表的概念大多数数据库管理系统一样，数据库中有多个数据表，创建数据库test1
clickhouse-client --query "create database if not exists test1"

创建表的语法要比数据库复杂一下，包括三要素：

表名称
表结构
表引擎和相关设置，决定了关于这张表的查询如何物理执行的

创建名称为events的表，指定存储引擎为 MergeTree

[root@localhost ~]# clickhouse-client
ClickHouse client version 20.10.3.30 (official build).
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 20.10.3 revision 54441.

localhost :) use test1

USE test1

Ok.

0 rows in set. Elapsed: 0.001 sec. 

localhost :) CREATE TABLE test1.events(id UInt64,status UInt8,eventDate Date,summary String,description String,userId UInt64)ENGINE = MergeTree() PARTITION BY toYYYYMM(eventDate) ORDER BY (eventDate, intHash32(userId)) SAMPLE BY intHash32(userId) SETTINGS index_granularity = 8192

CREATE TABLE test1.events
(
    `id` UInt64,
    `status` UInt8,
    `eventDate` Date,
    `summary` String,
    `description` String,
    `userId` UInt64
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(eventDate)
ORDER BY (eventDate, intHash32(userId))
SAMPLE BY intHash32(userId)
SETTINGS index_granularity = 8192

Ok.

0 rows in set. Elapsed: 0.056 sec.

在上面的导入语句中使用了 MergeTree 存储引擎。
导入数据
数据导入到ClickHouse使用插入语句，像其他SQL数据库一样。但是，数据通常以某种支持的数据提供，代替SQL语句中的vlues语法

下面使用制表符分隔的数据，通过控制台客户端导入到ClickHouse

插入数据如下
1	1	2020-10-11	西安	违法停车	1001
2	1	2020-09-01	北京	闯红灯	1002
3	2	2020-10-12	上海	超速50%	1003
4	2	2020-10-20	大连	占用应急车道	1004
5	1	2020-09-30	深圳	逆行	1002

执行插入语句
clickhouse-client --query "insert into test1.events format TSV" --max_insert_block_size=100000 < e

ClickHouse客户端有许多需要调整的设置，如我们在导入数据的时候指定–max_insert_block_size=100000，查看默认设置可以查询system.setting表,包括没有设置的缺省值，如
[root@localhost ~]# clickhouse-client --query "select name,value,changed,description from system.settings where name like '%max_insert_block%' "
max_insert_block_size	1048545	0	The maximum block size for insertion, if we control the creation of blocks for insertion.

可以在导入后优化表，使用MergeTree引擎的表会在后台合并数据部分优化数据存储，下面这个语句促使引擎立即进行优化，而不是稍后
clickhouse-client --query "OPTIMIZE TABLE test1.events FINAL"

查询数据
例如查询每月发生的次数，如下图。
[root@localhost ~]# clickhouse-client --query "select count(1),toMonth(eventDate) as month from test1.events group by month format TSV"
2	9
3	10

（完）（^_^）

                    
本篇文章介绍表格存储中的宽行流式读功能，简单说就是介绍如何读取一个列很多数据量很大的行，当一次读取不出整行时如何分多次读取，当只需要读取宽行的一部分时如何读取可以性能更好。
宽行与宽行流式读
表格存储的表结构设计中，每行由主键列和属性列构成，主键列按照顺序构成一个主键，唯一的确定一行。读写某一行时，我们必须指定这一行的主键，然后写入或者读取其中的某些属性列。
主键列的名称和类型是在建表时确定好的，作为TableMeta的一部分。但是属性列的列名和数量却是不需要指定的，在实际写入某一行时可以任意设置写入的属性列的列名，只要符合一定的字符集限制。
那么一行总共的属性列数量有没有限制呢？每行的大小是否有限制呢？答案是不限制，因为表格存储从存储机制和读写接口上支持宽行，这也是相比传统数据库的很大优势。 宽行一般而言就是指拥有非常多列的行，这样一行就会很宽，而且一行总大小很大。比如我们反复对同一行写入一些新的列，最终就会产生一个很宽的行。因为每次我们只写入一小部分数据到一个宽行，所以写入性能不是问题，问题在于读取。假如一行数据很大，我们是一次读不出整行的。那么要读取整行怎么办，可以想到假如可以先读取这一行的一部分列，再接着读后面的列，分多次读取就好了。这就是宽行流式读功能(需要使用4.0.0以上版本Java SDK)。
宽行读取方式
下面具体来介绍一下宽行的几种读取方式。
1. 使用startColumn，endColumn读取一定范围的属性列。
在GetRow的参数中，可以通过startColumn和endColumn指定要查询的属性列的起始和终止范围(按照字典序比较)，这样可以读取一个宽行中的一定列名范围的列。
      // 读一行
    SingleRowQueryCriteria criteria = new SingleRowQueryCriteria(TABLE_NAME, primaryKey);

    // 设置读取的列的范围
    criteria.setStartColumn("Col00000");
    criteria.setEndColumn("Col10000");

    // 设置读取最新版本
    criteria.setMaxVersions(1);
    GetRowResponse getRowResponse = client.getRow(new GetRowRequest(criteria));
    Row row = getRowResponse.getRow();

2. 使用ColumnPaginationFilter配合startColumn参数。
ColumnPaginationFilter有两个参数，limit和offset，使用ColumnPaginationFilter读取时，会跳过offset个属性列，然后读取limit个属性列。配合startColumn使用时，会从startColumn开始，跳过offset个属性列，读取limit个属性列。这种方式适合分页读取属性列的场景。
    // 读一行
    SingleRowQueryCriteria criteria = new SingleRowQueryCriteria(TABLE_NAME, primaryKey);

    // 设置从“ColumnX”开始读
    criteria.setStartColumn("ColumnX");

    // 使用ColumnPaginationFilter设置一次要读取的列数, limit=10, offset=0
    criteria.setFilter(new ColumnPaginationFilter(10, 0));

    // 设置读取最新版本
    criteria.setMaxVersions(1);
    GetRowResponse getRowResponse = client.getRow(new GetRowRequest(criteria));
    Row row = getRowResponse.getRow();

3. 使用WideColumnIterator
使用SDK提供的WideColumnIterator，可以通过迭代器的方式读取一行中的全部属性列，SDK内部会流式获取。
    SingleRowQueryCriteria criteria = new SingleRowQueryCriteria(TABLE_NAME, primaryKey);
   
    // 设置读取最新版本
    criteria.setMaxVersions(1);
    
    WideColumnIterator wideColumnIterator = syncClient.createWideColumnIterator(new GetRowRequest(criteria));

    System.out.println(wideColumnIterator.getPrimaryKey());
    while (wideColumnIterator.hasNextColumn()) {
        System.out.println(wideColumnIterator.nextColumn());
    }

总结
表格存储支持自由的属性列名称与个数，支持宽行，给业务的表结构设计提供了很高的灵活性。当表中具有宽行时，通常的读取方式可能不能满足需求，此时可以选用上述的几种方式进行宽行的读取。此外，业务在设计表结构时，如果有宽行需求，也要综合评估是否可将宽行转成多个窄行存储，避免处理宽行读取问题。

        
        
                
    

表格存储TableStore是阿里云自研的面向海量结构化和半结构化数据存储的Serverless NoSQL多模型数据库，被广泛用于社交、物联网、人工智能、元数据和大数据等业务场景。表格存储TableStore采用与Google Bigtable类似的宽表模型，天然的分布式架构，能支撑高吞吐的数据写入以及PB级数据存储。
原生的宽表数据模型，存在一些天然的缺陷，例如无法很好的支持属性列的多条件组合查询，或者更高级的全文检索或空间检索。另外在与计算系统的对接上，特别是流计算场景，传统的大数据Lambda架构，需要用户维护多套存储和计算系统，没法很天然的支持数据在存储和计算系统之间的流转。以上这些问题，均在表格存储TableStore在支持阿里巴巴集团内、阿里云公共云以及专有云等业务中逐渐暴露出来。
表格存储TableStore简单可靠的数据模型和架构，开始承担越来越丰富的不同类型的数据存储，例如时序时空数据、元数据、消息数据、用户行为数据和轨迹溯源数据等。越来越多的客户也开始把表格存储TableStore当做一个统一的在线大数据存储平台，所以我们迫切需要支持海量数据中对数据的高效查询、分析和检索。同时也需要考虑如何更贴近业务，抽象出更贴近业务的数据模型，让数据的接入变得更加简单。
在2019年3月6日的阿里云新品发布会上，表格存储TableStore对以下几个方面做了重大升级:
提供多种数据模型，满足不同数据场景的需求，简化数据建模和开发。
提供多元化索引，满足不同场景下简单或复杂条件查询的功能需求。
提供实时数据通道，无缝对接流计算引擎，支持表内数据的实时更新订阅。
多模型
表格存储TableStore在选择要支持的数据模型的时候，更多的综合了当前业务现状以及用户画像，提取大部分客户的通用需求，总结和定义了产品适合的几大类核心数据场景，来抽象和定义数据模型。数据模型的定义分为『具象』和『抽象』：抽象模型是类似于关系模型或者文档模型的能满足大部分类型数据的抽象，属于比较通用的数据模型；具象模型是对某一具体特征场景数据的抽象，适合单一垂直类的数据场景。表格存储TableStore同时提供抽象和具象模型，当然在介绍这些模型之前，先来明确我们的核心数据场景。
核心场景
表格存储TableStore的核心场景包含这五大类，分别对应不同类型的应用系统，以及每类数据场景下数据有典型的特征和对存储和计算的特殊的需求，简单来说：
时序数据：时序数据解决的是对包含4W(Who, When, Where, What)元素数据的抽象，数据量相对比较庞大，需要存储引擎支持对时间线的索引以及对时间线的时间范围查询。
时空数据：时空数据是基于时序数据加上了空间的维度，同时可能没有时序数据的连续性。总的来说，特征和时序数据比较类似。
消息数据：消息数据广泛存在于消息系统，例如即时通讯消息系统或者Feeds流消息系统内。消息的存储和传递更像是消息队列模型，但是要求消息队列能够提供海量级消息存储以及海量Topic，这是传统专业级消息队列产品所无法支撑的。
元数据：这类元数据属于非关系类元数据，例如历史订单数据、图片智能标签元数据点。特点是量级比较大，每个数据存在的属性比较多且是稀疏的，要求存储能够支持对各种维度属性的条件过滤，对查询可用性有比较高的要求。
大数据：这是Bigtable模型所对应的最主要数据场景，特点是数据量极其庞大，需要很好的支持批量计算。
TableStore多模型
基于以上总结的表格存储TableStore所针对的核心数据场景，我们从业务需求中抽象出三大类数据模型，分别是：WideColumn(宽行模型)、Timeline(消息模型)和Timestream(时序模型)。
宽行模型
宽行模型是由Bigtable提出，特征是：
三维数据结构：对比MySQL的二维数据结构，在属性列这一维度上多了版本属性。同一列数据可以存储多个不同版本，并可定义不同的生命周期，主要用于数据的自动化生命周期管理。
稀疏列：表不需要有强格式定义，可以任意的对每一行定义列和类型。
大表：一张表可以存储万亿行数据，大表数据根据分区键的范围来分区，不同的分区由不同的机器来加载和提供服务，能比较简单的实现分布式。
宽行模型主要应用于元数据和大数据场景，一些典型应用场景可参考：
消息模型
消息模型是表格存储TableStore针对消息数据所抽象的数据模型，主要适用于消息系统中海量消息存储和同步，特征是：
轻量级消息队列：大表中能模拟海量消息队列，虽然不能完全模拟一个真正消息队列的所有能力，但是能满足对消息最基本的存储和同步能力。
消息永久存储：能保证对数据的永久存储，消息写入和同步的性能不会受到数据规模的影响。
模型同步模型：对消息同步模型没有严格要求，应用层可以根据自己的业务特征，同时实现推模型或者拉模型。
消息模型主要应用于消息数据场景，一些典型应用场景可参考：
时序模型
时序模型主要应用与时序和时空场景，也是表格存储TableStore综合了业界主流的时序数据库，所定义和抽象的数据模型，特征是：
海量数据存储：能提供PB级数据存储，可打造多租户的时序数据库底层存储，写入和查询性能不受数据规模的影响。
时间线索引：提供对时间线的索引，能满足对时间线Tag的任何条件组合过滤，并且能够支持比较海量的时间线规模。
完整的模型定义：在业界标杆的时序数据库模型定义上，补充了空间维度的定义并且提供空间索引，以及支持多列值支持，不限制只对数值类型的支持。
时序模型主要应用于时序和时空数据，一些典型应用场景可参考：
查询优化
上述场景中提到的对于表内数据的查询优化，最基本手段就是需要对数据建立索引。表格存储TableStore选择的做法是，对于不同类型的查询场景，我们需要提供不同类型的索引。业界对海量数据建立索引的方案有多种，在传统技术架构中应用比较多的主要包括Phoenix SQL二级索引或者Elasticsearch搜索引擎。二级索引能提供高效的固定维度的条件查询，查询性能不受数据规模的影响，而Elasticsearch搜索引擎能提供比较灵活的多条件组合查询、全文索引和空间索引。两种类型的索引实现，有不同的优缺点，以及适用于不同的场景。表格存储TableStore的做法是同时实现和这两类索引原理类似的索引，来满足不同场景下对查询的不同需求。
全局二级索引
当用户创建一张表时，其所有PK列构成了该表的『一级索引』：即给定完整的行主键，可以迅速的查找到该主键所在行的数据。但是越来越多的业务场景中，需要对表的属性列，或者非主键前缀列进行条件上的查询，由于没有足够的索引信息，只能通过进行全表的扫描，配合条件过滤，来得到最终结果，特别是全表数据较多，但最终结果很少时，全表扫描将浪费极大的资源。表格存储TableStore提供的全局二级索引功能支持在指定列上建立索引，生成的索引表中数据按用户指定的索引列进行排序，主表的每一笔写入都将自动异步同步到索引表。用户只向主表中写入数据，根据索引表进行查询，在许多场景下，将极大的提高查询的效率。更多的技术解读，请参考这篇文章《通过全局二级索引加速表格存储上的数据查询》。
多元索引
表格存储TableStore多元索引是表格存储TableStore重点打造的一个多功能索引能力，旨在补位二级索引无法覆盖的场景，解决大数据场景下的复杂查询和轻量级分析问题，比如多字段组合查询、前缀查询、通配符查询、嵌套查询、全文检索(分词)、地理位置查询、排序和统计聚合等功能。关于对多元索引的更多解读，可以阅读这篇文章《TableStore多元索引，大数据查询的利器》，关于多元索引的更多应用场景，可以参考以下文章：
计算衔接
表格存储TableStore已经与比较多的开源大数据计算引擎以及阿里云计算产品衔接，例如Hive、Spark、MaxCompute以及DataLakeAnalytics等，覆盖了批量计算和交互式分析。可以由第三方产品提供的数据通道服务，将表格存储TableStore上的数据全量或者增量复制到计算系统，也可以由计算系统通过Connector直接访问表内的数据。
批量计算和交互式分析访问数据存储的方式是批量扫描，主要通过自定义数据Connector的方式。但是其他类计算系统例如流计算或者函数计算(Lambda架构)，数据是需要流式的并且实时的从存储系统到计算系统。这个能力是传统开源Bigtable类数据库所做不到的，例如HBase或Cassandra。
如果表内的数据可以实时的流动，那将给表带来更丰富的计算和处理场景，例如可以做跨域复制、备份，或者接入流计算引擎做实时分析或者函数计算做事件触发式编程，也可以由应用方自定义数据处理，来做个性化数据处理。
表格存储TableStore提供了全新的实时数据通道，能支持订阅表内的实时数据更新，来扩充表格存储TableStore的计算能力。
通道服务
TableStore 通道服务(Tunnel Service)是基于表格存储数据接口之上的全增量一体化服务，通道服务为用户提供了增量、全量、增量加全量三种类型的分布式数据实时消费通道。通过为数据表建立Tunnel Service数据通道，可以简单地实现对表中历史存量和新增数据的消费处理。基于通道服务用户可以轻松的实现如图所示的场景架构：数据同步、搬迁和备份，流式数据处理以及事件驱动架构。
关于对通道服务TunnelService更多的技术解读，可以参考这篇文章：《大数据同步利器: 表格存储全增量一体消费通道》。基于通道服务的更多应用场景，可以参考以下文章：
总结
表格存储TableStore通过同时提供具象和抽象的数据模型，来满足不同核心数据场景的要求，更贴近业务抽象；提供多元化索引(全局二级索引和多元索引)来满足不同类型场景条件查询需求；提供全新的实时数据通道，来扩充实时计算的能力以及可自定义的实时数据处理。这三大方面的新功能发布，能够让我们在数据模型、灵活查询以及数据分析层面，都有一定的提升，帮助打造统一的在线数据存储平台。
原文链接
更多技术干货 请关注阿里云云栖社区微信号 ：yunqiinsight