本发明涉及传媒领域，具体说涉及一种针对离线视频的分布式加密方法。
背景技术：
：在计算机数据处理应用中，视频加密是一种较常见的数据处理应用。由于视频数据的数据量较大，通常视频加密操作需要消耗大量的计算资源。随着分布式系统技术的不断发展，愈来愈多的
技术领域：
利用分布式数据处理技术来降低单台处理系统的数据处理压力。分布式数据处理技术也被应用到视频加密领域。在现有技术中，通常使用原生并行计算框架(映射-归约MapReduce)对视频进行分布式加密。利用MapReduce进行视频加密，在MapReduce任务内部，为了防止归约(Reduce)任务的失败，映射(Map)通常会把结果存储在磁盘上。通常一些查询在翻译到MapReduce任务的时候，往往会产生多个阶段(stage)，而这些串联的stage则又依赖于底层文件系统(如分布式文件系统HDFS)来存储每一个stage的输出结果。冗余的磁盘读写开销和多次资源申请过程，使得基于MapReduce的算法实现存在严重的性能问题。同时，Reduce任务需要等待所有Map任务都完成后才可以开始，也造成了较大程度的时间开销。因此，为了提高分布式加密系统的处理性能，需要一种更优的针对视频的分布式加密方法。技术实现要素：本发明提供了一种针对离线视频的分布式加密方法，所述方法包括：将离线视频数据分割成视频分片数据并保存；根据所述视频分片数据构建弹性分布式数据集，所述弹性分布式数据集中的每个元素为一个所述视频分片数据；将所述弹性分布式数据集中的各个元素分发给各个节点工作站；所述节点工作站对所述视频分片数据进行加密处理并输出加密结果。在一实施例中，将视频分割成视频分片数据并保存，其中，将所述视频分片数据保存在分布式文件系统中，在保存的过程中所述视频分片数据不做进一步分割。在一实施例中，将视频分割成视频分片数据并保存，其中，在本地客户端将所述视频上传到存储服务器的过程中完成对所述视频的分割，本地客户端将所述视频上传到存储服务器的过程包括：对视频进行分割操作获取视频分片；重新封装视频分片以获取视频分片数据；将所述视频分片数据保存至存储服务器。在一实施例中，根据所述视频分片数据构建弹性分布式数据集，其中，构建所述弹性分布式数据集后将所述弹性分布式数据集转化为键值对的形式。在一实施例中，将所述弹性分布式数据集中的各个元素分发给各个节点工作站，其中，利用命名管道进行与所述节点工作站的数据传输。在一实施例中，在数据传输之前，创建一对命名管道分别为输入管道和输出管道，其中：所述输入管道用来传递程序侧到加密侧的数据；所述输出管道用来传递加密后的数据到程序侧。在一实施例中，在进行数据传输的过程中采用数据长度校验，其中：在写入内容到所述命名管道之前，首先将要写入内容的内容长度先写入所述命名管道，然后写入要写入的内容；读取内容时先读取出所述命名管道中内容的长度，然后依照内容的长度读取内容。在一实施例中，所述视频分片数据以及所述加密结果的封装格式为“包头+内容”，其中：所述包头包含视频分片的标识符，用于描述所述视频分片的基本信息；所述内容包含视频分片的流媒体内容。在一实施例中，所述节点工作站对所述视频分片数据进行加密处理，密钥包含业务密钥以及加密密钥，其中：在加密过程中，先利用所述加密密钥对所述内容进行加密，再利用所述业务密钥对所述加密密钥的控制字进行加密；在解密过程中，先利用与所述业务密钥对应的解密密钥解密所述加密密钥的控制字，再利用所述加密密钥的控制字解密所述内容。在一实施例中，所述视频分片数据与所述加密密钥一一对应，不同的所述视频分片数据采用不同的加密密钥。根据本发明的方法，可以快速的对离线视频进行分布式加密；相较于现有技术，本发明的方法过程简单，操作实现难度低，具有良好的加密效果。本发明的其它特征或优点将在随后的说明书中阐述。并且，本发明的部分特征或优点将通过说明书而变得显而易见，或者通过实施本发明而被了解。本发明的目的和部分优点可通过在说明书、权利要求书以及附图中所特别指出的步骤来实现或获得。附图说明附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例共同用于解释本发明，并不构成对本发明的限制。在附图中：图1是根据本发明一实施例的方法流程图；图2和图3分别是根据本发明不同实施例的系统结构简图；图4是根据本发明一实施例的数据传输流程图；图5是根据本发明一实施例的密钥分发系统结构简图。具体实施方式以下将结合附图及实施例来详细说明本发明的实施方式，借此本发明的实施人员可以充分理解本发明如何应用技术手段来解决技术问题，并达成技术效果的实现过程并依据上述实现过程具体实施本发明。需要说明的是，只要不构成冲突，本发明中的各个实施例以及各实施例中的各个特征可以相互结合，所形成的技术方案均在本发明的保护范围之内。由于MapReduce的算法实现存在严重的性能问题，本发明提出了一种新的分布式加密方法。接下来基于附图描述根据本发明具体实施例的方法的执行过程，附图的流程图中示出的步骤可以在包含诸如一组计算机可执行指令的计算机系统中执行。虽然在流程图中示出了各步骤的逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。如图1所示，本发明的方法的主要步骤包括：将离线视频数据分割成视频分片数据(S110)；根据视频分片数据构建弹性分布式数据集(S120)，弹性分布式数据集中的每个元素为一个视频分片数据；将弹性分布式数据集中的各个元素分发给各个节点工作站(S130)；节点工作站对视频分片数据进行加密处理并输出加密结果(S140)。当用户需要播放视频时，可以按照视频分片在完整视频中的时间先后顺序一边解密一边播放；也可以将所有的视频分片数据解密后统合成完整的视频数据再播放。进一步的，为了便于用户播放视频，在根据本发明一实施例中，在步骤S140之后，对加密后的视频分片数据进行统一整理。将加密后的视频分片数据保存到存储服务器以便之后视频下载到客户端播放或者将加密后的视频单元传输给分发网络进行内容的分发。在本发明一实施例中，采用分布式文件系统保存加密后的视频分片数据。另外，在根据本发明另一实施例中，也可以不保存加密后的视频分片数据。而是在视频分片数据被加密后直接发送到客户端播放或者传输给分发网络进行内容的分发。在上述视频加密过程中，提高系统处理能力的最优解决办法之一是减少在整个加密集群中的存储和读取的环节。为了减少存储和读取的环节，在本发明一实施例中，主要基于通用并行框架(Spark)构造任务分发系统，利用Spark基于内存的协同算法，最优化各个代理节点的协同工作效率。以下的本发明的具体实施例也是基于Spark框架构造。在这里需要指出的是，本发明的具体实现方式并不限于Spark框架。本领域的技术人员可以采用其他方式实现本发明的任务分发步骤。如图2所示，在本发明一实施例中，基于Spark的分布式加密系统设计中，主要包括以下四个部分：视频分片模块210、分片分发模块220、加密模块以及视频分片整理模块240。在这里，为便于描绘，仅描绘分别构造在工作节点201、202、203、204上的加密模块231、232、233、234这4个加密模块。在实际运行中，加密模块的数量并不限于4个。视频分片模块210任务是将来自视频源200的整个的视频文件切割成较小的视频单元，便于后续的任务处理和传输；分片分发模块220任务是将任务单元分发到各个工作节点上的加密模块执行；加密模块部署在工作节点上，任务是对分发到节点的视频单元进行加密，输出加密后的视频分片；视频分片整理模块240的任务是接收并整理加密后的视频分片数据。在一实施例中，视频分片整理模块240将整理后的视频分片数据保存到存储服务器(分布式文件系统)。在另一实施例中，视频分片整理模块240直接将视频分片输出给用户或分发网络进行内容的分发。根据本发明的方法，在最初分割视频生成视频分片数据后就确定了需要分发的加密任务数目(一个视频分片数据对应一个加密任务)。使得任务的分发以及节点工作站的调配更加简单，大大提高了加密操作的执行效率。由于避免了不必要的磁盘读写开销和多次资源申请过程，降低了整个加密操作的计算需求，缩短了加密操作的执行时间。进一步的，分布式文件系统HDFS的数据块默认是64M，若一个文件大于64M，通过将大文件分解得到若干个数据块；若一个文件小于64M，则按它的实际大小组块存储。海量的小文件需要主节点存储较多的元数据信息记录块的位置。如果访问大量小文件，需要不断的从一个子节点跳到另一个子节点，严重影响性能。在现有技术中，当视频文件分片尺寸在64MB时，MapReduce分布式视频加密的性能达到最优，当视频分片尺寸过大或过小时，加密性能大大降低。如果分片太大以至于一个分片要跨越多个HDFS块，则一个Map任务必须要由多个块通过网络传输，读写开销和网络传输开销大大增加。因此，在现有技术中，为了保证处理性能，视频分片大小的上限是HDFS块的大小。根据本发明的方法，对视频分片尺寸不敏感，能够适应不同分片尺寸的加密需求。因此相较于现有技术，本发明的加密方法的应用灵活度大大增强。在视频业务形态中，最常见的主要有两种：直播(实时视频)和点播(离线视频)，两种业务形态视频的存在方式不同造成了对视频加密的需求也不相同。直播业务对视频加密的实时性是首要考虑的，而在点播类业务中较高效率的处理大数据的能力是其核心要考虑的问题。本发明的方法主要针对离线视频，对离线视频的加密作了具体优化。具体的，在将视频分割成视频分片数据后保存视频分片数据(保存至存储服务器)。在需要进行加密时读取保存的视频分片数据。通常，离线视频是由本地客户端上传到存储服务器中的，在根据本发明的一实施例中，在本地客户端将视频上传到存储服务器的过程中完成对视频的分割。具体的，将本地视频文件上传并对文件分割，而且分片是188字节整数倍。在一实施例中，本地客户端将视频上传到存储服务器的过程包括：对视频进行分割操作获取视频分片；重新封装视频分片以获取视频分片数据；将视频分片数据保存至存储服务器。进一步的，在一实施例中，将视频分片数据保存在分布式文件系统中，在保存的过程中视频分片数据不做进一步分割。这样就进一步降低了系统资源消耗。另外，在一实施例中，保存加密前的视频分片数据的存储服务器同样为保存加密后视频分片数据的存储服务器。具体的，在一实施例中，如图3所示，基于离线内容的内容保护系统主要由三部分构成，存储服务器330、分布式计算框架310(Master)和选择性加密模块(节点工作站321、322、323以及324，Worker)。存储服务器选用分布式文件系统(HDFS)。由于Spark框架是架构在分布式系统基础架构(Hadoop)基础之上，因此分布式文件系统沿用了HDFS。Spark框架与加密模块的交互实在节点处完成，加密模块被编译成可执行实例部署在子节点。Spark在调用加密实例的时候采用了Java提供的Runtime类进行本地视频加扰模块程序的调用。在本发明一实施例中，基于离线业务分布式加密的工作过程如下：(1)客户端将离线的视频文件上传至HDFS同时完成视频的分割工作，以便于构建Spark所需的弹性分布数据集(RDD)。(2)Spark通过读取HDFS中的视频分片数据，构建分布式处理所需的RDD。由于在后面的加密过程中仍然需要识别视频分片数据的关键信息，因此构建视频分片数据的RDD后需要经过一次转换，利用mapToPair方法将RDD转换成双键值(JavaPairRDD)的类型。JavaPairRDD参数类型为<LongWritable，BytesWritable>，类型为LongWritable的Key中赋值为视频分片数据的ID，类型为BytesWritable的Value中赋值为视频分片数据的内容。(3)Master会构建弹性分布式数据集的逻辑图，也就是DAG，然后将生成的DAG传递给DAGScheduler。(4)RDD中分片(partition)的个数决定任务(Task)的数量，Master通过基于共享内存的代理节点协同算法TaskScheduler，将分布式数据集中的各个元素根据节点性能和使用情况分发给各个节点Worker的进行数据处理，视频分片的加密处理在Worker中的执行器(Executor)上完成。(5)加密完成后，各Worker将加密后的元素返回到Master中。(6)Master通过与Hadoop之间的接口把加密后的数据集保存在HDFS中，完成整个离线分布式加密流程。在上述离线业务的分布式加密处理中，由于需要利用开源框架Spark，其中涉及到的系统和模块包括Hadoop的HDFS、本地客户端、加密模块，因此还需要解决本地文件系统与HDFS交互方式，HDFS与分布式集群的交互方式，Spark集群任务调度，Executor与加密模块之前的进程交互等。离线视频是由本地客户端上传到HDFS上保存的(实时视频不需要上传到HDFS上保存，这个之后描述)。离线视频的上传部分需要完成在视频文件上传至HDFS的过程中完成对完整视频的分割。上传过程的可以细分为对视频的分割操作、重新封装分片格式和视频分片保存至HDFS的操作。即：对视频进行分割操作获取视频分片；重新封装视频分片以获取视频分片数据；将所述视频分片数据保存至存储服务器(HDFS)。视频的分割需要从物理视频文件高效的完成自定义视频分片尺寸的分割操作和按照视频分片的封装要求进行封装。其中需要注意的是，由于加密视频传输格式采用TS，因此切分的视频分片数据长度为188字节的整数倍。具体视频分片的封装格式在后文详细介绍。视频分割和分片封装完成之后，将分片存入HDFS中，在此HDFS为读写操作提供了一个重要的接口FileSystem类。利用FileSystem获取指定URI的文件系统权限，同时封装Hadoop的配置，完成视频分片存储到HDFS中。视频文件的分割过程可以理解为本地视频通过程序操作，将完整的视频文件按照自定义的大小分割，然后把视频分片存储在HDFS中的过程。Spark框架架设在Hadoop平台之上，因此在与HDFS的交互中，兼容所有Hadoop框架中MapReduce与HDFS之间的交互接口。通常数据集读入后，会按照方法对数据集做进一步的切分和确定数据读入格式，数据的切分直接影响分布式Map方法的数量。由于视频分片的加密有其特殊性，视频分片本身包含有自己的特殊封装格式，不需要对视频分片进一步的切分，因此需要在视频分片读入时重新定义接口。重写后的类可以实现视频分片与Map任务的一一对应。它定义了两个方法：一个是将数据集分割方法重载成返回false值，来指定输入文件不被分片；另一个是实现了以一个视频分片作为读取格式的方法来返回一个定制的RecordReader实现。进一步的，在本发明一实施例中，考虑到视频分片数据在加密、传输和整合过程中可能会遇到的问题，定义了的视频分片数据的格式。在一实施例中，整体来看，视频分片数据的格式为“包头+内容”的模式。包头为视频分片的标识符，描述了该视频分片的基本信息，如所属的流媒体内容、包序号、时间戳、加密方式等。视频分片内容为加密后的流媒体内容，终端根据包头的信息和DRM授权，将获得的视频分片内容解密、解封装，将流媒体内容在在用户终端上呈现。分片格式如表1所示：表1由于详细定义了视频分片中包头的格式，也为整个系统中内容的分发和整合做好了准备。包头结构中的各字段描述如表2所示：表2Spark框架在进行分布式计算的时候，视频分片数据的加密任务分发到各个节点上，必不可少的会遇到任务和加密模块(节点工作站)之间的通信和调度问题。在Linux的进程间通信通常采用管道的方式。管道本身分为匿名管道和命名管道FIFO(firstinfirstout),两者不同之处在于匿名管道只允许两个具有亲缘关系的进程之间进行通信，而每个FIFO有一个路径名与之关联，从而允许无亲缘关系的进程访问同一个FIFO。在本发明一实施例中，利用命名管道进行与节点工作站的数据传输。为了避免管道两侧数据传递不同步的情况，在本发明一实施例中，在进行数据传输的过程中采用数据长度校验。即在数据的写入和读出时设计了一个数据长度校验的机制。如图4所示，在数据发送侧写入内容到管道之前，首先将要写入内容的内容长度先写入管道(S401)，然后写入要写入的内容(S402)。数据接收侧读取内容时先读取出管道中内容的长度(S411)，然后依照内容的长度读取内容(S412)，从而保证了管道内数据传递的完整性，不会造成管道阻塞和数据覆盖的问题。加密模块读取被加密数据后进行相关的选择性加密，加密后的数据通过输出管道写入数据传递给任务侧(Java程序)。输出管道的数据交换方法与输入管道的方法相同，首先将数据内容长度写入管道，然后写入数据内容。程序侧读取时也先将长度数据读取，然后读取内容，从而保证数据完整性。由于FIFO的文件属性，因此在对FIFO管道以文件方式进行读写之前，FIFO管道必须已经存在，进程只能对FIFO管道进行打开、关闭、读写等操作。因此，在数据传输之前，利用<K,V>键值对中的K值作为标识创建管道，对每个K值创建一对管道分别为输入管道inputPipe和输出管道outputPipe。输入管道用来传递程序侧到加密测的数据，输出管道用来传递加密后的数据到程序侧。程序侧与加密侧的管道写入策略是这样的，在写入内容到输入管道之前，首先将要写入内容的内容长度先写入管道，然后写入要写入的内容。读取内容时先读取出管道中内容的长度，然后依照内容的长度读取内容，从而保证了管道内数据传递的完整性，不会造成管道阻塞和数据覆盖的问题。加密模块读取被加密数据后进行相关的选择性加密，加密后的数据通过输出管道写入数据传递给任务侧(Java程序)。输出管道的数据交换方法与输入管道的方法相同，首先将数据内容长度写入管道，然后写入数据内容。程序侧读取时也先将长度数据读取，然后读取内容，从而保证数据完整性。进一步的，在本发明一实施例中，针对分布式系统特点，在视频加密算法、密钥的层次和密钥的随机性等方面进行了相关性的设计。视频分片的加密算法选择，采用了高级密钥加密算法AES，密钥长度为128bit，加密轮数设定为10轮。一方面在视频的安全性方面有了良好的保障，另一方面视频的加密效率也得到了较好的权衡。由于AES加密算法在发布以来的成熟应用以及其良好的跨平台性，最重要的是AES加密密钥不存在DES加密算法中出现的弱密钥和半弱密钥的情况。进一步的，在加密密钥生成的过程中，在视频加密的过程中引入了业务密钥SK，即在本发明一实施例中存在两种密钥，业务密钥SK以及加密密钥CW，其中：加密密钥CW用于加密视频分片数据的内容；业务密钥SK用来对加密密钥CW的加密控制字进行加密，保护加密密钥CW的安全性和安全传输。在加密过程中，首先利用加密密钥对内容进行加密，然后利用业务密钥对加密密钥CW的加密控制字进行加密并存入包头中；在解密过程中，首先利用与业务密钥对应的解密密钥解密加密密钥CW的加密控制字，然后利用加密密钥CW的加密控制字解密内容。进一步的，视频分片数据与加密密钥一一对应，不同的视频分片数据采用不同的加密密钥，每个加密密钥都是由生成规则随机产生的。这样就增加了视频的破解难度，即使单一加密密钥也漏也能保证视频数据整体的安全。同时，从属于同一视频的不同视频分片数据对应同一业务密钥。这样，客户终端只需要一把业务密钥就可以完成解密操作，降低了解密过程中密钥分发操作的复杂程度。在本发明一实施例中，整个密钥管理及分发的流程如图5所示：需要对视频分片数据加密时，密钥管理系统500将业务密钥和加密密钥分发给节点工作站(501、502、503)，每个节点工作站均收到业务密钥和加密密钥。加密密钥与节点工作站对应，业务密钥与视频分片所属的视频对应。不同的节点工作站接收到的加密密钥不同，针对同一视频的节点工作站接收到的业务密钥相同。当客户端410需要对视频分片数据进行解密时，密钥管理系统500只需要将该视频对应的业务密钥的解密密钥发送给客户端510即可。综上，根据本发明的方法，利用基于内存的分布式处理框架Spark解决了MapReduce框架中遇到的加密效率不高、数据块尺寸影响加密时间等问题。同时本发明还解决了分布式环境下密钥的传递和分发问题。虽然本发明所公开的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。本发明所述的方法还可有其他多种实施例。在不背离本发明实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变或变形，但这些相应的改变或变形都应属于本发明的权利要求的保护范围。当前第1页1 2 3