checkpoint

1、Tensorflow 模型文件 checkpoint model.ckpt-200.data-00000-of-00001 model.ckpt-200.index model.ckpt-200.meta 1.1 meta文件 model.ckpt-200.meta文件保存的是图结构，通俗地讲就是神经网络的网络结构。一般而言网络结构是不会发生改变，所以可以只保存一个就行了。我们可以使用下面的代码只在第一次保存meta文件。 saver.save(sess, 'my-model', global_step=step,write_meta_graph=False) 并且还可以使用tf.train.import_meta_graph(‘model.ckpt-200.meta’)能够导入图结构。 1.2 data文件 model.ckpt-200.data-00000-of-00001为数据文件，保存的是网络的权值，偏置，操作等等。 1.3 index文件 model.ckpt-200.index是一个不可变得字符串表，每一个键都是张量的名称，它的值是一个序列化的BundleEntryProto。 每个BundleEntryProto描述张量的元数据：“数据”文件中的哪个文件包含张量的内容，该文件的偏移量，校验和，一些辅助数据等等。 注意:

Estimator是Tensorflow的高阶API。除了Tensorflow官方定义的内置Estimator之外，用户也可以实现自定义的Estimator。 Estimator定义 Estimator的构造如下： def __init__(self, model_fn, # 定义模型，根据不同的模式分别定义训练、评估和预测的图。 model_dir=None, # 模型导出目录 config=None, # 配置参数 params=None, # 自定义Estimator的额外参数 warm_start_from=None): # 模型热启动 其中最核心的参数为 model_fn ，其接口如下 def _model_fn(features, # 特征，可以是Tensor或dict of Tensor labels, # 标签 mode, # 模式 params, # 自定义参数，即上面Estimator构造函数中的params config): # 配置参数 model_fn 会被Estimator多次调用，通过调用Tensorflow的layer来实现模型。通过模式字段(ModeKeys.TRAIN, ModeKeys.EVAL, ModeKeys.PREDICT)来判断是训练、评估还是预测阶段，分别构造不同的图。 model_fn 的返回结构为 EstimatorSpec

postgres csv日志和查看用户权限 最近在使用postgres 时遇到的2个问题，顺便记录一下查到的比较好的资料。 怀疑postgres在执行SQL时报错，程序日志中有无明确异常信息。通过查看csv日志来确定是否SQL真的是执行时报错。 下面转自： https://www.cnblogs.com/kuang17/p/6902122.html?utm_source=itdadao&utm_medium=referral 　　日志审计 　　审计是值记录用户的登陆退出以及登陆后在数据库里的行为操作，可以根据安全等级不一样设置不一样级别的审计， 　　此处涉及的参数文件有： 　　logging_collector --是否开启日志收集开关，默认off，开启要重启DB 　　log_destination --日志记录类型，默认是stderr，只记录错误输出 　　log_directory --日志路径，默认是$PGDATA/pg_log, 这个目录最好不要和数据文件的目录放在一起, 目录需要给启动postgres的操作系统用户写权限. 　　log_filename --日志名称，默认是postgresql-%Y-%m-%d_%H%M%S.log 　　log_file_mode －－日志文件类型，默认为0600 　　log_truncate_on_rotation －－默认为off

最近有个需求，实时统计pv,uv，结果按照date,hour,pv,uv来展示，按天统计，第二天重新统计，当然了实际还需要按照类型字段分类统计pv,uv,比如按照date,hour,pv,uv,type来展示。这里介绍最基本的pv,uv的展示。 id uv pv date hour 1 155599 306053 2018-07-27 18 关于什么是pv,uv，可以参见这篇博客: https://blog.csdn.net/petermsh/article/details/78652246 1、项目流程 日志数据从flume采集过来，落到hdfs供其它离线业务使用，也会sink到kafka，sparkStreaming从kafka拉数据过来，计算pv,uv，uv是用的redis的set集合去重，最后把结果写入mysql数据库，供前端展示使用。 2、具体过程 1）pv的计算 拉取数据有两种方式，基于received和direct方式，这里用direct直拉的方式，用的mapWithState算子保存状态，这个算子与updateStateByKey一样，并且性能更好。当然了实际中数据过来需要经过清洗，过滤，才能使用。 定义一个状态函数 // 实时流量状态更新函数 val mapFunction = (datehour:String, pv:Option[Long], state

CKPT->pb Demo 解析 tensor name 和 node name 的区别 Pb 的恢复 CKPT->pb tensorflow的模型保存有两种形式： 1. ckpt：可以恢复图和变量，继续做训练 2. pb : 将图序列化，变量成为固定的值，，只可以做inference；不能继续训练 Demo 1 def freeze_graph(input_checkpoint,output_graph): 2 3 ''' 4 :param input_checkpoint: 5 :param output_graph: PB模型保存路径 6 :return 7 void 8 ''' 9 10 # checkpoint = tf.train.get_checkpoint_state(model_folder) #检查目录下ckpt文件状态是否可用 11 # input_checkpoint = checkpoint.model_checkpoint_path #得ckpt文件路径 12 13 # 指定输出的节点名称,该节点名称必须是原模型中存在的节点 14 output_node_names = "InceptionV3/Logits/SpatialSqueeze" # 如果是多个输出节点，使用 ‘，’号隔开 15 16 ############################

checkpoint是Flink容错的核心机制。它可以定期地将各个Operator处理的数据进行快照存储（ Snapshot ）。如果Flink程序出现宕机，可以重新从这些快照中恢复数据。 1. checkpoint coordinator（协调器）线程周期生成 barrier （栅栏），发送给每一个source 2. source将当前的状态进行snapshot（可以保存到HDFS） 3. source向coordinator确认snapshot已经完成 4. source继续向下游transformation operator发送 barrier 5. transformation operator重复source的操作，直到sink operator向协调器确认snapshot完成 6. coordinator确认完成本周期的snapshot 代码设置示例： // 5 秒启动一次 checkpoint env.enableCheckpointing(5000) // 设置 checkpoint 只 checkpoint 一次 env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE) // 设置两次 checkpoint 的最小时间间隔 env.getCheckpointConfig

原文出处： 阿里云RDS-数据库内核组 HybridDB for MySQL（原名petadata）是面向在线事务（OLTP）和在线分析（OLAP）混合场景的关系型数据库。HybridDB采用一份数据存储来进行OLTP和OLAP处理，解决了以往需要把一份数据多次复制来分别进行业务交易和数据分析的问题，极大地降低了数据存储的成本，缩短了数据分析的延迟，使得实时分析决策称为可能。 HybridDB for MySQL兼容MySQL的语法及函数，并且增加了对Oracle常用分析函数的支持，100%完全兼容TPC-H和TPC-DS测试标准，从而降低了用户的开发、迁移和维护成本。 TokuDB是TokuTek公司（已被 Percona收购）研发的新引擎，支持事务/MVCC，有着出色的数据压缩功能，支持异步写入数据功能。 TokuDB索引结构采用fractal tree数据结构，是buffer tree的变种，写入性能优异，适合写多读少的场景。除此之外，TokuDB还支持在线加减字段，在线创建索引，锁表时间很短。 Percona Server和Mariadb支持TokuDB作为大数据场景下的引擎，目前官方MySQL还不支持TokuDB。ApsaraDB for MySQL从2015年4月开始支持TokuDB，在大数据或者高并发写入场景下推荐使用。 TokuDB优势 数据压缩

redo日志 作用 innoDB存储引擎中，需要在服务器故障重启后，能够准确的恢复所有已提交的数据，保证数据持久性；如某个事务在内存Buffer Pool中已被提交（脏页），但服务器突然故障，数据就丢失了； 为了解决这个问题，可以采用修改页面刷新到磁盘，但因为可能只修改了一条记录，没必要实时刷新浪费时间，而且修改的记录并不一定是连续的，随机IO刷新较慢。 可以将已提交事务修改的记录记录下来，即某个表空间中某页的某个偏移量的值更新为多少，这个记录的文件就称为redo log。相比刷新内存中的页面到磁盘，redo log刷新到磁盘的内容小了很多，而且是一个顺序写入磁盘的过程。 redo日志不止记录索引插入/更新记录等操作，还有执行这个操作影响到的其他动作，如页分裂新增目录项记录，修改页信息等对数据页做的任何修改等等。 和binlog区别：binlog记录的是页已经正式落盘的操作且是包含所有存储引擎，redo日志记录InnoDB引擎下仍然在buffer pool中的操作，用于系统奔溃时恢复脏页。 日志 日志格式 type：类型 MLOG_1BYTE：1 ：表示在页面的某个偏移量处写入1个字节的 redo 日志类型。 MLOG_2BYTE：2 MLOG_4BYTE：4 MLOG_8BYTE：8 MLOG_WRITE_STRING：30 MLOG_REC_INSERT：9

SCN（system change number） 系统更改号 RBA （redo block address）onlin redo log的重做块地址 select dbms_flashback.get_system_change_number from dual; 系统当前的SCN SCN的更新触发是由commit来进行的，每隔3秒种系统也都会刷新一次SCN CKPT进程是在checkpoint发生的时候将数据库当前的SCN更新入数据库文件头和控制文件当中，DBWn进程将buffer cache中的脏数据块(dirty block)写到数据文件中，而是ckpt在更新控制文件和数据文件头的有关信息后，通知DBWn进程，产生一个检查点，在产生检查点的时候，DBWn进程会将buffer cache中的脏数据(当前online redo log对应的脏数据)，写入我们的数据文件当中，基本就是这么一个循环过程，ckpt进程还会在控制文件当中记录RBA，这个地址用来标志实例恢复的时候需要从日志中的那个位置开始，也就是一个checkpoint对应一个rba，当instance recovery（实例恢复）的时候oracle就会知道从那个检查点开始在redo的那个rba开始介质恢复！ 创建检查点（checkpoint）的条件： 1.alter system checkpoint 　 　2

原文引用 大专栏 https://www.dazhuanlan.com/2019/08/26/5d633917bbdf6/ 最近我们集群的SNN发生了一些异常，记录下。 关于SNN的作用，见 我以前的一篇文章 。 txid用于标记一条editlog。 一般在ANN的dfs.name.dir有几种文档： fsimage_XXX，表示这个fsimage文档已经将txid=XXX的editlog合并进来了。这种文档必定有一个同名的md5文档对应。 fsimage.ckpt_XXX，表示正在做checkpoint的一个fsimage文档，其实就是正在从SNN copy的一个文档 edits_XXX-YYY，包含从XXX到YYY的所有editlog edits_inprogress_XXX，当前正在写的editlog文档，初始的txid是XXX NN启动时会加载txid最大的一个fsimage_XXX文档。然后读取XXX之后的所有editlog并合并。如果editlog不连续，NN无法启动。 当NN启动完成后，会自动做一次checkpoint。之后开始写新的edits_inprogress文档。 异常原因 4月30号删除了大量数据，fsimage文档大小从6G减小到3G。 由于找不回当时的日志了，不知道发生了什么。原来的fsimage_AAA有6G左右