Scala入门reduce操作

  categories:资料  author:

在Scala中,我们可以使用reduce这种二元操作对集合中的元素进行归约。


reduce包含reduceLeft和reduceRight两种操作,前者从集合的头部开始操作,后者从集合的尾部开始操作。

下面我们在Scala解释器中运行代码。

  1. scala> val list = List(1,2,3,4,5)
  2. list: List[Int] = List(1, 2, 3, 4, 5)
  3. scala
阅读全文

十个惊人的Scala集合操作函数

  categories:资料  author:

当我操作 Scala 集合时,我一般会进行两类操作:转换操作(transformation )和行动操作(actions)(有些人喜欢叫他为聚合操作)。第一种操作类型将集合转换为另一个集合,第二种操作类型返回某些类型的值。

  本文我将集中介绍几个日常工作必备的 Scala 集合函数,如转换函数和聚合函数。文章最后,我会展示如何结合这些函数以解决具体问题。

最大值和最小值

我们先从动作函数(action function)开始。在序列中查找最大或最小值是一个极常见的需求,较常用于面试问题和算法。还记得 Java 中的代码行吗?如下:

int[] arr = {11, 2, 5, 1, 6, 3, 9};
 
int to = arr.length - 1;
int max
阅读全文

Scala的map函数

  categories:资料  author:

map函数:
函数式编程都有一个map函数,map函数就像一个加工厂,传入一个函数,利用这个函数将集合里的每一个元素处理并将结果返回。
aList.map(processFunc)//就这么简单,aList中的每一个元素将会变成processFunc的返回值。 这个processFunc一般都是匿名函数,因为用过一次后就用不到了。
val l = List(1,2,3) var ll = l.map(x => x*x)//返回 ll=(1,4,9)
函数式编程不考虑循环,直接考虑将函数 应用到(apply) 数据/函数上。 函数编程语言一般都提供了强大的模式匹配的功能,其实就是对应面向对象的if判断或者是switch判断,但是比前两者都要简洁的多。
还有一个函数flatMap,
将map和flatMap说成Scala函数机制的核心都不为过分。
“flatMap “函数的一半功能和map函数一样,不过有个要求,传入的函数在处理完后返回值必须是List, 如果返回值不是List,那么将出错。也就是说,传入的函数是有要求的——返回值用List()函数构造成list才行。 这样,每个元素处理后返回一个List,我们得到一个包含List元素的List,flatMap自动将所有的内部list的元素取出来构成一个List返回。 sample:
var li= List(1,2,3,4) li.flatMap(x => x match { case 3 => List(3.1,3.2) case _ … 阅读全文

nginx添加key访问限制并且对链接加超时失效策略

  categories:资料  author:

实现key访问限制,nginx通过accessKey来实现。
具体参考:

实现链接的超时失效策略,nginx通过Secure Link来实现。
具体参考:

由于网上说的实现代码都是基于PHP的,所以在这我用JAVA实现了下。

<?php
$secret = ‘password'; # 密钥
$path = ‘/download/she.flv'; # 下载文件
$ipkey= md5(“password”.$_SERVER[‘REMOTE_ADDR’]); #加密IP
# 下载到期时间,time是当前时间,300表示300秒,也就是说从现在到300秒之内文件不过期
$expire = time()+300;
# 用文件路径、密钥、过期时间生成加密串
$md5 = base64_encode(md5($secret . $path . $expire, true));
$md5 = strtr($md5, ‘+/’, ‘-_’);… 阅读全文

Apache Pulsar简介

  categories:资料  author:

Pulsar是pub-sub模式的分布式消息平台,拥有灵活的消息模型和直观的客户端API。

Pulsar由雅虎开发并开源的下一代消息系统,目前是Apache软件基金会的孵化器项目。

概念

Topic

Topic是Pulsar的核心概念,表示一个“channel”,Producer可以写入数据,Consumer从中消费数据(Kafka、RocketMQ都是这样)。

Topic名称的URL类似如下的结构:

{persistent|non-persistent}://tenant/namespace/topic
  • persistent|non-persistent表示数据是否持久化(Pulsar支持消息持久化和非持久化两种模式)
  • Tenant为租户
  • Namespace一般聚合一系列相关的Topic,一个租户下可以有多个Namespace
租户和Namespace

上图中Property即为租户,每个租户下可以有多个Namespace,每个Namespace下有多个Topic。

Namespace是Pulsar中的操作单元,包括Topic是配置在Namespace级别的,包括多地域复制,消息过期策略等都是配置在Namespace上的。

订阅模型

Pulsar提供了灵活的消息模型,支持三种订阅类型:

  • Exclusive subscription:排他的,只能有一个Consumer,接收一个Topic所有的消息
  • Shared subscription:共享的,可以同时存在多个Consumer,每个Consumer处理Topic中一部消息(Shared模型是不保证消息顺序的,Consumer数量可以超过分区的数量)
  • Failover subscription:Failover模式,同一时刻只有一个有效的Consumer,其余的Consumer作为备用节点,在Master Consumer不可用后进行替代(看起来适用于数据量小,且解决单点故障的场景)

分区

为了解决吞吐等问题,Pulsar和Kafka一样,采用了分区(Partition)的机制。

Pulsar提供了一些策略来处理消息到Partition的路由(MessageRouter):

  • Single partitioning:Producer随机选择一个Partition并将所有消息写入到这个分区
  • Round robin partitioning :采用Round robin的方式,轮训所有分区进行消息写入
  • Hash partitioning:这种模式每条消息有一个Key,Producer根据消息的Key的哈希值进行分区的选择(Key相同的消息可以保证顺序)。
  • Custom partitioning:用户自定义路由策略

不同于别的MQ系统,Pulsar允许Consumer的数量超过分区的数量(对于RocketMQ,超过分区数的Consumer会分配不到分区而“空跑”)。

在Shared subscription的订阅模式下,Consumer数量可以大于分区的数量,每个Consumer处理每个Partition中的一部分消息,不保证消息的顺序。

持久化
阅读全文

深入NSQ 之旅

  categories:资料  author:

介绍

NSQ是一个实时的分布式消息平台。它的设计目标是为在多台计算机上运行的松散服务提供一个现代化的基础设施骨架。

这篇文章介绍了 基于go语言的NSQ的内部架构,它能够为高吞吐量的网络服务器带来 性能的优化,稳定性和鲁棒性。

可以说, 如果不是因为我们在bitly使用go语言,NSQ就不会存在。这里既会讲NSQ的功能也会涉及语言提供的特征。当然,语言会影响思维,这次也不例外。

现在回想起来,选择使用go语言已经收到了十倍的回报。由语言带来的兴奋和社区的积极反馈为这个项目提供了极大的帮助。

概要

NSQ是由3个进程组成的:

  • nsqd是一个接收、排队、然后转发消息到客户端的进程。
  • nsqlookupd 管理拓扑信息并提供最终一致性的发现服务。
  • nsqadmin用于实时查看集群的统计数据(并且执行各种各样的管理任务)。

NSQ中的数据流模型是由streamsconsumers组成的tree。topic是一种独特的stream。channel是一个订阅了给定topic的consumers 逻辑分组。

单个nsqd可以有多个topic,每个topic可以有多个channel。channel接收这个topic所有消息的副本,从而实现多播分发,而channel上的每个消息被分发给它的订阅者,从而实现负载均衡。

这些基本成员组成了一个可以表示各种简单和复杂拓扑结构的强大框架。

有关NSQ的设计的更多信息请参见设计文档。

Topics 和 Channels

Topics 和 channels,是NSQ的核心成员,它们是如何使用go语言的特点来设计系统的最好示例。

Go的channels(为防止歧义,以下简称为“go-chan”)是表达队列的一种自然方式,因此一个NSQ的topic/channel,其核心就是一个存放消息指针的go-chan缓冲区。缓冲区的大小由  –mem-queue-size 配置参数确定。

读取数据后,向topic发布消息的行为包括:

  • 实例化消息结构 (并分配消息体的字节数组)
  • read-lock 并获得 Topic
  • read-lock 并检查是否可以发布
阅读全文

开源规则流引擎实践

  categories:资料  author:

在很多企业的 IT 业务系统中,经常会有大量的业务规则配置,而且随着企业管理者的决策变化,这些业务规则也会随之发生更改。为了适应这样的需求,我们的 IT 业务系统应该能快速且低成本的更新。适应这样的需求,一般的作法是将业务规则的配置单独拿出来,使之与业务系统保持低耦合。目前,实现这样的功能的程序,已经被开发成为规则引擎。

规则引擎是一种推理引擎,它是根据已有的事实,从规则知识库中匹配规则,并处理存在冲突的规则,执行最后筛选通过的规则。因此,规则引擎是人工智能(AI)研究领域的一部分,具有一定的选择判断性、人工智能性和富含知识性。目前,比较流行的规则引擎有商业规则引擎 iLog 和开源规则引擎 drools。本文将对开源规则引擎 drools 做详细介绍,并通过分析一个在汽车保险行业中的实际应用案例,让读者对开源规则流引擎有一个更深刻的理解。

1. 基于 rete 算法的规则引擎

在 AI 领域,产生式系统是一个很重要的理论,产生式推理分为正向推理和逆向推理产生式,其规则的一般形式是:IF 条件 THEN 操作。rete 算法是实现产生式系统中正向推理的高效模式匹配算法,通过形成一个 rete 网络进行模式匹配,利用基于规则的系统的时间冗余性和结构相似性特征 [8],提高系统模式匹配效率。本文将介绍的 Drools 引擎就是利用 rete 算法对规则进行分析,形成 rete 网络,对模式进行匹配。

1.1 rete 算法研究

1.1.1 rete 算法概述

Rete 算法最初是由卡内基梅隆大学的 Charles … 阅读全文

携程基于Flink的实时特征平台

  categories:资料  tags:  author:

本文来自于flink-china,本文主要介绍原实时特征作业的开发痛点、特征平台系统架构以及选择Flink的原因等。

本文主要内容如下:

在公司实时特征开发的现状基础上,说明实时特征平台的开发背景、目标以及现状

选择Flink作为平台计算引擎的原因

Flink的实践:有代表性的使用示例、为兼容Aerospike(平台的存储介质)的开发以及碰到的坑

当前效果&未来规划

一、在公司实时特征开发的现状基础上,说明实时特征平台的开发背景、目标以及现状

1、原实时特征作业的开发运维

1.1、选择实时计算平台:依据项目的性能指标要求(latency,throughput等),在已有的实时计算平台:Storm Spark flink进行选择

1.2主要的开发运维过程:

80%以上的作业需要用到消息队列数据源,但是消息队列为非结构化数据且没有统一的数据字典。所以需要通过消费对应的topic,解析消息并确定所需的内容

基于需求中的场景,设计开发计算逻辑

在实时数据不能完全满足数据需求的情况,另外开发单独的离线作业以及融合逻辑;

例如:在需要30天数据的场景下,但消息队列中只有七天内的数据时(kafka中消息的默认保留时间),剩下23天就需要用离线数据来补充。

设计开发数据的校验和纠错逻辑 消息的传输需要依赖网络,消息丢失和超时难以完全避免,所以需要有一个校验和纠错的逻辑。

测试上线

监控和预警

2、原实时特征作业的开发痛点

消息队列数据源结构没有统一的数据字典

特征计算逻辑高度定制化,开发测试周期长

实时数据不能满足需求时,需要定制离线作业和融合逻辑

校验和纠错方案没有形成最佳实践,实际效果比较依赖个人能力

监控和预警方案需要基于业务逻辑定制

3、基于整理的痛点,确定下来的平台目标

实时数据字典:提供统一的数据源注册、管理功能,支持单一结构消息的topic和包含多种不同结构消息的topic

逻辑抽象:抽象为SQL,减少工作量&降低使用门槛

特征融合:提供融合特征的功能,解决实时特征不能完全满足数据需求的情况

数据校验和纠错:提供利用离线数据校验和纠错实时特征的功能

实时计算延迟:ms级

实时计算容错:端到端 exactly-once

统一的监控预警和HA方案

4、特征平台系统架构

现在的架构是标准lamda架构,离线部分由spark sql + dataX组成。现在使用的是KV存储系统Aerospike,跟redis的主要区别是使用SSD作为主存,我们压测下来大部分场景读写性能跟redis在同一个数据量级。… 阅读全文

密码保护:Flink 关系型 API 解读Table API 与 SQL

  categories:资料  author:

这是一篇受密码保护的文章,您需要提供访问密码:

阅读全文

实时计算 Flink SQL 核心功能解密

  categories:资料  tags:  author:

实时计算 Flink SQL 核心功能解密

Flink SQL 是于2017年7月开始面向集团开放流计算服务的。虽然是一个非常年轻的产品,但是到双11期间已经支撑了数千个作业,在双11期间,Blink 作业的处理峰值达到了5+亿每秒,而其中仅 Flink SQL 作业的处理总峰值就达到了3亿/秒。Flink SQL 在这么短的时间内支撑了如此多的业务,与其稳定的内核、完善的功能、强大的生态是分不开的。

本文会带着大家一起来揭开 Flink SQL 核心功能的面纱(API上我们将尽可能的和Flink社区保持一致,这样才能够更好的融入开源的生态,所以我们将API叫做Flink SQL,而不是Blink SQL。事实上flink社区的SQL绝大部分是我们阿里的工程师贡献的:3个 Flink Committer,10+ Contributor,贡献 80% 的SQL 功能,近200个 commit,近十万行的代码)。

为什么是 SQL?

Blink 将 SQL 定位为其最核心的 API。为什么是 SQL 而不是 DataStream API 呢?因为 SQL 具有以下几个优点:

阅读全文


快乐成长 每天进步一点点      京ICP备18032580号-1