锐眼洞察 | 理解非结构化数据的关键——数据可视化

作者:James Ovenden

原文:https://channels.theinnovationenterprise.com/articles/why-we-need-data-visualization-to-understand-unstructured-data

译者:TalkingData解决方案架构师 张雪倩

本译文禁止商用,转载请注明来源!

我们越来越擅长理解非结构化数据,但仍未达到理想状态。

数据可视化发展近几年突飞猛进。企业使用愈发令人惊叹的软件来展现他们收集的海量信息,使用反应敏捷、互动性强、往往又非常漂亮的表现形式,让观看者参与进来——无论是会议室里的决策者还是科技馆里的孩子们。

数据可视化领域从业者面临的最重要挑战之一,就是能用非结构化数据来做什么。非结构化数据是指所有不能纳入关系数据库的数据,包括视频、幻灯片、公司记录、社交媒体、RSS、文件和文本——基本上就是绝大部分的交流。

据估计,世界上80%的数据都是非结构化的而且这一数字正迅速增长,IDC预测非结构化数据将从2015年的9.3ZB到2020年增长至44.1ZB。它对企业的重要性也同样迅速增长着。墨尔本大学客座讲师与(商业分析)研究员Ranko Cosic曾指出:“在我看来,运用数据的方式在接下来几年中的变化将是,虽然企业会继续收集和分析数据仓库、传统数据库和关系数据库中的结构化数据,也将更多关注收集和分析传统网站与社交媒体网站上的以录音、图像、音乐、文本、视频和交互式内容形式出现的非结构化数据。”

非结构化数据如此重要,其原因是它所提供的语境。分析结构化数据能够告诉我们什么正在发生,但是通过分析复杂的非结构化数据流才能知道为什么会发生。结构化数据包含收入表现和运营指标,但是非结构化数据的文本能够展示对公司产品的看法、员工信息和竞争优势。

然而,对非结构化数据的分析则是一门相对来说比较新的科学,其规模和复杂性以往使得人们难以理解。高效处理非结构化数据是许多创业公司的目标,他们中的大部分现在关注于使用机器学习算法对其进行解锁,而不是像以前会将非结构化数据转化为结构化数据。他们将分析和可视化都自动化,所以公司能够立即从非结构化数据库得到结果。

BrainSpace和DeepDive是其中取得重大进展的两个创业公司,而且它们都获得了大型融资。Brainspace的CEO Dave Copps告诉我们:“之前,我们能够对非结构化数据做的只有搜索,搜集起来一堆文件,然后用关键词去尝试(搜索)。Tableau和Quickview之类的技术通常适合检索结构化数据,但是一旦你从文件中抽出词来看,语境就不在了。所以,比如说你在分析简历,如果你从一名软件开发者的简历中找到了‘Java’,但你不知道这个词的存在是否只是因为那个人写了‘我的Java很差劲’。我们做的,不仅仅只是分析词句,而是着眼于词与词之间的空白——语境。”

然而,我们在非结构化数据的分析上取得了一些显著进步的同时,实际上仍未发挥信息的全部潜力在动态数据专家Logtrust最近受委托的451研究中,有反馈的IT经理中有89%表示他们将结构化数据方案在企业中提升到很高的优先级,然而只有43%的人认为非结构化数据方案有一样的优先级。

改变这些态度的关键就是数据可视化。像BrainSpace这样的公司提供具有参与性、互动性的自动可视化,但仍有许多未被发现的潜力。洛克希德马丁的首席数据科学家Walter Storm指出:“技术确实使得非结构化数据更易被分析——一大问题却是:‘这种分析有什么用?’ 主题建模、图表分析、甚至降维和可视化都有许多艺术可言。有多少特征?都是些什么?深网中有多少层?有多少节点?多大的粒宽能展现良好的差异性?第二、第三顺序衍生出的特征空间中相邻两者之间的关系是什么?这种算法到底刚学习到了什么?我的假设是什么来着?”

探索新鲜事物是件很棒的事情,但是如果你不能说服决策者,让他们相信你想探索的东西确实是存在的,使他们采取合适的行动,那么这对企业来说就完全没有意义数据可视化是实现这一点最好的方法,它揭示了数据中无法以其它方式来理解的复杂结构。人类大脑处理信息的方式意味着,通过视觉的方式将它传达给人们并使得他们参与其中,让你可以描述出你所发现的模式,甚至可以发现这种模式的洞察。这也能让更多的人更易理解数据,可能有助于提升整个企业的数据平民化,并带来更多的洞察。

相较于传统数字化的数据,非结构化数据可视化带来了独特的挑战,且仍处于初期阶段。在最近旧金山数据可视化峰会上,通用汽车的数据可视化专家Ken Cherven使用以往所有国情咨文做了示范。他的示范结果显示了为什么可视化对于理解非结构化数据是非常有必要的,它也为我们提供了激动人心的机会,来创造性地以之前被认为是不可能的方式来展示信息,并为我们提供从中学习的机会。

延伸阅读:

① 两个工具帮你实现酷炫的数据可视化

② 手把手教你简单快速实现5种数据可视化

③ TalkingData 可视化能力及 iView 开发实践分享

技术专栏 | 微服务架构初探

作者:TalkingData 徐蓓

本译文禁止商用,转载请注明来源!

什么是微服务 

首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统Web应用,来理解什么是微服务。

传统的Web应用核心分为业务逻辑、适配器以及API或通过UI访问的Web界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。

一个打车软件的架构图如下:

尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR,部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目,优点是:

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

当然它的缺点也十分明显,特别对于互联网公司来说:

  • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
  • 代码维护难:代码功能耦合在一起,新人不知道何从下手
  • 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
  • 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
  • 扩展性不够:无法满足高并发情况下的业务需求

所以,现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用,而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能,比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。

比如,前面描述的系统可被分解为:

每个业务逻辑都被分解为一个微服务,微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下,这些客户端并不能直接访问后台微服务,而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务架构的优点 

微服务架构有很多重要的优点。

首先,它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变,但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平,而这通过单体代码库很难实现。因此,微服务开发的速度要快很多,更容易理解和维护。

其次,这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约,开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务,由于服务相对较小,所以这并不会对整体应用造成太大影响。

第三,微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI/CD成为可能。

最后,微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务,在EC2内存优化实例上部署内存数据库服务。

微服务架构的缺点和挑战 

实际上并不存在silver bullets,微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似,微服务强调了服务大小,但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务,这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的,但要记住,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署。

微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。

微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单,因为单体应用往往只存在一个数据库。但在微服务架构下,不同服务可能拥有不同的数据库。CAP原理的约束,使得我们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来说是一个挑战。

微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API即可,而对微服务进行测试,需要启动它依赖的所有其他服务。这种复杂性不可低估。

微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中,若有A、B、C三个服务需要更改,A依赖B,B依赖C。我们只需更改相应的模块,然后一次性部署即可。但是在微服务架构中,我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C,然后更新B,最后更新A。

部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上,然后前端使用负载均衡即可。每个应用都有相同的基础服务地址,例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外,我们还需要服务发现机制,以便服务可以发现与其通信的其他服务的地址。因此,成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。

以上问题和挑战可大体概括为:

  • API Gateway
  • 服务间调用
  • 服务发现
  • 服务容错
  • 服务部署
  • 数据调用

幸运的是,出现了很多微服务框架,可以解决以上问题。

第一代微服务框架 

Spring Cloud

Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具(包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等)。

主要项目包括:

  • spring cloud config:由git存储库支持的集中式外部配置管理。配置资源直接映射到Spring Environment,但是如果需要可以被非Spring应用程序使用。
  • spring cloud netflix:与各种Netflix OSS组件(Eureka,Hystrix,Zuul,Archaius等)集成。
  • spring cloud bus:用于将服务和服务实例与分布式消息传递联系起来的事件总线。用于在集群中传播状态更改(例如配置更改事件)
  • spring cloud for cloud foundry:将您的应用程序与Pivotal Cloudfoundry集成。提供服务发现实现,还可以轻松实现通过SSO和OAuth2保护资源,还可以创建Cloudfoundry服务代理。
  • spring cloud cloud foundry service broker:提供构建管理一个Cloud Foundry中服务的服务代理的起点。
  • spring cloud cluster:领导选举和通用状态模型(基于zookeeper,redis,hazelcast,Consul的抽象和实现)
  • spring cloud consul:结合Hashicorp Consul的服务发现和配置管理
  • spring cloud security:在Zuul代理中为负载平衡的OAuth2休眠客户端和认证头中继提供支持。
  • spring cloud sleuth:适用于Spring Cloud应用程序的分布式跟踪,与Zipkin,HTrace和基于日志(例如ELK)跟踪兼容。
  • spring cloud data flow:针对现代运行时的可组合微服务应用程序的云本地编排服务。易于使用的DSL,拖放式GUI和REST-API一起简化了基于微服务的数据管道的整体编排。
  • spring cloud     stream:轻量级事件驱动的微服务框架,可快速构建可连接到外部系统的应用程序。使用Apache Kafka或RabbitMQ在Spring Boot应用程序之间发送和接收消息的简单声明式模型。
  • spring cloud stream app starters:Spring Cloud任务应用程序启动器是Spring Boot应用程序,可能是任何进程,包括不会永远运行的Spring Batch作业,并且它们在有限时间的数据处理之后结束/停止。
  • spring cloud zookeeper:Zookeeper的服务发现和配置管理
  • spring cloud for amazon web services:轻松集成托管的Amazon的Web Services服务。它通过使用spring的idioms和APIs便捷集成AWS服务,例如缓存或消息API。开发人员可以围绕托管服务,不必关心基础架构来构建应用。
  • spring cloud connectors:使PaaS应用程序在各种平台上轻松连接到后端服务,如数据库和消息代理(以前称为”Spring Cloud”的项目)
  • spring cloud starters:作为基于spring boot的启动项目,降低依赖管理(在Angel.SR2后,不在作为独立项目)
  • spring cloud cli:插件支持基于Groovy预言快速创建spring cloud的组件应用

Dubbo

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。

其核心部分包含:

  • 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及”请求-响应”模式的信息交换方式。
  • 集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
  • 自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。

但是显而易见,无论是Dubbo还是Spring Cloud都只适用于特定的应用场景和开发环境,它们的设计目的并不是为了支持通用性和多语言性。并且它们只是Dev层的框架,缺少DevOps的整体解决方案(这正是微服务架构需要关注的)。而随之而来的便是Service Mesh的兴起。

下一代微服务:Service Mesh? 

Service Mesh

Service Mesh又译作”服务网格”,作为服务间通信的基础设施层。如果用一句话来解释什么是Service Mesh,可以将它比作是应用程序或者说微服务间的TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层(比如通过 HTTP 协议的 RESTful 应用),同样使用Service Mesh也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如Spring Cloud、OSS,现在只要交给Service Mesh就可以了。

Service Mesh有如下几个特点:

  • 应用程序间通讯的中间层
  • 轻量级网络代理
  • 应用程序无感知
  • 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh的架构如下图所示:

Service Mesh作为Sidebar运行,对应用程序来说是透明,所有应用程序间的流量都会通过它,所以对应用程序流量的控制都可以在Service Mesh中实现。

目前流行的Service Mesh开源软件有Linkerd、Envoy和Istio,而最近Buoyant(开源Linkerd的公司)又发布了基于Kubernetes的Service Mesh开源项目Conduit。

Linkerd

Linkerd是开源网络代理,设计为以服务网格部署:用于管理,控制和监控应用程序内的服务与服务间通讯的专用层。

Linkerd旨在解决Twitter,Yahoo,Google和Microsoft等公司运营大型生产系统时发现的问题。根据经验,最复杂,令人惊奇和紧急行为的来源通常不是服务本身,而是服务之间的通讯。Linkerd解决了这些问题,不仅仅是控制通讯机制,而是在其上提供一个抽象层。

它的主要特性有:

  • 负载平衡:linkerd提供了多种负载均衡算法,它们使用实时性能指标来分配负载并减少整个应用程序的尾部延迟。
  • 熔断:linkerd包含自动熔断,将停止将流量发送到被认为不健康的实例,从而使他们有机会恢复并避免连锁反应故障。
  • 服务发现:linkerd 与各种服务发现后端集成,通过删除特定的(ad-hoc)服务发现实现来帮助您降低代码的复杂性。
  • 动态请求路由:linkerd 启用动态请求路由和重新路由,允许您使用最少量的配置来设置分段服务(staging service),金丝雀(canaries),蓝绿部署(blue-green deploy),跨DC故障切换和黑暗流量(dark traffic)。
  • 重试次数和截止日期:linkerd可以在某些故障时自动重试请求,并且可以在指定的时间段之后让请求超时。
  • TLS:linkerd 可以配置为使用 TLS 发送和接收请求,您可以使用它来加密跨主机边界的通信,而不用修改现有的应用程序代码。
  • HTTP代理集成:linkerd 可以作为 HTTP 代理,几乎所有现代 HTTP 客户端都广泛支持,使其易于集成到现有应用程序中。
  • 透明代理:您可以在主机上使用 iptables 规则,设置通过 linkerd 的透明代理
  • gRPC:linkerd 支持 HTTP/2 和 TLS,允许它路由 gRPC 请求,支持高级 RPC 机制,如双向流,流程控制和结构化数据负载。
  • 分布式跟踪:linkerd 支持分布式跟踪和度量仪器,可以提供跨越所有服务的统一的可观察性。
  • 仪器仪表: linkerd 支持分布式跟踪和度量仪器,可以提供跨越所有服务的统一的可观察性。

Envoy

Envoy 是一个面向服务架构的L7代理和通信总线而设计的,这个项目诞生是出于以下目标:

对于应用程序而言,网络应该是透明的,当发生网络和应用程序故障时,能够很容易定位出问题的根源。

Envoy可提供以下特性:

  • 外置进程架构:可与任何语言开发的应用一起工作;可快速升级
  • 基于新C++11编码:能够提供高效的性能
  • L3/L4过滤器:核心是一个L3/L4网络代理,能够作为一个可编程过滤器实现不同TCP代理任务,插入到主服务当中。通过编写过滤器来支持各种任务,如原始TCP代理、HTTP代理、TLS客户端证书身份验证等。
  • HTTP L7过滤器:支持一个额外的HTTP L7过滤层。HTTP过滤器作为一个插件,插入到HTTP链接管理子系统中,从而执行不同的任务,如缓冲,速率限制,路由/转发,嗅探Amazon的DynamoDB等等。
  • 支持HTTP/2:在HTTP模式下,支持HTTP/1.1、HTTP/2,并且支持HTTP/1.1、HTTP/2双向代理。这意味着HTTP/1.1和HTTP/2,在客户机和目标服务器的任何组合都可以桥接
  • HTTP L7路由:在HTTP模式下运行时,支持根据content type、runtime values等,基于path的路由和重定向。可用于服务的前端/边缘代理
  • 支持gRPC:gRPC是一个来自谷歌的RPC框架,使用HTTP/2作为底层的多路传输。HTTP/2承载的gRPC请求和应答,都可以使用Envoy的路由和LB能力
  • 支持MongoDB L7:支持获取统计和连接记录等信息
  • 支持DynamoDB L7:支持获取统计和连接等信息
  • 服务发现:支持多种服务发现方法,包括异步DNS解析和通过REST请求服务发现服务
  • 健康检查:含有一个健康检查子系统,可以对上游服务集群进行主动的健康检查。也支持被动健康检查。
  • 高级LB:包括自动重试、断路器,全局限速,阻隔请求,异常检测。未来还计划支持请求速率控制
  • 前端代理:可作为前端代理,包括TLS、HTTP/1.1、HTTP/2,以及HTTP L7路由
  • 极好的可观察性:对所有子系统,提供了可靠的统计能力。目前支持statsd以及兼容的统计库。还可以通过管理端口查看统计信息,还支持第三方的分布式跟踪机制
  • 动态配置:提供分层的动态配置API,用户可以使用这些API构建复杂的集中管理部署

Istio

Istio是一个用来连接、管理和保护微服务的开放平台。Istio提供一种简单的方式来建立已部署服务网络,具备负载均衡、服务间认证、监控等功能,而不需要改动任何服务代码。想要为服务增加对Istio的支持,您只需要在环境中部署一个特殊的边车(sidecar),使用Istio控制面板功能配置和管理代理,拦截微服务之间的所有网络通信。

Istio目前仅支持在Kubernetes上的服务部署,但未来版本中将支持其他环境。

Istio提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能:

  • 流量管理:控制服务之间的流量和API调用的流向,使得调用更可靠,并使网络在恶劣情况下更加健壮
  • 可观察性:了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力
  • 策略执行:将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码
  • 服务身份和安全:为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转

Istio服务网格逻辑上分为数据面板和控制面板:

  • 数据面板由一组智能代理(Envoy)组成,代理部署为边车,调解和控制微服务之间所有的网络通信
  • 控制面板负责管理和配置代理来路由流量,以及在运行时执行策略

下图显示了构成每个面板的不同组件:

Conduit

Conduit是为Kubernetes设计的一个超轻型服务网格服务,它可透明地管理在Kubernetes上运行的服务的运行时通信,使得它们更安全可靠。Conduit提供了可见性、可靠性和安全性的功能,而无需更改代码。

Conduit service mesh也是由数据面板和控制面板组成。数据面板承载应用实际的网络流量。控制面板驱动数据面板,并对外提供北向接口。

对比

Linkerd和Envoy比较相似,都是一种面向服务通信的网络代理,均可实现诸如服务发现、请求路由、负载均衡等功能。它们的设计目标就是为了解决服务之间的通信问题,使得应用对服务通信无感知,这也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar,多个类似Linkerd和Envoy的proxy互相连接,就组成了service mesh。

而Istio则是站在了一个更高的角度,它将Service Mesh分为了Data Plane和Control Plane。Data Plane负责微服务间的所有网络通信,而Control Plane负责管理Data Plane Proxy:

并且Istio天生的支持Kubernetes,这也弥合了应用调度框架与Service Mesh之间的空隙。

关于Conduit的资料较少,从官方介绍看它的定位和功能与Istio类似。

Kubernetes + Service Mesh 

= 完整的微服务框架 

Kubernets已经成为了容器调度编排的事实标准,而容器正好可以作为微服务的最小工作单元,从而发挥微服务架构的最大优势。所以我认为未来微服务架构会围绕Kubernetes展开。

而Istio和Conduit这类Service Mesh天生就是为了Kubernetes设计,它们的出现补足了Kubernetes在微服务间服务通讯上的短板。虽然Dubbo、Spring Cloud等都是成熟的微服务框架,但是它们或多或少都会和具体语言或应用场景绑定,并只解决了微服务Dev层面的问题。若想解决Ops问题,它们还需和诸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes这类资源调度框架做结合:

但是这种结合又由于初始设计和生态,有很多适用性问题需要解决。

Kubernetes则不同,它本身就是一个和开发语言无关的、通用的容器管理平台,它可以支持运行云原生和传统的容器化应用。并且它覆盖了微服务的Dev和Ops阶段,结合Service Mesh,它可以为用户提供完整端到端的微服务体验。

所以我认为,未来的微服务架构和技术栈可能是如下形式

多云平台为微服务提供了资源能力(计算、存储和网络等),容器作为最小工作单元被Kubernetes调度和编排,Service Mesh管理微服务的服务通信,最后通过API Gateway向外暴露微服务的业务接口。

我相信未来随着以Kubernetes和Service Mesh为标准的微服务框架的盛行,将大大降低微服务实施的成本,最终为微服务落地以及大规模使用提供坚实的基础和保障。

参考资料:

  • Introduction to Microservices:https://www.nginx.com/blog/introduction-to-microservices
  • Pattern: Microservice Architecture:http://microservices.io/patterns/microservices.html
  • Spring Cloud for Microservices Compared to Kubernetes:https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes
  • Istio:https://istio.io
  • Envoy:https://www.envoyproxy.io
  • Linkerd:https://linkerd.io
  • 微服务(Microservice)那点事:https://yq.aliyun.com/articles/2764?spm=a2c4e.11153959.blogcont8611.3.7ea85f19HP1APU
  • Istio中文文档:http://istio.doczh.cn
  • Linkerd中文文档:http://linkerd.doczh.cn

锐眼洞察 | 手把手教你简单快速实现5种数据可视化

作者:George Seif

原文:https://towardsdatascience.com/5-quick-and-easy-data-visualizations-in-python-with-code-a2284bae952f

译者:TalkingData数据工程师 新壮

本译文禁止商用,转载请注明来源!

数据可视化是数据科学家工作中的一个重要部分。在项目的早期阶段,你通常会进行探索性数据分析(EDA),以获得对数据的一些见解。创建可视化确实有助于使数据更易懂,特别是对于更大的高维数据集。在你的项目即将结束时,重要的是能够以清晰、简明和令人信服的方式展示你的最终结果,让你的听众可以理解,而他们通常是不懂技术的客户。

Matplotlib是一种流行的Python库,可以非常容易地用来创建数据可视化。然而,每次创建一个新项目时,设置数据、参数、图形和绘图都会非常混乱和乏味。在这篇博客中,我们会使用Matplotlib库写一些快速且简单的函数,实现5种图形可视化。同时,这里有一个非常好的图表,可以为你在工作中选择合适的可视化提供参考!

根据不同情况选择合适的数据可视化技术

散点图 

散点图很好地显示了两个变量之间的关系,因为你可以直接看到数据的原始分布。您也可以通过颜色编码来查看不同组数据之间的关系,如下图所示。想可视化三个变量之间的关系吗?没问题!只需使用另一个参数,比如点大小,对第三个变量进行编码就可以,如下面的第二个图所示。

颜色分组散点图

按颜色分组并对三个变量进行了大小编码的散点图

现在该展示代码了。我们首先引入Matplotlib的pyplot并命名为“plt”。通过调用plt.subplots()创建一个新的图。我们将X轴和Y轴的数据传入ax.scatter()绘制出散点图。我们还可以设置点大小、点颜色和alpha透明度。你甚至可以设置y轴使用对数刻度。然后针对具体的图像设置标题和轴标签。这是一个好用的函数,它从端到端地创建了一个散点图!

import matplotlib.pyplot as plt
import numpy as np

def scatterplot(x_data, y_data, x_label="", y_label="", title="", color = "r", yscale_log=False):

   # Create the plot object
   _, ax = plt.subplots()

   # Plot the data, set the size (s), color and transparency (alpha)
   # of the points
   ax.scatter(x_data, y_data, s = 10, color = color, alpha = 0.75)

   if yscale_log == True:
       ax.set_yscale('log')

   # Label the axes and provide a title
   ax.set_title(title)
   ax.set_xlabel(x_label)
   ax.set_ylabel(y_label)

线形图 

当你想清楚展示一个变量随另一个变量明显变化时(例如它们有很高的协方差),最好使用线形图。让我们通过下图来说明。

我们可以清楚地看到,所有专业的百分比随着时间的推移有很大的变化。用散点图来绘制这些图形会非常混乱,很难真正理解并看出正在发生的事情。对这种情况来说,线形图则是完美的,因为它们基本上快速地给我们总结了这两个变量的协方差(百分比和时间)。同样,我们还可以使用颜色编码对其分组。

线形图示例

下面是线形图的代码。它和上面的散点图很相似,只是变量有一些细微的变化。

def lineplot(x_data, y_data, x_label="", y_label="", title=""):
   # Create the plot object
   _, ax = plt.subplots()

   # Plot the best fit line, set the linewidth (lw), color and
   # transparency (alpha) of the line
   ax.plot(x_data, y_data, lw = 2, color = '#539caf', alpha = 1)

   # Label the axes and provide a title
   ax.set_title(title)
   ax.set_xlabel(x_label)
   ax.set_ylabel(y_label)
view raw

直方图 

直方图对于显示或发现数据点的分布非常有用。看看下面的直方图,我们画出频率 vs IQ直方图。我们可以清楚地看到均值和中位数是什么。我们也可以看到它遵循高斯分布。使用直方图(而不是散点图)可以让我们清楚地看到每个bin(直方)频率之间的相对差异。使用bin(经过离散化)确实帮助我们看到“更大的图景”,因为如果我们使用所有的数据点而不是离散化后的bin,那么在可视化中可能会有很多噪音,很难看清到底发生了什么。

直方图实例

使用Matplotlib绘制直方图的代码如下所示。有两个参数需要注意。首先,n_bins参数控制我们希望我们的直方图有多少个离散箱。更多的bins会给我们提供更详细的信息,但也可能会带来噪音,使我们远离更大的画面;另一方面,减少bins给我们更多的“鸟瞰”,描述发生了什么事情而没有更详细的细节。其次,cumulative参数是一个布尔值,它允许我们选择我们的直方图是否累积。也就是说选择的是概率密度函数(PDF)还是累积密度函数(CDF)。

def histogram(data, n_bins, cumulative=False, x_label = "", y_label = "", title = ""):
   _, ax = plt.subplots()
   ax.hist(data, n_bins = n_bins, cumulative = cumulative, color = '#539caf')
   ax.set_ylabel(y_label)
   ax.set_xlabel(x_label)
   ax.set_title(title)

假设我们要比较数据中两个变量的分布。有人可能认为你必须制作两个单独的直方图,并把它们并排进行比较。但是,实际上有一个更好的方法:我们可以用不同的透明度覆盖直方图。查看下图。均匀分布被设置为透明度为0.5,这样我们就可以看到它后面是什么。这允许直接查看同一图形上的两个分布。

覆盖直方图

在代码中设置了一些用于覆盖直方图的参数。首先,我们设置水平范围来容纳两个变量分布。根据这个范围和所需的箱数,实际上可以计算每个箱子的宽度。最后,我们将两个直方图绘制在同一个图上,其中一个稍微透明一些。

# Overlay 2 histograms to compare them
def overlaid_histogram(data1, data2, n_bins = 0, data1_name="", data1_color="#539caf", data2_name="", data2_color="#7663b0", x_label="", y_label="", title=""):
   # Set the bounds for the bins so that the two distributions are fairly compared
   max_nbins = 10
   data_range = [min(min(data1), min(data2)), max(max(data1), max(data2))]
   binwidth = (data_range[1] - data_range[0]) / max_nbins


   if n_bins == 0
     bins = np.arange(data_range[0], data_range[1] + binwidth, binwidth)
   else: 
     bins = n_bins

   # Create the plot
   _, ax = plt.subplots()
   ax.hist(data1, bins = bins, color = data1_color, alpha = 1, label = data1_name)
   ax.hist(data2, bins = bins, color = data2_color, alpha = 0.75, label = data2_name)
   ax.set_ylabel(y_label)
   ax.set_xlabel(x_label)
   ax.set_title(title)
   ax.legend(loc = 'best')

柱状图 

当你试图把类别较少(大概是10个)的分类数据可视化时,柱状图最有效。如果我们有太多的类别,那么柱状图将是非常混乱,并且难以理解。它们对于分类数据是很好的,因为你可以很容易地根据柱状的形状(例如大小)来区分类别之间的区别;类别也很容易划分和进行颜色编码。我们要看3种不同类型的柱状图:常规的、分组的和堆积的。下图中代码的顺序与图的顺序一致。

常规柱状图是下面的第一个图。在barplot()函数中,x_data代表X轴上的tickers和y_data代表Y轴上的柱状高度。error线是一条在每一柱状中间的额外的线,可以画出以显示标准差。

常规柱状图

分组柱状图允许我们比较多个分类变量。看看下面的第二个柱状图。我们首先比较的变量是分数如何根据组(G1,G2等)而变化。我们还通过颜色编码比较了他们的性别。我们来看一看代码,y_data_list变量现在真的是一个列表的列表,其中每个子列表代表一个不同的组。然后我们遍历每个组,对于每个组绘制x轴上的每一个刻度条,每组也是颜色编码的。

分组柱状图

堆积柱状图非常适合可视化不同变量的类别构成。在下面的堆积柱状图中,我们一天天地比较服务器负载。通过颜色编码后的堆,我们可以很容易地看到并理解哪一台服务器每天工作最多,以及一台服务器负载如何与其他服务器进行比较。此代码遵循与分组柱状图相同的样式。除了我们遍历每个组时在旧的上面画新的条,而不是在它们旁边。

堆积柱状图

def barplot(x_data, y_data, error_data, x_label="", y_label="", title=""):
   _, ax = plt.subplots()
   # Draw bars, position them in the center of the tick mark on the x-axis
   ax.bar(x_data, y_data, color = '#539caf', align = 'center')
   # Draw error bars to show standard deviation, set ls to 'none'
   # to remove line between points
   ax.errorbar(x_data, y_data, yerr = error_data, color = '#297083', ls = 'none', lw = 2, capthick = 2)
   ax.set_ylabel(y_label)
   ax.set_xlabel(x_label)
   ax.set_title(title)

   
def stackedbarplot(x_data, y_data_list, colors, y_data_names="", x_label="", y_label="", title=""):
   _, ax = plt.subplots()
   # Draw bars, one category at a time
   for i in range(0, len(y_data_list)):
       if i == 0:
           ax.bar(x_data, y_data_list[i], color = colors[i], align = 'center', label = y_data_names[i])
       else:
           # For each category after the first, the bottom of the
           # bar will be the top of the last category
           ax.bar(x_data, y_data_list[i], color = colors[i], bottom = y_data_list[i - 1], align = 'center', label = y_data_names[i])
   ax.set_ylabel(y_label)
   ax.set_xlabel(x_label)
   ax.set_title(title)
   ax.legend(loc = 'upper right')

   
def groupedbarplot(x_data, y_data_list, colors, y_data_names="", x_label="", y_label="", title=""):
   _, ax = plt.subplots()
   # Total width for all bars at one x location
   total_width = 0.8
   # Width of each individual bar
   ind_width = total_width / len(y_data_list)
   # This centers each cluster of bars about the x tick mark
   alteration = np.arange(-(total_width/2), total_width/2, ind_width)

   # Draw bars, one category at a time
   for i in range(0, len(y_data_list)):
       # Move the bar to the right on the x-axis so it doesn't
       # overlap with previously drawn ones
       ax.bar(x_data + alteration[i], y_data_list[i], color = colors[i], label = y_data_names[i], width = ind_width)
   ax.set_ylabel(y_label)
   ax.set_xlabel(x_label)
   ax.set_title(title)
   ax.legend(loc = 'upper right')

箱线图 

我们以前研究过直方图,其对于可视化变量的分布非常有用。但是如果我们需要更多的信息呢?也许我们想更清楚地看一下标准差?也许中位数与平均值有很大的不同,因此我们有很多离群值。如果数据有倾斜,许多值集中在一边呢?

那就是箱线图发挥作用的时候了。箱线图给了我们上面所有的信息实线盒的底部和顶部总是第一和第三分位(即数据的25%和75%),以及箱内的实线总是第二分位(中位数)。“胡须”(例如虚线条一端的条线)从箱中延伸出以显示数据的范围。

由于箱线图绘制自每一个组或变量,所以设置起来相当容易。x_data是组/变量列表。Matplotlib中boxplot()函数对y_data的每一列或y_data序列中的每个向量绘制箱线图;因此x_data中每个值对应于y_data中的列/矢量。所有我们要设定的就是绘图的美学。

箱线图示例

def boxplot(x_data, y_data, base_color="#539caf", median_color="#297083", x_label="", y_label="", title=""):
   _, ax = plt.subplots()

   # Draw boxplots, specifying desired style
   ax.boxplot(y_data
              # patch_artist must be True to control box fill
              , patch_artist = True
              # Properties of median line
              , medianprops = {'color': median_color}
              # Properties of box
              , boxprops = {'color': base_color, 'facecolor': base_color}
              # Properties of whiskers
              , whiskerprops = {'color': base_color}
              # Properties of whisker caps
              , capprops = {'color': base_color})

   # By default, the tick label starts at 1 and increments by 1 for
   # each box drawn. This sets the labels to the ones we want
   ax.set_xticklabels(x_data)
   ax.set_ylabel(y_label)
   ax.set_xlabel(x_label)
   ax.set_title(title)

结论 

以上就是使用Matplotlib简单快速实现的5种数据可视化。把事情抽象成函数总能让代码更易于阅读和使用。希望你喜欢这篇文章,并学到一些新的、有用的东西。如果你没有,就随便给它一些掌声吧~

锐眼洞察 | 大数据与商业智能有什么区别?

作者:Dan Kusnetzky

原文:http://www.dataversity.net/big-data-business-intelligence-whats-difference/

译者:TalkingData架构师 曾晓春

本译文禁止商用,转载请注明来源!

大数据近来在媒体上频繁的出现,但其定义和应用仍然被一些企业的决策者所回避。这些企业在商业智能(BI)的流程和应用程序上投入了大量资金,并且希望将他们一直在做的事情冠以“大数据”的名义幸福地生存下去。可惜的是,BI与大数据所处理的事情确实是不同的。

概念战正在进行 

虽然大数据是一个相对较新的学科,但它已经集合了许多新的概念,用以解释如何收集数据、如何分析数据以及如何使用数据。让我们来看看其中的一些。

野生的大数据概念 

当供应商构建产品并提供旨在处理大数据整体或领域中一些部分的服务,他们通常会提出自己的概念。希望他们的概念能够影响到其他人。这样他们可以声称他们创造了这个概念,并且所有其他供应商都在追随他们。

在“机器智能”的旗帜下,业界已开始谈论“人工智能”、“深度学习”和“机器学习”,这些术语可用于描述产品如何处理数据从而让企业从数据中获取价值。它也可用于描述工具如何找到数据中的模式和异常情况,以帮助企业的数据科学家。

如果我们关注数据是如何被使用的,我们会听到诸如“预测分析”、“智能风险评估”,甚至“大数据分析”等词语。在大数据技术用于改进时,这些词语已被大量使用在系统和应用操作、网络性能以及数据和应用安全中。

随着行业的发展,新的概念会定期出现。通常这意味着一个供应商试图以一种新的方式来定位他们的产品和服务,而不是在底层技术上提供明显提升。

最后,当供应商挥舞大数据旗帜时,他们通常会谈论企业如何审查从大量到海量的数据,以找出隐藏的规律,利用各种类型的数据的能力,并基于新的洞察来进行有意义的调整,使他们能够快速采取行动。通常,其显著的区别是在哪里以及如何部署这些技术。

企业决策者需要问的关键问题是:“为企业或组织带来的影响是什么?”以及“我们是否应该了解更多并开始使用大数据?”

BI的重点在于检查已知信息

作者Mary Pratt认为,BI利用软件和服务将数据转化为可操作的情报,从而告知组织的战略和战术业务决策。BI工具可访问和分析数据集,并在报告、摘要、仪表板、图表和地图中提供分析结果,为用户提供关于业务状态的详细情报。换句话说,商务智能是企业提出问题,并从他们的信息系统获得有用的回应。

最终,BI基于企业知识,即正在发生的事情以及需要被跟踪和了解的已经发生的事情。为此,企业建立流程和系统来收集所需数据,分析数据,然后根据分析汇报结果。企业知道需要跟踪什么、如何分析这些数据以及如何报告分析结果以及应该汇报给谁。

BI成为许多供应商的盈利来源。他们开发了构建和利用“数据仓库”的工具,并通过复杂的工具来为决策者提供有用的仪表板和报告工具。

大数据在几个重要方面与BI相关,但它们是不同的。

大数据 

另一边,大数据被认为是处理大量数据,但它的范围更广,尤其是在探索未知方面。通常,目标是通过筛选企业自己的操作和机器数据来了解要提出什么问题。一旦这些问题被知晓,BI流程就可以用于额外的探索和报告。但大数据更有趣的用途之一是在业务活动发生时将分析集成到业务操作中。所以,大数据不仅仅是解释已经发生的事情的更好方式,而是可以直接影响业务结果。

大数据面临的挑战 

大数据希望解决的难点是:

  • 如何有效地获取和存储如此大量的数据
  • 如何分析这些数据,以便企业能够更好地了解自己的业务或客户需求,以及如何满足这些需求
  • 如何收集如此大量的数据并直接支持处理和分析,特别是以一种安全的方式来满足越来越多的隐私条例
  • 企业如何筛选数据,提出重要问题,并将结果可视化
  • 减少延迟和等待时间,以便将分析纳入企业的运营中

另一种看待这个问题的方式是,企业并不完全理解正在发生的事情。它观察到其业务运营或客户需求的变化,但并未完全了解发生了什么。它可能会看到收入突然增加或减少,客户满意度或竞争环境发生变化。实时应对这些变化的能力提供了显著的竞争优势。尤其是,相较之下,BI所主要提供的商业洞察无法全面自动化的发现洞察背后的那些变化。

意想不到的变化 

当企业经历意外的或突然的变化时,他们通常会开始思考为什么会错过以及是如何错过的。

例如,竞争对手可能突然进入市场。老竞争对手可能会消失或被视为局外人的公司收购。还可能开始与其他紧密相关的市场发生合并或冲突,以导致意想不到和被认为是不受欢迎的变化。

海量数据可能提供线索

很多时候,这些企业拥有大量的数据,这些数据已经积累了很长时间,但企业根本不知道该如何处理它。这些数据可能包含运营数据,其中包括销售数据、生产数据、研究数据和天气数据。它也可能有大量来自销售点设备或制造过程控制系统的数据。它也可能包含对监管变化或其他经济变化的信息。

在了解了“大数据”的概念后,企业决策者被鼓励系统地评估这些数据,并寻找模式和异常。这些有价值的信息可以为最近获得的数据提供适当的背景信息。因此,在网页加载时,就可以根据深层的历史数据以及流式和实时操作对客户体验进行优化。

最后,他们发现了该去了解的新问题,以帮助他们了解所发生的事情并推动洞察力。这意味着他们开始明白,他们需要更智能的、由机器学习所驱动的自动化响应,来识别背景和意义,从而改善企业自身的实践。他们的目标当然是增加收入,或降低成本,或两者兼而有之。

企业将很快意识到需要新的工具和专业知识 

一旦企业开始利用大数据,决策者很快就会认识到,它需要一套不同的工具和专门知识。首先,这个领域看起来需要企业“面面俱到”,才能通过整个过程获得价值。当然,这可能是耗费时间的,并且可能最终不会获得在流程开始时所期望的价值。

我们建议最好找一些更有可能产生新价值或容易学习的简单东西。这种学习应该带来新的机会和/或改变对当前业务、产品或服务的认识,而不是对已经显而易见的事情进行痛苦的研究。

一旦踏上这段旅程,企业很快就会发现,亡羊补牢的宝贵见解并不那么具备价值。企业很快就会发现,一遍又一遍地做同样的事情而没有实现流程的自动化,意味着任何好处都可能会在流程本身造成的时间和成本增加的情况下被淹没。

通常,企业意识到它“知道”组织中的某个地方即将发生变化,甚至应该如何处理这些变化。有些时候企业会意识到利用了这些知识并获得了一些重要的好处。其他时候,企业发现没有利用上这些知识,而是被事件“蒙蔽”了。

现在是时候了 

大数据工具和流程已经发展到足够让企业在学习如何利用它们时有安全感。他们很快就会了解到,这个领域已经迅速开发出新的工具、新的方法和新的思维方式。许多专家认为数据流(Data Logistics)是关键(可参考Ted Dunning和Ellen Friedman撰写的关于“机器学习流(Machine Learning Logistics)”的文章了解更多信息)。

不要单干 

既然大数据的概念已经发展了一段时间,那么企业决策者就不必再觉得需要自食其力,并且没有路线图、没有既定的道路、也没有指引。现在有许多供应商提供工具、现成的流程和专业服务,可以很好地利用。记得从小处着手,积累经验,并在过程中逐步获得实际价值。

技术专栏 | 走进分布式一致性协议

作者:TalkingData 战鹏弘

本文由TalkingData原创,转载请获取授权。

在分布式系统中,每一个机器节点虽然都能明确的知道自己在进行事务操作过程中的结果是成功或失败,但却无法直接获取其它分布式节点的操作结果。因此,当一个事务操作需要跨越多个分布式节点的时候,为了保证事务处理的ACID特性,需要引入一个成为“协调者”的组件来统一调度所有分布式节点的执行逻辑,这些被调度的分布式节点则被称为“参与者”。协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务真正进行提交。基于这个思想,衍生出了二阶段提交(2PC)和三阶段提交(3PC)。

2PC

为了使分布式系统下所有节点在进行事务处理的时候能够保持原子性和和一致性而设计的算法。

两个阶段

阶段一:提交事务请求

协调者向各个参与者发送事务内容,询问是否可以执行事务操作,等待参与者响应。

参与者接收到询问之后,执行事务操作,但是不commit,将undo和redo信息保存到事务日志中。

参与者根据执行情况向协调者返回是否可以执行事务的响应。

阶段二:执行事务提交

阶段一参与者都返回yes

协调者收到所有的yes信号之后,通知参与者执行最后的commit,参与者执行完成之后,想协调者返回ACK信息。

协调者接收到所有的ACK信息之后,完成分布式事务操作

阶段一某个参与者返回no

说明其中一个参与者无法成功执行事务,协调者通知所有参与者回滚事务。

参与者进行事务回滚,完成之后向协调者返回ACK信息

协调者接收到所有的ACK信息之后,事务中断完成

协调者的作用

阶段一

发送给参与者信息

接收参与者反馈,确定下一步需要发送给参与者的信息

阶段二

根据阶段一获得的响应,确定需要发送给参与者的信息(此时如果协调者出问题,无法通知参与者执行commit,参与者的资源会一直被锁住)

接收参与者的反馈,事务结束

注意问题

同步阻塞
第一阶段各个参与者执行事务操作的过程都是阻塞的,各个所有参与者全部完成响应之前,资源都是被加锁的,无法进行其它操作。

协调者的单点问题
两个阶段都需要协调者进行协调,第二阶段中协调者向参与者发送事务commit的新号时,一旦出问题,参与者将无法提交commit操作,资源一直会处于锁定状态,无法释放。

数据不一致
第二阶段协调者发送事务commit信息时,如果与某个参与者的连接出问题,会出现其他参与者成功提交事务,而该参与者事务无法提交,各个参与者的数据会出现不一致的情况。

3PC

阶段一(canCommit)

区别于2PC,3PC的第一阶段会询问所有的参与者是否可以进行事务提交,但是不去执行事务(2PC的第一阶段实际上去执行了事务,但是没有commit而已),这一阶段可以在不锁定资源的前提下,判断各个参与者是否能够执行事务,当然各个参与者返回yes不代表后续执行事务一定会成功。

2PC的第一阶段会真正执行事务,如果某个参与者出现问题,消耗了很长时间返回给协调者no信号,再这个很长时间内,其它的参与者会一直锁定资源,block在那里。3PC的第一阶段有效的解决了该问题。

阶段二(preCommit)

阶段二同2PC的阶段一实际上是相同的,会执行事务但是不提交,但是很大程度上减少了2PC在他的阶段一出现阻塞的问题

阶段一参与者都返回YES

各个参与者执行事务,但是不提交,返回给协调者ACK信号

阶段一有某个参与者返回no

协调者通知参与者中断事务,因为第一阶段中没有执行操作,所以不需要回滚

阶段三(doCommit)

阶段二所有参与者返回yes

说明各个参与者事务执行成功,通知参与者进行commit,返回给协调者ACK,完成事务

阶段二某个参与者返回No

通知所有参与者回滚事务,返回给协调者ACK,中断事务

注意问题

进入阶段三之后,如果协调者出现故障或者与参与者之间的连接出现问题,参与者等待commit信号超时之后,会继续进行事务提交。这种机制一定程度上在协调者故障或者连接出问题时,解决数据不一致问题。

2PC和Paxos

2PC和Paxos作为分布式一致性协议,分别适用于两类一致性:操作原子性和副本一致性。

2PC:保证分布式环境中的多台机器的操作的原子性,要么全部成功,要么全部不成功

Paxos:保证同一个数据分片的多个副本之间的数据一致性

Paxos算法

Paxos算法是莱斯利-兰伯特于1990年提出的一种基于消息传递且具有高度容错性的一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。

Paxos算法需要解决的问题是如何在一个可能发生机器宕机或者网络异常等异常的分布式系统中,快速且正确的在集群内部对某个数据的值达成一致,并且保证无论发生上述任何异常,都不会破坏整个系统的一致性。

分布式系统的存在为了解决单点问题,例如典型的master slave模式,一旦master宕机之后,需要将slave节点切换为master节点,条件是slave和master节点的数据是一致的,也就是说在master上的一切操作都需要同步到slave节点上,这样的slave才具备选举为master的条件。Paxos算法可以为这种数据一致性提供有效的保障。

Paxos算法可以分为两个阶段,prepare阶段和accept阶段,下面简单阐述一下这两个阶段。

prepare阶段

假设现在分布式集群中有三个节点:A、B、C,A把申请操作的请求发送给A、B、C,发送的请求会携带一个Sequence Number(这个值会不断递增,且是唯一的),接受节点在prepare阶段会拒绝接受到的任何提案号小于当前提案号的请求。

如果接受节点接收到的提案号大于当前提案号,节点会给节点A返回yes,并且不在接受提案号更小的提案,也就是说节点总会对最新的提案号做承诺。

accept阶段

如果提案者A收到了半数以上的节点返回yes,他会再次向接收节点发送accept request,仍会携带一个sequence number(n),当接收节点收到accept request信号之后,如果n是接收者接收到的最新的提案号,那么会最终通过提案,如果发现存在比n更大的提案号,拒绝该request,同时提案者会重新进行第一阶段(prepare阶段)。

具体的执行过程如下图所示:

(图片来自:https://www.cnblogs.com/cchust/p/5617989.html)

分布式一致性算法的工程实践

Chubby

Google Chubby是一个有名的分布式锁服务,Google的GFS和Big Table等大型分布式系统都是用它来解决分布式写作、元数据存储和Master选举等一系列与分布式锁相关的问题。

假设Chubby集群中有5台服务器:A B C D E,其中A是当前的master,另外4台服务器实际上是A的副本。Chubby实际运行过程中,只有作为master的A服务器会对外提供写操作服务,其他四台服务器通过Paxos协议从A服务器中同步数据的操作,Paxos协议能够有效的保证副本节点的数据和master节点之间保持一致性。

Chubby中每次提案value的选定是一个Paxos instance,提案由多个proposer提出,最终得到一个value。每次提案的选举都会计入到底层的log日志中,由于Chubby需要不间断的对外提供服务,因此会不断产生Paxos instance,事务日志也会不断增长。每个Paxos instance负责确定一个value,多个instance之间是互不相关的,可以并发进行。将Paxos每两个阶段的提交prepare→promise→propose→accept记作一个round,每个Paxos instance执行过程中可能会经历多轮round,最终才能确定最后的提案。

上述基本的Paxos算法执行过程存在可优化的地方:多个proposer的活锁问题会严重影响效率,导致一个instance最终选定提案需要执行多轮round。

实际执行过程中,可以将多个instance的prepare阶段合并成一个阶段。首先必须在多个proposer中选举出一个master作为唯一的proposer,原本多个instance之间是互相独立的,只需要保证instance内部的round序号不重复即可。现在为了合并prepare阶段,多个instance之间公用一套序号,具体做法如下:

当某个replica通过选举获得master资格后,用新分配的编号N广播一个prepare消息,这个prepare消息被所有未达成一致的instance和将来还未开始的instance共用。

当acceptor接收到prepare后,现在必须对多个instance同时做出回应,这可以封装在一个数据包中,假设最多允许K个instance同时选举,那么:

当前至多有K个未达成一致的instance,将这些未决的instance各自最新accept的value(若没有用null代替)封装进一个数据包,作为promise消息返回

同时,标记这些未决instance和所有未来instance的highestPromisedNum为N,如果N比它们原先的值大的话。这样,这些未决instance和所有未来instance都不能再accept编号小于N的proposal。

然后master就可以对所有未决instance和所有未来instance分别执行propose→accept阶段,始终使用编号N,如果这个master保持稳定的话,就再也不需要prepare→promise了。但是,一旦发现acceptor返回了一个reject消息,说明另一个master启动,用更大的编号M>N发送了Prepare消息,这时自己就要分配新的编号(必须比M更大)再次进行prepare→promise阶段。

ZooKeeper

在ZooKeeper中,client向ZooKeeper提出一个事务,例如创建一个znode,请求会发送到ZooKeeper中的所有机器上,leader需要协调事务的执行,只要集群中半数以上的机器成功执行了该事务,leader便会通知follower进行事务提交。leader作为ZooKeeper中最重要的角色,协调事务执行过程中会保存一个全局的变更序列,可以保证如果一个状态变更已经被处理了,那么所有以来的状态变更应该已经被提前处理了。
ZooKeeper中使用的分布式一致性协议ZooKeeper Atomic Broadcast(ZAB,ZooKeeper原子消息广播协议),ZAB协议的消息广播过程使用的是一个原子广播协议,类似于一个二阶段提交过程。根据客户端的事务请求,leader服务器会为其生成对应的事务poposal,并发送给集群中其余所有的机器,然后收集各自的选票,最后进行事务的提交。

与二阶段提交不同的是,ZAB协议移除了终端逻辑,所有的follower服务器要么正常反馈leader提出的事务proposal,要么抛弃leader服务器,这意味着leader可以在过半的follower服务器已经反馈ACK信号之后就开始提交事务proposal,而不需要等待所有的follower服务器都反馈响应。当时,这种简化的二阶段提交下,无法处理leader服务器崩溃退出而带来的数据不一致问题,因此ZAB协议添加了崩溃恢复模式来解决这个问题。

ZAB协议的执行过程

ZAB主要包括消息广播和崩溃恢复两个过程,进一步可以分为三个阶段,分别是发现(Discovery)、同步(Synchronization)、广播(Broadcast)阶段。ZAB的每一个分布式进程会循环执行这三个阶段,称为主进程周期。

发现:选举产生PL(prospective leader),PL收集Follower epoch(cepoch),根据follower的反馈,PL产生new epoch(每次选举产生新Leader的同时产生新epoch)。

同步:PL补齐相比follower多数派缺失的状态、之后各Follower再补齐相比PL缺失的状态,PL和follower完成状态同步后PL变为正式leader(established leader)。

广播:leader处理客户端的写操作,并将状态变更广播至follower,follower多数派通过之后leader发起将状态变更落地(deliver/commit)。

在正常运行过程中,ZAB协议会一直运行于阶段三来反复进行消息广播流程,如果出现崩溃或其他原因导致leader缺失,那么此时ZAB协议会再次进入发现阶段,选举新的leader。

leader可能在事务提交完成或者提交了一半的时候崩溃,因此leader选举算法需要确保提交已经被leader提交的事务的proposal,同时丢弃已经被跳过的事务proposal。

如果让leader选举算法能够保证新选举出来的leader服务器拥有集群中所有机器最高编号(ZXID最大)的事务proposal,那么就可以保证这个新选举出来的leader一定具有所有已经提交的提议,更为重要的是如果让具有最高编号事务的proposal机器称为leader,就可以省去leader服务器查询proposal的提交和丢弃工作这一步骤了。

技术专栏 | 利用HDFS备份实现Elasticsearch容灾

作者:TalkingData数据工程师 杨双亮

本文由TalkingData原创,转载请获取授权。

01 问题

Elasticsearch 副本提供了高可靠性;它们让你可以容忍零星的节点丢失而不会中断服务。但是,副本并不提供对灾难性故障的保护。对这种情况,你需要的是对集群真正的备份——在某些东西确实出问题的时候有一个完整的拷贝。

02 解决方案

通过快照的方式,将Elasticsearch集群中的数据,备份到HDFS上,这样数据即存在于Elasticsearch(以下简称ES)集群当中,又存在于HDFS上。当ES集群出现不可恢复性的故障时,可以将数据从HDFS上快速恢复。

ES集群快照存在版本兼容性问题,请注意:

  • A snapshot of an index created in 5.x can be restored to 6.x.
  • A snapshot of an index created in 2.x can be restored to 5.x.
  • A snapshot of an index created in 1.x can be restored to 2.x.

03 操作步骤

插件GitHub地址:https://github.com/elastic/elasticsearch-hadoop/tree/master/repository-hdfs

下载地址:https://download.elastic.co/elasticsearch/elasticsearch-repository-hdfs/elasticsearch-repository-hdfs-2.2.0-hadoop2.zip

  • 在线安装

进入ES的目录,执行命令:bin/elasticsearch-plugin install repository-hdfs

  • 离线安装

现将下载好的zip包,放在指定目录,如/home/hadoop/elk/es-reporitory.zip,然后执行命令:bin/plugin install file:///home/hadoop/elk/es-reporitory.zip

显示:

-> Installing from file:/home/hadoop/elk/elasticsearch-repository-hdfs-2.2.0-hadoop2.zip…
Trying file:/home/hadoop/elk/elasticsearch-repository-hdfs-2.2.0-hadoop2.zip …
Downloading ……………..DONE
Verifying file:/home/hadoop/elk/elasticsearch-repository-hdfs-2.2.0-hadoop2.zip checksums if available …
NOTE: Unable to verify checksum for downloaded plugin (unable to find .sha1 or .md5 file to verify)
ERROR: Plugin [repository-hdfs] is incompatible with Elasticsearch [2.3.3]. Was designed for version [2.2.0]

注意:应当选择与你使用ES版本的插件,由于我们使用的ES版本是2.3.3,而使用的插件版本是2.2.0 ,故可以先解压,修改plugin-descriptor.properties

解压,修改plugin-descriptor.properties:

name=repository-hdfs
description=Elasticsearch HDFS Repository
version=2.3.3
classname=org.elasticsearch.plugin.hadoop.hdfs.HdfsPlugin

elasticsearch.version=2.3.3
java.version=1.7
jvm=true

重新打包为es-reporitory.zip,再执行(最好使用root权限);使用Hadoop权限,会出现以下信息:

bin/plugin install file:///home/hadoop/elk/es-reporitory.zip
-> Installing from file:/home/hadoop/elk/es-reporitory.zip...
Trying file:/home/hadoop/elk/es-reporitory.zip ...
Downloading ......................DONE
Verifying file:/home/hadoop/elk/es-reporitory.zip checksums if available ...
NOTE: Unable to verify checksum for downloaded plugin (unable to find .sha1 or .md5 file to verify)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: plugin requires additional permissions     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.lang.RuntimePermission accessClassInPackage.sun.security.krb5
* java.lang.RuntimePermission accessDeclaredMembers
* java.lang.RuntimePermission getClassLoader
* java.lang.RuntimePermission loadLibrary.jaas_nt
* java.lang.RuntimePermission setContextClassLoader
* java.lang.RuntimePermission shutdownHooks
* java.lang.reflect.ReflectPermission suppressAccessChecks
* java.security.SecurityPermission createAccessControlContext
* java.util.PropertyPermission * read,write
* javax.security.auth.AuthPermission getSubject
* javax.security.auth.AuthPermission modifyPrincipals
* javax.security.auth.AuthPermission modifyPrivateCredentials
* javax.security.auth.AuthPermission modifyPublicCredentials
* javax.security.auth.PrivateCredentialPermission org.apache.hadoop.security.Credentials "*" "*" read
See http://docs.oracle.com/javase/ ... .html
for descriptions of what these permissions allow and the associated risks.

Continue with installation? [y/N]y
Installed repository-hdfs into /home/hadoop/elk/elasticsearch-1/plugins/repository-hdfs

3.2 ES集群添加配置 

ES集群各个node节点的config/elasticsearch.yml文件添加一下配置,然后滚动式重启:

security.manager.enabled: false
repositories.hdfs:
   uri:"hdfs://172.23.5.124:9000"
   path:"/es"

注意:这里是简单的配置,还有其它的参数,这里就采用默认的了。

3.3. 常用的快照命令 

建立仓库命令:

curl -XPUT 'http://172.20.33.3:9200/_snapshot/es_backup' -d ' {"type":"hdfs", "settings":{ "path":"/user/ysl", "uri":"hdfs://172.23.5.124:9000" } }'

至于快照命令,常用的快照命令,简单记录如下:

创建存储快照的仓库:

curl -XPUT 'http://172.20.33.3:9200/_snapshot/backup' -d '{"type":"hdfs", "settings":{ "path":"/user/ysl", "uri":"hdfs://172.23.5.124:9000" } }'

快照特定的索引:

curl -XPUT 'http://172.20.33.3:9200/_snapshot/backup/snapshot_1' -d '{"indices":"logstash-gatewaylog"}'

恢复特定索引:

curl -XPOST 'http://172.20.33.3:9200/_snapshot/my_backup/snapshot_1/_restore?pretty'

查看特定快照信息:

curl -XGET  'http://172.20.33.3:9200/_snapshot/backup/snapshot_20171223'

删除快照:

curl -XDELETE 'http://172.20.33.3:9200/_snapshot/backup/snapshot_20171223'

监控快照:

curl -XGET 'http://172.20.33.3:9200/_snapshot/backup/snapshot_20171223/_status'

响应包括快照的总体状况,但也包括下钻到每个索引和每个分片的统计值。这里展示了有关快照进展的非常详细的视图。分片可以在不同的完成状态:

  • INITIALIZING:分片在检查集群状态看看自己是否可以被快照。这个一般是非常快的。
  • STARTED:数据正在被传输到仓库。
  • FINALIZING:数据传输完成;分片现在在发送快照元数据。
  • DONE:快照完成!
  • FAILED:快照处理的时候碰到了错误,这个分片/索引/快照不可能完成了。检查你的日志获取更多信息。

监控恢复快照:

Curl -XGET  'http://172.20.33.3:9200/logstash-gatewaylog/_recovery'

要获取一个仓库中所有快照的完整列表,使用 _all 占位符替换掉具体的快照名称:

curl -XGET  'http://172.20.33.3:9200/_snapshot/backup/_all'

取消一个快照:

curl -XDELETE 'http://172.20.33.3:9200/_snapshot/backup/snapshot_20171223'

备份集群:

https://www.elastic.co/guide/cn/elasticsearch/guide/current/backing-up-your-cluster.html

快照恢复:

https://www.elastic.co/guide/cn/elasticsearch/guide/current/_restoring_from_a_snapshot.html

3.4 脚本 

/home/hadoop/elk/script/snapshot_all_hdfs.sh
#!/usr/bin
current_time=$(date +%Y%m%d%H%M%S)
command_prefix=" http://172.20.33.3:9200/_snapshot/es_backup/all_"
command=$command_prefix$current_time
echo $command
curl -XPUT $command -d '{"indices":"index*,logstash*,nginx*,magicianlog*,invokelog*,outside*"}'
/home/hadoop/elk/script/snapshot_gatewaylog_hdfs.sh

3.5 crontab

0 0 */1 * * /bin/bash /home/hadoop/elk/script/snapshot_all_hdfs.sh>>/home/hadoop/elk/task_log/snapshot_all_day.log 2>&1

注意:这里采用的是每天一份快照,快照的频率可以自己控制。

04 恢复时间

我们采用的测试环境:

ES集群:四个节点,每个节点:10G内存,ES版本:2.3.3,每个索引5个主分片,一个replica.

4.1 备份数据 

第一次快照是全量的(gatewaylog_20171226),第二次快照则是增量的快照(gatewaylog_20171228):

gatewaylog_20171226的详细数据:

gatewaylog_20171228的详细数据:

4.2 恢复数据

第一次是全量的数据恢复,第二次则是在第一次恢复的基础上进行的:

以下是各个分片的数据恢复的详细数据:

gatewaylog_20171226 恢复详细数据:

Gatewaylog_20171228 恢复详细数据:

通过将ElasticSearch的数据备份到HDFS,我们再也不用担心数据会丢失了。

锐眼洞察 | 2018年及未来的人工智能走向(翻译)

作者:Eugenio Culurciello

原文:Artificial Intelligence, AI in 2018 and beyond

译者:TalkingData研发副总裁 阎志涛

本译文禁止商用,转载请注明来源!

译者注: 很多对于未来的预测实际上经常是错误的,不过多看看不同的人对未来的想法无疑是有价值的。人工智能发展到现在已经在很多领域证明了自己。不过目前的人工智能还远远达不到我们期望中的那个状态。下一个目标无疑是人工智能有了更好的感知能力,能够利用记忆、迁移学习以及持续学习能力来处理复杂的情况,这样的人工智能可能才会逐渐的向通用智能方面发展。

以下是我关于深度神经网络以及机器学习在更广泛的人工智能领域如何发展的看法,以及我们如何能够获得越来越复杂的机器以帮助我们的日常生活。 需要注意的是这些并不是对于未来的预测,而是对这些领域的发展轨迹、趋势以及技术需求进行更详细的分析,从而让我们能够获得有用的人工智能。 并不是所有的机器学习都是针对人工智能的,还有一些比较容易获得的成果,这里也会一并进行介绍。

目标

这个领域的目标是实现达到或者超过人类的机器,从而能够在我们的日常生活中帮助我们。自动驾驶车辆、智能家居、智能助手以及安全摄像头是第一个目标。家庭烹饪和清洁机器人以及无人机和机器人是第二个目标。另外一个是移动设备上的智能助手。还有就是能够听到或者看到我们日常生活中经历的全职的智能陪伴助理。终极目标是一个完全自主的综合体,在执行人类的日常任务上能够达到或者超过人类。

软件

在这里,软件被定义为通过优化算法进行训练的能够解决一个特定任务的神经网络架构。 在今天,神经网络已经在事实上成为了学习解决任务的工具,这些任务涉及通过监督学习来对大规模数据集进行分类。但这并不是人工智能,因为在真实的世界中经常需要从没有经历过的经验中进行无监督的学习,这需要能够整合从不同环境中获得的知识去解决所面临的新问题。

神经网络架构 – 几年前,当这个领域蓬勃发展时,我们经常说它具备从数据中自动学习算法参数的能力,并且优于人手工进行的特征工程。但是我们有意识的忘掉了一个小细节:基于训练来解决任务的神经网络架构并不是从数据中学得的,实际上它仍旧是由人来设计的。基于经验进行手工设计仍旧是这个领域中最主要的局限之一。神经网络架构是学习算法基础的核心。尽管我们的学习算法能够掌握新的任务,如果神经网络不正确,它们仍旧不能正常的工作。从数据中学习神经网络架构的问题在于在一个大规模数据集上尝试多个架构花费的时间太长。一个人不得不从头到尾尝试训练多个架构去看看哪个能够表现的最好。这正是我们今天最为耗时的试错的过程。我们需要在这个问题上投入更多的人的脑力去解决这个重要的问题。

非监督学习 – 我们不能总是在那里指导神经网络如何去做,不能总是在帮助它们纠正每一个错误,对它们的性能提供反馈,我们有我们自己的生活要去过。但是这就是我们今天对于有监督的神经网络需要做的:对于每一个实例,我们都要去帮助它使得它能够正确的工作。相反,人类会从一些例子中去学习,然后能够以一种持续的方式自我修正和学习更复杂的数据。

预测神经网络 – 当前的神经网络的一个主要局限就是它不具备我们人类大脑的一个重要特性:预测能力。关于人类大脑是如何工作的一个主要理论是大脑在不断做出预测:预测编码。如果你仔细想一下,我们每天都会体验到它。当你提起一个你认为很轻但是实际上很重的物体时,你会感到吃惊。因为当你准备提起它时,你已经预测了它将会如何影响你和你的身体,以及以及如何影响周边环境。 预测不仅仅帮助理解世界,而且还能够帮助我们知道什么时候不需要、什么时候需要学习。实际上,我们保存关于我们不知道的或者让我们感到吃惊的事情的信息,这样下次遇到的时候我们就不会感到吃惊。认知能力显然与我们大脑中的注意力机制有关系:我们具备先天的能力能够去忘掉99.9%的感官输入,而仅仅聚焦于对于我们的生存至关重要的数据 – 威胁在那里以及我们跑到哪里您够避开它。或者,在当今的社会,当我们急着要出门时我们的手机在哪里。 构建预测神经网络是与真实世界交互以及在复杂的环境中能够进行运转的核心,因此这是任何强化学习网络的核心网络。我们已经广泛的讨论了预测神经网络这个话题,并且是研究和创建它们的先锋组织之一。

当前的神经网络的局限 – 我们前面已经讨论了今天的神经网络的局限,不能够预测、基于内容的推理以及不稳定性,因此我们需要一种新型的神经网络。 神经网络胶囊是解决当前的神经网络局限的一种方法。在这里我们认为胶囊需要扩充一些新的特性:

  • 对视频帧的操作:这非常的简单,我们需要做的是让胶囊路由查看最近播放过的多个数据点。这相当于对最近的重要数据点上的联想记忆。需要注意的是它不是最近的帧的最近的表达,而是最近的帧的最不同点的表达。不同内容的不同点表达可以通过仅仅保存与预定义值不同的表达来获得。这个重要的细节可以保存最近的历史的相关信息,而不是一系列相关的数据点的无用的信息。
  • 预测神经网络能力:这已经是动态路由的一部分,从而强迫每一层都去预测下一层的表达。这是一个非常强大的自学习技术,在我们看来,它比我们社区所开发的所有的其他类型的无监督学习都更有效果。胶囊现在需要能够预测长时间的时空关系,但是现在这个能力还没有被实现。

持续学习 – 这一点很重要,因为神经网络需要不断向学习新的数据点。目前的神经网络每一次都只能够重新训练才能够学习新的数据。神经网络需要能够自我评估哪些是它们已经知道的以及哪些需要重新的训练。这也是现实生活中的增强学习任务所需要的,这样我们就能教机器学习新的任务而不会忘记旧的任务。 迁移学习 – 或者我们如何能够让这些算法通过观看视频自己学习,就像我们想要学习如何做一道新菜一样。这个能力需要我们前面列出的所有的组件,并且对于增强学习非常的重要。现在你只需要给机器一个例子,就可以训练你的机器来做你想要它做的事情,就像我们人类一样。 增强学习 – 这是深度神经网络的研究的圣杯:教给机器如何在一个真实世界的环境中去 学会行动。这需要自我学习、持续学习、预测能力以及很多我们不知道的东西。在增强学习领域还有很多的工作要去做,但是对于作者来讲,他仅仅是了解了这个问题的皮毛,距离解决它还有很多的路要走。 强化学习通常被认为是“锦上添花”,这意味着它仅仅是一个塑料合成大脑上的小型训练。那我们如何能够得到一个能够轻松解决所有问题的“通用”大脑呢? 这是一个先有鸡还是先有蛋的问题。今天为了一个一个的解决增强学习的问题,我们使用标准的神经网络:

  • 一个深度神经网络,它接受大量的输入数据,例如视频或者音频,然后将它们压缩为表达
  • 一个序列学习神经网络(例如RNN),去学习任务

上面是解决这个问题的两个显而易见的解决方案,但明显是错误的。但这正是每个人现在都在使用的,因为它们是目前可用的组件。结果却是不令人满意:我们的确可以从头学会玩视频游戏,并且掌握象棋或者围棋这类完全可被观察的游戏。但是不用我说,这些远远不能够解决现实世界的复杂问题。想象一下,一个AI玩Horizon Zero Dawn可以比人玩的更好,我非常想看到这个发生。 这正是我们想要的,机器可以和我们人类一样的运行。 我们在这里详细介绍了增强学习的工作和建议。它使用一个可以连续操作的预测神经网络以及一个关联存储器去存储当前的体验。

不会再存在循环神经网络 – 循环神经网络(RNN)已经出现了有一段时日了。RNN在训练并行化方面表现的非常不好,即使在特殊定制的机器上运行的也非常慢,原因是它们需要非常高的内存带宽,由此它们更受限于内存带宽而不是受限于计算能力。基于注意力的神经网络训练和部署上更高效也更快速,并且他们不容易受到训练和部署伸缩性的影响。在神经网络中,注意力有可能改变很多架构,但是现在它还没有得到应有的认可。将关联记忆和注意力结合起来,将会是下一波神经网络发展浪潮中的核心。 注意力神经网络已经能够像RNN一样学习序列,并且能够减少100倍的计算量!谁能够忽略这个巨大的进步? 我们认识到基于注意力的神经网络将会慢慢的在语音识别领域替换RNN,并且会在增强学习架构和通用人工智能领域获得一席之地。

硬件

硬件是深度学习取得进步的核心,让我们忘掉深度学习在2008-2012年的快速扩张,近些年深度学习迅速发展主要是因为硬件:

  • 每个手机上的廉价的图像传感器使得我们可以收集大量的数据集
  • GPU可以加速深度神经网络的训练

我们之前曾频繁的讨论过硬件。但是现在需要进行更新了。在过去的1-2年,我们看到了机器学习硬件的爆发式发展,尤其是针对深度神经网络。 有多家公司在这个领域有所投入:NVIDIA、Intel、Nervana、Movidius、Bitmain、Cambricon、Cerebras、DeePhi、Google、Graphcore、Groq、Huawei、ARM、Wave Computing。它们都在开发能够训练和运行深度神经网络的定制化高性能芯片。 关键是,在提供最低功耗和最高性能的同时,运行最新、最有用的神经网络。但是这个领域里很少有人能够理解硬件如何真正的改变机器学习、神经网络以及人工智能。很少有人理解芯片的重要性以及如何去开发它们。

  • 训练还是推理? – 很多公司在打造能够进行神经网络训练的芯片,其目的是抢占NVIDIA的一部分市场,而NVIDIA是神经网络训练硬件的事实上的标准。但是训练仅仅是深度神经网络应用世界中的一小部分。对于任何一个训练步骤,在真实世界中都有实际应用的上百万次的部署。例如你可以在云上使用一个目标检测神经网络:它基于大量图片进行一次训练,但是一旦训练完成,它将会基于数十亿数据在上百万台计算机上运行。这里试图说明的是:就像与真正使用的次数相比,训练次数其实很少,同样训练硬件的重要性也不高。而且制造训练所需要的芯片组需要额外的硬件和技巧。这意味这对于相同的性能需要更高的功率,因此不适合进行当前的生产部署。训练硬件重要,也是对推理硬件的简单调整,它并没有你想的那么重要。
  • 应用 – 在这个领域,能够提供以更低能耗来进行更快训练的硬件非常重要,因为它能够帮助更快创建和测试新模型。但是,运行应用的硬件(大部分用于推理)才是真正的飞跃。目前,有很多应用由于没有硬件或硬件低效的问题还不能用或不实用。比如我们的手机可以是语音助手,但由于不能让它一直在线,目前还远不达理想状态。我们的家庭助手都需要连接到供电设备上,因此不能随时的跟随我们在家里随意移动,除非我们周边有多个麦克风和设备。可能最重要的应用是将手机屏幕从我们的生活中移走,然后嵌入到我们的视觉系统当中。没有超级有效的硬件,所有这些应用以及其他更多应用(小机器人)都将无法实现。
  • 赢家和输家 – 在硬件领域,赢家是单位能耗最低并且能够最快进入市场的那些企业。例如在手机中取代SoC。这每年都在发生。现在想象一下将神经网络加速器嵌入到内存中,这可能能够更快征服和明显渗透大部分市场。这就是我们所说的赢家。

前面我们简要讨论了应用,但是我们需要详细讨论一下AI和神经网络如何进入和影响我们的生活。如下:

  • 图像和视频分类 – 已经有存在于很多云服务中。下一步在很多智能相机做到这些(已经有很多厂商提供)。在未来,神经网络将会越来越减少对云的依赖而在本地处理越来越多的数据:因为保护隐私和节省带宽而成为赢家。
  • 语音助手 – 因为能在我们的“智能”家居中播放音乐和控制基本设备,语音助手正在成为我们生活中的一部分。但是对话是我们人类活动中如此基础的一个能力,我们太把它当成理所当然的事情了。能够与你对话的小型设备是一场正在发生的革命。语音助手在为我们的服务中变得越来越好。但是它们仍需要连接电源。我们真正需要的助手是能够跟随我们移动的。我们的手机合适吗?在这里硬件又一次获得了胜利,因为硬件的进步使之成为可能。Alexa、Cortona和Siri会一直在你的身边陪伴。手机将很快变为智能家居,这是智能手机的有一次胜利。我们还希望语音助手能在车里跟随我们在城市中移动。我们需要能够在本地处理声音,越来越少的依赖云,从而更好隐私保护并降低带宽成本。硬件的进步将在1-2年实现这些。
  • 真正人工助手 – 能够识别语音真的很棒,但是我们真正需要的是能够实时识别我们所看到的,在我们移动时对周围环境进行分析。这是真正会让我们喜爱的智能助手。神经网络硬件能够满足你的这个愿望,因为分析视频流非常耗费计算能力,而且已经达到了现有硅基硬件理论的极限。换句话说,实现这些要比语音助手困难的多。但是这并不是不可能的,许多智能初创公司(比如AiPoly)已经有了所需的相关软件,但是缺乏能够支撑在手机上运行的强大硬件。还要注意的是,利用可穿戴眼镜之类的设备替换手机屏幕,将会使得智能助手真正的成为我们生活的一部分。
  • 烹饪机器人 – 会做饭和清洁的机器人将会成为下一个伟大的设备,我们可能很快就会拥有相关硬件,但是我们缺乏对应的软件。我们需要迁移学习、持续学习以及增强学习。这些工作看起来都非常有魅力,因为你会看到:每一个配方都是不同的,每一个烹饪的原材料看起来都不一样,我们不可能硬编码这些选项,我们需要一个综合体来非常好的学习和总结,从而能够完成相关的工作。我们远没有达到这个地步,但是也不是非常的遥不可及。按照目前的发展速度,可能需要几年的时间。我过去几年就在做这些工作,未来也将继续做下去。

锐眼洞察 | 大数据和经济的不安全感会驱动更多的SaaS创业公司吗?(翻译)

作者:Ryan Kade

原文:Will Big Data and Economic Fears Drive More SaaS Startups?

译者:TalkingData架构师 曾晓春

本译文禁止商用,转载请注明作者与来源!

big-data-and-SaaS-startups-768x556.jpg

1995年,第一家SaaS的公司WebEx创立。在互联网的早期,像WebEx这样的SaaS公司是一个新鲜事物。在当时,没有人认为这种商业模式会成为主流。在过去的二十年里,这种情况发生了显著变化。

SaaS行业去年的市场规模约为2040亿美元。它每年以将近25%的速度增长。SaaS服务已经成为一种卓越的新业务模式。许多因素在这个行业的增长中发挥了作用。

其中有两个因素可能比任何事情都更快地推动(SaaS行业)发展。大数据的进步与经济不确定性的增长。我们来看看这两个因素。

大数据是SaaS产业的驱动力

一些业内专家解释说,大数据是SaaS行业发展的关键。早期的SaaS解决方案(如原先的WebEx平台)无法与广泛依赖大数据的现代SaaS品牌竞争。

通过文章“2013年大数据及SaaS将与小企业紧密相关”,TechCrunch撰稿人、FiveStars营销副总裁Chris Luo成为讨论这一话题的首批专家之一。在此之前,SaaS并不是一个非常具有颠覆性的技术。Luo解释说,合并大数据和SaaS使他的公司在面对竞争对手时拥有巨大优势。

“我亲眼目睹了大数据和SaaS对企业的影响,当时我是Facebook的高级营销经理,领导SMB营销团队。借助内部工具以及像Tableau这样的各种商业工具,对数据可视化和探索也发展很快。而且,当我们的团队希望根据这些数据洞察推动新的基于触发性的市场营销活动时,只需最少的外部团队协助,就可以使用基于云的电子邮件和与内部数据集成的营销自动化工具迅速完成这些工作。”

在2010年初,SaaS解决方案主要依靠大数据进行市场营销。此后,SaaS提供商开始拓展视野,开始使用大数据来提供其他解决方案,如财务支持和竞争分析。

早期的SaaS工具(如WebEx)依靠用户输入来处理这些服务。更多的现代工具使用大量的第三方数据,如果没有基于Hadoop的工具,这将是不可能的。

经济不确定性的作用不容置疑

服务提供商正被迫应对不断变化的经济形式。有两个主要因素影响着其商业模式:

  • 全球经济衰退对无数企业造成了伤害,创造了新一代规避风险的企业家。品牌必须提供成本更低的解决方案来吸引他们。这些企业家对提供可升级的免费服务提出了强劲需求。
  • 越来越多的新兴企业以新兴市场为基础。这些品牌中的大多数资本都比较有限,这推动了SaaS的商业模式。

由于SaaS服务的成本比靠人力服务的公司要低得多,所以它们可以提供更有性价比的服务,并为这些客户提供免费规划。他们还可以使用网络工具更容易地管理他们的客户群体。

大数据和SaaS是应对经济不确定性的新解决方案

经济正在以神秘和可怕的方式变化。品牌面临着越来越大的压力,要保持低成本以实现增长目标,同时面对有限的融资机会。

SaaS解决方案使他们能够以最小的成本满足他们的预期。如果没有大数据的重大发展,这种做法是行不通的。

因此,我们预计未来几年SaaS初创公司的数量将大幅上升。这应该有助于企业更容易适应经济不确定性的增长。

锐眼洞察 | 数据产品经理的兴起(翻译)

作者:Trey Causey

原文:Rise of the Data Product Manager

译者:TalkingData CEO助理兼TDU执行校长 杨慧

本译文禁止商用,转载请注明来源与译者!

译者注:

数据产品经理是数据人才中的高等级交叉性人才,也是将来维持一个数据服务企业/企业数据部门核心竞争力的人才。

在接下来的几年中,将会有一种新的产品经理需求——数据产品经理。我以前曾经争辩说,优秀的数据科学家可以成为优秀的产品经理,但这是不完整的。数据是产品开发的核心,而不是仅在使用指标和A / B测试的事后分析中。数据的不断吸收和耗尽正在决定产品的行为方式以及新产品可能的类别。机器学习模型可以根据用户的偏好自动调整产品,为下一步行动做推荐,并对未来的功能和产品提出建议。数据产品经理了解这一点,并将其纳入他们的产品。

处理产品核心数据需要对数据建模、数据基础架构、统计和机器学习有一定程度的了解。它超越了对实验和阅读仪表盘的结果的理解——它需要一个深入的增值:通过对数据流的充分利用,可能发生什么以及接下来很快会发生什么。如果传统的产品经理在业务,工程和用户体验交叉领域作业的话,数据产品经理还必须具有数据和数据科学的领域知识。

数据产品经理要了解,使用数据构建产品需要一个数据策略——如何生成、收集和使用数据的计划是什么,以及如何在所在市场中赢得独特的位置?仅仅是收集数据并存储在数据仓库进行事后分析是不够的。数据产品经理已经制定了一个计划,为什么随着时间的推移,该产品生成的数据将被用来改进产品、算法等,为什么这会产生一个防御性的壁垒来增加产品长期成功的机会。换句话说,数据产品经理做了让飞轮与数据一起转动的产品决策。

数据产品经理要了解在技术层面上建设产品所涉及的技术基础架构。需要什么样的基础架构来支持产品?机器学习模型是否需要实时评分,还是可以脱机?对新数据进行再训练模型的计划是什么?随着时间的推移如何评估模型的成功?在生产中实施模型的复杂性成本是多少?是的,数据科学家也会回答这些问题,但数据产品经理需要积极参与这些讨论,作为产品开发中不可避免的权衡的一部分。

数据产品经理要了解,带着数据构建的过程中,收集数据和使用数据是两个不同的部分,其中数据有着不同的权衡,并经常涉及工程团队的不同部分。他们帮助推动产品开发流程,使这两个流程无缝衔接,帮助双方成功完成工作。

数据产品经理不仅了解许多问题可以使用机器学习模式,而且知道什么时候需要开发一个启发式模式。当不清楚的时候,他们通过时间盒探索来看看哪种方法可能更有用。他们也知道,从启发式模式到机器学习模式的切换会有一个适当的时机,并为此应变提前计划。

数据产品经理可以执行自己的分析——他们可以编写自己的SQL,建立自己的仪表板,解释他们自己的实验。他们对任何声称“数据自身说明”的人持怀疑态度,因为他们知道这是不正确的。人们说数据,知道如何进行分析与获得结果一样重要。数据产品经理并不是一味地“数据驱动”的决策者,这类人盲目地根据单一的号码拨打电话。数据产品经理会适当的怀疑数据的生产者和消费者。

数据产品经理可以在数据科学家、工程师、设计师、营销人员和其他产品经理之间转换需求。他们与数据科学家合作,确保尽可能快地获取和使用数据进行分析和建模的同事,将产品仪器和数据存储设备纳入他们的验收标准。他们不会让那些不是数据科学家的工程师对什么数据对数据科学家才有价值做出假设。

最后,数据产品经理只知道数据,模型和输出是不够的 – 他们仍然必须成为产品经理,并将这些组成部分与商业模式和组织的战略相结合。不符合商业模式的机器学习模式不仅会无理由的浪费时间和金钱,而且会削弱组织对机器学习的信任。在数据科学开展的迟,对数据科学的力量持怀疑态度,或者在领导力方面已经非常定性的公司尤其如此。

由于这些原因,我仍然相信优秀的数据科学家会成为优秀的产品经理,但是显而易见,一种新型的产品经理即将出现。

锐眼发现 | 2018 年五大科技趋势预测:区块链、笔记本电脑、智能手机、交互和云计算

作者:Ed Oswald

原文:5 tech trends you’ll be talking about in 2018

转载于:36Kr

本文翻译自 www.digitaltrends.com。如若转载请注明出处。

编者按:科技的发展不单单是科技本身之事,它涉及风投、政策、用户等多种因素的综合影响。本文作者Ed Oswald在“5 tech trends you’ll be talking about in 2018”一文中讲述了他所观察并预测的2018年5大科技发展趋势,它们包括区块链、笔记本电脑、智能手机、交互和云计算等。

2017年是科技变革的一年。推特用户终于能发表超140字的内容,特斯拉Model3电动智能汽车市场反应良好。永恒之蓝勒索病毒成为历史上最具破坏性的网络攻击之一,由阿吉特 派领导的联邦通信委员会以3:2的结果废除了奥巴马时代的网络中立原则。

过去一年无论是好是坏,科技领域很是繁忙,2018年似乎也会如此。我们已经察觉到一些重要的科技趋势,并期待它们能够在新的一年成为引领潮流之物。但是首先,我们需要回望去年此时所预测的“2017将会有什么发生”。

回望2017年的科技预测

智能家居在2017年终于开始起飞,而且确实像我们在2016年末预测的那样没有成为“智能中枢”。为什么呢?这要归咎于亚马逊。

Alexa在这一年中击败了它的众多竞争者,从其在CES 2017(2017年国际消费类电子产品展览会)的表现来看,它像是一个设备制造商。虽然这导致了一些相当愚蠢的整合,但也从侧面证明了亚马逊的实力,并使得留给谷歌、苹果和微软的市场份额更小。

多亏了巨头之间的竞争,如今人们只需30美元就可以尽情享受智能支持:这个价格是2016年初费用的六分之一。同时“价格战”也巩固了现有市场份额长期存在的既定优势:这对于新进入者来说十分残酷。

自动化和人工智能在今年的应用中也有所增加,但可能没有达到我们预期的规模。正如我们所料,自动化大多应用于聊天机器人,而大肆炒作的亚马逊无人机送货实验并没有比2016年进一步扩大,自动化普及的速度也没有进一步增加。同时,人工智能和所谓的“机器学习”却引起巨大轰动,尤其是在应用领域。

在增强现实和虚拟现实中,2016年是一个标志性年份,但是2017年增强现实近乎淡出人们的视野。Pokémon Go获得病毒式的传播,但是2017年其他增强现实应用却没有延续这种火热。

另一个失误是我们之前预测人造肉会经历一场繁荣。尽管我们依旧很乐观,但是合成食品在2017年的发展仍然不尽如人意。但是,植物汉堡生产商Beyond Meat却在做出改变,并于2017年年底使其产品在美国全境的沃尔玛超市中上架。这是一个新的开端,但是距离人造肉成为餐桌上的主流还需要很长的路走。

总而言之,这些预测都不算太坏,而且在某些情况下,我们可能已经超前了一些。现在,来看看2018年的五大科技趋势预测,希望这些预测更具有指导意义和价值。

区块链

要知道,它不仅仅如同“郁金香狂热”。无论比特币的价格是0还是5万美元,加密货币的基础,即被称为区块链的分布式分账类系统,将在未来的技术中占有一席之地。

区块链是分散的加密货币核心,它是一种分布式的记录账本,能够对过程进行验证而不需要中间人。虽然区块链在2017年以前的主要用途是验证加密货币交易,但是开发人员却正在意识到除金融以外的用途。交易记录或“块”受加密保护,然后分发给所有参与者。

2018 年五大科技趋势预测:区块链、笔记本电脑、智能手机、交互和云计算

2017年比特币平均区块规模

这使得交易可以排除人为干预进行验证,也不再受欺骗的影响。如果一个版本的块被损坏,其他参与者仍然拥有该块的正确副本,从而分散风险。区块链可以用来核实合同条款,甚至能够在“智能合同”中自动执行,或者验证对资源的访问。

因此,2018年将是许多行业多年转型的开端。在2017年,网络安全是一个重大议题,区块链可能于2018年进入突破的黄金时期。不论哪种原因,多年来,密码货币崩溃了,但是区块链却幸存了下来,这没有什么值得惊讶的。是游戏规则发生了改变。

 ARM服务器芯片支持的笔记本电脑回归

随着制造商和软件开发商不断改进硬件和软件,我们已经习惯了智能手机和平板电脑所具备的长时间续航能力。但是笔记本电脑还存在一个缺陷,即在大多数情况下,它仍需要在一天的某个时间充电,除非一个人并不爱上网。对于该问题的解决正在进行,这使得笔记本电脑超长待机成为可能。

在此需求下,微软于2017年重新设计了Windows系统,使其于ARM技术更兼容。这与启动Windows RT(一种基于Windows的新操作系统)的效果不一样:代码将自动运行这些处理器,使得ARM服务器芯片支持的笔记本电脑广泛使用,尤其是使用高通骁龙835处理器。

虽然早期的基准测试并不受人关注,但是我们注意到其结果是基于原型芯片而产生。高通自己承诺电池续航时间为20-25小时,在2018年正式发布时其性能应该与英特尔处理器相似。当然,这些笔记本电脑的目标客户是那些入门级消费,但却总是关注于性能和LTE(通用移动通信技术的长期演进)连通性特性的人群。

当然,任何新产品的第一个版本总是很粗糙。虽然它很可能在2018年无法实现,但是骁龙845处理器由于比之前版本优化25%的功能和30%的显卡性能而受人关注。

再加上人工智能、生物识别、加密技术和移动支付的支持,基于骁龙845的笔记本电脑很有可能对广大消费者具有吸引力。

 智能手机的终结

这是一个大胆的预测,对吧?不过,事实听起来并没有那么疯狂。传统意义上,智能手机的理念是一种让人们保持联系的设备,而不只是传统的语言通话功能。面对人工智能和机器学习技术的发展,这种情况正在发生改变。

尽管此种设备仍然可能被称为智能手机(smartphone),但是在2018年以后称其为有智慧的智能手机(intelligent phones)可能更合适。正如我们刚刚所提到,移动处理器的出现是为了处理人工智能技术。在2018年,数字化助手将会发挥更大作用,因为它们能够在你提出要求之前预测你的需求。

想想现在你如何与数字化助手交互。如果让它在房间里“打开灯”而不是告诉它需要关掉哪些灯,是不是更有意义?通过位置感知,自动打开离人最近的灯,而不再需要人们的特殊指明。

有传言称,亚马逊正在为Alexa开发更多的位置感知平台,其他公司可能也在研究类似的技术,我们也需要开始了。未来的智能设备将具有真正的智能,并在此种情境下使其本质上更有用。

 非接触型界面

用户界面是我们体验科技产品的关键。但是,大多数产品体验依赖于某种物理交互才能实现。而这将在2018年发生改变,改变的关键在于“无接触型界面”。

亚马逊的Alexa、Siri和其他虚拟助手已经开始规训我们不再依赖于手指。正如我们在讨论智能手机的未来时所指出的那样,已经有其他有效的方式进行交互。

想象一下,拿起你的空果汁杯,说“Alexa,来一杯这个。”在你没有明确物理指示的前提下,Alexa已经了解你在看什么或者是拿着什么。而其他一些功能,例如基于个人的个性化定制已经成为可能,并会在2018年更加普及。

 云计算走向“边缘”

我们已经习惯了“云”以至于这个科技预测听起来似乎是违反常规发展的。但是,边缘计算将会改变我们对“云”的看法,以及之后它们该如何使用。

边缘计算是“分布式计算”的回归,在这里,处理程序分布在多台计算机上。考虑到“云”可以将请求通至可用的服务器上,人们可能会认为云计算也是分布式计算的一种形式,实际上并不如此:云计算时,服务器本身仍然在一台机器上处理所有计算工作。

为什么边缘计算是下一个趋势?随着设备功能的完善,它们需要更大的数据流来支撑运行,这使得云计算本身变得非常缓慢。即使有超快的5G作为基础,连接本身也总会有一定程度的延迟,而这并不包括远程服务器上的处理时间。

想一想,自动驾驶汽车需要在瞬间做出何时转弯、何时停止或移动以避免危险时的决定。而当数据从车传输到中央服务器的时间区间中,有谁能够保证这种延迟不会导致事故的发生?当然无法保证。更好的方法是,车本身成为数据中心,在本地进行密集型计算并及时做出决策,同时将数据发挥中心服务器,为优化其他车辆的运行情况提供数据支持。同样的思路也适用于物联网设备,所有事物都可以在彼此的实际经验中总结学习,而不是在自身运行过程中使用超载通信网络。

这将会是一份巨大的工程,尤其是考虑到我们在云计算上投入了如此多的精力和物力。但是随着物联网设备数量的激增,我们需要找到一个更好的方式,让它们彼此在不占用所有可用宽带的情况下进行通信。