c++列表结构flink架构 与BLink的F 与 B 是什么英语缩写？

来源：蜘蛛抓取(WebSpider) 时间：2022-10-27 23:20 标签： B和F一定垂直吗

　　2.1) 打开任意进程，在寄存器窗口找到 fs:[0]，查看其内存地址。

　　2.2) 在内存窗口使用命令 "db 5E7000" 跳转到该内存，使用地址格式(长型-地址)显示。

使用 Windbg 指令 dt _PEB 查看 PEB结构体,重点关注最后一个 进程加载信息表。

　　1.1）重点关注 0x00c处的指针，其指向 _PEB_LDR_DATA 这个结构体，在这个结构体中 0x00c、0x014、0x01c 分别表示 模块加载顺序 / 加载后在内存中的顺序 / 模块初始化的顺序。

　　2.2）理解其三个成员的顺序，其指向_LDR_DATA_TABLE_ENTRY元素中开始的三个成员，而 _LDR_DATA_TABLE_ENTRY 中存储着就是关于有关模块信息的元素(比如模块名等)

　　2.4）选中第一个进入，在其偏移0x02c处(UNICODE结构体占四字)，可以查看字符串名称。

　　2.5）通过开头 _LIST_ENTRY结构体可以遍历前一个模块的内容和下一个模块的内容。

三、利用C++断链来实现模块隐藏

　　如果你看懂上面分析，则源代码非常好理解。 

// 隐藏模块.cpp : 此文件包含 "main" 函数。程序执行将在此处开始并结束。
//所谓模块句柄，即该模块的入口地址
 // 三个链表同时给断掉
 // 通过模块名，来获取模块句柄

以上所述是小编给大家介绍的利用C++ R3层断链实现模块隐藏功能,希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对码农之家网站的支持！
如果你觉得本文对你有帮助，欢迎转载，烦请注明出处，谢谢！

flink 1.9之前的版本，对于Table API和SQL的底层实现结构如下图，可以看处流处理和批处理有各自独立的api (流处理DataStream，批处理DataSet)。而且有不同的执行计划解析过程，codegen过程也完全不一样，完全没有流批一体的概念，面向用户不太友好。

所以后期的架构会进一步实现流批统一，流批主要区别在Trasformation和codegen层，整体架构如下：

下图是flink sql 的从编码层到执行的解析过程概览图：

3.批处理SQL解析过程

逻辑执行计划是优化的开始，案例中的sql优化过程如下：

常量折叠，也即是对sql中的常量的加减乘除等操作进行预计算，避免执行过程频繁对常量重复执行加减乘除计算：

上图常量折叠前：1+2+t1.value；折叠后：3+t1.value，逻辑执行计划缩减了一个大步骤。

假设不进行这一步优化，执行过程是：全量数据扫描，执行join操作，然后才进行fiter，这明显很浪费，id大于1000的不需要执行join操作，将fliter操作下推到join之前执行，减少了join的数据量，大大提升性能。

project下推执行，可以用来避免加载不需要的字段。由原来的sql可知，t1只需要加载t1.id，t1.value，t2只需要加载t2.id。假如表还有大量的其他字段，由于SQL中没用到，加载多余字段就是浪费，所以将project操作下推执行，就不需要加载无用字段。而且此时假如是列存储，只需要加载指定的列，优化更大。

4.流处理SQL解析过程

flink 的流处理sql解析过程如下：

期望的结果是cnt 值为1和2各 出现一次。

假如数据先输入了hello 和word两个词，得到计算过程及结果如下：

图中结果是cnt为1出现频次为2，因为word和hello各出现了一次。

此时，在输入hello，假设没有changelog机制，得到结果如下：

图中cnt 值为1出现的频次为2，cnt为2出现频次为1，这明显不符合预期，是错误的结果。

changelog机制保证了结果的正确性，同时query优化器决定者update_before消息是否需要，并且该机制对于用户来说是无感知的。

5.1 确定node该产生消息类型

简单来说，对于flink流处理的动态实时表，主要是有三种操作Insert，update，delete。这三种操作在transfoation之间传递的时候就是对应着三种message，下游算子接受到这三种message之后就知道该进行如何操作了，changelog机制就以此来实现的。

消息正向传递过程解释：

  • Aggregate知道前一层会发送：update_before和update_after，而自身也需要两种消息，那么就会通知Calc节点同时发送两种消息，其实Calc节点是不会产生消息，只会透传的。

最后就是正向传递update消息的过程，具体过程如下图右侧，source 到sink流动箭头。

经过上述过程之后，最终生成的物理计划如下： Flink的一些优化操作
6.1 内部数据结构优化
原有的row数据结构如图：

b.频繁的封箱和拆箱操作
c.序列化和反序列化的开销，尤其在随机访问字段的时候开销更明显。
新的内部数据结构，BinaryRow如下图：

大家都知道flink是可以基于时间和事件进行处理，原有策略是每条数据都会触发计算，状态更新等操作，这个其实性能也不是很好。

翻一下，就是逐条消息处理代价：

每条消息都需要序列化反序列化，

每条消息都会输出一次。

支持微批处理，就会缓解单事件处理的缺点，具体介绍如下：

策略也是很简单，批次加超时，来实现该功能，主要有三个配置：
在反问历史状态和进行序列化操作之前，内存中聚合。
也可以减轻下游的负载。

[版权声明] 本站所有资料由用户提供并上传，若内容存在侵权，请联系邮箱。资料中的图片、字体、音乐等需版权方额外授权，请谨慎使用。网站中党政主题相关内容(国旗、国徽、党徽)仅限个人学习分享使用，禁止广告使用和商用。

我要回帖

更多关于 B和F一定垂直吗 的文章

 

随机推荐