大家好，很高兴在今天的峰会上跟大家分享ApacheIoTDB核心技术解析的内容。首先，让我简单介绍一下自己。我是阿里巴巴的孙金城，外号金珠。2016年开始投入开源建设，目前是ApacheFlink的PMC成员，ApacheBeamCommitter和ApacheIoTDB的PMC成员。也是Apache软件基金会ApacheMember的成员。那么，今天我们将分为四个部分。首先，我们跟大家聊一聊物联网领域的发展趋势。目前，5G恰逢其时。马总还表示，5G催化了物联网的发展，5G80%的收益将体现在物联网领域。好吧，这不是预言，而是现实。目前，中国和美国的工业互联网，以及德国的工业4.0都在蓬勃发展。事实上，早在2018年，Gartner就将云计算向边缘计算的推进列为十大战略技术趋势之一。2019年和2020年，也不断强调赋能和边缘赋能。云、边、端一体化已经成为物联网领域的典型架构。同时，国务院于2017年发布了工业互联网指导意见，设定了分阶段的基础建设目标。从数据库领域的权威排名来看，时序数据数据库的热度从2018年开始持续走高，同时也涌现出了很多优秀的时序数据库产品，比如Influxdb、opentsdb、ApacheIoTDB等。目前时序数据库有30多种，从架构上可以分为三类。第一类，第二类以TimescaleDB为代表的基于关系的时序数据库，第三类以OpenTSDB为代表的基于KV的时序数据库。专为时序数据设计的InfluxDB和ApacheIoTDB。那么这三种类型的数据库有什么特点呢？基于关系的时序数据库建立在B+树数据结构之上，在编写上有先天的局限性。基于KV的时序数据库在建立索引时存在存储弊端，导致查询能力受限。然后基于LSMTree的InfluxDB和IoTDB在架构上解决了高吞吐量写入的问题，IoTDB官方也给出了一些性能测试数据。我们看到IoTDB在写入和查询上都有很大的优势。那么这些优势的本质是什么？这就是我们今天要与大家分享的核心内容。那么我们就来看看IoTDB的核心技术点。这部分可能有点复杂，需要大家集中讨论。技术是建立在解决实际问题的基础上的。首先，我们需要看看物联网时间序列数据的领域问题。时间序列数据的来源很多，如交通设施、智能建筑、工况指标数据等。尤其是在数据规模领域更是一个不容忽视的实际问题。以金风发电为例，有2万台风力发电机，每台风力发电机有500个测点，数据采集频率为50Hz。数据量达到每秒5亿条的吞吐量需求。因此，物联网领域的时序数据存储计算涉及三个非常重要的领域问题：存储成本/写入吞吐量/查询性能。同时，客观上也存在乱序问题。这是2018年青海大数据平台的真实数据情况，物联网行业时序数据乱序是常态。那么，面对以上问题，IoTDB是基于LSMtree架构设计的。LSM树的核心思想是放弃部分读能力来换取最大化的写能力。核心思想其实很简单，就是假设内存足够大，所以不需要每次有数据更新就把数据写入磁盘，而是可以把最新的数据存入内存优先，当积累到一定程度，再用归并排序的方法将内存中的数据归并追加到磁盘队列的尾部。我们先看一下基于LSMTree的写入流程：一个数据写入到达后，首先将WAL写入磁盘。写WAL是为了恢复。真正的有序写入需要将数据写入内存，即Mem-Table，然后对Mem-Table进行排序。数据写入内存后，表示写入成功。那么写入内存后会发生什么？就是解决放置的问题。当内存数据达到一定大小时，需要写入磁盘。LSMTree的做法是让需要刷盘的Mem-Table不可变，在不影响写请求的情况下刷盘，并创建一个新的Mem-table。同时，我们对持久化数据进行合并和索引。那么查询逻辑是怎样的呢？查询逻辑的核心是查询索引，先在内存Mem-table中查询，然后在immutableMem-table中查找，再在磁盘Flie中查找。当然这里还有Bloomfilter辅助查询。布隆过滤器的本质是位图。每个关键数据可以用k个独立的哈希计算，填充位图。查询数据的时候Bloomfilter说没有，Bloomfilter说没有，必须继续索引查找。那么，IoTDB架构设计是对LSM的优化和增强，针对物联网时序数据的乱序问题做了关键的设计考虑。从内存到文件存储，对有序数据和乱序数据都有专门的处理，可以更大程度的解决乱序问题。.同时，IoTDB拥有查询优化机制，可以为用户提供极致的查询性能。从宏观上，我们可以感知到IoTDB的优秀之处，但在具体细节上有哪些设计上的考虑呢？接下来我们来看一下细节。IoTDB本质上是一个数据库和一个存储系统。最终数据以文件的形式存储和管理。IoTDB设计了自己的TsFile格式。那么什么样的文件格式设计才能满足高效写入和快速读取呢？首先根据实际查询需求，对TsFile的文件格式进行反转。通常，我们更喜欢将同一台设备的数据存储在一起，将每条测量信息连续存储在磁盘上是最高效的。因此IoTDB在逻辑上将一个设备的数据抽象成一个ChunkGroup，每个ChunkGroup进行独立的云端数据管理。同时，每个Measurement数据都存储在一个Chunk中。同时，在实际的工业场景中，我们多以时间间隔来查询某些工况信息。因此，我们还需要对时间间隔进行抽象。在IoTDB中，chunk数据按照时间间隔划分为若干个Page信息。那么，这样的数据结构抽象的最终目的是什么？即充分利用边缘有限的内存资源，尽量减少磁盘IO。我们以最佳方式构建索引树。那么，哪个层次的数据抽象信息更适合作为索引树的节点信息呢？是为了保存pange信息吗？或者chunk信息，或者all信息，在资源有限的情况下，如何选择？那么这个权衡的原则就是，在一定内存大小的情况下，内存中的索引信息越完整越好。根本目的是减少磁盘IO。既然一个页面是一个细粒度的数据块，那么是否可以为所有的页面元信息构造一个索引树呢？其实通过刚才的范例，我们会发现，工业场景7*24小时不间断的数据采集，每秒5亿个数据点，会形成一个海量的页面，以页面作为索引tree节点信息，而构建的树将是一棵巨大的树，即使将所有的chunk信息加载到内存中也是一个巨大的挑战。所以一开始，我们使用Device和Measurement的粒度来构建索引信息。即我们为ChunkGroup和Chunk构造Meta信息。这是IoTDB0.8版本的TsFile的完整结构，包括数据的Meta信息和Device的tsFile/Meta信息/Chunk的Meta信息。查询设备工作状态信息时文件的读取过程如下：首先读取4个字节的MetaSize，其次根据Meta的内容进行二分查找，设备信息，如d信息.第三，根据Device的MetadataIndex的偏移量定位到Device的Meta数据。第四，将当前设备的ChunkMeta信息全部读入内存。嗯，说到这里，在实际生产过程中，我遇到了一个设备，有几十万个工作数据采集。加载与当前查询无关的Chunk信息也是一个巨大的性能消耗。那么如何解决呢？为解决上述问题，为未来提供极致的查询性能，我们需要优化Meta信息的利用。在0.10版本中，我们根据设备和工况信息构建了一个B+Tree。假设一个设备有150个测量集合，我们将元信息从0.8优化到0.10。首先是对Chunk信息进行细粒度的时间分片，如TimeSeriesmeta中所示；更重要的是，我们对Measurement实现了更高层次的逻辑抽象，即LEAF_MEASUREMENT节点，这样我们就可以构建索引树。这样一个索引树，当我们查询某个设备的某个Measurement信息时，比如查询s0，那么优化后的索引结构，我们不需要读取设备下Measurement的所有Meta信息，只需要读取取s0-s9的数据即可。那么，理解这里的内容需要一点磁盘数据块管理和读取的知识背景，磁盘数据块管理和B+Tree数据结构性感内容。您可以扫描二维码查看更详细的内容解析。如果你刚才了解了Measurement中间层的抽象和优化，那么相信你下一秒也会明白，当设备很多的时候，你也可以对设备的Meta信息进行一层INTERNAL_DEVICE节点抽象.通过这种方式，IoTDBv0.10针对DEVICE和MESUREMENT优化了中间节点的抽象，从而优化了内存利用率/数据分析，降低了磁盘IO成本，大大提升了查询性能。这是v0.10版本中完整的TsFile的数据结构。下面用一个具体的查询来全面梳理一下查询逻辑：假设我们要查询时间间隔为(20,80)的设备d1的s1的采集点信息：SELECTsensor_1FROMroot.device_1WHEREtime>20andtime<80读取TsFile的MetaDataSize信息根据MetaDataSize和offset获取MetaData的位置根据TsFile的MetaData获取IndexNodes的Offset信息我们要查询device_1的信息，根据的偏移信息读取MetadataIndexNodes的数据内容device2535我们要查询sensor_1的信息，根据sensor_1的offset信息2175读取TimeseriesMetadata信息。我们要查询时间间隔(20,80)的信息。根据offset1487读取Chunk信息，根据ChunkHeader的offset12读取ChunkHeader内容。最后依次读取Chunk中的PageHeader。如果Page的时间间隔是(20,80)，那么我们来读取PageData。虽然搜索的步骤很多，但内部索引结构是B+Tree，辅助bloomfilter等加速机制。查询性能还是很不错的！！！其实IoTDB整体还是很复杂的，内部细节很多。上面我们详细介绍了Meta设计和阅读流程。IoTDB的编写设计也很巧妙，有很多细节需要给大家介绍一下。会涉及到ChunkGourp/chunk/等部分的详细考虑。今天就不展开了，公开给大家详细分析一下。如果我们跳出细节，从宏观的角度来理解IoTDB，我们会发现IoTDB不仅在数据读写上有优势，而且融合了行业标准，更注重与大数据生态的融合。非常适合企业搭建云-边-端一体化存储计算系统平台。好的，那么让我们快速了解一下IoTDB的现状和未来计划。IoTDB于2020年9月获得最权威开源社区认可，成为Apache顶级项目。Apache开源社区对项目毕业的控制非常严格，IoTDB成为顶级项目就足以证明它的优秀和潜力。刚才我们也提到ApacheIoTDB非常注重行业标准的融合，与Apache的顶级项目PLC4X有很好的生态融合和线下交互。得到了多方的认可，包括工信部的认可和行业的肯定。2020年，它也成为了开源中国年度最受欢迎的开源项目。未来规划，图中棕色部分是已经提供的功能，橙色部分是社区目前正在规划的部分。那么更多的功能规划和开发也欢迎大家积极参与其中。好的，让我们快速浏览一下IoTDB的现有生产用例。目前，IoTDB已在多个工业领域投产，包括风电行业、工程机械、气象大数据平台和城市轨道等项目。其中，在中车青岛四方车辆的合作项目中，一个IoTDB实例替代了旧系统。超过10个Cassandra实例。每天管理4000亿个数据点。同时，IoTDB也在德国和美国得到了推广应用。图为IoTDB在德国的工业应用。当然，还有更多的用例正在进行中。..作者介绍孙金城，51CTO社区编辑，ApacheFlinkPMC成员，ApacheBeamCommitter，ApacheIoTDBPMC成员，ALC北京成员，Apache神鱼导师，Apache软件基金会成员。专注于技术领域的流计算和时序数据存储。
