首页 文章 精选 留言 我的

精选列表

搜索[快速入门]，共10000篇文章
优秀的个人博客,低调大师

Keras快速上手——打造个人的第一个“圣诞老人”图像分类模型

首发地址：https://yq.aliyun.com/articles/288077 2017年已到最后一个月的尾巴，那圣诞节还会远吗？不知道各位对于圣诞节有什么安排或一些美好的回忆，我记得最清楚的还是每年圣诞节前一晚那些包装好的苹果，寓意平平安安。那谈到圣诞节，不可或缺的主角——“圣诞老人”会出现在各地的大街小巷、各种画册上，本文将带领读者使用Keras完成“圣诞老人”图像的分类，算是圣诞节前的预热活动吧。 在介绍正式内容前，读者可以先看这篇内容： 如何利用谷歌图片获得训练数据 在本教程的第一部分，将介绍本文使用的数据集；其次使用Python和Keras训练一个卷积神经网络模型，该模型能够检测一个图像中是否存在圣诞老人， 所选的网络结构类似于LeNet网络；最后，在一系列的图像上评估本文搭建的模型，然后讨论一下本文方法的局限性以及如何拓展等。 “圣诞老人”和“非圣诞老人”数据集 为了训练搭建的模型，本文需要两类图像集： 图像含圣诞老人（“圣诞老人”）; 图像不包含圣诞老人（“不是圣诞老人”） 上周我们用谷歌图片迅速获取训练图像数据集，数据集中包含461张有圣诞老人的图像中，如图1（左）所示；此外从UKBench数据集中随机获取461张不包含圣诞老人，如图1（右）所示。 基于卷积神经网络和Keras搭建的第一个图像分类器 如图2所示，该图是一个典型的Lenet网络结构，最初被用来数字手写体的分类，现将其扩展到其他类型的图像。 本教程主要是介绍如何将深度学习应用于图像分类中，所以不会对Keras和Python语句介绍得非常详细，感兴趣的读者可以看下Deep Learning for Computer Vison with Python这本书。 首先先定义网络架构。创建一个新文件并命名为lenetpy，并插入以下代码： 第2-8行是需要导入的Python包，其中conv2d表示执行卷积，maxpooling2d表示执行最大池化，Activation表示特定的激活函数类型，Flatten层用来将输入“压平”，用于卷积层到全连接层的过渡，Dense表示全连接层。 真正创建Lenet网络结构是代码的第10-12行，每当定义了一个新的卷积神经网络结构时，我喜欢： 把它放在自己的类中（为了命名空间及便于组织） 创建一个静立建造函数，来完成整个模型的建立 建立的模型时需要大量的参数： weight：输入图像的宽度 height：输入图像的高度 depth：输入图像的通道数（1表示单通道图像灰度，3表示标准的RGB图像） claclasses：想要组织的层类别总数 第1第4行定义我们的模型，第15行初始化inputshape，第18-19行正常更新inputshape 现在我们已经初始化我们的模型，可以开始添加其它层，代码如下： 第21-25行创建第一个CONV->RELU->POOL层，卷积层使用20个大小5x5的滤波器，之后紧跟RELU激活函数，最后使用窗口大小为2x2的最大池化操作； 之后定义第二个CONV->RELU->POOL层: 这次卷积层使用50个滤波器，滤波器个数的增加加深整个网络体系结构。 最终的代码块是将数据“压平”以连接全连接层： 第33行能将maxpooling2d层的输出压扁成一个单向量； 第34行显示全连接层包含500个节点，然后紧跟一个ReLU激活函数； 第38行定义另一个全连接层，该层的节点数等于分类的类别数，Dense 层送入softmax分类器输出每类的概率值； 第42行返回模型的调用函数； 使用Keras训练卷积神经网络图像分类器 打开一个新的文件并命名为train_networkpy，并插入以下代码打开 第2 - 18行导入程序需要的数据包； 下面开始解析命令行参数： 这里有两个需要命令行参数，--dataset和--model，以及accuracy/loss图的路径选择。其中--dataset表示模型的训练集，--model表示训练分类器后保存的模型，如果--plot未指定，则默认为plot.PNG。 接下来，设置一些训练变量、初始化列表并设置图像路径： 第32-34行定义模型的训练次数、初始学习率以及批量大小； 第38和39行初始化数据和标签列表，这些列表对应存储图像以及类别标签； 第42-44行获取输入图像路径并将图像随机打乱； 现在对图像进行预处理： 该循环简单的将每个图像的尺寸重新调整为28×28大小（为LeNet所需要的空间尺寸） 能够提取标签是由于我们的数据目录结构如下所示： 因此，imagePath的一个例子为： 从ImagePath提取标签，结果为： 下一步，将数据集分为训练数据集和测试数据集： 第61行进一步预处理输入数据，按比例将数据点[ 0, 255 ]缩放到[ 0, 1 ]范围内； 然后第66-67行将75%数据作为训练集，25%数据作为测试集；第70-71行对标签进行独热编码；随后，通过以下操作增加数据量： 第74-76行创建一个图像发生器，对数据集图像进行随机旋转、移动、翻转、剪切等，通过这种操作允许我们能用一个较小的数据集实现好的结果。 继续深入学习Keras训练图像分类器： 第80-83行使用Adam优化器，由于本文是一个二分类问题，可以使用二进制交叉熵损失函数（binary cross-entropy）。但如果执行的分类任务多于两类，损失函数更换为类别交叉熵（categorical_crossentropy） 第87-89行调用model.fit_generator开始训练网络，第93行保存模型参数，最后画出图像分类器的性能结果： 为了训练网络模型，需要打开一个终端执行以下命令： 可以看到，当网络训练了25个回合后，模型的测试精度为97.40%，损失函数也很低，如下图所示： 评估卷积神经网络图像分类器 打开一个新的文件并命名为test_networkpy，然后开始进行评估： 第2-7行导入需要的数据包，另外注意导入的load_model是训练过程中保存的模型。 下一步，解析命令行参数： 需要两个命令行参数：--model和输入--image，然后加载图像预处理： 预处理与前面几乎一模一样，这里不做过多的解释，只是第25行通过np.expand_dims对数据额外添加了一个维度，如果忘记添加维度，它将导致调用model.predict时出现错误。现在加载图像分类器模型并进行预测： 第29行加载模型，第32行做出预测。最后画出头像以及预测标签： 第35行建立标签，第36行选择对应的概率值，第37行将标签文本显示在图像的左上角，第40-42行调整图像大小为标准的宽度以确保它适应电脑屏幕，最后，第45行显示输出图像，第46行表示当一个键被按下结束显示。 以下是包含圣诞老人图像的实验结果： 以下是不包含圣诞老人图像的实验结果： 本文图像分类模型的局限性 本文图像分类器有一些局限性： 第一个是输入图像尺寸28×28很小。一些示例图像（图像中圣诞老人本身已经很小）调整尺寸为28×28后大大降低圣诞老人的尺寸。 最优的卷积神经网络正常接受输入图像大小一般为200-300像素，因此一些较大尺寸的图像将帮助我们建立一个更强大的图像分类器。然而，使用更大的分辨率的图像会加深网络模型的深度和复杂度，这将意味着需要收集更多的训练数据，以及昂贵的计算训练过程。 因此，如果各位读者想提高本文模型的精度话，有以下四点建议： 收集更多的训练数据（超过5000幅“圣诞老人”图像）； 利用高分辨率的图像在训练。64×64、128×128像素的图像可能效果会更理想； 在训练过程中使用一个更深层次的网络体系结构； 阅读Deep Learning for Computer Vision with Python，里面有更多关于自定义数据集等内容的细节； 总结 本文教你学会利用Keras和Pyhton训练LeNet模型，并用来完成是否含有圣诞老人形象的图像分类，最终目标可以是建立一个应用程序类似于Not Hotdog； “圣诞老人”图像数据集（460幅）是按照之前的教程——通过谷歌图片采集深度学习的图像获得，而“没有圣诞老人”的图像数据集是由从UKBench数据集中挑选得到； 在一系列的测试图像上评估本文搭建的网络模型，在每一种情况下，本文模型都能对输入图像分类正确。 作者信息 Adrain Rosebrock，企业家、博士，专注于图像搜索引擎。 Linkedin:https://www.linkedin.com/in/adrian-rosebrock-59b8732a/ 本文由北邮@爱可可-爱生活老师推荐，阿里云云栖社区组织翻译。 文章原标题《Image classification with Keras and deep learning》，作者：Adrain Rosebrock，译者：海棠，审阅：董邵男。 文章为简译，更为详细的内容，请查看原文 翻译者： 海棠 Wechat：269970760 weibo：Uncle_LLD Email:duanzhch@tju.edu.cn 微信公众号：AI科技时讯
2017-12-26
优秀的个人博客,低调大师

北京Workshop准备条件：《云数据·大计算：快速搭建互联网在线运营分析平台》

实验背景介绍 了解更多2017云栖大会·北京峰会 TechInsight & Workshop. 本手册为云栖大会Workshop之《云计算·大数据：海量日志数据分析与应用》场的前提准备条件所需。主要为保障各位学员在workshop当天能够顺畅进行动手实操，那么本场需要各位学员再参加之前确保自己云账号已免费开通表格存储TableStore、大数据计算服务MaxCompute、DataWorks和Quick BI。 实验涉及大数据产品 表格存储 TableStore 大数据计算服务 MaxCompute 数据工场 DataWorks 智能分析套件Quick BI 其中表格存储TableStore、大数据计算服务MaxCompute的服务Region都选择华北2. 实验环境准备 必备条件：首先需要确保自己有阿里云云账号并已实名认证。详细点击
2017-12-12
优秀的个人博客,低调大师

利用binlog2sql快速闪回误删除数据 - 别拿豆包不当干粮

各位兄弟们，好久不见了！最近一直忙于新书的创作，所以一直没有时间更新博客。不知道这段时间大家学习得怎么样，希望大家通过看我的文章给大家带来帮助。老张我也花费了大量时间录制一些数据库的视频课程，大家要是感兴趣，也可以去学习，不要错过啊！ 今儿抽出时间，给大家分享一篇利用binlog2sql闪回工具，来恢复误删除的数据。我们都知道binlog的作用是备份恢复和完成MySQL的主从复制功能。利用mysqlbinlog工具可以进行基于时间点或者位置偏移量的数据恢复工作，在生产环境中遇到误删除，改错数据的情况，那是常有的事儿。我们都知道Oracle数据库有闪回功能，而MySQL本身没有自带闪回，但我们可以使用binlog2sql来完成这项工作。 我们都知道binlog是以event作为单位，来记录数据库变更的数据信息，闪回就是可以帮助我们重现这些变化数据信息之前的操作。也就是说对于insert操作，会生成delete语句，反之delete操作，会生成insert语句。对于update操作，也会生成相反的update语句。这款工具只能使用在binlog格式为row模式下。 下面进行实战演练：binlog2sql工具的下载地址： https://github.com/danfengcao/binlog2sql第一步：环境准备安装各种依赖的工具包列表 python-pip ， PyMySQL ， python-mysql-replication， wheel argparse 第二步：解压binlog2sql软件，命令如下 unzip binlog2sql-master.zip cd binlog2sql-master pip install –r requirements.txt 第三步：通过python binlog2sql.py --help命令，来查看重要参数的使用; -B, --flashback 生成回滚语句 --start-file 需要解析的binlog文件 --start-position 解析binlog的起始位置 --stop-position解析binlog的结束位置 --start-datetime 从哪个时间点的binlog开始解析，格式必须为datetime --stop-datetime 到哪个时间点的binlog停止解析，格式必须为datetime -d, --databases 只输出目标db的sql -t, --tables 只输出目标tables的sql 第四步：开始模拟数据删除首先删除掉zs库下，t表中的数据 root@db 14:26: [zs]> select * from t; +----+------+---------+ | id | name | address | +----+------+---------+ | 1 | aaa | bj | | 2 | bbb | sh | | 3 | ccc | gz | | 4 | ddd | sy | | 5 | eee | fj | +----+------+---------+ 5 rows in set (0.00 sec) root@db 14:26: [zs]> delete from t; Query OK, 5 rows affected (0.04 sec) root@db 14:27: [zs]> select * from t; Empty set (0.00 sec) 第五步：需要创建一个闪回用户 create user 'zs_test'@'%' identified by '123456'; grant select,replication slave,replication client on *.* to 'zs_test'@'%' ; flush privileges; 第六步：确定当前binlog文件和position位置 root@db 14:41: [zs]> show master status; +---------------------+----------+--------------+------------------+------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------------+----------+--------------+------------------+------------------------------------------+ | mysql-binlog.000002 | 2091 | | | e10f0ead-d595-11e7-82cb-080027cd683a:1-8 | +---------------------+----------+--------------+------------------+------------------------------------------+ 可以看到当前binlog是：mysql-binlog.000002位置偏移量：2091 第七步：需要预估下时间，误操作的时间范围应该在下午2点20分到2点30分之间。命令如下：python binlog2sql.py -h192.168.56.102 -P3306 -uzs_test -p123456 -dzs -tt --start-file='mysql-binlog.000002' --start-datetime='2017-11-30 14:20:00' --stop-datetime='2017-11-30 14:30:00'输出结果：DELETE FROM zs.t WHERE address='bj' AND id=1 AND name='aaa' LIMIT 1; #start 1214 end 1427 time 2017-11-30 14:27:46DELETE FROM zs.t WHERE address='sh' AND id=2 AND name='bbb' LIMIT 1; #start 1214 end 1427 time 2017-11-30 14:27:46DELETE FROM zs.t WHERE address='gz' AND id=3 AND name='ccc' LIMIT 1; #start 1214 end 1427 time 2017-11-30 14:27:46DELETE FROM zs.t WHERE address='sy' AND id=4 AND name='ddd' LIMIT 1; #start 1214 end 1427 time 2017-11-30 14:27:46DELETE FROM zs.t WHERE address='fj' AND id=5 AND name='eee' LIMIT 1; #start 1214 end 1427 time 2017-11-30 14:27:46 从解析结果中我们了解到，误操作sql的位置是在1214~1427之间;这样就可以进一步过滤，使用flashback模式生成回滚sql；命令如下：python binlog2sql.py -h192.168.56.102 -P3306 -uzs_test -p123456 -dzs -tt --start-file='mysql-binlog.000002' --start-position=1214 --stop-position=1427 -B >t_rollback.sql 查看闪回导出文件： [root@node3 binlog2sql]# cat t_rollback.sql INSERT INTO `zs`.`t`(`address`, `id`, `name`) VALUES ('fj', 5, 'eee'); #start 1214 end 1427 time 2017-11-30 14:27:46 INSERT INTO `zs`.`t`(`address`, `id`, `name`) VALUES ('sy', 4, 'ddd'); #start 1214 end 1427 time 2017-11-30 14:27:46 INSERT INTO `zs`.`t`(`address`, `id`, `name`) VALUES ('gz', 3, 'ccc'); #start 1214 end 1427 time 2017-11-30 14:27:46 INSERT INTO `zs`.`t`(`address`, `id`, `name`) VALUES ('sh', 2, 'bbb'); #start 1214 end 1427 time 2017-11-30 14:27:46 INSERT INTO `zs`.`t`(`address`, `id`, `name`) VALUES ('bj', 1, 'aaa'); #start 1214 end 1427 time 2017-11-30 14:27:46 第八步：应用回滚文件，恢复数据。命令如下：/usr/local/mysql/bin/mysql -uroot -proot123 zs < t_rollback.sql 第九步：检验恢复数据是否成功 root@db 15:09: [zs]> select * from t; +----+------+---------+ | id | name | address | +----+------+---------+ | 1 | aaa | bj | | 2 | bbb | sh | | 3 | ccc | gz | | 4 | ddd | sy | | 5 | eee | fj | +----+------+---------+ 5 rows in set (0.00 sec) 验证恢复数据成功！ 工具虽小，但功能很强大，我们要善于发现周围的资源，利用这些武器，来帮助我们学习MySQL数据库！今后老张会继续分享新的干货，供大家学习参考！
2017-11-30
优秀的个人博客,低调大师

新型IoT僵尸网络正快速扩张，家中有这些设备赶快升级打补丁

路由器、家用摄像头是现代一些家庭的标配，给很多人的生活带来了便利和安全保障。不过，如果你家里有下列品牌的路由器和摄像头就要小心了，因为它们可能被病毒感染。 近日，360安全研究人员率先发现一个新的针对IoT设备的僵尸网络，并将其命名为“IoT_reaper”。据悉，该僵尸网络利用路由器、摄像头等设备的漏洞，将僵尸程序传播到互联网，感染并控制大批在线主机，从而形成具有规模的僵尸网络。目前，很多厂商的公开漏洞都已经被IoT_reaper病毒所利用，其中包括Dlink(路由器)、Netgear(路由器)、Linksys(路由器)、Goahead(摄像头)、JAWS(摄像头)、AVTECH(摄像头)、Vacron(NVR)等共9个漏洞，感染量达到近200万台设备，且每天新增感染量达2300多次。 360安全研究人员介绍：该恶意程序脱胎于此前曾导致美国断网的僵尸网络mirai，但比mirami的感染途径更广，如果照目前速度继续肆意扩张，其造成的后果将不堪设想。广大用户应及时为IOT设备升级版本，增强设备密码，关闭共享端口，避免被此类僵尸网络感染。 僵尸网络危害极大 曾使美国网络瘫痪所谓僵尸网络，就是攻击者通过各种途径传播僵尸程序，并感染互联网上的大量主机。被感染的主机将通过一个控制信道接收攻击者的指令，组成一个僵尸网络。之所以被称之为“僵尸网络”，是因为众多被感染的计算机在不知不觉中被人驱赶和指挥，成为被人利用的一种工具，如同中国古老传说中的僵尸群一样。 不要小看这些被控制的“僵尸”设备，在2016年10月21日，造成半个美国互联网都瘫痪的罪魁祸首，就是Mirai僵尸网络控制下的数以十万计的物联网设备。在美国断网事件中，美国域名解析服务提供商Dyn公司遭到了峰值达到1.1Tbps 的DDoS攻击，美国东部出现大面积网络瘫痪，包括Twitter、Facebook在内的多家美国网站无法通过域名访问。 IoT_reaper“青胜于蓝” 扩张速度令人担忧本次发现的IoT_reaper借用了部分mirai的源代码，但是在几个关键行为上有显著区别，且比mirai更加“高明”：恶意代码投入时不再使用弱口令猜测、而是使用iot设备漏洞，扫描发现效率大大提高;主动抑制了扫描速度，被安全研究者发现的几率大大降低。 目前很多厂商的公开漏洞都已经被IoT_reaper病毒所利用，其中包括Dlink(路由器)、Netgear(路由器)、Linksys(路由器)、Goahead(摄像头)、JAWS(摄像头)、AVTECH(摄像头)、Vacron(NVR)等共9个漏洞。 目前来看，IoT_reaper规模较大且正在积极扩张，根据360安全中心提供的最近数据显示，IoT_reaper恶意软件已经感染了近200万台设备，日活量已达到10,000台。此外，研究人员指出，恶意软件中还包含100多个DNS解析服务器，能够发动DNS放大攻击。 所幸目前该僵尸网络除了下载样本的指令以外，没有看到实际的DDoS攻击指令，这反映出该僵尸网络仍然处在早期扩张阶段。“但作者在修改代码，因此需要警惕。”360安全研究人员表示。 鉴于该僵尸网络的创建者以及创建目的还未可知，360安全卫士提醒广大用户，一定要及时升级版本安装补丁，修复系统漏洞;给自己的设备及各个账户设置高强度密码，避免被恶意软件轻易破解;并且要关闭不必要的共享端口，防止被恶意程序入侵后变成“僵尸”。 Dlink https://blogs.securiteam.com/index.php/archives/3364 Goahead https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html JAWS https://www.pentestpartners.com/blog/pwning-cctv-cameras/ Netgear https://blogs.securiteam.com/index.php/archives/3409 Vacron NVR https://blogs.securiteam.com/index.php/archives/3445 Netgear seclists.org/bugtraq/2013/Jun/8 Linksys www.s3cur1ty.de/m1adv2013-004 dlink www.s3cur1ty.de/m1adv2013-003 AVTECH https://github.com/Trietptm-on-Security/AVTECH 原文发布时间为：2017-10-30 本文作者：佚名 本文来自云栖社区合作伙伴51CTO，了解相关信息可以关注51CTO。
2017-10-31
优秀的个人博客,低调大师

CDH5之Balancer难以在快速增长的集群上平衡大量的数据

背景： 公司在线上使用了CDH5集群，一开始由于疏忽，忘记了在计划任务中定期执行Balancer来平衡各节点的数据。 后来，在引入大量的Job之后，数据增长非常迅猛，有很多节点开始出现利用率超过99.9%的情况，部分Job甚至开始Failed。 于是我们便执行Balancer来清理数据，结果发现有26T的数据需要平衡，而Balancer每次只移动50G的数据，并且耗时30分钟，而集群每个小时新写入的数据会导致又有40-60G的数据需要平衡。这样一来，Balancer就根本无法胜任了。 14/10/14 20:31:11 INFO balancer.Balancer:Need to move 26.49 TB to make the cluster balanced. 14/10/14 20:31:11 INFO balancer.Balancer:Decided to move 10 GB bytes from 10.100.1.10:50010 to 10.100.1.60:50010 14/10/14 20:31:11 INFO balancer.Balancer:Decided to move 10 GB bytes from 10.100.1.20:50010 to 10.100.1.70:50010 14/10/14 20:31:11 INFO balancer.Balancer:Decided to move 10 GB bytes from 10.100.1.30:50010 to 10.100.1.80:50010 14/10/14 20:31:11 INFO balancer.Balancer:Decided to move 10 GB bytes from 10.100.1.40:50010 to 10.100.1.90:50010 14/10/14 20:31:11 INFO balancer.Balancer:Decided to move 10 GB bytes from 10.100.1.50:50010 to 10.100.1.100:50010 14/10/14 20:31:11 INFO balancer.Balancer:Will move 50 GBinthisiteration ......... 解决办法： 1. 增加Balancer可操作的带宽 我们思考，是否是因为Balancer的默认带宽太小，所以效率低下，于是我们尝试将Balancer的带宽扩容到了500M/s： hadoop dfsadmin -setBalancerBandwidth 524288000但问题并没有得到太大的改善。2. 强行对节点进行Decommission 我们发现，当对一些节点进行Decommission操作时，上面的数据虽然有10-30T甚至更多，但总能在1天内全部Copy到其它的节点上，这里面由于默认集群副本数为3的原因，应该只有1/3的数据被复制了，但数据是完整的，并且被复制出去的数据也是平均分配到各个节点上的。那么我们何不使用它来作为一个类似Balancer的功能来解决一些磁盘用量超过99.9%的节点呢？ 事实证明，这个方法非常可行，我们针对线上8个节点进行了Decommission操作（注意要尽量一台一台进行），在完成下线之后再立刻格式化数据磁盘，并重新添加回集群，新的数据也会非常快的平衡过来。比较完美的解决了之前头疼的问题，并且只花费了不到4天的时间。 3. Hadoop对LVM磁盘卷的支持问题 在解决Balancer的问题时，我们还发现，Hadoop对LVM磁盘卷的支持不是很好，表现在如果在一块磁盘上创建了逻辑卷/根分区等，再创建了逻辑卷/data1分区，Hadoop会一直将/data1写到100%，然后导致一些Job提示没有空间写入。我们猜想Hadoop应该是物理卷为单位来控制用量的。因此，我们不得不将这些包含了逻辑卷数据磁盘的主机重新安装，并分配单独的物理卷，如/dev/sda3作为/data1挂载，便再也没有以上问题。 转： http://heylinux.com/archives/3392.html
2016-03-07
优秀的个人博客,低调大师

【差分隐私】基本原理与入门级应用 | 京东云技术团队

差分隐私（Differential Privacy，DP）是密码学中的一种手段，可以提高从统计数据库进行数据查询的准确性，同时帮助最大限度减少识别其具体记录的机会。DP一般分为：CDP（Centralized Differential Privacy）、LDP（Local Differential Privacy）。 一、CDP 1.1 基本定义 保护效果：查询者无法判断特定样本是否在一个数据集当中。 1.2 应用举例 1.3 全局敏感度 1.4 数据裁剪 COUNT函数的GS始终为1，但是SUM函数的GS就不好说了，因为这要看SUM作用于哪个属性列，如：年龄和收入应用SUM就有很大差异。如1.2所述，我们应用Laplace扰动机制时需要f(x)（此处为SUM）的有界全局敏感度，但SUM显然不容易做到，因此需要对待处理的列进行裁剪处理，以得到f(x)的有界全局敏感度。有两点需要特别注意： • 在裁剪造成的信息损失与满足差分隐私所需要的噪声间进行trade off，一般裁剪后要尽可能保留100%的信息。 • 不能通过查看数据集来确定裁剪边界，这可能会泄露信息，同时也不满足差分隐私的定义。 那我们应该如何对属性列进行裁剪动作，一般有如下两个做法： • 根据数据集先天满足的一些性质来确定裁剪办界。如人的年龄一般在0~125岁之间。 • 采用差分隐私问询估计选择的边界是否合理。先通过数据变换把属性列映射为非负值，然后将裁剪下界置0，逐渐增加上界，直至问询输出不变。 1.5 向量值函数及其敏感度 1.6 Laplace机制 1.7 Gaussian机制 1.8 Laplace vs Gaussian 向量值Laplace机制需要使用L1敏感度，而向量值Gaussian机制L1和L2敏感度都可以使用。在L2敏感度远低于L1敏感度的场景下，Gaussian机制添加的噪声要小得多。向量值Laplace和Gaussian的发布规则为： 1.9 指数机制 前述Laplace和Gaussian机制的回复都是数值型的，只需要直接在回复的数值结果上添加噪声即可。如果我们想从一个备选回复集合中选出最佳结果，同时又保证回复过程满足差分隐私，那应该怎么办呢？一种可行的方法是使用指数机制。首先，定义一个备选回复集合；然后，再定义评分函数，评分函数输出备选集合中每个回复的分数；分数最高的回复就是最大回复。指数机制通过返回分数近似最大的回复来实现差分隐私保护。 报告噪声最大值 1.10 组合性与后处理性 二、LDP 2.1 LDP基本定义 2.2 LDP经典算法 2.3 LDP举例-随机应答 有n个用户，假设X病患者的真实比例为Π，我们希望对这个比例进行统计。于是我们发起一个敏感问题：“你是否为X病患者？”，每个用户的答案是yes or no。出于隐私性考虑，用户可能不会给出正确答案[5]。 我们可以对每位用户的回答加一些数据扰动。比如：用户正确回答的概率为p，错误回答概率为(1-p)。这样就不会准确知道每位用户的真实答案，相当于保护了用户隐私。按此规则我们统计回答yes与no的用户占比。 DP在机器学习领域的应用、基于Gaussian机制实现LDP的原理请听下回分享。 参考资料 1.Balle B, Wang Y X. Improving the gaussian mechanism for differential privacy: Analytical calibration and optimal denoising[C]//International Conference on Machine Learning. PMLR, 2018: 394-403. 2. https://programming-dp.com/ 3.Cynthia Dwork, Aaron Roth, and others. The algorithmic foundations of differential privacy. Foundations and Trends® in Theoretical Computer Science, 9(3–4):211–407, 2014. 4.Xiong X, Liu S, Li D, et al. A comprehensive survey on local differential privacy[J]. Security and Communication Networks, 2020, 2020: 1-29. 5.LDP随机响应技术举例： https://zhuanlan.zhihu.com/p/472032115 作者：京东科技 李杰 内容来源：京东云开发者社区
2023-06-12
优秀的个人博客,低调大师

「Spark从精通到重新入门(一)」Spark 中不可不知的动态优化

前言 Apache Spark 自 2010 年面世，到现在已经发展为大数据批计算的首选引擎。而在 2020 年 6 月份发布的Spark 3.0 版本也是 Spark 有史以来最大的 Release，其中将近一半的 issue 都属于 SparkSQL。这也迎合我们现在的主要场景（90% 是 SQL），同时也是优化痛点和主要功能点。我们 Erda 的 FDP 平台（Fast Data Platform）也从 Spark 2.4 升级到 Spark 3.0 并做了一系列的相关优化，本文将主要结合 Spark 3.0 版本进行探讨研究。 ​ 为什么 Spark 3.0 能够“神功大成”，在速度和性能方面有质的突破？本文就为大家介绍 Spark 3.0 中 SQL Engine 的“天榜第一”——自适应查询框架 AQE（Adaptive Query Execution）。 AQE，你是谁？ ​ 简单来说，自适应查询就是在运行时不断优化执行逻辑。 ​ Spark 3.0 版本之前，Spark 执行 SQL 是先确定 shuffle 分区数或者选择 Join 策略后，再按规划执行，过程中不够灵活；现在，在执行完部分的查询后，Spark 利用收集到结果的统计信息再对查询规划重新进行优化。这个优化的过程不是一次性的，而是随着查询会不断进行优化, 让整个查询优化变得更加灵活和自适应。这一改动让我们告别之前无休止的被动优化。 ​ AQE，你会啥？ ​ 了解了 AQE 是什么之后，我们再看看自适应查询 AQE 的“三板斧”： ​ 动态合并 Shuffle 分区 动态调整 Join 策略 动态优化数据倾斜 动态合并 shuffle 分区 ​ 如果你之前使用过 Spark，也许某些“调优宝典”会告诉你调整 shuffle 的 partitions 数量，默认是 200。但是在不同 shuffle 中，数据的大小和分布基本都是不同的，那么简单地用一个配置，让所有的 shuffle 来遵循，显然不是最优的。 ​ 分区过小会导致每个 partition 处理的数据较大，可能需要将数据溢写到磁盘，从而减慢查询速度；分区过大又会带来 GC 压力和低效 I/O 等问题。因此，动态合并 shuffle 分区是非常必要的。AQE 可以在运行期间动态调整分区数来达到性能最优。 ​ 如下图所示，如果没有 AQE，shuffle 分区数为 5，对应执行的 Task 数为 5，但是其中有三个的数据量很少，任务分配不平衡，浪费了资源，降低了处理效率。 ​ 而 AQE 会合并三个小分区，最终只执行三个 Task，这样就不会出现之前 Task 空转的资源浪费情况。 动态调整 join 策略 ​ SparkJoin 策略大致可以分三种，分别是 Broadcast Hash Join、Shuffle Hash Join 和 SortMerge Join。其中 Broadcast 通常是性能最好的，Spark 会在执行前选择合适的 Join 策略。 ​ 例如下面两个表的大小分别为 100 MB 和 30 MB，小表超过 10 MB (spark.sql.autoBroadcastJoinThreshold = 10 MB)，所以在 Spark 2.4 中，执行前就选择了 SortMerge Join 的策略，但是这个方案并没有考虑 Table2 经过条件过滤之后的大小实际只有 8 MB。 ​ AQE 可以基于运行期间的统计信息，将 SortMerge Join 转换为 Broadcast Hash Join。 ​ 在上图中，Table2 经过条件过滤后真正参与 Join 的数据只有 8 MB，因此 Broadcast Hash Join 策略更优，Spark 3.0 会及时选择适合的 Join 策略来提高查询性能。 ​ 动态优化数据倾斜 数据倾斜一直是我们数据处理中的常见问题。当将相同 key 的数据拉取到一个 Task 中处理时，如果某个 key 对应的数据量特别大的话，就会发生数据倾斜，如下图一样产生长尾任务导致整个 Stage 耗时增加甚至 OOM。之前的解决方法比如重写 query 或者增加 key 消除数据分布不均，都非常浪费时间且后期难以维护。 ​ AQE 可以检查分区数据是否倾斜，如果分区数据过大，就将其分隔成更小的分区，通过分而治之来提升总体性能。 ​ 没有 AQE 倾斜优化时，当某个 shuffle 分区的数据量明显高于其他分区，会产生长尾 Task，因为整个 Stage 的结束时间是按它的最后一个 Task 完成时间计算，下一个 Stage 只能等待，这会明显降低查询性能。 ​ 开启 AQE 后，会将 A0 分成三个子分区，并将对应的 B0 复制三份，优化后将有 6 个 Task 运行 Join，且每个 Task 耗时差不多，从而获得总体更好的性能。通过对倾斜数据的自适应重分区，解决了倾斜分区导致的整个任务的性能瓶颈，提高了查询处理效率。 自适应查询 AQE 凭借着自己的“三板斧”，在 1TB TPC-DS 基准中，可以将 q77 的查询速度提高 8 倍，q5 的查询速度提高 2 倍，且对另外 26 个查询的速度提高 1.1 倍以上，这是普通优化无法想象的傲人战绩！ ​ 真的吗？我不信 口说无凭，自适应查询 AQE 的优越性到底是如何实现，我们“码”上看看。 ​ AQE 参数说明 #AQE开关 spark.sql.adaptive.enabled=true #默认false，为true时开启自适应查询，在运行过程中基于统计信息重新优化查询计划 spark.sql.adaptive.forceApply=true #默认false，自适应查询在没有shuffle或子查询时将不适用，设置为true将始终使用 spark.sql.adaptive.advisoryPartitionSizeInBytes=64M #默认64MB,开启自适应执行后每个分区的大小。合并小分区和分割倾斜分区都会用到这个参数 #开启合并shuffle分区 spark.sql.adaptive.coalescePartitions.enabled=true #当spark.sql.adaptive.enabled也开启时，合并相邻的shuffle分区，避免产生过多小task spark.sql.adaptive.coalescePartitions.initialPartitionNum=200 #合并之前shuffle分区数的初始值，默认值是spark.sql.shuffle.partitions，可设置高一些 spark.sql.adaptive.coalescePartitions.minPartitionNum=20 #合并后的最小shuffle分区数。默认值是Spark集群的默认并行性 spark.sql.adaptive.maxNumPostShufflePartitions=500 #reduce分区最大值，默认500，可根据资源调整 #开启动态调整Join策略 spark.sql.adaptive.join.enabled=true #与spark.sql.adaptive.enabled都开启的话，开启AQE动态调整Join策略 #开启优化数据倾斜 spark.sql.adaptive.skewJoin.enabled=true #与spark.sql.adaptive.enabled都开启的话，开启AQE动态处理Join时数据倾斜 spark.sql.adaptive.skewedPartitionMaxSplits=5 #处理一个倾斜Partition的task个数上限，默认值为5； spark.sql.adaptive.skewedPartitionRowCountThreshold=1000000 #倾斜Partition的行数下限，即行数低于该值的Partition不会被当作倾斜，默认值一千万 spark.sql.adaptive.skewedPartitionSizeThreshold=64M #倾斜Partition的大小下限，即大小小于该值的Partition不会被当做倾斜，默认值64M spark.sql.adaptive.skewedPartitionFactor=5 #倾斜因子，默认为5。判断是否为倾斜的 Partition。如果一个分区(DataSize>64M*5) || (DataNum>(1000w*5)),则视为倾斜分区。 spark.shuffle.statistics.verbose=true #默认false，打开后MapStatus会采集每个partition条数信息，用于倾斜处理 AQE 功能演示 ​ Spark 3.0 默认未开启 AQE 特性，样例 sql 执行耗时 41 s。 ​ 存在 Task 空转情况，shuffle 分区数始终为默认的 200。 ​ 开启 AQE 相关配置项，再次执行样例 sql。 ​ 样例 sql 执行耗时 18 s，快了一倍以上。 ​ 并且每个 Stage 的分区数动态调整，而不是固定的 200。无 task 空转情况，在 DAG 图中也能观察到特性开启。 ​ 总结 Spark 3.0 在速度和性能方面得提升有目共睹，它的新特性远不止自适应查询一个，当然也不意味着所有的场景都能有明显的性能提升，还需要我们结合业务和数据进行探索和使用。 ​ 注：文中部分图片源自于网络，侵删。
2021-12-01

资源下载

更多资源
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-05-30 大小: 1.42GB 下载: 5次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2025-12-03 大小: 9.84MB 下载: 39次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册