:::: MENU ::::

TalkingData's Blog

现在开始,用数据说话。

Blog

  • 十一 24 / 2017
  • 0
Tech

锐眼洞察 | flink关系型API:Table API与SQL

作者:TalkingData Java数据工程师  王剑

本文为TalkingData原创,未经授权禁止转载。申请授权请在评论中留言联系!

 

本篇文章主要介绍flink的关系型API,整个文章主要分为下面几个部分来介绍:

  1. 什么是flink关系型API
  2. flink关系型API的各版本演进
  3. flink关系型API执行原理
  4. flink关系型API目前适用场景
  5. Table & SQL API介绍
  6. Table & SQL API举例
  7. 动态表
  8. 总结

一、什么是flink关系型API

当我们在使用flink做流式和批式任务计算的时候,往往会想到几个问题:

  1. 需要熟悉两套API : DataStream/DataSetAPI,API有一定难度,开发人员无法focus on business
  2. 需要有Java或Scala的开发经验
  3. flink同时支持批任务与流任务,如何做到API层的统一

flink已经拥有了强大的DataStream/DataSetAPI,满足流计算和批计算中的各种场景需求,但是关于以上几个问题,我们还需要提供一种关系型的API来实现flink API层的流与批的统一,那么这就是flink的Table & SQL API。

首先Table & SQL API是一种关系型API,用户可以像操作MySQL数据库表一样的操作数据,而不需要写Java代码完成flink function,更不需要手工的优化Java代码调优。另外,SQL作为一个非程序员可操作的语言,学习成本很低,如果一个系统提供SQL支持,将很容易被用户接受。

总结来说,关系型API的好处:

  1. 关系型API是声明式的
  2. 查询能够被有效的优化
  3. 查询可以高效的执行
  4. “Everybody” knows SQL

Table & SQL API是流处理和批处理统一的API层,如下图。flink在runtime层是统一的,因为flink将批任务看做流的一种特例来执行,然而在API层,flink为批和流提供了两套API(DataSet和DataStream)。所以Table & SQL API就统一了flink的API层,批数据上的查询会随着输入数据的结束而结束并生成DataSet,流数据的查询会一直运行并生成结果流。Table & SQL API做到了批与流上的查询具有同样的语法语义,因此不用改代码就能同时在批和流上执行。

图片 20

关于DataSet API和DataStream API对应的Table如下图:

图片 16

图片 17

二、flink关系型API的各版本演进

关于Table & SQL API,flink在0.9版本的时候,引进了Table API,支持Java和Scala两种语言,是一个类似于LINQ模式的API。用于对关系型数据进行处理。这系列 Table API的操作对象就是能够进行简单的关系型操作的结构化数据流。结构如下图。然而0.9版本的Table & SQL API有着很大的局限性,0.9版本Table API不能单独使用,必须嵌入到DataSet或者DataStream的程序中,对于批处理表的查询并不支持outer join、order by等操作。在流处理Table中只支持filters、union,不支持aggregations以及joins。并且,这个转化处理过程没有查询优化。整体来说0.9版本的flink Table API还不是十分好用。

图片 18

在后续的版本中,1.1.0引入了 SQL,因此在1.1.0 版本以后,flink 提供了两个语义的关系型API:语言内嵌的 Table API(用于 Java 和 Scala)以及标准 SQL。这两种 API 被设计用于在流和批的任务中处理数据在API层的统一,这意味着无论输入是批处理数据还是流数据,查询产生完全相同的结果。

在1.20版本之后逐渐增加SQL的功能,并对Table API做了大量的enhancement了。在1.2.0 版本中,flink的关系API在数据流中,支持关系操作包括投影、过滤和窗口聚合。

在1.30版本中开始支持各种流上SQL操作,例如SELECT、FROM、WHERE、UNION、aggregation和UDF能力。在2017年3月2日进行的flink meetup与2017年5月24日Strata会议,flink都有相应的topic讨论,未来在flink SQL方面会支持更细粒度的join操作和对dynamic table的支持。

三、flink关系型API执行原理

flink使用基于Apache Calcite这个SQL解析器做SQL语义解析。利用Calcite的查询优化框架与SQL解释器来进行SQL的解析、查询优化、逻辑树生成,得到Calcite的RelRoot类的一颗逻辑执行计划树,并最终生成flink的Table。Table里的执行计划会转化成DataSet或DataStream的计算,经历物理执行计划优化等步骤。但是,Table API和 SQL最终还是基于flink的已有的DataStream API和DataSet API,任何对于DataStream API和DataSet API的性能调优提升都能够自动地提升Table API或者SQL查询的效率。这两种API的查询都会用包含注册过的Table的catalog进行验证,然后转换成统一Calcite的logical plan。再利用 Calcite的优化器优化转换规则和logical plan。根据数据源的性质(流和批)使用不同的规则进行优化。最终优化后的plan转传成常规的flink DataSet或 DataStream程序。结构如下图: 

图片 19

3.1 Translation to Logical Plan

每次调用Table&SQL API,就会生成Flink 逻辑计划的节点。比如对groupBy和select的调用会生成节点Project、Aggregate、Project,而filter的调用会生成节点Filter。这些节点的逻辑关系,就会组成下图的一个Flink 自身数据结构表达的一颗逻辑树; 根据这个已经生成的Flink的 logical Plan,将它转换成calcite的logical Plan,这样我们才能用到calcite强大的优化规则。Flink由上往下依次调用各个节点的construct方法,将Flink节点转换成calcite的RelNode节点。

3.2 Translation to DataStream Plan

优化逻辑计划并转换成Flink的物理计划,Flink的这部分实现统一封装在optimize方法里头。这部分涉及到多个阶段,每个阶段都是用Rule对逻辑计划进行优化和改进。声明定义于派生RelOptRule的一个类,然后再构造函数中要求传入RelOptRuleOperand对象,该对象需要传入这个Rule将要匹配的节点类型。如果这个自定义的Rule只用于LogicalTableScan节点,那么这个operand对象应该是operand(LogicalTableScan.class, any())。通过以上代码对逻辑计划进行了优化和转换,最后会将逻辑计划的每个节点转换成Flink Node,既可物理计划。

 

3.3 Translation to Flink Program

四、flink关系型API目前适用场景

4.1 目前支持范围

Batch SQL & Table API 支持:

  • Selection, Projection, Sort, Inner & Outer Joins, Set operations
  • Windows for Slide, Tumble, Session

Streaming Table API 支持:

  • Selection, Projection, Union
  • Windows for Slide, Tumble, Session

Streaming SQL:

  • Selection, Projection, Union, Tumble

4.2 目前使用场景

五、 Table & SQL API介绍

Table API一般与DataSet或者DataStream紧密关联,可以通过一个DataSet或DataStream创建出一个Table,再用类似于filter, join, 或者 select关系型转化操作来转化为一个新的Table对象。最后将一个Table对象转回一个DataSet或DataStream。从内部实现上来说,所有应用于Table的转化操作都变成一棵逻辑表操作树,在Table对象被转化回DataSet或者DataStream之后,转化器会将逻辑表操作树转化为对等的DataSet或者DataStream操作符。

5.1 Table & SQL API的简单介绍

① Create a TableEnvironment

TableEnvironment对象是Table API和SQL集成的一个核心,支持以下场景:

  • 注册一个Table
  • 注册一个外部的catalog
  • 执行SQL查询
  • 注册一个用户自定义的function
  • 将DataStream或DataSet转成Table

一个查询中只能绑定一个指定的TableEnvironment,TableEnvironment可以通过来配置TableConfig来配置,通过TableConfig可以自定义查询优化以及translation的进程。

TableEnvironment执行过程如下:

  1. TableEnvironment.sql()为调用入口
  2. flink实现了个FlinkPlannerImpl,执行parse(sql),validate(sqlNode),rel(sqlNode)操作
  3. 生成Table

其中,LogicalRelNode是flink执行计算树里的叶子节点。

源码如下图:

图片 1

图片 2

② Register a Table

  1. 将一个Table注册给TableEnvironment图片 3
  2. 将一个TableSource注册给TableEnvironment,这里的TableSource指的是将数据存储系统的作为Table,例如MySQL, hbase, CSV, Kakfa, RabbitMQ等等
  3. 将一个外部的Catalog注册给TableEnvironment,访问外部系统的数据或文件
  4. 将DataStream或DataSet注册为Table图片 4

③ Query a Table

  • Table API
    Table API是一个Scala和Java的集成查询序言。与SQL不同的是,Table API的查询不是一个指定的sql字符串,而是调用指定的API方法。Table API中的每一个方法输入都是一个Table,输出也是一个新的Table。

通过table API来提交任务的话,也会经过calcite优化等阶段,基本流程和直接运行SQL类似:

  1. table API parser: flink会把table API表达的计算逻辑也表示成逻辑树,用treeNode表示;
  2. 在这棵树上的每个节点的计算逻辑用Expression来表示。
  3. Validate: 会结合catalog将树的每个节点的Unresolved Expression进行绑定,生成Resolved Expression;
  4. 生成Logical Plan: 依次遍历数的每个节点,调用construct方法将原先用treeNode表达的节点转成成用calcite 内部的数据结构relNode 来表达。即生成了LogicalPlan, 用relNode表示;
  5. 生成 optimized Logical Plan: 先基于calcite rules 去优化logical Plan,
  6. 再基于flink定制的一些优化rules去优化logical Plan;
  7. 生成Flink Physical Plan: 这里也是基于flink里头的rules将,将optimized LogicalPlan转成成Flink的物理执行计划;
  8. 将物理执行计划转成Flink Execution Plan: 就是调用相应的tanslateToPlan方法转换。图片 5
  • SQL

Flink SQL是基于Apache Calcite的实现的,Calcite实现了SQL标准解析。SQL查询是一个完整的sql字符串来查询。一条stream sql从提交到calcite解析、优化最后到flink引擎执行,一般分为以下几个阶段:

  1. Sql Parser: 将sql语句解析成一个逻辑树,在calcite中用SqlNode表示逻辑树;
  2. Sql Validator: 结合catalog去验证sql语法;
  3. 生成Logical Plan: 将sqlNode表示的逻辑树转换成Logical Plan, 用relNode表示;
  4. 生成 optimized Logical Plan: 先基于calcite rules 去优化logical Plan;
  5. 再基于flink定制的一些优化rules去优化logical Plan;
  6. 生成Flink Physical Plan: 这里也是基于flink里头的rules将,将optimized Logical Plan转成成Flink的物理执行计划;
  7. 将物理执行计划转成Flink Execution Plan: 就是调用相应的tanslateToPlan方法转换。

图片 6

③ Table&SQL API混合使用

Table API和SQL查询可以很容易的混合使用,因为它们的返回结果都是Table对象。一个基于Table API的查询可以基于一个SQL查询的结果。同样地,一个SQL查询可以被定义一个Table API注册TableEnvironment作为Table的查询结果。

④ 输出Table

为了将Table进行输出,我们可以使用TableSink。TableSink是一个通用的接口,支持各种各样的文件格式(e.g. CSV, Apache Parquet, Apache Avro),也支持各种各样的外部系统(e.g., JDBC, Apache HBase, Apache Cassandra, Elasticsearch),同样支持各种各样的MQ(e.g., Apache Kafka, RabbitMQ)。

批数据的导出Table使用BatchTableSink,流数据的导出Table使用的是AppendStreamTableSink、RetractStreamTableSink和 UpsertStreamTableSink.

图片 7

⑤ 解析Query并执行

Table&SQL API查询被解析成DataStreamDataSet程序。一次查询就是一个 logical query plan,解析这个logical query plan分为两步:

  1. 优化logical plan,
  2. 将logical plan转为DataStream或DataSet

一旦Table & SQL API解析完毕, Table & SQL API的查询就会被当做普通DataStream或DataSet被执行。

5.2 Table转为DataStream或DataSet

图片 8

5.3 Convert a Table into a DataSet

图片 9

5.4 Table & SQL API与Window

Window种类

  • tumbling window (GROUP BY)
  • sliding window (window functions)

① Tumbling Window

WX20171124-115353

② Sliding Window

WX20171124-115353

5.5 Table&SQL API与Stream Join

Joining streams to streams:

WX20171124-115758

六、 Table&SQL API举例

首先需要引入flink关系型api和scala的相关jar包:

WX20171124-115924

6.1 批数据的相关代码

WX20171124-120116WX20171124-120425

6.2 流数据的相关代码

WX20171124-120640 WX20171124-120705 WX20171124-120729

七、动态表

flink 1.3以后,在flink SQL上支持动态表查询,也就是说动态表是持续更新,并且能够像常规的静态表一样查询的表。但是,与批处理表查询终止后返回一个静态表作为结果不同的是,动态表中的查询会持续运行,并根据输入表的修改产生一个持续更新的表。因此,结果表也是动态的。在动态表中运行查询并产生一个新的动态表,这是因为流和动态表是可以相互转换的。

流被转换为动态表,动态表使用一个持续查询进行查询,产生一个新的动态表。最后,结果表被转换成流。上面所说的只是逻辑模型,并不意味着实际执行的查询查询也是这个步骤。实际上,持续查询在内部被转换成传统的 DataStream 程序去执行。

动态表查询步骤如下:

  1. 在流中定义动态表
  2. 查询动态表
  3. 生成动态表

7.1 在流中定义动态表

动态表上的 SQL 查询的第一步是在流中定义一个动态表。这意味着我们必须指定流中的记录如何修改现有的动态表。流携带的记录必须具有映射到表的关系模式。在流中定义动态表有两种模式:append模式和update模式。

在append模式中,流中的每条记录是对动态表的插入修改。因此,流中的所有记录都append到动态表中,使得它的大小不断增长并且无限大。下图说明了append模式。append模式如下图。

图片 10

在update模式中,流中的记录可以作为动态表的插入、更新或者删除修改(append模式实际上是一种特殊的update模式)。当在流中通过update模式定义一个动态表时,我们可以在表中指定一个唯一的键属性。在这种情况下,更新和删除操作会带着键属性一起执行。更新模式如下图所示。

图片 11

 

7.2 查询动态表

一旦我们定义了动态表,我们可以在上面执行查询。由于动态表随着时间进行改变,我们必须定义查询动态表的意义。假定我们有一个特定时间的动态表的snapshot,这个snapshot可以作为一个标准的静态批处理表。我们将动态表 A 在点 t 的snapshot表示为 A[t],可以使用 SQL 查询来查询snapshot,该查询产生了一个标准的静态表作为结果,我们把在时间 t 对动态表 A 做的查询 q 的结果表示为 q(A[t])。如果我们反复在动态表的snapshot上计算查询结果,以获取进度时间点,我们将获得许多静态结果表,它们随着时间的推移而改变,并且有效的构成了一个动态表。我们在动态表的查询中定义如下语义。

查询 q 在动态表 A 上产生了一个动态表 R,它在每个时间点 t 等价于在 A[t] 上执行 q 的结果,即 R[t]=q(A[t])。该定义意味着在批处理表和流表上执行相同的查询 q 会产生相同的结果。

在下面的例子中,我们给出了两个例子来说明动态表查询的语义。在下图中,我们看到左侧的动态输入表 A,定义成append模式。在时间 t=8 时,A 由 6 行(标记成蓝色)组成。在时间 t=9 和 t=12 时,有一行追加到 A(分别用绿色和橙色标记)。我们在表 A 上运行一个如图中间所示的简单查询,这个查询根据属性 k 分组,并统计每组的记录数。在右侧我们看到了 t=8(蓝色),t=9(绿色)和 t=12(橙色)时查询 q 的结果。在每个时间点 t,结果表等价于在时间 t 时再动态表 A 上执行批查询。

图片 12

这个例子中的查询是一个简单的分组(但是没有窗口)聚合查询。因此,结果表的大小依赖于输入表的分组键的数量。此外,这个查询会持续更新之前产生的结果行,而不只是添加新行。

第二个例子展示了一个类似的查询,但是有一个很重要的差异。除了对属性 k 分组以外,查询还将记录每 5 秒钟分组为一个滚动窗口,这意味着它每 5 秒钟计算一次 k 的总数。 我们使用 Calcite 的分组窗口函数来指定这个查询。在图的左侧,我们看到输入表 A ,以及它在append模式下随着时间而改变。在右侧,我们看到结果表,以及它随着时间演变。

图片 13

与第一个例子的结果不同的是,这个结果表随着时间而增长,例如每 5 秒钟计算出新的结果行。虽然非窗口查询更新结果表的行,但是窗口聚合查询只追加新行到结果表中。

无论输入表什么时候更新,都不可能计算查询的完整结果。相反,查询编译成流应用,根据输入的变化持续更新它的结果。这意味着不是所有的有效 SQL 都支持,只有那些持续性的、递增的和高效计算的被支持。

7.3 生成动态表

查询动态表生成的动态表,其相当于查询结果。根据查询和它的输入表,结果表会通过插入、更新和删除持续更改,就像普通的mysql数据表一样。它可能是一个不断被更新的单行表,或是一个只插入不更新的表。

传统的mysql数据库在故障和复制的时候,通过日志重建表。比如 UNDO、REDO 和 UNDO/REDO 日志。UNDO 日志记录被修改元素之前的值来回滚不完整的事务,REDO 日志记录元素修改的新值来重做已完成事务丢失的改变,UNDO/REDO 日志同时记录了被修改元素的旧值和新值来撤销未完成的事务,并重做已完成事务丢失的改变。基于这些日志,动态表可以转换成两类更改日志流:REDO 流和 REDO+UNDO 流。

通过将表中的修改转换为流消息,动态表被转换为 redo+undo 流。插入修改生成一条新行的插入消息,删除修改生成一条旧行的删除消息,更新修改生成一条旧行的删除消息以及一条新行的插入消息。行为如下图所示。

图片 14

左侧显示了一个维护在append模式下的动态表,作为中间查询的输入。查询的结果转换为显示在底部的 redo+undo 流。输入表的第一条记录 (1,A) 作为结果表的一条新纪录,因此插入了一条消息 +(A,1) 到流中。第二条输入记录 k=‘A’(4,A) 导致了结果表中 (A,1) 记录的更新,从而产生了一条删除消息 -(A,1) 和一条插入消息 +(A,2)。所有的下游操作或数据汇总都需要能够正确处理这两种类型的消息。

在两种情况下,动态表会转换成 redo 流:要么它只是一个append表(即只有插入修改),要么它有一个唯一的键属性。动态表上的每一个插入修改会产生一条新行的插入消息到 redo 流。由于 redo 流的限制,只有带有唯一键的表能够进行更新和删除修改。如果一个键从动态表中删除,要么是因为行被删除,要么是因为行的键属性值被修改了,所以一条带有被移除键的删除消息发送到 redo 流。更新修改生成带有更新的更新消息,比如新行。由于删除和更新修改根据唯一键来定义,下游操作需要能够根据键来访问之前的值。下图描述如何将上述相同查询的结果表转换为 redo 流。

图片 15

插入到动态表的 (1,A) 产生了 +(A,1) 插入消息。产生更新的 (4,A) 生成了 *(A,2) 的更新消息。

Redo 流的通常做法是将查询结果写到仅append的存储系统,比如滚动文件或者 Kafka topic ,或者是基于key访问的数据存储,比如 Cassandra、关系型 MySQL。

切换到动态表发生的改变

在 1.2 版本中,flink 关系 API 的所有流操作,例如过滤和分组窗口聚合,只会产生新行,并且不能更新先前发布的结果。 相比之下,动态表能够处理更新和删除修改。

1.2 版本中的处理模型是动态表模型的一个子集, 通过附加模式将流转换为动态表,即一个无限增长的表。 由于所有操作仅接受插入更改并在其结果表上生成插入更改(即,产生新行),因此所有在动态append表上已经支持的查询,将使用重做模型转换回 DataStreams,仅用于append表。

最后,值得注意的是在开发代码中,我们无论是使用Table API还是SQL,优化和转换程序并不知道查询是通过 Table API还是 SQL来定义的。由于 Table API 和 SQL 在语义方面等同,只是在样式上有些区别而已。

八、总结

本篇文章整理了flink关系型API的相关知识,整体上来说,flink关系型API还是很好用的,其原理与实现结构清晰,存在很多可借鉴的地方。

 

Reference:

  1. http://flink.apache.org/
  2. Flink社区
  3. 2017 Strata Meeting
  4. 2017 Flink Forward Meeting
  • 十一 24 / 2017
  • 0
Ideas

锐眼发现 | Andrej Karpathy发文谈神经网络后,引发的对硬件、软件和学件的思考

作者:Uri Yerushalmi

编译:雷锋网

本文转自雷锋网,如需转载请至雷锋网官网申请授权。

雷锋网按:近日,Tesla AI总监Andrej Karpathy发表了一篇关于“Software 2.0”的文章,该文章引发了对未来神经网络的编程方式的更深入探讨,本文就是其中之一。在Software 2.0的基础上,本文作者Uri Yerushalmi还借用了南京大学周志华教授在2016年提出的“学件”(Learnware)的概念,并更详细地讲述了他眼中的“学件”和软件的区别。他山之石,可以攻玉,本着传递更多信息的想法,雷锋网特此编译该文章,供读者讨论。

本文作者Uri Yerushalmi为AI社区Dopamind的创始人, 2008年于以色列Bar-llan University获得计算机和神经科学博士学位。以下是雷锋网编译的文章全文:

本周,我阅读了Andrej Karpathy的“Software 2.0”,他分析了新软件“Software 2.0”与旧软件“Software 1.0”之间的区别。 我和Karpathy有一个非常类似的结论,我们来看看这种新型软件的兴起如何影响软件行业和市场。

软件vs学件

以下是旧软件和Karpathy的帖子中描述的新的适应性软件之间的一些主要区别,我将其称为“学件”(雷锋网注:“学件”(Learnware)的概念最早由南京大学教授周志华2016年提出,是一种包含模型和模型描述模型规约的机器学习应用模型,这些模型可以以共享或定价的方式放在某一个地方,当有新的用户想做自己的应用的时候,可以先去市场上看看有没有可以使用的模型,从而可以部分重用别人的结果而不需要重新开始)。 

软件与学件的差异

“学件”将给软件市场带来什么变化?

您可能已经注意到软件市场开始发生变化,尽管这些变化并不明显。

协作处理和服务导向

在软件中,我们习惯通过库和API(应用程序编程接口)进行相互协作。每个接口的任务都需要定义好,用户通常很清楚在调用接口时做了什么、以及如何做。

举个例子,想象两个没有菜单、按顾客指示烹饪的餐馆:

第一家餐厅叫“旧软件类型”:客人需要准确地给予指示他们想要的餐点该如何烹饪。他们必须出示详细的食谱,以确保他们获得正确的食物。

第二家餐厅叫“学件”,客人会提出更多的抽象要求,比如“我很伤心,给我一些能让我开心的东西”,厨师能够当场创造出最佳的餐点。

很显然,第一家餐厅的一些顾客宁愿避免编写食谱的麻烦而改为在家做饭,对不对?但在第二家餐厅,顾客就算想自己编食谱,臣妾也做不到啊啊啊。

这样的底线通常会导致API用户采取“我最了解我所需要的,所以我会自己编程”的方法(这通常是错误的事情,但这又是另一个故事了)。在学件中,“我会自己做”的方法更加不合理,因为通过简单地定义用户需要什么(例如“在图片中找到一只猫”),开发人员仍然没有接近最终的解决方案。

由于这种巨大差异的客观存在,我认为在不久的将来会有越来越多的协作处理工具和平台出现。

主要影响因素见上表中的F、G、H项

“学件”的应用领域

我们可以将大多数使用软件2.0的方法的商业应用归入“学件”的范畴。这些新应用包括基于视觉和语音识别,视觉生成,语音合成,机器人技术,游戏,翻译,决策等。

主要影响因素见上表中的A项

人才市场

显然,“学件”将大大改变就业的市场格局。无论企业如何设计将知识或数据“喂”给“学件”的工作岗位(如程序员,数据科学家,定量分析),“学件”的培训会越来越普遍和越来越简单,使用这一新软件所需的技能将会发生进化。我预计未来对于开发人员角色的需求将与旧软件程序员完全不同。

主要影响因素见上表中的B、C、D项

“喂知识/数据”的技巧

作为一名软件开发人员,您可以使用C ++、Java或Python等语言将知识编程到软件中。目前,编写和训练“学件”使用相同的技术,然而,常规的软件编程语言视为了能够最好地描述,管理和维护各种指令集而设计的,但在“学件”中,编程知识的关键在于准确地描述最佳的数据流图。因此,我不确定使用旧的编程语言是开发“学件”的最佳方法。

主要影响因素见上表中的C、D项

用于构建学习软件的软件库

近几年来,我们已经看到了这些新的软件库:Tensorflow,Pytorch,Keras,Theano,MXNet …

主要影响因素见上表中的B、C、D项

专用硬件

在具有大型指令集的旧式软件中,引入新硬件需要对编译和代码级别进行调整。相反,在“学件”中,新硬件的使用更加透明。 对“学件”适用的专用硬件的竞赛已经打响,目前NVidia处于领先地位。

主要影响因素见上表中的B、E项

查看黑盒的工具

为了更好地进行开发,我们需要用于查看“学件”的黑盒的工具。如果我们了解每个“学件”如何做出决策,我们可能会更好地训练它。此外,从社会的角度看也更容易获得认可(例如,欧盟成员国预计通过新的立法,规定如果AI的决定出现不公平或随意性,AI的决定可能会被推翻,而在“通用数据保护条例”(GDPR)的早期草案也从法律上规定了所谓的“解释权”)。

主要影响因素见上表中的H项

Dopamine.ai正在对这方面的协作处理解决方案进行努力。如果您有兴趣阅读更多内容或接收我们项目的更新,请点击此处进行订阅

  • 十一 23 / 2017
  • 0
Ideas

锐眼洞察 | iOS的未来是AI(翻译)

作者:Svilen Kostadinov

原文:Why Artificial Intelligence Is the Future of iPhone’s iOS

译者:TalkingData首席架构师 黄洋成(YC)

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

 

自十年前首次亮相以来,iPhone已经发生了翻天覆地的变化:运行速度有了指数级的提升,屏幕和相机在各种指标上都有了很大的提升(初代iPhone甚至无法录制视频),而外形也已经完善, 还不断增加新的传感器。 虽然苹果的工业设计在制造业不断开创新领域,但其软件多年来一直处于低谷。

智能手机,傻操作系统

当然,功能和美学都有了明显的改善,但除了(被史蒂夫·乔布斯强烈反对的)App Store之外,iOS 1和iOS 11之间的体验差异并不是很大:

无论是白天还是夜晚,在家或在国外使用iPhone,你每天收到哪些朋友的信息,你在午休时玩的是什么游戏,或者你家中有什么智能设备 – 只要你解锁手机,就会被置于相同的静态多屏应用图标网格中。

更过分的是,应用程序的管理和分组的负担也要留给用户,让他们依靠肌肉记忆来找到App的位置。

 

“数字化体验应该动态适应用户需求”的想法其实并不新鲜:

  1. Netflix推荐你可能感兴趣的电影、你会继续观看的节目、最新播出的节目、节目的流派/分类等
  2. 亚马逊向你推荐你最近搜索的商品、搭配购买的商品、打折促销的商品等
  3. Spotify根据你的口味组织个性化的播放列表

对于苹果来说,他们也已经开始在往这个方向走,比如Siri的联系人和应用程序建议,在锁屏上基于地理位置的应用程序建议(不知道它是否仍然存在于iOS 11):

但哪怕只是在正确的地点和时间推荐正确的应用程序的能力现在似乎都还没有。 根据帕累托原则,80%的时间里我们只使用应用程序20%的功能。

Facebook就是一个很好的例子:它包含了从信息流和视频,到故事、市场、群组、趋势新闻、天气、游戏和城市指南等所有内容。 但是,所有这些功能中,我敢打赌,超过80%的时间用户只是使用信息流。

所以,相对于推荐Facebook这个App,为什么不直接推荐信息流?你可能在想,单个功能如何模块化? 其实苹果也有一个潜在的解决方案——部件化。

   

 

不幸的是,组件化屏幕与主屏幕出现相同的问题:它只是一个静态库存列表。

具有讽刺意味是,新的iPhone有一个专用的A.I.处理器,但iOS的使用体验并没有从你的使用模式或偏好中学到什么。 但如果iPhone做到了呢?

如果你的手机了解你在何时何地、出于何种原因、使用何种功能,会怎样?

在2015年初,我在几个常见的场景中探索了一个以部件化为中心的iOS概念:

机器学习有可能使iPhone真正智能化、能够学习我们使用手机的上下文和环境。 更进一步,通过将地理位置、邻近的朋友、环境光线、噪音水平和Apple Watch采集的生命体征等因素关联起来,将带来全新的体验和服务。

下一代移动操作系统

Google似乎验证了这种动态交互的范式。在2017年,Google披露了他们实验性移动操作系统FUCHSIA的一瞥; 虽然迄今为止我们仍对它知之甚少,但它主要的前提似乎是围绕类似于部件化的模块,围绕用户的需求进行智能化安排:https://youtu.be/dziInGrVHac

无论部件化是否是正确的解决方案,有一点是明确的:随着世界动态性不断增强,我们需要更流畅、更无缝的手机和智能手表体验。 是时候重新思考我们与设备互动的基本方式了,因为静态应用范例的可用性已经在不断增长的苹果生态系统中达到了极限。

  • 十一 22 / 2017
  • 0
Data, Tech

锐眼洞察 | 数据目录应该拥哪些能力?

作者:TalkingData数据产品经理  史忠贤

本文为TalkingData原创,未经授权禁止转载。申请授权请在评论中留言联系!

从去年开始,一直在思考什么样的数据目录才能满足数据管理的需求,但是由于没有真正的深入到数据治理和数据业务流程中,一直没有比较清晰的思路。今年在梳理标签数据、做数据标准化等过程中,才深刻的认识到数据的杂乱和无序会严重浪费计算和存储资源、增加沟通成本。资源浪费主要体现在,不同人员重复生成一些数据集。沟通成本增加主要体现在,数据和数据规格说明的分离,以及数据集的问题和知识没有沉淀。

针对以上问题,结合当前数据治理中数据目录使用情况和行业调研,对数据目录应有的能力有了更加清晰的认识,总结如下:

一、数据的连接和发现能力

做数据治理就需要清晰的知道公司有哪些数据,通过人工梳理的方式显然已经跟不上数据增长和变化的速度。所以,一个数据目录最基础的能力,就是可以连接公司拥有的多种数据源(如:HDFS\MySQL\Hbase…),并且可以定时的监测新生成的数据,在数据目录中根据规则自动注册为数据集或更新数据集状态(如:对关系型数据库新产生的表注册为数据集,HDFS分区格式数据只更新当前数据集的容量大小)。

二、元数据管理能力

  1. 数据集基本信息:包括数据集的名称、标签、负责人以及存储详情的变动趋势。
  2. 字段描述信息:字段的物理存储类型、字段的业务类型(地址、IP地址等)、字段的描述信息、整个schema的版本控制(尤其对SDK采集到的数据有用)
  3. 数据规格:数据规格是数据资产部门或者数据负责人维护数据说明的页面,包括数据生成方式、数据使用范围、主意事项等。提供数据规格编写能力,方便版本控制,用户可以按照时间线来查询数据规格。

三、数据profile能力

  1. 数据集的条数、空值等。
  2. 针对枚举字段枚举值的统计,针对数据类型字段数值分布范围的统计。
  3. 用户自定义策略的统计。提供用户自定义界面,可以组合各种规则统计数据集中满足条件的数据条数。
  4. 针对各类指标的时序可视化展示。数据的profile有了时序的概念,才能做一些数据趋势的分析,以及监控和报警。
  5. 可配置的数据集profile计算频率。不同的数据集,数据量差距很大,针对MySQL的一个小表profile可能秒出,ETL产生的天库一天的数据只能定时运行了。

四、协作和分享能力

  1. 协作能力:主要体现在数据集相关问题的处理上面。使用数据集时遇到的问题可以在系统中提问,问题会自动转向数据集负责人,数据集负责人需要在系统中答复。所有问题和回答应该以时间线的方式组织,方便其他数据集使用人员的查阅和检索。
  2. 分享能力:关于某个数据集的所有信息,不再以口口相传的形式进行,将数据集及相关信息分享给使用者,使用者可以看到数据集的元数据等详情。

五、检索筛选和用户自组织能力

  1. 检索筛选能力:如果数据目录没有强大的检索能力,系统中数据集的信息和沉淀的相关知识就不能实现其价值,也不能促进系统的良性循环。检索和筛选的内容包括:数据集名称、标签、描述、字段相关信息、问答内容、数据规格详情等。
  2. 用户自组织数据集的能力:不同用户使用数据集的场景不一样,所以组织方式也会不一样。每个用户可以按照自己的理解和需求组织自己的数据目录,方便用户的使用。同时,不同用户根据不同场景对数据集的组织方式也是一种知识,可以沉淀。

六、安全和开放能力

  1. 权限和审计:为数据集的访问提供权限控制。不同的用户在不同的时间有不同的权限,所有用户对数据集的操作都需要做记录。
  2. 开放能力:数据目录应该提供数据集的访问接口,可以支持内部数据探索工具、数据ETL工具的调用,可以支持外部客户的调用和加工。

附总体能力脑图:

数据目录.png

  • 十一 22 / 2017
  • 0
Tech

锐眼洞察 | 报告:接近技术提升商业银行的竞争力(翻译)

作者:Greg Sterling

原文:Report: Location data provides ways to differentiate in a commoditized banking sector

译者:TalkingData CTO 肖文峰

本文著作权归原作者所有。本译文禁止商用,转载请注明来源与译者!

译者注:接近技术(Beacon、WIFI、NFC等)作为越来越重要的场景触发的手段,广泛应用于各种线下商业过程的用户体验提升。

更详细的案例可以参看报告原文:https://www.proximity.directory/reports/

Unacst的报告大家可以关注一下,列举了接近技术字各个行业的使用案例,对我们的零售、房地产、金融等领域有一定借鉴意义。

个性化、提高效率和增强客户体验,是Unacast季度报告中引用的一些例子所要表达的关键词。

位置数据平台Unacast最近发布了其Q3的Proximity.Directory报告。Unacast每个季度都会发布报告,展示位置技术在不同的细分市场或垂直领域中的应用。

Q3的报告考察了金融服务行业使用位置情报的情况。报告提出的一个有趣的观点是,虽然信用卡交易数据越来越多地被用于许多场景(例如,消费者行为分析、公司收入预测),但它描述的并不全面,因为现金仍被广泛使用,多达32%的离线交易都是通过现金完成。

Unacast还认为,虽然银行也已经深度市场化,但位置数据依然可以用来提高效率、客户体验和忠诚度:

  • 品牌广告和ATM设备位置优化 – 基于步行和交通模式、邻里特征和其他与现实世界行为相关的变量。
  • 个性化功能,以满足不断上升的消费者期望。
  • 针对银行客户的高级或增强型服务,例如向ATM机发送接近警报,以消除实物卡提取现金的需要。

该报告讨论了欧洲和美国银行围绕移动支付、合规和消费者便利体验的几个案例研究。其中一个案例涉及花旗银行的试点项目,试图实现以下目标:

  • 提供与客户环境和地点相关的更具针对性的移动体验。
  • 提供安全的基于应用程序的方法来使用ATM设备(特别是在晚上)。
  • VIP进入银行时,给银行员工提醒。

报告指出,全球现在有1730万个接近传感器被使用。此类别包括一系列技术:信标(比如Beacon)、WiFi、NFC等。信标仍然是当今最流行的接近传感器,大部分的部署如下:

  • 信标 – 58%。
  • WiFi(用于位置感知) -25%。
  • 近场通信(NFC) – 17%。

虽然信标部署是“稳定的”,但是根据报告,其他类的技术使用比例正在增加。

美国仍然是接近传感器和相关技术的主要市场。然而,其整体领先地位从全球部署的35%略有下降到本季度的33%。接下来的国家是英国、加拿大和印度。然后是法国,意大利,西班牙和澳大利亚(均为3%)。

根据Unacast的统计,以下是全球涉及接近传感器市场的软件公司排名:

00.png

该报告还定期研究多个垂直领域的技术渗透情况。下图比较了2017年第三季度和2016年第三季度各行业(全球)接近传感器的部署情况。

01.png

位置智能越来越多地是关于洞察和分析,而不是推送通知和直接面向消费者的营销。这个数据指出的其中一个较大的故事是,信标作为一个定向选择技术,正在被纳入更广泛的范畴——接近技术。

 

  • 十一 22 / 2017
  • 0
Tech

锐眼发现 | 共识算法的比较:Casper vs Tendermint

作者:Chjango Unchained

原文:Consensus Compare: Casper vs. Tendermint

转载于:简书

译者:许莉

校对:郭光华

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

权益证明的漫漫长路

权益证明的定义可以查看理解权益证明

1982年,拜占庭将军问题首次被Lamport,Shostak和Pease提出。Cosmos的Ethan Buchman这样描述它:”这是一个在可妥协的通信网络中实现分布式协议的问题,也就是在不可靠的环境中建立一个可靠的系统的问题“。从1982年到1999年,都没有人能够创造一个可以解决拜占庭将军问题系统。长久以来,拜占庭将军问题与计算都是无关的,因为在那个时候,互联网演进出基于云的中央中心化计算模式,所需要解决的只是容错问题。

所以,故障容错算法得到普及,例如1998年发明的Paxos算法和2013年发明的Raft算法被广泛的应用。而1999年发明的实用拜占庭容错(PBFT)却没有被学术界之外采用。直到2008年,中本聪将网络规模级别的分布式拜占庭容错(BFT)算法设计到区块链方案中,才使拜占庭容错得到推广。当这种原型出现之后,系统研究界的人都开始围绕将学术界“奇物”应用到真实世界而去构思各种想法。

在2011年,BitcoinTalk论坛对一个叫做权益证明(PoS)的概念组织了一场讨论。最初的PoS协议例如点点币,实现结果的并不理想。第一个真正提出将BFT研究应用到PoS公有区块链环境中是Jae Kwon,他在2014年创造了Tendermint。

在当时,PoS研究做出了很大的假设:假设系统中的一系列对等节点都是静态的,并且在长时间内都是稳定的。在区块链环境中完全是不现实的。 Jae Kwon的重大突破是使Tendermint能够使用区块,哈希链接,动态验证器集合和循环的领导者选举来将BFT研究适应复制状态机(区块链)的领域。

在Tendermint环境中,出现了大量的共识算法(Honeybadger, Ouroboros, Tezos, Casper),它们都包含了BTF研究的元素以及在区块链上其他模块观察的元素。

为权益证明做的所有研究都指向一个重要问题:在不耗尽物质稀缺资源的情况下,我们可以达到工作量证明(PoW)的安全级别吗?这个问题可以转化为:PoS的投票权以链上货币计价而不是计算力计价。区块链的POS共识问题比可扩展性更被广泛讨论,运行PoW挖矿的高开销成本以及环境外部性方面存在的问题都刺激了大量资源涌入PoS安全研究。

本文主要探讨了在加密货币中使用了权益证明的三个主要PoS协议的特性:由Vlad Zamfir带领研究的Casper the Friendly Ghost(CTFG)和由Vitalik Buterin带领研究Casper the Friendly Finality Gadget(CFFG)以及Jae Kwon带领研究的Tendermint

权益证明的陷阱

无利害关系

起初,有多种不同的说法来描述权益证明的一般陷阱,无利害关系就在这时被提出。Jae Kwon 2014年5月以“错误选择谬论”的不幸名字第一次提到这个问题。在2014年7月Vitalik把比特币开发者所描述的确切定义的问题普及推广为“无利害关系”。问题呈现出此情况:验证者通过在给定高度为多个有冲突的区块投票可以有效的破坏安全性而不用付出任何代价。

简单的PoS实现对于这些攻击而言是非常脆弱的。灾难性的是,因为没有任何的激励来鼓励大家永远集中在一个独一的链上,并且每次激励都要同时在相互冲突的链条上进行重复签名,所以为了获得更多的区块奖励,在经济上最优的策略就变成了尽可能的在多个分杈上进行投票。下面这张图就展示了:

在简单的PoS设计中竞争链上的期待投票数高于单一链上期待的投票数

在工作量证明中,对于在多个链上进行挖矿的矿工“惩罚”是他们必须分开他们的计算力(非常稀缺的资源)。在现代非简并的PoS设计中,这种成本必须嵌入到协议里面以此模仿物理PoW挖矿的限制。

Vitalik Buterin在2014年1月引入的“slasher”概念或协议内惩罚可以减轻这个攻击。Jae Kwon在同一年进一步推算了此方法,这是实现Tendermint共识协议的第一个迭代进展。苛刻以及允许这种惩罚的条件,对于所有的非简并BFT协议都是有帮助的,甚至在本文中出现的三种共识都采用了。

远程攻击

远程攻击来源于用户不得不撤回保证金的权利。这就产生了一个基本问题,因为这意味着攻击者可以从任意长度的距离建立一个分杈而不用担心被削减。一旦保证金被解除绑定,激励不从某个高度区块前进行长距离投票就被取消了。换句话说,当超过2/3的验证者解除了绑定,那么他们就可以恶意的创造包含之前验证者集的第二条链,这可能导致任意的交易。

对于权益证明协议这是相当致命的,因为安全模型必然是“主观”的。当参与网络要求大量的社会信息,那么这个安全模型就会被称为是“主观的”。一个新节点加入网络之后,对于当前网络的状态可能会得出不同的结论,因为他们的决策是基于主观信息的,即社会声誉。在相反面,工作量证明的安全模型必然是“客观的”,因为当前网络状态总是工作量最多的那个状态,新节点对于网络状态的结论总是相同的,因为他们的决策是基于客观信息。

PoS的远程攻击在弱主观性模型下进行了纠正,这要求接入到网络中的后续新节点:

  • 当前必须是被绑定的。只相信当前有保证金的验证节点
  • 解除绑定保证金必须要经过一个”解冻”期。解除绑定之后,代币需要数周到数月的“解冻”时间,用以实现“同步性”前提(即延迟的消息)
  • 禁止在N个块之前恢复,其中N是保证金的长度。 这个规则使任何长程分杈无效。
  • 可选择的将验证者集存放在PoW的链上

Casper(s)和Tendermint采用一种简单的锁定机制(“Tendermint”中俗称“冻结”)来锁定股权一段时间(几周到几个月后“解冻”),以防止任何恶意联合验证者 违反安全。在CFFG算法中,一个分杈选择规则永远只能修改最终块之后的块阻止了远程攻击。通过使用时间戳,在CFFG中的长距离分叉试图修改比最终块还要更早的块的时候会被协议直接忽略掉。

卡特尔形式

第三,最后的障碍是面临任意价值的任何经济形式都将面对一个真正的寡头垄断问题,就算本土加密货币也不例外。

“加密货币令人难以置信的集中,挖矿算力也是一样。寡头垄断竞争是很多现实市场的常态。少数相对富有的验证者之间的协调比多数相对贫穷验证者之间的协调要容易的多。在我们这种情况下,卡特尔形式是完全被预料到的。”
——Vlad Zamfir,Casper的历史第4章节

Tendermint依靠额外协议管理方法来与寡头垄断验证者进行对抗。虽然在审查制度方面没有任何协议措施,但依靠带外社会信息解决卡特尔形成,其中的基本原理是:用户最终将不可避免地注意到卡特尔的形成,社会上也会对此到处八卦,然后放弃或者投票重新组织受到攻击的区块链。

到目前为止,Vlad的Casper协议是唯一一个明确使用共识内审查激励来打击卡特尔形式一种模式。

概述

有很多不同的方式来实现权益证明的算法,但是权益证明设计的两个主要原理是基于链的PoS和基于拜占庭容错(BFT)的PoS。Tendermint是基于拜占庭容错的PoS设计,CTFG是基于链的PoS设计,而CFFG则混合了两者。

计算机科学中的CAP理论返回在分布式数据系统中提供超过2/3担保的不可能性:可用性、一致性、分区容错。基于链的PoS算法倾向于选择可用性高的而不选择一致性高的,因为可用性高意味着所有的交易都能被处理,不过要以牺牲整个网络中一致性状态复制为代价。基于BFT的却相反,会倾向于选择高一致性。

基于BTF的权益证明

拜占庭容错共识算法源于30多年的丰富研究。Tendermint(2014)是Castro和Liskov在1999年引入的实用拜占庭容错(PBFT)算法的第一个PoS的改编版。基于BFT的PoS协议伪随机的安排一个验证者在多轮投票的过程中提出一个区块。但是,提交和最终化区块取决于大多数——所有验证者中2/3的验证者在提交的区块中签名。在区块最终化之前可能需要进行几轮(译者注:这种多轮投票和现实世界的波尔卡舞蹈类似, 这也是polkadot 名字的由来)签名。BFT系统只能容错1/3的失败,其中失败包括故障或是恶意的攻击。

Tendermint核心

Tendermint主要包含两个主要的技术:区块链共识引擎和通用的应用接口。共识引擎被称为Tendermint核心模块,确保相同的交易在每个机器中都按照相同的顺序被记录下来。应用接口被称为应用区块链接口(ABCI),让交易可以被任何编程语言编写的程序处理。
在核心模块中,Tendermint基于循环投票机制进行工作,这也是共识协议的原理。一个回合被分成3个处理步骤:验证者提出一个块、发送提交意图、签名后提交一个新区块。这种机制为原子广播提供了一个安全的状态复制机,增加了一个责任层——安全故障可以完全归结于Tendermint。

Tendermint共识算法从验证者集开始。验证者们都维护了一份区块链的全拷贝,并且可以用公钥来识别验证者的身份。在每个新的块高度他们轮流的提出一个区块。每轮投票都只有一个验证者可以提出块,并且要用验证者相应的私钥对此进行签名,这样的话如果有错误发生就可以找到为此负责的验证者。然后剩下的验证者就需要对每个提议都进行投票,投票都需要用自己的私钥进行签名。这些组成一个回合。不过可能因为网络的异步需要好几个回合才能提交一个新块。

验证者提交块的时候由于几种原因可能会失败:当前的提议可能下线了,或者网络可能遇到了延迟。Tendermint允许验证者可以被跳过(就是轮到一个验证者出块的时候但是此验证者没出块)。验证者在移到下一轮投票之前等待一小段时间来接收提议者(此轮出块的验证者)提出的整个区块。这种对超时的依赖让Tendermint成为一个弱同步协议,而不是一个异步协议。不过,剩下的协议是异步的,并且验证者只有在接收到了超过2/3的验证者集消息时才会进行处理事物。正是因为这样,所以Tendermint需要大多数的验证者可以100%正常运行,如果1/3或更多的验证者离线或脱机,网路就会停止运行了。

假设少于1/3的验证者是拜占庭,Tendermint保证安全永远不会被破坏——也就是,验证者(2/3以上)永远不会在同一个高度提交冲突的区块。因此,基于Temdermint的区块链永远不会分叉。

目前为止,Tendermint的设计决策确实是把安全性和不可改变性地位放在了灵活性之上。在现实世界上有相当高的可能性是,系统真的会停止运行,参与者将会需要在协议外组织在某种软件上更新后重启系统。

在数字加密货币社区中只有少数人理解 Casper以及为什么它很有价值的时候,Tendermint就为Casper研究奠定了基础。这个洞察力就是:如果一个链的本身是高度容错的,那么你就可以依赖链来对于谁来生产区块做出一个好的决定,但是如果链的本身就是不可靠的,那么你就陷入了鸡和鸡蛋的问题中去了,这也是之前所有其他共识算法的灭顶之灾。

这个设计决策被认为不如可用性优先的协议例如以太坊和比特币。比特币中的权衡是:如果它的网络被分裂了,比特币在各种攻击的情况下就失去了它的安全保证。这其实就是一个不可修改理论,也就是你的置信区间是100%的时候,那么你跟随的就是一条正确的链,你会使用这条链来选择谁来生产下个区块,但是一旦你转移到一条不安全的链上之后,并没有一条明确的路径让你回到正确的链上。

Tendermint的明确属性

  • 可证明的活跃性
  • 安全阈值:1/3的验证者
  • 公有/私有链相容
  • 即时的最终确定性:1-3秒,取决于验证者数量
  • 一致性优先
  • 在弱同步性网络的共识安全

基于链的权益证明

基于链的权益证明模仿了工作量证明共识算法,在此权益证明中协议让伪随机选择出来的验证者产生一个新块,新块是哈希连接(包含上个块的哈希值)到前一个最长链的父区块上。基于链的PoS非常依赖同步的网络,通常优先考虑可用性而非一致性。Casper(s)对于倾向于活跃性而非安全性环境而言,它就是Tendermint核心思想的一个改编。

CFFG

CTFG是一个明确的PoS构造,但是CFFG是一个覆盖在已存在的以太坊PoW提议机制上的PoS——融合了PoW和PoS两者,由Vitalik Buterin带领实现。

比特币和以太坊的PoW共识协议都不会做“最终”决定,并且区块可能会潜在的被重新组织到一些过去区块高度。当区块没有机会再被修改的时候才能称为“最终确定”的。因为工作量证明没有提供这样的修改保证,所以它被认为是共识不安全的。相反,当我们持续加长链的时候区块的最终确定性概率也越来越高。为了为以太坊区块链增加想要的最终确定性和51%的攻击阻力,CFFG实现的逻辑就完美的提供了这种效果。

CFFG将通过多个步骤推出,以保守的方式将以太坊的PoW安全模式逐渐过渡到PoS安全模式。Casper的第一个迭代将会是实现这里讨论的混合PoW/PoS协议,Casper的最后一个迭代很有可能吸取CFFG和CTFG的教训,朝着一个完整的PoS协议发展。

CFFG是基于链的PoS和基于BFT的PoS的之间的混合体,因为它吸取了两者的思想。它的模块化覆盖设计让现在的PoW链的更新变得更加容易,因为它对于将系统升级到完全不同的共识模式而言是一种更保守的方法。

Casper的应用逻辑存在于智能合约的内部。要想在Casper中成为验证者,必须要有ETH并且要将ETH存储到Casper智能合约中作为杠杆的权益。在Casper第一次迭代中区块提议的机制会被保留:它依然使用Nakamoto PoW共识,矿工可以创建区块。不过为了最终化区块,Casper的PoS覆盖掌握控制权,并且拥有自己的验证者在PoW矿工之后进行投票。

Casper的PoS共识最重要的一个部分就是检查点(checkpoints)。Casper在50区块增量的时候评估最终确定性就称之为检查点,每50个块片段就称之为周期(epoch)。通过验证者在每个周期发送投票消息时触发这个处理过程。

在一个周期前最终化检查点需要2个周期才能完成,也就是需要两轮投票。例如,当超过2/3的验证者(也就是大多数)给一个检查点c投票了,那么就说这个检查点已经被”审判”了。下一个周期,当大多数人给检查点c投票了,会发生两件事情:c变成了被审判的并且c已经最终化了。c这个周期也就代表着最后一个最终化的周期(LFE)。

回顾一下,一个区块最终化需要两个条件:

  • 大多数(超过2/3)验证者在周期1的时候给区块1进行了投票,因此审判了区块1
  • 大多数(超过2/3)验证者在周期2的时候给区块2进行了投票,区块2是区块1的子区块,因此在周期2的时候最终化了区块1

在理想执行中,一个区块的最终化是按照下面的步骤的:

区块1的2/3投票→审判区块1→2/3投票区块2→最终化区块1

  • 其中区块2是区块1的子区块

当一个检查点被最终化之后验证者就会得到报酬。不过,如果有两个最终化的检查点在相同高度上分杈时,那么就破坏了安全性,这个时候就达到了消减的条件,最少1/3的保证金将会被消减掉。当安全性被破坏的时候可以将错误归因的证据当作交易广播给PoW的矿工。然后PoW就将这个证据交易组成一个区块来进行挖矿,提交了这个证据的验证者会得到查找者的费用。当此事发生的时候,签署了在冲突区块的有罪验证者将会在两条链上被消减掉。

现在如果一个矿工进行蛮力攻击,那么会发生什么?现在Casper的最终化区块链可以防止PoW的攻击者,就算是51%或者更多的计算力重写最新检查点之外的历史也会被阻止。因此,Casper协议提供了安全。不像CTFG,因为CFFG就是不同提议机制上的一层覆盖,Casper不能确保活跃性,因为活跃性是取决于提议机制的。

验证者是被激励着集合在权威链上的,因为如果他们持续在不同的链上进行投票将会受到惩罚。slasher 2.0的形成让验证者不仅仅会为双重投票而受罚也要为在不正确的链上进行投票而受到惩罚。不过这也造成了一个“泄气”的窘境,因为验证者担心如果出现一个分杈而自己不确定到底哪个才是权威的,然后投错票之后被消减所以选择退出投票。

CFFG的明确属性

  • 最终化:超过20分钟最终化。每隔50块(一个周期)就最终化一次区块,防止PoW挖矿暴利攻击
  • 共识安全性
  • 可证明的活跃性
  • 优先可用性

CTFG

CTFG是Vlad Zamfir的正确构造(CBC)共识协议专用于对抗寡头垄断的真实世界的环境。CTFG是工作量证明中GHOS或GHOST协议的PoS改编版,用于其分杈选择规则。CTFG背后的指导设计原则是基于加密经济学的,使用旨在实现评估安全的正规方法。与前面详细说明的CFFG混合协议不同,CTFG是纯粹的权益证明的概念。

“Casper刚刚开始的时候只是简单的‘友好的幽灵’,它对于PoS而言是GHOST的改编,完善的激励让卡特尔‘友善地’变成‘非卡特尔’的验证者。”

——Vlad Zamfir,Casper的历史第5章

与工作量证明类似,CTFG会为一致性和可用性进行权衡。特别,在区块没有被最终化的时候,随着在链中的深度越深的它们就会越安全。CTFG与CFFG有一点相似,链头部的处理总是比区块最终化的处理要快很多。

Casper的PoS提议机制与Tendermint提议机制最大的区别是相比较伪随机选择领导者,前者的验证者可以基于自己见到的块提出块。

Casper提供的一个独特功能是参数化安全阈值。与比特币中使用6个确认来确定一个经济最终状态类似,CTFG中的“评估安全”提供了一个验证者可以有一个与其他验证者不同的安全阈值功能。Casper的设计目标是在网络维持PoS低开销的时候能够允许验证者选择自己的容错阈值。

Casper对Tendermint的核心优势在于网络随时可以容纳一定数量的验证者。因为Tendermint中的区块在创建的时候需要最终化,所以区块的确认时间应该短一点。为了达到短区块时间,Tendermint PoS能够容纳的验证者数量就需要有个限制。由于CTFG和CFFG到在区块创建的时候都不需要安全性,所以以太坊网络相对于cosmos容纳100个验证者来说,可以容纳验证者的数量会更加的多一点。

CTFG的明确属性

  • 可用性。Casper的节点在它们达成共识之前可以块分杈
  • 异步安全性
  • 生存。Casper的决策可以在部分同步中存活,但是不能在异步中存活
  • 卡特尔阻力。Casper的整个前提是建立在抵制寡头垄断攻击者基础之上,因此不会有任何勾结的验证者可以超越协议
  • 安全性。取决于每个验证者的评估安全阈值

未来的工作

公链在产品上运行是一个比较新生的技术。在这个范例中到目前为止显示出不会腐败的唯一安全模型就是工作量证明。权益证明的设计空间还非常的大,而且工程学上权衡的理解也远远不够,因为权益证明是一个研究前沿也没有足够的数据。不用多说,要达到一个最佳的PoS共识算法,我们还有很多未来工作需要完成。

Tendermint的一个改进可能是新的提出机制,或者将Tendermint的多轮投票过程压缩成一轮投票。

第二个未来工作的领域可能是利用更高级的加密技术让区块头的签名更小一点。因为我们是通过Cosmos来建立一个“区块链的互联网”,所以将轻客户端证明从一条链上移到另一条链上就是我们的核心工作。从这个观点来看的话,使用更加高级的密码学将区块头的大小减少三十倍或者更多是非常有利的。目前,100验证者,Tendermint的区块头接近4KB,它们都是验证者的签名。我们可以使用高级的加密技术让100个签名从3.2KB减少到64字节。

还有一些优化p2p层的方法,这样我们就可以显著减少点对点需要最终化块的流量。在未来的工作中,不仅仅是压缩区块头中的数据量,还会减少发送到对端的数据量。这样的话,在Cosmos网络初始100个验证者的阈值之上,Tendermint还可以增加更大的验证者集。

  • 十一 21 / 2017
  • 0
Data

锐眼洞察 | 大数据实施为什么需要方法论指导?(翻译)

作者:Kayla Matthews

原文:Why You Need A Methodology For Your Big Data Research

译者:TalkingData副总裁 高铎

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

译者摘要:

  • 靠谱的大数据方法论指导,能让企业在实施大数据方案时少走弯路;
  • 方法论实施的核心,是能确定收集和整合的数据,以及模型和工具,能够创造商业价值;
  • 实施大数据方案时,既要考虑效能和生产力,也要考虑法律和道德问题。 

靠谱的研究方法可以帮助大数据管理团队收集更好、更智能的信息。利用大数据进行分析的企业,尤其是有靠谱研究方法论指导,其盈利能力和生产效率普遍比竞品高出5~6%。

企业可能认为大数据能大幅提高效率,而立即寻求扩大大数据管理的能力和范围,但如果没有适当的方法论支持,大量时间和金钱的投入很可能无济于事。很多大数据战略失败的公司,都是缺乏关于大数据、分析以及工具之间如何相互作用的规划。

在实施大数据方法论时,一个谨慎的方案应该包括数据科学家、工程技术专家、业务管理人员和高层管理人员,这些角色结合在一起,用他们各自的专业知识来制定全面的计划。项目启动和团队选择是方法论得以成功实施的关键,因为它强调了企业必须做出的决策,以及这些决策如何影响最终目标,以实现更快的增长或更高的利润率。

一个靠谱的大数据方法论,应该明确所处理领域理想的分析工具和模型,确定要集成哪些内外部数据,并制定一个组织架构以适应数据流的目标。

收集和整合数据

大数据是战略决策的生命线,可能会影响公司是否会盈利或遭受损失。特别是在当今数字时代,很多企业都淹没在大量数据里面,挣扎着去寻找相关性。由于社交媒体平台的大量出现,如今的数据量特别巨大,这些平台提供了对客户行为数据的洞察。

搜集数据和了解哪些数据是优先考虑因素,是建立方法论的重要方面,它可以指出在哪些新数据能力方面需要进一步投入。短期选择可以是把问题外包给外部数据专家,虽然这可能是昂贵的,对有些企业来说甚至要求过高。在企业内部,可以通过将交易数据和其它数据分开来整合分析报告,也可以尝试实施一些数据治理标准,以避免在准确性和一般合规性方面的失误。

利用分析模型和工具

虽然实施方法论时,数据的整合是至关重要的。但是如果没有高级的分析模型来帮助优化结果并根据这些数据做预测分析,那么整合就没有多大价值。方法论是要确定模型如何创造商业价值,譬如关于客户购买历史数据,如何影响他们通过电子邮件收到的折扣类型。

另外,方法论要能利用分析模型来帮助企业解决数据存储的优化问题。从有意义的数据中分离出多余信息的模型,可能会触动企业的底线,会对生产结果造成巨大的影响。将数据集成到日常流程和业务活动中的工具,可以为许多功能提供一个易于理解的界面,无论是员工时间表,还是决策提供哪种优惠券。

而行业将关注其核心领域的数据。如运输公司比店面更依赖GPS和天气数据,而医院则需要有关药物功效的数据。无论如何,分析大数据的关键点是最重要的,尤其是分析它们如何与日常生活相互作用。

实施方法论的挑战

有效的大数据研究方法论将有助于解决企业面临的一些常规问题,尤其是将投资重点与公司战略结合考虑的时候,重点将聚焦在业务参与与成本之间的平衡。

如果能检测异常数据集,将会提高前端业务参与度和总体效率,有助于提醒需要手动参与分析的研究人员(优化预先存在的机器学习算法和自动交易数据)。大数据研究的方法论应该能准备好时刻识别异常,并制定计划如何去解决这些异常。

此外,无视负责任的大数据研究方法论,可能会陷入法律和道德问题,因为其涉及数据共享和用户数据的使用,特别是在社交网络里面。因此,方法论应该在考虑效率和生产能力时,也要考虑道德。

大数据方法论研究中考虑相关道德问题,通过相关分析工具将数据收集并整合到有组织的系统里面,可以更合规地提高企业的生产效能和盈利能力。

 

  • 十一 21 / 2017
  • 0
Data

锐眼洞察 | Azure Databricks技术概览(翻译)

作者:Matei Zaharia & Peter Carlin 

原文:A Technical Overview of Azure Databricks

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

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

译者注:
从前年就从Databricks的一些朋友了解到Databricks在构建基于Spark的云平台。如今这个世界是云的时代已经是个勿容置疑的趋势。传统的IT厂商都在做云端的转型,比如Oracle已经决定将自己安身立命的Oracle数据库都变成云端的服务了。Databricks作为Spark的核心贡献者,其商业模型势必是要走到云端提供端到端的大数据平台。这篇文章就是关于Databricks和Azure Cloud的深度集成的Azure Databricks。回到我们自身,我坚信我们的未来也是与云化密不可分的。

今天,我们在Microsoft connect(); 介绍了Azure Databricks,一个结合了业内最好的Apache Spark分析平台和Azure Cloud的能力的令人兴奋的新的服务。通过Databricks和微软的紧密的合作,Azure Databricks带来了在其他的云平台上都不具备的独特的价值。这篇博客将会介绍这个新的技术以及通过Azure上的Databricks给数据科学家、数据工程师和业务决策者带来的新的能力。

Apache Spark + Databricks + Enterprise Cloud = Azure Databricks

当你在云上管理大量的数据的时候,你给预测分析、AI和实时应用带来了无限的可能。在过去的五年中,构造这些应用选择的平台是Apache Spark,由于有全球数以千计的企业组成的庞大的社区,Spark使得实时的运行大规模的强大的分析算法成为可能,从而能够支持进行业务洞察。然而,大规模的部署和管理Spark仍旧是个挑战,尤其是对于有大量的用户并且需要很强大的安全要求的企业客户。

进入Databricks,公司是2013年由启动Spark项目的团队创建的。Databricks提供针对云平台进行优化的端到端的托管式的Spark平台。通过一键部署、自动弹性伸缩、以及优化的可以在云上以10倍到100倍提高性能的Spark运行时环境,Databricks使得运行大规模的Spark负载简单而且高效。另外,Databricks还包括了交互式的notebook环境,监控工具以及安全控制从而使得Spark可以非常容易的在具有上千个用户的企业落地。

在Azure Databricks, 通过微软和Databricks的密切合作,我们在Databricks平台基础能力上更进一步,紧密的集成了Azure服务的能力。Azure Databricks提供了访问Azure存储平台的优化的连接器,从而提供最快的数据访问速度。同时支持通过Azure Console的一件事管理。这是Apache Spark平台第一次紧密的与一个云平台提供商合作,从最底层进行优化提高数据分析的性能。

对数据工程师和数据科学家的好处

为什么Azure Databricks对于数据工程师和数据科学家有用呢?让我们来看看:

优化的环境

Azure Databricks从底层开始做优化从而保证在云上的性能和成本收益。Databricks运行时环境给Spark负载增加了几个关键的能力,可以在Azure上运行时提高性能并且节省10到100倍的成本:

  1. 高速的连接到Azure Blob Store和Azure Data Lake等Azure存储服务的连接器,这些连接器是与这些服务的开发者一起联合开发的。
  2. Spark集群的自动缩放和自动终止,从而最小化花销。
  3. 包括缓存,索引和高级查询优化在内的性能优化,比传统的Apache Spark在云或本地环境中的性能提高了10-100倍。

无缝的协同

你应该记得当文档变得真正的能多人编辑时效率是如何的提升。我们为什么不能使得数据工程和数据科学也变成这样?Azure Databricks就是如此。Databricks上的notebook能够进行共享和实时协作,以便您组织中的每个人都可以使用您的数据。仪表板使业务用户能够在现在存在的任务中使用新的参数。 Databricks与PowerBI紧密的集成以支持交互式的可视化。 能够使这些能力成为可能,是因为Azure Databricks由Azure数据库和其他支持高度并发访问、高性能和地理复制的技术的支持的。

易于使用

Azure Databricks附带了交互式的notebook,可让您连接到常见的数据源,运行机器学习算法,并学习Apache Spark的基本知识以快速入门。 它还具有集成的调试环境,可以让您从交互式notebook中分析Spark作业的进度,另外还包含分析已经完成的作业的强大工具。 最后,还预装了其他常用分析库,例如Python和R数据科学技术栈,以便您可以使用Spark来进行洞察。 我们确实相信大数据可以变得数以十倍的更易用,我们正在继续坚持Apache Spark的理念,以提供统一的端到端平台。

Azure Databricks架构

那么Azure Databricks是如何组装在一起的呢?在高层次上,服务在每个Azure客户的订阅中启动和管理worker节点,从而让客户可以利用其帐户中的现有管理工具。

具体而言,当客户通过Databricks启动集群时,“Databricks appliance”将作为客户订阅中的Azure资源进行部署。 客户指定使用的虚拟机的类型和数量,但Databricks管理所有其他方面。 除了这个设备,一个托管资源组被部署到客户的订阅中,托管资源包括一个VNet,一个安全组和一个存储账户, 这些是Azure用户熟悉的概念。 一旦这些服务准备就绪,用户就可以通过Azure Databricks UI或通过自动伸缩等功能来管理Databricks集群。 所有元数据(如计划作业)都存储在具有地理复制功能的Azure数据库中以实现容错。

Azure-DB-Blog-Image.png

对于用户来说,这个设计意味着两件事。 首先,他们可以轻松地将Azure Databricks连接到其帐户中的任何存储资源,例如现有的Blob Store或Data Lake。 其次,Databricks从Azure控制中心集中管理,不需要额外的设置。

完全的Azure集成

我们将Azure Databricks与Azure平台的所有功能紧密集成,以便为用户提供最好的平台。 以下是我们迄今为止所做的一些部分:

  • VM类型的多样性:客户可以使用所有现有的VM:机器学习场景的F系列,海量内存场景的M系列,通用的D系列等。
  • 安全和隐私:在Azure中,数据的所有权和控制权属于客户。 我们已经构建了Azure Databricks来遵守这些标准。 我们旨在为Azure Databricks提供Azure其余部分遵守的所有合规性认证。
  • 网络拓扑结构的灵活性:客户有多种网络基础设施需求。 Azure Databricks支持客户VNET中的部署,这可以控制可以访问哪些源和接收器以及如何访问它们。
  • Azure存储和Azure Data Lake集成:通过DBFS向Databricks用户展示这些存储服务,以便对现有数据进行缓存和优化的分析。
  • Azure Power BI:用户可以使用JDBC将Power BI直接连接到Databricks集群,以便使用熟悉的工具以大规模的交互方式查询数据。
  • Azure Active Directory提供对资源访问的控制,并已在大多数企业中使用。 Azure Databricks工作区部署在客户订阅中,所以可以非常自然的用AAD控制访问数据源,结果和作业。
  • Azure SQL数据仓库,Azure SQL数据库和Azure CosmosDB:Azure Databricks可轻松高效地将结果上载到这些服务中,以便进一步分析和提供实时服务,从而使在Azure上构建端到端数据架构变得非常简单。

除了您可以看到的所有整合之外,我们还努力以无法看到的方式进行整合 – 虽然好处是显而易见的。

  • 在内部,我们使用Azure容器服务通过容器运行Azure Databricks控制面板和数据面板。
  • 加速网络提供了云中最快的虚拟化网络基础架构,Azure Databricks利用它来进一步提高Spark的性能。
  • 最新一代的Azure硬件(Dv3虚拟机),NvMe SSD能够在IO上延迟100us,这使Databricks I / O性能更好。

我们只是抓到最浅层的表面! 随着服务GA并且进一步演进,我们希望能够继续与其他即将到来的Azure服务进行整合。

结论

我们很高兴能够携手合作为您带来Azure Databricks。 领先的云提供商和领先的分析系统提供商首次合作建立了一个云端分析平台——从Azure的存储和网络基础架构到Databricks的Apache Spark运行环境。 我们相信,Azure Databricks将极大地简化企业级生产环境数据应用的构建,并且我们很乐意听到您的反馈意见。

 

  • 十一 20 / 2017
  • 0
Data, Enterprise

锐眼洞察 | 移动App行为数据研究的商业价值

作者:TalkingData首席布道师 鲍忠铁

本文为TalkingData原创,未经授权禁止转载。申请授权请在评论中留言联系!

 

证券行业的客户金融交易渠道将会转向移动互联网,客户证券投资和财富管理服务将主要发生在移动App,其将成为客户的主要入口和金融产品主要发布场所。证券企业如果想赢得未来市场,赢得客户,取得在金融市场的领先优势,就必须了解客户的金融产品需要,重视客户的交易行为和互动行为数据。利用数据了提升客户体验,提升移动互联网端的数据和业务运营能力,具有同互联网企业一样的技术能力和迭代速度。重视用户的移动端行为数据将成为证券行业未来在市场成败的一个关键。

证券行业过去主要分析交易数据、资产数据、产品数据、人口属性数据。典型数据应用有数据库营销中的关联分析和交叉销售。交易数据对营销具有较大的商业价值,特别是老客户经营。例如某些产品的客户复购率较高,利用交易数据可以进行多次营销,降低营销成本。

行为数据相对于交易数据具有不确定性大的特点,行为数据更关注客户的兴趣偏好,更适合了解客户体验和用户潜在金融需求。利用App行为数据进行营销,具有范围广、预测性强等优点,缺点主要其营销的业务转化率不太稳定。考虑到潜在的目标人群基数较大,即使是较低的转化率,其转化的目标客户也会很多。曾经在一个案例中,利用资讯推送来影响客户进行投资,其过转化率接近40%,大大超出了想象。一般行为数据营销的转化率都低于10%,集中在1% – 5%之间。如果低于1%的转化率,这个基于行为数据建立的营销方案将会被放弃。

行为数据的场景应用建立在场景化标签之上的,基于App内部行为的场景应用来源于具体业务目标,例如证券App中的绑卡入金、购买理财、股票交易、基金买卖、贵金属购买、关注收藏等。

第一节:行为数据分析有助于加速产品迭代和提升客户体验

App行为数据包含浏览、点击、评论、交易等几类,可以通过App的按钮和事件埋点进行提取。经过异常值处理和数据去噪音之后,就可以进行分析和应用。移动互联网企业如BAT等巨头,其产品和用户体验的竞争力就是来源于行为数据的分析和应用。

过去证券行业人员可以通过线下的营业网点来接触客户,利用同客户面对面的交流,了解客户金融产品需求和用户体验。现在客户几乎不再去营业场所,或者去证券营业部的客户年龄都较大。光大银行曾经统计过一个数据,经常到营业网点办理业务的客户,平均年龄为52岁,说明年轻客户基本上很少去网点办理业务。这些年轻客户正是证券行业主要的客群,未来将会成为证券企业的主要收入来源。证券企业如果想了解客户的金融需求和客户体验,其主要的方式就变成了分析App的行为数据,这也说明了研究分析App行为数据的重要性。

在互联网企业中,App运营团队有一个重要的职责就是每天分析App的行为数据,主要是因为行为数据代表了客户对产品的喜好。基于App行为数据的分析,互联网企业的产品经理可以及时调整产品,进行产品迭代,快速满足客户对移动产品的需求。互联网企业产品迭代完全基于App行为数据的分析,基于行为数据的结果。

客户在App的行为点击和浏览数据,辅以时间维度分析和漏斗分析,可以真实反应客户体验情况。互联网企业的运营部门参考这个数据可以分析客户喜欢哪些产品、广告、活动等,同时也可以了解客户不喜欢哪些产品、活动等。利用行为数据分析,运营部门可以实时了解客户体验情况,及时调整运营活动和产品布局,围绕客户需求来提升客户体验。移动互联网时代,客户体验本身比产品更加重要。

证券行业一直想学习和掌握互联网企业的竞争优势,特别是在产品迭代和用户体验提升两个方面。行为数据分析为证券行业产品迭代和体验提升提供了技术支持。证券企业完全可以深度分析App行为数据,利用行为数据分析结果来进行产品迭代和用户体验提升。例如证券行业可以分析App的点击热力图,利用App点击热力图来了解客户喜欢哪些功能,客户很少点击的功能就可以及时下架。参考AB测试的数据来分析客户更加喜欢哪些功能,基于客户点击爱好进行App的功能迭代和用户体验提升。证券行业还可以参考客户DAU、留存时间、打开次数等行为数据进行分析,了解客户对App体验反馈,留存时间增加和打开次数增多代表用户对App的喜爱程度增加。实时反馈的行为数据可以及时让证券行业了解体验情况,及时进行产品迭代。

证券移动App的行为数据具有直观、实时、客观等特点。基于行为数据的分析对于了解客户体验和了解客户对产品喜爱具有重要意义,是证券行产品迭代和用户体验提升的基础数据,证券行业必须重视对其的研究和应用。

第二节 行为数据研究有助于提升券商互联网运营能力

互联网行业有一句经典的话,三分产品、七分运营,好的产品不是设计出来的而是运营出来的。互联网运营的基础就是行为数据的分析,运营团队通过行为数据的分析实现运营能力的提升。

证券企业希望学习互联网企业的数据运营能力,其主要体现在数据的分析和应用能力,包括基于数据的产品运营、渠道运营、用户运营、活动运营等。这些运营能力是建立在数据分析和应用基础之上的,其中行为数据应用能力是其重要组成部分。

产品运营的核心工作就是产品优化,包括UI/UE、产品框架、内容建设、产品维护、用户维护、活动策划等。用户需求不断变化,产品需要通过持续的迭代完善才能满足用户需求,没有运营则无法时刻洞察用户需求变化;运营是让产品持续产生产品价值和商业价值。行为数据是产品进行优化的基础,基于行为数据中的点击数据和浏览数据,运营团队可以了解客户对UI、产品的喜好,对内容的关注,对活动的反应。依据行为数据分析进行产品迭代和优化,行为数据是产品运营的重要参考。

渠道运营是指利用资源和流量为产品带来新增用户,包括免费、付费、换量、人脉积攒、产品的吸引力、圈内人的推荐、策划活动、内容营销、用户口碑等手段。互联网线上渠道发展比较野蛮,鱼龙混杂。特别是移动App推广市场,不但流量贵,而且假量还大。参考TalkingData发布的移动互联网报告,在某些高峰时段,一些渠道的假量超过了50%,也就是说至少有一半的点击和下载是无效的,广告推广费用是浪费的。曾经在某一个特殊时间段TalkingData移动广告监测平台Ad Tracking一天收到了24亿次点击,其中90%的点击是假量、是恶意刷量。券商利用App的行为数据可以有效分析出哪些渠道效果好,真实量比例高;哪些渠道效果差,假量明显。行为数据还可以分析出哪些是真正的客户,哪些是一次性客户,哪些是羊毛党客户,哪些是有效客户。通过App渠道分析数据,券商可以降低广告投放费用,提升线上获客质量,提升广告获客的ROI。行为数据是渠道运营的重要参考指标,通过App渠道数据的分析,可以提升券商在移动互联网渠道运营能力。

用户运营指以用户为中心,遵循用户的生命周期价值点和用户产品需求设置运营活动与规则,制定运营战略与运营目标,严格控制实施过程与结果,以达到预期所设置的运营目标与任务。用户运营最直接价值就是提升用户金融产品的复购率,提升单客价值,激活休眠客户、挽留流失客户、发现潜在客户等。证券行业面临较大的挑战有休眠客户比例过高,客户单客价值不高,流失客户明显。这些问题都可以通过行为数据分析找到解决办法。例如通过客户点击和关注的数据,了解客户资讯需求,主动推送资讯给客户,激活休眠客户。利用点击和浏览行为数据趋势分析,及时了解客户流失倾向,结合客户产品喜好和兴趣爱好,定制激励方案,挽回流失客户。行为数据可以直观反映出客户兴趣和喜好,为用户运营提供方案支持,具有非常大的参考价值。

券商如果希望具备互联网企业的运营能力,在产品运营、渠道运营、用户运营等方具有同互联网企业同样的技术和运营能力,就需要重视行为数据的分析和应用。

第三节 行为数据应用是券商业务智能化发展的基础

证券行业智能化发展是必然趋势,一方面是智能化应用的技术条件具备了,例如数据处理能力、模型算法能力、专业人才储备;一方面是券商所面临的经营成本高、效率低、客户服务覆盖率不高等问题,可以通过智能化应用来解决。

证券行业智能化应用的广义涵义是借助于工具平台和智能应用来解决具体的业务问题,这些业务问题可能是个人投顾无法直接服务全体客户;可能是传统电话客户服务成本高,效率低,客户体验不好;可能是内部流程效率较低,无法满足客户变化的金融需求;也可能是投研和投顾人员缺少可以服务客户资讯平台等。

证券行业智能化应用狭义的应用领域包含智能投顾(机器人理财)、智能客服、智能资讯推荐、智能投研数据平台、智能数据应用平台等。其主要解决还是效率问题,本质还是券商服务的自动化和智能化,可以提升客户体验和降低服务成本。

证券行业智能化应用的一个前提是海量数据,包含交易数据和行为数据。但是这些数据不是原始数据,而是经过业务专家标注的,具有业务价值的数据,可能是标签数据、归类数据和分析结果数据。行为数据对于智能应用具有较大的商业价值,例如在智能客服中,客户的行为数据代表其产品和风险偏好,智能客户可以利用这些处理过的行为数据,为客户打上标签。基于行为数据进行客户分群或分层,智能客户将参考这些行为数据为定制客户服务内容,直接有效地为客户提供金融产品服务。借助于行为数据标签,智能客服将会缩短服务路径,直接切入客户喜好,提升客户体验,提高服务效率。如果行为数据揭示客户倾向于港股交易,智能客服在服务时就可以侧重于港股资讯。如果客户有融资融券倾向,智能客服就会提供相关介绍和激励措施。如果行为数据揭示客户倾向投资能源板块,智能客服就可以提供更多的能源资讯,为客户投资提供支持。

智能投顾原理是参考客户投资风险偏好和投资兴趣,为客户定制投资组合,在一定风险可控的前提下,获得一定的最优收益。行为数据可以支撑智能投顾中客户的投资偏好,通过对客户点击、浏览、关注等行为数据的分析,券商可以了解客户的投资兴趣偏好。例如客户点击股票所属的板块、关注的交易板块、浏览的资讯、这些行为都可以在一定程度上反映客户的投资兴趣,经过一定分析和加工之后,可以作为标签类数据输入到智能投顾平台,作为智能投顾推荐投资组合的参考信息,有助于提升智能投顾的客户体验和客户购买转化率。

券商移动App行为数据具有intention属性,代表了客户内心的需要,也可以认为是客户理性行为和感性行为的综合,其中感性成分更高一些。中国的投资客户,大部分变现为理性投资客户,但是在进行证券交易时往往体现的是感性一面。因此研究行为数据有利于了解客户心理行为,也就是客户感性行为。行为数据经过加工处理之后,可以表现为标签数据,结合业务场景和交易数据,可以帮助券商更加客观了解客户金融需求。券商可以针对客户的兴趣爱好,提供相应的智能资讯和投研报告,协助客户作出更加客观的投资决策。行为数据结合相应的资讯会缩短客户决策周期,提升客户交易积极性,有助于提升客户交易额和交易频度。例如通过行为数据的分析,推送客户关注股票板块的资讯,通过不同组客户测试,发现收到资讯的客户其交易下单率高于不收到资讯客户30%,其中收到相应板块资讯的客户,高于非相关资讯客户的50%。

总之,移动App行为数据的分析和应用可以帮助券商加速产品迭代和提升客户体验,建设同互联网企业同样领先的运营能力,并为券商智能化应用提供具有较高商业价值的数据,推动券商智能化应用的发展。

 

  • 十一 20 / 2017
  • 0
Ideas

锐眼洞察 | 前Uber产品负责人:企业若想繁荣发展,产品团队需要多样化人才(翻译)

作者:Alexander Volkov

原文:To thrive, product teams need diverse talent – a former Uber product leader explains why

译者:TalkingData副总裁 皮山杉 

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

 译者注:

这篇文章对于我们打造优秀团队有很多借鉴。文中主人公Mina曾是一个在明星创业企业的产品负责人,她分享关于多元化产品经理团队组建的切身体会和一些具体实操经验。其主要观点包括:

  • 构建多元化人员组成的产品团队才能回避回音室效应,真正能打造一款满足需要的产品;
  • 打造多元化产品团队需要团队管理者需要做到招募多元化人才(不局限于自身经验类似或既有网络,招聘时提出更好的问题,了解候选人的创新思维),更重要的是能包容团队中的多元化人才,让每个人都能发挥价值;最后是要有培养这种意识,能坚持招募多元化人才和包容他们

其实,不单单是产品团队,任何团队,无论是销售,咨询,数据工程和研发,数据科学,产品,以及中后台职能团队,在一定基础原则上的多元化是让团队能不断提升的一个加速力,而身为团队管理者就需要有意识的这样训练,并且能找到他们,给他们空间,发挥每个人的作用。

 

Mina Radhakrishnan不希望构建一个产品,其被打上是“解决富人问题”的标签。 在湾区科技企业八年之后(曾在Google担任产品经理,后来在Uber领导产品管理),Mina开始关注创业,这些创业企业借助融资可以让更多用户能够负担得起体验产品的便利。

这一趋势并未让她感到惊讶。 而事实上,这直观上是有道理的。 Mina说:“大多数产品经理都是为自己制造产品。 “而大多数VC都被大量的公司所困扰,他们只关注那些他们能立即明白的,且是由已经与他们的建立联系的人所创立的公司。”

这些创始人和他们背后支持他们的VC可能都会存在认知偏见,当我们没有足够的信息时,我们大多数人会陷入被动的状态:我们把我们熟悉的或者喜欢的事情想象的更好。

在像硅谷这样的地方,年轻人,白人,男人和精英学院的毕业生严重超额——这种偏见极大地限制了可行的创业公司的数量、范围和潜在客户群基数。

然而,有可能利用我们所熟悉的倾向来创造好的方面。 “解决我们眼前的问题是没有错的 – 那些问题往往是我们最擅长解决的问题。 但是只有当某些人得到同一块馅饼时,同样的产品才能被建立起来。 而反过来,如果创始人和产品经理所代表的身份,背景和经验更多,解决的问题就越多,从用户的视角出发的就越多,能把握世界接受程度的团队所能掌控的产品也就越多。

在一些最受欢迎的技术公司工作近十年之后,Mina深入了解建立多样化产品团队所需要的因素,以及如何通过多样性来推动产品持久的成功。 她还看到了同质化的丑陋之处:当同一类人为同一类用户构建相同类型的产品时会发生什么。 (严肃地说,看看那些在旧金山提供的顶级餐厅订阅服务的创始人——这真是令人毛骨悚然)。

为了阻止这个循环,将新鲜的想法带回到所谓的创新领域,产品领导者必须开始寻找和保留不同的人才。 在这篇独家文章中,Mina解释了为什么企业应该优先考虑多样性,以及我们每个人能做些什么来实现。

Mina3CTT_-_01.png

回声室效应不会产生好的产品 – 并阻碍伟大产品的产生

没有一个单一的产品经理能够理解他们用户群中的每一个细节,或者准确地预测每一个新功能如何被接收,没有人会期望这些功能。 事实上,根据Mina的说法,产品经理常常发现自己处于水深火热之中,并不是因为他们不知道什么,而是因为他们认为他们知道他们实际上不知道的东西。

“包括我自己在内的产品经理常常陷入这样一个陷阱:我们自己对于产品体验与每个人如何体验相匹配。 这种思维方式使我们无法构建能够新的各种功能,以让我们接触和服务于新用户。”

发展从用户考虑的同理心可以帮助打破这种习惯,但是当PM们不得不迅速行动以实现他们的路线迭代时,再不断进行观察则是不可能的。而且,无论人们多么努力,总会有一些他们无法预料或理解的观点。

“为了抓住错误,填补空白,并建立一个与用户产生共鸣的产品,产品经理必须学会与身份、背景以及与我们有不同的经验的人员在一起。如果我们只和我们相同的人分享我们的想法,没有人会注意到我们疏漏的方面。同质性是产品团队的‘氪石’。”

不幸的是,即使是那些认为重视多样性的产品领导者,也往往会对其降低优先顺序,并最终打造一个完全来自自己网络的团队。这也设定未来潜在的破坏性后果。 “如果你问自己,’我怎么没有注意到这个致命的缺陷?’ 此时可能已经太迟了。”根据Mina的说法,创始人和产品经理需要从构思阶段就寻求多样化的输入,否则产品将是或者迅速失去打动他人的特点。

Mina举了一个名为Bodega的例子:Bodega是由两位前Google员工创立的一家闪亮的自动售货机创业公司,在《Fast Company》杂志收录之后立即引发了反弹。 “显然,那些家伙不像那样拥有相同的语言、生活方式或文化特色的听众。但还有多少人听了那个演讲呢?有多少顾问、投资者、家人和朋友,他们向其分享了想法?可能有几十个。事实上,由于在硅谷地区缺乏种族、文化和社会经济多样性,他们在谈论了多次后仍认为这是一个好主意。”

Bodega的问题可以从更大的层面来看,考虑到大多数VC选择不投资的可行产品种类时,如:仅为黑人妇女或以母亲为目标的产品 “我们是谁塑造了我们认为有价值的东西。我朋友的公司选择投资一家向黑人女性销售头发拉长器的公司。但由于VC未能看到市场的适应性,所以他们花费了大量的对话沟通才得到资金。不是因为没有市场,而是因为VC他们团队或其生活中没有足够的黑人女性,使得他们认识到这是一个巨大的,尚未开发的市场。”

这不仅仅是由于我们的种族,性别和社会经济背景影响了我们如何构思有价值的产品或特征。 “我曾经在许多拥有各种不同能力的产品队伍中工作过。很多次,我把按钮放在一个具有相同颜色的应用上,团队中有色盲的人告诉我,从而让我意识到这样设计会让许多我们的用户无法区分yes和no按钮。

即使像Mina这样的产品领导者,不断地提醒自己注重不同用户的体验,自己仍然不能完全避免犯错误。 “假设我们能看到一切,甚至假设我们能看到准确的东西,这种观点是非常愚蠢的。我们只注意到我们所关注的,因为我们认为重要。这就是为什么我们必须把注意力集中在我们不知道的人身上。我们最终都会搞砸,但是当我们这样做的时候,不同的团队可以让对方重新回到正确的轨道上。

多元化的产品团队可以对用户体验拥有360度视角

Mina_CTT_02.png

播种和培养多样化团队所需的部分工作正在考虑其他技能,背景和经验对于构建手头产品有何贡献。

“这看起来很明显,但值得一提的是,产品管理工作所需要的情况因产品而异。 成功的产品经理没有一种所谓的通用技能。 如果一个团队需要设计一个非常复杂的调度系统,那么招聘经理可能会想要寻找一个技术背景而不是设计背景的候选人。 但是,如果团队需要建立一个用户交互的消费产品,则设计背景人选更重要。”

Mina在Uber时领导的团队需要产品经理包括技术背景人员以及运营经验的人员。 “我们建立了一些我们的用户从不直接与之互动的产品。那些真正漂亮的司机和用户的App只解决了20%的难题。另外80%是我们用户没有看到的东西 :一切都运行在后台,只需按下一个按钮就可以得到一辆车。这感觉很简单,因为所有的操作都要在后台进行。”

跨界的新型驾驶员App团队是多样化产品团队能够完成而其他人是无法完成的光辉事例。 “我们在建立最初的驾驶员App时犯的一个错误是,我们只看到了驾驶员的人口统计学数据,但我们并没有考虑到是否是否有工作的基本事实:这是一个压力。尤其是当你开车的时候人们对压力的反应方式完全不同。有些人觉得这很令人兴奋,而另一些人却觉得很压抑。”

我们团队的PM在建立了一个新的驾驶员使用的App时,首先确保组建一个广泛的团队。因为团队中同事在面对压力有着不同的回应和经验,所以他们可以评估驾驶员在行驶中的感受,如果突然间车内发出巨大的哔哔声。虽然对某些人有帮助,但这种警报可能会让其他驾驶者完全不知所措。幸运的是,这个团队有足够的同理心去关注这个问题,设想驾驶员是一个已经工作了几个小时,只想回家的司机。

出于这个原因,Mina找到了具有运营背景的产品经理,最终证明他们对于团队在Uber的成功非常重要。“我们需要一个能够回答这样一个问题的人:‘我们怎样才能使这个产品为一个每天使用上百次的用户工作?’不仅仅是回答这个问题,而且更要有问这些问题的感觉。 ”

对于Mina的团队,那个人是Emily。 “如果我们坚持按照传统的产品经理要求,我们就不会雇用她,但是如果没有她,我们也就不会创造出那些令人着迷的产品。她在芝加哥有司机运营的经验,我从来没有见过任何人像Emily一样忙碌的工作,或者如此迅速地掌握她需要的技术技能。最重要的是,她对我们的驾驶员有了大量you价值的知识:他们想什么、他们想要什么、他们为什么奋斗。所以她可以为他们设计出正确的产品。”

随着时间的推移,Mina看到团队中的所有产品经理相互学习,拥有更全面的视角。 “与不同群体的团队一起工作,迫使每个人都变得更有同理心,因为他们不能假设他们知道其他团队成员想要什么或他们的想法。你会有意识地在日常工作中思考这个问题。当你这样做和思考时,它会强迫你使用同理心和有意识的沟通,这就成为你设计的产品一部分。”

在产品团队中优先考虑多样性的基本原则

在某种程度上,大多数产品领导者都会犯错误,阻止他们建立起自己设定的多样化成员的产品团队。Mina表示她已准备好。 “我有多次尝试多样化和包容实践的失败经验。在一个团队中,我曾设定了一个性别比例目标。现在回想起来,这是一个全面的交叉性禁忌,因为它不仅是关于性别,而是通常其所代表的群体不足。如果一个产品团队只是招聘白人女性,他们在多元化方面并没有削弱。只是她们刚建立了一个不同类型的回音室。”

Mina从失败中学到了大量的教训。她与我们分享了以下四个。

切断技术程度的要求

作为一名具有工程背景的产品经理,Mina不得不摆脱这样一个想法:来自知名学校技术学科的人可能会成为更好的PM。 “大多数符合这个标准的人都是白人。招聘经理如果拥有从其的母校或以前的雇主的“谱系”中挑选候选人的潜在意识的话,那么很多合格的候选人进行第一轮面试前淘汰。这些候选人往往来自技术上代表性不足的群体。“

Mina领导产品团队的经验告诉她,不是每个PM都需要特殊的技术才能在产品团队中茁壮成长。 “应该有一个健康的组合,鼓励人们相互学习,填补其他人不能的空白。并不是每个PM都需要在产品所需的每一项任务中都有出色表现 – 这就是为什么有一个团队。”

提出更好的问题

为了聘请具有丰富经验的产品经理,Mina准备了一些问题,促使候选人在工作场所以外谈论他们的生活。 Mina在PM中最重要的素质之一就是对于产品的好奇心,这是产品经理们最有效的一个重要特性,这往往会渗透到他们的日常生活中。

“在面试中,我问了一个非常简单的问题:你最喜欢的实体产品是什么?我认为它是人们品味和创造力的核心。“Mina寻找那些在科技泡沫之外思考的人,因为为了创新,产品经理必须能超越已经完成的事情。

“任何人说iPhone或Macbook后,谈话都会很快结束。因为我真正想要的是他们对“为什么”的回答,没有任何人可以告诉我这些产品还有什么功能没有被包含在大量的思考设计中的。当人们谈论他们个人的东西时,这会更有趣。人们谈到了令人惊异的直发器和兔子开瓶器 – 这并不重要。我想在答案中听到的是一个关于他们发现的产品独特价值的想法。”

对于Mina来说,它已经成为一个创造性思维的伟大代表。 “在司机App新的应用团队中的每一位产品经理都对这个问题做出了很好的回答。”

制定包容性领导战略

希望聘用和留住多样化人才的产品领导者需要围绕这一努力构建领导力战略,而不仅仅是一次次尝试。Mina建议从委员会的招聘开始,建立跨职能团队,并扩大更安静的团队成员的声音。

“也许我是天真的,但我不认为有任何产品负责人是在积极尝试建立独特的,同质化的团队。然而,实时上这其中有很多。为了缩小这个差距,产品经理应该确保他们有一个多元化的面试小组,如同他们想要建立的团队那样。跨职能团队可以帮助实现。通常情况下,工程团队没有太多的多样性,但是有设计师和客户支持人员、撰稿人和财务分析师,则产品团队的多样性可能会更大。”

为了让团队保持多样化,产品领导者相比于投资于多元化,则至少要投资于包容性 。 “作为管理者,确保没有人被轻易地打发掉或关闭下想法是至关重要的。在会议结束时,我会回顾谈话,以确保每个人都有足够的表达时间。这看起来似乎很简单,但是在一个领导人不知所措的小公司里,很多人都不理会。例如问自己:“我放过这个机会是因为我的盘子里有太多东西吗?”大部分情况下都是这个原因,所以我们必须腾出时间和创造空间来做出改变。

培养意识

为了确保他们在日常工作中优先考虑多样性和包容性,产品负责人需要实践自我意识。 这听起来很简单,但从Mina的角度来看,真正的工作是花时间和精力进行自我教育、研究和反思。 “理解你的偏见,以便你能先于他们,同时也意识到你最终会搞砸。 只要确定这个搞砸了不会成为你放弃的时刻。”

从Mina的角度来看,这种粗心大意(而不是恶意)妨碍了多元化的努力。 “作为产品经理,我们战略性地思考我们的产品路线图,但是战术性地考虑其他事情。 现在是时候从战略上思考聘用和留住多元化人才和建设包容性团队的问题了。 如果你在做清单上的另一项任务,它将不会发生。”

当你像Mina这样的领导者把这作为自己的使命的时候,你就能建立多元化团队。

Mina2_MP_-03.png

与众不同的方式构建Different.com.au 

几年前,Mina把她从硅谷学到的东西运用在了其他地方。在看到短视对创新构成威胁之后,Mina决定在远离湾区的其他地方创办她的公司。

Mina说:“我知道我想要建立一些与众不同的产品,这个产品可以解决那些没有从技术中获益的人的问题。

她尽可能地去做。在涉及她和丈夫多年来思考的一系列创业想法之后,他们终于选择了一个有坚实基础的方向。如果他们做得好,这个产品将会在一个几十年来一直没有改变的产业中取得重大进展:澳大利亚的物业管理。

在电话中,Mina详细描述了这个问题。 “在澳大利亚,所有人中有10%拥有投资性房地产。与美国不同的是,这些业主很大一部分并不富裕。他们中的许多人是中产阶级,他们的财产是他们退休的唯一途径。但是由于他们大多数仍然全职工作,他们不得不花费他们一大部分的储蓄来雇佣一个专业的房地产经理,让房地产经理可以和房客进行沟通并处理维护工作。”

Mina在审视岳父的财务状况并为其退休做准备方案时,他们发现物业管理公司在过去二十年收取的费用继续增加,且没有任何理由。当她问起这件事的时候,她的岳父说他们并没有真正和他们的物业经理有任何关系,也没有确切地知道他们做了什么。这家公司每九个月就发一次新的账单。

“这个对话是我的’哈哈’时刻。我看到有人喜欢把他们的退休收入用在糟糕的服务上,我觉得我们可以提供一个很好的服务。“在和更多的业主,房客和物业经理交谈之后,Mina和她的丈夫看到了明确的需求,最终可能具有全球潜力。

因此,有了Different.com.au,Mina和丈夫的愿望解决了他们所爱的人的直接问题。他们的决策过程与硅谷创始人和风投公司的决策过程之间的相似之处并未在Mina身上所迷失。事实上,这些相似之处是让她分享这个故事的核心。

 

页面:1234567...35
随时欢迎您 联系我们