精华内容
下载资源
问答
  • hadoop的版本优化

    2019-08-16 10:41:07
    hadoop已经成为了大数据公认的处理框架,在业内得到广泛应用,又因其为开源项目,所以在开源社区十分活跃,在使用过程中逐渐得到改进完善。通过不断的优化提升,hadoop的生态组件也越来越丰富,支持的场景应用...

    优化与发展

    hadoop已经成为了大数据公认的处理框架,在业内得到广泛应用,又因其为开源项目,所以在开源社区十分活跃,在使用过程中逐渐得到改进和完善。通过不断的优化和提升,hadoop的生态组件也越来越丰富,支持的场景应用越来越广泛,提高了集群的可用性以及带来更高的资源利用率。

    新特性

    组件 hadoop1.0 hadoop2.0
    HDFS 名称节点单点故障 设计HDFS HA,提供节点热备份机制
    HDFS 单一命名空间,无法资源隔离 设计HDFS联邦,管理多个命名空间
    mapreduce 资源管理效率低 引入YARN资源管理器

    HDFS2.0

    2.0增加了HA(High Available)和联邦等新特性

    HDFS HA

    在前面介绍的HDFS原理中,介绍了名称节点存储了集群的两个核心文件Editlog和FsImage,如果没有一个机制来保证实时数据的备份,那么一旦发生故障,势必会造成一部分EditLog的操作丢失。第二名称节点起到的作用仅仅是在EditLog文件变大的时候进行与FsImage的合并,并不能直接充当热备份节点来恢复集群。

    在2.0中引入了HA架构,在集群中设置两个名称节点,在集群启动时,推选出一个节点处于“活跃(Active)"状态,另外一个处于”待命(stanby)“状态。活跃状态的节点负责响应客户端的请求,待命状态节点负责同步活跃节点的数据,提供”热备份“的能力。
    HDFS2.0架构
    由架构图看出,为了实现两个名称节点同步,需要一个共享文件系统来连接两边的EditLog文件,通常有NFS、QJM、Zookeeper。活跃节点将更新数据写入到共享文件系统,待命节点接听文件系统,一旦有文件写入,就立即从共享文件系统读取这些数据并加载到自己内存中,从而保证活跃节点的同步。另外一个需要注意的是,名称节点对数据节点是被动接收数据节点心跳的方式,所以为了保证在名称节点故障切换的时候可以获得数据节点的信息,数据节点再一次心跳汇报的时候像两个名称节点汇报。而Active和Stanby的竞选则由Zookeeper来实现,保证同一时刻只有一个处于活跃状态对外提供服务。

    HDFS 联邦

    在1.0中不仅存在单点故障问题,还有可扩展性、性能和隔离性等问题。在可扩展性上,HDFS1.0只用一个名称节点,随着系统运行,名称节点保存的元数据信息越来越大,限制了文件、目录的数目。如果通过纵向扩展,比如增加内存、CPU,这就会导致集群元数据过大导致启动时间变得更长,影响用户体验。
    在系统性能方面,在面对客户端并发时受限于名称节点的吞吐量。单个名称节点也难以提供不用程序的隔离性,一个程序可能影响其他程序的正常运行。
    联邦的设计
    在联邦设计中,设计多个互相独立的名称节点,这些名称节点分别进行各自的命名空间和块的管理,在水平扩展上形成联邦关系。所有名称节点共享底层的数据节点资源,每个数据节点向集群中所有的名称节点发送心跳包和块信息,报告自己的状态,同时也会响应名称节点的指令。

    HDFS联邦访问
    采用客户端挂载表方式把各个命名空间挂债到全局”挂载表“中,实现数据全局共享。

    较HDFS1.0的优点

    • HDFS集群水平可扩展性。多个名称节点分管一部分目录,使得一个集群扩展到更多节点,不会再因为内存限制制约文件存储数目
    • 性能更高效。多个节点管理不同的数据,且能同时对外提供服务,为客户带来更多吞吐率。
    • 良好的隔离。通过业务区分对名称节点的访问,业务与业务之间影响很小。

    新一代资源管理调度框架YARN

    MapReduce1.0缺陷

    mapreduce1.0采用C/S架构,一个JobTracker和若干个TaskTracker,前者负责任务调度和资源管理,后者负责具体任务执行。

    1. 单点故障。单个JobTracker负责集群的mapreduce作业调度,一旦出现故障系统将不可用。
    2. JobTracker任务过重,消耗大量资源且容易导致任务执行失败,业内总结mapreduce1.0支持主机的上限为4000台。
    3. 容易出现内存溢出,在实际工作中,资源分配并不考虑CPU,内存等实际使用情况,只根据mapreduce的任务个数来分配资源。
    4. 资源划分不合理,资源被强制等分划分成多个slot,slot又进一步划分为map槽和reduce槽,彼此之间不能使用对方的槽。

    YARN的诞生

    为了克服上述问题,在hadoop2.0版本后,设计了YARN框架,包含ResourceManager、AppMaster和NodeManager,其中ResourceManager负责资源管理,由AppMaster负责任务调度和监控,NodeManager负责执行原TaskTracker的任务。这种设计大大降低了JobTracker的负担,提高系统运行效率和稳定性。

    在1.0中mapreduce不仅仅是计算框架,还是一个任务调度框架。到了2.0mapreduce变成纯粹的计算框架,不再自己负责资源调度,而是由YARN来完成。

    ResourceManager

    • 处理客户端请求
    • 启动/监控AppMaster
    • 监控NodeManager
    • 资源分配与调度
      RM是一个全局资源管理器,负责整个系统的资源管理和分配,主要有两个组件,调度器(Scheduler)和应用程序管理器(AppManager)。调度器主要负责资源管理和分配。调度器接收来自AppManager的应用程序资源请求,并根据容量、队列等限制条件,把集群中的资源以”容器“的形式分配给提出请求的应用程序。每个容器封装了一定数量的CPU、内存、磁盘资源等,从而限定每个应用程序可以使用的资源量。常见的调度器有公平调度器、先进先出调度器和容量调度器

    AppMaster

    • 为应用程序申请资源,并分配给内部任务
    • 任务调度、监控和容错
      作业提交申请后,AppMaster向RM申请资源,RM以容器的方式返回资源给AppMaster,由AppMaster给map任务或reduce任务分配资源。AppMaster与nodemanager保持通信进行应用程序的启动、运行、监控和停止,监控资源使用情况,对任务的执行进度和状态监控,处理失败恢复,定时向RM汇报资源使用情况和应用进度信息,作业完成时向RM注销容器,执行周期完成

    NodeManager

    • 单个节点上的资源管理
    • 处理来自ResourceManager的命令
    • 处理来自NodeManage的命令
      NodeManager负责容器生命周期管理,监控每个容器的资源使用情况,跟踪节点健康情况。NodeManager只负责抽象的容器,只处理与容器相关的事情,而不具体负责每个任务自身状态管理。

    部署

    ResourceManager 部署在名称节点
    AppMaster、NodeManager部署在每个数据节点

    展开全文
  • 安家岭露天矿生产二队借鉴先进的管理模式和理念,通过对原有的管理模式加以完善改进,制定出了与生产二队相适应的新型管理模式。新管理模式在未增加任何专职管理人员和管理机构的情况下,极大地提升了安全、生产管理...
  • 目录 ...4. 提升检测效果 5. 总结 6. AlexeyAB大神改进 darknet优化经验 主要来自于:AlexeyAB 版本darknet 1. AlexeyAB改进项 提供window支持 相较于原版pjreddie...

    darknet优化经验

    主要来自于:AlexeyAB 版本darknet

    1. AlexeyAB改进项

    • 提供window支持

    • 相较于原版pjreddie版本darknet提升了训练速度

    • 添加了二值化网络,XNOR(bit) ,速度快,准确率稍低https://github.com/AlexeyAB/darknet/blob/master/cfg/yolov3-tiny_xnor.cfg

    • 提升7%通过将卷积层和BN层合并为一个(*_*)不太懂。

    • 多GPU训练提升

    • 修补了[reorg]层

    • 添加了mAP, IOU,Precision-Recall计算

      darknet detector map...

    • 可以在训练过程中画loss图像

    • 添加了根据自己数据集的anchor生成

    • 提升视频检测,网络摄像头,opencv相关问题

    • 提出了一个INT8的网络,提升了检测速度,但是准确率稍有下降

      https://github.com/AlexeyAB/yolo2_light

    2. Linux下编译选项

    • GPU=1 to build with CUDA to accelerate by using GPU (CUDA should be in /usr/local/cuda)
    • CUDNN=1 to build with cuDNN v5-v7 to accelerate training by using GPU (cuDNN should be in /usr/local/cudnn)
    • CUDNN_HALF=1 to build for Tensor Cores (on Titan V / Tesla V100 / DGX-2 and later) speedup Detection 3x, Training 2x
    • OPENCV=1 to build with OpenCV 3.x/2.4.x - allows to detect on video files and video streams from network cameras or web-cams
    • DEBUG=1 to bould debug version of Yolo
    • OPENMP=1 to build with OpenMP support to accelerate Yolo by using multi-core CPU
    • LIBSO=1 to build a library darknet.so and binary runable file uselib that uses this library. Or you can try to run so LD_LIBRARY_PATH=./:$LD_LIBRARY_PATH ./uselib test.mp4 How to use this SO-library from your own code - you can look at C++ example: https://github.com/AlexeyAB/darknet/blob/master/src/yolo_console_dll.cpp or use in such a way: LD_LIBRARY_PATH=./:$LD_LIBRARY_PATH ./uselib data/coco.names cfg/yolov3.cfg yolov3.weights test.mp4

    3. 训练经验

    • 首先对数据集进行检错,使用提供的如下库进行检测:

    https://github.com/AlexeyAB/Yolo_mark

    • 什么时候停止训练

      • avg loss不再下降的时候

      • 通常每个类需要2000-4000次迭代训练即可

      • 防止过拟合:需要在Early stopping point停止训练

        使用以下命令:

        darknet.exe detector map...

        建议训练的时候带上-map,可以画图

        loss_chart_map_chart

    4. 提升检测效果

    • random=1可以设置适应多分辨率

    • 提升分辨率:416--> 608等必须是32倍数

    • 重新计算你的数据集的anchor:(注意设置的时候计算问题)

      darknet.exe detector calc_anchors data/obj.data -num_of_clusters 9 -width 416 -height 416

    • 检查数据集通过https://github.com/AlexeyAB/Yolo_mark

    • 数据集最好每个类有2000张图片,至少需要迭代2000*类的个数

    • 数据集最好有没有标注的对象,即负样本,对应空的txt文件,最好有多少样本就设计多少负样本。

    • 对于一张图有很多个样本的情况,使用max=200属性(yolo层或者region层)

    • for training for small objects - set layers = -1, 11 instead of https://github.com/AlexeyAB/darknet/blob/6390a5a2ab61a0bdf6f1a9a6b4a739c16b36e0d7/cfg/yolov3.cfg#L720 and set stride=4 instead of https://github.com/AlexeyAB/darknet/blob/6390a5a2ab61a0bdf6f1a9a6b4a739c16b36e0d7/cfg/yolov3.cfg#L717

    • 训练数据需要满足以下条件:

      • train_network_width * train_obj_width / train_image_width ~= detection_network_width * detection_obj_width / detection_image_width
      • train_network_height * train_obj_height / train_image_height ~= detection_network_height * detection_obj_height / detection_image_height
    • 为了加速训练,可以做fine-tuning而不是从头开始训练,设置stopbackward=1在网络的结束部分(以####作为分割)

    • 在训练完以后,进行目标检测的时候,可以提高网络的分辨率,以便刚好检测小目标。

      • 不需要重新训练,需要使用原先低分辨率的权重,测用更高分辨率。
      • 为了得到更高的检测效果,可以提升分辨率至608*608甚至832*832

    5. 总结

    为了小目标:

    • 提升分辨率
    • 在测试时候提升分辨率
    • 数据集添加跟正样本数量一样多的负样本
    • 数据集每个类至少2000张,训练迭代次数2000*classes个数
    • 设置自己数据集的anchor

    6. AlexeyAB大神改进

    • web-cam版本:

    ./darknet detector demo ... -json_port 8070 -mjpeg_port 8090

    • 计算mAP, F1, IoU, Precision-Recall

    ./darknet detector map ...

    • 展示map-loss曲线(需要opencv)

    ./darknet detector train cfg/voc.data cfg/yolo.cfg -dont_show -mjpeg_port 8090 -map

    • 计算聚类产生的anchor

    ./darknet detector calc_anchors data/voc.data -num_of_clusters 12 -width 608 -height 608

    • 分离前部基础网络

    ./darknet partial cfg/darknet19_448.cfg darknet19_448.weights darknet19_448.conv.23 23

    • 测试opencv

    ./darknet imtest data/eagle.jpg

    • 阈值设置

    -thresh 0

    代码改变世界

    转载于:https://www.cnblogs.com/clemente/p/10660001.html

    展开全文
  • 针对其1.0版本的不足改进提升2.1 Hadoop框架自身的改进提升2.2 Hadoop生态系统的完善3. HDFS2.03.1 HDFS HA3.2 HDFS 联邦 1. Hadoop(1.0)的局限与不足 抽象层次低。需要手工编写代码来完成,有时只是为了...

    1. Hadoop(1.0)的局限与不足

    1. 抽象层次低。需要手工编写代码来完成,有时只是为了实现一个简单的功能,也要手工编写大量的代码。
    2. 表达能力有限。Hadoop把复杂的分布式编程高度抽象到两个函数Map和Reduce上,在降低使用难度的同时,但也带来了表达能有限的问题,实际操作的时候有些问题并不能单单靠这两个函数来解决问题。
    3. 开发者自己管理作业之间的依赖关系。一个作业Job只包含Map和Reduce两个阶段,通常的实际应用问题需要大量的作业协调才能顺利解决,这些作业之间往往存在着复杂的依赖关系,但是MapReduce框架本身并没有提供相关的机制来对这些依赖关系进行有效的管理,只能开发者自己管理。
    4. 难以看到程序的整体逻辑。用户处理的逻辑都隐藏在代码的细节当中,没有更高层次的抽象机制对程序整体逻辑进行设计,这就给代码理解和后期的维护带来了障碍。
    5. 执行迭代操作效率低。对于一些大型的机器学习,数据挖掘任务,往往需要更多轮次迭代才能得到结果。采用MapReduce实现这些算法的时候,每次迭代都是执行一次Map,Reduce任务的过程,这个过程的数据来源于分布式文件系统HDFS中,本此的迭代处理的结果也放在HDFS中,继续用于下一次的迭代。反复读写HDFS中的数据,大大降低了迭代操作的效率。
    6. 资源浪费。在MapReduce的框架设计中,Reduce任务必须等待所有的Map任务执行完毕后再开始执行,造成不必要资源的浪费。
    7. 实时性差。只是适用于离线批数据处理,无法支持交互式数据处理,实时数据的处理。

    2. 针对其1.0版本的不足改进和提升

    2.1 Hadoop框架自身的改进和提升

    组件 Hadoop1.0的问题 Hadoop2.0的改进
    HDFS 1.单一名称节点,存在单点失效的问题。
    2.单一命名空间,无法实现资源隔离。
    1.设计了HDFS HA,提供名称节点的热备份机制。
    2.设计了HDFS联邦,管理多个命名空间
    MapReduce 资源管理效率低 设计了新的资源管理框架YARN

    2.2 Hadoop生态系统的完善

    组件 功能 解决Hadoop中存在的问题
    Pig 处理大规模数据的脚本语言,用户只需要编写几条简单的语句,系统就会自动转换为MapReduce作业 抽象层次低,需要手工编写大量的代码
    Oozie 工作流和协作服务引擎,协调Hadoop上运行的不同任务 没有提供作业依赖关系管理机制,需要用户自己处理作业之间的依赖关系
    Tez 支持DAG作业的计算框架,对作业的操作进行重新分解和组合,形成一个大的DAG作业,减少不必要的操作 不同的MapReduce任务之间存在重复操作,降低了效率
    kafka 分布式发布订阅消息系统,我的另一篇博文中有介绍 Hadoop生态系统中各个组件和其他产品之间缺乏统一的,高效的数据交换中介

    3. HDFS2.0

    3.1 HDFS HA

    对于分布式文件系统HDFS而言,名称节点(NameNode)是系统的核心节点,因为它存储了各类元数据的信息,并负责管理文件系统的命名空间和客户端对文件的访问。但是在HDFS1.0当中,只存在一个单一的名称节点,一旦这个名称节点宕掉那么整个HDFS就会崩掉,虽然存在第二名称节点(SecondNode),但其的主要作用是合并FsImage和EditLog文件,减少名称节点的压力和加快HDFS启动的时间,并不可以作为名称节点的备份节点,因为在其从名称节点拉回FsImage和EditLog进行合并的时候,HDFS新的对文件的操作其并不能进行记录, 故不能作为名称节点的实时备份切换节点。(详细了解名称节点和第二名称节点的工作原理我的这篇博文

    为了解决上述所存在的,第二名称节点无法提供“热备份”的功能,即在名称节点发生故障的时候,系统无法实时的切换到第二名称节点立即对外提供服务,存在单点故障的问题。设计出了HA(High Availability)架构

    3.1.1 架构简介

    在一个典型的HA集群当中,一般设置两个名称节点,其中一个处于“活跃”状态,另一个处于“待命”状态。处于活跃状态的名称节点负责对外处理所有客户端的请求,而处于待命状态的名称节点则作为备用节点,保存足够多的元数据信息,当名称节点出现故障的时候提供快速回复的能力。一旦活跃的名称节点出现故障,就可以立即切换到待命的名称节点,不会影响到系统的正常的对外服务。

    3.1.2 详细解析HA架构如何工作

    在这里插入图片描述
    如上图是我画的HDFS HA的架构图。

    1. 由于待命的名称节点在活跃的名称节点出现故障的时候是可以实时立即切换对外提供服务的,所以二者的状态信息必须实时的同步,包括写操作的信息,数据存储等等的元数据信息。
    2. 实现这些通过一个共享的存储系统(Zookeeper) 来实现。活跃的名称节点将跟新数据写入共享存储系统当中,待命的名称节点会一直监听该系统,一旦发现有新的写入,就立即从公共存储系统中读取这些数据并加载到自己的内存当中,从而保证和活跃名称节点同步。
    3. 对于名称节点中保存的数据块到实际存储位置的映射信息,即每个数据块是由哪个数据节点所存储的。当一个数据节点加入到HDFS集群的时候,它会把自己所包含的数据块列表报告给名称节点,此后通过“心跳”的方式定期执行这个操作,以确保名称节点的块映射是最新的。因此,为了做到这一点,需要给数据节点配置两个名称节点的地址,并把块的信息和心跳信息同时发送给这两个名称节点。
    4. Zookeeper保证任意时刻只有唯一一个名称节点对外提供服务。
    5. 当然所有的数据都是保存在本地的Linux系统当中的。

    3.2 HDFS 联邦

    3.2.1 HDFS1.0当中存在的问题

    • 在1.0的版本当中,是只有一个单一的名称节点的,其内存中包含了整个HDFS系统中的元数据信息,不可以进行水平扩展。
    • 单个的名称节点的内存空间是有限的,这就限制了系统中的数据块,文件和目录的数目。
    • 整个HDFS的系统吞吐量会受限制于单个名称节点的吞吐量。
    • 隔离性方面,单个名称节点无法提供不同程序之间的隔离性,一个程序的运行很可能会影响其它程序的运行。
    • HDFS HA虽然提供了两个名称节点,但是实际上正则在对外提供服务的任然是一个名称节点,之解决了单点故障的问题。

    3.2.2 HDFS联邦的设计

    • 在HDFS联邦中,设计了多个相互独立的名称节点,使得HDFS的命名服务可以很好的水平扩展,这些名称节点分别自己管理各自的命名空间和块的管理,相互之间是联邦关系,不需要彼此之间进行协调。
    • HDFS联邦有很好的向后兼容性,可以无缝地支持单名称节点架构中的配置。所以,针对单名称节点的部署配置,不需要做任何的修改。
    • 我理解认为,这些相互独立的名称节点,每个每个名称节点都用着HA 的架构,整个联邦是多个HA集群的并联。
    • HDFS联邦中的名称节点提供了命名空间和管理功能。在HDFS联邦中,所有的名称节点会共享底层的数据节点存储资源,每个数据节点要向集群中所有的数据节点注册,并周期性地向名称节点发送“心跳”和块的信息,报告自己的状态,并处理来自名称节点的命令。
    • 在HDFS联邦中,有多个独立的命名空间,其中,每个命名空间管理属于自己的一组块,这些属于同一个命名空间的块构成一个“块池”。每个数据节点会为多个块池提供块的存储。
    • 数据节点是物理概念,块池属于逻辑概念,一个块池是一组块的逻辑集合,块池中的各个快实际上是存储在各个不同的数据节点当中的。因此,HDFS联邦中的一个名称节点失效,也不会影响到与它相关的数据节点继续为其他名称节点提供服务。

    3.2.3 HDFS联邦的访问方式

    使用客户端挂载表的方式进行数据共享的访问。
    在这里插入图片描述

    1. 一个阴影三角便代表一个独立的命名空间,上方的空白三角形表示从客户端方向于访问下面的子命名空间。
    2. 客户端可以访问不同的挂载点来访问不同的子命名空间。
    3. HDFS联邦中命名空间管理的基本原理:把各个命名空间挂载到全局“挂载表”中,实现全局的数据共享,同样的,命名空间挂载到个人的挂载表当中,就成为了应用程序可见的命名空间。
    展开全文
  • 通过问卷调查和访谈,研究认为:提升高校"形式与政策"课程的教学效果,应从创新教学理念、整合教学资源、完善教学设计、优化教学环境和严格教学评估等方面入手,改进"讨论互动式"教学,以期进一步提升该课程的教学成效。
  • 中厚煤层采煤机是由某煤机公司研制的,要对其截割部的可靠性进行分析,通过使用ANSYS和ADAMS软件,...基于仿真结果的分析,的充分化完善措施及改进办法,为升级产品、实现采煤机截割部系统级性能的提升提供具体的量化依据。
  • 根据已经有了的数据反馈,拼多多商家可以知道店铺的阶段性运作的情况,根据情况来优化店铺的经营模式,这样可以掌握新产品该往哪个方面来营销发展,掌握营销的节奏和思路。 2、关注数据 商家需要经常对数据进行监测...

    开一个拼多多店铺似乎是一个很简单的事情,但是运营起来还是难道了不少的人,下面小编跟大家一起来看看关于拼多多店铺能力提升,可以从哪些方面来提升。
    在这里插入图片描述

    拼多多店铺能力提升,以下四点:
    1、新品营销
    根据已经有了的数据反馈,拼多多商家可以知道店铺的阶段性运作的情况,根据情况来优化店铺的经营模式,这样可以掌握新产品该往哪个方面来营销发展,掌握营销的节奏和思路。
    2、关注数据
    商家需要经常对数据进行监测,了解店铺的发展状况,需经过数据分析才能知道店铺有哪些地方是不足的,然后才好对症下药,做出改进。完善店铺的经营策略。
    3、做好售后
    要把售后做好,需要客户及时回复、热情礼貌、引导消费、引导好的评价、跟进物流、解决问题等等,拼多多客服是拼多多店铺的核心职位,售后服务的重要依据有(5分钟回复率、3分钟人工回复率、平均人工回复率、查询转化率、客服销售额),根据这些数据,商家可以完善售后。
    4、打造受欢迎店铺
    很重要的就是引流,可以通过站内、站外、付费免费甚至直播的方式进行全面的推广,吸引更多的流量,打造收欢迎的店铺,当然,还是要依托数据进行,数据是基础。通过对数据的研究,才能有一个清晰的思路来实施相应的措施。

    展开全文
  • 的不断改进,GPU被越来越多地应用到非图形领域的计算,出现了一个全新的 研究领域——GPGPU(General Purpose Computation on GPUs)。利用CPU和GPU 构建异构并行系统,以CPU提供通用的基础计算环境,GPU作为加速...
  • 鉴于不完善的束管监测技术可能影响监测结果,...结果表明:改进的双巷束管监测技术切实可行,提升了有效监测时间和数据准确率;推算出014N-11综放工作面氧化自燃带的最大宽度为37.7 m,工作面最小极限推进速度为3.25 m/d。
  • 然后花了一个多小时将bug都修复了,又花了点时间加了几个功能,同时也优化了原有的枚举方法。 代码当然也做了好几重的修改。很多地方也改变了,所以重新写一次博客。 此次改进: 1)效率极大提升,在...
  • 6 Hadoop2.0新特性

    2020-09-30 18:10:57
    相比Hadoop1.0版本,Hadoop2.0的优化改良主要体现在两个方面:一方面是Hadoop自身核心组件架构设计的改进,另一方面是Hadoop集群性能的改进,通过这些优化提升,Hadoop可以支持更多的应用场景,提高资源利用率。...
  • Odoo 11版本说明及功能点

    千次阅读 2018-09-17 12:58:46
    odoo 11 不像odoo前面的几个版本,每个版本对odoo 的某个关键模块做了重大优化,odoo 11重点做的是细节的提升完善,比如更加灵活的发货、比如采购协议、比如速度的优化,.....。通过几百人的专业开发团队和数千...
  • 优化课程内容体系、改进教学方式、加强课程实践教学等方面探索与分析,对生物工程专业发酵工程课程进行了教学改革,以期提高教学质量,提升学生创新精神和创新能力。经过近几年来的教学实践,发酵工程教学工作得到...
  • 大数据环境下的数据质量管理策略

    千次阅读 2018-09-07 16:04:00
    信息时代,数据已经慢慢成为一种资产,...提出一种数据质量策略,从建立数据质量评价体系、落实质量信息的采集分析与监控、建立持续改进的工作机制和完善元数据管理4个方面,多方位优化改进,最终形成一套完善...
  • Discuz! X1.5 最让人期待完善的...优化做了更详细的改进和全新的研发,直接全面提升站点被收录的几率。 对站点进行搜索引擎优化设置一直是广大站长朋友比较关心和关注的问题之一,有些站点开始的时候搜索引擎蜘蛛的抓
  • Typo3 v4.7.5

    2019-10-25 03:38:51
    Typo3是开源内容管理系统(CMS)和内容管理框架(CMF)。特性: 完善的用户和权限管理、认证系统;自动保存编辑中的内容, 自动优化图片;剪切板支持复制、剪切、粘贴;...同时该版本改进了缓存提升了性能。
  • 免费小说爬虫:python3.6+requests+...1.GUI版本中各按钮间的限制关系有待完善。 2.对于线程的理解和进一步运用能力还需提高。 3.UI与耗时间任务的分离方法还需优化。 有很多可以提升的地方,请多多指教。 ...
  • 招聘高级产品经理

    2019-09-14 19:44:20
    岗位职责 1、负责用户需求分析、市场分析,制定产品设计方案及产品发展计划; 2、绘制产品设计草图,书写逻辑缜密的产品需求文档;...4、对产品进行持续优化改进完善功能,不断提升产品用户体验; ...
  • 围绕上面三点原则,TiDB 做了大量的改进,一些是对外可见,如 OLAP 性能的显著提升、监控项的大量增加以及运维工具的各项优化,还有更多的改进是隐藏在数据库背后,默默的提升整个数据库的稳定性以及正确性。...
  • 主要有掘进设备落后、施工工艺落后、组织管理不完善及施工者素质不高等,指出采用先进的地质探测技术、改进掘进的设备、采用深孔爆破技术、优化出矸系统、加强施工组织管理等措施,来提升岩巷掘进速度。
  • 今天,我们正式发布了Egret Native1.1.0版本,这个版本中我们重点仍然是放在稳定性提升上,主要改善文字渲染、音频、NativeRenderer 的稳定性以及改进对 DOM事件的支持。 详细内容见下: [新增] 支持 DOMContentLoaded...
  • 意见评论

    2018-12-02 19:51:00
    根据其余各组针对我组提出的意见,我认为,在下一个冲刺周期内,我们团队会...我们还计划继续改进完善软件的功能,让用户背诵完单词后还能及时地进行测试,以此来检测自己的背诵情况,从而来计划自己下一阶段的学...
  • 改进系统后台“安全中心”木马检测功能,进一步完善了文件检测策略,在不降低速度的情况下相对过去版本能提供更为全面的检测,尤其针对疑似木马文件检测效果提升明显;(重要程度:高)9.改进系统后台“安全中心”木马...
  • 围绕上面三点原则,TiDB 做了大量的改进,一些是对外可见,如 OLAP 性能的显著提升、监控项的大量增加以及运维工具的各项优化,还有更多的改进是隐藏在数据库背后,默默的提升整个数据库的稳定性以及正确性。...
  • KesionEshop在线商城系统 X1.5 UTF-8 更新日志:2016-03-221、大量的优化前后台程序代码,兼容性、体验度及性能得到很大的提升.2、自定义表单改进可以设置普通管理员只能管理指定表单,并且增加前台会员可以查看的开关...
  • A 性能优化内置完善的解决方案,继续提升产品负载能力 B 短消息增加多人会话模式,并支持后台批量搜索管理 C 门户DIY新增简洁模式,全面开放,支持第三方产品以API模式接入 D 全新的手机版 E 支持自定义规则的充值卡...
  • 其中 Chrome 88 主要针对安全性、外观设计进行进一步改进完善,而Edge 88 相比上一版本注重于「在线购物」体验,更新重点也重新回到了增加功能性和提升性能上。来看都有哪些变化! 暗色模式细节优化 Chrome ???? ...
  • 航天发射场科研试验质量管理体系...分析了问题产生的根源,并结合靶场实际,着眼未来发展需求、有效地完善质量管理体系提出了对策建议,重点要突出体系知识的宣贯、体系的优化设计、管理模式的改进和信息化工具的应用。

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 176
精华内容 70
关键字:

优化完善提升改进