MOP:Metamodel of Optimal Prognosis最优预后元模型,从模型中去除不重要的变量,提升模型的预测质量。
结果如下:(在刚仿真完时查看结果,和优化结束时点开弹出的结果图不一样,分别分析)
这张的工程文件名叫做Sensitivity,刚做完灵敏度分析得到的,分别介绍下几个图的含义(根据help文件的猜测)
左上角:相关性矩阵,绿色低相关,红蓝是高相关(正负),极弧系数对平均转矩的相关系数就是1,因为其他因素对转矩无影响右上角:直方图,横轴是输入/输出值,纵轴PDF概率密度函数,点开下面的箭头,可以看到平均值、最值等,猜测是这100的采样点的分布图,有什么作用不清楚。左下角:相关系数,某个输入量对三个输出量的相关性系数,点上面矩阵的不同块儿,会有不同的图。右下角:蚁丘图,就是散点图,这些点就是采样的点。
这张的工程文件名叫做Sensitivity_MOP,做完优化之后,再点开灵敏度分析的结果得到的,分别介绍下几个图的含义
左上角的图是3D响应面图,曲面是响应面,黑点就是采样点,XYZ轴的量都可以改,也可以XY同属于一个量。右上角的图是残差图,显示的就是模型预测值和实际值的误差。左下角Cop:Coefficient of Prognosis,模型的预测系数,越高说明模型越精确。此图显示了这两个量对这个Cop系数的贡献。右下角是Cop矩阵,显示每个块儿的cop。纵坐标是齿槽转矩、转矩,横坐标是极弧系数、槽口宽和总计,因为计算得到转子内径对这些优化量没影响(Cop=0?)所以就没有它。点每个矩阵块儿的时候,其他三个图也会变。
补充:上述的敏感性分析,设置的时候选择的是Sampling method,如果cop比较低,那么可以再拖一个敏感性分析模块,选择AMOP(自适应性最佳预后元模型)。
4.优化
理论上,可以跳过第三步,直接优化,但是这个过程要跑很多数据点,甚至都不知道到底多少,看教程有700多。如果先做个敏感性分析(100个点),再做优化(1分钟),速度就快很多,有人也叫他为基于响应面优化。
设置的时候,平均转矩目标函数为MAX,这时右边显示的值为负,猜测是因为软件以最小值为基准,所以,最大值只能取负,后面的结果图要注意区分,看实际结果图他是正,看目标值他就是负。
接下来,看一看结果图分析:
左上角:帕累托图,分为2D和3D的,图中很多黑色的点,还有红色的线,并没有红色的点,这图比较密集,看起来像一个面。点了红色的部分,右边显示design就会变成best design,最优解不唯一,且从2D中找不到,要从3D图中找。如果在前面的优化设置中,设置了Limit,那么这里还会有其他信息。右上角:设计参数图,当前某点的参数(不考虑转子内径)左下角:响应数据图,横坐标的百分比是设计值占当初设置优化时划定的范围的百分比,纵坐标就是转矩、齿槽转矩的响应值右下角:标准值(翻译是这样),实际上是优化目标值,平均转矩还是负的,其他都和左图一样的。
如果觉得还不错的话,求个点赞啊!!!
这是学习笔记的第 2286篇文章读完需要9分钟速读仅需7分钟Maxwell是开源产品,相比Canal的体量也小很多,综合考虑下,在短期内选择了Maxwell.从快速上手到功能支持,算是一...
这是学习笔记的第2286篇文章
读完需要
9
分钟
速读仅需7分钟
Maxwell是开源产品,相比Canal的体量也小很多,综合考虑下,在短期内选择了Maxwell.
从快速上手到功能支持,算是一个总体支持还不错的产品,也让技术调研和迭代进度进展相对快了很多。
一般说要比较,基本都会拿出这幅图来(数据带有主观特点,仅供参考),因为考虑到bootstrap是个硬性需求,所以这部分的功能考量也是一个重要权衡。
最近在做数据库到大数据流转的过程中发现了Maxwell的一些问题和改进点:
1)Maxwell的服务管理模式目前只支持start模式,如果要停止只能采用手工kill的方式,相对粗暴一些,当然和作者交流,可以使用信号处理的方式来间接实现。
2)Maxwell的核心配置是对于同步对象的过滤,可以支持正则等模式,如果过滤规则较为复杂,或者后期不断的调整,每次调整都需要重新启动Maxwell服务,没有类似reload的模式。
3)对于DDL变更,如果Maxwell的初始化已完成,服务已启动,在后续创建一张表的时候,Maxwell会把变更记录至`schemas`表中维护版本变更记录,在已有的元数据表中`tables`和`columns`里面就没有这些信息了,对于后端的服务解析表结构会带来一些偏差(DDL的变更配置会有相应的JSON)
1.问题定位
这些问题算起来大多是建议,不算是致命问题,所以整体的进度依然可以继续推进,但是最近在做了几张大表的同步之后发现了一些数据问题。
1)bootstrap的时间比较长,查看Maxwell相关监控,整体的数据吞吐量在800条/秒左右,好像是达到了整个同步的瓶颈,同步一张200多万数据的表需要1个小时左右,相对比较长,我们在近期的测试中,几张千万级的大表如果串行初始化,差不多得2-3个小时,实在是太长了。
2)同步数据的时间字段值存在差异,这也是在中端(maxwell规划为中端服务)和后端(Flink,Kudu规划为后端)在做数据比对中发现的,bootstrap的数据比对结果几乎没有相同的,也就意味是bootstrap在数据方面存在一些潜在问题,所以整个事情轮盘到了Maxwell的bootstrap部分。
查看代码逻辑,着实让我一惊,这个问题目前仅在bootstrap的环节出现,比如数据的时间字段值为:
但是经过逻辑处理后,会有时区的计算,会自动补上时区的差异。
现在的问题已经不是初始化带来的性能隐患,而是数据质量出现了侵入性,导致数据看起来错乱。
对于这个问题,分析的重点就是时区的处理差异,本来想这个改动应该很小,没想到调试和环境集成着实花了不少功夫。
2.问题修正
对于时区的数据差异,主要在于datetime数据类型存在时区差异,目前差距在13个小时。
查看Maxwell的代码类SynchronousBootstrapper:
经过调试,需要改动的代码逻辑范围是基于函数setRowValues:
可以修改为:
改动之后,整个bootstrap的逻辑经过调试和反复测试就正常了。
3.性能问题的取舍和修正
当然在这个之外,也做了一些细小的改进。
第一个问题就是bootstrap的性能问题,之前看似乎是有瓶颈,吞吐量在800左右就上不去了,对此我做了如下的改进:
1).bootstrap的一个基本原理就是select * from xxxx order by id;这种使用模式,如果表数据量比较大,其实order by的部分看起来是走了主键,该子句会强制走全索引扫描,但是整体的效果反而不是全表扫描,所以我就干脆去除了逻辑中的order by子句。
整个逻辑的改造也很轻量:
private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause,
if ( pk != null && !pk.equals("") ) {
sql += String.format(" order by %s", pk);
}
2).去除了写入数据后的sleep 1毫秒
进一步分析代码,发现bootstrap中吞吐量的瓶颈是其中一个诡异的sleep 1的处理,根据初步分析,可能考虑到bootstrap的任务会产生大量数据,对于带宽和负载压力较大,通过sleep的方式能够做到降速,整体可控。
另外对于bootstrap的日志统计中会包括同步的数据条数,这个指标值目前的依赖度不高,而且数据校验的工作目前会先停止Slave再进行数据比对
性能提升和改进,在3-5倍左右,所以这个部分的逻辑我们可以根据实际情况取舍,在我们的流传设计中,数据都是基于Slave端进行流转的,所以不会对主库造成冲击,改动的这个部分的逻辑也很轻巧,注释掉sleep(1)即可。
public void performBootstrap(BootstrapTask task, AbstractProducer producer, Long currentSchemaID) throws Exception {
producer.push(row);
Thread.sleep(1);
++insertedRows;
改动后经过测试和对比,发现性能好了很多,最多的时候能有6000多,同样的初始化不到15分钟左右就全部搞定了。
这样一些细小的改进也给我们带来了一些成就感,后续的数据同步规模继续扩大,也没有再反馈过数据质量的问题,当然在这个基础上还有一些工作需要细化。
4.后续对于bootstrap方向的改进
1)使用分片的思路来完善bootstrap
提高数据提取的效率,对于千万级以上的大表数据抽取,可以按照区间分段来提取(需要考虑到数据的变更和写入的影响),目前的逻辑过于僵硬。
private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause,
Connection connection) throws SQLException {
Statement statement = createBatchStatement(connection);
String pk = table.getPKString();
String sql = String.format("select * from `%s`.%s", databaseName, tableName);
if ( whereClause != null && !whereClause.equals("") ) {
sql += String.format(" where %s", whereClause);
}
if ( pk != null && !pk.equals("") ) {
sql += String.format(" order by %s", pk);
}
return statement.executeQuery(sql);
}
2)数据字典索引优化
Maxwell数据字典的优化,目前的数据字典中,部分SQL执行频率较高,但是从数据库层面来看是全表扫描,这些细节的地方还需要进一步调整。
比如如下的SQL语句:
>>explain select * from bootstrap where is_complete = 0 and client_id = 'dts_hb30_130_200_maxwell003' and (started_at is null or started_at