时空数据技术方面的深入分析
随着物联网迅速崛起,智能设备广泛普及,各类联网传感器正以前所未有的速度推动着我们走向智能时代。这些智能设备不仅实现了自动化、远程控制和实时监测,还产生了庞大且多样化的数据资源。这些数据涵盖传统的温度、湿度等遥感传感数据,同时也包含大量的地理位置信息、音频、视频等多种数据类型。这些物联网数据蕴含着巨大潜力,但也伴随一个至关重要的挑战:如何高效、安全地存储、管理和处理这些信息。数据的价值并不仅仅体现在存储本身,而在于如何从中提炼出有价值的信息。度能团队基于自身长期对时序数据存储管理的技术积累,不仅扩展了对空间属性维度的数据管理和分析应用能力,打造了时空数据管理平台产品,还通过多源时空数据管理及服务发布的能力,广泛应用于工业、园区、水务、智慧城市、数字孪生、物联网、GIS等私有化场景,为业务应用系统筑造时空数据服务底座。本文聚焦物联网数据的发展趋势,重点探讨数据存储关键技术要点。
智能领域的重要角色:时序数据
联网设备迅猛发展推动大量时序数据应运而生。时序数据在智能设备领域即提供了设备状态和行为的关键洞察,通过设备传感器记录了诸如温度、湿度等重要感应数据。与其同时,时序数据正在广泛应用于金融、气象、生产制造等不同领域。
▌1.1 时序数据五大特点
时序数据具有五大特点,第一,时间顺序性作为时序数据主要特征,数据点按照时间先后顺序进行排列,这种顺序性使时序数据在分析过程中有一定规律。第二,时序数据的数据点采集频率取决于设备传感器工作频率,因此数据点之间通常存在一定时间间隔,这种频率性可以揭示出数据采集的速率和节奏。第三,时序数据可能表现出明显时序趋势,即数据值在较长时间跨度内逐渐上升或下降。这一趋势有助于我们理解数据的演变和发展。第四,时序数据在较长时间跨度上可能呈现出重复的模式和周期性,这种呈现可以揭示出某种规律性,对于预测和决策制定至关重要。第五,时序数据中常常包含噪音和异常值,这些干扰因素可能影响数据的准确性和可靠性,因此需要特别处理。如图1所示,基于这些特点,我们可以为时序数据定义特殊语义度量、字段和标签,从而构建核心时间序列概念。
▲ 图1 时序数据
▌1.2 时序数据常见问题与挑战
时序数据通常以大规模和高频率方式产生。例如传感器数据,由于数据量庞大,需要低成本存储方案,以确保高效地保存大量时序数据,但同时需保持成本效益。在数据分布式存储时,多台服务器共同承担数据存储,常常会面临数据倾斜的问题,即数据在分布上不均匀,导致一些节点或分区负载过重,需要有效解决这一问题以确保系统性能稳定性。时序数据在实际存储和查询时,实际写入/查询的数据大小可能存在比程序要求写入查询数据更大的情况,既读写放大,在这个过程中会产生额外存储和计算成本,如何有效减少读写放大对降低数据处理成本至关重要。查询时的随机IO也是时序数据难点之一,有效减少查询时的随机IO对于提高查询性能至关重要。这些技术难点构成了打造高性能、低成本的时序数据存储系统关键挑战。
▌1.3 四大时序数据技术多维度解决数据管理痛点
时间索引技术是一种关键数据管理方法,用于加速和优化时间序列数据的查询。它通过对数据按时间进行排序、分区以及采用特定索引结构来实现,从而使在时间范围内迅速定位和检索数据成为可能。这种索引结构极大地提升了查询性能,有效减少读写的随机IO。此外,时序压缩技术采用多种方法和策略,以降低存储占用。其中一种关键方法是 Delta-of-delta (二阶差分编码)编码,通过存储实际数据值,连续数据点之间的变化,从而有效减少数据存储需求。针对不同数据点类型,也可以采用诸如Simple8b、Gorilla等压缩后,再通过 Snappy、LZ4和 Zstd 等压缩算法,以减小实际数据存储空间的占用。存储空间越连续、紧凑,就意味着实际存储查询时,可以最大程度减少读写IO成本。
▲图2 时序数据抽象架构
在预聚合技术方面,高频率生成的原始时序数据不仅按照指定时间窗口进行聚合,形成更大时间粒度数据点,极大减少了数据点数量,还显著降低了存储需求,在长期数据保留和成本控制方面至关重要。另一方面,在大规模时序数据场景下,查询预聚合数据比查询原始高频率数据更快,最大程度上缩短查询响应时间。
时序数据分级存储是将时序数据分成不同层级的策略,每个层级使用不同存储介质和策略,用以最优化存储资源的使用和查询性能。热数据,即频繁访问的数据,通常存储在高性能介质如固态硬盘(SSD)或内存中,以确保快速读取和查询响应时间。相对不经常访问的暖数据,虽然需要更多存储空间,但通常存储在成本较低但查询性能稍慢的传统磁盘驱动器上。冷数据,即很少访问的历史数据,通常需要长期保存以满足法规或合规性要求,可以归档到成本最低的存储介质上,如磁带存档或云存储,以进一步降低存储成本。
时序数据分级存储通常需要自动数据迁移策略,以将数据从一个层级迁移到另一个层级,触发条件可以基于数据访问频率、时间戳或其他标准。合理化数据生命周期管理策略有助于确定何时将数据从热层级迁移到暖层级,后续再次迁移至冷层级,以最大程度地降低存储成本。
发展过程中的新突破:时序和空间数据深度结合
▌2.1 空间实体的描述形式:空间数据特点
空间数据(Spatial Data)是对空间实体的描述,空间实体则是由自然世界中地理实体抽象而来,比如一个城市地图可以由点(Point)、线(Line)、多边形(Polygon)以及由这3种基本空间类型衍生的复合空间类型进行描述,除了表达其本身形状的空间描述外,还需要包含其所处空间位置的描述(如经纬度),以及一些业务属性(如所属辖区)。
对于空间数据的建模,分为2种类型,一种是基于对象的模型,一种是基于场的模型。基于对象的模型是将整个地理空间看作一个空域,所有的空间实体作为独立对象分布其中,这种模型的空间数据我们称之为矢量数据;基于场的模型是将地理空间中的空间实体和现象看作连续变量,比如地表的温度分布、土壤湿度等,这种模型将地理空间划分为均匀的网格,每个网格取值就是其表示的现象数值表达,比如温度、海拔等,这种模型的空间数据我们称之为栅格数据。
矢量数据和栅格数据是两种截然不同的空间数据,存储方式也完全不同,由于矢量数据是由多个独立对象表示,因此往往采用支持空间索引的数据库来存储;而栅格数据由于主要用于表达连续的空间现象,因此主要采用tiff这种图像格式来存储,而图像则主要使用文件系统、对象存储等方式来进行持久化存储。
▌2.2 空间数据融合时间信息:时空数据特点
时空数据(Spatial-Temporal Data)是由空间数据和时间信息复合而成的数据,用于描述在地理空间中随着时间变化的现象、事件或属性。时空数据的空间属性描述了该数据在地理空间中的位置,比如经纬度信息,而时间信息则往往用于表达数据采集、观察或者记录的时间点。由于时空数据能够描述一段时间内连续变化的现象,因此这种数据类型能够帮助我们分析空间位置和时间信息间的关联,比如地理区域内随时间变化的温度、人口流动等。
基于空间数据从模型上可以分为矢量数据和栅格数据,所以时空数据模型也是来源于这两种模型。矢量数据的时空数据,可以将时间戳作为一个属性附加到空间数据上,这样空间数据就变成了时空数据,并且由于矢量数据是结构化数据,因此存储空间占用很低,还可以很好地支持几何空间查询,这也是主流时空数据描述方式;对于栅格数据的时空数据,则需要保存采样时间内的所有栅格图像,这对于存储空间极其不友好,往往难以支持高效的时空查询。
▌2.3 空间索引技术解决时空数据存储遇新挑战
时空数据从模型上可以分为矢量数据和栅格数据,由于栅格数据主要以图片的方式保存,存储上也主要以文件系统和对象存储为主,因此本文不做详细介绍,而矢量数据是结构化数据,一般存储在关系型数据库中,需要空间索引技术支持,以便能够查询一定空间范围内的空间对象,其技术挑战主要有以下2点:
1) 如何索引多维数据
数据库索引大致可以分为2类,一是哈希索引,二是范围索引,哈希索引本质上是对单个字段进行精确匹配查询;范围索引一般采用多叉树作为数据结构,支持对索引字段进行范围匹配。而时空数据这种多维数据无法直接使用上述这2种索引模型,因此需要单独设计一种适用于多维数据的索引模型。
2) 如何在支持空间查询条件的前提下实现一般字段条件查询
时空数据的查询往往包含有一般字段的筛选条件,例如,查询7点到8点之间,位于浦东新区内,类型为出租车的所有汽车对象。为了实现这种查询,要求存储系统支持多种索引模型,还需考虑到存储空间和查询性能,这对存储系统设计是一个重要挑战。
▌2.4 时空数据存储要点
时空数据存储面临最大的挑战是如何索引多维数据,以及如何支持多种索引模型。我们将以二维点和二维多边形为例,介绍如何索引这些数据。
2.4.1 二维点的空间索引
▲图3 二维空间查询
由上图可见二维空间中散落着一些点,如pt-1、pt-2等,红色矩形框是我们的查询条件,这个查询可以表达为如下的SQL语句:
SELECT * FROM data WHERE ST_Within(geometry, BOX)
其中data表示我们的数据集,ST_Within函数表示被BOX包含的所有空间对象。我们首先对空间进行分块,图中将空间划分为了4*4的方格,并且为每个方格赋予了唯一编码,这样每个点都散落到了某个方格中,并与其编码相关联,这使得我们可以通过编码值索引到其内部的所有点,我们用下图的表格来存储这种关联关系:
▲表1 index表
由于图中红框与0000和0001两个方格相交,因此查询可以转化如下:
SELECT * FROM index WHERE key >= ‘0000’ and key <= ‘0001’
其中index即为表1所示的index表,通过空间分割加编码方式,我们将一个二维空间查询转化为了一维范围查询,最后我们还需要一个过滤器根据查询条件过滤出最终结果。
2.4.2 以空间分割、编码为基础二维多边形的空间索引新思路
对于二维多边形,大致的思路也相同,但是在编码方式上有较大区别。在进行编码前,我们首先需要一些定义,对于在切割空间中产生的子空间,我们称之为Element,对于每个Element,我们在计算其是否包含一个多边形时,会对其本身的范围向右上方向进行一级扩展(不超过整个空间的边界),如下图所示:
▲图4 Element的扩展
之所以这样做,是因为如果一个多边形落在*位置,则没有任何一个Element可以包含这个多边形,如图4*的多边形所示。一种常见的二维多边形编码方式就可以总结为,对于包含多边形的子空间进行不断切分,直到切分后的子Element无法包含目标多边形,停止空间切分,如图5所示。
▲图5 二维多边形的编码过程
编码结束后,得到的编码值无法直接使用,因为00和0000这种编码值如果直接使用是重复的,所以要对编码值进行一次映射,假设分割最大层级是N,则总的Element数是4^0+4^1…+4^N=((4^(N+1)-1))/3,即需要将编码值映射到[0,( (4^(N+1)-1))/3- 1],映射方式不是唯一的,这里我们假设映射方式叫做,会在查询时使用到。
在查询方面,对多边形、对点查询也存在一些差异,如图6所示,红色查询框与对应编号Element相交,将其加入待查询的key的集合,并对其进行子空间切分,将与查询框有交集的空间加入待查询的key集合,直到达到最大切分层级。最后,对得到的key集合进行合并,得到一组key range,对key range使用进行映射,使用映射的结果进行查询,使用过滤器进行过滤,得到最终结果。
▲图6 二维多边形的空间查询
2.4.3 差异化空间填充曲线对空间索引的多元影响
我们介绍了如何对点和多边形进行空间索引,其中核心思想是对空间进行分割,其次编码。其中编码方式有很多种,不同的编码方式会导致编码值在空间上以不同顺序相连接,如下图所示:
▲图7 空间填充曲线
我们在2.4.1和2.4.2节中使用的编码方式称之为z曲线,除了z曲线以外,还有其他的空间填充曲线,如希尔伯特曲线、皮亚诺曲线等,这些不同的曲线对于空间索引的性能往往存在一定影响,如下图所示:
▲图8 z曲线和希尔伯特曲线
图中对于空间使用了z曲线和希尔伯特曲线进行了切分,蓝色框是一个空间查询框。我们会发现,对于z曲线来说,这个查询会产生2个range查询;而对于希尔伯特曲线来说,会产生1个range查询。所以不同的空间填充曲线,在空间查询时,会带来不同的IO次数。一般来说,希尔伯特曲线的性能涉及到旋转操作,所以编码方式比z曲线复杂。
2.4.4 时空数据存储
在2.4.1到2.4.3节中,我们介绍了对多维数据进行索引的大致原理,基于这些大致原理,我们可以给出对应存储设计,来支持多索引模型,以及空间和时间的混合查询。
▲图9 时空数据存储
时空数据整体上由空间索引表、tag索引表和数据表三个部分组成,空间索引表和tag索引表根据查询条件得到一批token(token可以看作数据的主键),不同token数据全局有序分布在不同存储节点上,每个存储节点数据又按照时间分片,每个时间分片的数据按照token排序,同一个token的数据则按照时间排序。
通过这个设计,可以在查询时,将对数据表的查询请求合并成少数batch请求,每个batch请求携带一批token,对这一批token的查询则可以通过顺序io的方式查询磁盘,从而大大降低io次数,提升查询性能。而时间分片设计则可以大大减少需要过滤的数据量,缩小查询范围,并且在数据按照时间批量删除时,通过直接删除文件的方式大大提升删除性能。
时代浪潮下机遇与挑战共存:时空数据将不断攀登新高峰
党的二十大报告提出加快发展数字经济,促进数字经济与实体经济深度融合。由此可见顺应新一轮科技、产业变革趋势,数字化转型在数字经济发展过程中的重要地位。2023年9月13日至14日,由中国信息通信研究院、中国通信标准化协会联合主办的2023数字化转型发展大会暨首届数字原生大会于北京隆重举办。会上公布了第二届“鼎新杯”数字化转型应用大赛全国总决赛获奖案例。本次赛事,百度以智慧北京-面向北京市地理空间领域建设的政务时空大数据平台案例斩获二等奖。本次获奖案例,采用时空数据管理平台构建政务时空大数据空间底座,赋能时空平台专区试点应用建设,加速*数据和行业领域数据融合,提升*数据使用价值。实现政务地理空间信息资源共享服务平台对数据接入层、数据托管平台、数据管理门户的扩展、升级,搭建时空专区的运营支撑平台。加深智慧城市业务、空间两个方向在时间维度上的纵深关联,建立即时感知、全时响应的“时空动态”智慧城市建设新范式。
▲第二届“鼎新杯”数字化转型应用大赛颁奖图
未来,我们将努力构建更多创新实践案例和解决方案,使得时空数据在城市规划、环境监测、医疗保健、交通管理等多元化领域发挥关键作用,推动大数据技术产业创新发展、助力构建以数据为关键要素的数字经济、同时,在不断探索时空数据的潜力时,我们也将全力保障数据隐私和安全,确保时空数据的规范使用。
推荐阅读
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
广联达:"数字建筑 "将推动建筑业向现代工业化水平迈进--一是全过程、全要素、全参与方的数字化。"数字建筑 "整合了人员、流程、数据、技术和业务系统,对建筑从规划设计到施工建设、运营维护的全生命周期进行管理。 二是数字化、在线化、智能化。这也是数字化建筑的三大典型特征。其中,数字化是基础,在线化是关键,智能化是目标。 三是新设计、新建设、新运维。试想,未来通过全数字化样板设计实现个性化最优方案,通过工业化施工提高效率精益求精,通过智能化运维提升建筑品质低碳宜居,将推动建筑业向现代工业化水平迈进。 广联达的一批标杆项目和应用案例备受关注。
-
苏州,遇见恩智浦痞子恒--刚下高铁比较累 "飞机、高铁、打车、打车、打车",加上这些年运动机能下降,身体状态比不上年轻的时候,但是一到打球的时候,我就很兴奋,我喜欢呆在球场上的感觉,这种感觉跟着我的体力走,我有体力的时候,我就想在球场上大杀四方,我没有体力的时候,我就想回家睡觉。没有体力的时候,我就想回家睡觉。 今天的比赛很激烈,恩智浦的年轻球员有那么一点凶,我本来是想过来打酱油的,但实际情况是他们在不停地搓我的老腰,晚上我发了一张比赛的照片,一个微信好友私聊我说了下面的话。 大家自己体会,我觉得有人在针对我的腰,????。 痞子恒打得很好,中投和突破上篮技术很娴熟,有几次上篮我觉得很勉强,但球还是往篮筐里面进,可能是这种同是天涯沦落人的情怀,让我喜欢上了这个同龄的小伙子,做技术很好,打球也很好,待人很体贴????。 比赛结束后,痞子恒带我们去吃烧烤,因为太累了,胃口不是很好,只能看着肉叹气,不过吃饭的时候听大家聊天的感觉还是很不错的,让我知道了苏州的工作和生活节奏。 晚上回到宾馆,何先生说:"这就是他们的生活啊,让我感慨万千"。 我跑了三千多里路,就是为了来这里玩游戏,说出来你可别笑! ---- 痞子衡嵌入式公共号文章汇总
-
时空数据技术方面的深入分析
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。
-
发热、心慌、头晕、肌肉或筋骨异常跳动、哆嗦、站立不稳、跌倒等,这些情况说明汗出出现了问题,导致患者体质极虚,转为阴寒证。这个时候,就需要用真武汤来纠正。 有人说,风寒感冒只要发汗就可以了,其实远非如此,发汗不好病人就可能出危险,没有足够的发汗力量,病就好不了,有的人感冒了就喝姜汤,结果感冒没好,就说中药不治病,这纯粹是捣乱。就像上面提到的案例,如果医生技术不好,病人又不太懂中医,很有可能直接去医院输液。 说到输液,前几天有一位女前辈,原来也是我的病人,身体很不好,一直喜欢输液。后来我见过她几次,因为她不常在外面,再加上我们都比较年轻,有时候她身体不舒服还是喜欢去医院输液。我跟她说,这样对身体不好。她说只要管用就好。我只能暗暗摇头。前段时间,她感冒了,连续输了 5 天液,再看她,整个脸黑黑的,她还说输液管用,输完液就不发烧了。过了不到 10 天,听说她怀孕了,到现在已经快 2 个月了。去检查的时候,她说胎儿已经死在子宫里了。 这就是输液的结果。刚开始输液的时候,把一些病压在身体里,表面上看起来病轻了,其实病变得更严重了。脸色发黑说明体内阴寒之气很盛,小肚子肯定受凉感冒了,这个时候怎么能给孩子喂奶呢。以前都知道,白白胖胖的才叫健康。 下面接着说真武汤的组成:熟附子10克,茯苓16克,白术16克,白芍12克,生姜5片。 去生姜仅为四味药。 上述发汗后的症状,都是水气上冲所致。一过渡到发汗,心气突然空虚,下面的水气一下子冲上来。这比苓桂术甘汤更严重,寒邪也很重。苓桂术甘汤是心慌、头晕、身体颤抖等,对应的是中焦以上的水气。真武汤则是下焦水气上行。此时单纯扶助心阳为时已晚,应先抑制下焦水气。真武汤就是抑制下焦水气。 真武汤,用道家的话来说,就是玄武汤。玄武是北方的水神,负责镇压寒水。因此,真武汤的含义是降伏下焦的寒水之气。 方中熟地温补肾阳,茯苓利水渗湿,白术健脾利水,白芍治疗腹痛,生姜散寒下气。另一方面,水往上冲是因为木不疏泄,肝木负责水的正常下行。此时用茯苓泄脾湿,白术健脾补土,何首乌温补肾阳,芍药养肝木,肝木燥则不能疏泄,生姜行水散寒。 所以这个方子可以抑制下焦的水邪,使水邪顺其自然地排出。 这是发汗操作失误后的一种补救方法。目前还不能将其视为真武汤的正确疗法。 下文介绍了真武汤的其他用途: 1.水肿
-
腾讯视频直播 02-推流-美颜滤镜 同样,腾讯云提供了 setBeautyFilter 方法来设置美颜风格、磨皮程度、美白程度和泛红程度 //style 磨皮风格:0:平滑 1:自然 2:朦胧 //美容级别:0-9。值为 0 时关闭美颜效果。默认值:0,关闭美颜效果。 //美白级别:取值 0-9。值为 0 时,将关闭美白效果。默认值:0,关闭美白效果。 //ruddyLevel:取值范围为 0-9。值为 0 时关闭美白效果。默认值:0,关闭美白效果。 public boolean setBeautyFilter(int style, int beautyLevel, int whiteningLevel, int ruddyLevel);; public boolean setBeautyFilter(int style, int beautyLevel, int whiteningLevel, int ruddyLevel) 滤镜 setFilter 方法可以设置滤镜效果,滤镜本身是一个直方图文件。setSpecialRatio 方法可以设置滤镜的程度,从 0 到 1,越大滤镜效果越明显,默认值为 0.5。 Bitmap bitmap = BitmapUtils.decodeResource(getResources, R.drawable.langman); if (mLivePusher) if (mLivePusher ! = null) { mLivePusher.setFilter(bmp); } 控制摄像头 腾讯云 sdk 默认为前置摄像头(可以通过修改 TXLivePushConfig 的配置函数 setFrontCamera 来修改默认值),调用一次 switchCamera 就切换一次,注意切换摄像头前要确保 TXLivePushConfig 和 TXLivePusher 对象已经初始化。 mLivePushConfig.setFrontCamera(true); // 默认前置摄像头。 mLivePusher.switchCamera; //切换摄像头。 ⑦ 设置徽标水印 腾讯视频云目前支持两种设置水印的方式:一种是在流媒体 SDK 中设置水印,原理是在 SDK 中对视频进行编码前在画面中设置水印。另一种方式是在云端设置水印,即由云端解析视频并添加水印标识。 建议使用 SDK 添加水印,因为在云端添加水印会有问题。下面是添加水印的 SDK 介绍: //设置视频水印 mLivePushConfig.setWatermark(BitmapFactory.decodeResource(getResources,R.drawable.watermark), 10, 10); // 最后两个参数是视频的水印。 //最后两个参数是水印位置的 X 轴和 Y 轴坐标。 mLivePusher.setConfig(mLivePushConfig); 如果需要对水印图像的位置进行模型适配,则需要调用水印规范化接口。 /设置视频水印 mLivePushConfig.setWatermark(mBitmap, 0.02f, 0.05f, 0.2f); //参数为水印图像。 //参数包括水印图像的位图、水印位置的 X 轴坐标、水印位置的 Y 轴坐标和水印宽度。后三个参数的范围是 [0,1]。 // 最后两个参数是水印位置的 X 轴坐标和 Y 轴坐标。 mLivePusher.setConfig(mLivePushConfig); TXLivePushConfig 中的 setHardwareAcceleration 方法可以启用或禁用硬件编码。 if (mHWVideoEncode){ if (mLivePushConfig ! = null) { if (Build.VERSION.SDK_INT < 18){ Toast.makeText(getApplicationContext, "Hardware acceleration failed, current phone API level is too low (min 18)"、 Toast.LENGTH_SHORT).show; mHWVideoEncode = false; } } } } mLivePushConfig.setHardwareAcceleration(mHWVideoEncode ? TXLiveConstants.ENCODE_VIDEO_HARDWARE : TXLiveConstants.ENCODE_VIDEO_SOFTWARE); mLivePusher.setConfig(mLivePushConfig); // 如果您不确定何时启用硬件加速,建议将其设置为 ENCODE_VIDEO_AUTO。 // 默认情况下启用软件编码,但如果手机的 CPU 使用率超过 80% 或帧速率为 10,SDK 将自动切换到硬件编码。 ⑨ 后台推流 在常规模式下,一旦应用程序进入后台,摄像头捕捉数据的能力就会被 Android 禁用,这意味着 SDK 无法继续捕捉和编码音频和视频数据。如果我们什么都不做,故事就会按照下面的脚本发展: 阶段 1(背景剪切后 10 秒 ->)- CDN 无法将视频流传输给观众,因为没有数据,观众看到的是主帧。 阶段 2(10 秒-> 70 秒)--观众一方的播放器因无法接收到直播流而退出,房间里空无一人。 第 3 阶段(70 秒后)--服务器直接断开了推送流媒体的 RTMP 链接,主播需要重新打开直播才能继续。 主播可能只是短暂地接了一个紧急电话,但各云提供商的安全措施会迫使主播的直播提前结束。 1) 设置 setPauseFlag 在开始推流之前,使用 TXLivePushConfig 的 setPauseImg 接口设置一个等待图像,其含义建议为 "主播将暂时离开,稍后再回来"。
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。
-
DeepShip-它由四个类别的265艘不同船只的47小时4分钟的真实世界水下录音组成。建议的数据集包括全年不同海况和噪音水平的记录。所提供的数据集不仅有助于评估现有算法的性能,而且还将使研究团体在未来受益。使用提出的数据集,我们还对六种基于时频提取特征的各种机器学习和深度学习算法进行了全面研究。此外,我们提出了一种新的基于可分离卷积的自编码器网络,以提高分类精度。对比分类准确率、精密度、查全率、fl-score等方面的实验结果,并进行配对抽样统计测试,结果表明,基于CQT特征的网络分类准确率达到77.53%,优于其他方法。 1.Introduction 近年来,由于水声分类在海洋船舶分类和探测、测量这些船舶的声音对环境的影响、退出船设计和海洋生物分类等方面的应用,引起了广泛的关注(Erbe et al., 2019;Malfante, Mars, Dalla Mura, & Gervaise, 2018)。复杂的水下环境、背景噪声、声音数据的频率依赖性吸收和散射等因素使其成为一个具有挑战性的领域(Erbe et al., 2019)。此外,螺旋桨、发动机和隐形船体技术的改进使该领域更具挑战性(Khishe &摩萨维,2020 年)。