本文主要给大家介绍隐藏在华为云数据湖探索服务（后文简称DLI）背后的核心计算引擎——Spark。DLI团队在Spark之上做了大量的性能优化与服务化改造，但其本质还是脱离不了Spark的核心概念与思想，因此笔者从以下几点阐述，让读者快速对Spark有一个直观的认识，玩转DLI。Spark的诞生及优势     2009年，Spark诞生于伯克利大学AMPLab，诞生之初是属于伯克利大学的研究性项目。于2010年开源，2013年成为Apache开源项目，经过几年的发展逐渐取代了Hadoop，成为了开源社区炙手可热的大数据处理平台。Spark官方的解释：“Spark是用于大规模数据处理的统一分析引擎”，把关键词拆开来看，“大规模数据”指的是Spark的使用场景是大数据场景；“统一”主要体现在将大数据的编程模型进行了归一化，同时满足多种类型的大数据处理场景（批处理、流处理、机器学习等），降低学习和维护不同大数据引擎的成本；“分析引擎”表明Spark聚焦在计算分析，对标的是Hadoop中的MapReduce，对其模型进行优化与扩展。Spark为了解决MapReduce模型的优化和扩展，那么我们先探讨一下MapReduce存在的问题，然后分析Spark在MapReduce之上的改进。（1）MapReduce中间结果落盘，计算效率低下随着业务数据不断增多，业务逻辑不断多样化，很多ETL和数据预处理的工作需要多个MapReduce作业才能完成，但是MapReduce作业之间的数据交换需要通过写入外部存储才能完成，这样会导致频繁地磁盘读写，降低作业执行效率。Spark设计之初，就想要解决频繁落盘问题。Spark只在需要交换数据的Shuffle阶段（Shuffle中文翻译为“洗牌”，需要Shuffle的关键性原因是某种具有共同特征的数据需要最终汇聚到一个计算节点上进行计算）才会写磁盘，其它阶段，数据都是按流式的方式进行并行处理。（2）编程模型单一，场景表达能力有限MapReduce模型只有Map和Reduce两个算子，计算场景的表达能力有限，这会导致用户在编写复杂的逻辑（例如join）时，需要自己写关联的逻辑，如果逻辑写得不够高效，还会影响性能。与MapReduce不同，Spark将所有的逻辑业务流程都抽象成是对数据集合的操作，并提供了丰富的操作算子，如：join、sortBy、groupByKey等，用户只需要像编写单机程序一样去编写分布式程序，而不用关心底层Spark是如何将对数据集合的操作转换成分布式并行计算任务，极大的简化了编程模型Spark的核心概念：RDD     Spark中最核心的概念是RDD（Resilient Distributed Dataset）——弹性分布式数据集，顾名思义，它是一个逻辑上统一、物理上分布的数据集合，Spark通过对RDD的一系列转换操作来表达业务逻辑流程，就像数学中对一个向量的一系列函数转换。Spark通过RDD的转换依赖关系生成对任务的调度执行的有向无环图，并通过任务调度器将任务提交到计算节点上执行，任务的划分与调度是对业务逻辑透明的，极大的简化了分布式编程模型，RDD也丰富了分布式并行计算的表达能力。RDD上的操作分为Transformation算子和Action算子。Transformation算子用于编写数据的变换过程，是指逻辑上组成变换过程。Action算子放在程序的最后一步，用于对结果进行操作，例如：将结果汇总到Driver端（collect）、将结果输出到HDFS（saveAsTextFile）等，这一步会真正地触发执行。常见的Transformation算子包括：map、filter、groupByKey、join等，这里面又可以分为Shuffle算子和非Shuffle算子，Shuffle算子是指处理过程需要对数据进行重新分布的算子，如：groupByKey、join、sortBy等。常见的Action算子如：count、collect、saveAsTextFile等如下是使用Spark编程模型编写经典的WordCount程序：该程序通过RDD的算子对文本进行拆分、统计、汇总与输出。Spark程序中涉及到几个概念，Application、Job、Stage、Task。每一个用户写的程序对应于一个Application，每一个Action生成一个Job（默认包含一个Stage），每一个Shuffle算子生成一个新的Stage，每一个Stage中会有N个Task（N取决于数据量或用户指定值）。Spark的架构设计    前面讲述了Spark 核心逻辑概念，那么Spark的任务是如何运行在分布式计算环境的呢？接下来我们来看看开源框架Spark的架构设计。（注：涂色表示进程）Spark是典型的主从（Master- Worker）架构，Master 节点上常驻 Master守护进程，负责管理全部的 Worker 节点。Worker 节点上常驻 Worker 守护进程，负责与 Master 节点通信并管理 Executor。（注：橙色和绿色表示进程）Spark程序在客户端提交时，会在Application的进程中启动一个Driver。看一下官方对Driver的解释“The process running the main() function of the application and creating the SparkContext”。我们可以把Master和Worker看成是生产部总部老大（负责全局统一调度资源、协调生产任务）和生产部分部部长（负责分配、上报分部的资源，接收总部的命令，协调员工执行任务），把Driver和Executor看成是项目经理（负责分配任务和管理任务进度）和普通员工（负责执行任务、向项目经理汇报任务执行进度）。项目经理D to 总部老大M：Hi，老大，我刚接了一个大项目，需要你通知下面的分部部长W安排一些员工组成联合工作小组。总部老大M to 分部部长W：最近项目经理D接了一个大项目，你们几个部长都安排几个员工，跟项目经理D一起组成一个联合工作小组。分部部长W to 员工E：今天把大家叫到一起，是有个大项目需要各位配合项目经理D去一起完成，稍后会成立联合工作小组，任务的分配和进度都直接汇报给项目经理D。项目经理D to 员工E：从今天开始，我们会一起在这个联合工作小组工作一段时间，希望我们好好配合，把项目做好。好，现在开始分配任务…员工E to 项目经理D：你分配的xxx任务已完成，请分配其它任务。项目所有任务都完成后，项目经理D to 总部老大M：Hi，老大，项目所有的任务都已经完成了，联合工作小组可以解散了，感谢老大的支持。以上就是Spark的基本框架，基于Apache Spark/Flink生态，DLI提供了完全托管的大数据处理分析服务。借助DLI服务，你只需要关注应用的处理逻辑，提供构建好的应用程序包，就可以轻松完成你的大规模数据处理分析任务，即开即用，按需计费。华为云828企业上云节期间，购买数据湖探索DLI优惠更多。点击这里→了解更多精彩内容

如今，企业大数据资产在企业辅助决策、用户画像、推荐系统等诸多业务流程中扮演着越来越重要的作用，如何保证企业大数据在满足各业务部门数据访问需求的同时又能精细化保障数据访问安全、避免数据泄露是每个企业大数据资产管理者必须关注的话题。笔者结合在华为云数据湖探索服务中的技术沉淀与丰富的企业数据安全管理经验，从以下几点来探讨如何精细化保障企业大数据安全。1、企业大数据的安全挑战2、数据资产权限管理的通用做法3、以华为云DLI为例，对数据资产管理的实践&案例分析4、未来展望数据隔离、分层访问、授权，难题多多企业大数据的日积月累，自然面临着大数据安全的挑战：数据来源广泛，来源于不同的业务单元，又要服务于各种业务单元，还需要对不同层级的员工设置不一样的权限。如何防范企业数据不被未经授权的用户访问，管理数据在不同业务单元的共享，隔离企业敏感数据……企业可能面临着以下的挑战：1.1 数据隔离不同的项目业务数据需要隔离，如游戏运营数据，企业在设计大数据分析平台时可能期望A游戏产生的业务数据用来支撑A游戏运营分析，B游戏产生的业务数据是支撑B游戏运营分析，那么需要对业务数据按项目进行隔离，A游戏运营部门员工只可访问A游戏运营数据，B游戏运营部门员工只可访问B游戏运营数据1.2 数据分层访问不同层级业务部门对数据具备不同的访问权限，高层级部门可以访问底层级部门的数据，而低层级部门不可访问高层级部门的数据。如省级部门可以访问地市级数据，而地市级部门只可访问本地市数据，不可访问跨区数据，也不可访问省级部门数据。这就要求对数据的权限管理需要具备分层管理能力，能够分层级授予不同的权限。1.3 列级数据授权不同业务部门对同一份数据的访问权限要求不同，所以要求能够对数据进行精细化授权。如银行系统中，用户表中的身份证号信息是敏感信息，柜台系统可以查询用户的身份证号，但推荐系统就不需要身份证信息，只需要用户ID就可以了。这种场景下需要对用户表能够分列授权，对不同的业务单元不同的权限。1.4 批量授权随着企业规模的增大，企业员工可能非常庞大，分部门授权，批量授权也是很常见的业务场景。例如销售部门下面员工很多，如果单个单个的给销售人员授权，会非常麻烦，人员流动时取消授权也很复杂，这时就需要能够批量授权或者基本角色的授权模型，来实现一次授权，部门内员工均可使用的目的。四种权限模型，孰优孰劣？目前比较流行的大数据分析平台的有Hadoop，Hive，Spark等，它们使用的权限模型有POSIX模型、ACL模型、SQL Standard模型和RBAC模型。其中Hadoop大数据平台使用了POSIX和ACL权限模型来管理数据，HIVE和Spark使用了ACL和RBAC权限模型来管理数据。POSIX权限模型是基于文件的权限模型，与Linux系统的文件系统权限类似。即一个文件有相应的OWNER和GROUP，只能支持设置OWNER,、GROUP和其他用户的权限，可授权限也只有读写执行权限。这种模型不适用于企业用户，有一个明显的缺点就是它只有一个GROUP，不能实现不同的GROUP有不同的权限，也无法实现精细化的权限管理，只能在文件级授权，所授权限也只有读写与执行权限。ACL即Access Control List，ACL权限模型可以弥补POSIX权限模型的不足，可以实现比较精细化的权限管理。通过设置访问控制列表，我们可以授予某一个用户多个权限，也可以授予不同用户不同的权限。但ACL也有明显的缺点，当用户数较大时，ACL列表会变得庞大而难以维护，这在大企业中问题尤其明显。RBAC（Role-Based Access Control）模型也是业界常用的一种权限模型。是基于用户角色的权限管理模型，其首先将一个或多个权限授权某一个角色，再把角色与用户绑定，也实现了对用户的授权。一个用户可以绑定一个或多个角色，用户具备的权限为所绑定角色权限的并集。RBAC可以实现批量授权，可以灵活维护用户的权限，是当前比较流行的权限管理模型。SQL Standard模型是Hive/Spark使用权限模型之一，本质是使用SQL方式的授权语法来管理权限。Hive中的权限模型也是基于ACL和RBAC模型，即可以给单独的用户直接授权，也可能通过角色进行授权。数据湖探索怎么做数据资产管理？华为云DLI结合了ACL和RBAC两种权限模型来管理用户权限。DLI中涉及到的概念有：DLI用户：DLI用户为IAM账号及其下的子用户，下面访问权限说明的用户均指IAM账号及其下的子用户。DLI资源：DLI的资源分为数据库(Database)、表（table）、视图（View）、作业（Job）和队列(Queue)。资源是按项目隔离的，不同项目的资源不可互相访问。表和视图是数据库(Database)下的子资源。DLI权限：DLI权限为执行DLI相关操作所需要的权限。DLI中的权限比较细，每项操作对应的权限都不一样，如创建表对应CREATE_TABLE权限，删除表对应DROP_TABLE权限, 查询对应SELECT权限等等。DLI使用统一身份认证（IAM）的策略和DLI的访问控制列表（ACL）来管理资源的访问权限。其中统一身份认证（IAM）的策略控制项目级资源的隔离，和定义用户为项目的管理员还是普通用户。访问控制列表（ACL）控制队列，数据库，表，视图，列的访问权限和授权管理。DLI使用统一身份认证来完成用户认证和用户角色管理。DLI在IAM中预定义了几个角色：Tenant Administrator（租户管理员），DLI Service Admin（DLI管理员），DLI Service User（DLI普通用户）。其中具备租户管理员或DLI管理员角色的用户在DLI内是管理员，可以操作该项目的所有资源，包括创建数据库，创建队列，操作项目下的数据库，表，视图，队列，作业。普通用户不可创建数据库，不可创建队列，依赖管理员的授权，可以执行创建表，查询表等操作。DLI使用ACL和RBAC两种模型来管理用户权限。管理员或资源的所有者可以授予另外一个用户单个或多个权限，也可能创建角色，授予权限给创建好的角色，然后绑定角色和用户。DLI提供了API和SQL语句两种方式来实现以上权限管理，方便用户灵活授权。具体使用方式可以参考DLI的权限管理。案例分析拿银行的大数据实践来分析下如何利用DLI来管理数据的权限。众所周知，银行积累了大量的用户数据，包括用户信息，交易信息，账户信息等等数以亿计的数据。而银行业务也是非常的复杂，涉及到柜员系统，监管部门，运营部门，营销部门等等各个业务线，各业务线对数据的要求不同，访问的权限不同。我们拿反洗钱业务与画像业务来简单介绍下如何利用DLI平台实现大数分析和数据资产权限管理。典型的反洗钱业务一般是大额预警和黑名单机制，需要从海量的交易数据中筛选出大额交易或者是黑名单人员交易数据，将这些数据反馈给监管人员进行进一步分析，涉及到的数据是交易数据，账户信息和黑名单信息。画像一般会分析用户的交易类型与交易数据，推断出用户的兴趣爱好，给用户画像，标记用户的兴趣点在哪些地方。涉及交易信息中的交易类型和账号信息。这两项业务中在DLI中，由数据管理员生成生成用户信息表，交易数据表，账户信息表，黑名单信息表，并导入相应的数据。在反省钱业务，授予反洗钱业务部门或人员账户信息表的查询权限，交易数据表的查询权限，黑名单信息的查询权限，通过对账户信息表和交易数据表和黑名单表的联合查询，可以查找出异常交易信息及相关交易人员，反馈给反洗钱监管人员。在画像业务中，由数据管理员授予画像业务部门或人员用户信息表的查询权限，交易数据表中交易金额和交易类型，交易商户等列的查询权限，账户信息表中的账户ID和用户ID列的查询权限，经过这几张表的联合与聚合查询，找出用户常用交易信息，包含交易类型，金额，及相关地点等信息，描绘出用户画像信息。未来展望传统企业数据资产面临着几个难题。各业务部门均会产生数据，数据标准不一致，维护复杂。各业务部门数据存在在不同的系统中，数据容易形成孤岛，无法有效挖掘利用。部门间数据共享复杂，容易形成网状授权网络，维护成本巨大。数据湖DLI方案可以解决这样的难题，使用统一的数据管理平台、数据存储、数据标准，进行统一的数据资产管理、授权管理。华为云828企业上云节期间，数据湖探索DLI也在活动产品之列，有数据分析需求的企业赶紧趁着促销入手试试。转自：https://blog.csdn.net/devcloud/article/details/108256178

数据湖探索DLI服务 按需计费-数据扫描量 中国站原先要0.3元/GB现在只需0.03元/GB，直接降价90%官网页直达：https://www.huaweicloud.com/product/dli.html

尊敬的华为云客户：华为云对数据湖探索DLI的单位进行调整，新单位于2020/01/16 00:00（北京时间）正式生效，生效后DLI整体计费不变。具体价格详情如下：单位规格单位定义华北-北京一、华北-北京四、华东-上海一、华东-上海二、华南-广州各局点单价香港、亚太-曼谷各局点单价调整后调整前调整后调整前调整后调整前CU1核CPU+4G内存4核CPU+16G内存￥0.35/小时￥1.40/小时￥0.42/小时￥1.68/小时如您有任何问题，可随时通过工单或者服务热线（4000-955-988或950808）与我们联系。感谢您对华为云的支持！

尊敬的华为云客户：华为云对数据湖探索DLI的单位进行调整，新单位于2020/01/16 00:00（北京时间）正式生效，生效后DLI整体计费不变。具体价格详情如下：单位规格单位定义华北-北京一、华北-北京四、华东-上海一、华东-上海二、华南-广州各局点单价香港、亚太-曼谷各局点单价调整后调整前调整后调整前调整后调整前CU1核CPU+4G内存4核CPU+16G内存￥0.35/小时￥1.40/小时￥0.42/小时￥1.68/小时如您有任何问题，可随时通过工单或者服务热线（4000-955-988或950808）与我们联系。感谢您对华为云的支持！

尊敬的华为云客户：华为云对数据湖探索服务（Data Lake Insight，简称DLI）价格进行调整，新价格于2018/09/25 00:00:00正式生效，生效后数据湖探索服务新购、续费均按调整后价格收取费用。价格调整后，数据湖探索服务按扫描量的计费单价统一为0.3元/GB，不再根据资源大小阶梯计费，按CU时的计费单价调整为1.4元/CU/时，并且新增加基因作业计费项。具体价格请在新价格生效后参考产品的计费详情页。如您有任何问题，欢迎您拨打华为云服务热线:4000-955-988。感谢您对华为云的支持！