精华内容
下载资源
问答
  • 通过神华集团科技创新项目"煤基费托合成反应铁系催化剂开发"成功的案例,对企业研究院参与下...同时对项目执行过程中出现的有关问题进行了剖析,提出了企业研究院的功能定位以及对官产学研用科技开发体系运行机制的建议。
  • 以神华集团牵头组建的"煤炭开发利用技术创新战略联盟"产学研合作成功案例为基础,对以企业为主体的纵向产业链结构技术创新体系进行分析,总结了战略联盟创新模式取得的经验,分析了战略联盟运转机制中出现的若干问题,...
  •  1、YARN 并不清楚用户提交的程序的运行机制  2、YARN 只提供运算资源的调度(用户程序向 YARN 申请资源,YARN 就负责分配资源)  3、YARN 中的主管角色叫 ResourceManager  4、YARN 中具体提供运算...

    原 Hadoop MapReduce 框架的问题

    从上图中可以清楚的看出原 MapReduce 程序的流程及设计思路:

    1. 首先用户程序 (JobClient) 提交了一个 job,job 的信息会发送到 Job Tracker 中,Job Tracker 是 Map-reduce 框架的中心,他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上,需要管理所有 job 失败、重启等操作。
    2. TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分,他做的事情主要是监视自己所在机器的资源情况
    3. TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker,JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程。

       可以看得出原来的 map-reduce 架构是简单明了的,在最初推出的几年,也得到了众多的成功案例,获得业界广泛的支持和肯定,但随着分布式系统集群的规模和其工作负荷的增长,原框架的问题逐渐浮出水面,主要的问题集中如下:

    1. JobTracker 是 Map-reduce 的集中处理点,存在单点故障
    2. JobTracker 完成了太多的任务,造成了过多的资源消耗,当 map-reduce job 非常多的时候,会造成很大的内存开销,潜在来说,也增加了 JobTracker fail 的风险,这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
    3. 在 TaskTracker 端,以 map/reduce task 的数目作为资源的表示过于简单,没有考虑到 cpu/ 内存的占用情况,如果两个大内存消耗的 task 被调度到了一块,很容易出现 OOM
    4. 在 TaskTracker 端,把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候,会造成资源的浪费,也就是前面提过的集群资源利用的问题。
    5. 源代码层面分析的时候,会发现代码非常的难读,常常因为一个 class 做了太多的事情,代码量达 3000 多行,,造成 class 的任务不清晰,增加 bug 修复和版本维护的难度。
    6. 从操作的角度来看,现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复,性能提升和特性化 ) 时,都会强制进行系统级别的升级更新。更糟的是,它不管用户的喜好,强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。

     

    YARN 基本架构

    YARN是Hadoop 2.0中的资源管理系统,它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务:一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。
    其中ResourceManager负责整个系统的资源管理和分配,而ApplicationMaster负责单个应用程序的管理。

    YARN中包括以下几个角色:

    1. 客户端(Client):向整个集群提交MapReduce作业。
    2. YARN资源管理器(ResourceManager):负责调度整个集群的计算资源。
    3. YARN节点管理器(NodeManager):在集群的机器上启动以及监控container。
    4. MapReduce应用管理器(MRAppMaster): 调度某个作业的所有任务. 应用管理器和任务运行在container中, container由资源管理器调度, 由节点管理器管理。

    一、YARN 概述 

      YARN 是一个资源调度平台,负责为运算程序提供服务器运算资源,相当于一个分布式的操 作系统平台,而 MapReduce 等运算程序则相当于运行于操作系统之上的应用程序

      YARN 是 Hadoop2.x 版本中的一个新特性。它的出现其实是为了解决第一代 MapReduce 编程 框架的不足,提高集群环境下的资源利用率,这些资源包括内存,磁盘,网络,IO等。Hadoop2.X 版本中重新设计的这个 YARN 集群,具有更好的扩展性,可用性,可靠性,向后兼容性,以 及能支持除 MapReduce 以外的更多分布式计算程序

      1、YARN 并不清楚用户提交的程序的运行机制

      2、YARN 只提供运算资源的调度(用户程序向 YARN 申请资源,YARN 就负责分配资源)

      3、YARN 中的主管角色叫 ResourceManager

      4、YARN 中具体提供运算资源的角色叫 NodeManager

      5、这样一来,YARN 其实就与运行的用户程序完全解耦,就意味着 YARN 上可以运行各种类 型的分布式运算程序(MapReduce 只是其中的一种),比如 MapReduce、Storm 程序,Spark 程序,Tez ……

      6、所以,Spark、Storm 等运算框架都可以整合在 YARN 上运行,只要他们各自的框架中有 符合 YARN 规范的资源请求机制即可

      7、yarn 就成为一个通用的资源调度平台,从此,企业中以前存在的各种运算集群都可以整 合在一个物理集群上,提高资源利用率,方便数据共享

    二、原 MR框架的不足

      1、JobTracker 是集群事务的集中处理点,存在单点故障

      2、JobTracker 需要完成的任务太多,既要维护 job 的状态又要维护 job 的 task 的状态,造成 过多的资源消耗

      3、在 TaskTracker 端,用 Map/Reduce Task 作为资源的表示过于简单,没有考虑到 CPU、内 存等资源情况,当把两个需要消耗大内存的 Task 调度到一起,很容易出现 OOM

      4、把资源强制划分为 Map/Reduce Slot,当只有 MapTask 时,TeduceSlot 不能用;当只有 Reduce Task 时,MapSlot 不能用,容易造成资源利用不足。

      总结起来就是:

        1、扩展性差

        2、可靠性低

        3、资源利用率低

        4、不支持多种计算框架

    三、新版 YARN 架构的优点

      YARN/MRv2 最基本的想法是将原 JobTracker 主要的资源管理和 Job 调度/监视功能分开作为 两个单独的守护进程。有一个全局的 ResourceManager(RM)和每个 Application 有一个 ApplicationMaster(AM),Application 相当于 MapReduce Job 或者 DAG jobs。ResourceManager 和 NodeManager(NM)组成了基本的数据计算框架。ResourceManager 协调集群的资源利用, 任何 Client 或者运行着的 applicatitonMaster 想要运行 Job 或者 Task 都得向 RM 申请一定的资 源。ApplicatonMaster 是一个框架特殊的库,对于 MapReduce 框架而言有它自己的 AM 实现, 用户也可以实现自己的 AM,在运行的时候,AM 会与 NM 一起来启动和监视 Tasks。

    Yarn基本架构

    从YARN的架构图来看,它主要由ResourceManager、NodeManager、ApplicationMaster和Container等以下几个组件构成。

    1)ResourceManager(RM)

    YARN分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。ResourceManager将各个资源部分(计算、内存、带宽等)精心安排给基础NodeManager(YARN的每节点代理)。ResourceManager还与ApplicationMaster一起分配资源,与NodeManager一起启动和监视它们的基础应用程序。在此上下文中,ApplicationMaster承担了以前的TaskTracker的一些角色,ResourceManager承担了JobTracker 的角色。

    总的来说,RM有以下作用

    (1)处理客户端请求

    (2)启动或监控ApplicationMaster

    (3)监控NodeManager

    (4)资源的分配与调度

    2)ApplicationMaster(AM)

    ApplicationMaster管理在YARN内运行的每个应用程序实例。ApplicationMaster负责协调来自ResourceManager的资源,并通过NodeManager监视容器的执行和资源使用(CPU、内存等的资源分配)。请注意,尽管目前的资源更加传统(CPU 核心、内存),但未来会带来基于手头任务的新资源类型(比如图形处理单元或专用处理设备)。从YARN角度讲,ApplicationMaster是用户代码,因此存在潜在的安全问题。YARN假设ApplicationMaster存在错误或者甚至是恶意的,因此将它们当作无特权的代码对待。

    总的来说,AM有以下作用

    (1)负责数据的切分

    (2)为应用程序申请资源并分配给内部的任务

    (3)任务的监控与容错

    3)NodeManager(NM)

    NodeManager管理YARN集群中的每个节点。NodeManager提供针对集群中每个节点的服务,从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1通过插槽管理Map 和Reduce任务的执行,而NodeManager管理抽象容器,这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。

     总的来说,NM有以下作用

     (1)管理单个节点上的资源

     (2)处理来自ResourceManager的命令

    (3)处理来自ApplicationMaster的命令

    4)Container

    Container是YARN中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当AM向RM申请资源时,RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。

    总的来说,Container有以下作用

    对任务运行环境进行抽象,封装CPU、内存等多维度的资源以及环境变量、启动命令等任务运行相关的信息

    要使用一个YARN集群,首先需要一个包含应用程序的客户的请求。ResourceManager协商一个容器的必要资源,启动一个ApplicationMaster来表示已提交的应用程序。通过使用一个资源请求协议,ApplicationMaster协商每个节点上供应用程序使用的资源容器。执行应用程序时,ApplicationMaster监视容器直到完成。当应用程序完成时,ApplicationMaster从 ResourceManager注销其容器,执行周期就完成了。

      通过上面的讲解,应该明确的一点是,旧的Hadoop架构受到了JobTracker的高度约束,JobTracker负责整个集群的资源管理和作业调度。新的YARN架构打破了这种模型,允许一个新ResourceManager管理跨应用程序的资源使用,ApplicationMaster负责管理作业的执行。这一更改消除了一处瓶颈,还改善了将Hadoop集群扩展到比以前大得多的配置的能力。此外,不同于传统的MapReduce,YARN允许使用MPI( Message Passing Interface) 等标准通信模式,同时执行各种不同的编程模型,包括图形处理、迭代式处理、机器学习和一般集群计算。

    Yarn工作机制

    1)Yarn运行机制

    2)工作机制详解

    (0)Mr程序提交到客户端所在的节点

    (1)Yarnrunner向Resourcemanager申请一个Application。

    (2)rm将该应用程序的资源路径返回给yarnrunner

    (3)该程序将运行所需资源提交到HDFS上

    (4)程序资源提交完毕后,申请运行mrAppMaster

    (5)RM将用户的请求初始化成一个task

    (6)其中一个NodeManager领取到task任务。

    (7)该NodeManager创建容器Container,并产生MRAppmaster

    (8)Container从HDFS上拷贝资源到本地

    (9)MRAppmaster向RM 申请运行maptask容器

    (10)RM将运行maptask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器。

    (11)MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动maptask,maptask对数据分区排序。

    (12)MRAppmaster向RM申请2个容器,运行reduce task。

    (13)reduce task向maptask获取相应分区的数据。

    (14)程序运行完毕后,MR会向RM注销自己。

    六、资源调度器

    目前,Hadoop作业调度器主要有三种:FIFO、Capacity Scheduler和Fair Scheduler。Hadoop2.7.2默认的资源调度器是Capacity Scheduler。

    具体设置详见:yarn-default.xml文件

    <property>

        <description>The class to use as the resource scheduler.</description>

        <name>yarn.resourcemanager.scheduler.class</name>

    <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>

    </property>

    1)先进先出调度器(FIFO)

      FIFO是Hadoop中默认的调度器,也是一种批处理调度器。它先按照作业的优先级高低,再按照到达时间的先后选择被执行的作业。原理图如下所示。

     比如,一个TaskTracker正好有一个空闲的slot,此时FIFO调度器的队列已经排好序,就选择排在最前面的任务job1,job1包含很多map task和reduce task。假如空闲资源是map slot,我们就选择job1中的map task。假如map task0要处理的数据正好存储在该TaskTracker 节点上,根据数据的本地性,调度器把map task0分配给该TaskTracker。FIFO 调度器整体就是这样一个过程。

    2)容量调度器(Capacity Scheduler)

    支持多个队列,每个队列可配置一定的资源量,每个队列采用FIFO调度策略,为了防止同一个用户的作业独占队列中的资源,该调度器会对同一用户提交的作业所占资源量进行限定。调度时,首先按以下策略选择一个合适队列:计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值,选择一个该比值最小的队列;然后按以下策略选择该队列中一个作业:按照作业优先级和提交时间顺序选择,同时考虑用户资源量限制和内存限制。 原理图如下所示。

     比如我们分为三个队列:queueA、queueB和queueC,每个队列的 job 按照到达时间排序。假如这里有100个slot,queueA分配20%的资源,可配置最多运行15个task,queueB 分配50%的资源,可配置最多运行25个task,queueC分配30%的资源,可配置最多运行25个task。这三个队列同时按照任务的先后顺序依次执行,比如,job11、job21和job31分别排在队列最前面,是最先运行,也是同时运行。

    3)公平调度器(Fair Scheduler)

    同计算能力调度器类似,支持多队列多用户,每个队列中的资源量可以配置,同一队列中的作业公平共享队列中所有资源。原理图如下所示

    比如有三个队列:queueA、queueB和queueC,每个队列中的 job 按照优先级分配资源,优先级越高分配的资源越多,但是每个 job 都会分配到资源以确保公平。在资源有限的情况下,每个 job 理想情况下获得的计算资源与实际获得的计算资源存在一种差距, 这个差距就叫做缺额。在同一个队列中,job的资源缺额越大,越先获得资源优先执行。作业是按照缺额的高低来先后执行的,而且可以看到上图有多个作业同时运行。

    作业提交全过程

    1)作业提交过程之YARN

    2)作业提交过程之MapReduce

    3)作业提交过程之读数据

    4)作业提交过程之写数据

    5)作业提交详解

    (1)作业提交

    client调用job.waitForCompletion方法,向整个集群提交MapReduce作业 (第1步) 。 新的作业ID(应用ID)由资源管理器分配(第2步)。作业的client核实作业的输出, 计算输入的split, 将作业的资源(包括Jar包, 配置文件, split信息)拷贝给HDFS(第3步)。最后, 通过调用资源管理器的submitApplication()来提交作业(第4步)。

    (2)作业初始化

    当资源管理器收到submitApplciation()的请求时, 就将该请求发给调度器(scheduler), 调度器分配container, 然后资源管理器在该container内启动应用管理器进程, 由节点管理器监控(第5步)。

    MapReduce作业的应用管理器是一个主类为MRAppMaster的Java应用。其通过创造一些bookkeeping对象来监控作业的进度, 得到任务的进度和完成报告(第6步)。然后其通过分布式文件系统得到由客户端计算好的输入split(第7步)。然后为每个输入split创建一个map任务, 根据mapreduce.job.reduces创建reduce任务对象。

    (3)任务分配

    如果作业很小, 应用管理器会选择在其自己的JVM中运行任务。

    如果不是小作业, 那么应用管理器向资源管理器请求container来运行所有的map和reduce任务(第8步)。这些请求是通过心跳来传输的, 包括每个map任务的数据位置, 比如存放输入split的主机名和机架(rack)。调度器利用这些信息来调度任务, 尽量将任务分配给存储数据的节点, 或者分配给和存放输入split的节点相同机架的节点。

    (4)任务运行

    当一个任务由资源管理器的调度器分配给一个container后, 应用管理器通过联系节点管理器来启动container(第9步)。任务由一个主类为YarnChild的Java应用执行。在运行任务之前首先本地化任务需要的资源, 比如作业配置, JAR文件, 以及分布式缓存的所有文件(第10步)。最后, 运行map或reduce任务(第11步)。

    YarnChild运行在一个专用的JVM中, 但是YARN不支持JVM重用。

    (5)进度和状态更新

    YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。

    (6)作业完成

    除了向应用管理器请求作业进度外, 客户端每5分钟都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和container会清理工作状态, OutputCommiter的作业清理方法也会被调用。作业的信息会被作业历史服务器存储以备之后用户核查。

    任务推测执行

    1)作业完成时间取决于最慢的任务完成时间

    一个作业由若干个Map任务和Reduce任务构成。因硬件老化、软件Bug等,某些任务可能运行非常慢。

    典型案例:系统中有99%的Map任务都完成了,只有少数几个Map老是进度很慢,完不成,怎么办?

    2)推测执行机制:

    发现拖后腿的任务,比如某个任务运行速度远慢于任务平均速度。为拖后腿任务启动一个备份任务,同时运行。谁先运行完,则采用谁的结果。

    3)执行推测任务的前提条件

    (1)每个task只能有一个备份任务;

    (2)当前job已完成的task必须不小于0.05(5%)

    (3)开启推测执行参数设置。Hadoop2.7.2 mapred-site.xml文件中默认是打开的。

    <property>

      <name>mapreduce.map.speculative</name>

      <value>true</value>

      <description>If true, then multiple instances of some map tasks

                   may be executed in parallel.</description>

    </property>

     

    <property>

      <name>mapreduce.reduce.speculative</name>

      <value>true</value>

      <description>If true, then multiple instances of some reduce tasks

                   may be executed in parallel.</description>

    </property>

    4)不能启用推测执行机制情况

       (1)任务间存在严重的负载倾斜;

       (2)特殊任务,比如任务向数据库中写数据。

    5)算法原理:

    假设某一时刻,任务T的执行进度为progress,则可通过一定的算法推测出该任务的最终完成时刻estimateEndTime。另一方面,如果此刻为该任务启动一个备份任务,则可推断出它可能的完成时刻estimateEndTime`,于是可得出以下几个公式:

    estimateEndTime=estimatedRunTime+taskStartTime

    estimatedRunTime=(currentTimestamp-taskStartTime)/progress

    estimateEndTime`= currentTimestamp+averageRunTime

    其中,

    currentTimestamp为当前时刻;

    taskStartTime为该任务的启动时刻;

    averageRunTime为已经成功运行完成的任务的平均运行时间;

    progress是任务运行的比例(0.1-1);

    这样,MRv2总是选择(estimateEndTime- estimateEndTime·)差值最大的任务,并为之启动备份任务。为了防止大量任务同时启动备份任务造成的资源浪费,MRv2为每个作业设置了同时启动的备份任务数目上限。

    推测执行机制实际上采用了经典的优化算法:以空间换时间,它同时启动多个相同任务处理相同的数据,并让这些任务竞争以缩短数据处理时间。显然,这种方法需要占用更多的计算资源。在集群资源紧缺的情况下,应合理使用该机制,争取在多用少量资源的情况下,减少作业的计算时间。

    参考链接:

    https://www.cnblogs.com/frankdeng/p/9311474.html

    https://blog.csdn.net/u014774781/article/details/50921006

     

     

     

    展开全文
  • 第一阶段(1-3月):会从浅入深,基于大量案例实战,深度剖析和讲解Spark,并且会包含完全从企业真实复杂业务需求中抽取出的案例实战。课程会涵盖Scala编程详解、Spark核心编程、Spark SQL和Spark Streaming、...

    第一阶段(1-3月):会从浅入深,基于大量案例实战,深度剖析和讲解Spark,并且会包含完全从企业真实复杂业务需求中抽取出的案例实战。课程会涵盖Scala编程详解、Spark核心编程、Spark SQLSpark StreamingSpark GraphXSparkRMachine LearningSpark内核以及源码剖析、性能调优、企业级案例实战等部分

    第二阶段(Spark超大规模大数据案例实战):使用了Spark技术生态栈中的Spark CoreSpark SQLSpark StreamingSparkRMachine Learning,进行离线计算和实时计算业务模块的开发、数据的关联性分析、用户行为模式和特征的训练与应用、用户网络的社区发现、用户影响力、能量传播、标签传播、标签推理、人群划分、年龄段预测、商品交易时序跳转。

    本课内容:

    实战讲解Spark运行原理

    2 RDD解密

    RDD(弹性分布式数据集)

    分布式基于内存特别适合于迭代计算,也可以基于磁盘计算,适合各种规模的集群的计算。

    1、分布式:多态集群,整个Spark有一个提交程序的Driver端,提交给集群(多台)进行运行,不同的Node处理其中一部分内容,Node间各不影响

    2、主要基于内存:data首先会考虑在MEM中运行,data太大可将部分data数据存放于disk上,

    3、擅长迭代计算(多步骤计算)shuffle

    RDD:rdd代表要处理的数据,分布式处理,data分成若干分片Partition,存储于不同的节点中,只进行rdd的处理,

    1RDD弹性的特点:

    1、弹性之一:自动的进行内存和磁盘数据存储的切换;

    2、弹性之二:基于Lineage的高效容错(第n个节点出错,会从第n-1个节点恢复,血统容错);

    3、弹性之三:Task如果失败会自动进行特定次数的重试(默认4次);

    4、弹性之四:Stage如果失败会自动进行特定次数的重试(可以值运行计算失败的阶段);只计算失败的数据分片

    2RDD写入缓存cache的几种情况:

    1、计算步骤特别耗时会做Cache

    2、计算链条很长,失败的时候会有很大代价,血统容错恢复;

    3shuffle之后;

    4checkPointTachyonCache不可靠)data放于文件系统中,保证数据安全

    3)启动Spark后的测试:

    ./start-dfs.sh

    多次检验

    ./spark-all.sh

    启动history server

    ./start-history-server.sh

    http://master:18080

    >sc.textFile("hdfs://Master:9000/libary/wordcount/input/Data")

    数据来源于HDFS

    >val sc.textFile("library/wordcount/input/Data") 

    //hdfs上读取了数据,这些数据是一系列分片的数据分布于不同的机器上

     

    Partition size默认情况下 = hsfs上的 Block size128M

     

    sc.textFile("错误路径") 不会报错,因为trasformation的时候采用了lazy的机制。

    >val flatted=data.flatMap(_.split(" "))

    //rdd有依赖关系

    >val mapped =flatted.map(word =>(word,1))

    >mapped.toDebugString

    >val reduced = mapped.reduce(_+_)

    //分布式处理shuffle过程,统计数据

    >reduced.savaAsTextFile("http://...")

    >reduced.toDebugString 

    //显示rdd依赖关系


    Spark架构设计

    1、创建SparkContext:用户开发编写的逻辑与集群交互的接口,他会通过与Cluster Manager进行交互,以及通过Cluster Manager申请计算资源

    2Cluster Manager:资源管理器,类似于Hadoopyarnmesos

    3Worker Node:集群中具体中每台机器的存储和计算的支撑

    4Executor:在Worker Node上为某个应用程序启动的进程,其内以线程池的方式负责Spark的任务运行,并负责将数据存储在Disk或者MEM

    通常在Driver端发送的任务发送到Worker上的Executor上,让线程池进行计算,每个任务都有独立的Executor

    所以Spark执行时线程级别的。

     

    Spark运行机制:

    首先用户创建SparkContext,新创建的SparkContext会根据编程时设置的参数或系统默认的配置连接到

    ClusterManager上,ClusterManager会根据用户提交时的设置(如:占用CPUMEN等资源情况),来为用户程序分配计算资源,启动相应的Executor;而Driver根据用户程序调度的Stage的划分,即高层调度器(RDD的依赖关系),若有宽依赖,会划分成不同的Stage,每个Stage由一组完全相同的任务组成,该Stage分别作用于待处理的分区,待Stage划分完成和Task创建完成后,Driver端会向Executor发送具体的task,当Executor收到task后,会自动下载运行需要的库、包等,准备好运行环境后由线程池中的线程开始执行,所以Spark执行是线程级别的。

    Hadoop运行比Spark代价大很多,因Hadoop中的MapReduce运行的JVM虚拟机不可以复用,而Spark运行的线

    程池中的线程可以进行复用。

    执行Task的过程中,Executor会将执行的Task汇报给DriverDriver收到Task的运行状态情况后,会根据

    具体状况进行更新等。Task根据不同的Stage的划分,会被划分为两种类型:

    1shuffleMapTask,在最后一个Stage前的其他Stage都进行shuffleMapTask,此时是对数据进行shuffle

    shuffle的结果保存在Executor所在节点的本地文件系统中;

    2)第二种TaskResultTask,负责生成结果数据;

    Driver会不断发送TaskExecutor进行执行,所以Task都正确执行或者超过执行次数的限制,或者没有执

    行时会停止,多正确执行会进入下一个stage,若没有正确执行成功,高层调度器DAGSchedular会进行一定次

    数的重试,若还是执行不成功就意味着整个作业的失败。


    DT大数据梦工厂

    新浪微博:www.weibo.com/ilovepains/

    微信公众号:DT_Spark

    博客:http://.blog.sina.com.cn/ilovepains

    TEL:18610086859

    Email:18610086859@vip.126.com




    展开全文
  • 我国的企业运行之中一直在寻找一种对员工行之有效的约束与激励机制。从20世纪的50年代中期到80年代末期,我国的国有企业为了寻求制度上的创新,率先扩大企业自主经营权,为求达到通过自主权的下放使得员工拥有最大...

     我国的企业在运行之中一直在寻找一种对员工行之有效的约束与激励机制。从20世纪的50年代中期到80年代末期,我国的国有企业为了寻求制度上的创新,率先扩大企业自主经营权,为求达到通过自主权的下放使得员工拥有最大限度的效用,但是这种方式并没未取得预期的效果。从1995年开始我国的一些企业开始试点现代公司,在这个过程中,有一些根本的矛盾并未得到解决,比如落实了下放的“自主权”,却架空了所有者。直到1999年 “公司治理结构”的建立才提出了 “股票期权激励制度”的概念,现代化企业的发展才由此开始了。

     

    在较为成熟的美国市场,股票期权的用途早已得到了广泛的认识并得到了广泛的运用。而在我国直到2006年,随着《上市公司股权激励管理办法》的实施,才逐步有43家上市公司公布了公司筹划的股权激励计划草案,但仅有22家获得中国证监会备案无异议,其中就有南玻A。

    南玻集团有限公司最早一直是实行传统薪酬制度即工资和奖金为主要薪酬,这种薪酬制度显然只能达到赋予短期报酬,对长期的激励并没有太大的效果。虽然公司也看到传统薪酬的弊端,并且在实行过程中一直完善以及寻求较好的薪酬结构,比如通过绩效的管理,对于行业的横向比较,以及公司效益的直接评价改善工资和奖金的比例,但是始终未能达到比较好的长期激励效果。直到2006年,南玻集团有限公司初尝股权激励制度给企业带来的新鲜活力。

    从2006年《上市公司股权激励管理办法》的实施开始,我国各上市公司接二连三的各自推出适用于自己公司的股权激励制度之后给我国股市带来了不小的震动。从2007年开始A股走出了少见的牛市上涨行情,同时由于《上市公司股权激励管理办法》出台不久,很多上市公司都找到了管理办法的漏洞,出现了与股权激励相关的上市公司高管离职套现现象。例如三花股份,根据这个公司2007年披露的年报显示,该公司原副总裁、董事任金土、以及董事王剑敏于2006年3月份辞职,并于2007年分别减持了所持有的三花股份88.83万股和50.10万股,按照三花股份120日均价21.77元/股计算,两位原高管套现金额分别达到1933.83万元和1090.67万元。此外,包括科华生物、山河智能、新和成等在内的多家中小板公司均出现了高管主动辞职套现现象。这不由得使整个市场开始思考关于股权激励在我国资本市场的施行需要得到更完善的法律规范和政策支持。于是,中国证监会对上市公司股权激励一度暂缓审批。

    近一年后,南玻A(000012)成为股权激励证监会再度开闸后第一家通过审批的公司。2008年4月11日,南玻A披露了首份股权激励方案。5月6日,证监会发布了股权激励有关事项备忘录1号和2号,对于股权激励进行更加严格的审批,对照新规,南玻A对之前的股权激励方案进行修改并于5月28日推出了新的股权激励方案,而证监会也正是在这一天对该公司的股权激励进行“放行”。并且,与前一次激励对象集中在公司中、高管人员以及核心技术人员相比,此次的激励对象扩大了范围。

    随着我国经济迅速融入世界经济,人才成为了企业经营的重中之重,能否留住或者吸引人才进入企业,成为了当代企业经营亟需解决的问题。人才争夺战愈演愈烈,考验的是我国传统的薪资制度以及企业经营分配制度,通过对国外企业的先进经验,结合我国上市公司的实际情况,从制度本身以及外部环境出发,建立适合我国企业的,行之有效的激励与约束机制,并制定企业经营者股票期权激励制度的实施细则,从而为我国上市公司提供制度支撑,同时完善相关法律法规,加强资本市场与经理人市场的管理,为我国上市公司实施经营者股票期权激励提供良好的环境,使得股权激励制度在我国更好的发挥其功效。

    更多内容请访问泰山管理学院官网:http://www.tms.org.cn/。

    转载于:https://my.oschina.net/u/3178724/blog/883004

    展开全文
  • Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。 Kubernetes一个核心...
  • [管理]案例剖析企业ERP失利原因

    千次阅读 2008-10-12 00:14:00
     谈起ERP(企业资源计划),它在国内“流行”已不是一两年时间了,并成为企业信息化过程中的“必修课”。但谈到“上ERP”,国内许多企业则“又爱又怕”。爱的是ERP代表着一种先进的工具,能为企业的发展提供动力;而...

        【IT168 信息化

        谈起ERP(企业资源计划),它在国内“流行”已不是一两年时间了,并成为企业信息化过程中的“必修课”。但谈到“上ERP”,国内许多企业则“又爱又怕”。爱的是ERP代表着一种先进的工具,能为企业的发展提供动力;而与此同时,企业不得不面临国内ERP失败率居高不下的困境。

        有调查显示,国内企业ERP用户中,实施成功率不足50%.曾有人提出了ERP的“三分论”,即“三分之一能用、三分之一失败、三分之一修改后能用”。“许多企业更是为此陷入资金深渊,无力发展。”专家如是说。

        同样,ERP的实施要想获得令人满意的结果也并非易事。而导致企业实施ERP系统失败,或在实践中效果不理想的原因也是多种多样,有企业自身实力方面的、有协调组织方面的、也有人员方面的。

        失利原因之一:企业管理基础过于薄弱

        案例1:王经理是一家家具制造企业的老总。几年来,王经理的公司虽然规模上没有迅速增长,但因为产品做工在当地已经树立了一定口碑,加上管理机制又相对比较灵活,业务开展得却是红红火火,甚至一些国内知名的家居品牌慕名而来,希望与王经理的公司洽谈合作。

        这样的机会,王经理自然不会轻易错过。可是自己公司的规模上和人家相去甚远,管理水平也不在一个档次,这对于日后业务的进一步拓展,肯定有弊无利的。于是,本身对IT就有所偏好的王经理有了上ERP的念头。

        可是经过几家服务供应商的咨询,大家都认为王经理的公司业务过于灵活,采购、销售、人力资源等环节根本没有固定的流程模式,这样,ERP的功能设计就很难成型。

        急于改变公司面貌的王经理,这时候根本听不进这些意见,坚决地拍了板,ERP项目不久后便启动了。

        看着一项项功能得以实现、公司的管理规范有序,王经理喜上眉梢。可好景不长,ERP上线不到一个月,各种各样的问题便接踵而至:原先在采购原料时,都是按月、或者按年结账,这在ERP里是不被允许的;原先当一些老客户急于上货时,可以先完成交易,再签署合同,这些在ERP中也都无法实现……

        一个又一个的问题不断出现,最终,原以为能为公司业务添光添彩的ERP系统,落得了被弃置不用的下场。

        管理基础薄弱对于急于实施ERP的企业无疑是致命的。ERP实施是一个复杂的系统工程。ERP的管理理论基础是供应链管理,而供应链牵涉到企业的采购、供应、财务、人力资源、生产、设备、销售等,因此ERP的实施非常复杂。

        据不完全统计表明,在所有的ERP系统应用中,存在三种情况:按期按预算成功实施实现系统集成的只占10%-20%;没有实现系统集成或实现部分集成的只有30%-40%;而最终失败的占50%.在实施成功的10%-20%中,大多数为管理基础比较好的外资或合资企业。

        ERP作为规模最大,与管理捆绑最紧密的信息系统之一,实施的风险同样也是最大的,其失败之多已让不少企业视之为“望而却步”,甚至拒之门外。

        其实在企业信息化建设过程中不难发现这样的规律:系统规模越大、与管理联系越密切、集成度越高的系统,风险也越大,失败概率越高,其中最明显的例子就是ERP。

        因此,没有良好的管理基础而去实施ERP,就如同在一个地基没有建好的地方盖摩天大厦,时刻都会有倒塌的危险。

        失利原因之二:拿ERP当软件,不重视规划、培训

        案例2:A公司是一家经营汽车零配件加工的制造型企业。经过几年的发展,公司业务规模取得了一定的增长,甚至已经开始准备向海外市场发展。

        面对发展需求,公司领导决定在信息化上下下功夫,争取使公司的生产、经营再上一个台阶,同时,也便于和国外的零配件营销企业建立起更为紧密的联系。

        经过一段时间对业内同行的信息化状况分析,公司发现国内该行业的领头企业大多应用了ERP,于是,领导拍板--A公司ERP项目立即启动。

        半年紧张的选型、实施,A公司价值上百万元的ERP系统也顺利上线了。很快,又是半年过去了,A公司的ERP却丝毫没有起到预期的作用。

        询问之下,员工们一一反应:“对ERP操作不熟悉”;“我们的ERP流程和一些业务有冲突,不够合理”;“用ERP审核原料入库,比原先用表格记录还要麻烦”……

        “为什么花大笔金钱换来的ERP会成为摆设?一套小小的软件在我们公司怎么就应用不起来呢?”A公司领导百思不得其解。

        很多企业认为,实施ERP就是花钱买来一套软件系统,认为可以像办公软件一样购买回来就可以使用,把ERP首先看成是软件问题然后才是管理问题。

        这种认识上的错误导致许多企业将ERP项目预算的90%都花在购买功能齐全的ERP软件系统上,而忽视了对人员的培训和系统流程的调整。这种本末倒置的作法必然导致项目收效甚微。

        实际上,ERP不仅是现代企业向国际化发展的管理模式,它更是一种以现代资源管理为基础的企业管理集成化的思想及新管理理论。

        首先,ERP更加注重与供应商、分销商与制造商的联系;涵盖了从接单、采购、生产、库存、发货、货款回收、会计处理等范畴。其次,ERP更加强调企业业务流程,通过工作流程优化实现企业的人员、财务、制造与分销间集成,支持企业的流程重组。

        此外,ERP更多地强调财务,具有较完善的企业财务管理体系;这使得价值管理概念得以实施,资金流与物流、信息流更加有机地结合。而且ERP较多地考虑人作为资源的因素在生产经营规划中的作用,也考虑了人的培训成本等。

        成功实施ERP,就需要企业站在优化资源及流程管理的立场上,对业务及生产流程进行一次评价检查、优化改造,即重视人员的配合和训练、树立“资源及流程管理”的理念,同时改造企业内部的所有流程,塑造“资源及流程”的新型导向。

        如果没有投放足够的资源于人员培训,没有改造固有的业务流程,再好的ERP软件也是枉然。

        失利原因之三:对ERP期望值过高

        案例3:欧主管是B公司的信息部门领导。面对B公司管理、经营逐渐走入了发展的瓶颈,E主管向总经理主动请缨,希望公司能够尽快上马ERP。

        为了能够使公司的管理经营水平尽快得到提升,欧主管找来了各种资料、案例,对ERP的功能、作用,逐一向总经理进行了汇报。最终得到了领导的认同。

        一年后,B公司的ERP系统应用已经进入了正轨,公司各项业务开展正处于稳定运行期,公司业务管理也一一步入了规范化、流程化。

        可令欧主管意想不到的,公司领导却对ERP的效果产生了质疑。领导认为,为上ERP花了大笔金钱,可一年多过去了,却没见它创造出了什么效益,与之前的预想相差太远。

        本以为为公司立下了大功的欧主管,满腹的委屈。

        企业无法正确评价ERP系统的真实价值是一种比较普遍的现象。要么把它看成是包治百病的灵丹妙药,认为企业的所有问题都可以通过实施ERP来解决;要么认为ERP是鸡肋,没有多大价值。这两种认识都是对ERP投资回报的极端化表现。

        ERP主要目的是为了帮助企业充分通过流程重组及资源整合,从而帮助企业谋求利润的最大化。通过实施ERP,企业可以实现从“手工操作”向“信息集成化”的转变,从而使企业的资源尽可能得到利用。

        ERP力图解决的是企业在竞争中最直接和最关键的问题--资源配置、业务效率,以及由此引起的成本问题。但它不可能解决企业的所有问题,例如企业战略的选择、企业文化的塑造、企业制度的确立、企业融资等问题。

        因此,要想通过ERP直接、快速地实现巨大的利益回报,肯定是一种不切实际的想法。而抱有这种想法来实施ERP,最终的失利也是在所难免的。

        失利原因之四:对ERP功能不了解

        案例4:C公司实施ERP已经有一年多的时间了。通过ERP,C公司在财务管理、库存管理方面效率也有了明显改善。可公司领导钱经理却总是觉得:别人家用ERP,生产效率、业务管理都有了很大改进,可C公司为什么只在财务、库存两方面有效果呢?

        偶然的机会,钱经理在出席一次大会时,听到了来自同行业企业ERP的实施经验。配送系统管理、客户需求分析管理、各式各样的报表生成……一个个实用的功能听得他一头雾水,“为什么我们公司的ERP没有这些功能呢?”

        回到公司后,钱经理立刻打电话询问了ERP实施方,结果却是:这些功能应用在C公司的ERP系统中一个也不少。只是由于大家对ERP的应用还并不习惯,许多操作还停留在原始的手动或半手动状态,结果许多的功能应用都变成了摆设。

        在记者接触过的一些使用了ERP的人中,有不少认为:ERP的功能仅仅在于库存、物流、财务、会计等层面上。甚至有些人认为,ERP的使用只是把财务或物流管理的工作转嫁到其它部门罢了。事实上,这种对ERP的看法是非常片面的。

        举个例子,企业在未使用ERP前,为了满足管理需求,经常会用到一些信息统计表格,诸如投入产出率统计表、产量明细表、销量明细表、生产进度表等。这些报表往往会由人工对日常业务发生的内外部交易进行统计得出。而在使用ERP后,很多报表都可以从系统直接生成;但部门负责人如果对系统不了解,要么会以为什么报表都可以从ERP系统里面直接生;要么就是根本不知道哪些报表本来可以从ERP系统中直接生成。

        这样的使用结果与企业实施ERP的目标无疑是背道而驰的。

        失利原因之五:过度依赖实施方

        案例5:D公司是一家食品加工制造企业,已经有多年的发展历史。然而随着越来越多的新兴食品企业的崛起,使D公司所承受的市场压力也是与日俱增。

        为了能够保证公司在新的市场竞争中站稳脚跟,提高企业运作效率,公司决定引进先进的生产设备,并通过信息化手段,从管理上改变现有的面貌。

        通过多方面了解、介绍,D公司最终决定实施ERP系统,并选择了一家在当地企业中小有名气的服务供应商实施系统。

        由于D公司内上上下下没有人对ERP有所了解,所以D公司只能依赖于这家服务供应商。从需求分析,功能选择,方案设计,到部署实施,几乎完全是由服务供应商一方完成,D公司则只是提供相应的配合。

        经过几个月的实施,D公司的ERP系统上线了。上线后的ERP系统结构纷繁复杂、功能多种多样。然而在应用一段时间之后,D公司却发现:这套ERP系统虽然功能全面,但许多功能对D公司而言根本没有用武之地,而且很多模块也很难和公司的业务相容,结果整套ERP系统近70%的功能设计都成为了多余。

        过度依赖实施方是中小企业应用ERP失利,最为常见的一种状况。许多中小企业想用ERP,但又不懂ERP,于是过度吸收和接受软件提供商、实施方的咨询建议,流程策划时不结合自身的实际情况,削足适履,到头来不但未能提高工作效率,还为此赔进不少的人力物力。

        我们都清楚,对于企业信息化,服务是维护发展的重要因素。特别是像ERP这样牵扯到企业整体业务管理的大型系统,卖方、实施方有针对性的服务更是尤为重要。

        国外企业实施ERP,实施方的服务链应具三个层次:一、环境服务链,即要事先进行风险鉴定和评估,但这一点在国内还没有得到普及;二、实施服务链,即企业在实施ERP时,要有第三方的咨询,从而获得客观声音;三、运行服务链,即实施方应对企业进行对应性的ERP培训,并进行完整流程的复合性验证。

        同时,企业也应对自身业务特点、对ERP的各种需求有着清醒的认识,起码要能够向实施方清楚地表明自身的业务体系如何规划、需求在哪里。否则,完全由实施方来进行规划决策,最终受苦的只能是自己。

        失利原因之六:一把手工程推行不利

        案例6:小张刚刚被E公司提升为公司的信息化部门的主管,全面掌控公司的信息化建设。技术出身的他刚一上任就迫不及待地希望能够为公司的发展做出突出贡献。

        经过几个月对公司上上下下业务模式、管理结构,以及操作方式的仔细研究后,小张立即向公司领导层提交了一份“E公司实施ERP可行性分析报告”。随后,他又多方联系,调研、选型,为E公司选择了一套非常适合的ERP系统,和一家有着丰富专业经验的服务商。

        另一方面,尽管公司的领导对于ERP并不熟悉,但看到小张对公司发展如此的热心,加上已经找到了适合的产品及实施方,便也未加干预。

        在对ERP功能需求进行规划时,小张也曾多次找到了销售、生产、财务等部门的领导与之沟通,这其中,不免出现很多的分歧。为了保证工程进度,小张并没有理会各个部门提出的意见,继续埋头于项目当中。而看到整个项目实施进展快速,E公司的领导也就没有再过问此事。

        三个月的鏖战,小张和他部门的同事都累瘦了一圈,ERP终于在最短的时间内成功上线了。而另小张意想不到的事情,也从ERP应用进入正轨的第一天起陆续发生了。

        从采购开始,生产、财务、服务等部门的同事纷纷对这套ERP系统提出质疑,一位销售部的同事更是直言:“这个系统的业务流程设计与我们以往的工作习惯大相径庭,我们根本无法适应。”

        面对此起彼伏的反对之声,小张显得无所适从。最终,E公司在最短时间内完成的ERP系统,也在最短的时间内成为了“摆设”。

        ERP的“一把手”问题已经是老生常谈了。但在现实中,仍有许多企业认为实施ERP是ERP推进工作小组的事情,无可厚非地应由ERP推进小组负责实施。而正确答案应是与公司资源及业务流程有关的全体管理人员都要对ERP负责任,因为ERP系统的最终目标是通过流程重组和资源合理配置,达到企业信息速化、资源配置合理化。

        而正由于实施ERP会牵扯到几乎所有的部门、人员,必然会弱化责任意识,所以必须要有决策者或决策机构对ERP的成功负主要责任。由于ERP的最高层次是企业流程最优化和资源合理,而制订这一管理战略的企业领导者就责无旁贷地对ERP的成功负有不可推卸的责任。

        所以ERP的成功实施首先需要企业的领导者给予高度关注并亲力亲为,缺乏他们的支持和参与,ERP项目在开始就注定要失败。其次,需要全体员工达成共识,齐心协力。

        失利原因之七:只认价格,忽视可用性

        案例7:林总是一家服装企业的老总,尽管他的企业进入市场时间不久,但林总精明活的商业头脑和灵活的处事原则,却使企业在短短几年内打下了一片江山。

        眼看着自己的企业大踏步地发展,许许多多业务管理中的问题也越来越凸现出来。在与公司的各位领导以及信息部门进行了几次协商之后,林总决定为自己的企业上马ERP。

        决定之后,ERP的选型工作立即开始。两个月中,林总与不下十家的实施方进行了细致的沟通,可每一次在谈到产品和服务的价格问题时,却一一都被林总否决了下来。

        “毕竟我们企业规模不算大,能够留给信息化的资金很有限。所以ERP的费用无论如何也要压下来。”最终,久经商场的林总取得了价格上“成功”,与一家实施方签订了协议。实施方将在一套其他企业ERP方案设计的基础上,为林总的企业稍加修改,便开始了实施,而整体价格只有原先的三分之二。

        然而好景不长,刚刚上线没有几天,这套“廉价ERP”与公司原有管理体制的就出现了“排斥现象”,一些重要的业务流程在这套ERP上很难得以实现,而一些原先希望能够通过ERP得以改善的功能也并不存在。

        本以为选择了一款物美价廉的好系统,结果却是事与愿违。

        “只认价格,不顾质量”,这种想法同样会经常出现在中小企业中。由于自身资源的限制,中小企业在选择信息化方式和产品时对于“性价比”的热衷,往往会导致信息化的效果不够理想,甚至没有作用。

        企业实施ERP,就要选择到该企业的最优信息化解决方案。对于中小企业而言,ERP的成败将关系到企业下一步的未来。但现阶段很多企业ERP的选型却步入了一个怪圈:选型负责人从一开始就是“只向钱看”,甚至不讲自己企业自身的特点、管理流程、生产流程及特点,就让各个厂商来先报一个基本价格,使ERP的选型过程成了热热闹闹“价格竞拍”。

        可以说,企业如果忽视了ERP方案提供商的实施、售后服务,以及与自身企业的适合度,只看重它的价格因素,那结果将是不可想象的。

        失利原因之八:认为ERP是一步到位,忽视二次开发

        案例8:F公司是一家中型制造业企业,由于在同行业中率先部署实施了ERP系统,因而使企业获得了快速地发展。几年间,已经将业务涉及面扩展到了全国。

        F公司能够得以快速发展,实现业务规范化、系统化管理,ERP功不可没。可是随着企业业务面的扩大、部门间职能的调整,原有的ERP逐渐体现出了疲态,许多功能模块都已经很难适应企业现有业务的运营。

        公司信息部门主管向领导层提交了请示报告,希望能够在现有的ERP系统基础上进行二次开发,修改或去掉原有的一些不适应功能,添加新的模块。

        可当时公司领导考虑:原有ERP系统数十万元的投入对F公司来说,并不是一个小数目,要将其中近一半的功能删除或修改,还需要慎重考虑;更何况要想进行二次开发,加入新的功能模块,又将是一笔不小的开销。于是,便回绝了这一想法。

        两次请示均没有得到批准,信息主管也就没有再提起此事。然而,一年之后,当F公司的业务管理多点都出现了问题时,公司领导才发现,原有的ERP系统已经近乎成为了“废品”。

        国内很多企业在实施ERP时,都抱着“一锤子买卖”的心态,“只要当时合适,其他一切都无所谓”,至于ERP以后的完善和针对本企业特点的二次开发就与自己没有关系了。

        应用ERP,企业首先应该认识到:ERP系统是为企业的发展战略和目标服务的。而要想使ERP能够实现这一功能目标,它的系统功能则需要对企业的发展、业务的转变有所跟进。

        这就好比我们所使用的计算机,当硬盘、内存的容量无法满足应用需求时,就需要对系统进行相应的扩容。只是对企业的ERP系统进行二次开发时,更应注重企业的实际功能需求,同时,具体的开发、实施相对也更加复杂。

        此外,仔细了解实施方是否具备专业的研发能力、丰富的实战经验、持续的服务和强大二次开发能力等综合情况,也是非常重要的。否则,最后吃亏的将是企业自身。

    展开全文
  • 中国知名企业ERP失败案例分析

    千次阅读 2009-07-25 09:35:00
    中国已经有很多企业开始实施ERP了,有成功的案例,但是更多是失败的案例,这些企业实施ERP失败的教训在哪里呢?还是ERP真的不适合中国的国情吗?尽管ERP的高失败率已经成为不争的事实,诸如成功概率为0说、80亿投资...
  • Mapreduce核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序,并发运行在一个hadoop集群上; 1.1 为什么要MAPREDUCE(1)海量数据在单机上处理因为硬件资源限制,无法胜任(2)而...
  • ESB架构之企业实施案例

    千次阅读 2015-02-01 00:04:00
    ESB的存在主要是为了整合企业内部的应用, 使企业内的应用能融为一体, 而不是成为一个个信息孤岛。可以说ESB是企业内所有服务的中心点, 其它系 统间的交互都需要通过ESB来完成。为此, 它需拥有如下质量属性:...
  • 二、智慧南京运行管理中心建设 智慧南京运行管理中心共分为两期建设。 (一)智慧南京运行管理中心一期建设情况 智慧南京运行管理中心一期工程始建于2012年并于当年投入使用,是智慧城市各个运行环节与各类运行...
  • 经过近一个多月的努力,我使用自己的业余时间在V2的基础上对Byteart Retail案例重新打造,使得V3以一种全新的面貌出现在关注.NET企业级架构和领域驱动设计的读者朋友面前。与前两个版本相比,V3无论在界面上,还是在...
  • 企业内部控制体系建设路径及启示 ——基于某公司内控建设案例研究 来源:新浪博客作者:马军生2013-01-25 XY股份有限公司为符合上市公司内控法规要求,提高企业经营管理水平和风险防范能力,促进企业可...
  • 1960 年代第一批学术论文出现以来,计算机视觉已经走了很远,现代系统已经出现,且它们可以集成到移动应用中。 今天,由于其广泛应用和巨大潜力,计算机视觉成为最热的人工智能和机器学习子领域之一。其目标是:...
  • 最终形成以财务为核心,将业务执行层、操作层的信息化系统与企业经营层的采购、生产、销售、物流和财务系统有机结合,形成一个多层次、多方位、财务业务一体化的信息化管理体系,解决企业运行过程中管理流程可调、...
  • 案例上手 Spring 全家桶

    千次阅读 2019-07-21 23:30:02
    案例上手 Spring 全家桶》课程亮点spring boot面试题 Spring 技术零基础轻松入门 spring boot 68 讲更全面地覆盖 Spring 全家桶核心模块 100+ 段代码示例,理解 Spring 全家桶要领 3 大项目实战,掌握 Spring ...
  • 这是作者网络安全自学教程系列,主要是关于安全工具和...前文分享了WannaCry蠕虫的传播机制,带领大家详细阅读源代码。这篇文章将分享APT攻击检测溯源与常见APT组织的攻击案例,并介绍防御措施。希望文章对您有所帮助~
  • JDBC+MySQL入门增删改查案例

    千次阅读 2020-08-14 12:28:37
    目录前言案例分析核心思路拆解案例涉及知识点第一关 创建数据库和项目创建数据库创建项目第二关 JDBC插入和查询预备工作单个插入批量插入查询数据JDBC修改和删除修改数据删除数据总结与拓展总结拓展 前言 hello我是...
  • ERP沙盘实操案例

    千次阅读 2010-11-08 14:54:00
    <br />ERP沙盘实操案例  ××有限责任公司,按照ERP沙盘模拟企业划分岗位角色,实施企业调研→解决方案设计→数据准备→企业建账→期初业务处理→日常业务处理→报表编制→深入业务应用的企业信息化流程...
  • SSM实现秒杀系统案例

    千次阅读 2016-11-01 17:16:16
    对于抢购系统来说,首先要有可抢购的活动,而且这些活动具有促销性质,这种大型活动的负载可能是平时的几十倍,所以通过增加硬件、优化瓶颈代码等手段是很难达到目标的,所以抢购系统得专门设计。...
  • 本文以现有的真实区块链应用案例为切入点,通过分析技术架构和实际数据验证,尝试性的测试了其风险,并对未来区块链应用所面临的不同风险进行了研究和探讨,最后针对不同的风险类型,尝试性的提出了相关的建议。...
  • 基础信息的不完善,但是同时,不完善的点知道的不全面,也没有完善的处理方法、处理机制来应对 从业务系统具体功能来看,现有业务系统很难有效解决如下问题: 1.目前公司所有的系统都只有简单的报表...
  • 目录大咖心声新书图片内容简介作者简介目录前言/序言新书案例案例一:研盘古人工智能框架案例二:基于Pytorch的自然语言处理模型(BERT)的应用案例案例三:人力资源主管正确评估新招聘员工薪水的案例案例四: 基于...
  • 现实中的容器技术运用案例

    万次阅读 2016-08-30 20:14:44
    很多企业都已经在实际项目中或深或浅的使用着容器技术,享受到新技术带来的简洁和高效。作为国内最早研究和使用Docker技术的企业,ThoughtWorks在2013年底就在实际项目中将Docker用于测试环境的资源复用,并在之后的...
  • Hadoop:MapReduce概述和编程案例

    万次阅读 2020-05-28 08:42:12
    MapReduce概述、核心思想、编程规范,Hadoop序列化介绍,WordCount、FlowCount统计案例
  • 本文在相关论文研究虚拟企业构建及运行机制的基础上.提出了“敏捷制造运行螺旋”和“敏捷制造运行环”的概念。并详细分析了其中各步骤的主要问题所在。一、敏捷制造运行环基于国内外文献以及有关企业案例的研究,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,201
精华内容 14,080
关键字:

企业自运行机制案例