数字经济时代的来临，推动市场向着更灵活高效的形态演进，也促进了一批新业态和新模式的形成。而数据作为这一时代的核心要素，凭借其强大的潜在生长力，改变了人们对于生产效力的认知，不断地为社会发展注入新的活力。    2020年，国家层面将“数据”作为新型生产要素写入中央文件中，“数据是资产”也已成为市场的共识。随着数据资产成为企业数字化转型中的重要基石，市场主体对于数据管理的需求也持续扩张。    而数据资产运营是挖掘数据价值的有效引擎，能够决定企业数字化转型蜕变之路的成败。由数据资源集成的大数据产业生态，需要高效的数据资产运营手段为伍，才能实现企业商业价值最大化。企业未来想实现数智化发展，就要充分认识数字时代的转型关键，重点把握核心数据资产运营环节，通过闭环管理、周期评估、优化迭代运营过程，最终形成动态可持续的数据应用价值链。    未来，数据资产运营将成为企业商业价值实现的重要一环，如何有效掌握这一关键，全面释放数据潜能，将成为各市场主体的战略突破点。    白皮书指出，数据资产运营的关键在于“三要素”与“四重奏”。    在数字经济时代背景下，企业通过数据资产运营实现数据价值的重要性凸显。数据资产如何运营？其核心在于向下扎根与向上生长。向下扎根，意味着围绕数据建立良好的组织与意识、流程与规范、平台与工具，以在公司内部培育数据资产运营土壤。向上生长，意味着在深深扎根数据文化土壤的基础上，通过开展数据资产的盘点、评估、治理与共享，将核心业务数据资产紧握手中，实现数据资产稳健运营。二者缺一不可，只有做到这两点，才能助力企业数据互联互通，释放独有价值。“三要素”之组织与意识：凝心聚力——建立完善组织架构体系，培养数据资产运营文化    组织与意识需要企业管理层的引领。构建基于数据驱动的组织模式，实现组织内外人、物、知识等资源弹性供给和单元的动态协作是构建数字企业的基础，也是组织适应、利用、驾驭不确定环境的利器，数据资产运营组织架构的调整帮助企业打造一体化柔性运营管控能力，针对公司需求作出更敏捷的响应。“三要素”之流程与规范：规圆矩方——数据管理规范化，确保规章制度有效实施，奠定创新数据管理基础    无规矩不成方圆，数据驱动型企业在创新拼搏的同时，也亟需对数据全生命周期进行有机管理。规范化的数据管理的流程与制度能够让数据的交互、整合与使用更加流畅，从而大大减少数据上的问题与冲突，助力公司的数据管理由传统模式健康稳定地转向创新模式。“三要素”之平台与工具：巧借东风——数据资产管理平台承载数据产业化与商品化    平台与工具意味着生产力，是开展数据资产管理不可或缺的底层基石。通过一体化的系统框架体系，集中治理数据问题、集中进行数据监控运维与服务运营，不仅将传统数据管理工具各个组件进行了整合，更是将其进行打通与融合，实现数据在平台上的有效运转。“四重奏”之数据资产盘点：细致入微——双视角厘清数据资产，绘制企业级数据资产地图    数据资产盘点是数据资产运营的先行任务，旨在解决数据资产“有什么”的问题。从业务视角与技术视角出发，形成企业数据资产框架和数据资产目录，支持建立全面覆盖的企业级数据资产地图，为数据资产“用什么”以及“如何用”奠定基础。“四重奏”之数据资产评估：详察形候——多维度评估企业数据资产    数据资产评估是时代赋予企业的课题。在现如今的数字经济时代，随着数据、算法的升级，“资产”的形态和范围正在出现革命性的变化，“数据资产”这一概念也应运而生。但目前这一资产形式尚未体现在企业的财务报表上，同时也面临着诸多争议与挑战，合理、健全、有效的数据资产评估方式对社会数字化趋势的意义尤为深远。“四重奏”之数据治理：准绳嘉量——全方位构建数据治理完整链条，奠定高质量数据基石    数据治理是对数据资产的管理形式权力和控制的活动集合，它不仅仅是一套用工具组合的产品级解决方案，更是从决策层到技术层，从管理制度到工具支撑，自上而下贯穿整个组织架构的完整链条，以期通过持续的评估、指导和监督，确保富有成效且高效的数据利用，促进组织协作和结构化决策，为企业创造价值。“四重奏”之数据共享：内外兼修——全面释放数据价值    数据共享是盘活企业数据资产的有效手段。企业通过开展数据资产的内部循环与外部流通，运用数据分析与挖掘获取新的信息，在企业内部形成数据流转与共享，在企业外部为社会提供数据资产的价值，也同时为企业谋取创新型的收益，实现数据的增值。    后疫情时代，企业数字化转型需求不断攀升，塑造线上化、数字化服务能力成为转型变革的核心诉求，而数据资产运营则是转型中的关键环节。    数生万物，转型之本。响应数字化趋势不能只靠口号，而是需要充分把握“三要素”与“四重奏”的关键要义，搭建规范完善的数据管理框架，借力数据资产运营持续激发数据活力。通过数据重塑业务链与管理链，用数据贯穿企业经营与创新发展，使数据成为真正的生产力。最终实现企业长远发展愿景。来源：中国大数据产业观察，如有侵权，请联系删除~

 基于JVM的开源数据处理语言主要有Kotlin、Scala、SPL，下面对三者进行多方面的横向比较，从中找出开发效率最高的数据处理语言。本文的适用场景设定为项目开发中常见的数据处理和业务逻辑，以结构化数据为主，大数据和高性能不作为重点，也不涉及消息流、科学计算等特殊场景。  基本特征 适应面  Kotlin的设计初衷是开发效率更高的Java，可以适用于任何Java涉及的应用场景，除了常见的信息管理系统，还能用于WebServer、Android项目、游戏开发，通用性比较好。Scala的设计初衷是整合现代编程范式的通用开发语言，实践中主要用于后端大数据处理，其他类型的项目中很少出现，通用性不如Kotlin。SPL的设计初衷是专业的数据处理语言，实践与初衷一致，前后端的数据处理、大小数据处理都很适合，应用场景相对聚焦，通用性不如Kotlin。  编程范式  Kotlin以面向对象编程为主，也支持函数式编程。Scala两种范式都支持，面向对象编程比Koltin更彻底，函数式编程也比Koltin方便些。SPL可以说不算支持面向对象编程，有对象概念，但没有继承重载这些内容，函数式编程比Kotlin更方便。  运行模式  Kotlin和Scala是编译型语言，SPL是解释型语言。解释型语言更灵活，但相同代码性能会差一点。不过SPL有丰富且高效的库函数，总体性能并不弱，面对大数据时常常会更有优势。  外部类库  Kotlin可以使用所有的Java类库，但缺乏专业的数据处理类库。Scala也可以使用所有的Java类库，且内置专业的大数据处理类库（Spark）。SPL内置专业的数据处理函数，提供了大量时间复杂度更低的基本运算，通常不需要外部Java类库，特殊情况可在自定义函数中调用。  IDE和调试  三者都有图形化IDE和完整的调试功能。SPL的IDE专为数据处理而设计，结构化数据对象呈现为表格形式，观察更加方便，Kotlin和Scala的IDE是通用的，没有为数据处理做优化，无法方便地观察结构化数据对象。  学习难度  Kotlin的学习难度稍高于Java，精通Java者可轻易学会。Scala的目标是超越Java，学习难度远大于Java。SPL的目标就是简化Java甚至SQL的编码，刻意简化了许多概念，学习难度很低。  代码量  Kotlin的初衷是提高Java的开发效率，官方宣称综合代码量只有Java的20%，可能是数据处理类库不专业的缘故，这方面的实际代码量降低不多。Scala的语法糖不少，大数据处理类库比较专业，代码量反而比Kotlin低得多。SPL只用于数据处理，专业性最强，再加上解释型语言表达能力强的特点，完成同样任务的代码量远远低于前两者（后面会有对比例子），从另一个侧面也能说明其学习难度更低。  语法 数据类型  原子数据类型：三者都支持，比如Short、Int、Long、Float、Double、Boolean  日期时间类型：Kotlin缺乏易用的日期时间类型，一般用Java的。Scala和SPL都有专业且方便的日期时间类型。  有特色的数据类型：Kotlin支持非数值的字符Char、可空类型Any?。Scala支持元组（固定长度的泛型集合）、内置BigDecimal。SPL支持高性能多层序号键，内置BigDecimal。  集合类型：Kotlin和Scala支持Set、List、Map。SPL支持序列（有序泛型集合，类似List）。  结构化数据类型：Kotlin有记录集合List，但缺乏元数据，不够专业。Scala有专业的结构化数类型，包括Row、RDD、DataSet、DataFrame（本文以此为例进行说明）等。SPL有专业的结构化数据类型，包括record、序表（本文以此为例进行说明）、内表压缩表、外存Lazy游标等。  Scala独有隐式转换能力，理论上可以在任意数据类型之间进行转换（包括参数、变量、函数、类），可以方便地改变或增强原有功能。  流程处理  三者都支持基础的顺序执行、判断分支、循环，理论上可进行任意复杂的流程处理，这方面不多讨论，下面重点比较针对集合数据的循环结构是否方便。以计算比上期为例，Kotlin代码：  mData.forEachIndexed{index,it-> if(index>0) it.Mom= it.Amount/mData[index-1].Amount-1 } Kotlin的forEachIndexed函数自带序号变量和成员变量，进行集合循环时比较方便，支持下标取记录，可以方便地进行跨行计算。Kotlin的缺点在于要额外处理数组越界。  Scala代码：  val w = Window.orderBy(mData("SellerId")) mData.withColumn("Mom", mData ("Amount")/lag(mData ("Amount"),1).over(w)-1) Scala跨行计算不必处理数组越界，这一点比Kotlin方便。但Scala的结构化数据对象不支持下标取记录，只能用lag函数整体移行，这对结构化数据不够方便。lag函数不能用于通用性强的forEach，而要用withColumn之类功能单一的循环函数。为了保持函数式编程风格和SQL风格的底层统一，lag函数还必须配合窗口函数（Python的移行函数就没这种要求），整体代码看上去反而比Kotlin复杂。  SPL代码：  mData.(Mom=Amount/Amount[-1]-1)  SPL对结构化数据对象的流程控制进行了多项优化，类似forEach这种最通用最常用的循环函数，SPL可以直接用括号表达，简化到极致。SPL也有移行函数，但这里用的是更符合直觉的“[相对位置]"语法，进行跨行计算时比Kotlin的绝对定位强大，比Scala的移行函数方便。上述代码之外，SPL还有更多针对结构化数据的流程处理功能，比如：每轮循环取一批而不是一条记录；某字段值变化时循环一轮。  Lambda表达式  Lambda表达式是匿名函数的简单实现，目的是简化函数的定义，尤其是变化多样的集合计算类函数。Kotlin支持Lambda表达式，但因为编译型语言的关系，难以将参数表达式方便地指定为值参数或函数参数，只能设计复杂的接口规则进行区分，甚至有所谓高阶函数专用接口，这就导致Kotin的Lambda表达式编写困难，在数据处理方面专业性不足。几个例子：  "abcd".substring( 1,2)                        //值参数 "abcd".sumBy{ it.toInt()}                    //函数参数 mData.forEachIndexed{ index,it-> if(index>0) it.Mom=…}        //函数参数的函数带多个参数 Koltin的Lambda表达式专业性不足，还表现在使用字段时必须带上结构化数据对象的变量名（it），而不能像SQL那样单表计算时可以省略表名。  同为编译型语言，Scala的Lambda表达式和Kotlin区别不大，同样需要设计复杂的接口规则，同样编写困难，这里就不举例了。计算比上期时，字段前也要带上结构化数据对象变量名或用col函数，形如mData (“Amount”)或col(“Amount”)，虽然可以用语法糖弥补，写成$”Amount”或’Amount，但很多函数不支持这种写法，硬要弥补反而使风格不统一。  SPL的Lambda表达式简单易用，比前两者更专业，这与其解释型语言的特性有关。解释型语言可以方便地推断出值参数和函数参数，没有所谓复杂的高阶函数专用接口，所有的函数接口都一样简单。几个例子：  mid("abcd",2,1)                            //值参数 Orders.sum(Amount*Amount)                    //函数参数 mData.(Mom=Amount/Amount[-1]-1)                    //函数参数的函数带多个参数 1 2 3 SPL可直接使用字段名，无须结构化数据对象变量名，比如：  Orders.select(Amount>1000 && Amount<=3000 && like(Client,"*S*")) 1 SPL的大多数循环函数都有默认的成员变量~和序号变量#，可以显著提升代码编写的便利性，特别适合结构化数据计算。比如，取出偶数位置的记录：  Students.select(# % 2==0) 1 求各组的前3名：  Orders.group(SellerId;~.top(3;Amount)) 1 SPL函数选项和层次参数  值得一提的是，为了进一步提高开发效率，SPL还提供了独特的函数语法。  有大量功能类似的函数时，大部分程序语言只能用不同的名字或者参数进行区分，使用不太方便。而SPL提供了非常独特的函数选项，使功能相似的函数可以共用一个函数名，只用函数选项区分差别。比如，select函数的基本功能是过滤，如果只过滤出符合条件的第1条记录，可使用选项@1：  T.select@1(Amount>1000) 1 对有序数据用二分法进行快速过滤，使用@b：  T.select@b(Amount>1000) 1 函数选项还可以组合搭配，比如：  Orders.select@1b(Amount>1000) 1 有些函数的参数很复杂，可能会分成多层。常规程序语言对此并没有特别的语法方案，只能生成多层结构数据对象再传入，非常麻烦。SQL使用了关键字把参数分隔成多个组，更直观简单，但这会动用很多关键字，使语句结构不统一。而SPL创造性地发明了层次参数简化了复杂参数的表达，通过分号、逗号、冒号自高而低将参数分为三层：  join(Orders:o,SellerId ; Employees:e,EId) 1 数据源 数据源种类  Kotlin原则上可以支持所有的Java数据源，但代码很繁琐，类型转换麻烦，稳定性也差，这是因为Kotlin没有内置的数据源访问接口，更没有针对结构化数据处理做优化（JDBC接口除外）。从这个意义讲，也可以说它不直接支持任何数据源，只能使用Java第三方类库，好在第三方类库的数量足够庞大。  Scala支持的数据源种类比较多，且有六种数据源接口是内置的，并针对结构化数据处理做了优化，包括：JDBC、CSV、TXT、JSON、Parquet列存格式、ORC列式存储，其他的数据源接口虽然没有内置，但可以用社区小组开发的第三方类库。Scala提供了数据源接口规范，要求第三方类库输出为结构化数据对象，常见的第三方接口有XML、Cassandra、HBase、MongoDB等。  SPL内置了最多的数据源接口，并针对结构化数据处理做了优化，包括：  JDBC（即所有的RDB）  CSV、TXT、JSON、XML、Excel  HBase、HDFS、Hive、Spark  Salesforce、阿里云  Restful、WebService、Webcrawl  Elasticsearch、MongoDB、Kafka、R2dbc、FTP  Cassandra、DynamoDB、influxDB、Redis、SAP  这些数据源都可以直接使用，非常方便。对于其他未列入的数据源，SPL也提供了接口规范，只要按规范输出为SPL的结构化数据对象，就可以进行后续计算。  代码比较  以规范的CSV文件为例，比较三种语言的解析代码。Kotlin：  val file = File("D:\\data\\Orders.txt") data class Order(var OrderID: Int,var Client: String,var SellerId: Int, var Amount: Double, var OrderDate: Date) var sdf = SimpleDateFormat("yyyy-MM-dd") var Orders=file.readLines().drop(1).map{ var l=it.split("\t") var r=Order(l[0].toInt(),l[1],l[2].toInt(),l[3].toDouble(),sdf.parse(l[4])) r } var resutl=Orders.filter{ it.Amount>= 1000 && it.Amount < 3000} Koltin专业性不足，通常要硬写代码读取CSV，包括事先定义数据结构，在循环函数中手工解析数据类型，整体代码相当繁琐。也可以用OpenCSV等类库读取，数据类型虽然不用在代码中解析，但要在配置文件中定义，实现过程不见得简单。  Scala专业性强，内置解析CSV的接口，代码比Koltin简短得多：  val spark = SparkSession.builder().master("local").getOrCreate() val Orders = spark.read.option("header", "true").option("sep","\t").option("inferSchema", "true").csv("D:/data/orders.csv").withColumn("OrderDate", col("OrderDate").cast(DateType)) Orders.filter("Amount>1000 and Amount<=3000") Scala在解析数据类型时麻烦些，其他方面没有明显缺点。  SPL更加专业，连解析带计算只要一行：  T("D:/data/orders.csv").select(Amount>1000 && Amount<=3000) 1 跨源计算  JVM数据处理语言的开放性强，有足够的能力对不同的数据源进行关联、归并、集合运算，但数据处理专业性的差异，导致不同语言的方便程度区别较大。  Kotlin不够专业，不仅缺乏内置数据源接口，也缺乏跨源计算函数，只能硬写代码实现。假设已经从不同数据源获得了员工表和订单表，现在把两者关联起来：  data class OrderNew(var OrderID:Int ,var Client:String, var SellerId:Employee ,var Amount:Double ,var OrderDate:Date ) val result = Orders.map { o->var emp=Employees.firstOrNull{ it.EId==o.SellerId } emp?.let{ OrderNew(o.OrderID,o.Client,emp,o.Amount,o.OrderDate) } } .filter {o->o!=null} 很容易看出Kotlin的缺点，代码只要一长，Lambda表达式就变得难以阅读，还不如普通代码好理解；关联后的数据结构需要事先定义，灵活性差，影响解题流畅性。  Scala比Kotlin专业，不仅内置了多种数据源接口，而且提供了跨源计算的函数。同样的计算，Scala代码简单多了：  val join=Orders.join(Employees,Orders("SellerId")===Employees("EId"),"Inner") 1 可以看到，Scala不仅具备专用于结构化数据计算的对象和函数，而且可以很好地配合Lambda语言，代码更易理解，也不用事先定义数据结构。  SPL更加专业，结构化数据对象更专业，跨源计算函数更方便，代码更简短：  join(Orders:o,SellerId;Employees:e,EId) 1 自有存储格式  反复使用的中间数据，通常会以某种格式存为本地文件，以此提高取数性能。Kotlin支持多种格式的文件，理论上能够进行中间数据的存储和再计算，但因为在数据处理方面不专业，基本的读写操作都要写大段代码，相当于并没有自有的存储格式。  Scala支持多种存储格式，其中parquet文件常用且易用。parquet是开源存储格式，支持列存，可存储大量数据，中间计算结果（DataFrame）可以和parquet文件方便地互转。遗憾的是，parquet的索引尚不成熟。  val df = spark.read.parquet("input.parquet") val result=df.groupBy(data("Dept"),data("Gender")).agg(sum("Amount"),count("*")) result.write.parquet("output.parquet") SPL支持btx和ctx两种私有二进制存储格式，btx是简单行存，ctx支持行存、列存、索引，可存储大量数据并进行高性能计算，中间计算结果（序表/游标）可以和这两种文件方便地互转。  A 1    =file("input.ctx").open() 2    =A1.cursor(Dept,Gender,Amount).groups(Dept,Gender;sum(Amount):amt,count(1):cnt) 3    =file("output.ctx").create(#Dept,#Gender,amt,cnt).append(A2.cursor()) 结构化数据计算 结构化数据对象  数据处理的核心是计算，尤其是结构化数据的计算。结构化数据对象的专业程度，深刻地决定了数据处理的方便程度。  Kotlin没有专业的结构化数据对象，常用于结构化数据计算的是List，其中EntityBean可以用data class简化定义过程。  List是有序集合（可重复），凡涉及成员序号和集合的功能，Kotlin支持得都不错。比如按序号访问成员：  Orders[3]                        //按下标取记录，从0开始 Orders.take(3)                        //前3条记录 Orders.slice(listOf(1,3,5)+IntRange(7,10))        //下标是1、3、5、7-10的记录 还可以按倒数序号取成员：  Orders.reversed().slice(1,3,5)                //倒数第1、3、5条 Orders.take(1)+Orders.takeLast(1)            //第1条和最后1条 涉及顺序的计算难度都比较大，Kotlin支持有序计集合，进行相关的计算会比较方便。作为集合的一种，List擅长的功能还有集合成员的增删改、交差合、拆分等。但List不是专业的结构化数据对象，一旦涉及字段结构相关的功能，Kotlin就很难实现了。比如，取Orders中的两个字段组成新的结构化数据对象。  data class CliAmt(var Client: String, var Amount: Double) var CliAmts=Orders.map{it.let{CliAmt(it.Client,it.Amount) }} 上面的功能很常用，相当于简单SQL语句select Client,Amount from Orders，但Kotlin写起来就很繁琐，不仅要事先定义新结构，还要硬编码完成字段的赋值。简单的取字段功能都这么繁琐，高级些的功能就更麻烦了，比如：按字段序号取、按参数取、获得字段名列表、修改字段结构、在字段上定义键和索引、按字段查询计算。  Scala也有List，与Kotlin区别不大，但Scala为结构化数据处理设计了更加专业的数据对象DataFrame（以及RDD、DataSet）。 DataFrame是有结构的数据流，与数据库结果集有些相似，都是无序集合，因此不支持按下标取数，只能变相实现。比如，第10条记录：  Orders.limit(10).tail(1)(0)                         可以想象，凡与顺序相关的计算，DataFrame实现起来都比较麻烦，比如区间、移动平均、倒排序等。 除了数据无序，DataFrame也不支持修改（immutable特性），如果想改变数据或结构，必须生成新的DataFrame。比如修改字段名，实际上要通过复制记录来实现：  Orders.selectExpr("Client as Cli")                     DataFrame支持常见的集合计算，比如拆分、合并、交差合并，其中并集可通过合集去重实现，但因为要通过复制记录来实现，集合计算的性能普遍不高。 虽然有不少缺点，但DataFrame是专业的结构化数据对象，字段访问方面的能力是Kotlin无法企及的。比如，获得元数据/字段名列表：  Orders.schema.fields.map(it=>it.name).toList 还可以方便地用字段取数，比如，取两个字段形成新dataframe：  Orders.select("Client","Amount")                //可以只用字段名 或用计算列形成新DataFrame:  Orders.select(Orders("Client"),Orders("Amount")+1000)        //不能只用字段名     遗憾的是，DataFrame只支持用字符串形式的名字来引用字段，不支持用字段序号或默认名字，导致很多场景下不够方便。此外，DataFrame也不支持定义索引，无法进行高性能随机查询，专业性还有缺陷。  SPL的结构化数据对象是序表，优点是足够专业，简单易用，表达能力强。 按序号访问成员：  Orders(3)                            //按下标取记录，从1开始 Orders.to(3)                            //前3条记录 Orders.m(1,3,5,7:10)                        //序号是1、3、5、7-10的记录 按倒数序号取记录，独特之处在于支持负号表示倒数，比Kotlin专业且方便：  Orders.m(-1,-3,-5)                        //倒数第1，3，5条 Orders.m(1,-1)                            //第1条和最后1条 1 2 作为集合的一种，序表也支持集合成员的增删改、交并差合、拆分等功能。由于序表和List一样都是可变集合（mutable），集合计算时尽可能使用游离记录，而不是复制记录，性能比Scala好得多，内存占用也少。 序表是专业的结构化数据对象，除了集合相关功能外，更重要的是可以方便地访问字段。比如，获得字段名列表：  Orders.fname()                             1 取两个字段形成新序表：  Orders.new(Client,Amount) 1 用计算列形成新序表：  Orders.new(Client,Amount*0.2) 1 修改字段名：  Orders.alter(;OrderDate)                    //不复制记录 1 有些场景需要用字段序号或默认名字访问字段，SPL都提供了相应的访问方法：  Orders(Client)                            //按字段名（表达式取） Orders([#2,#3])                            //按默认字段名取 Orders.field(“Client”)                        //按字符串（外部参数） Orders.field(2)                            //按字段序号取 1 2 3 4 作为专业的结构化数据对象，序表还支持在字段上定义键和索引：  Orders.keys@i(OrderID)                        //定义键，同时建立哈希索引 Orders.find(47)                            //用索引高速查找 1 2 计算函数  Kotlin支持部分基本计算函数，包括：过滤、排序、去重、集合的交叉合并、各类聚合、分组汇总。但这些函数都是针对普通集合的，如果计算目标改成结构化数据对象，计算函数库就显得非常不足，通常就要辅以硬编码才能实现计算。还有很多基本的集合运算是Kotlin不支持的，只能自行编码实现，包括：关联、窗口函数、排名、行转列、归并、二分查找等。其中，归并和二分查找等属于次序相关的运算，由于Kotlin List是有序集合，自行编码实现这类运算不算太难。总体来讲，面对结构化数据计算，Kotlin的函数库可以说较弱。  Scala的计算函数比较丰富，且都是针对结构化数据对象设计的，包括Kotlin不支持的函数：排名、关联、窗口函数、行转列，但基本上还没有超出SQL的框架。也有一些基本的集合运算是Scala不支持的，尤其是与次序相关的，比如归并、二分查找，由于Scala DataFrame沿用了SQL中数据无序的概念，即使自行编码实现此类运算，难度也是非常大的。总的来说，Scala的函数库比Kotlin丰富，但基本运算仍有缺失。  SPL的计算函数最丰富，且都是针对结构化数据对象设计的，SPL极大地丰富了结构化数据运算内容，设计了很多超出SQL的内容，当然也是Scala/Kotlin不支持的函数，比如有序计算：归并、二分查找、按区间取记录、符合条件的记录序号；除了常规等值分组，还支持枚举分组、对齐分组、有序分组；将关联类型分成外键和主子；支持主键以约束数据，支持索引以快速查询；对多层结构的数据（多表关联或Json\XML）进行递归查询等。  以分组为例，除了常规的等值分组外，SPL还提供了更多的分组方案：  枚举分组：分组依据是若干条件表达式，符合相同条件的记录分为一组。  对齐分组：分组依据是外部集合，记录的字段值与该集合的成员相等的分为一组，组的顺序与该集合成员的顺序保持一致，允许有空组，可单独分出一组“不属于该集合的记录”。  有序分组：分组依据是已经有序的字段，比如字段发生变化或者某个条件成立时分出一个新组，SPL直接提供了这类有序分组，在常规分组函数上加个选项就可以完成，非常简单而且运算性能也更好。其他语言（包括SQL）都没有这种分组，只能费劲地转换为传统的等值分组或者自己硬编码实现。  下面我们通过几个常规例子来感受一下这三种语言在计算函数方式的差异。  排序  按Client顺序，Amount逆序排序。Kotlin:  Orders.sortedBy{it.Amount}.sortedByDescending{it.Client} 1 Kotlin代码不长，但仍有不便之处，包括：逆序正序是两个不同的函数，字段名必须带表名，代码写出的字段顺序与实际的排序顺序相反。  Scala:  Orders.orderBy(Orders("Client"),-Orders("Amount")) 1 Scala简单多了，负号代表逆序，代码写出的字段顺序与排序的顺序相同。遗憾之处在于：字段仍要带表名；编译型语言只能用字符串实现表达式的动态解析，导致代码风格不统一。  SPL:  Orders.sort(Client,-Amount) 1 SPL代码更简单，字段不必带表名，解释型语言代码风格容易统一。  分组汇总  Kotlin：  data class Grp(var Dept:String,var Gender:String)  data class Agg(var sumAmount: Double,var rowCount:Int) var result1=data.groupingBy{Grp(it!!.Dept,it.Gender)} .fold(Agg(0.0,0),{acc, elem -> Agg(acc.sumAmount + elem!!.Amount,acc.rowCount+1)}) .toSortedMap(compareBy { it.Dept }.thenBy { it.Gender })  Kotlin代码比较繁琐，不仅要用groupingBy和fold函数，还要辅以硬编码才能实现分组汇总。当出现新的数据结构时，必须事先定义才能用，比如分组的双字段结构、汇总的双字段结构，这样不仅灵活性差，而且影响解题流畅性。最后的排序是为了和其他语言的结果顺序保持一致，不是必须的。  Scala：  val result=data.groupBy(data("Dept"),data("Gender")).agg(sum("Amount"),count("*")) 1 Scala代码简单多了，不仅易于理解，而且不用事先定义数据结构。  SPL：  data.groups(Dept,Gender;sum(Amount),count(1)) 1 SPL代码最简单，表达能力不低于SQL。  关联计算  两个表有同名字段，对其关联并分组汇总。Kotlin代码：  data class OrderNew(var OrderID:Int ,var Client:String, var SellerId:Employee ,var Amount:Double ,var OrderDate:Date ) val result = Orders.map { o->var emp=Employees.firstOrNull{it.EId==o.EId} emp?.let{ OrderNew(o.OrderID,o.Client,emp,o.Amount,o.OrderDate)} } .filter {o->o!=null} data class Grp(var Dept:String,var Gender:String)  data class Agg(var sumAmount: Double,var rowCount:Int) var result1=data.groupingBy{Grp(it!!.EId.Dept,it.EId.Gender)} .fold(Agg(0.0,0),{acc, elem -> Agg(acc.sumAmount + elem!!.Amount,acc.rowCount+1)}) .toSortedMap(compareBy { it.Dept }.thenBy { it.Gender }) Kotlin代码很繁琐，很多地方都要定义新数据结构，包括关联结果、分组的双字段结构、汇总的双字段结构。  Scala  val join=Orders.as("o").join(Employees.as("e"),Orders("EId")===Employees("EId"),"Inner") val result= join.groupBy(join("e.Dept"), join("e.Gender")).agg(sum("o.Amount"),count("*")) Scala比Kolin简单多了，不用繁琐地定义数据结构，也不必硬编码。  SPL更简单：  join(Orders:o,SellerId;Employees:e,EId).groups(e.Dept,e.Gender;sum(o.Amount),count(1)) 1 综合数据处理对比  CSV内容不规范，每三行对应一条记录，其中第二行含三个字段（即集合的集合），将该文件整理成规范的结构化数据对象，并按第3和第4个字段排序.  Kotlin:  data class Order(var OrderID: Int,var Client: String,var SellerId: Int, var Amount: Double, var OrderDate: Date) var Orders=ArrayList() var sdf = SimpleDateFormat("yyyy-MM-dd") var raw=File("d:\\threelines.txt").readLines() raw.forEachIndexed{index,it-> if(index % 3==0) { var f234=raw[index+1].split("\t") var r=Order(raw[index].toInt(),f234[0],f234[1].toInt(),f234[2].toDouble(), sdf.parse(raw[index+2])) Orders.add(r) } } var result=Orders.sortedByDescending{it.Amount}.sortedBy{it.SellerId} Koltin在数据处理方面专业性不足，大部分功能要硬写代码，包括按位置取字段、从集合的集合取字段。  Scala：  val raw=spark.read.text("D:/threelines.txt") val rawrn=raw.withColumn("rn", monotonically_increasing_id()) var f1=rawrn.filter("rn % 3==0").withColumnRenamed("value","OrderId") var f5=rawrn.filter("rn % 3==2").withColumnRenamed("value","OrderDate") var f234=rawrn.filter("rn % 3==1") .withColumn("splited",split(col("value"),"\t")) .select(col("splited").getItem(0).as("Client") ,col("splited").getItem(1).as("SellerId") ,col("splited").getItem(2).as("Amount")) f1.withColumn("rn1",monotonically_increasing_id()) f5=f5.withColumn("rn1",monotonically_increasing_id()) f234=f234.withColumn("rn1",monotonically_increasing_id()) var f=f1.join(f234,f1("rn1")===f234("rn1")) .join(f5,f1("rn1")===f5("rn1")) .select("OrderId","Client","SellerId","Amount","OrderDate") val result=f.orderBy(col("SellerId"),-col("Amount")) Scala在数据处理方面更加专业，大量使用结构化计算函数，而不是硬写循环代码。但Scala缺乏有序计算能力，相关的功能通常要添加序号列再处理，导致整体代码冗长。 SPL:  A 1    =file("D:\\data.csv").import@si() 2    =A1.group((#-1)\3) 3    =A2.new(~(1):OrderID, (line=~(2).array("\t"))(1):Client,line(2):SellerId,line(3):Amount,~(3):OrderDate ) 4    =A3.sort(SellerId,-Amount) SPL在数据处理方面最专业，只用结构化计算函数就可以实现目标。SPL支持有序计算，可以直接按位置分组，按位置取字段，从集合中的集合取字段，虽然实现思路和Scala类似，但代码简短得多。  应用结构 Java应用集成  Kotlin编译后是字节码，和普通的class文件一样，可以方便地被Java调用。比如KotlinFile.kt里的静态方法fun multiLines(): List，会被Java正确识别，直接调用即可：  java.util.List result=KotlinFileKt.multiLines(); result.forEach(e->{System.out.println(e);}); Scala编译后也是字节码，同样可以方便地被Java调用。比如ScalaObject对象的静态方法def multiLines():DataFrame，会被Java识别为Dataset类型，稍做修改即可调用：  org.apache.spark.sql.Dataset df=ScalaObject.multiLines(); df.show(); SPL提供了通用的JDBC接口，简单的SPL代码可以像SQL一样，直接嵌入Java：  Class.forName("com.esproc.jdbc.InternalDriver"); Connection connection =DriverManager.getConnection("jdbc:esproc:local://"); Statement statement = connection.createStatement(); String str="=T(\"D:/Orders.xls\").select(Amount>1000 && Amount<=3000 && like(Client,\"*s*\"))"; ResultSet result = statement.executeQuery(str); 的SPL代码可以先存为脚本文件，再以存储过程的形式被Java调用，可有效降低计算代码和前端应用的耦合性。  Class.forName("com.esproc.jdbc.InternalDriver"); Connection conn =DriverManager.getConnection("jdbc:esproc:local://"); CallableStatement statement = conn.prepareCall("{call scriptFileName(?, ?)}"); statement.setObject(1, "2020-01-01"); statement.setObject(2, "2020-01-31"); statement.execute(); SPL是解释型语言，修改后不用编译即可直接执行，支持代码热切换，可降低维护工作量，提高系统稳定性。Kotlin和Scala是编译型语言，编译后必须择时重启应用。  开源是每个程序员的精神，大家可以一起交流学习  交互式命令行  Kotlin的交互式命令行需要额外下载，使用Kotlinc命令启动。Kotlin命令行理论上可以进行任意复杂的数据处理，但因为代码普遍较长，难以在命令行修改，还是更适合简单的数字计算：  >>>Math.sqrt(5.0) 2.236.6797749979 Scala的交互式命令行是内置的，使用同名命令启动。Scala命令行理论上可以进行数据处理，但因为代码比较长，更适合简单的数字计算：  scala>100*3 rest1: Int=300 SPL内置了交互式命令行，使用“esprocx -r -c”命令启动。SPL代码普遍较短，可在命令行进行简单的数据处理。  (1): T("d:/Orders.txt").groups(SellerId;sum(Amount):amt).select(amt>2000) (2):^C D:\raqsoft64\esProc\bin>Log level:INFO 1       4263.900000000001 3       7624.599999999999 4       14128.599999999999 5       26942.4 ———————————————— 版权声明：本文为CSDN博主「程序员springmeng」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/mengchuan6666/article/details/126616736 

近日，在 “2022 IDC中国数字金融论坛”上，国际权威咨询机构IDC联合蚂蚁集团正式发布了《十大风控技术趋势指南》白皮书。这是风控行业技术创新的一次风向标，也意味着和黑灰产对抗中技术升级迫在眉睫。当今的商业模式已不同于往昔，随着数字化进程的进一步加快，金融机构必须要时刻为可能出现的业务风险做好准备。面对正在走向无边界和强对抗的新型重大风险，金融机构如何与之博弈，并始终领先一步？这正是“ IDC《十大风控技术趋势指南》”将深入探讨的议题。数字支付激增 新型风险类型相伴相生新冠疫情算得上数字化发展的一个“加速器”，但其实早在疫情出现之前，数字服务领域已经有了大规模的转型：从线上互动，到数字支付，再到依托于数字平台而生的新服务。疫情的出现加速了这一趋势，加速的势头预计将保持到2030年。图1数据显示，2020年到2025年，全球消费者数字支付市场预计增长2.2倍，而在2025到2030年期间，上涨幅度预计将进一步增至3.4倍。数字化世界的机遇和潜力巨大，但也充满了风险。随着企业加速运营调整以应对数字化进程，这种激增的趋势带来了明显的合规风险和业务风险，让黑产有机可乘。IDC的一项研究表明，相较于2020年，在2021年，亚太地区52%的企业因遭遇诈骗而蒙受的损失上涨了至少5%，26%的企业损失上涨了至少11%。由于支付管控不力及降低风险手段的不到位，欺诈活动现在越来越猖獗。黑灰产的欺诈手法正在不断升级，欺诈套路也变得越来越复杂。值得关注的十大新技术能力面对快速变化的欺诈发展形势，传统降低风险的做法和欺诈检测工具是否能及时应对？如果不采用新的工具和技术，企业是否能够安然地扩大其数字化业务的规模？现有的基础设施是否能够支撑企业分析海量数据、检测欺诈，尤其是新型欺诈？对于亚太地区的银行、商家、支付公司和其他金融机构来说，这些问题的答案可能都是否定的。本节中，我们将重点说明十项科技趋势，凭借这些能力，金融机构才能够有机会实现可信的智能黑灰产对抗。01 人工智能，风控能力提升的基础预计到2025年，银行业还将再投入约310亿美元用于在现有系统中嵌入人工智能技术。在接受调查的100位来自全球银行业的高管中，多数人表示他们会将欺诈管理作为重点，其中，有些银行在与欺诈相关的场景用例中已经应用了人工智能，包括开户欺诈（57%）、支付欺诈检测（57%）、欺诈操作和调查（53%）还有反洗钱监测（46%）。自2022年开始，人工智能将成为打击欺诈活动的一个重要基础能力，人工智能将有效缩短决策时间，在7*24小时的全天候业务中，帮助实现客户快捷、无缝的交易体验，同时确保决策的准确性。02 威胁情报的挖掘技术， 为风险防控提供有效依据IT安全解决方案不胜枚举，而市场仍然对多种威胁情报有强烈需求。因此基于巡检技术的胁情报挖掘和分享能够持续为金融机构提供与新型威胁、欺诈迹象相关的信息。金融机构需要对这些情报进行审查，同时记录不同威胁情报效率和准确度得分，以便更好地了解不同的线索，进而指导对各种威胁的检测、识别、调查和处理。黑灰产通常不会只在一个平台犯案，因此威胁情报对金融机构来说至关重要，例如亚太地区的许多银行协会，他们会定期分享他们感知到的威胁情报，并和行业分享应对举措。对金融机构来说，你得到的情报越多越准确，就越有可能在风险防控中领先于黑灰产。03 全图风控， 实现动态可视事实风险挖掘金融风险决策是一个不断对抗升级的过程，从单一事件和孤立行为来分析无法获得准确决策。随着大规模图计算技术的发展，风险防控将从单一时间切片的图数据，走向基于时序的图数据，该防控方式将有效沉淀如账户盗用、电信网络诈骗、套利等风险特征，通过知识表征推理发现更多稀薄关系和隐藏风险，结合规则推理、规则挖掘与规则学习挖掘更多风险模式并有效泛化，让风险知识和实时交易事件联动实现动态图推理，形成全局的洞察，构建实时监控体系。基于大规模图技术的全图风控能够支持千亿级的金融风险知识图谱，进而为管理者们提供全面、可见、动态、实时的交易风险概览，使他们能够监测风险并及时决策。04 高效的算力体系，为精准流畅风险防控提供算力支撑交易和互动的数量、频率都在急剧增长，随之而来的是数据的激增，企业几乎要被海量的数据所淹没。此外，消费者设备、支付渠道、5G网络、物联网等也在不断产生新的数据。现在，企业所面临的挑战是通过分析从不同来源（结构化和非结构化）收集到的数据，从而发现欺诈的线索。然而，生成的大量数据可能会使存储和处理的环节负担过重，进而让不法分子有机可乘，组织比如跨境洗钱、非法交易等网络犯罪。一旦处理和分析数据的机制存在缺陷的话，那么虚假交易的中间人就很可能“隐身”其中，为了能够实时、准确地检测到欺诈行为，只有将传统的架构转为云计算和多节点高效算力体系，才能利用更高的计算效率来支撑人工智能/机器学习的计算需求。05 极速风控，实现更快的实时风险决策欺诈检测的实效性对金融机构来说至关重要，分析决策环节的每一秒延时都会降低用户体验，也让金融机构和用户增加一份资损的风险。在登录、交易支付、验证检查或用户验证等环节，实时决策的能力有赖于风险情报的收集和风控系统强大的分析和计算能力，而如何解决大规模风险数据计算中的耗时问题是行业面临的一大挑战。极速风控通过预测的方式将风险识别和风险决策进行解耦，通过提前风险计算，提高决策时的风险判断效率，实现毫秒级的实时风险决策。06 主动式风控， 在即时响应基础上主动出击传统的风险管理解决方案大都是被动的“事后应对”：即在不利事件发生后，基于已有信息做出判断，采取保护性行动，以便之后能够及时应对类似的攻击。但这还远远不够，尤其是面对技术越来越好、作案手段不断演进的欺诈团伙。随着人工智能及其相关技术的发展，企业主动应对潜在的风险变得可能，例如通过主动和用户产生交互，来获得更多的风险信息，帮助平台做更好的风险判断，同时给到用户更好的安全服务。以本人授权的被诈骗支付为例，传统的风险管理系统仅能在检测到风险后限制或冻结交易；而现在，系统能够在发现潜在风险后，以图文提示、电话等多模态交互方式进一步确认风险，提醒用户主动意识到欺诈风险。07 端云协同，提高计算效能保护用户隐私随着企业越来越重视隐私保护和用户体验，传统的风险防控将面临全新的挑战，为了应对隐私保护和用户体验的挑战，端云协同的方案应运而生。受海量流媒体数据的驱动，企业需要让数据处理环节更靠近数据的来源，以进一步降低延迟、加快决策，减少个人数据的传输。通过端云协同的风控方案，企业可以让隐私数据计算在用户智能终端（如手机）中进行，将不含隐私信息的决策结果输送到云端，以实现“端云协同”的风控保障。08 多方风控，确保安全的跨机构协作数字化世界愈加互联互通，但很多时候，即使一家公司内的风险数据都没有被整合，更不用说行业间风险数据的互联互通。基于此，多方风控技术已在广泛试点使用，不但让多方在共同应对欺诈时实现数据、模型和分析结果的共享，而无需牺牲数据隐私或数据集的质量。有了这一更高效的协作方式，多方均可提升自身在鉴别和应对风险方面的能力。多方风控主要由区块链及隐私计算技术支撑，比如可信执行环境（TEE）， 多方安全计算和联邦学习，使得不同的机构能够在数据隐私得到极好保护的前提下进行风险数据共享，甚至联合建模。因此，为应对连通性风险，各商家、银行和第三方支付机构之间的“互联互通”十分必要，同时，还须保证这种“互联互通” 的安全性。09 可信AI，智能风控系统的安全基础人工智能（AI）的应用是风险管理中出现的新常态。但是，AI不仅仅可以为好人所用，也可以被黑灰产作为突破口，或者攻击武器。由于风险防控是一场和犯罪团伙的竞速赛，企业必须开始考虑他们以人工智能驱动的风险防控系统是否足够稳健、可靠，能够扛得住黑灰产的攻击。这时对抗智能就变得尤为重要，它建立在经济学的博弈论框架之上，通过模拟攻击者和防御者之间的冲突，让机器自动且实时、动态地对自身系统进行安全性攻击，从而提升模型能力，使模型更加鲁棒（robust），处理结果更加准确。先进的欺诈管理解决方案已经采用了对抗智能技术，以提升人工智能模型的稳健性，此涉及的技术很多，包括像防御性的对抗性权重扰动（AWP）、投影梯度下降（PGD）等概念和技术。在智能数字化服务中，我们必须尽可能地严格看待人工智能/ 机器学习模型所做出的决策。如果人工智能/ 机器学习的决策是基于不完整、低质量、非客观的数据集，通过错误的建模方式和错误的变量集而做出的，在未来可能会引发了诸多争议。因此，企业应当建立一个值得信赖、可靠且可追溯的AI安全框架，来更好地管理AI相关风险。尽管AI构成了应对复杂欺诈案件的解决方案，但如果没有恰当的AI治理框架，AI也可能会影响用户体验甚至是破坏品牌声誉。AI模型的安全性也需要保护，因为它们也可能会被那些有技术团队的专业作案团伙所破坏。10 用户行为分析（UBA），将变得愈加重要金融机构在行为分析方面的投资正在逐年增加，以提升其分析客户资料、互动模式和交易数据的能力，此外，行为分析还能帮助银行发现可疑活动，检测和预防欺诈。多年以来，在IT安全市场上，人们都是在不利事件发生后才想起这一能力，因而直到现在，UBA的相关投资仍相对缺乏；但是，未来对UBA的投资估计不会小。当然，分析的本质决定了对其投入的时间越多，效率越会提升。要想实现有效的UBA，需要花费大量的时间并进行多次的细微调整，同时还需制定一条恰当的路线图。随着时间的推移，企业使用UBA会愈加成熟，逐渐形成自己的反馈回路并获得一系列的结果，根据这些结果，他们可以再进行建模。来源：IDC、蚂蚁集团、蚂蚁技术AntTech

北京，2022年8月30日IDC近日发布了《2022年V2全球大数据支出指南》(IDC Worldwide Big Data and Analytics Spending Guide)。本次发布新增2026年预测数据，从技术、行业、企业规模等维度发掘未来五年（2021-2026）全球大数据市场中的发展趋势和潜在机会，同时对2021年的市场情况进行了梳理。大数据市场概览IDC数据显示，2021年全球大数据市场的IT总投资规模为2,176.1亿美元，并有望在2026年增至4,491.1亿美元，五年预测期内（2021-2026）实现约15.6%的复合增长率（CAGR）。聚焦中国市场，IDC预计，2026年中国大数据IT支出规模预计为359.5亿美元，市场规模位列单体国家第二。从增速的角度来看，中国大数据IT支出五年CAGR约为21.4%，位列全球第一。中国大数据市场增速持续领跑全球，呈现出强劲的增长态势，市场前景广阔。随着数字经济、数字化转型、新基建等投资建设进一步加快，中国终端用户对大数据硬件、软件、服务的需求将稳步扩大。 技术维度IDC预测，到2026年，中国大数据硬件市场IT投资规模将达到137.2亿美元，超过2021年投资规模的两倍。值得关注的是，未来五年，硬件市场仍将是中国大数据市场占比最高的一级子市场，占比规模接近四成。聚焦中国大数据软件市场，2026年大数据软件将成为第二大技术市场。大数据软件以26.9%的五年CAGR强势增长，软件IT投资规模逐年接近硬件市场。其中，人工智能软件平台（AI Software Platforms）市场和终端用户查询、报告和分析（End-User Query, Reporting and Analysis Tools）市场将主导中国大数据软件IT投资，两者共计近软件投资总规模的四成。从增速的角度来看，内容分析（Content Analytics Tools）技术子市场增速亮眼，该市场将以41.1%的五年CAGR快速扩大规模。未来大数据软件市场将发挥承上启下的关键作用，与上下游产品形成耦合榫卯结构。从中国大数据服务市场的角度来看，2026年中国大数据服务市场规模将接近百亿大关。面对全球服务市场增速放缓的大趋势，中国大数据服务市场将以略高于全球平均水平的五年CAGR稳步增长。行业应用从行业终端用户的角度来看，至2026年，专业服务、电信、金融和政府将成为大数据相关IT支出的主力行业。具体而言，专业服务、电信、银行和地方政府将会贡献超过50%的中国大数据IT投资。就增速而言，医疗保健行业将以30.9%的五年CAGR成为增长最快的行业终端用户。此外，专业服务、离散制造、电信等行业也展现出了较大的发展潜力。IDC调研显示，各行业领域企业都在不断探索布局大数据处理分析产品和完整解决方案，文娱、电商、社交等多样式互联网产品服务创新将持续带动市场增长，对于信息化基础较好、数据就绪度较高、市场服务要求更高的电信、金融等行业，平台管理、决策分析等组合型产品市场前景明朗。另外，在政府专项政策推动下，智慧城市、智能制造、智慧医疗、智慧农业等领域也将迎来新的机遇。终端用户企业规模IDC《全球大数据支出指南》将终端用户企业规模由上至下分为了五个区间，从企业规模的维度对大数据支出情况做出进一步透视。和上一版相比，中国大数据市场集中度有所提高。雇员超过1,000人的超大型企业在五年预测期内（2021-2026）占据整个中国市场支出的65%左右，较之前预测小幅上调。中小型企业整体增速较快，但市场占比较小。大数据市场呈现横纵一体化发展格局，大型及超大型企业依托优势数据资源、丰富行业场景经验、高水平信息化技术、规模化服务体系以及较强预算支出能力，表现出较强竞争力。而中小型企业依托核心技术和业务资源优势，在专业化需求上也拥有一定优势。 

10:12    Cannot download sources             Sources not found for:             org.apache.spark:spark-hive_2.11:2.4.5-hw-ei-302002

摘要：SPL实现了更优算法，性能远远超过存储过程，能显著提高单机计算效率，非常适合跑批计算。本文分享自华为云社区《Java开源专业计算引擎：跑批真的这么难吗？》，作者： Java李杨勇。业务系统产生的明细数据通常要经过加工处理，按照一定逻辑计算成需要的结果，用以支持企业的经营活动。这类数据加工任务一般会有很多个，需要批量完成计算，在银行和保险行业常常被称为跑批，其它像石油、电力等行业也经常会有跑批的需求。大部分业务统计都会要求以某日作为截止点，而且为了不影响生产系统的运行，跑批任务一般会在夜间进行，这时候才能将生产系统当天产生的新明细数据导出来，送到专门的数据库或数据仓库完成跑批计算。第二天早上，跑批结果就可以提供给业务人员使用了。和在线查询不同，跑批计算是定时自动执行的离线任务，不会出现多人同时访问一个任务的情况，所以没有并发问题，也不必实时返回结果。但是，跑批必须在规定的窗口时间内完成。比如某银行的跑批窗口时间是晚上8:00到第二天早上7:00，如果到了早上7:00跑批任务还没有完成，就会造成业务人员无法正常工作的严重后果。跑批任务涉及的数据量非常大，很可能用到所有的历史数据，而且计算逻辑复杂、步骤众多，所以跑批时间经常是以小时计的，一个任务两三小时是家常便饭，跑到十个小时也不足为奇。随着业务的发展，数据量还在不断增加。跑批数据库的负担快速增长，就会发生整晚都跑不完的情况，严重影响用户的业务，这是无法接受的。问题分析要解决跑批时间过长的问题，必须仔细分析现有的系统架构中的问题。跑批系统比较典型的架构大致如下图：从图上看，数据要从生产数据库取出，存入跑批数据库。跑批数据库通常是关系型的，编写存储过程代码完成跑批计算。跑批的结果一般不会直接使用，而是再从跑批数据库中导出，采用接口文件的方式提供给其他系统，或者再导入其他系统数据库。这是比较典型的架构，图中的生产数据库也可能是某个中央数据仓库或者Hadoop等。一般情况下，生产库和跑批库不会是同一种数据库，它们之间往往通过文件的方式传递数据，这样也比较有利于降低耦合度。跑批计算完成后，结果要给多个应用系统使用，一般也都是以文件方式传递。跑批很慢的第一个原因，是用来完成跑批任务的关系数据库入库、出库太慢。由于关系数据库的存储和计算能力具有封闭性，数据的进出要做过多的约束检查和安全处理，当数据量较大时，写入读出的效率非常低，耗时会非常长。所以，跑批数据库导入文件数据的过程，以及跑批计算结果再导出文件的过程都会很慢。跑批很慢的第二个原因，是存储过程性能差。由于SQL的语法体系过于陈旧，存在诸多限制，很多高效的算法无法实施，所以存储过程中的SQL语句计算性能很不理想。而且，业务逻辑比较复杂的时候很难用一个SQL实现，经常要分成多个步骤，用十几甚至几十个SQL语句才能完成。每个SQL的中间结果，都要存入临时表给后续步骤的SQL使用。临时表数据量较大时就必须落地，会造成大量的数据写出。而数据库的写出要比读入性能差很多，会严重拖慢整个存储过程。对于更复杂的计算，甚至很难用SQL语句直接实现，需要用数据库游标遍历取出数据，循环计算。但数据库游标遍历计算性能又要比SQL语句差很多，一般也都不直接支持多线程并行计算，很难利用多CPU核的计算能力，会让计算性能更加糟糕。那么，是否可以考虑用分布式数据库来代替传统关系数据库，通过增加节点数量的办法，来提高跑批任务的速度呢？答案仍然是不可行。主要原因是跑批计算的逻辑相当复杂，即使是用传统数据库的存储过程，也常常要写几千甚至上万行代码，而分布式数据库的存储过程计算能力还比较弱，很难实现这么复杂的跑批计算。而且，当复杂计算任务不得不分成多个步骤时，分布式数据库也面临中间结果落地的问题。由于数据可能在不同的节点上，所以前序步骤将中间结果落地，后续步骤再读取的时候，都会造成大量跨网络的读写操作，性能很不可控。这时，也不能采用分布式数据库依靠数据冗余来提升查询速度的办法。这是因为，查询之前可以预先准备好多份冗余数据，但是，跑批的中间结果是临时生成的，如果冗余的话就要临时生成多份，整体的性能只会变得更慢。所以，现实的跑批业务通常仍然是使用大型单体数据库进行，计算强度太大时会采用类似ExaData这样的一体机（ExaData是多数据库，但被Oracle专门优化过，可以看成是个超大型单体数据库）。虽然很慢，但是暂时找不到更好的选择，只有这类大型数据库有足够的计算能力，所以只能用它来完成跑批任务了。SPL用于跑批开源的专业计算引擎SPL提供了不依赖数据库的计算能力，直接利用文件系统计算，可以解决关系数据库出库入库太慢的问题。而且SPL实现了更优算法，性能远远超过存储过程，能显著提高单机计算效率，非常适合跑批计算。利用SPL实现的跑批系统新架构是下面这样的：在新架构中，SPL解决了造成跑批慢的两大瓶颈问题。首先来看数据的入库、出库问题。SPL可以直接基于生产库导出的文件计算，不必再将数据导入到关系数据库中。完成跑批计算后，SPL还能将最终结果直接存储成文本文件等通用格式，传递给其他应用系统，避免了原有跑批数据库的出库操作。这样一来，SPL就省去了关系数据库缓慢的入库、出库过程。下面再来看计算的过程。SPL提供了更优的算法（有许多是业界首创），计算性能远远超过存储过程和SQL语句。这些高性能算法包括：这些高性能算法可以应用于跑批任务中的常见JOIN计算、遍历、分组汇总等，能有效提升计算速度。例如，跑批任务常常要遍历整个历史表。有些情况下，对一个历史表还要遍历好多次，来完成多种业务逻辑的计算。历史表数据量一般都很大，每次遍历都要消耗很多的时间。此时我们可以应用SPL的遍历复用机制，仅对大表遍历一次，就可以同时完成多种计算，可以节省大量时间。SPL的多路游标能做到数据的并行读取和计算，即使是很复杂的跑批逻辑，也可以利用多CPU核实现多线程并行运算。而数据库游标是很难并行的，这样一来，SPL的计算速度常常可以达到存储过程的数倍。SPL的延迟游标机制，可以在一个游标上定义多个计算步骤，之后让数据流按顺序依次完成这些步骤，实现链式计算，能够有效减少中间结果落地的次数。在数据必须落地的情况下，SPL也可以将中间结果存成内置的高性能数据格式，供下一个步骤使用。SPL高性能存储基于文件，采用有序压缩存储、自由列式存储、倍增分段、自有压缩编码等技术，减少了硬盘占用，读写速度要远远好于数据库。应用效果SPL在技术架构上打破了关系型跑批数据库存在的两大瓶颈，在实际应用中也取得了非常好的效果。L 银行跑批任务采用传统架构，以关系数据库作为跑批数据库，用存储过程编程实现跑批逻辑。其中，贷款协议存储过程需要执行 2 个小时，而且是很多其他跑批任务的前序任务，耗时这么久，对整个跑批任务造成了严重影响。采用SPL后，使用高性能列存、文件游标、多线程并行、小结果内存分组、游标复用等高性能算法和存储机制，将原来2个小时的计算时间缩短为10分钟，性能提高12倍。而且，SPL代码更简洁。原存储过程3300多行，改为SPL后，仅有500格语句，代码量减少了6倍多，大大提高了开发效率。P保险公司的车险业务中，需要用往年历史保单来关联新的保单，在跑批中称为历史保单关联任务。原来也采用关系数据库完成跑批，存储过程计算10天的新增保单关联历史保单，运行时间47分钟；30天则需要112分钟，接近2小时；如果日期跨度更大，运行时间就会长的无法忍受，基本就变成不可能完成的任务了。采用SPL后，应用了高性能文件存储、文件游标、有序归并分段取出、内存关联和遍历复用等技术，计算10天新增保单仅需13分钟；30天新增保单只需要17分钟，速度提高了近7倍。而且，新算法执行的时间随着保单天数的增长并不是很大，并没有像存储过程那样成正比的增长。从代码总量来看，原来存储过程有2000行代码，去掉注释后还有1800多行，而SPL的全部代码只有不到500格，不到原来的1/3。T银行通过互联网渠道发放贷款的明细数据，需要每天执行跑批任务，统计汇总指定日期之前的所有历史数据。跑批任务采用关系数据库的SQL语句实现，运行总时间7.8小时，占用了过多的跑批时间，甚至影响了其他的跑批任务，必须优化。采用SPL后，应用了高性能文件、文件游标、有序分组、有序关联、延迟游标、二分法等技术，原来需要7.8小时的跑批任务，单线程仅需180秒，2线程仅需137秒，速度提高了204倍。

鲲鹏920服务器，1台NameNode， 3台DataNode，Hadoop 3.3.1 使用官网 aarch64包 cid:link_0works配置正确，副本数设置为3.进行dfs write测试时会报如下错误（使用Hadoop 2.6不会），求解决方法： 2022-08-25 10:21:38,080 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* allocate blk_1073743798_2974, replicas=10.10.10.4:9866, 10.10.10.3:9866 for /benchmarks/TestDFSIO/io_control/in_file_test_io_1973 2022-08-25 10:21:38,082 INFO org.apache.hadoop.hdfs.StateChange: DIR* completeFile: /benchmarks/TestDFSIO/io_control/in_file_test_io_1973 is closed by DFSClient_NONMAPREDUCE_-1180995040_1 2022-08-25 10:21:38,083 INFO org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Not enough replicas was chosen. Reason: {NO_REQUIRED_STORAGE_TYPE=1} 2022-08-25 10:21:38,083 INFO org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Not enough replicas was chosen. Reason: {NO_REQUIRED_STORAGE_TYPE=1} 2022-08-25 10:21:38,083 INFO org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Not enough replicas was chosen. Reason: {NO_REQUIRED_STORAGE_TYPE=1} 2022-08-25 10:21:38,083 WARN org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to place enough replicas, still in need of 1 to reach 3 (unavailableStorages=[], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true) For more information, please enable DEBUG log level on org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy and org.apache.hadoop.net.NetworkTopology 2022-08-25 10:21:38,083 WARN org.apache.hadoop.hdfs.protocol.BlockStoragePolicy: Failed to place enough replicas: expected size is 1 but only 0 storage types can be selected (replication=3, selected=[], unavailable=[DISK], removed=[DISK], policy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}) 2022-08-25 10:21:38,083 WARN org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to place enough replicas, still in need of 1 to reach 3 (unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true) All required storage types are unavailable:  unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]} 2022-08-25 10:21:38,083 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* allocate blk_1073743799_2975, replicas=10.10.10.4:9866, 10.10.10.3:9866 for /benchmarks/TestDFSIO/io_control/in_file_test_io_1974 2022-08-25 10:21:38,085 INFO org.apache.hadoop.hdfs.StateChange: DIR* completeFile: /benchmarks/TestDFSIO/io_control/in_file_test_io_1974 is closed by DFSClient_NONMAPREDUCE_-1180995040_1

大佬们好，我们再对接华为大数据平台【FusionInsight Manager】时出现了一下问题问题描述：我们设计的Yarn任务提交设计以下几个步骤：检测 Yarn执行资源是否充足   【成功】QueueInfo queueInfo = yarnClient.getQueueInfo(amClientContext.getQueueName());设置yarn运行相关信息【成功】//部分代码 appContext.setApplicationName(amClientContext.getAppName()); appContext.setAttemptFailuresValidityInterval(20000); Set tags = new HashSet<>(1); tags.add("ddmp"); appContext.setApplicationTags(tags); ApplicationId appId = appContext.getApplicationId();上传待运行的任务至HDFS 【成功】 以下是部分代码，上传资源，包括设置yarn执行相关的环境变量，将AppMaster任务信息设置好/** * 添加一个本地资源到远程 * * @param fs 文件系统 * @param fileSrcPath 要上传的文件 * @param fileName 文件名 * @param appId 应用id * @param localResources 本地文件资源映射 * @param resources 文件资源 ,有时候我们并没有实际的资源信息，只有一个类似于命令操作，如果我们想将该命令生成一个文件并上传，就可以将该命令写在这里 * @throws IOException 异常信息 */ private void addToLocalResources(String appName, FileSystem fs, String fileSrcPath, String fileName, String appId, Map localResources, String resources) throws IOException { //获取要上传的目录路径 String suffix = appName + "/" + appId + "/" + fileName; Path dst = new Path(fs.getHomeDirectory(), suffix); //当要上传的文件不存在的时候 尝试将 resources 文件写入到一个目录中 if (fileSrcPath == null) { FSDataOutputStream ostream = null; try { //赋予 可读,可写,可执行的权限 ostream = FileSystem.create(fs, dst, new FsPermission((short) 456)); ostream.writeUTF(resources); } finally { IOUtils.closeStream(ostream); } } else { //将要上传的文件拷贝到对应的目录中 fs.copyFromLocalFile(new Path(fileSrcPath), dst); } //获取刚刚上传的文件的状态 FileStatus scFileStatus = fs.getFileStatus(dst); //创建一个本地资源映射 hdfs URI uri = dst.toUri(); URL url = URL.fromURI(uri); long len = scFileStatus.getLen(); long modificationTime = scFileStatus.getModificationTime(); LocalResource scRsrc = LocalResource.newInstance(url, LocalResourceType.FILE, LocalResourceVisibility.APPLICATION, len, modificationTime); //放入到资源映射中 localResources.put(fileName, scRsrc); }提交AppMaster任务到Yarn引擎 【失败】// 为应用程序主机设置容器启动上下文 ContainerLaunchContext amContainer = ContainerLaunchContext.newInstance(localResourceMap, env, commands, null, null, null); //权限处理 securityCheck(amContainer, amClientContext); //将容器设置进上下文对象 appContext.setAMContainerSpec(amContainer); //配置任务优先级状态 Priority pri = Priority.newInstance(0); appContext.setPriority(pri); //配置队列名称 appContext.setQueue(amClientContext.getQueueName()); yarnRunCallHook.doMessage("任务准备完成，开始提交任务！"); yarnClient.submitApplication(appContext);程序再运行到 yarnClient.submitApplication(appContext); 时执行卡住，通过日志观察，出现一下日志：48833 [main] INFO org.apache.hadoop.io.retry.RetryInvocationHandler - com.google.protobuf.InvalidProtocolBufferException: Protocol message end-group tag did not match expected tag., while invoking ApplicationClientProtocolPBClientImpl.getApplicationReport over 27. Trying to failover immediately. 48833 [main] INFO org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider - Failing over to 28 49849 [main] INFO org.apache.hadoop.io.retry.RetryInvocationHandler - java.net.ConnectException: Call From DESKTOP-BTSFCSH/10.0.55.152 to 10-0-120-162:26004 failed on connection exception: java.net.ConnectException: Connection refused: no further information; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused, while invoking ApplicationClientProtocolPBClientImpl.getApplicationReport over 28 after 1 failover attempts. Trying to failover after sleeping for 35465ms. 85315 [main] INFO org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider - Failing over to 27 85366 [main] INFO org.apache.hadoop.io.retry.RetryInvocationHandler - com.google.protobuf.InvalidProtocolBufferException: Protocol message end-group tag did not match expected tag., while invoking ApplicationClientProtocolPBClientImpl.getApplicationReport over 27 after 2 failover attempts. Trying to failover after sleeping for 30581ms.请重点关注 Protocol message end-group tag did not match expected tag. 连接主节点的时候，出现协议不一致的问题连接信息如下：fs.defaultFS=hdfs://hacluster yarn.resourcemanager.address.27=10-0-120-161:26004 yarn.resourcemanager.address.28=10-0-120-162:26004 yarn.resourcemanager.ha.rm-ids=27,28 dfs.client.failover.proxy.provider.hacluster=org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider yarn.resourcemanager.scheduler.address.28=10-0-120-162:26002 dfs.nameservices=hacluster yarn.resourcemanager.scheduler.address.27=10-0-120-161:26002 dfs.namenode.rpc-address.hacluster.14=10-0-120-161:25000 dfs.namenode.rpc-address.hacluster.15=10-0-120-162:25000 yarn.resourcemanager.ha.enabled=true yarn.resourcemanager.recovery.enabled=true yarn.log-aggregation-enable=true dfs.ha.namenodes.hacluster=14,15 yarn.http.policy=HTTPS_ONLYFusionInsight Manager 已经开启Kereros,再本次提交中，kerberos认证已经通过 以上配置信息来自于 FusionInsight Manager 配置，确认端口信息等无误！以下是引入的Maven依赖 3.1.1 1.3.1 3.1.0 8 8 org.apache.hadoop hadoop-common ${hadoop.version} org.apache.hadoop hadoop-client ${hadoop.version} org.apache.hadoop hadoop-mapreduce-client-app ${hadoop.version} org.apache.hadoop hadoop-mapreduce-client-common ${hadoop.version} org.apache.hadoop hadoop-mapreduce-client-core ${hadoop.version} org.apache.hbase hbase-client ${hbase.version} org.apache.hbase hbase-common ${hbase.version} org.apache.hbase hbase-protocol ${hbase.version} org.apache.hbase hbase-server ${hbase.version} org.apache.hive hive-jdbc ${hive.version} org.apache.hive hive-service ${hive.version} 上述依赖，模仿华为云大数据平台 客户端案例的依赖！

伴随着科技的飞速发展，人工智能逐渐进入日常生活的各个方面。而大数据技术的研究和发展，则更推动技术的革新和社会经济的变革。大数据技术的出现背景、发展历程、研究现状以及发展过程中的存在问题是什么？同时在人工智能领域的大数据技术的发展又有哪些应用场景？让我们一起去探索。大数据的起源和发展随着互联网的广泛运用，云计算时代已经逐渐步入人们的生活，大数据在此背景下应运而生。1982年，约翰·奈斯比特在其著作中提出“我们现在大量生产信息，正如过去我们大量生产汽车一样”；阿尔文·托夫勒在《第三次浪潮》一书中，称大数据为“第三次浪潮的华彩乐章”；面对海量的数据，原有的处理方式已无法应对。2011年，麦肯锡全球研究所发布了《大数据：创新、竞争和生产力的下一个前沿》的报告，对“大数据”进行清晰解释；2012年，瑞士达沃斯召开世界经济论坛，大数据是会议主题。大数据发展起始于18世纪80年代初至90年代末，统计学家赫尔曼做出一台电动设备来统计美国本土人口普查数据，揭开数据处理新时代。雷德和普赖斯分别在1944年和1961年出版了《学者与研究型图书馆的未来》和《巴比伦以来的科学》，预测大数据时代的到来。2001年，美国Cartner公司推出大数据模型。2008年，美国自然杂志出版的一期专刊中第一次提出大数据——Big Data模型。大数据技术研究现状在国外，大数据技术被认为源于谷歌，在2003至2006年先后公开发表关于MapReduce、GFS和BigTable等核心技术学术论文。2012年，美国白宫颁布了《大数据研究与发展计划》，投入巨资到大数据研究领域。美国防部还开展XDATA项目，将大数据研究投入军事领域数据分析。在国内，2013年被称为大数据元年。2014年，国内众多互联网企业如小米、百度、腾讯、阿里等已将大数据技术应用于公司业务。大数据技术存在问题大数据技术的发展对各行各业也有重大影响，同时大数据技术的研究目前还不够完善，也面临着诸多问题需要去解决。（1）数据分析和处理问题。传统数据处理方式适用于少量的、结构化数据，而生活中采集的大多数数据是非结构化的数据，这就对数据分析和处理过程产生很大的影响。MapReduce计算并不能解决大数据处理的所有问题，需要更深层次的研究，解决数据处理的局限性。（2）数据安全和隐私问题。伴随着海量数据的采集和处理，数据的安全和数据的隐私问题应运而生。如何能够保障被采集数据的安全性、数据本身的隐私保护，都将是今后大数据技术研究的重点问题。现今社会就存在许多用户数据信息被盗用或者共享公开化等情况，这样对用户的人身和财产安全都产生很大的威胁。（3）政策和法规保障问题。面对大数据飞速发展的今天，国家缺乏相应监管体系，致使大数据滥用后用户的个人权益无法得到有效保障，国家应该建立相应的法律体系，对大数据的收集、开发和利用进行严格管理，同时对数据的正确使用设置规范和标准，推动大数据发展的规范化、合法化。大数据技术在人工智能领域的应用大数据技术在人工智能领域的应用广泛，涉及智慧农业、智慧城市、智慧工业等诸多方面[。智慧农业，大数据技术结合人工智能技术，收集海量数据信息进行处理分析，建立起精准农业、农产品流通体系、农业气象预测、农业环境管理等多个系统，推动农业的生产。智慧农业的提出使得很多技术可以整合使用，通过对土壤数据信息的采集，对土地耕作环境的监控，密切关注着温度、湿度的变化，并及时反馈监测的数据信息，预测出今后发展的方向。智慧城市，大数据技术应用于城市建设，建立城市数据信息共享平台，实时监管交通状况系统、智慧社区服务平台、城市地下排水监控系统等，推动城市智能化管理。智慧城市的格局要以网络化覆盖为基础，涵盖公共、卫生、交通、社区服务、社会保障等诸多方面，每一个环节都有相应的系统进行建构网络，然后通过各环节的相互配合去建造智慧城市格局。智慧工业，大数据技术促进工业“跨尺度、产业链、跨界”多源数据融合特点，推动工业化的智能管理和产量提升。工业化的进程在大数据技术的协助下，可以有效进行数据规整，对工业流程数据进行密切监控，确保产品生产环节精确度更高。当今时代是大数据的时代，大数据的合理使用将推动生产、生活的方方面面。大数据的发展和革新还在不断地发生改变，与此同时对大数据处理技术的研究也一直从未间断。然而，目前大数据的研究还处于初级阶段，很多技术不够完善，也存在着诸多问题，面临着巨大的挑战。伴随着智能化时代的来临，人工智能与大数据技术的结合将是今后大数据发展研究的重要主题。

推荐学习顺序：请知：编号顺序相同的可并行学习；知识图谱：课程链接：组件名称组件介绍链接Manager华为FusionInsight HD是一个分布式数据处理系统，对外提供大容量的数据存储、查询和分析能力基础知识安装教程运维知识HBaseHBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为 Java。它是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，为 Hadoop 提供类似于BigTable 规模的服务。基础串讲+运维知识最佳实践KafkaKafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。 该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。基础串讲+运维知识最佳实践HiveHive 是一个架构在 Hadoop 之上的数据仓库基础工具，它可以处理结构化和半结构化数据，它使得查询和分析存储在 Hadoop 上的数据变得非常方便基础串讲+运维知识最佳实践SparkApache Spark 是一种用于大数据工作负载的分布式开源处理系统。它使用内存中缓存和优化的查询执行方式，可针对任何规模的数据进行快速分析查询。基础串讲+运维知识最佳实践FlinkApache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。基础串讲+运维知识最佳实践

       在大数据背景下，数据库安全保障体系的构建对于有效防范信息安全事件发生具有重要意义。该文首先分析了大 数据背景下数据库系统的安全威胁问题，然后介绍了几种网络安全的新技术，包括身份认证技术、访问控制技术等，最后 阐述了数据库安全保障体系的构建路径，希望为进一步解决大数据背景下的数据库安全问题提供支持。 现阶段大数据产业的快速发展创造了极大的经济效益，大数据的出现推动了社会经济发展，但是随之而来的数据库安全问题也引起了学者对大数据信息安全问题的反思。大数据时代下的信息与隐私安全问题已经成为全球性重点关注的问题，为了能够更有效地避免数据安全问题发生，需要相关人员积极构建数据库安全保障体系。1  数据库的安全威胁问题研究      数据库的信息安全问题得到了社会的普遍关注，从现有的数据库网络安全事件来看，其信息安全问题的风险具有范围广、影响大、突发性强等特征，并且可能产生严重的损失。与传统的攻击行为相比，数据库的网络安全问题呈现出以下特征：（1）高技术性与高智能性特征。例如部分不法分子为了能够盗取数据库中的资料，会采用各种手段穿越防火墙，通过不断地攻击数据库的安全防护体系或注入SQL等方法篡改数据，导致数据大量流失。（2）作案手段日益多样化。在大数据技术的支持下，不法分子威胁数据库的手段也呈现出了多样化的趋势，例如部分人员会运用程序的漏洞进行作案，甚至通过非法用户向管理人员非法授予操作权限的方法进行授权。（3）网络安全问题不受地域与时间因素的显示，不法分子可以随时远程攻击数据库。（4）数据库攻击的隐蔽性较强，收集证据的难度较大。文献认为，数据库作为一种特殊的信息存储结构，在大数据环境下所面临的信息安全隐患问题更加突出，表现为：（1）在网络方面，大部分数据库采用了TCP/IP  的协议通信方式，而该协议本身存在弊端，难以有效鉴别通信双方的身份，导致数据库无法正确识别攻击者的身份而遭到严重破坏。（2）在数据库管理系统上，大部分数据采用了DB2、SQL Server等商用数据库系统，这些数据库系统的技术条件成熟，但是在应用过程中，一些数据库的安全问题发生，例如关于SQL Server数据库的SQL  注入等。虽然现阶段各个厂商都在不断完善数据库等更新补丁包，但是大部分出于对数据库稳定性的考虑，通常会延后补丁的更新速度，最终导致数据库的漏洞难以第一时间被处理，最终成为安全隐患。2  大数据背景下数据库安全技术分析2.1  身份认证技术分析为实现数据库安全对用户的身份进行认证是其中的重点。现阶段常用的数据库普遍采用“ID＋密码”的方式进行身份核实，即将用户的账号信息存储在数据字典等当用户产生连接需求之后，系统能够查询数据字典，并对用户的合法性进行判断。但是在大数据背景下，各种解密技术得到了快速的发展，导致  ID  认证方式面临挑战，因此鉴定人体信息的生物认证安全技术出现，通过语言识别、指纹识别的方法，对用户的身份进行判断。但从现有技术发展情况来看，身份认证技术尚未在数据库安全管理中得到运用，但是鉴于大数据的强大数据处理能力，可预见该技术在未来会具有广阔的发展前景。2.2  访问控制技术访问控制是数据库安全管理的核心内容，能够对规定主体的访问行为进行限制，避免出现任何不满足数据库安全的访问行为发生。2.2.1  自主访问控制目前自主访问控制是数据库信息安全中一种常见的访问控制技术，用户可结合自己的需求对系统的数据进行调整并判断哪些用户能够访问数据库。在此基础上，通过构建自主访问控制模型，能够对访问客体的权限做进一步界定，这样当用户的身份被系统识别后，则可以对客体访问数据库的行为进行监控，用户只能在系统允许的范围内完成操作。作为一种灵活的控制策略，自主访问控制能够保障用户自主地将自己所拥有的权限赋予其他用户，操作过程灵活简单，因此大部分的商业数据库都会采用这种访问控制技术。2.2.2  基于角色的访问控制在数据库安全管理中，基于角色的访问控制作为一种新的控制方法，其主要特征为：在该技术中权限并不是直接赋予指定用户的。所以当用户与特定角色绑定之后，则可以通过将基于角色的访问控制过程进行划分，实现对权限的分配。 2.3 数据加密技术数据加密技术主要包括库内加密与库外加密的方法，其中库内加密是在数据库内部设置加密模块，例如对数据内的相关列表进行加密，而库外加密则是通过特定的加密服务器完成加密与解密操作。在大数据环境下，大部分的数据库都能够提供数据加密功能，例如SQL Server数据库构建的多维度密钥保护与备份信息加密等。但是考虑到数据的特殊性，数据库所存储的信息量较大，在这种情况下可能对数据库的加密与加密的稳定性产生影响，因此用户可根据安全管理要求对数据库中的高度机密的数据做加密处理。3 大数据背景下的数据库安全保障策略分析在大数据背景下，应该围绕信息安全问题落实数据库安全管理方案，以大数据强大的数据处理能力结合数据库的功能诉求对数据库的安全保障方案进行改进。 3.1 角色访问控制策略分析受大数据的影响，数据库的访问人数会快速增加，导致数据库所面临的安全风险更高。因此为了能够进一步保障数据库安全，则需要基于角色访问模型的数据库访问控制，为用户分配数据库角色，最终使用户在数据库上获得相应的权限，进一步提高数据库安全质量。本文基于大数据的技术要求，在数据库安全保障体系的设置上提出了一种新的集中管理模式——基于应用的角色访问模型，该模型能够对数据库的信息安全问题进行有效识别，通过对应用数据库、安全中心的功能进行界定，进而明确数据库安全管理的角色与权限。在实施阶段，其中的重点内容包括： （1）应用方案。在大数据系统中的应用系统中往往会存在大量的账户与用户群，所以在数据库安全保障体系建设中能够将任意一个用户的信息注册到安全中心中，这样数据库可以收录用户权限的有用信息，包括名称、属性、创建时间、应用用途等。 （2）子应用。数据安全管理应用方案需要根据环境进行分类，将数据库中的自应用作为特定类用户的集合，可用于实现数据库的安全管理。例如在数据库安全的子应用中，将DBA作为数据库管理员集合。（3）数据库。这里所提到的数据库为特定数据库，为达到安全管理要求，将数据库注册到系统中并与相关安全软件相绑定，或者在特定的数据库环境下将对应的子应用创设到数据库中。（4）用户。用户的数据安全需要与数据库的账户相连接，在数据库安全管理制定用户所属的子应用，并划分相应的权限即可。 3.2 攻击检测大数据背景下的数据库安全形势严峻，数据库所承受的攻击数量巨大，通过开展攻击检测的方法能够发现滥用与异常的攻击行为。现阶段的大部分数据库都不具有攻击检测功能，所以在安全保障体系的构建中，本文根据技术数据挖掘与数据采集的要求，构建基于攻击检测的数据保全保障体系，通过该方法能够记录数据库被攻击情况，为实现数据库安全奠定基础。实时检测主要是针对各种已知的攻击方式，并将这种攻击以代码的形式存储在数据库中，按照数据库中所记录的数据判断系统是否遭受到攻击。该技术的具有较高的检测精度，但由于该技术无法对内部人员与未知攻击行为进行检测，所以本文在实时检测的基础上进一步完善了其中的功能，包括：（1）登录失败检测。当系统检测到在特定时间段内频繁地出现登录失败的情况，则需要对该IP的用户登录情况进行检测。（2）登录检测。若登录数据库的IP地址与以前登录过的地址不同，则需要警惕数据库安全问题。（3）操作失败检测。针对特定时间内检测到的操作失败次数，检测无访问权限对象的登录行为。（4）用户权限变更检测。其主要功能是检测用户的权限是否在满足规定的情况下进行变更。在该系统中，通过将关于系统安全的规则上传到数据库的审计中心中，再同步到各个数据中，由此实现对滥用规则的统一控制。在实时检测过程中，可在数据库添加两个触发器来完成对攻击的检测，包括：（1）通过DDL触发器来抓取数据库的事物，并检测用户权限变更等情况，作为SQLServer数据库中的一种特有触发器，当数据库发生安全事件的同时能够做出响应，在各种数据库安全事件发生之后快速地捕捉信息并分析安全攻击行为的发生间隔，判断攻击事件是否有效。（2）DML触发器具有跟踪审计信息的功能，针对数据库操作过程中的各种常见问题进行安全评估，包括操作失败事件、登录失败情况以及敏感用户对系统的访问等。当DML 检测到数据库遭受到攻击，则会退出攻击账户，保证数据库的安全。 3.3 数据库的安全防护机制在数据库的安全防护中，可利用虚拟化平台来实现数据库的安全管理，为能够达到有效的安全防护目的，可采用以下措施进行数据库安全管理。 3.3.1 数据库的安全备份数据备份的目的就是要为数据安全增添“第二把锁”，当前数据库的数据备份主要采用物理备份与逻辑备份相结合的方法，按照既定的时间要求对数据库中的数据进行存储。此时假设数据遭到攻击或者出现损害时，可以在原数据库的基础上调度备份数据，达到数据快速复原的目的。为实现该目的，可通过MySQL恢复工具、导出数据等方法并引入数据信息的变化，最终有助于实现二进制文件保存，避免备份数据的滥用。 3.3.2 数据库的防火墙设置防火墙是维护数据安全的关键，所以在设置防火墙期间，利用SQL数据库检测到的攻击痕迹将数据与数据库SQL语句运用到应用程序中，利用数据库防火墙的名单检测对任意一个针对数据库的操作行为进行检测，避免系统遭受注入攻击而造成数据损失。4 结束语在大数据背景下，数据库的安全保障管理更加复杂，为了能够更好地适应数据库管理要求，相关人员要充分发挥大数据技术优势，结合各种常见的数据库安全问题进行处置，这样才能有效降低数据库安全事件发生率，最终适应数据安全管理要求。来自：今日头条

【摘要】 随着大数据时代的来临，数据量不断增长，传统小机上跑数据库的模式扩容困难且成本高昂，难以支撑业务发展。很多用户开始转向分布式计算路线，用多台廉价的PC服务器组成集群来完成大数据计算任务。Hadoop/Spark就是其中重要的软件技术，由于开源免费而广受欢迎。经过多年的应用和发展，Hadoop已经被广泛接受，不仅直接应用于数据计算，还发展出很多基于它的新数据库，比如Hive、Impala等。 H...本文分享自华为云社区《Hadoop Spark太重，esProc SPL很轻》，作者：石臻臻的杂货铺。随着大数据时代的来临，数据量不断增长，传统小机上跑数据库的模式扩容困难且成本高昂，难以支撑业务发展。很多用户开始转向分布式计算路线，用多台廉价的PC服务器组成集群来完成大数据计算任务。Hadoop/Spark就是其中重要的软件技术，由于开源免费而广受欢迎。经过多年的应用和发展，Hadoop已经被广泛接受，不仅直接应用于数据计算，还发展出很多基于它的新数据库，比如Hive、Impala等。Hadoop/Spark之重Hadoop的设计目标是成百上千台节点的集群，为此，开发者实现了很多复杂、沉重的功能模块。但是，除了一些互联网巨头企业、国家级通信运营商和大型银行外，大多数场景的数据量并没有那么巨大。结果，经常能看到只有几个到十几个节点的Hadoop集群。由于目标和现实的错位，对很多用户来讲，Hadoop成了一个在技术、应用和成本上都很沉重的产品。技术之重如果真的有几千台计算机组成的集群，是不可能依靠手工个性化管理的。试想，将这些计算机罗列出来，运维人员看都看不过来，更别说管理和分配任务了。再说，这么多机器，难免会不断出现各种故障，怎么保证计算任务顺利执行？Hadoop/Spark的开发者为了解决这些问题，编写了大量代码，用于实现自动化节点管理、任务分配和强容错功能。但是，这些功能本身就要占用很多计算资源（CPU、内存和硬盘等），如果用到几台到十几台节点的集群上，就太过沉重了。集群本来就不大，Hadoop还要占用相当一部分的资源，非常不划算。不仅如此，Hadoop产品线很长，要把这些模块都放在一个平台上运行，还要梳理好各个产品之间的相互依赖性，就不得不实现一个包罗万象的复杂架构。虽然大多数场景只用其中一两个产品，也必须接受这个复杂、沉重的平台。后来出现的Spark弥补了Hadoop对内存利用的不足，技术上是不是可以变轻呢？很遗憾，Spark走向了另一个极端，从理论模型上就只考虑内存计算了。特别是Spark 中的 RDD 采用了 immutable 机制，在每个计算步骤后都会复制出新的 RDD，造成内存和 CPU 的大量占用和浪费，离开大内存甚至无法运行，所以技术上还是很重。使用之重Hadoop技术上太过复杂，也就意味着安装和运维会很麻烦。集群只有几台计算机时，却不得不使用为几千台节点集群设计的节点管理、任务分配和容错功能。可想而知，安装、配置、调试都很困难，日常运行的维护、管理工作也不容易。即使克服这些困难让Hadoop运行起来了，编写大数据计算代码时还会面临更大的麻烦。Hadoop编程的核心框架是MapReduce，程序员要编写并行程序，只要写 Map 和 Reduce 动作即可，用来解决求和、计数等简单问题也确实有效。但是，遇到复杂一些的业务逻辑，用MapReduce编程就会变得非常困难。例如，业务计算中很常见的JOIN计算，就很难用MapReduce实现。再比如，很多和次序有关的运算实现起来也很困难。Spark的Scala语言具备一定的结构化数据计算能力，是不是能简单一些呢？很可惜，Scala使用难度很大，难学更难精。遇到复杂一些的运算逻辑，Scala也很难写出来。MapReduce、Scala都这么难，所以Hadoop/Spark计算语法开始回归SQL语言。Hive可以将SQL转化为MapReduce所以很受欢迎，Spark SQL的应用也比Scala广泛的多。但是，用SQL做一些常规查询还算简单，用于处理多步骤过程计算或次序相关运算还是非常麻烦，要写很复杂的UDF。而且，许多计算场景虽然勉强能用SQL实现，但是计算速度却很不理想，也很难进行性能调优。成本之重虽然 Hadoop 软件本身开源免费，但它技术复杂、使用困难，会带来高昂的综合成本。前面说过，Hadoop自身会占用过多的CPU、内存和硬盘，而Spark需要大内存支撑才能正常运行。所以不得不为Hadoop/Spark采购更高配置的服务器，要增加硬件支出。Hadoop/Spark使用困难，就需要投入更多的人力去完成安装、运维，保证Hadoop/Spark的正常运转；还要投入更多的开发人员，编程实现各种复杂的业务计算，要增加人力资源成本。由于使用过于困难，很多用户不得不采购商业公司的收费版本Hadoop/Spark，价格相当可观，会大幅增加软件采购成本。既然Hadoop如此沉重，为什么还有很多用户会选择它呢？答案很简单：暂时找不到别的选择，也只有Hadoop勉强可用，好歹知名度高一些。如此一来，用户就只能安装、配置Hadoop的重型应用，并忍受Hadoop本身对计算资源的大量消耗。小规模集群的服务器数量本来就不多，Hadoop又浪费了不少，小马拉大车，最后运行的效果可想而知。花了大价钱采购、费事费力的使用Hadoop，实际计算的性能却不理想。就没有别的选择了？轻量级的选择开源的esProc SPL是轻量级大数据计算引擎，采用了全新的实现技术，可以做到技术轻、使用简单、成本低。技术轻本文开头说过，越来越大的数据量让传统数据库撑不住，所以用户只能转向分布式计算技术。而数据库之所以撑不住，是因为SQL难以实现高速算法，大数据运算性能只能指望数据库的优化引擎，遇到复杂计算时，优化引擎又常常无能为力。所以，我们应该想办法设计更高效的算法，而不是一味地追求分布式计算。按照这个思路，SPL提供了众多高性能算法（有许多是业界首创）以及高效的存储方案，同等硬件环境下可以获得远超过数据库的运算性能。安装在单机上的SPL就可以完成很多大数据计算任务，架构比集群简单很多，从技术上自然就轻的多了。SPL的高性能算法有下面这些：对于数据量更大的情况，SPL实现了轻量级集群计算功能。这一功能的设计目标是几台到十几台节点的集群，采用了与Hadoop完全不同的实现方法。SPL集群不提供复杂沉重的自动化管理功能，而是允许对每个节点进行个性化配置。程序员可以根据数据特征和计算目标来决定各节点存储什么样的数据，完成哪些计算。这样做，不仅大大降低了架构复杂度，也是提升性能的重要手段。以订单分析为例，订单表很大，要通过产品号字段与较小的产品表主键做关联，再按照产品供应商分组汇总订单金额。SPL集群可以很容易的将订单表分段存放在各个节点的硬盘上，再将较小的产品表读入每个节点的内存中。计算时，每个节点仅对本机上的订单分段和产品数据做关联、分组汇总，可以缩短总计算时间；再将结果传输到一个节点上做二次汇总。由于传输的是第一次汇总的结果，数据量小、网络传输时间较短。总体来说，这个方案可以获得最佳性能，虽然程序员需要做一些更细致的工作，但对于小规模集群来说，增加的工作量并不大。SPL也不提供超强的容错能力，不会像Hadoop那样，在有节点故障的情况下，还要保证任何一个任务都会执行成功。实际上，大多数计算任务的执行时间都在几个小时以内，而几台、十几台机器的集群一般都能做到较长时间正常运行，不会这么频繁的出故障。即使偶尔出现节点故障导致任务执行失败，再重新计算一遍也可以接受，毕竟这种情况不会经常发生。所以，SPL的容错能力只是保证有少数节点故障的时候，整个集群还能继续工作并接受新任务（包括重算的任务），这就大大降低了SPL集群的复杂度。在内存计算方面，SPL没有使用Spark RDD的 immutable机制，而是采用了指针式复用机制，利用地址（指针）访问内存，在数据结构没有改变的情况下，直接用原数据的地址形成结果集，不必每个计算都将数据复制一遍，仅仅多保存一个地址（指针），可以同时减少 CPU 和内存的消耗，运行起来要比Spark轻很多了。并且，SPL改进了当前的外存计算算法体系，降低了复杂度并扩大了适应范围，可以做到内外存计算结合，充分提升计算性能的同时，还不像Spark那样依赖大内存。使用简单SPL采用轻量级技术，自然更容易安装、配置和运行维护。SPL不仅可以作为独立服务器使用，还很容易集成到需要高性能计算的应用中，比如即时查询系统，只要引入几个jar包即可。Hadoop则很难集成，只能在边上作为一个数据源运行。有些临时性数据需要随时进行处理，则可使用SPL的桌面集成开发环境可视化地计算，快速得到结果。如果要安装部署Hadoop，那么等环境搭建好时临时数据任务已经过期了。前面展示的众多SPL高性能算法，也能让大数据计算编程变得简单。程序员可以在较短时间内掌握这些算法函数，学习成本相对较低。而且，使用这些现成的函数很容易实现各种复杂的计算需求，不仅比MapReduce/Scala简单，比SQL也简单很多。比如，以电商网站常见的漏斗分析为例，用SQL实现三步漏斗的代码大致如下：with e1 as ( select gid,1 as step1,min(etime) as t1 from T where etime>= to_date('2021-01-10', 'yyyy-MM-dd') and etime<to_date('2021-01-25', 'yyyy-MM-dd') and eventtype='eventtype1' and … group by 1 ), with e2 as ( select gid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2 from T as e2 inner join e1 on e2.gid = e1.gid where e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e2.etime > t1 and e2.etime < t1 + 7 and eventtype='eventtype2' and … group by 1 ), with e3 as ( select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3 from T as e3 inner join e2 on e3.gid = e2.gid where e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e3.etime > t2 and e3.etime < t1 + 7 and eventtype='eventtype3' and … group by 1 ) select sum(step1) as step1, sum(step2) as step2, sum(step3) as step3 from e1 left join e2 on e1.gid = e2.gid left join e3 on e2.gid = e3.gidSQL写出来要三十多行，理解起来有相当的难度。如果用MapReduce/Scala来写，会更加困难。即使是用SQL实现，写出来的这段代码和漏斗的步骤数量相关，每增加一步就要再增加一段子查询。相比之下，SPL 就简单得多，处理任意步骤数都是下面这样简洁的代码：AB1=["etype1","etype2","etype3"]=file("event.ctx").open()2=B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime<date("2021-01-25") && A1.contain(etype) && …)3=A2.group(id).(~.sort(etime))=A3.new(~.select@1(etype==A1(1)):first,~:all).select(first)4=B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime<t1+7).etime, null))))5=A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)SPL集群计算的代码也非常简单，比如前面提到的订单分析计算，具体要求是：大订单表分段存储在4个节点上，小产品表则加载到每个节点的内存中，两表关联之后要按照产品供应商分组汇总订单金额。用SPL写出来大致是下面这样：AB1["192.168.0.101:8281","192.168.0.102:8281",…, "192.168.0.104:8281"]2fork to(4);A1=file("product.ctx").open().import()3>env(PRODUCT,B2)4=memory(A1,PRODUCT)5=file("orders.ctx":to(4),A1).open().cursor(p_id,quantity)6=A5.switch(p_id,A4)7=A7.groups(p_id.vendor;sum(p_id.price*quantity))这段代码执行时，任务管理（内存加载、任务拆分、合并等）所需要的计算资源，远远小于关联和分组汇总计算的消耗。如此轻便的任务管理功能，可以在任意节点、甚至是集成开发环境IDE上执行。成本低与Hadoop相同，SPL也是开源软件，不同的是SPL不仅软件免费，综合成本也非常低。SPL安装、配置、运维很容易，可以大大降低支持人员的人力资源成本。同时，由于SPL降低了大数据计算编程的难度，程序员很容易实现各种复杂的计算，开发效率显著提高，也就节省了程序员的人力资源成本。而且，由于SPL技术体系非常轻，平台自身占用的CPU、内存和硬盘很少，可以让更多的资源用于业务计算，能大幅提高硬件利用率。SPL也不像Spark那样依赖大内存，总体来说，大大减少了硬件采购成本。SPL既轻且快SPL技术轻、自身消耗小，而且还提供了众多高性能算法，所以，在几个到几十个节点的集群，甚至单机的情况下，比Hadoop/Spark有更好的性能表现。案例1：某电商漏斗分析计算。Spark：6节点，每节点4CPU核，平均计算时间：25秒。SPL：单机，8线程计算，平均计算时间可达10秒。代码量仅有Spark Scala的一半。案例2：某大型银行用户画像分析。Hadoop上某OLAP服务器：虚拟机100CPU核，计算时间：120秒。SPL：虚拟机12CPU核，计算时间：仅4秒。性能提高250倍。案例3：某商业银行的手机银行APP，活期明细查询，数据量大且高并发。基于Hadoop的某商用数据仓库：高并发时无法达到秒级的响应速度，只好换用6台ES集群。SPL单机：达到6台ES集群同样的并发和响应能力。总结来说，Hadoop/Spark是源自头部互联网企业的重型解决方案，适合需要有超大规模集群的巨大企业。很多场景的数据虽然也不少，但小集群甚至无集群就足够处理，远没多到这些巨大企业的规模，也没有那么多的硬件设备和维护人员。这种情况下，轻量级的大数据计算引擎SPL是首选，投入很低的成本，就可以做到技术轻、使用简便，而且还能提高开发效率、达到更高的性能。SPL资料SPL下载SPL源代码

在工业和信息化部所发布的《“十四五”大数据产业规划》中明确，数据是新时代重要的生产要素，是国家基础性战略资源，也是推动经济转型发展的新动力。现今数据逐步受到各方的重视，数据即资产也成为了共识。而面对不断激增的数据，如何管理、如何使其发挥价值、给企业提供决策支撑是现阶段的关键。因此，中国信息通信研究院云计算与大数据研究所聚焦数据管理工具体系，推出了结构化数据管理与非机构化数据管理产品评测，包括数据管理平台、数据质量管理平台、数据标准管理平台、数据模型管理平台、元数据管理平台、主数据管理平台、数据资产目录管理平台、以及数据标注平台，集合数据采集、数据建模、数据标准化、数据质量管理、数据分析应用等多项能力，助力企业提升数据管理的效率与人员意识，辅助各部门人员协作，增强数据与数据应用方的契合程度，发挥数据的潜在价值。数据管理平台基础能力评测是数据治理评测体系里首个推出的标准，依据《YD/T 3760-2020大数据 数据管理平台技术要求与测试方法》行业标准开展评测工作，其中涵盖12个测试大项：数据源、数据质量、数据标准、模型管理、元数据、主数据、数据资产报告、数据共享服务管理、安全性等，共计80项测试用例。截止至2022年6月，已评测50家企业，覆盖了市场上主流的数据管理产品，同时也逐步发展成为甲方的选型标准，涉及金融、银行、医疗、能源、工业等行业。在2022年上半年，“可信大数据”产品评测也推出了首批数据质量管理平台、数据标准管理平台的首批评测工作，杭州数梦工场科技有限公司也成为了第一家通过数据质量与数据标准两项测评的企业。数据治理体系系列评测中国信通院云大所开展的“可信大数据”评测是国内首个大数据产品的评测体系，截止至2022年6月中国信通院已完成400余次测试累积完成近300款产品的测试工作，包括数据管理平台、数据挖掘平台、数据脱敏工具、数据库等，见证了国内大数据产品不断进步，逐渐丰富的过程，也成为了大数据产品发展的风向标。目前，数据治理系列工作评测项目正式启动，其中数据模型管理平台、主数据管理平台、元数据管理平台、数据资产目录管理平台、数据标注平台作为“可信大数据”产品能力评测体系的新项目，将于2022年12月的“数据资产管理大会”上为通过首批评测产品颁发证书，欢迎相关单位积极报名参与！来源：中国信通院-大数据技术标准推进委员会

大家好！我是酷哥，数据库资讯，带您速览，欢迎大家阅读。 ------------------------------------------------ **本期精选** ------------------------------------------------ - 创未来，享非凡 | openGauss Developer Day 2022圆满举行 - 中国信通院首批“可信数据库”-数据库运维管理能力成熟度模型评估正式启动 - 鲲鹏应用创新大赛-openGauss赛道报名通道已开启 - 《2021年中国数据管理解决方案市场报告》——湖仓协同，赋能数智融合 - 《云计算白皮书（2022年）》即将重磅发布，七大趋势洞悉行业发展新风向 - 用GaussDB(for Redis)存画像，推荐业务轻松降本60% - 标准系列解读|服务商如何做好SQL审核与安全审计？ - ------------------------------------------------ **资讯摘要** ------------------------------------------------ - 创未来，享非凡 | openGauss Developer Day 2022圆满举行 **摘要：** openGauss Developer Day 2022（openGauss开发者大会2022）于7月14-15日线上和线下同步举办。这是面向数据库开发者的年度活动，也是openGauss开源社区发起并主办的首届开发者大会。本届大会在中国计算机学会数据库专委会的指导下，由openGauss开源社区主办，联合海量数据、云和恩墨、东方通、清华大学共同举办。  本次大会以“创未来 享非凡”为主题，邀请学术专家、行业用户、合作伙伴和开发者共同探讨数据库面向多场景的技术创新，分享基于openGauss的行业联合创新成果及商业实践，完善社区治理，共同打造中国最具创新力的开源数据库根社区。会上： - 神舟通用、云和恩墨、超图软件、南大通用、海量数据、超聚变及中国联通等伙伴和行业客户基于openGauss 3.0推出商业发行版； - 社区治理持续升级，openGauss开源社区用户委员会和品牌委员会成立； - 社区贡献看板和面向开发者的Try Me在线实验环境上线。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194575](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194575) - 中国信通院首批“可信数据库”-数据库运维管理能力成熟度模型评估正式启动 **摘要：** 数据库作为信息系统基础底座软件，在大数据背景下，数据库的数据量和节点规模日益增长，数据库使用方的内部数据库节点动辄达到成百上千，甚至万级节点规模，传统手工运维方式对系统稳定性和业务连续性保障的弊端逐渐凸显。数据库使用方越来越看重系统运行是否稳定、安全和高效，这也使其自身信息系统运行与维护的要求也随之增高。是否拥有成熟健全的信息系统运行维护体系，支撑团队的数据库运维管理能力是否足够专业化和标准化，是否拥有提升标准化运维能力的自动化管理平台，都将影响和制约着企业信息化发展的步伐。  基于以上背景，中国信通院云计算与大数据研究所依托中国通信标准化协会大数据技术标准推进委员会（CCSA TC601）和中国信通院数据库应用创新实验室（CAICT DBL），联合中移信息、联通（广东）产互、华泰证券、江苏电力、联通数科、联通软研院、云和恩墨、新炬网络、天道金科、科蓝软件、南大通用等近40家企业专家参与编制，历时5个月完成13次会议讨论，每次会议讨论时长约4小时，共同讨论完成了《数据库运维管理能力成熟度模型》，旨在为应用侧评价自身数据库运维团队提供参考。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194922](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194922) - 鲲鹏应用创新大赛-openGauss赛道报名通道已开启 **摘要：** 自2020年以来，鲲鹏应用创新大赛至今已经连续举办两年，是面向全球开发者的顶级赛事。本次大赛由24个鲲鹏生态创新中心与华为，联合中国软件行业协会、绿色计算产业联盟、中国计算机行业协会、中国计算机学会高专委共同举办，旨在激发行业应用创新、加速产业融合、促进人才培养，吸引全产业开发者共同打造鲲鹏全栈解决方案。  鲲鹏应用创新大赛.openGauss赛道是openGauss社区与各区域鲲鹏生态创新中心一起为开发者准备的大赛。大赛包括区域赛和决赛两大阶段。开发者可自行组队参赛，完成赛道任务参与评选，共同角逐区域赛与决赛的前三等奖。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=195027](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=195027) - 《2021年中国数据管理解决方案市场报告》——湖仓协同，赋能数智融合 **摘要：** 湖仓一体进一步取消了用户的选型困难，为用户提供的数据管理平台兼具数据仓库的结构和治理优点与数据湖的扩展性和为机器学习提供的便利性  大数据（Big Data）在字面上的理解是海量数据，但这个角度是抽象的。在网络信息时代，大数据产生的客观意义并不在于其宏大的数据规模，而在于如何数据进行专业存储和处理，并从中挖掘和提取所需要的知识价值。 技术突破通常来源于市场对产品的实质需求，互联网、云、AI的不断发展与大数据技术融合满足了商业需求。在大数据产业中，降低存储成本、提升计算速度、对数据进行多维度的分析加工、赋能企业利用数据价值，是大数据产业实现盈利的关键，也是大数据技术蓬勃发展的根源。 大数据技术的内涵伴随着传统信息技术和数据应用的发展不断演进，而大数据技术体系的核心始终是面向海量数据的存储、计算、处理等基础技术。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194690](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194690) - 《云计算白皮书（2022年）》即将重磅发布，七大趋势洞悉行业发展新风向 **摘要：** 在政策和市场双轮驱动下，云计算迎来了黄金时代，其触角已经从互联网的虚拟世界，伸向了实体经济这个更加广阔的天地。面对呼啸而来的下一个十年，云计算将走向何方？ 在7月21-22日即将举行的“2022可信云大会”上，中国信通院将重磅发布年度重磅研究成果——《云计算白皮书（2022年）》，对云计算产业的发展进行深度剖析，这已是中国信通院连续八年发布云计算白皮书。  今年白皮书主要围绕过去一年多来全球云计算产业的发展，重点聚焦云原生、算力服务、云上系统稳定性、云安全、云成本优化等当前行业发展热点进行系统性剖析，并对未来技术发展趋势进行展望： - 全球云计算市场增速反弹，我国 保持高速增长 - 我国云计算展现中国特色，产业呈现五大特点 - 云原生技术和能力不断成熟 加速企业IT要素变革 - 云服务向算力服务演进 助力算力经济高质量发展 - 云上系统稳定性面临挑战 技管结合助力能力提升 - 云安全聚焦应用新技术理念 构建上云全流程安全体系 - 云成本优化治理势在必行 流程贯穿上云用云全生命周期 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194956](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194956) - 用GaussDB(for Redis)存画像，推荐业务轻松降本60% **摘要：** 什么是推荐系统？维基百科上的定义：推荐系统是一种信息过滤系统，可以根据用户历史行为预测用户对物品的“评分”或“偏好”。简单来说，如果你是一个电子发烧友，那么系统肯定会给你推荐各种新鲜出炉的3C产品，如果你是一个coder，那么你的页面肯定充满各种编程大全的书籍。推荐系统近年来非常流行，应用于各行各业，推荐的对象包括：电影、音乐、新闻、书籍、学术论文、搜索查询、分众分类、电商购物和游戏业务等。  在大数据时代，推荐系统的应用场景将会越来越多，作为推荐系统的数据存储，GaussDB(for Redis)完美弥补了开源Redis的短板，并为推荐系统提供强有力的技术支撑。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194957](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194957) - 标准系列解读|服务商如何做好SQL审核与安全审计？ 摘要：本期继续为大家解读《数据库服务能力成熟度模型》运维运营能力域的SQL审核与安全审计两个能力项。  SQL审核能力是指为数据库服务方通过SQL审核平台或工具对未上线、已上线的SQL代码进行代码语法、算法的安全性和质量审核检查，提前发现SQL编写、表和索引设计等方面的隐患问题，推动开发部门提前进行规避性优化处理。 安全审计是指数据库服务方根据需求方的安全审计要求，通过数据库自带的审计功能，或独立的安全审计工具、平台实现数据库安全审计功能，记录符合审计选项的操作记录。通过对用户访问数据库行为的记录、分析和汇报，帮助用户事后生成合规报告、事故追根溯源，同时加强内外部数据库行为记录，提高数据资产安全。 根据公安行业标准《信息安全技术 数据库安全审计产品安全技术要求》定义，数据库安全审计产品是指对用户访问数据库的操作行为进行记录、分析并响应的产品。主要支持数据采集、设置采集策略、生成审计记录、安全告警、设置告警方式和内容、查询和统计审计记录、生成和导出报表、安全存储审计记录、会话分析、安全管理、审计日志等功能。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194685 ](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=194685) *声明：文章源于第三方公开的信息，如果存在侵权或信息不实时，请及时联系处理。* 整理者：酷哥

云服务公共资源服务开通服务官网云服务社区入门材料赋能&产品文档等DGC大数据领域公共资源：1、大数据福利专场 0元试用 - 数据域主力产品0元试用https://activity.huaweicloud.com/Date-free.html2、微信公众号：智能数据湖微信号：ei-datalake    1、免费注册-[教程]DGC免费实例购买流程2.0https://bbs.huaweicloud.com/forum/thread-193738-1-1.html华为云-数据湖治理中心DGC-服务官网https://www.huaweicloud.com/product/dayu.html云社区 -EI企业智能数据湖治理中心DGChttps://bbs.huaweicloud.com/forum/forum-890-1.html1、快速入门：提供3个入门示例场景https://support.huaweicloud.com/qs-dgc/dgc_04_0021.html2、数据湖治理中心 DGC> 视频：入门准备https://support.huaweicloud.com/dgc_video/index.html1、DGC官方使用帮助文档：DGC的每个功能提供详细指导https://support.huaweicloud.com/dgc/index.html2、DGC 赋能视频：数据湖治理中心（DGC）伙伴赋能课程https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXE133+Self-paced/about3、华为伙伴暨开发者大会2022数据治理生产线，加速构建企业数据资产视频回看：https://live.huawei.com/HPDC/meeting/cn/10741.htmlMRS1、云原生数据湖MRS集群开通https://support.huaweicloud.com/qs-mrs/mrs_09_0010.html华为云-云原生数据湖MRS-服务官网https://www.huaweicloud.com/product/mrs.html云社区 -云原生数据湖MRShttps://bbs.huaweicloud.com/forum/forum-612-1.html云原生数据湖MRS> 视频：入门介绍、操作&二次开发指导https://support.huaweicloud.com/mrs_video/index.html1、云原生数据湖MRS帮助文档：MRS的每个功能提供详细指导https://support.huaweicloud.com/mrs/index.html2、云原生数据湖MRS最佳实践https://support.huaweicloud.com/bestpractice-mrs/mrs_05_0023.htmlDLI免费注册-[教程]DLI免费实例购买流程2.0https://bbs.huaweicloud.com/forumreview/thread-193899-1-1.html华为云-数据湖探索 DLI-服务官网https://www.huaweicloud.com/product/dli.html云社区 -数据湖探索 DLIhttps://bbs.huaweicloud.com/forum/forum-599-1.html1、快速入门：使用DLI SQL分析OBS数据https://support.huaweicloud.com/bestpractice-dli/dli_05_0044.html2、数据湖探索 DLI> 视频：入门准备https://support.huaweicloud.com/dli_video/index.html1、DLI官方使用帮助文档：DLI的每个功能提供详细指导https://support.huaweicloud.com/wtsnew-dli/index.html2、DLI 赋能视频：数据湖探索（DLI）伙伴赋能课程https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXE100+Self-paced/about