业务背景：自纵行科技在 2020 年推出 ZETag 云标签以来广受市场好评，目前曾经在物流、资产治理、库存盘点等畛域有了许多落地我的项目。在业务量急速减少的过程中，ZETag 云平台作为解决方案中重要的一环，也面临了许多挑战与考验。本文分享了在建设 ZETag 云平台过程中，咱们在架构设计方面的一些思路与实际。
面临的挑战
1）设施量与数据量的疾速减少
不同于传统的物联网终端，低成本 ZETag 云标签更多用于物的定位与追踪，同时，还有次抛等新的利用场景。因而，ZETag 云标签的数量远远大于传统的物联网终端，万级别标签每客户将是业务常态，能够预估 ZETag 云平台须要治理的标签量将在百万到千万级，每天须要保留的上报数据将达到亿级，这对平台数据存储的写性能、扩展性以及存储老本将是一个微小的考验。
2）如何在保留云上扩展性的同时，升高私有化部署的老本
物联网行业是一个典型的 B2B 行业，私有化部署是很多对数据私密性较高要求的客户的强需要，一个简单的大数据平台架构兴许可能满足咱们对性能、扩展性的需要，然而却同样有十分高的运维老本与设施老本，对于大部分老本敏感的中小长尾客户来说，较高的施行运维老本是难以承受的，因而在离线部署公有云的场景，除了性能之外，整体架构的轻量化也是一个重要的考量因素。
3）如何反对实时灵便的多维分析，开掘数据价值
ZETag 云标签业务大多波及指标告警、实时追踪、多维分析报表等，端到端的提早须要管制在秒级别，同时也须要满足客户不同条件、维度、指标的实时统计与剖析，因而对于数据的查问提早、灵活性都有比拟高的要求。
技术选型
综合来看，查的快、写的快、成本低是咱们三个比拟外围的诉求。咱们调研了业内常见的开源分布式 OLAP 数据库，最终确定了 ClickHouse+MySQL 混合存储的形式作为 ZETag 云平台最终存储计划。
其中，ClickHouse 用于存储网关、终端、标签的事件数据，例如心跳、注册等。同时，MySQL 专一存储设备的物模型数据，通过两者的协同配合来更好的撑持平台的业务指标，其中 ClickHouse 的一些独特的个性是咱们抉择它的次要起因。
1. 相比其余时序数据库，例如 ElasticSearch、HBase 等，ClickHouse 的 LSM-Tree 实现机制更为极致，领有更弱小的写性能，这意味着能够用更少的老本撑持更大的数据量。
2.ClickHouse 反对 Apache 2.0 license 开源协定，相比 ElasticSearch 协定更加敌对，同时也不像 InfluxDB，开源版本有性能上的限度。
3.ClickHouse 的架构十分的轻量，相比其余数据库产品，例如 OpenTSDB 依赖 Hbase、Druid.io 依赖 HDFS，ClickHouse 单机版本齐全能够不依赖第三方组件，并且只有一个服务过程，有着非常低的离线部署运维老本。
4. 因为 ClickHouse 的 MPP 架构及优良的工程实现，查问性能在各大基准测试榜中名落孙山。
个性剖析
存储构造
LSM-Tree 是业内存储时序数据的罕用数据结构，它的外围思路其实非常简单，每次有数据写入时并不将数据实时写入到磁盘，而是先缓存在内存的 memTable 中并应用归并排序的形式将内存中的数据合并，等到积攒到肯定阈值之后，再追加到磁盘中，并依照肯定的频率与触发阈值将磁盘存储的数据文件进行合并。
这种计划利用了硬盘程序写性能远大于随机写的个性，升高了硬盘的寻道工夫，对于物联网设施所产生时序数据这种写远大于读的场景来说有十分好的优化成果。
由下图能够看到，硬盘的程序 IO 性能与随机 IO 性能有着微小的差距。
传统的 LSM-Tree 虽在写性能上很优良，但随之带来的读放大与写放大仍然是业内难以解决的问题，目前最优良的 LSM-Tree 构造数据库读写放大倍数也在 20 倍以上，读写放大次要来自于几个方面：
1. 因为数据须要 buffer 在内存之中，为了保障刹时停机例如断电时数据不失落，因而所有内存里的数据都须要记录一份 WAL(Write Ahead Log)，用于在极其时刻进行数据恢复。
2. 后盾进行数据文件合并时是一个先读取再写入的过程，这个行为同样会造成写放大。
3. 当数据库产生数据查问操作时，因为 LSM-Tree 写数据的形式会生成较多的小文件，读申请往往须要逾越内存与硬盘的多个 memTable 与数据文件能力获取到正确的后果。
相比其余应用 LSM-Tree 的数据库，ClickHouse 在设计上间接勾销了 memTable 的内存聚合阶段，只对同一写入批次的数据做排序并间接落盘。因而，齐全不须要传统的写 WAL 的过程，缩小了数据的反复写入。
同时，ClickHouse 也限度了数据的实时批改，这样就缩小了合并时产生的读写放大，这个思路相当于限缩了数据库的应用场景，但却换取了更弱小的读写性能。
对于物联网设施产生的数据来说，写入时原本就是肯定距离的批量写入，同时极少有数据批改的场景，与 ClickHouse 的优化方向正好统一。
列式存储带来的极高压缩比
相比于传统的行存储数据库（例如 MySQL），ClickHouse 采纳列式存储的形式存储数据，而列式存储，可能带来更极致的压缩比。
压缩的实质是依照肯定步长对数据进行匹配扫描，当发现重复部分的时候就进行编码转换。数据中的反复项越多，则压缩率越高，举一个简略的例子：
压缩前：12345678_2345678
压缩后：12345678_(8,7)
上述示例中的 (8，7)，示意如果从下划线开始向前挪动 8 个字节，并向前匹配到 7 个字节长度的反复项，即这里的 2345678，实在的压缩算法必定比这个简略的例子简单，但实质是一样的。不言而喻，同一个列字段的数据，因为它们领有雷同的数据类型和事实语义，反复项的可能性天然就更高，在大数据量的场景下，更高的压缩比，会给咱们带来更大的性能和老本劣势。
1. 剖析场景中往往有须要读大量行然而多数列的状况。在行存模式下，数据按行间断存储，所有列的数据都存储在一个 block 中，不参加计算的列在 IO 时也要全副读出，读取操作被重大放大。而列存模式下，只须要读取参加计算的列即可，极大的减低了 IO cost，减速了查问。
2. 更高的压缩比意味着更小的文件，从磁盘中读取相应数据耗时更短。
3. 高压缩比，意味着等同大小的内存可能寄存更多数据，零碎 cache 成果更好。
4. 同样更高的压缩比下，雷同大小的硬盘能够存储更多的数据，大大地升高了存储老本。
极低的查问提早
在索引正确的状况下，ClickHouse 能够说是世界上最快的 OLAP 剖析引擎之一。这里快指的就是查问提早，简略说就是用户发动一次查问到用户获取到后果的工夫，这种快很大的起因也来自于 ClickHouse 极其的设计思路与优良的工程实现。
ClickHouse 的大部分计算操作，都基于 CPU 的 SIMD 指令，SIMD 的全称是 Single Instruction Multiple Data，即用单条指令操作多条数据，它的原理是在 CPU 寄存器层面实现数据的并行操作，例如一次 for 循环每次解决一条数据，有 8 条数据则须要循环 8 次，但应用 SIMD 指令能够让这 8 条数据并行处理，从而在一次就失去后果，这种形式被称为向量化计算。
ClickHouse 的每一次查问或统计分析操作，都会尽可能的应用所有的 CPU 资源来进行并行处理，这种形式可能让便宜的服务器同样领有极低的查问提早，从而在海量数据的场景下保障平台产品的晦涩与疾速，而疾速和晦涩就是最好的用户体验。
ClickHouse 在工程实现上也同样保持了快这个准则，能够看到在 ClickHouse 源码中一直地给函数或者算子的部分逻辑减少更多的变种实现，以晋升在特定情景下的性能，依据不同数据类型、常量和变量、基数的高下抉择不同的算法。
例如 ClickHouse 的 hash agg，用模板实现了 30 多个版本，笼罩了最常见的 group key 的类型，再比方去重计数函数 uniqCombined 函数，当数据量较小的时候会抉择 Array 保留，当数据量中等的时候会抉择 HashSet 保留，当数据量很大的时候，则应用 HyperLogLog 算法等等，Clickhouse 的性能，就是大量相似的工程优化堆积起来的。
那么代价是什么呢？
然而，世界上并没有白璧无瑕的计划，方案设计更像是一场 trade-off，比起理解它的长处，更重要的是能不能承受它的毛病。
为了更极致的写入性能，ClickHouse 去掉 memtable 缓存数据再写入的机制以及实时批改的能力，前者须要客户端进行额定的攒批操作，而后者限缩了数据库的应用场景。ClickHouse 其实更像一个单机的数据库，极致的单表性能优化，十分轻量的装置部署流程，这些给咱们带来了非常低的离线部署老本，但在大规模分布式场景下却有着一些缺点。
在分布式查问的场景上，ClickHouse 应用 Distributed Table 来实现分布式解决，查问 Distributed Table 相当于对不同节点上的单机 Table 进行一个 UNION ALL，这种方法凑合单表查问还能够，但波及多表 Join 就有点力不从心了，在分布式多表 Join 的场景下，因为没有 Data shuffling 之类的性能，ClickHouse 须要消耗更多的内存和带宽来缓存和迁徙数据，造成了性能的重大降落，大部分人不得不应用大宽表的形式来躲避这个问题。
另外，运维一个分布式 ClickHouse 集群也是十分头疼的一个点。ClickHouse 并不具备数据平衡性能，提供的 Distributed Table 因为写入性能太差形同虚设，往往须要通过业务层来保障散发的数据足够平均，开源的 ClickHouse 并没有集中的元数据管理，ON CLUSTER 语法可能节约肯定的操作，但个体扩容当前因为新的节点并不会同步元数据信息，也不会主动均衡数据的负载，因而须要大量的人工染指。
作为从规范的计算存储一体的 Shared-nothing 构造倒退而来的数据库，ClickHouse 对于云原生和存算拆散的反对也比拟个别，目前社区正在朝这个方向致力，只能说还算是将来可期。
实践经验
写入优化
因为 ClickHouse 非凡的数据写入形式，为了取得更高的性能咱们须要在写入客户端上进行肯定的定制化开发。
在整体架构上，咱们次要应用 Flink 来实现 ClickHouse 数据的写入，因为目前还没有官网的 Connector，咱们基于社区接口自研了本人的 ClickHouse Connector，次要实现了以下性能：
1. 实现了基于表与分区的攒批性能，因为 ClickHouse 非凡的写入策略，雷同表与分区数据在同一批次进行写入会有更好的性能，同时也能缩小写入时生成的文件数量。
2. 反对通过配置不同算法将数据以不同的形式散发到节点的 shard 中，实现了惯例的 Hash、轮询、加权等等算法。
3. 背压感知与限流性能，通过查问 ClickHouse 不同 shard 的文件碎片数，经限流算法评估后在必要时触发 Flink 的反压机制，避免 ClickHouse 客户端报错造成写入性能继续降落。
4. 反对通过接入设施数自动化调节攒批的各种参数、包含数据量大小、条数、间隔时间等等，缩小在参数配置时的工作量与门槛。
冷热拆散
时序数据的价值往往与工夫相干，越凑近以后工夫的热数据越有价值，会被频繁的应用，越长远的冷数据价值绝对较低，但仍然须要长期的存储。因而，能够通过冷热拆散的策略将近期高价值的数据存储在绝对低廉的存储来晋升统计分析的性能，并在一段时间后将数据挪动到绝对便宜的大容量存储中，这种形式能够在不影响用户体验的状况下较好的节俭数据的存储老本。
在 ClickHouse 19.15 版本之后开始原生反对冷热拆散的存储策略，通过相应配置能够依照工夫或大小主动的将数据迁徙到冷盘。
<storage_configuration>
<policies>
<!-- 冷热拆散计划 -->
<moving_from_ssd_to_hdd>
<volumes>
<hot>
<disk>disk_ssd</disk>
<max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
</hot>
<cold>
<disk>disk_hdd</disk>
</cold>
</volumes>
<move_factor>0.2</move_factor>
</moving_from_ssd_to_hdd>
</policies>
</storage_configuration>上述配置中配置了一个名为 moving_from_ssd_to_hdd 的存储策略，该策略蕴含了 hot 和 cold 两个 volume。
在 volumes 的前后程序决定了 volume 的优先级，意味着 part 会优先在这个卷上生成，且没有轮询策略。因而 volumes 内的程序是敏感的。hot 中含有一块 ssd 类型的 disk；cold 中含有一块 hdd 类型的 disk。move_factor 定义了前一个卷残余存储空间的量。当存储空间小于这个值时，会将前一个 volume 中绝对较早的 part 迁徙到前面的 volume 中。上述配置示意，当 hotvolume 的存储空间超过 80% 时，便将数据迁徙到 cold 中。
字段扩大场景
查问中须要裁减字段是十分常见的业务场景，在咱们的架构中局部字段甚至存在不同的数据库例如 MySQL 中。目前，业内的常见做法是通过流式计算引擎，例如 Flink、Storm 等，在入库之前进行数据字段的拼接，在 ClickHouse 中间接存储计算后的数据。这种计划能够最大的保证数据的查问效率，但须要付出额定的开发工作量以及硬件资源，特地是 SQL JOIN 的场景，须要在流式计算引擎中缓存大量实时更新的状态，有着很大的资源耗费。
而咱们在实践中发现，有些更新频率很低的字段裁减场景，例如设施型号、所属企业等其实有更好的解决方案，通过 ClickHouse 提供的 Dictionaries 个性可能代替局部更新频率较低 JOIN 场景。
CREATE [OR REPLACE] DICTIONARY [IF NOT EXISTS] [db.]dictionary_name [ON CLUSTER cluster]
(key1 type1 [DEFAULT|EXPRESSION expr1] [IS_OBJECT_ID],
key2 type2 [DEFAULT|EXPRESSION expr2],
attr1 type2 [DEFAULT|EXPRESSION expr3] [HIERARCHICAL|INJECTIVE],
attr2 type2 [DEFAULT|EXPRESSION expr4] [HIERARCHICAL|INJECTIVE]
)
PRIMARY KEY key1, key2
SOURCE(SOURCE_NAME([param1 value1 ... paramN valueN]))
LAYOUT(LAYOUT_NAME([param_name param_value]))
LIFETIME({MIN min_val MAX max_val | max_val})
SETTINGS(setting_name = setting_value, setting_name = setting_value, ...)
COMMENT 'Comment'ClickHouse 反对将内部数据源例如 MySQL、Redis、PostgreSQL 等等配置为一个内置的字典，在查问中能够通过函数进行 key -> attributes 的转换，变相的实现了相似 JOIN 的性能，这种形式相比于 JOIN 有着更好的性价比。
总结
在物联网这个业务场景下，须要存储大量的时序事件数据并且不须要预先进行批改，刚好符合了 ClickHouse 的写入性能劣势并且躲避了应用场景上的劣势，同时 ClickHouse 部署成本低、架构轻量化的劣势也很合乎以后物联网客户需要。
目前，ZETag 云平台曾经对接大量的网关、标签、设施，帮忙许多客户实现了降本增效，这些都离不开一个高效稳固的存储计算引擎的帮忙，后续咱们也会继续优化产品，积攒优良实际，打造一个更弱小、稳固、通用的物联网云平台。