演讲的主题是 时序数据库现状及核心技术/问题，因为技术都是为解决具体问题生的。
我们将从如下3个视角的分享，分别从：
- 领域趋势方面和大家聊聊时序数据库的现状和未来发展空间。
- 核心技术角度和大家聊聊时序数据库面临怎样的实际问题，将会以怎样的技术手段来解决。
- 从应用场景和价值缔造角度我们简单聊聊如何才能让时序数据库在具体应用场景中产生业务价值。
那么，在开始今天的分享之前，先简单的介绍一下我的个人信息：
我是 孙金城，阿里花名 “金竹”。
目前在阿里工作已经接近10年，以ApacheFlink为切入点，在流计算领域贡献了5年，目前以阿里巴巴物联网分析团队负责人的角色，基于ApacheIoTDB对时序数据存储领域进行探索。
在开源领域，目前是两个Apache顶级项目的PMC成员，也是ApacheMember，同时也在支持Apache本土社区的发展，是ALCBeijing的成员，Apache孵化器的IPMC 成员，以及开放原子开源基金会的孵化器导师。
那么，在众多的开源 参与和贡献 的同时，我个人也非常喜欢做一些技术类的博客和视频分享，也欢迎大家关注我的个人公众号，大家可以保持线下的持续交流。
好的，我们开始今天的第一部分，我们看看时序数据库目前处在一个怎样的趋势，是什么造就了时序数据库的快速发展？
从我的角度看，聊存储，我喜欢从数据的角度切入。。
目前不仅仅是数据时代，而且数据的规模是惊人的，我们处在一个大数据时代。那么我们所说的大数据时代的数据规模到底是怎样的呢？
根据某研究院发布的统计数据，近年，随着人工智能、5G，AIoT等技术的推动，全球数据量正在无限地增加。2018年全球数据总量为33ZB，在2019年约达到45ZB。按照这样的增长趋势，到2025年，全年将会有175ZB的数据产生。
在希捷的首页，有一句话，这里分享给大家：
全球数据领域将从2019年的45ZB增长到2025年的175ZB，全球数据的近30%将需要实时处理，您的企业是否已经做好准备？同样带着这个问题，我们看看实时数据库领域是否做好了准备？
那么，到2025年每年175ZB的数据从哪里来的呢？我们从云/边/端三个角度看数据的创建和存储。
随着网络的高速发展，尤其是5G时代的到来，数据越来越多的进入云端。那么我们所说的Core/Edge/Endpoint(云/边/端）分别指的是什么呢？
- 云(Core) - 这包括企业中指定的计算数据中心和云提供商。它包括各种云计算，公共云、私有云云和混合云。
- 边(Edge) - 边缘是指不在核心数据中心的企业级服务器和设备。这包括服务器机房、现场服务器、还有一些较小的数据中心，这些数据中心位于距离设备较近的区域，以加快响应。
- 端(Endpoint) - 端包括网络边缘的所有设备，包括个人电脑、电话、联网汽车、可穿戴备以及工业传感器等。
那么这些数据来源，有哪些是我们日常工作生活可以感知到的呢？我们接下来简单举例分析一下：
作为在阿里工作近10年的我，对我来说感觉最近的数据是一年一度的双11全球狂欢。我们发现自2009年以来，双11每年的成交额飞速增长，到2020年竟然高达4982亿。这个数字背后，说明了大量数据的产生。但是相对于175ZB的数据来说，这些交易数据，监控数据，只是冰山一角。为什么这样说呢？我们继续往下看。。。
这里同样又一份关于全球设备连接的统计数据，到2020年全球有500亿的设备数据上云，这些设备覆盖了很多实际场景，比如：智能生活，智能城市，智能农业，
更值得大家关注的是智能制造，也即是工业物联网领域。在5G和工业4.0的的大背景下，工业物联网也将会是下一个技术趋势所在。。。
我们说到技术发展趋势，Gartner的数据是大家非常信任的，在2021年Gartner又指明了9大技术趋势，如果大家关注Gartner的报告，我们发现这9大战略技术趋势和前三年有了一些变化。
2018强调云向边缘挺进，2019主张赋权边缘，2020更加强调流量的处理要靠近设备本地，其实也就是端和边的计算技术。这连续三年都明确提到了端/边，也就是物联网领域，那么2021的战略趋势和物联网有怎样的关系呢？
2021强调的分布式云就是强调了物联网领域已经走进云边端一体化的进程，分布式云将取代私有云。分布式云的架构更强调了中心云计算能力下沉的时代趋势。
分布式云的多样性也囊括了物联网领和边缘计算的技术方向。那么在这样一个大的技术趋势下，时序数据库当前处在一个怎样的阶段呢？
国家对物联网领域，尤其是工业物联网领域是高度重视的，早在2017年就提出了指导意见，明确了三个阶段性的发展目标：在2025年之前重点在基础设施的建设，到2035年具备平台化能力，最终达到应有层面的落地。那么实际上各个大厂的发展都是超前于这份指导性建议的发展目标额，目前各个云厂商已经基本形成了各自的工业物联网平台的搭建，后续的重点是平台的增强和实际应用的创新发展。那么在这样一个高速发展的阶段，各个大厂都在解决这这样的问题呢？
其实，物联网领域的数据产生，大部分来自于 工业物联网，刚才大家看到，物联网领域设备连接在2020年已经超过500亿，我们以一个挖掘机工矿信息来说，一个设备就有5000多的工况指标要采集，数据每秒都在不停的采集，数据量可畏是惊人的，那么在千亿的工矿数据和ZB级别的时序数据面前，我们面临怎样的难题呢？
大家会想到的是数据上云的带宽流量成本问题，但幸运的是，在过去的20年中，有线宽带服务每兆比特的费用下降了98％，从2000年的平均28.13美元下降到2020年的0.64美元。所以低流量成本的情况下，ZB级别的存储成本问题就更为显著。技术都是为领域问题而生，面对这样的领域问题，存储领域又有这样的技术变化呢？
根据DB-Engines的统计数据，我们发现，在各种数据库存储产品中，时序数据库的发展是最受欢迎，发展是最快的。
也就是说，5G和工业4.0的发展，大量时序数据的产生，促就了时序数据库的快速发展。那么，目前都有哪些时序数据库产品呢？
同样这个统计也是来自DB-engines网站，目前我们已经有几十种时序数据库产品，这些产品有些是开源的，有些是各个大厂研发的商业产品。
目前来看，大概有20%+的商业产品，近80%来自开源社区，这里也多说一句，拥抱开源同样也是大势所趋。
好的，趋势方面我们就了解到这里，接下来我们细致的看看现在的时序数据库有哪些特点，如何分类，时序数据库又🈶️哪些核心技术。
首先，我们从存储架构角度，看看时序数据库的分类情况。
- 第一类就是是基于关系数据库的时序数据库，比如timescale。
- 第二类就是基于KV的时序数据库，比如OpenTSDB。
- 第三类就是专门面向时序数据场景的原生时序数据库，比如InfluxDB,IoTDB和TDengine等。
当然持久化角度看，还有很多优秀的内存时序数据库，比如：Google的Monarch,Facebook基于Gorilla论文实现的产品。那么不论基于怎样的架构，这些时序数据库都要解决的共性问题有是什么呢？
我们前面说最大的数据来源是工业领域的各种设备传感器数据，这些设备的工况数据收集和处理将给存储和计算带来巨大的挑战。我们还是以一个具体的案例来说，这是GoldWind发电数据采集，GoldWind有超过2w个风机，一个风机有120-510个传感器，采集频率高达50Hz，就是每个传感器1秒50个数据点采集峰值。这要算下来就是每秒5亿个时序指标点的数据。这个数据量让数据采集/存储/计算面临很大的挑战。同时还有我们业务中的一些非常常见的查询需求。所以时序数据的存储将要解决写入吞吐问题，还有数据查询分析的性能问题。
同时，时序数据领域还有一个很大的领域特点，或者说是领域问题，那就是弱网环境下，时序数据的乱序是一种常态。
乱序问题问什么是时序数据场景的核心问题呢，我看一个具体的智能制造的案例，如图。是一个工业冶炼能耗控制的例子。核心需求是，在云端进行大量的实时模型训练，然后模型下推到边缘端，在边缘端利用时序数据库进行数据的本地存储和局部数据数据预测，进而控制本地的熔炉燃料投放。比如，5秒钟一个计算窗口，那么乱序造成的计算不精准，将会对能源消耗和冶炼质量带来很大的影响。所以说，乱序问题的解决也是时序数据价值最大化的核心问题所在。
那么从存储架构的维度看，基于关系/基于KV和原生时序数据库的写入速度有怎样的排布？
宏观来看，基于关系数据库的时序数据库写入速度远远慢于，基于KV和原生的时序数据库。为什么会有这样的判断呢？这个结论还是从底层存储架构设计角度得出的。
关系数据库的存储写入架构是基于B-Tree或者B+Tree，而KV和原生的时序数据库都是基于LSM-Tree进行数据写入设计的。不同的数据结构对写入性能产生巨大的影响。我们进一步细聊一下其中的原因。。。
聊到存储写入，我们立即会想到磁盘，我们应用数据写到磁盘会经过内存，然后持久化到磁盘。那么这个过程中，写入的核心耗时是在什么阶段呢？
就是大家熟知的磁盘IO部分。那我们看看怎样的磁盘IO才是高性能的？而怎样的磁盘IO又是低效的呢？
我们知道 扇区 是磁盘的最小组成单元，通常是512字节,文件系统/数据库不是一个扇区一个扇区的来读数据，因为太慢了，所以有了block（块）的概念，它是一个块一个块的读取的，block才是文件存取的最小单位。每个块的大小是 4~64KB，但是这个数值是可配置。一般来说磁盘访问一个磁盘块平均要用10ms左右，因此，我们有必要做一些事情来减少磁盘的平均访问时间来提高写入性能。大家都知道，顺序IO性能远高于随机IO，随机I/O可能是因为磁盘碎片导致磁盘空间不连续，或者当前block空间小于文件大小导致的。连续 I/O 比随机 I/O 效率高的原因是：在做连续 I/O 的时候，磁头几乎不用换道，或者换道的时间很短；而对于随机 I/O，很多的话，会导致磁头不停地换道，造成效率的极大降低。那么刚才说的B+Tree和 LSM-Tree的数据结构，与磁盘IO有怎样的关系呢？
我们先来看看Btree和B+Tree的的写入复杂度，这里我们核心看对磁盘的访问，
所以我以DAM的维度看两种数据结果的复杂度，我们会发现不论是BTree和B+Tree写入和查询复杂度都是LogBN，B是阶数，N是节点数。感兴趣算法复杂度的推导的朋友可以扫描左下角二维码查看推导过程。那么，既然算法复杂度一样，在实际的存储产品中这两种设计有怎样的区别呢，我们先看看BTree和B+Tree的数据结构设计的区别：
核心区别就是：是否在非叶子节点存储数据以及在叶子节点是否以指针连接相邻节点。那么问题来了，在存储对磁盘访问的角度考虑，我们是选择BTree还是选择B+Tree呢？这里面我们就要加入另一个变量因素，就是存储产品一次读取磁盘的block因素和每个节点数据和指针大小因素。根据BTree和B+Tree的数据结构特点，在一次读取磁盘的Block大小一定的情况下，一个Block的磁盘读取所包含节点越多那么在数据量一定的情况下，树的阶数越大，也就是LogBN的B越大，进而读取磁盘次数越少性能越好。这句话的信息点有点多，相信如果不是存储领域的朋友可能会有若干个“为什么”，那么如果除了对这个结论感兴趣，对细节推到部分也感兴趣的话，我的公众号里面有一个近2小时的细致剖析，大家可以关注我的公众号，在会后进行选择性观看。
好的，那么我们再回到，为什么BTree/B+Tree的写入会设涉及到随机IO问题。
假设我们有如上数据按顺序进入存储系统，如果存储系统采用的是BTree进行设计的，我们简单分析一下写入过程。
首先数据陆陆续续的到来，35，3，90这个小树是如何变化的。。先来3，再来 35，再来 90，我们构建数据结构，如图，35左右是3和90，数据再陆续到来，当17到来的是，数据如何变化？17比35小，所以17再左子树。假设这时候我进行了一次持久化操作，然后，后续数据陆续到来。。。当26到来的时候，26比35小，在35的左子树，但是35左边已经有2个data了，做3阶Btree，节点超了。因为节点超了，所以我们需要进行节点分裂，如图，17上提与35同一层级。这时候我们假设再次磁盘持久化处理，我们发现3和17已经不在一个数据块了，17和35又重新写到了磁盘上的一个数据块。
数据不断的到来，数据的节点不断的变化，磁盘持久化也不断发生。
这个变化过程中大家发现机遇BTree和B+Bree的设计，写入磁盘的数据是有更新操作的，进而造成了大量随机IO。
那么我们再来看看LSM-Tree的为什么是顺序IO？其实，LSM核心思想是放弃部分读能力，换取写入的最大化能力。我们看到LSM-Tree的写入复杂度是O（1）。具体的插入流程如下：
- 来请求之后 首先写入write ahead文件，然后进行内存的更新，
- 更新完成之后，就返回成功。那么数据是如何持久化的呢？
- 当内存到一定大小后，就将内存变成immutable，进行持久化操作。
- 最后刷盘进行持久化成功之后，会有后续的 Merging Compaction在后台进行。
所以基于LSM Tree结构完美的解决了写入的高吞吐问题。
那么，解决的写入问题，基于LSM-Tree的时序数据库产品是如何解决
查询性能问题的呢？我看OpenTSDB查询逻辑是怎样的？
- 查询请求来了，会对各种索引进行查询。。。
- 首先是以二分法查询MemTable，
- 然后查询immutableMem-table，
- 如果都没有查到，就查询磁盘文件
当然在查询过程中还伴随各种优化，比如BloomFilter的应用。
虽然都是基于LSM-Tree的设计，但不同的产品有不同的优化定制，
比如我们再来看看InfluxDB的设计。。
- 同样数据来了也是第一写入到WAL文件。
- 接下来再更新内存Mem-Table之前，InfluxDB出于查询性能的考虑，在这个环节增加了内存索引构建。
- 然后才是内存更新，
- 最后返回客户端成功信息。
当然，在Mem-Table部分，InfluxDB也做了局部优化，利用hash进行分布优化。同时在持久化时机上面也考虑了内存大小和刷盘时间周期。其实，InfluxDB设计了自己的TSMFile格式，文件增加了索引建立。这里和大家提一句就是，InfluxDB的设计充分考虑时序数据的时间特点，在Mem-Table中的Map中采用timestamp作为key的组成部分。从1.8版本看，InfluxDB代码里面没有看到将内存变成immutable的部分。在InfluxDB的Compaction时候也考虑若干优化因素。比如压缩算法的选择等。最后，InfluxDB还设计了自己的索引结构，TSI极大的加速了数据查询性能。
好的，看完OpenTSDB和InfluxDB，我们再来看看Apache顶级项目 IoTDB。
IoTDB为了提高查询速度，不仅定制了 索引结构还增加了查询优化器的支持。
更值得大家关注的是，IoTDB针对工业物联网领域时序数据乱序问题对LSM-Tree
进行了优化改造，在内存和文件上面都考虑乱序的处理。出于今天接下来还有
黄老师对ApacheIoTDB进行细节分享，我这里先对IoTDB简单说这么多。
OK，那么我们想想，在时序数据库领域到底涉及里哪些问题和哪些解决这些领域问题的核心技术呢？
- 第一个就是存储数据结构的设计，利用xLSM-Tree的架构解决写入高吞吐问题。
- 第二个在高性能查询上面，各个产品都有自己的索引定制和查询优化器的引入。
- 第三个在存储成本上面，各个时序数据库产品以列式存储和具体类型的针对性压缩算法选取解决存储成本问题。当然在云上存储成本上面我，们还可以在边缘端做更多的优化处理，在云上有冷热数据的处理，这也是分布式云的技术战略趋势所导向的。
- 第四个也是非常重要的领域问题，就是乱序的解决，利用写前保序和写后重排多种手段在存储层面解决乱序问题。进而在后续的计算分析部分发挥最大的价值。那么大家想想除了上面核心的四个方面还有其他关键问题和技术需要关注吗？
- 当然还有，那就是在分布式云的架构下，边缘端的部署也是需要高可靠的，各个时序数据库产品都需要提供多副本的集群版支持。
- 最后还有一个，如果最大限度让时序数据库产生最大价值，边缘端的实时计算也是必不可少的，那么，时序数据库对实时计算的支持也有很大的技术挑战。
那么在上面提到的6大领域问题和技术挑战中，实时计算看起来和数据库关系不大，为什么我这里还要重点提出呢？
这里和大家分享的思考是，在分布式云的大技术方向下，计算不仅仅是集中云上的需求，也是在边缘端的计算能力也是一种强需求，我们还以前面提到的案例来说在边缘上面同样需要实时计算和实时预测，那么出于边缘端硬件资源有限，现有云上实时计算产品大多是部署很重的，很难在实际的工业领域边缘节点进行部署，边缘端需要更轻量的、针对时序数据进行的实时计算支持。所以在边缘端的时序数据库同样需要接受 支持实时计算 的 技术挑战。
那么在分布式计算领域，我们按照计算延时角度已经有了很多的技术产品。
从计算延时以天为单位，到计算延时达到毫秒，大家熟知的产品如图。Hadoop/Hive/Spark/Kafka/Flink等产品，但这些产品的定位都是云上硬件资源丰富的大规模分布式计算场景，那么在边缘端的时序数据分析场景，我们需要具备怎样的实时能力呢？边缘的实时计算能力我们重点放到分钟到毫秒的实时性。
在这部分的实时计算设计架构中，我们也有两种典型的设计架构，一个是NativeStreaming的设计模式，认为批是流的特例，另一个是Micro-Batching的设计模式，认为流是批的特例。在目前的很多时序数据库产品已经考虑对实时计算的支持，比如InfluxDB1.x版本的CQ功能，和2.x版本的Task设计。还有ApacheIoTDB正在设计的实时计算功能。当然今天下午也给大家准备了专门面向IoT领域的时序数据流计算分析产品HStreamDB的分享。
好的，到了今天最后一部分。那么，时序数据库可以应用到哪些场景呢？我们如何才能利用技术手段，让数据价值最大化呢？
时序数据库可以应用到各种场景中包括前面提各种监控领域，以及前面提到的智能制造，智能生活，智能城市等场景中，那么要想这些场景中的价值最大化，我们需要考虑从采集到数据分析和数据可视化的各个环节的不同挑战性问题。
这里想稍加强调的是云边端的数据闭环的建立，才是数据最大化的最佳途径。我们不仅仅是采集数据和数据的监控，数据的可视化，最大的数据业务价值需要在采集的数据上面进行数据分析，分析之后的数据再反向控制终端，达成数据闭环。
那么，不同的大厂，不同的时序数据产品在数据闭环的缔造中采用的技术手段可能个各不相同。今天非常有兴邀请到业界知名的时序产品负责人/大神为大家针对性的对具体时序数据库产品进行细致分享，我们接下来把时间交给 后续的老师。
作者介绍
孙金城，51CTO社区编辑，Apache Flink PMC 成员，Apache Beam Committer，Apache IoTDB PMC 成员，ALC Beijing 成员，Apache ShenYu 导师，Apache 软件基金会成员。关注技术领域流计算和时序数据存储。
