精华内容
下载资源
问答
  • Symphony SDK:强大的移动异构计算神器!
    2022-01-06 15:52:02

    为了在今天的智能设备上提供顺滑和丰富的用户体验,对设备性能的要求也与日俱增,使得续航与散热成为应用设计需要考虑的重要方面。为实现这些目标,应用必须以最优方式使用底层硬件资源,给开发者增加了沉重的负担。

    Symphony SDK 就是为解决这一问题而生,它提供了一组API,可以更加严格地控制如何利用Qualcomm® Snapdragon™处理器中各个运算单元,比如多核CPU、GPU和DSP,以便实施任务调度、异构卸载、续航及散热管理。

    Symphony SDK为开发人员提供:

    • 一个针对 Snapdragon多核定制CPU、Adreno GPU和Hexagon DSP的简单编程框架。
    • 一个编程框架,可将Snapdragon 异构架构的任务调度、内存管理、内核同步等苦不堪言的工作抽象化,同时轻松对代码进行并行处理。
    • 直接利用Snapdragon处理器内部续航/散热管理软件的能力,为您的应用实现出色的性能和/或效率。
    • 更强的控制能力,通过核心亲和性(Core Affinity)控制代码在Snapdragon处理器中的执行位置,这也是任务调度的一个重要方面。

    Symphony SDK 可以在任何计算密集型用例中使用,比如计算机视觉、图像/数据处理、低级算法开发、视频游戏等。


    更多Qualcomm开发内容请详见:Qualcomm开发者社区

    更多相关内容
  • Qualcomm Symphony System Manager SDK使用举例  Symphony System Manager是Qualcomm公司的产品,提供整体的CPU、GPU和DSP功率与性能管理,让程序能够在低功耗、低散热的严格要求下,以稳定的帧数率运行。此SDK为...

    Qualcomm Symphony System Manager SDK使用举例

            Symphony System Manager是Qualcomm的产品,提供整体的CPU、GPU和DSP功率与性能管理,让程序能够在低功耗、低散热的严格要求下,以稳定的帧数率运行。此SDK为应用程序提供可调用的接口和相应的动态库文件。

            下载和安装

            https://developer.qualcomm.com/download/software

            把下载后的文件libsymphony-1.1.0.deb放在任意目录下,解压:

            #dpkg -x libsymphony-1.1.0.deb symphony-1.1.0

            目录symphony-1.1.0即是我们需要的文件,其主要内容如下:

          

           本文之讲解android环境上的使用,我们只关注arm-linux-androideabi目录。

            使用举例

            1.搭建工程环境

                   # mkdir project_symphony

               # cd project_symphony

               # mkdir jni

               # cd jni

               # cp -r <symphony_dir>/opt/Qualcomm/Symphony/1.1.0/arm-linux-androideabi/include ./

               # cp -r <symphony_dir>/opt/Qualcomm/Symphony/1.1.0/arm-linux-androideabi/lib ./

               # vim Application.mk

               内容如下:

    APP_STL := gnustl_static
    APP_ABI := armeabi-v7a
    NDK_TOOLCHAIN_VERSION := 4.9
    #set the APP_PLATFORM to match your platform version.
    APP_PLATFORM := android-18
    
             # vim Android.mk

             内容如下:

    LOCAL_PATH := $(call my-dir)
    include $(CLEAR_VARS)
    SYMPHONY_VERSION := 1.1.0
    SYMPHONY_LIB_TYPE := release-cpu
    include $(LOCAL_PATH)/lib/SYMPHONY.mk
    

           工程目录下的目录文件包括: Android.mk、Application.mk、include和lib;

           2.验证环境

            执行ndk交叉编译(请安装crystax-ndk并配置环境变量)

            # ndk-build

            如下,则环境配置成功:


            3.举例代码

                 # vim pfor_helloworld.cc

                 源码如下:

    <span style="font-size:18px;">#include <vector>
    #include <symphony/symphony.h>
    
    int main()
    {
        // initialize the input vector
        std::vector<size_t> vin(1024, 0);
    
        // in-place update of the input vector
        // equivalent to the following code
        // for (size_t i = 0; i < vin.size(); ++i) {
        //   vin[i] = 2 * i;
        // }
        symphony::pfor_each(size_t(0), vin.size(), [&vin](size_t i) {
                            vin[i] = 2 * i;
        });
    
        return 0;
    }
    </span>
            # vim Android.mk

           添加后的代码如下:

    LOCAL_PATH := $(call my-dir)
    include $(CLEAR_VARS)
    SYMPHONY_VERSION := 1.1.0
    SYMPHONY_LIB_TYPE := release-cpu
    include $(LOCAL_PATH)/lib/SYMPHONY.mk
    
    ################################################
    include $(CLEAR_VARS)
    
    LOCAL_ARM_MODE         := arm
    ifeq ($(TARGET_ARCH_ABI), armeabi-v7a)
      LOCAL_ARM_NEON       := true
    endif
    
    LOCAL_MODULE           := pfor_helloworld
    LOCAL_CPP_FEATURES     := exceptions
    LOCAL_SHARED_LIBRARIES := libsymphony
    LOCAL_SRC_FILES        := pfor_helloworld.cc
    
    include $(BUILD_EXECUTABLE)
    

            4. 编译代码

             # ndk-build

             输出如下,则编译成功:



    展开全文
  • java多人聊天室源码Symphony 机器人 ...>symphony-bdk-bot-sdk-java</ artifactId > < version >1.0.8</ version > </ dependency > 从源安装 要从源代码构建和安装 Symphony Bot SDK,您
  • 该机器人是使用Symphony Python SDK构建的。 (质量检查:1.3.4) 。 工作流程 将漫游器添加到房间中,并使用@mention / all将所有流成员(房间/ MIM / IM)添加到@mention 命令列表: @Mention Bot /帮助 @...
  • Platform Symphony简介 简单来说,Platform Symphony 是一个提供数据分发、任务调度以及资源管理的企业级分布式计算框架,并且支持异构化的 IT 环境。Symphony 由两层架构组成,一层是负责资源管理的 EGO,另一层是...

    Platform Symphony简介

    简单来说,Platform Symphony 是一个提供数据分发、任务调度以及资源管理的企业级分布式计算框架,并且支持异构化的 IT 环境。Symphony 由两层架构组成,一层是负责资源管理的 EGO,另一层是任务管理的 SOAM。在 Symphony 的集群中,用户需要根据 Symphony 提供的 API 实现 Client 和 Service 程序。Symphony 涉及的基础模块如下图。

    图 1. Platform Symphony 基础模块
    在这里插入图片描述
    如图所示,Client 程序用于提交任务到 Symphony 集群,Symphony 会在 EGO 层为该类应用申请计算资源,接着在对应的机器上启动用户的 Service。Service 接收任务数据并进行计算,最终会通过 Symphony 将任务结果返回 Client 程序。

    PMC 是 Symphony 提供的一个专业 WEB 操作界面,其可以定制 Symphony 集群的配置,以及管理任务等。

    CLI 是 Symphony 提供了一些命令行工具的集合,对于习惯使用命令操作的用户来说,更加方便和高效。Knowledge Center 是 Symphony 产品文档的 WEB 接口,用户可以在其中找到 Symphony 各个功能的介绍和使用方法。

    分布式大数据框架的分类

    在详细介绍 Platform Symphony 与大数据生态圈的关系之前,让我们先了解一下整个大数据生态系统。我个人理解是:目前这个行业可以简单的分为三大块,分别是数据源、数据处理以及数据分析。数据分析是直接将大数据转换为商业价值的领域,在数据分析的领域会提出各种业务需求。数据处理领域则是负责实现数据分析提出的需求,这一领域也就是我们经常说的基础设施架构层(Infrastructure)。数据源指的就是数据产生的地方。在这三块之间也有一些衔接的软件领域,不过往往也都归在了数据处理领域(基础架构层),例如衔接数据源与数据处理层的数据导入工具(如 sqoop 等),以及衔接数据分析和数据处理的应用接口(如:SQL 接口的 Hive,以及流的接口等)。在大数据的这三大领域中有很多开源以及非开源的产品,熟知的开源的 Hadoop、Spark 等,都属于数据处理领域,也就是基础架构这块。IBM Platform Symphony 无疑也属于这一块。综上所述,如果宏观的抽象出整个大数据生态涉及的相关领域,大致如下图所示:

    图 2. 大数据行业相关的领域
    在这里插入图片描述
    基于对大数据相关领域的宏观描述,下来我们就再来谈下基础架构这一块。目前大多开源相关的大数据框架基本可以归属到基础设施架构这块。为了更好的理解各个框架之间的关系,我们又将基础设施架构这块分为四层,分别是数据存储层、集群资源管理层、计算引擎层、以及应用接口层。除了一些提供易用性、可维护性以及健壮性的框架之外(一般也可以统称为管理类),其他大部分都可以归在这四类。例如 HDFS 属于数据存储层,Mesos 和 Yarn 则属于集群资源管理层,Hadoop MapReduce、Storm、Spark 等则归属于计算引擎层,Hive、Pig 则为数据查询提供接口。Ambari 则是一个提升易用性和可维护性的工具,Zookeeper 提供了健壮性(HA)。这些系统之间具体的关系,请参见下面的简图:

    图 3. 分布式大数据基础架构关系图
    在这里插入图片描述
    那么 Platform Symphony 又具体处在哪个层,又可以替代哪些开源的框架呢?带着问题,我们来理解下图。

    图 4. Platform Symphony 与大数据生态圈的关系
    在这里插入图片描述
    从图 3 中我们可以看出,在大数据应用场景中,Platform Symphony 既处在资源管理层,也涵盖了计算引擎层。因此很多原有的大数据应用,都可以很平滑的迁移到 Symphony 的集群中运行,例如 Hive、Pig 等。并且用户以前在 Hadoop MapReduce 上开发的应用也可以很平滑的运行在 Symphony 之上。

    类比开源的框架,Platform Symphony 中的 EGO 相似与 Yarn 和 Mesos 处于集群资源管理层SOAM 处于计算引擎层,负责任务管理和调度。Symphony MapReduce 只是 Symphony 内置的一种应用(Hadoop MapReduce 也是内置于 Yarn 的一种应用)。用户其实可以根据 Symphony 的 API 实现各种不同的 Symphony 应用。目前 Symphony 已经与开源 Yarn 和 Spark 集成,也就是说用户之前在 Yarn 和 Spark 上面的应用,可以直接通过 Symphony 管理和调度集群资源。

    Platform Symphony 的模块和基础知识

    在文章的开始我们就已经谈到了 Platform Symphony 的基础架构,这里我们就来看看 Platform Symphony 两层架构中都有哪些详细的模块。

    EGO 简介

    用一句说,EGO(全称为 Enterprise Grid Orchestrator)就是一个管理集群资源的模块。首先它会将物理资源,进行虚拟抽象并管理,然后在多个应用之间进行协调和分配。这也是其设计的初衷。类似于开源的 Yarn,可是要知道 EGO 这个设计及实现都是十几年前就已经有了,而 Yarn 则是这几年才发展起来的(企业级的分布式系统,通常都会积累沉淀很久才会趋于稳定)。EGO 会将集群节点分为管理节点和计算节点,并定义一套资源分配的策略。我们也可以说 EGO 就是由这三部分组成,如下图所示。

    图 5. EGO 的组成
    在这里插入图片描述
    管理节点,一般会运行一些特殊化的服务,例如管理 Symphony 任务的服务(Session Manager 和 WEB 的服务进程,后面会介绍)。
    计算节点则是承载用户计算任务的节点。图中的 Master candidate 属于一个 Standby 的 Master 节点。对于 Symphony 的 Master 节点来说,这就是它的 HA。Master 和 Master Candidate 都属于管理节点,它们会共享一个目录(NFS)来记录运行时的一些媒体信息。当 Master 宕机或长时间不响应的时候,Master Candidate 会接管集群成为新的 Master,并从 NFS 的媒体信息中恢复正在执行的任务信息。CPU slot 是一个用来衡量计算资源的基本单位。一个 Slot 可以用来启动一个用户的 Service 实例(在计算节点),也可以用来启动一个 Session Manager 这样的管理服务实例(在管理节点)。其实管理节点和计算节点只是 EGO 内置的两种资源分组,我们也叫 Resource Group。用户也可以自定义其特有的 Resource Group 来隔离不同的应用。Resource Group 之间也可以有优先级,也可以定制化共享资源。这也是 EGO 提供给上层的功能。

    这里也介绍下 EGO 中几个重要的服务进程,VEMKD、EGOSC、PEM。VEMKD 相当于 Yarn 中的 RM,它启动在 Master 节点上面,用于监测集群的资源的状态以及管理集群资源。上层的应用最终都会向 VEMKD 来申请资源(Slot)。EGOSC 全名就是 EGO service controller,它会向 VEMKD 申请资源启动一些系统管理的服务。PEM 全名是 Process Manager,用于启动进程实例,和监测进程实例的状态。

    SOAM 的组成

    SOAM 是一个面向服务的中间件,其由 Session Director(SD)、Session Manager(SSM)、Service Instance Manager (SIM) 和 Service Instance(SI)组成。具体的关系如下图。

    图 6. SOAM 的架构设计
    在这里插入图片描述
    简单介绍下各个模块之间的关系,Client 就是用户根据 Symphony SDK 开发的客户端程序,用户从 Client 提交计算任务。Client 会先和 SD 建立连接,SD 会找到该类型应用的 SSM。如果该类型 SSM 不存在,SD 会向 EGO 层申请管理节点的资源,并启动 SSM(这里的 SD 和 SSM 都是管理节点的系统服务实例,不占用计算节点的资源)。SSM 会根据用户提交的任务向 EGO 层申请一定的计算资源。拿到计算资源后 SOAM 层会在计算节点启动 SIM 和 SI(一般一个 Slot 启动一个 SI 实例)。然后 SSM 会发送任务和数据到 SIM,进而到 SI 完成计算。SIM 会管理用户的 Service 进程,如果用户的 Service 遇到一些错误,SIM 会根据用户配置产生对应的行为,我们称之为 Error Handing。

    Symphony 的应用以及其运行时涉及的概念

    在 Symphony 中运行的应用,主要包含三部分,分别是 Client、Service 程序以及该应用的定义文件 App Profile。其中 Client、Service 都需要用户根据 Symphony SDK 开发。运行时涉及的概念见下图。

    图 7. Symphony App 运行时的相关概念
    在这里插入图片描述
    从图中,可以看见 Client 会创建 Session(跟 Job 是一个意思),Session 会包含很多个 Task。Client 每提交一次作业都会创建一个 Session,并生成多个 Task。Session 的 ID 是全局唯一的,而 Task 的 ID 只是在该 Session 中唯一。每一个应用都会有一个 App Profile,它会定义跟该应用相关的属性,以及 Symphony 对该应用在某个场景的行为。对运行时的数据流向,我们可以参见下图。

    图 8. Symphony 应用的数据流向
    在这里插入图片描述

    Symphony 的 Package 管理

    无论是开源的 Hadoop 还是 Platform Symphony,用户都需要开发自己的程序。因此,会涉及到如何管理用户应用的部署包。对于 Hadoop 来说,需要上传 Package(Jar 包)到 HDFS。同样的 Symphony 需要用户将 Package 发送给 RS 服务。不过 Symphony 提供了很友好的命令行工具和 WEB 操作入口。用户上传完成后,Symphony 会在运行该用户应用时,自动下载 Package 到计算节点。如下图所示。

    图 9. Symphony 的 Package 的管理
    在这里插入图片描述

    Platform Symphony 应用间的资源管理和和共享

    Platform Symphony 通过 Consumer 来管理应用之间的资源。我们可以简单理解 Consumer 就相当于每个应用的银行账户,申请到的资源就会存放在 Consumer,然后与其关联的应用就可以使用该 Consumer 获得的资源。下图是 Consumer 和 App 以及 Resource Group 的关系。

    图 10. Consumer、App、RG 的关系
    在这里插入图片描述
    从图中我们可以看到 App 会以 Consumer 为账户在 Resource Group 中取得资源,一个 Consumer 可以配置从一个或多个 RG 中申请资源。为了最大化的利用资源,Symphony 允许 Consumer 之间的资源共享。在 Symphony 的集群中,会有 Resource Distribution Plan 的定义,也就是全局资源分配的策略。它会包含三种资源共享的模型、分别是 Siloed 模型、Directed Shared 模型以及 Brokered share 模型(也可以称为 utility 模型)如下图。

    图 11. Symphony 资源共享模型
    在这里插入图片描述
    简单来说,用户可以对一个(或多个)应用配置独占一部分资源,将剩下的分配给其他应用。在独占的资源中,又可以配置借入和借出规则。在应用与应用之间(也就是 Consumer 之间)也可以配置一个比例,这样应用之间可以按比例获取集群中国的资源。以上只是很简单的概括描述,资源如何分配是 Symphony 的一个核心的内容,感兴趣的读者可以在 IBM Knowledge Center 中获得更多内容。

    Platform Symphony 与 Yarn 的对比

    前面介绍了 Symphony 中 EGO 和 SOAM 里的一些模块和概念,可能有的人觉得和大数据并没有什么关系。其实是很多人已经先入为主了,提到大数据可能想到的更多的是 Hadoop MapReduce 和 Spark 之类,而这些都只是计算框架而已。Symphony 的用户完全可以根据自己的业务计算逻辑,实现自己的 Symphony 应用。拿 MapReduce 而言,它也只是 Symphony 的一个应用。这也间接说明了 Symphony 的另一个优势,多租户的概念。Symphony 中可以同时运行多种类型的应用。用过 Yarn 的读者,可能觉得 Symphony 有些类似于 Yarn。这里就将 Symphony 的各个模块与 YARN 做个简单的对照。下图是 Yarn 的架构设计,我们对比下 Yarn 与 Symphony 的相似之处。

    图 12. Yarn 的架构设计
    在这里插入图片描述
    Client 都是用来提交任务的,在 Yarn 中 RM 会申请资源启动 App Master。这一步类似于 SOAM 中 SD 申请资源启动(或找到)SSM。
    Yarn 中 App Master 会向 RM 申请资源启动 container 运行 MR 任务,并收集任务状态。这里类似于 SSM 向 EGO 申请资源启动 SIM 和 SI,并发送任务和收集任务结果的过程。SSM 和 App Master 一样,是管理和调度任务的模块,在一个集群中可以存在多个(多种不同类型的应用)。很多人都很赞叹 Yarn 架构的前沿性,尤其与 Hadoop 一代比较,Yarn 将资源管理层单独抽象出来,这样使得 Hadoop 的架构更加清晰。而 Symphony 十几年前就已经这样设计,可见 Symphony 已经领先开源很多年。

    当然 Symphony 与 Yarn 也有一些差异,例如默认情况下(Yarn 可以配置),Yarn 的 App Master 是启动在 Yarn 的 Container 中,与真正的计算实例的 Container 并无特殊对待。也就是说启动 App Master 的机器,有随机性。而 Symphony 一般只能启动 SSM 在 Symphony 的管理节点。一般情况下,管理节点的性能会远高于计算节点的,而 SSM 等管理进程对性能的消耗一般也会比较大,所以在管理节点启动 SSM 这样的重量级进程是有技术背景的。再例如 Yarn 没有 Resource Group 的概念,如果需要将某些特殊的任务调度到某一群特定机器时,Yarn 显得有些沉重,因为 Yarn 目前只能通过标签调度(Tag Policy)去做。Symphony 可能只需要设定几个 Resource Group,并设计不同优先级即可(Symphony 很早前也支持了 Tag 的调度策略)。与所有的开源框架相比,Symphony 支持更多的 OS 平台以及硬件平台。例如 Hadoop 目前还没支持 Windows,而 Symphony 很早就支持了。更多的差异化,可以在 IBM 的 Knowledge Center 找到。

    Platform Symphony 的 SDK 接口介绍

    在介绍 SDK 层之前,先简单介绍一下 Symphony 本身的实现语言。Symphony 的主要模块 EGO 和 SOAM 是由 C/C++语言实现的,这也是 Symphony 追求性能极致的一种体现。因此 Symphony 也不会受限于 JVM(如 GC 的影响)。不过对于用户来说,更关心的是 SDK 层支持的语言。

    目前,Symphony 支持 2 种接口:

    - 原生的 SDK

    支持 Java、C++、C# 以及 Python。因此,用户可以根据自己擅长的语言,开发对应的 Symphony 应用程序。

    — Symphony MapReduce 的接口

    Symphony 提供和开源 Hadoop 一致的 API,并确保兼容性,这里就再不多做介绍。

    下面主要介绍下 Symphony 原生 SDK 的接口。

    Client 端的 API

    在 Client 端涉及的最重要的几个 API 有:
    1connect(),用于在 Client 端连接 Symphony 集群中该类应用的 SSM。
    2createSession(),用于为该次任务创建 Session(Job)。
    3sendTaskInput(),用于发送任务需要的输入。
    4fetchTaskOutput(),用于获取计算任务的结果。

    Client 工作流程图如下:

    图 13. Client 端 API 的流程图
    在这里插入图片描述

    Service 端 API

    在 Service 端主要的 API 会有:
    1onCreateService(),提供用户 Service 端初始化的时机。
    2onSessionEnter(),用户 Service 端 Common Data 等数据的读取。
    3onInvoke(),用户计算逻辑的实现接口,也就是说在这里并行执行用户的计算逻辑。
    4onSessionLeave(),用于 Common Data 数据的清理。
    5onDestoryService(),用户可以在这里清理掉初始化时候的数据。

    图 14. Service 端 API 的流程图
    在这里插入图片描述
    更多 API 的细节,可以参见 Knowledge Center 中的介绍。

    结束语

    Platform Symphony 凭借其技术沉淀,已经在国外银行业应用了很多年,其历史远远早于 Hadoop。随着大数据在国内的兴起,Symphony 也一直致力于解决国内大数据场景的问题和瓶颈,发挥其优势。目前 Platform Symphony 已经支持了多维度资源调度,并且支持通过 Ambari 安装部署 Symphony 集群。最新的发行版中也支持了 Spark、Yarn 和 Docker 的集成。用户可以很平滑将开源框架中的应用运行在 Symphony 上。如果想了解更多 Symphony 的内容,可以查看 IBM 在线的 Knowledge Center。

    展开全文
  • Client就是用户根据Symphony SDK开发的客户端程序,用户从Client提交计算任务。Client会先和SD建立连接,SD会找到该类型应用的SSM。SSM用于管理一类应用的任务。如果该类型SSM不存在,SD会向EGO层申请管理节点的资源...

    随着开源社区不断的壮大,很多以前鲜为人知的技术慢慢地走进了大众IT人员的视野。对一个数据中心而言,最火的两个技术领域便是云计算与大数据。其中每个领域都有一些代表的项目,如云计算领域的OpenStack、CloudStack等,那么大数据领域又有哪些知名的项目呢?当面对这样的问题时,很多人可能会快速地回答:Hadoop、Hive、Hbase以及后来的Yarn(Hadoop二代)、Mesos、Spark、Storm、Flink等。这些答案无疑都是正确的,然而对于整个大数据生态圈而言,会有很多不同的场景需要不同的框架和平台应用去处理,例如流计算任务、批处理任务或者存储的构建、数据的导入等等。我们可以看到一些企业已经开始将一部分业务或者数据迁移到大数据的平台,尤其是一些大型的互联网企业。那么,一个企业该如何选择一个适合的平台甚至一个框架?这个问题不太容易回答。本文致力于介绍整个大数据的生态圈以及IBM Platform Symphony产品,希望读者能从中得到这个问题的线索或答案。

    分布式大数据框架的分类

    在详细介绍Platform Symphony与大数据生态圈的关系之前,让我们先了解一下整个大数据生态圈的组成。我个人的理解是,目前这个行业可以简单的分为三大层次:分别是数据源、数据处理以及数据分析。数据分析是直接将大数据转换为商业价值的领域,在数据分析的领域会提出各种业务需求;数据处理领域则是负责实现数据分析提出的需求,这一领域也就是我们经常说的基础设施架构层(Infrastructure);数据源指的就是数据产生的地方。在这三块之间也有一些衔接的软件领域,不过往往也都归在了数据处理领域(基础架构层),例如衔接数据源与数据处理层的数据导入工具(如Sqoop等),以及衔接数据分析和数据处理的应用接口(如:SQL接口的Hive,以及流接口的Spark Streaming、Storm等)。在大数据的这三大领域中有很多开源以及非开源的产品,熟知的开源的Hadoop、Spark、Mesos等,都属于数据处理领域,也就是基础架构这一层次。IBM Platform Symphony也属于这个部分。 综上所述,如果宏观的抽象出整个大数据生态涉及的相关领域,大致如图1所示:

    图片描述

    图1. 大数据行业相关的领域

    基于对大数据相关领域的宏观描述,下来我们就再谈下基础架构这一块。目前大多开源相关的大数据框架基本都可以归属到基础设施架构这个层次。为了更好的理解各个框架之间的关系,我们又将基础设施架构这块分为四层,分别是数据存储层、集群资源管理层、计算引擎层、以及应用接口层。除了一些提供易用性、可维护性以及健壮性的框架之外(一般也可以统称为管理类),其他大部分都可以归在这四类。例如HDFS属于数据存储层,Mesos和Yarn则属于集群资源管理层,Hadoop MapReduce、Storm、Spark等则归属于计算引擎层,Hive、Pig则为数据查询提供接口。Ambari则是一个提升易用性和可维护性的工具,Zookeeper提供了健壮性(HA)。这些系统之间具体的关系,可以参见下面的简图:

    图片描述

    图2. 分布式大数据基础架构关系图

    目前开源的大数据框架所支持的操作系统大多数都只支持了Linux,不过这一问题相信未来会有所解决,毕竟大多大数据框架的实现语言都是与操作系统无关的Java(Scala)。

    大数据案例举例

    通过以上的介绍,我们了解了其中一部分大数据相关的开源架构,但可能没法短期内将其对应到实际的案例中。因此,这里用一个很简单的查询业务架构作为例子,来说明这些框架之间的具体关系。由于传统的业务架构会将大部分数据保存在数据库中,所以这里假设有一个MySQL数据库保存了海量的客户终端信息(例如电话号码、话单以及动态GPS纪录),如果要将查询业务迁移到大数据平台,首先要做的便是数据迁移(Data Movement)。

    对于数据迁移的场景我们可以使用Sqoop工具进行数据导入。简单来说,Sqoop是一个用MapReduce框架实现的应用,并且Sqoop只有Map的实现。Sqoop的Map任务会并行的从数据库中读取表的信息,并保存到Hadoop的HDFS中。Sqoop本身也可以实现反向的导入,也就是从HDFS到数据库,不过这里我们用不到。了解了Sqoop的大致实现,我们可以知道Sqoop的运行离不开Hadoop的支持。另外需要注意的是,在这个例子中的数据是结构化的DB数据。如果是非结构化或半结构化数据,Sqoop可能就无能为力了。对于非结构化的数据,有兴趣的读者可以研究下Flume等的使用。

    当数据迁移完成之后,我们可以通过Hive提供SQL的支持。上层应用便可以方便的通过SQL语句查询HDFS中的用户信息。从这里我们也要了解到Hive本身并不是数据库,它只是提供SQL支持的一种接口实现。Hive会将查询语句转换为MapReduce任务来执行。对于响应时间要求高的客户,可能Hive并不能满足需求。有兴趣的读者也可以在类似的案例中使用Hbase。Hbase是一个分布式的列式数据库,其底层存储也是使用HDFS。不过与Hive不同,其是一款真正的数据库。在大多的场景中,Hbase的响应延迟会比Hive小很多。篇幅有限,这里就不过多介绍Hbase。

    到这里我们知道整个方案至少需要有Sqoop、Hive、HDFS以及MapReduce的实现框架。那么Hadoop Yarn除了支持MapReduce的Workload之外,还有什么作用?为了回答这个问题,我们需要引入另一个重要的概念“多租户”。在Hadoop一代中只有对MapReduce任务的支持,而今随着数据中心的发展,往往是多种计算框架并存的。在我们这个例子中,数据迁移一旦完成,批处理的查询任务又不是很频繁的话,就会造成集群资源的浪费。那么为了最大化的提高集群资源利用率,就必须允许多种计算框架之间的资源共享。而Yarn作为一个集群资源的管理者,就可以很好协调多种计算框架之间的资源分配和管理。当然,这也需要计算框架本身的支持。MapReduce是Yarn内置的一种计算框架,已经由Hadoop社区实现。但对于其他的计算框架,则需要其他社区根据Yarn的API来实现对应的App Master。为了方便用户部署和管理集群,我们可以使用Ambari。该案例的整体架构图如图3。

    图片描述

    图3. 示例方案的架构图

    如果引申该案例的话,我们可以在上图的其他Framework中应用更多的计算框架。例如当该案例的集群又需要处理流数据的话,那么我们可以在Other中使用Spark以及Storm等。目前Yarn已经支持在其上运行Spark和Storm等计算框架。对于部分应用也可以使用Apache Slider来部署到Yarn之上。篇幅有限,这里就不过多的介绍这些框架了。

    Platform Symphony简介

    简单来说,Platform Symphony是一个提供数据分发、任务调度以及资源管理的企业级分布式计算框架,并且支持异构化的IT环境。Platform Symphony由两层架构组成,一层是负责资源管理的EGO(全称Enterprise Grid Orchestrator),另一层是任务管理的SOAM(全称Service-Oriented Architecture Management)。在Symphony的集群中,用户需要根据Symphony提供的API实现Client和Service程序。Symphony涉及的基础模块如图4。

    图片描述

    图4. Platform Symphony基础模块

    如图4所示,Client程序用于提交任务到Symphony集群,Symphony会在EGO层为该类应用申请计算资源,接着在对应的机器上启动用户的Service。Service接收任务数据并进行计算,最终会通过Symphony将任务结果返回Client程序。PMC是Symphony提供的一个专业WEB操作界面,其可以定制Symphony集群的配置,以及管理任务等。CLI是Symphony提供的命令行工具的集合,对于习惯使用命令操作的用户来说,更加方便和高效。Knowledge Center是Symphony产品文档的WEB接口,用户可以在其中找到Symphony各个功能的介绍和使用方法。

    那么Platform Symphony在大数据中的基础架构层扮演怎样的角色,又可以替代哪些开源的框架呢?带着问题,我们来理解图5。

    图片描述

    图5. Platform Symphony与大数据生态圈的关系

    从图5中我们可以看出,在大数据应用场景中,Platform Symphony既处在资源管理层,也涵盖了计算引擎层。因此很多原有的大数据应用,都可以很平滑的迁移到Symphony的集群中运行,例如Hive、Pig等。并且用户以前在Hadoop MapReduce上开发的应用也可以很平滑的运行在Symphony之上。

    对比开源的框架,Platform Symphony中的EGO相似与Yarn和Mesos,都处于集群的资源管理层。SOAM则处于计算引擎层,也就是计算框架,负责任务管理和调度。Symphony MapReduce是Symphony内置的一种应用(Hadoop MapReduce也是内置于Yarn的一种应用)。用户其实可以根据Symphony的API实现各种不同的Symphony应用。目前Symphony已经与开源Yarn、Spark、Docker集成,也就是说用户之前在Yarn和Spark上面的应用,都可以直接通过Symphony管理和调度集群资源。另外,也可以将Symphony的用户实例运行在Docker容器中。同时Symphony也支持了通过Ambari部署和管理集群,从而方便用户使用Platform Symphony替代部分开源框架。如果将Symphony应用到之前我们给的示例方案中,大致架构如图6。

    图片描述

    图6. 示例案例架构图(Platform Symphony)

    与开源框架不同,Symphony最终是通过其中的EGO模块实现应用之间的资源管理和共享。值得一提的是,Symphony的实现语言是以C和C++为主,其支持的平台也涵盖了市面上大多的操作系统,例如Windows、Linux、Solaris以及AIX等。篇幅有限,这里没有过多的阐述Symphony的内部架构,后续文章中,我们再来探讨Symphony的详细功能和设计。

    Platform Symphony与Yarn的对比

    很多人提到大数据,可能只意识到了之前我们提到的开源框架,其实是先入为主了。Hadoop MapReduce和Spark之类,这些都只是不同的计算框架而已。Symphony的用户完全可以根据自己的业务计算逻辑,实现自己的Symphony应用。拿MapReduce而言,它也只是Symphony的一个应用。这也间接说明了Symphony的另一个优势,多租户的概念。也就是说,Symphony中可以同时运行多种类型的应用。用过Yarn的读者,可能觉得Symphony有些类似于Yarn。这里就将Symphony的各个模块与YARN做个简单的对比。在对比之前,我们需要先介绍一些Symphony的概念,如图7。

    图片描述

    图7. Symphony中SOAM的架构设计

    Symphony中的SOAM是一个面向服务的中间件,其由Session Director(SD)、Session Manager(SSM)、Service Instance Manager (SIM)和Service Instance(SI)组成。Client就是用户根据Symphony SDK开发的客户端程序,用户从Client提交计算任务。Client会先和SD建立连接,SD会找到该类型应用的SSM。SSM用于管理一类应用的任务。如果该类型SSM不存在,SD会向EGO层申请管理节点的资源,并启动SSM。SSM会根据用户提交的任务向EGO层申请一定的计算资源。拿到计算资源后SOAM层会在计算节点启动SIM和SI(一般一个Slot启动一个SI实例)。然后SSM会发送任务和数据到SIM,进而到SI完成计算。SIM会管理用户的Service进程,如果用户的Service遇到一些错误,SIM会根据用户配置做出对应的行为,我们称之为Error Handing。

    图8是Yarn的架构设计:

    图片描述

    图8. Yarn的架构设计

    同样Yarn的Client也是用来提交任务的,在Yarn中RM会申请资源启动App Master。这一步类似于SOAM中SD申请资源启动(或找到)SSM。Yarn中App Master会向RM申请资源启动container运行MR任务,并收集任务状态。这里类似于SSM向EGO申请资源启动SIM和SI,并发送任务和收集任务结果的过程。SSM和App Master一样,是管理和调度任务的模块,在一个集群中可以存在多个(多种不同类型的应用)。很多人都很赞叹Yarn架构的前沿性,尤其与Hadoop一代比较,Yarn将资源管理层单独抽象出来,这样使得Hadoop的架构更加清晰。而Symphony十几年前就已经这样设计了,可见Symphony设计的前瞻性。

    当然Symphony与Yarn也有一些差异,例如默认情况下(Yarn可以配置),Yarn的App Master是启动在Yarn的Container中,与真正的计算实例的Container并无特殊对待。也就是说启动App Master的机器,有随机性。而Symphony一般只能启动SSM在Symphony的管理节点。一般情况下,管理节点的硬件性能要求会高于计算节点,而SSM等管理进程对内存以及CPU计算能力的消耗一般也会比较大,所以在管理节点启动SSM这样的重量级进程是有技术背景的。再例如Yarn没有Resource Group的概念,如果需要将某些特殊的任务调度到某一群特定机器时,Yarn显得有些笨重,因为Yarn目前只能通过标签调度(Tag Policy)去做。Symphony可能只需要设定几个Resource Group,并设计不同优先级即可(Symphony很早前也支持了Tag的调度策略)。与所有的开源框架相比,Symphony支持更多的OS平台以及硬件平台。例如Hadoop目前还没支持Windows,而Symphony很早就支持了。更多的差异化,可以在IBM的Knowledge Center找到。

    结束语

    开源技术的发展确实降低了大数据计算的门槛,因而很多企业也开始了各自的大数据之路。不过一个符合企业特定使用的分布式框架往往需要经历数年甚至十年的进化,才会趋于稳定和成熟。所以并不是每个企业都适合直接去使用开源的产品,往往更多的是使用某些公司包装过的开源产品,从而减少维护和开发的成本。对于IBM Platform Symphony来说,它是一个经历十年以上磨练的分布式计算产品,凭借其技术沉淀,已经在国外银行业应用了很多年,历史远远早于Hadoop。随着大数据在国内的兴起,Symphony也一直致力于解决国内大数据场景的问题和瓶颈,发挥其优势。目前Platform Symphony已经支持了多维度资源调度,并且支持通过Ambari安装部署Symphony集群。最新的发行版中也支持了Spark、Yarn和Docker。用户可以很平滑将开源框架中的应用运行在Symphony上。

    作者:沈钊伟(shenzhaowei@foxmail.com),2011年加入IBM CSTL(西安)至今,一直从事分布式计算以及大数据相关的研发工作。
    责编:周建丁(zhoujd@csdn.net)

    展开全文
  • <div><p>This is a solution to issue number 7 (Fatal error: Call to undefined function Safaricom\Mpesa\env() in env() error.) <p>This error occurs when someone is not ...safaricom/mpesa-php-sdk</p></div>
  • Qualcomm_Snapdragon_VR_SDK 2.1.1 Qualcomm snapdragon vr sdk是Qualcomm Technologies, Inc 公司为vr开发者提供的vr应用的sdk,硬件上依赖与高通820版本以上的vr一体机使用。 目前SDK已经更新了四个版本,...
  • IBM的36万名全球员工即将彻底抛弃微软Office办公套装,转而使用自家的Lotus Symphony。该消息的来源是来自IBM高层管理人士的一封内部信件,但尚未得到IBM的正式确认。事实上,IBM早在2008年6月就已经开始着手摆脱...
  • 虽然我们基本上都是Qualcomm开发者网络软件工具的高级用户,但是到目前为止,我们一直都很喜欢使用Symphony SDK。使用这个软件,可以有效地分割代码,针对Snapdragon处理器进行优化,并通过电源管理API提高电源效率...
  • 本文介绍 Lotus Symphony 在 Lotus Notes V8 中对 Notes 可编程性做出的增强,其中包括对基于 Lotus Expeditor 的 Rich Client 编程模式的支持,对 Notes 复合应用...
  • 摘要: 在日前举行的GMIC全球VR峰会上,Qualcomm®高级产品总监Hugo Swart从移动VR入手分享了Qualcomm在VR方面的软硬整合实践,一方面,以Snapdragon™ 820解决VR对处理能力的高需求,另一方面,推出VR SDK帮助...
  • Lotus Symphony 是可免费使用的具备丰富功能的文档编辑工具, 可以选择集成在Notes中或者独立运行。在 Lotus Notes 中可以从 Open 菜单打开该编辑器,也可以在应用程序中以编程方式打开编辑器。...
  • 下载 2019.06.13更新 2.16 GB共1,848 个文件,487 个文件夹。 文件夹 PATH 列表 卷序列号为 0FEA-0BC6 E:. │ 001各种结构文件列表生成.bat │ 目录列表_树2019.06.13更新.txt ...├─20190612后收集游戏 ...
  • 《Cloud Native》云原生技术汇总

    千次阅读 2018-03-23 14:32:23
    An awesome &amp;amp;amp; curated list of best applications and tools for Cloud Native. This Awesome Repository is highly inspired from cncf’s landscape &amp;amp;amp; Awesome. ...
  • 有来自AMD、Arm、Broadcom、Imagination、Intel、Nvidia、Qualcomm和VeriSilicon的Vulkan驱动程序,以及适用于Windows、Linux、macOS/iOS和Android的Vulkan SDK。最著名的游戏引擎现在也n支持Vulka Redis Redis是一...
  • 该框架允许汽车生态系统通过利用神经处理引擎和Symphony SDK在Snapdragon 820A的异构核心上高效运行感知和机器学习,构建基于多传感器的信息ADAS解决方案以及信息娱乐功能。 这些只是高通公司如何为联网汽车带来...
  • Maven那些非常有用的 Plugin

    千次阅读 2019-03-01 15:29:04
    主要提供了 rename 包名,将依赖包放进一个 jar 中,简直是一个万能的插件,使用,根据实际经验,这个插件在提供防止和其他包有冲突的 sdk 的时候特别有用. filters: 只选择 jar 包中需要的包名或者 exclude 不需要的包...
  • 增强整体VR体验 VR图层:生成菜单、文字和其他覆盖图层,在虚拟世界中实现正确渲染,减少失真可能造成的视觉不适感 先进的应用调试和电源管理:集成Snapdragon Profiler和Qualcomm® Symphony System Manager SDK,...
  • Qualcomm Technologies 提供了各种软硬件工具,帮助用户在移动设备上构建逼真的、可媲美游戏机质量的游戏和图形体验。现在,全球有超过10亿台搭载骁龙芯片...我们提供的 Adreno™SDK 工具,为图形和计算应用程序开发...
  • DeviceDetector Code Status ...The Universal Device Detection library that parses User Agents and Browser Client Hints to detect devices (desktop, tablet, mobile, tv, cars, console, etc.), clients...
  • SML 并行使用 Qualcomm® Snapdragon™ Symphony System Manager SDK 。 SML 是否支持CPU、GPU及DSP? 目前,SML仅支持CPU。 除了Andr​​oid,还支持哪些平台? SML还支持ARM Linux和 x86 架构的Linux、Windows和...
  • 一个PHP5.4的组件包 Hoa Project - 一个PHP组件集合 微框架( Micro Frameworks ) 微型框架和路由 Silex - 基于Symphony2组件的微型框架 Silex Skeleton - 用于Silex的项目框架 Silex Web Profiler - 用于Silex的Web...
  • InfoWorld 公布 2020 年最佳开源软件

    千次阅读 多人点赞 2021-01-11 10:49:22
    AMD、Arm、Broadcom、Imagination、Intel、NVIDIA、Qualcomm 和 VeriSilicon 都提供了 Vulkan 驱动程序,以及适用于 Windows、Linux、macOS/iOS 和 Android 的 Vulkan SDK。现在,最优秀的游戏引擎也支持 Vulkan。 ...
  • 因为laravel框架本身要求就是少去关注工具类的实现,多关注业务本身,所以所有的sdk或者扩展包都在接入时尽量提供便利,其中$this->app->bind()也体现了一个依赖注入控制反转的思想,使得定义了匿名类的,可以在...
  • 常用php类库、资源

    千次阅读 2020-06-11 11:37:27
    Micro Frameworks ) 微型框架和路由 Lumen - 基于Laravel的微型框架 Silex - 基于Symphony2组件的微型框架 Silex Skeleton - 用于Silex的项目框架 Silex Web Profiler - 用于Silex的Web调试工具条 Slim - 另一个简单...
  • 分享给大家一些不错的软件05

    千次阅读 2021-01-10 22:17:08
    并且能根据热点来创建动作) Spherical.Panorama.SP.SC.Exe.HTML.Converter.v4.01 1CD(将全景转换为exe文件的工具) AVS产品: AVS/EXPRESS v6.3 1CD(三维可视化系统) Ardence产品: Ardence.RTX.v7.1.SDK 1CD(提高...

空空如也

空空如也

1 2 3 4 5 ... 11
收藏数 215
精华内容 86
关键字:

symphony sdk