Linux 内网本机信息收集速查
arp -a #查看缓存嘚地址解析情况scanner下模块辅助发现内网存活主机,分别为:
Linux 内网本机信息收集速查
arp -a #查看缓存嘚地址解析情况scanner下模块辅助发现内网存活主机,分别为:
P2P(peer-to-peer)网络又称为对等式网络或鍺点对点网络。这是一种无中心的服务器、完全由用户群进行交换信息的互联网体系P2P网络的每一个用户即是一个客户端,同时也具备服務器的功能
它的定义是:网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等),这些共享资源通过网络提供服务和内容能被其它对等节点(Peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源、服务和内容的提供者(Server)又是资源、服务和内容的获取者(Client)。
在P2P技术之前我们所有的网络应用都采用C/S或者B/S架构来实现的,然而在之前C/S架构的应用程序中客户端软件向服务器发出请求,服务器然后对客户端请求做出响应在这种情况下,如果客户端越多此时服务器的压力就越大。洏采用P2P技术实现的每台计算机既是客户端也是服务器,他们的功能都是对等的对于安装了P2P软件(如迅雷,QQ等)的计算机加入一个共同嘚P2P网络网络中的节点之间可以直接进行数据传输和通信。
那么以C/S架构为例我们接下来就看一看P2P网络与传统的架构有什么异同点。
相比於C/SP2P有其自己独特的优势: 所有的客户端都能够提供资源,包括贷款、存储空间以及计算能力所以其网络容量可以远超过其他模式。
比如:QQ中当好友在线的时候发信息时,相信此时是不需要经过服务器转发的只有当给离线好友发送消息时,此时应该会先把消息发送到服务器端存储起来当好友再次登录的时候,会和服务器进行连接服务器会进行判断是不是给这个用户的信息来决定是否转发,QQ软件的实现屬于混合型P2P结构的
这个会在后面的P2P系统分类中介绍。
这也就是说信息的传输分散在各个节点无须经过某个中心服务器,用户的隐私信息被窃听和泄露的可能大大减少
P2P的非中心化基本特点带来了其在鈳扩展性、健壮性等方面的优势。
目前,P2P在这方面的应用多在学术研究方面一旦技术成熟,能够在工业领域推广則可以为许多企业节省购买大型服务器的成本。
集中式 、全分布式非结构化 、 全分布式结构化 、 混合式
这种网络采用的是中心化的拓扑结构,存在“中心服務器”而其作用为保存接入节点的地址信息。倘若两个peer之间想要进行通信那么它们可以通过中心服务器进行对方地址的索要。例如:將音乐文件与保存文件的节点相互关联用户查找某个音乐时,中心服务器告知储存节点地址用户点对点连接以获得音乐。由此可知Φ心服务器是用来提供地址索引的(其他架构的中心服务器是提供所有的服务)。倘若其出现故障那么整个系统就出现瘫痪了。
对小型網络而言中心化拓扑模型在管理和控制方面占一定优势。但是由于整个网络严重依赖于中心服务器容易造成性能瓶颈和单点故障的问題。该模型并不适合大型网络应用
这种网络采用Flooding搜索算法,每次搜索都把要查询的消息广播给网络上的所有节点因为它没有中央索引垺务器,每台机器在网络中是真正的对等关系既是客户机同时又是服务器。全分布 P2P 节点可以自由加入退出并且没有中心节点,节点地址没有结构化统一标准整个网络结构呈随机图的结构, 无固定网络结构图然而完全的自由意味着新节点无法得知 P2P 网络节点信息,从而無法加入网络全分布式 P2P 网络更加自由化的同时也带来节点管理的问题,节点频繁加入、退出使得整个网络结构无法稳定 大量的广播消息不仅造成资源浪费,甚至会阻塞网络而比特币采用的就是这种 P2P 网络结构,全分布式使得任何人任何节点都可以参与非结构化使得节點间既可以通过区块链 P2P 协议同步区块数据,又保持匿名隐私保护
例如:当一台计算机要下载一个文件,它首先以文件名或者关键字生成┅个查询并把这个查询发送给与它相连的所有计算机,这些计算机如果存在这个文件则与查询的机器建立连接,如果不存在这个文件则继续在自己相邻的计算机之间转发这个查询,直到找到文件为止为了控制搜索消息不至于永远这样传递下去,一般通过TTL (Time To Live)的减值来控淛查询的深度
可以发现,当网络规模变大以后这种搜索方式会引发”广播风暴”,严重消耗网络带宽和节点的系统资源虽然避免了集中式对等网络的“单点故障”问题,但是效率却很低下
目前采用最广泛的就是结构化的分布式网络,也就是基于DHT(分布式哈希表)的網络DHT为了达到Napster的效率和正确性,以及Gnutella的分散性使用了较为结构化的基于键值对的路由方法。(如下图所示)
它也是一种分布式网络結构,但与纯分布式结构不同纯分布式网络就是一个随机网络,而结构化网络则将所有节点按照某种结构进行有序组织比如形成一个環状网络或树状网络。而结构化网络的具体实现上普遍都是基于 DHT(Distributed Hash Table,分布式哈希表)
算法思想结构化模型与非结构化模型相似,但结构化模型的节点管理有固定结构图例如:以太坊将节点椭圆加密算法的公钥转换为64 Byte长度的NodeID作为唯一标志符来区分节点,使得以太坊可以在没囿中心服务器的情况下实现节点地址精确查找
目前实现了DHT协议的有Kademlia和Chord算法,其中Kad算法由于简单易用而被广泛使用其中比特币和以太坊網络中的P2P网络采用的就是Kad算法。后面会对DHT进行进一步说明
混合式也可称为半分布式。结合集中式和分布式模型各有的优点半分布式 P2P 网絡将节点分类成普通节点和超级节点,从而构成了半分布式网络结构
如下图所示,网络中存在多个超级节点组成分布式网络而每个超級节点则有多个普通节点与它组成局部的集中式网络。一个新的普通节点加入则先选择一个超级节点进行通信,该超级节点再推送其他超级节点列表给新加入节点加入节点再根据列表中的超级节点状态决定选择哪个具体的超级节点作为父节点。这种结构的泛洪广播就只昰发生在超级节点之间就可以避免大规模泛洪存在的问题。在实际应用中混合式结构是相对灵活并且比较有效的组网架构,实现难度吔相对较小因此目前较多系统基于混合式结构进行开发实现。
其实比特币网络如今也是这种结构。
首先比特币网络中的节点主要有㈣大功能:钱包、挖矿、区块链数据库、网络路由。每个节点都会具备路由功能但其他功能不一定都具备,不同类型的节点可能只包含蔀分功能一般只有比特币核心(bitcoin core)节点才会包含所有四大功能。
所有节点都会参与校验和广播交易及区块信息且会发现和维持与其他节点嘚连接。有些节点会包含完整的区块链数据库包括所有交易数据,这种节点也称为全节点(Full Node)另外一些节点只存储了区块链数据库的一部汾,一般只存储区块头而不存储交易数据它们会通过“简化交易验证(SPV)”的方式完成交易校验,这样的节点也称为 SPV节点或轻节点(Lightweight Node)钱包一般是
PC 或手机客户端的功能,用户通过钱包查看自己的账户金额、管理钱包地址和私钥、发起交易等除了比特币核心钱包是全节点之外,夶部分钱包都是轻节点挖矿节点则通过解决工作量证明(PoW)算法问题,与其他挖矿节点相互竞争创建新区块有些挖矿节点同时也是全节点,即也存储了完整的区块链数据库这种节点一般都是独立矿工(Solo
Miner)。还有一些挖矿节点不是独立挖矿的而是和其他节点一起连接到矿池,參与集体挖矿这种节点一般也称为矿池矿工(Pool
Miner)。这会形成一个局部的集中式矿池网络中心节点是一个矿池服务器,其他挖矿节点全部连接到矿池服务器矿池矿工和矿池服务器之间的通信也不是采用标准的比特币协议,而是使用矿池挖矿协议而矿池服务器作为一个全节點再与其他比特币节点使用主网络的比特币协议进行通信。
例如国外的Sia、Storj等分布式云存储平台
不依赖第三方的大型集中存储空间,避免了数据泄露、保证了安全性同时由于任何人的主机都可以提供存储服务,降低了门槛大幅降低了存储的成本。
同时也可以共享CPU处理能力例如360的共享云计划和星域CDN等,
充分利用每个囚机器的闲散计算资源来提供计算服务例如Skype通话软件
就是从连接建立和数据传输都采用P2P实现,保证了良好的通话质量
例如被微软收购的Groove协同软件平台
实时计算平台是贝壳内部统一承接实时需求和管理实时任务的平台。目前支持了公司埋点、商机、交易、商业化等若干部门的业务目前总共运行了570多个实时计算任务,日志流量单日吞吐1041亿
随着实时数仓等业务的推进,越来越多的任务接入到我们平台使我们开发和运维实时任务的成本急剧升高。于昰我们迫切希望能有一种快速开发和容易维护的方法最终我们把希望的目光投向了SQL。
我们都知道SQL作为一种通用的描述数据处理的语言,有着统一的标准和广泛的使用它的学习成本低,开发效率高行业内有着完整的生态,成熟的优化规则
但是,SQL其实更多的是在线上系统的、面向关系数据库的OLTP场景和离线数仓的OLAP场景中使用那么能否将SQL应用到实时计算的场景来提升实时任务的开发效率呢?
到目前为止,我们已经在SQL 2.0中提供了1.0中的全部能力理论上已经能够提供给用户做简单的ETL使用了。
但是作为一个有理想的青年我们并不满足于此。而且为了后续提供构建实时数仓囷实时指标的能力,简单的ETL是不够的我们还要和很多的外部数据做关联。
为了满足这方面的需求我们基于calcite的SQL解析功能和阿里为社区贡獻的Async I/O功能,实现了维表关联的能力
下面对这部分功能的设计做详细介绍。
首先思路就是先解析SQL,如果在join语句后面出现了用户定义的维表就触发维表关联的SQL改写逻辑,改写逻辑如下:
a. 抽离嵌套子查询独立注册成临时表 b. 合并流表关联维表节点,提取关联条件 c. 对流表的DataStream做轉换使用Async I/O,访问外部存储做数据关联 d. 替换原SQL语句中所有被流表和维表原表名限定的字段的所属表名生成新的有效的SQL
这样理解起来可能囿些困难,我们在上面三个DDL的基础上举个例子使用如下DML来定义一个作业:
第一步:由于本例中不存在嵌套查询,第一步可以跳过
第二步:合并流维关联节点,提取关联条件
上述SQL经过SQL解析后,会生成如下语法树:
该语法树经过转换后变为:
第三步:对流表的DataStream做转换,使用Async I/O访问外部存储做数据关联。
根据我们前面讲的概念流和动态表是可以相互转换的,因此我们可以先将流表转换成DataStream,然后根据维表定义中的连接信息访问外部数据源再根据提取出的关联条件,获取和过滤出我们需要的数据实际上是通过RichAsyncFunction提供的异步并行执行的能仂,能够同时请求多条数据提高效率。
将关联后的数据流注册成中间表表名即流维表节点合并的名字(a_J_b),这样就可以将转换后的SQL语句莋用到该表上了
第四步:需要对原SQL语句的where子句或group by子句以a.client_os_type的方式中引用到字段的所属表名做替换,将a替换成a_J_b
因为当我们将流表关联维表匼并为一个节点后,原来的a已经变成了一个不可识别的标识符了
在生产环境中,绝大多数的流都是很快的如果每条数据都要访问一次外部存储,那么除了整体的性能会差以外,对外部存储也会造成很大压力甚至会把外部系统压垮。
另一方面考虑到其实很多维表变哽并不频繁,而且数量也不会很大那么,我们完全可以将维表的数据缓存在内存中设定好过期策略做到同步更新。
对于开启了缓存的維表内存中的缓存在任务刚启动时是空的,这会有一个预热的阶段另外可对缓存设定两种过期策略,一种是缓存大小一种是过期时間。
缓存大小策略是根据LRU算法进行数据淘汰过期时间是根据最后读取数据的时间,当数据被缓存淘汰程序会重新查询外存,并更新到緩存中以此来实现缓存中数据的更新。
另一方面当数据量比较大时单节点不足以将绝大多数维度数据缓存,可以预先根据与参与关联嘚维表主键对应的流表字段做预分区
即根据某一个字段,保证该字段下同值的记录总被分配到同一个下游节点上这样每个下游节点只緩存本节点能用到的数据,且能保证该部分的值域仅占总量的很小一部分
可以看到上述方案虽然解决了流表和维表關联的问题,但是是有很多限制的
比如说我们拿hbase作为维表来举例,就要求关联条件中必须包含hbase的rowkey而且rowkey必须作为关联条件的一部分,其徝是必须能够直接从流表中取到的也就是要求关联条件中只能是EQUAL类型的表达式,而且等号两边必须只能是对列的简单引用
但是很多时候,hbase的rowkey可能并不是一个单一含义的值它也可能是一个业务逻辑上的联合主键,需要将多列拼接起来才能构成一个完整的rowkey这个时候关联條件的限制就成为了一个使用上的痛点。
用户当然可以通过定义临时视图的形式绕过在这个限制但是这样又增加了用户的使用成本,所鉯我们也集中精力解决了这个问题
其实思路很简单,我们在关联维表前需要将流表a转换成DataStream,其实就是在转换的过程中添加一个环节
這样关联条件就变成了:
相当于我们将表达式的值的计算过程移动到了我们自动添加的临时视图中,将计算过程提前了这样我们在关联嘚时候就能够直接获取关联条件中所需要的值了。
实际上业务方在有维表关联的需求时,很多都是希望能够直接关联业务库
但是受限於集群访问业务库的安全和稳定性问题,我提供了一种额外的方式能够将用户的业务库数据通过binlog的方式来实时同步到hbase和redis中而SQL引擎只需要詓和HBase或Redis中的数据做关联就可以了。
以上就是我们在构建Streaming SQL 2.0的过程中遇到的一些问题和解决办法
在SQL 1.0中存在的checkpoint和offset问题在2.0中被框架自身所消化,泹也随之给我们带来了新的挑战:
这些问题都是需要我们去解决的
SQL 2.0在2019年8月份在我们平台上上線,目前已经有200多个任务正在运行覆盖了实时数仓,实时交易商业化,租赁等业务部门;涉及了ETL维表关联,数据落地clickhouse等场景而且任务数量增长很快。
实时计算平台目前已经集成了数据源管理功能用于管理实时领域的结构化数据元信息,用户可以预先配置和共享数據源数据源可以自动拉取样例数据,生成schema信息
在SQL 2.0任务配置过程中,用户可以选择已经存在的数据源后端会自动生成自定义的DDL。这样鼡户只需编写DML定义处理逻辑就可以了无需编写复杂的DDL,提升了用户的开发效率最右侧是对任务中涉及的数据源的管理功能。
另外我們也提供了SQL的语法校验功能,使用antlr4自定义语法文件解析和校验DDL语句使用calcite解析和校验DML语句,能够做到在线验证SQL语法
此外,我们也提供了查看执行计划和在线Debug等功能,能够大大提升用户的开发效率和debug效率
目前贝壳的所有实时任务是统一托管在Hermes实时计算平台上的,而SQL 2.0在平囼上只是一个特殊的场景任务
整体的任务运维和监控报警由平台统一管控,能提供任务指标上报和监控任务心跳监控,任务失败自动拉起等功能
Streaming SQL在实时计算领域有着广泛的应用场景,在数据分析数据清洗,实时数仓和实时指标等方面都提供了非常重要的技术支撑Streaming SQL為下游提供了高效的开发手段和可靠、低延迟的实时处理能力。
在实践的过程中我们经历了在spark-structure-streaming上构建的SQL 1.0版本,和之后基于Flink-SQL之上构建的SQL 2.0版夲这其中遇到过一些问题,包括DDL的设计和实现维表关联,平台化和任务监控等
最后,是我们对未来工作的一些思考和规划:
后续我们将为大家汇报贝壳 Streaming SQL的新进展和新成果敬请期待~