用户您好!请先登录!

Archives十月 2019

推荐系统基础知识

本文主要包括推荐系统的相关概念、推荐系统的架构和流程、常见的推荐算法、挖掘、召回、排序、评估和总结这几部分。

概念部分会简述推荐系统相关的理论知识,架构和流程主要是介绍推荐系统的通用架构和常规的推荐流程。

算法部分主要是一些常见的推荐算法介绍,挖掘》召回》排序主要是基于推荐流程的详细展开。

评估部分指的是如何评估一个推荐系统的好坏,总结部分主要是整体内容的回顾,以及一个真实推荐系统的案例。

1. 相关概念

1.1. 什么是推荐系统

先来看下Wiki的定义:

一种信息过滤系统,用来预测用户对物品的行为和偏好。

按照字面意思理解下来,就是帮助过滤信息,预测用户对物品的行为和偏好。

在今日头条曹欢欢博士的一次分享中提到了这样一个定义:

资讯推荐系统本质上要解决用户,资讯和环境的匹配,y=F(Xi,Xu,Xc)

感觉把这个定义延伸到其他推荐系统上也是成立的,那就是推荐系统本质上要解决用户,物品和环境的匹配问题,帮助建立用户和物品之间的连接。

回到定义本身,理论上说能实现这个功能的系统都可以称之为推荐系统。

阅读更多

区块链的计算范式与共识机制

区块链的本质是使冯诺依曼计算体系不再依赖特定的计算物理设施,从而使得其计算过程和相关的存储和通讯,不再为单方控制,而由各个参与者多方分时控制。这是一种全新的计算范式,区块链计算范式,所谓的不可篡改数据库,仅仅是这个内涵的一部分外延。

共识算法,分布式网络是当前实现这一计算范式的重要技术手段。这些是区块链的技术本质。

1. 计算范式

之前所有信息系统,比如支付,搜索,推荐系统之类,都是单一的一家企业掌握这个计算过程的全部,数据也好,计算代码也好,计算的输入/输出都被一个单一企业完全控制。如果这个计算是为了大规模的公众服务的,那么这个企业可以通过任意操纵这个计算过程,任意修改数据和状态,限定和歧视来自外部的输入,从而谋求高额利润甚至造成严重的社会问题 (这类问题在搜索领域已经凸显)。

同时企业也需要承担巨大的责任保护好这个信息系统的数据和计算过程,否则就会导致严重的大规模数据泄露问题(例如时常听到的拖库事件,导致几百万用户的个人数据被盗取,甚至如开房记录等)。

阅读更多

2B产品的概念与分类

现在已经有了很多个版本的B产品的概念和分类,但总是各说各的,也没有什么对与不对。毕竟概念也好,分类也好,更加希望能够有助于实际的产品设计,也不是为了分类而分类。我们换个思,换个维度看看2B的概念和分类。

1. B端产品何以成为热点

我们总是可以笼统地讲,这是由行业发展的必然趋势决定的(虽然没啥用,但确不会错),具体来看:

  • C端的天下格局已定,换句话说,没实力的,玩不起了
  • 整体B端利润率降低,从经济发展规律来看,各行各业的利润会趋向于行业整体平均利润,暴利行业会越来越少;而公司总是追求商业价值最大化,利润最大化,那就不得不内部提升效率,降低成本,从而促成B端产品的爆发。
  • 线上与线下的整合,传统与互联网的融合,链条变长,业务形态复杂,整个产品服务的交付需要统一的管理工具辅助协作,也促成B端产品的爆发。
  • 垂直细分领域的突起,在垂直细分领域,整体市场规模降低(或者说单个企业可覆盖的市场规模会降低)。在市场体量一定的情况下,同样需要提高企业效率,降低成本,来获得更多的盈利,也引发B端产品突起。
  • 巨头突起,整合味道明显,巨头内部集团林立,企业众多,各企业间的协作成为必然,也引发IT产品形态的变革。

阅读更多

“重为轻恨,静为躁君”

自从小时候偶然看到家里的《道德经》,便被那玄之又玄的”道可道,名可名”莫名吸引,耐何那个年代,类似《道德经》尚是封建糟粕之物。再一次看它,便是三十年以后的事情了。

全篇《道德经》5162字(通行本),共计81章,包罗之万象,对于自己而言,竟然花了半年的时候才算读完一遍。感悟太多,不一而举,闲来便列举一二,聊以记录。

重为轻根,静为躁君。是以圣人终日行不离辎重,虽有荣观,燕处超然。奈何万乘之主而以身轻天下?轻则失根,躁则失君。” 重是轻的根本,静是躁的主宰。因此,圣人整天赶路,全都不离开途中所用的各种装备,虽然享有富裕的生活,居处悠闲,但却不会沉溺其中。为什么万乘之国的国君,还以轻率的态度治理天下呢?轻率就会失去根基,浮躁就会丧失主宰。

一棵树苗要想长成参天大树,就要在泥土下有深厚的根基。人们在建造高楼大厦的时候,首先也都要打下坚实牢固的基础,不然风一吹就倒了,这就是“重为轻根”。静能成事,躁而无功,即“静为躁君”。

套用当下人们喜文乐见的散文手法,“只有你自己静了,这个世界才能听到你”。

不能免俗:学习下阿里数据中台

数据中台的概念是最早由阿里巴巴首次提出,是为了应对内部众多业务部门千变万化的数据需求和高速时效性的要求而成长起来的,它既要满足业务部门日常性的多个业务前台的数据需求,又要满足像双十一,六一八这样的业务高峰、应对大规模数据的线性可扩展问题、应对复杂活动场景业务系统的解耦问题,而在技术、组织架构等方面采取的一些变革。

数据中台定义

阿里巴巴数据中台是阿里云上实现数据智能的最佳实践,它是由数据中台方法论+组织+工具所组成。

  • 数据中台方法论采用实现企业数据的全局规划设计,通过前期的设计形成统一的数据标准、计算口径,统一保障数据质量,面向数据分析场景构建数据模型,让通用计算和数据能沉淀并能复用,提升计算效能;
  • 数据中台的建设实施必须有能与之配合的组织,不仅仅相应岗位的人员要配备齐全,而且组织架构建设也需要对应,有一个数据技术部门统筹企业的数字化转型,数据赋能业务中形成业务模式,在推进数字化转型中实现价值;
  • 数据中台由一系列的工具和产品组成,阿里云数据中台以智能数据构建与管理Dataphin产品、商业智能QuickBI工具和企业参谋产品为主体等一系列工具组成。

详解阿里云数据中台

数据中台的概念来自于阿里巴巴“大中台,小前台”业务战略下的数据化实践,它是关于“数据价值化和数据资产化”的一整套解决方案,内容包括数据中台方法论,组织,数据产品三个方面。

阅读更多

深入解析Keepalive机制

很多同学包括自己对keepalive理解不清晰,经常搞不清楚,TCP也有keepalive,HTTP也有keepalive,Nginx有keepalive,高可用也有叫keepalived的工具,经常混淆这几个概念。很多时候keepalive对于开发人员几乎是透明的,但从架构的角度,大家还是有必要认真了解一下keepalive后面那些事。

1. HTTP中的keep-alive

1.1 为什么HTTP是短连接

众所周知,HTTP是短连接,client向server发送一个request,得到response后,连接就关闭。之所以这样设计使用,主要是考虑到实际情况。例如,用户通过浏览器访问一个web站点上的某个网页,当网页内容加载完毕之后,用户可能需要花费几分钟甚至更多的时间来浏览网页内容,此时完全没有必要继续维持底层连。当用户需要访问其他网页时,再创建新的连接即可。

阅读更多

Tomcat系统架构概述

Tomcat 是一个 Web 应用服务器,它是对 HTTP 和 Servlet 规范的实现,简单来说它做了这几件事:处理 HTTP 协议、执行 Servlet 和处理网络 I/O。

Spring 框架就是对 Servlet 的封装,Spring 应用本身就是一个 Servlet,而 Servlet 容器是管理和运行 Servlet 的。

分享:详细讲解Tomcat之系统架构

Servlet 接口和 Servlet 容器这一整套规范叫作 Servlet 规范。Tomcat 和 Jetty 都按照 Servlet 规范的要求实现了 Servlet 容器。

阅读更多

Apache Flink:Flink SQL 编程实践

注:本文实践基于 Ververica 开源的 sql-training 项目,基于 Flink 1.7.2 。

环境准备

本文教程是基于 Docker 进行的,因此你只需要安装了 Docker 即可。不需要依赖 Java、Scala 环境、或是IDE。

注意:Docker 默认配置的资源可能不太够,会导致运行 Flink Job 时卡死。因此推荐配置 Docker 资源到 3-4 GB,3-4 CPUs。

阅读更多

Apache Flink:Table API 编程

一、什么是 Table API

为了更好地了解 Table API,我们先看下 Flink 都提供了哪些 API 供用户使用。

1. Flink API 总览

如图,Flink 根据使用的便捷性和表达能力的强弱提供了 3 层 API,由上到下,表达能力逐渐增强,比如 processFunction,是最底层的 API,表达能力最强,我们可以用他来操作 state 和 timer 等复杂功能。Datastream API 相对于 processFunction 来说,又进行了进一步封装,提供了很多标准的语义算子给大家使用,比如我们常用的 window 算子(包括 Tumble, slide,session 等)。

阅读更多

Apache Flink:状态管理及容错机制

一. 状态管理的基本概念

1.什么是状态

首先举一个无状态计算的例子:消费延迟计算。假设现在有一个消息队列,消息队列中有一个生产者持续往消费队列写入消息,多个消费者分别从消息队列中读取消息。从图上可以看出,生产者已经写入 16 条消息,Offset 停留在 15 ;有 3 个消费者,有的消费快,而有的消费慢。消费快的已经消费了 13 条数据,消费者慢的才消费了 7、8 条数据。

阅读更多

Apache Flink:Time & Window 解析

一、Window & Time 介绍

Apache Flink(以下简称 Flink) 是一个天然支持无限流数据处理的分布式计算框架,在 Flink 中 Window  可以将无限流切分成有限流,是处理有限流的核心组件,现在 Flink 中 Window 可以是时间驱动的(Time Window),也可以是数据驱动的(Count Window)。

下面的代码是在 Flink 中使用 Window 的两个示例

阅读更多

Apache Flink: DataStream API 编程

1. 流处理基本概念

对于什么是流处理,从不同的角度有不同的定义。其实流处理与批处理这两个概念是对立统一的,它们的关系有点类似于对于 Java 中的 ArrayList 中的元素,是直接看作一个有限数据集并用下标去访问,还是用迭代器去访问。

图1. 左图硬币分类器

硬币分类器也可以看作一个流处理系统,用于硬币分类的各部分组件提前串联在一起,硬币不断进入系统,并最终被输出到不同的队列中供后续使用。右图同理。

阅读更多

边缘计算那点事

边缘计算(Edge Computing)是云计算向边缘的延伸,本文对边缘计算、雾计算、MEC、Cloudlet、分布式云等边缘计算领域相关概念和技术的定义、架构、场景等进行了比较分析,并对该领域的技术发展趋势给出了预测与展望。

一、概述

在整个行业数字化转型的大背景下,在 IoT、5G、 VR、AI 等业务云化需求驱动和技术发展推动下,边缘计算(Edge Computing)概念应运而生并迅速得到了行业的广泛关注。相对于经典云计算带来的“云端”的海量计算能力,边缘计算实现了资源和服务向边缘位置的下沉, 从而能够降低交互时延、减轻网络负担、丰富业务类型、优化服务处理,提升服务质量和用户体验。

边缘计算概念并无明确定义,雾计 算、MEC、Cloudlet、 边 缘 计 算、 分 布 式 云 等 概 念 迭 出,ETSI、ITU、OpenFog、ECC、OEC、3GPP、ISO、IEC、 IEEE、Linux 基金会、OpenStack 基金会等业界主流标准 化、开源和行业组织都在积极推进但都有所侧重。本文针对边缘计算、雾计算、MEC、Cloudlet、分布式云等领域内核心技术的定义、架构、场景等进行简介,并进行比较分析。

阅读更多

Apache Flink开发环境搭建与部署

本文主要面向于初次接触 Apache Flink(以下简称Flink)、或者对 Flink 有了解但是没有实际操作过的同学。希望帮助大家更顺利地上手使用 Flink,并着手相关开发调试工作。

课程内容包括:

  • Flink 开发环境的部署和配置
  • 运行 Flink 应用(包括:单机 Standalone 模式、多机 Standalone 模式和 Yarn 集群模式)

一、Flink 开发环境部署和配置

Flink 是一个以 Java 及 Scala 作为开发语言的开源大数据项目,代码开源在 GitHub 上,并使用 Maven 来编译和构建项目。对于大部分使用 Flink 的同学来说,Java、Maven 和 Git 这三个工具是必不可少的,另外一个强大的 IDE 有助于我们更快的阅读代码、开发新功能以及修复 Bug。因为篇幅所限,我们不会详述每个工具的安装细节,但会给出必要的安装建议。

关于开发测试环境,Mac OS、Linux 系统或者 Windows 都可以。如果使用的是 Windows 10 系统,建议使用 Windows 10 系统的 Linux 子系统来编译和运行。

工具 注释
Java Java 版本至少是Java 8,且最好选用 Java 8u51 及以上版本
Maven 必须使用 Maven 3,建议使用 Maven 3.2.5。Maven 3.3.x 能够编译成功,但是在 Shade 一些 Dependencies 的过程中有些问题
Git Flink 的代码仓库是: https://github.com/apache/flink

建议选用社区已发布的稳定分支,比如 Release-1.6 或者 Release-1.7。

阅读更多

Apache Flink 基础概念解析

一、Apache Flink 的定义、架构及原理

Apache Flink 是一个分布式大数据处理引擎,可对有限数据流和无限数据流进行有状态或无状态的计算,能够部署在各种集群环境,对各种规模大小的数据进行快速计算。

1. Flink Application

了解Flink 应用开发需要先理解Flink 的Streams、State、Time 等基础处理语义以及Flink 兼顾灵活性和方便性的多层次API。

  • Streams:流,分为有限数据流与无限数据流,unbounded stream 是有始无终的数据流,即无限数据流;而bounded stream 是限定大小的有始有终的数据集合,即有限数据流,二者的区别在于无限数据流的数据会随时间的推演而持续增加,计算持续进行且不存在结束的状态,相对的有限数据流数据大小固定,计算最终会完成并处于结束的状态。
  • State,状态是计算过程中的数据信息,在容错恢复和Checkpoint 中有重要的作用,流计算在本质上是Incremental Processing,因此需要不断查询保持状态;另外,为了确保Exactly- once 语义,需要数据能够写入到状态中;而持久化存储,能够保证在整个分布式系统运行失败或者挂掉的情况下做到Exactly- once,这是状态的另外一个价值。
  • Time,分为Event time、Ingestion time、Processing time,Flink 的无限数据流是一个持续的过程,时间是我们判断业务状态是否滞后,数据处理是否及时的重要依据。
  • API,API 通常分为三层,由上而下可分为SQL / Table API、DataStream API、ProcessFunction 三层,API 的表达能力及业务抽象能力都非常强大,但越接近SQL 层,表达能力会逐步减弱,抽象能力会增强,反之,ProcessFunction 层API 的表达能力非常强,可以进行多种灵活方便的操作,但抽象能力也相对越小。

阅读更多

竞品分析示例:腾讯、百度、高德App

出行是人们生活的必然需求,面对道路交通复杂的地带,导航定位成为地图最重要的功能卖点。由于资质、资源等原因,进入的门槛较高,地图远没有其他行业那么热闹,经过真实数据反映表明导航类app已经形成了三者割据的形式,以高德地图、百度地图为首,腾讯地图穷追猛赶的势头拼命追赶。

这里,示例对这三大巨头进行全方位解析,以求达到以下目的:

  1. 深入了解导航定位app的现状、市场情况和用户体验
  2. 通过剖析腾讯地图了解其模式,功能特色
  3. 与高德和百度等竞品比较发现其亮点和不足,寻找进一步改善的要点

一、产品概述

1.1 基础信息

竞品分析报告:腾讯地图APP VS 百度地图 VS 高德地图

阅读更多

Kafka的基本概念

Kafka 是一个消息系统,原本开发自 LinkedIn,用作 LinkedIn 的活动流(Activity Stream)和运营数据处理管道(Pipeline)的基础。

现在它已被多家不同类型的公司作为多种类型的数据管道和消息系统使用。活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。

活动数据包括页面访问量(Page View)、被查看内容方面的信息以及搜索情况等内容。

这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件,然后周期性地对这些文件进行统计分析。

运营数据指的是服务器的性能数据(CPU、IO 使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。

近年来,活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分,这就需要一套稍微更加复杂的基础设施对其提供支持。

阅读更多

GridDB: The Fastest Open Source Time Serials Database for IoT and Big Data

Practical Introduction to Time Series Databases and Time Series Data

1. What is Time Series data?

Time series data is a series of values ​​where the time information (timestamp) corresponds to data recorded or an event that happened at that point in time. The data can have both regular and fluctuating intervals. For example, temperature recordings would be recorded at a set time, every minute or hour, while a stock price would be recorded every time a trade is completed.

Time Series data is usually a log or “append-only”, records are rarely updated except upon deletion when they expire. You wouldn’t update values in your web server logs and the same holds true for most Time Series data collections.

阅读更多

京东JDTX:强一致性、高性能的分布式事务中间件

导读:在分布式数据库、云原生数据库、NewSQL 等名词在数据库领域层出不穷的当今,变革——在这个相对稳定的领域已愈加不可避免。相比于完全革新,渐进式增强的方案在拥有厚重沉淀的行业则更受青睐。

同所有分布式领域的解决方案相同,分而治之的透明化数据分片方案,是新一代数据库解决海量数据的核心理念。水平拆分使得分布式事务的重要性,较之垂直拆分的业务系统进一步提升。另外,弹性扩(缩)容、HTAP 等概念也是新一代数据库的关注重点。京东数科开源的 Apache ShardingSphere 在数据分片方面已逐渐成熟,在此场景之上开发的分布式事务中间件 JDTX 与之共同组成了分布式数据库的内核拼图。

JDTX 是由京东数科的数据研发团队倾力打造的分布式事务中间件。本次分享是 JDTX 首次公开出现在大众视野面前,分享内容涵盖 JDTX 的核心设计理念及相关的技术实现难点,希望能为打造分布式事务解决方案的团队提供一些思路。

阅读更多

微服务注册中心的原理及Go的基本实现

在现实生活中,我们每个家庭都有一个户口本,我们会统一的去户籍中心,去注册自己家的信息,包括自己家的门牌号,家里几个人,如果有人找我们,就可以通过这个来定位,同理微服务中的注册中心也是一样,所有的服务实例都到注册中心去注册,后续大家如果需要查找别的服务,就到注册中心去查找即可

服务调用方式

图解微服务注册中心设计原理与思考并基于go语言实现核心架构

服务调用方式主要是指微服务中服务之间调用的方式,主要分为两类:

  • 基于负载均衡:通过负载均衡设备对外提供VIP地址来实现服务的调用
  • 基于注册中心:微服务之间通过服务注册中心进行节点发现,然后在服务端直接调用对应的节点进行调用

阅读更多

负载均衡解析

一、负载均衡

集群中的应用服务器(节点)通常被设计成无状态,用户可以请求任何一个节点。

负载均衡器会根据集群中每个节点的负载情况,将用户请求转发到合适的节点上。

负载均衡器可以用来实现高可用以及伸缩性:

  • 高可用:当某个节点故障时,负载均衡器会将用户请求转发到另外的节点上,从而保证所有服务持续可用;
  • 伸缩性:根据系统整体负载情况,可以很容易地添加或移除节点。

负载均衡器运行过程包含两个部分:

  1. 根据负载均衡算法得到转发的节点;
  2. 进行转发。

阅读更多

微软开源微服务构建软件 Dapr

随着越来越多的开发人员构建可扩展的云原生应用,利用托管服务来部署和运行这些云原生应用。在过去几年中,这一转变值得人们关注。随着这一转变,微服务架构已经成为构建云原生应用的标准,预计到 2022 年,将有 90% 的新应用采用微服务架构。微服务架构提供了极具说服力的好处,包括可扩展性、松散的服务藕合和独立部署等,但这种方法的成本可能很高,因为开发人员需要了解和熟练掌握分布式系统。

开发人员希望专注于业务逻辑,频繁且增量地迁移遗留代码,同时依靠平台为他们的应用提供所需的规模、弹性、可维护性、灵活性和云原生架构的其他属性。然而,开发人员发现,在云端和边缘之间的可移植性有限,他们不断地解决相同的分布式系统问题,如状态管理、弹性方法调用和事件处理。此外,许多编程运行时通常具有狭隘的语言支持和严格控制的特性集,这使得构建微服务架构变得具有挑战性。

为了使所有开发人员能够使用任何语言和框架轻松地构建可移植的微服务应用,无论是编写新代码还是迁移现有代码,我们很高兴地宣布将 Dapr 开源。

阅读更多

Steering Kubernetes to an application-centric future

Kubernetes is the cloud’s breakout success story. It’s gone from nothing to the application development equivalent of a superstar in only a few years, a rapid growth that’s left developers looking for better ways to build and manage Kubernetes-hosted applications.

There have been plenty of workarounds and extensions. Tools such as Helm make it easy to deploy resources to clusters, whereas CNAB (Cloud Native Application Bundle) wraps up applications and all their dependencies ready for deployment. At a lower level, services such as Draft help design and build basic services. You can build code and deploy it using familiar containers, and you can quickly assemble elements into Kubernetes applications. You can even automate management with Azure Kubernetes Services.

阅读更多

物联网架构简谈

物联网(IOT)由国际电信联盟(ITU)的定义为:通过二维码读取设备、射频识别装置(RFID)、红外线感应器、全球定位系统和激光扫描器等信息传感设备,按照既定协议,把任何物品与互联网连接,进行信息交换和通信,以实现智能化识别、定位、跟踪、监控和管理的一种网络。

物联网将传感器与智能处理相结合,运用云计算、模式识别等多种智能技术,拓展应用领域。从传感器获取的海量信息中,分析、处理得到有意义的信息,以满足不同用户的不同需求,找到新的应用领域和模式。

物联网的架构

物联网的本质很简单:传感+通信+IT技术

物联网架构超强解读

 

  • 终端:透彻的感知和测量,使生产资料能够有自己的思想,并与外界沟通交流
  • 网络:泛在的接入和互连、公共通信网络、物联网、互联网,以确保生产资料和工业应用的泛在的连接
  • 应用程序:深度智能分析与控制、行业智能应用与控制系统(计算、存储、应用)

阅读更多


1 2 3