技术专栏丨Fabric 和 Sawtooth 技术分析(下)

在前一篇文章(Fabric和Sawtooth技术分析(上))中,我们着重跟大家分享了 Fabric 相关的内容,在本篇文章中,我们将围绕着 Sawtooth 进行一些分析和探讨。

Sawtooth 结构及分析
Sawtooth 是 Intel 公司推出的企业级区块链,2018年 Intel 将其贡献给 Hypherlegder 项目。本文中笔者主要从 Sawtooth 的存储结构、数据结构、网络结构方面做简要介绍。

Sawtooth

Sawtooth 的存储结构

Sawtooth 使用名为 Radix Merkle Tree 的存储结构,它融合了 Radix Tree 和 Merkle Hash Tree 的功能,先看看这两种结构:

  • Radix Tree

Radix Tree 概念比较拗口,简单地说就记住在这个树上,任何一个叶子节点的位置和一个 01 串唯一对应,因此我们可以根据一个 01 串组成的地址确定叶节点是谁。

下图是一个 Sawtooth 所使用的 Radix Tree 对应的字符串,由70个16进制字符组成,前6位称为命名空间前缀(Namespace prefix),后边的是该前缀所对应的空间内可分配的地址范围。

我们以 Sawtooth 预定义的一个 Transaction Family-IntegerKey 为例,注意 Sawtooth中 的 Transaction Family 相当于 Fabric 中的 chaincode 或者 Ethereum 中的 Smart Contract 。IntegerKey 的前缀(prefix)计算法方法是:hashlib.sha512(‘intkey’.encode(‘utf-8’)).hexdigest()[0:6],运算结果是 ‘1cf126’。那么,存储该 transaction family 中一个 block 的地址就是:

address = “1cf126” + hashlib.sha512(‘name’.encode(‘utf-8’)).hexdigest()[-64:]

当然,地址的构成也可以更复杂一些,比如,有个自定义 Transaction Family 的前缀是 prefix = “my-transaction-family-namespace-example”。命名空间可以进一步划分为 object-type 和 unique-object-identifier 。其中,object-type = “widget-type”,unique-object-identifier = ”unique-widget-identifier”。那么,对应的字符串就可以计算如下:

hashlib.sha256(“my-transaction-family-namespace-example”.encode(‘utf-8’)).hexdigest()[:6] + hashlib.sha256(“widget-type”.encode(‘utf-8’)).hexdigest()[:4]

+ hashlib.sha256(“unique-widget-identifier”.encode(‘utf-8’)).hexdigest()[:60]

最后得到下面的地址:

‘4ae1df0ad3ac05fdc7342c50d909d2331e296badb661416896f727131207db276a908e’

众所周知,2的10次方是1K,20次方是1M,30次方是1G,40次方是1T,对于一个名字空间,Sawtooth 为其保留64位,从存储空间需求上讲,即使有一些位被用来做子空间划分,应该也够用了。在查找时,完全可以根据 Transaction 的名字找到它的存储位置,所以检索速度也会非常快。

我们可以认为,Sawtooth 就像一个原始的区块链,每向后一层都可以分叉,以树的形式组织数据存储,而不再是以线性的方式来组织数据存储。也可以把原始的比特币区块链理解为只有一个Transaction Family 的 Sawtooth。在完整的分析过 Sawtooth 以后,最应该记住的就是 Sawtooth 的存储结构,它其后的所有设计都是基于这一结构。

  • Merkle Hash Tree

Merkle Hash Tree 的特点是所有节点的值都是哈希值,每个哈希值是根据其子节点的哈希值计算出来的,所以任何一个节点和哈希值出现变化,它的上层节点的哈希值都会跟着变。

Sawtooth 采用 Radix Merkle Tree 结构做数据存储的好处就是给定 Block 名及类别,直接计算哈希值,就找到它的存储位置了。而且存储空间是隔离的,每个 transaction family 的存储空间和其它的都是分开的,互不影响。所以,从存储结构来看,基于 Sawtooth 的区块链天生是多条连的(Forked),很容易去解析它的分叉。

Sawtooth 的数据结构

Fabric 没有去严格定义数据结构,Sawtooth 的数据结构也没有什么值得特别提出的亮点。只要知道 Sawtooth 定义了 Transaction 包括Header 和 Payload 两部分即可,而 Sawtooth 要求不管是一个还是多个 Transaction 必须被封装在 Batch 中才可以提交给 Transactio n的 Processor ,或者说 Transaction Processor 只接受以 Batch 为最小单位的 Transactions 。同样地,Batch 也包括 Header 和 Payload 两部分,其关系如下图所示:

Sawtooth 的网络结构

如下图所示,Sawtooth 的一个节点可能由如下几个部件组成:Validator、Transaction Proc essor、REST API、以及 Client。Validator 是 Sawtooth 的核心部件,主要功能包括接收 Transaction 请求,并将其转发给相应的 Transaction Processor 来处理,根据 Transaction Processor 的处理结果,决定如何生存新的区块,如何给 Client 回显。Validator 还要与其他的 Validator 协同,以保持 Sawtooth 网络的全局状态一致。Transaction Processor 顾名思义就是用来专门处理某一类型 Transaction Family 的 Transactions 的 Processor 。

Client 需要按照 Transaction 和 Batch 规定的数据结构生成请求,REST API 则是标准化的网络传输数据格式。之所以说可能由这几部分组成,是因为对 Sawtooth 来说,只有 Validator 属于其固定结构,比如图中有 Validator1 和 Validator2 ,而 Validator2 就没有连接其他部件,而是只与 Validator1 相连。从构成角度看,一个 Sawtooth 网络可以只由一个 Validator 构成。从网络方面看,其他的 Validator 可以动态加入网络。从部件方面看,Transaction Processor 可以动态注册到 Validator ,然后 Client 提交相应 Transaction 就有对应的 Processor 来进行处理。网络节点和部件可以分别使用不同的端口来区分。这样,Sawtooth 网络就变成完全动态的了,每个组成部分都可以动态插拔。

接下来,我们先看看 Validator 的组成结构,Validator 的软件实现部分称为 Journal,如下图。从功能上看,Journal 包括 Completer、ChainController 和 BlockPublisher 三个主要部分。

当 Batch 被提交给 Validator 后,先被交付到 Completer ,它先检查是否 Batch 的所有依赖项都得到了满足。完整且满足依赖的 Batch 会被提交给 ChainController 。Sawtooth 的这种设计可以支持串行和并行的 Batch,注意这已经不是进程级并行了,而是线程级并行。接下来再看看 ChainController 是干什么的:

ChainController 需要完成4个工作:

  • 1)确定块的头在哪
  • 2)确定当前块在哪-先去 BlockCache 里找,再去 BlockStore 里找。
  • 3)验证块有没有损坏
  • 4)把新块写进区块链

写入新区块链后的发布工作则是由 BlockPublisher 完成。从图中可以看到,ChainController 和 BlockPublisher 本质上都是接口,具体的实现由更下层的共识(Consensus)机制完成,共识机制向上提供 BlockVerifier,ForkResolver 和 BlockPublisher 三个功能。

从整体上看,Validator 的结构比较简单。接下来再看看 Validator 之间是怎么连接起来的。Sawtooth 的 Validator 的网络连接方式如下图,可能会有点乱,同时解释地也不是很清楚,这里笔者的理解是:把它看做一个 Ad Hoc 网络,组网的过程完全就是模拟 Ad Hoc 网络路由节点发现的。开始的时候有初始(生成 Genesis block 的)节点,它可以发出广播包,问谁在它边上,可以按照设定的规则加入网络,如果有人应答就可以加入,然后这些节点继续广播,每个广播包只传播给距离自己1跳的 Validator 节点,这样网络很快就组成了。有新节点想加入也是这样,发广播包,看看自己周围有没有可以直连的节点,退出就无所谓了,反正少一个节点不影响网络。我们知道 Ad Hoc 网络的健壮性和灵活性都是非常高的,所以 Sawtooth 的 Validator 网络中任何节点都是可以动态加入或退出的,只要网络规模足够大,理论上,网络的健壮性是有保障的。

这里有两个关键问题其实没有说清。

  • 1)哪些 Validator 可以加入该网络
  • 2)Validator 接受哪些 client 提交的 Batch

这两个问题就构成了访问控制和隐私保护功能的核心,而 Fabric 花大力气实现的体系结构也正是为了回答这两个问题,稍后会详细说明,核心网络介绍完毕以后,会想到 Client 提交了 Transaction,那Transaction 执行与否?所以,还差一个事件机制来实现消息传递和回显功能。这里的事件机制要确定这么几件事:

  • 1)谁应该被告知事件—(广播?还是根据注册情况组播单播)
  • 2)事件应该包括什么—(消息格式-收据(Transaction Receipt))
  • 3)事件在什么情况下,或什么时候才算有效—(放在 Transaction Receipt Store 中,通知发起 Transaction 的 client 来拿)

下图是 Sawtooth 的事件机制示意图,它把技术实现和组件名称混到一起,看起来也比较乱。大体的意思是左上部是事件子系统用 Zero message queue 的技术实现,其特点是在需要的时候可以随时创建,右上部是写好的类库,注册后,只要满足约束就可以调用它。下部说的是 Transaction Processor 调用具体的 Handler 处理 Transaction 后会告诉 ChainController 的 Scheduler 和 Executor 执行 Transaction 的结果情况,ChainController 除了把新的 block 写到它应该在的地方之外,还会把 Transaction 的 Receipt 放到一个叫 Transaction Receipt Store 的地方,这时候 ChainObserver (Client 注册后产生的一个部件)就会告诉 Client, Transaction 执行完了,来拿收据吧。

下面是一些事件的例子,可以帮助我们理解事件的格式:

 1Example events generated by BlockEventExtractor:
 2Event {
 3  event_type = "sawtooth/block-commit",
 4  attributes = [
 5    Attribute { key = "block_id"value = "abc...123" },
 6    Attribute { key = "block_num"value = "523" },
 7    Attribute { key = "state_root_hash"value = "def...456" },
 8    Attribute { key = "previous_block_id"value = "acf...146" },
 9  ],
10}
11
12
13Example events generated by ReceiptEventExtractor:
14// Example transaction family specific event
15Event {
16  event_type = "xo/create",
17  attributes = [Attribute { key = "game_name"value = "game0" }],
18}
19
20// Example sawtooth/block-commit event
21Event {
22  event_type = "sawtooth/state-delta",
23  attributes = [Attribute { key = "address"value = "abc...def" }],
24  event_data = <bytes>
25}

Sawtooth的访问权限控制

Sawtooth 的权限(Permissions)机制应该参考过 Fabric。主要功能包括网络权限的设置(哪些 Validator 可以加入这个网络),和 Transaction 权限设置(哪些 client 提交的 Batch 可以被 Validator 执行)两种。和 Fabric 一样的是,Sawtooth 也需要配置文件,如果所有功能全部用配置文件完成则称为 Off-Chain transactor  Permission,通常来说小规模网络,极限情况下,只有一个节点的网络完全可以使用 Off-Chain 的方式实现。在 Off-Chain Permission 中,权限是静态设置的。在配置文件 validator.toml 中,直接配置:

[permissions]

ROLE = POLICY_NAME

Policy file:

PERMIT_KEY <key>

DENY_KEY <key>

这里的 ROLE,POLICY_NAME 暂不解释,key 一般是一个公钥,PERMIT_KEY 和 DENY_KEY 就将它理解为一个 bool 值,一个是1,一个是0,含义就是允许不允许。

和 Fabric 不一样的地方是,Sawtooth 还有一种配置方式叫 On-Chain transactor Permission 。就是在区块链上直接设置访问权限,还专门为此设置了一个叫 Identity 的 Transaction Family 。这样 transactor Permission 就有自己的存储空间,其当前值也好,变化也罢,所有节点都可以同步过去,不会存在各个节点配置文件不一样导致系统出错的可能性。

接下来具体看下 Identity。Identity Namespace 以 key-value 对的形式存储 roles,key 是 role name,value 是 policy。所有的 role 都以 transactor 为前缀。比如下面:

transactor.SUB_ROLE = POLICY_NAME

首先,第一个问题是开始谁可以设置访问权限。和 Fabric 例子中类似,机构 R4 通过网络配置文件设置访问权限一样。在 Sawtooth 中,理所当然的应该由创始区块的生成者来设置初始权限。它执行如下命令来设定允许给别人授权的人的公钥:

sawset proposal create sawtooth.identity.allowed_keys=00000

这里的00000是创始区块的生成者自己的公钥,那现在就它自己可以给别人授权。这个类似于 Fabric 里设定,公钥设定以后可以利用 identity-tp 进行授权,也可以继续用 sawset proposal create 命令让其他 Validator 有权做网络或者 Transaction 授权。proposal 这个子命令其实就能猜到 Sawtooth 设计访问权限的时候肯定是参考了 Fabric 的。

具体的 Transaction 授权命令的例子如下:

sawtooth identity policy create policy_1 “PERMIT_KEY *”,这个的意思是创建一个叫 policy_1 的策略,对所有人都是允许的,也就是谁都可以提交 Transaction ,注意这仅仅是个策略,还可以定义其他的策略,相当于 Fabric 里的 Deploy 而不是 Invoke 。可以调用 sawtooth identity policy list,查询当前有哪些策略,比如在执行了刚才的命令后,会得到如下回显:

$ sawtooth identity policy list

policy_1:

Entries:

PERMIT_KEY *

接下来执行如下命令:

$ sawtooth identity role create transactor policy_1

就会把 transactor 的策略设置为 policy_1。换句话说,这时,就真正让 policy_1 生效了,类似于 Fabric 里的 Invoke。然后可以调用sawtooth identity role list,查询当前角色的状态:

$ sawtooth identity role list

transactor: policy_1

上边我们都用 transactor 为例子,其实 role 可以有如下几种:

default、transactor、transactor.transaction_signer、transactor.transaction_signer.{tp_name}、transactor.batch_signer。

意思其实从字面上能看出来,这里 transactor 可以是 organization,一个 transactor.batch_signer 可以是一个 organization 下边的部门,transactor.transaction_signer 可以是该部门的一个用户,如果有好多 tp 的话,该用户可以只具有其中某些 tp 的执行权限。

比如,我们现在自己写了一个新的 tp 叫 supply_chain,新定义了两个用户,一个的公钥是12345,另一个的公钥是23456,我们希望这个 tp 只有这两个新用户可以运行,这时我们就可以执行命令:

sawtooth identity policy create policy_2 “PERMIT_KEY 12345” “PERMIT_KEY 23456”

sawtooth identity role create transactor.transaction_signer.supply_chain policy_2

网络权限设置和 tp 执行权限设置差不多,比如有个 Validator 对外的公钥是00001,然后执行如下命令,它就不能加入网络了:

$sawtooth identity policy create policy_3 “DENY_KEY 00001”

$ sawtooth identity role create network policy_3

$ sawtooth identity role list

network: policy_3

Fabric 和 Sawtooth 的比较

相信看完了 Fabric 和 Sawtooth 的介绍,大家对这两个项目都有了自己的认识。笔者再谈一下个人对这两个项目的理解。

首先,从背景上看,Fabric 是脱胎于 Ethereum 的,或者说能在 Fabric 上看到 Ethereum 的影子,而 Sawtooth 已经看不到 Ethereum 的任何痕迹了。反而,个人觉得 Sawtooth 更加纯粹一点,它就是一个有共同起点的 比特币区块链,只是比特币没有不同 Transaction 的概念,而 Sawtooth 把 Transaction 按照用途分类,且允许用户根据需要自己定义新的 Transaction (这个概念是 Ethereum 提出来的)。

从体系结构角度看,我认为 Sawtooth 明显优于 Fabric 。Fabric 像是针对特定问题的一个专用解决方案,而不像一个通用架构。Sawtooth 可以认为是一个通用架构,然后根据需求变为一个专用解决方案。从访问控制角度看,Fabric 像是根据实际情况建设了一套管网,让涉及隐私的数据只能在其中运行。Sawtooth 则更像是在一套管网上加装了阀门,通过阀门来控制数据的流向。这可能和 IBM 以及Intel 的业务特点和公司文化息息相关。我的印象中,IBM 是一家咨询公司,专门针对企业级用户设计解决方案。Intel 是处理器公司,不管你的业务是什么样的,它提供通用中央处理器,让你能根据自己的需要配置成自己的专用解决方案。

当然,二者也有一些具体的差异:Fabric 中,多个节点收到相同的输入后分别独立执行,以期得到一致的结果。Sawtooth 的 SGX 和基于 SGX 的 PoET 验证的是在一台机器上的执行结果,没有再让每个节点都去执行一遍,而是一个执行完了以后去和别的同步结果。二者的假设不同,效率上也有差别。Fabric 的权限控制依赖形成 channel 这种体系结构,Sawtooth 的权限控制通过 Transaction 本身进行设置。或者说,Fabric 只有特定的人能看,但能看到特定范围内的全部。Sawtooth 所有人都可以看,但 Transaction 的 Permissions 限制了能看什么。Fabric 的 orderer 完成 Transaction 排序,可以实现进程级并行。Sawtooth 的排序是在 batch 里指明依赖关系,通过Completer 排序实现线程级并行。

对 Fabric 来说,要设计它时,大家认可的网络结构就是 Ethereum 了,怎么能稍作修改,实现隐私保护和访问控制是它的设计目标。Sawtooth 没这种包袱,可以重新设计网络。所以,我感觉 Fabric 更像是一个过渡性的产品。从我的角度看,Sawtooth 的结构设计的比较精巧,可扩展性强,这是它比 Fabric 强的地方。但它还可以借鉴 Fabric,增加类似 CA 的机制确保用户可以被识别,也应该增加权限配置的灵活性,比如引入 ABAC,等等。不过,现在这样就已经非常不错了。

推荐阅读:

技术专栏丨Fabric和Sawtooth技术分析(上)

技术专栏丨基于Core ML的通用性机器学习开发框架探索

干货分享丨研发代码质量管理技术最佳实践

技术专栏丨Redis分布式锁的小坑踩一踩

举个例子丨什么是量子计算机?比常规计算机强在哪里?

作者:YK Sugi

译者:赵磊

原文链接:http://t.cn/EZAElk0

本文作者访问了加拿大温哥华的一家名为 D-Wave System 的制造尖端量子计算机的公司,并在那里学习了很多关于量子计算机的知识。

在这篇文章中,作者将通过一个简单地例子让没有物理或计算机科学知识地小伙伴也能搞懂什么是量子计算机,欢迎分享~

1什么是量子计算机

量子计算机是一种使用量子力学原理进行计算的计算机,它能比常规计算机更有效地执行特定类型的计算。

听的是不是有点云里雾里?不是说好了没有物理学或计算机科学知识也能听懂吗?别急,这里将通过一个简单的例子来告诉大家,它到底是什么。

为什么解释什么是量子计算机,首先就需要解释一下常规(非量子)计算机。

2存储信息方式有何不同

一台普通的计算机以 0 和 1 的 序列存储信息,不同类型的信息,如数字、文本和图像都可以使用这种方式表示,这种由 0 和 1 组成的序列中的每个单元都被成为比特位,所以,比特位可以设置为 0 或 1。

量子计算机不使用比特位来存储信息,相反,它使用一种叫量子位的东西,每个量子位不仅可以设置为 1 或 0,还可以设置为 1 和 0。那这到底意味着什么呢?这里用一个简单的例子来解释这个问题:

假设我们在经营一家旅行社,需要把一群人从一个地方搬到另一个地方。

为了简单起见,假设现在只需要移动3个人—— Alice、Becky 和 Chris。我们为此预定了两辆出租车,但想知道谁上了哪辆出租车。另外我们也得到了关于谁和谁是朋友,谁和谁是敌人的信息。

这里我们假设:

  • Alice 和 Becky 是朋友
  • Alice 和 Chris 是敌人
  • Becky和 Chris 是敌人

我们的目标是把这3个人分成两组并实现以下两个目标:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

这是这个问题的基本前提。我们首先考虑如何用常规计算机解决

3用常规计算机去解决问题

要用普通的非量子计算机解决这个问题,首先需要弄清楚如何用比特存储相关信息。

我们把这两个出租车标记为出租车 1 号和出租车 0 号。

然后,可以用3个比特位表示谁进入哪辆车。

例如,我们可以通过将这3位设为0、0 和 1 来表示:

  • Alice 在 0 号出租车
  • Becky 在 0 号出租车
  • Chris 在 1 号出租车

因为每个人有两种选择,所以有 2x2x2 = 8 种方法将这群人分到两辆车上。

这里列出了所有可能的情况:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

使用3个比特位,就可以表示这些组合中的任何一种。

计算每个配置的得分:

现在,使用常规计算机,我们如何确定哪种配置是最好的方案呢?

为此,我们需要定义如何计算每个配置的得分。这个分数将代表每个解决方案达到我前面提到的两个目标的程度:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

我们简单定义分数如下:

给定配置的分数 = 共享同一辆车的朋友对数 – 共享同一辆车的敌人对数

例如,假设 Alice、Becky 和 Chris 都乘坐出租车1号。用三个比特表示为 111。

在这种情况下,只有一对朋友共用一辆车—— Alice 和 Becky。

但是却有两对敌人共用一辆车——Alice 和 Chris 以及 Becky 和 Chris。

所以,这个配置的总分为 1 – 2 = -1。

解决问题:

有了这些,我们终于可以着手解决这个问题了。

对于一台普通的计算机,要找到最好的配置,需要遍历所有配置,看看哪个达到了最高分。

构建的表格如下:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最佳解决方案之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最佳解决方案

1 | 1 | 1 | -1

这里有两个正确的答案——001 和 110,都达到了 1 分。

这个问题相当简单。但是随着越来越多的人参与到这个问题中来,用一台普通的电脑很快就会变得难以解决。

可以看到如果是3个人,需要遍历8种可能的配置。

如果有4个人呢?我们需要遍历 2x2x2x2 = 16 个配置。

对于n个人,我们需要通过遍历2的n次方个配置来找到最佳解。

所以,如果有100个人,我们需要遍历:

2¹⁰⁰ ~= 10³⁰ 个配置

因此这是常规计算机根本无法解决的问题。

4用量子计算机去解决问题

那么如果我们用量子计算机来解决这个问题呢?

让我们回到把3个人分到两辆出租车的例子。

正如我们前面看到的,这个问题有8种可能的解决方案:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

用一台普通的计算机,用3个比特位,一次只能表示其中一个解——例如 001。

然而,使用量子计算机,通过3个量子位,我们可以同时表示所有8个解。

关于这个说法的确切含义存在争议,但作者的看法是这样的:

首先,来看这3个量子位中的第一个量子位。当将其设置为 0 和 1 时,就好像创建了两个并行世界。

在其中一个平行世界中,量子位被设置为 0,而在另一个平行世界中为1。

现在,如果再把第二个量子位也设为 0 和 1 呢?就像是创造了4个平行世界。

在第一个平行世界中,两个量子位被设置为 00,第二个平行世界中是 01,第三个平行世界中是 10,第四个平行世界中是 11。

类似的如果将这三个量子位都设置为 0 和 1 ,就会创建8个平行世界——000、001、010、011、100、101、110 和 111。

虽然这是一种奇怪的思考方式,但它是解释量子比特在现实世界中的行为的正确方式之一。

现在,当对这三个量子位进行某种计算时,实际上是在同时对这8个平行世界进行同样的计算。

因此,我们可以同时计算所有解的分数,而不是按顺序遍历所有这些可能的解。

有了这个特殊的例子,理论上量子计算机可以在几毫秒内找到最好的解——001 或 110,正如我们之前看到的:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最优解之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最优解

1 | 1 | 1 | -1

实际上,要解决这个问题只需要让量子计算机去做两件事:

  • 所有可能的解都用量子位表示
  • 将每个可能的解转化成分数的函数。在本例中,这个函数计算共享同一辆车的朋友对和敌人对的数量。

具备了上述两个条件,量子计算机将在几毫秒内给出其中一个最好的解决方案。在本例中,分数为 1 的是 001 或 110。

现在从理论上讲量子计算机每次运行都能找到最好的解。

然而,实际上在运行量子计算机时有可能存在错误。所以,它可能会找到次优解,次次优解,等等。

随着问题变得越来越复杂,这些错误变得越来越突出。

因此,在实践中可能需要在量子计算机上运行相同的操作数十次或数百次。然后从结果中选出最优解。

量子计算机的改进之处:

即使有一些缺陷,但量子计算机也不会遇到常规计算机那样的计算规模问题。

当有3个人需要分到两辆车上时,需要在量子计算机上执行的操作数是1。这是因为量子计算机同时计算所有情况的分数。

当有4个人的时候,操作的次数仍然是 1。

当有100人的时候,操作的次数仍然是 1。仅仅一次操作,量子计算机就能同时计算出2¹⁰⁰ ~ = 10³⁰ 种情况的分数。

而正如之前所说,在实践中最好运行量子计算机几十次或几百次,然后从得到的结果中选出最好的结果。

5总结

D-Wave Systems 最近推出了一个与量子计算机交互的云环境。

如果你是一名开发人员,并且想使用量子计算机,可以尝试这种简单的方法:

  • 名称:Leap
  • 地址:https://cloud.dwavesys.com/leap

可以免费使用它来解决很多问题,并且在注册后还可以看到很多关于量子计算机的相关教程。

备注:在本文中,作者使用术语“常规计算机”来指代非量子计算机。然而,在量子计算行业中,非量子计算机通常被称为经典计算机

技术专栏丨Fabric和Sawtooth技术分析(上)

背景

Fabric 和 Sawtooth 是 Hypherlegder 的两个重要企业级项目,在国家鼓励区块链无币化的当下,受到了广泛的关注。当我们希望改造传统项目,实现多方数据自动化对账、自动化运维等功能时,它们往往成为了最佳的选择。但它们各自有什么特点,又应该如何选择呢?本文将分别分析这两个项目的结构和特点,又对它们进行了比较和总结。

区块链本身和虚拟货币(Token)没有任何关系,比特币,Ethereum 等引入虚拟货币所起的作用是费用计量,并通过费用来控制用户对资源的使用权限。在传统互联网体系结构中,访问权限的实现方式并不是只有通过货币一种。所以,区块链的应用价值本质上还是取决于它能做什么,或者说它是否可以作为一种通用技术广泛服务于商业领域,并提供现有系统无法实现的功能。

当然,有人看到 Fabric 框架的问题以后,选择自己改动其中不合理的部分。假如A看到了问题,项目开发者也看到了,随后B在新版本中进行更改,而且改法与A不同,那样就会有版本更新的风险。所以最合理的方式还是尽量不改要动现有项目的核心部分,而是搞清楚之后,再进行合理的选择。从最后的比较结果看,笔者是强烈推荐 Sawtooth ,因为从通用性,灵活性角度看,几乎找不到 Sawtooth 的缺点。

本文将分为上下两部,本篇将讲述 Fabric 的相关内容,下一篇将为小伙伴们带来 Sawtooth 的相关内容敬请期待。

一、Hypherlegder Fabric 的分析

Fabric 是 IBM 公司推出的企业级区块链,2017年 IBM 将其贡献给 Hypherlegder 项目。本文将主要从 Fabric 产生的原因,Fabric 的特点,和 Fabric 的结构及工作流程做简要介绍。

Fabric 产生的原因

Fabric 的诞生主要是因为在金融、销售、供应链等特殊应用领域中,一些机构的数据不能公开,而且并不是所有的机构都有权力发起 Transaction。而在 Fabric 诞生之前,主流的区块链结构 Ethereum 的体系结构不能满足数据的隐私与访问控制需求。正是看到这一机会,IBM 在2017年推出了 Fabric。这之前其实有个插曲,2014年美国几十家银行成立了一个 R3 区块链联盟,目的就是满足金融领域中带有特殊访问控制和隐私保护需求的区块链技术,结果2017年,R3 觉得当隐私保护和访问控制需求变为主流需求后,区块链并不是必须的,于是把自己从“区块链新创公司”改成了“受区块链启发的新创公司”。

所以,在分析 Fabric 时也不必把“区块链”这种新存储结构看得和传统结构有什么不同,因为 Fabric 主要是要弥补在它出现前的技术的不足。从体系结构角度看,Fabric 其实并不新颖。

Fabric 的特点

Fabric 把区块链分为需要许可的和不需要许可的区块链(Permissioned vs Permissionless Blockchains)。众所周知参与 Ethereum 的用户是匿名的,也就是任何人都可以参与,所以 Ethereum 是不需要许可的区块链,向 Ethereum 网络中提交一个合法的(只要有以太币即合法) Transaction,所有节点都会独立执行合约(根据数据)得到输出并生成区块。对 Ethereum 这种不需要许可的区块链来说,由于程序和数据在所有节点上执行,跟本没啥保密可言。这对很多应用是不行的,比如,做销售,供应的,哪里还有底价一说,大家知道的都一样。还有用户位置、等等隐私数据也不能全网暴露。

Fabric 针对不需要许可的(Permissionless)区块链存在的问题提出需要许可的(Permissioned)区块链,简单来说,就是在所有节点中选择一部分,形成一个个的联盟,特定 Transaction 只在联盟内的节点独立运行,这样只有经过选择的特定节点参与执行 Transaction,数据只在这部分节点范围内公开,这样隐私和访问控制就有可能缓解了(与Ethereum相比,效率提高也是自然的,虽然不是 Fabric的主要目标)。

具体怎么解呢:配置文件。在不同的配置文件里写好访问控制逻辑即可,谁可以做什么一目了然。这里 Fabric 假设,进到联盟中的就没有坏人了,不会有节点通过有问题智能合约捣乱。为此,Fabric 提供了一套 CA ,确保联盟内任何人的身份都是可以验证的,其行为,包括修改网络设置,部署智能合约等可以被记录在区块链上,并且有人为其背书。这就可以识别出捣乱的人。

Ethereum 等技术是遵循顺序执行的体系结构 (order-execute architecture) 的。需要先验证所有 Transaction 的执行顺序,然后把状态复制到所有节点上,然后每个节点各自顺序执行。简单来说就是在架构上就没考虑过 Transaction 的并行。Fabric 引入了一种称为(execute-order-validate)的架构。先执行 Transaction 然后再检查它的正确性,然后为其背书;通过可插拔的共识协议给 Transaction排序;在提交给账本前,用应用程序描述的背书策略(application-specific endorsement policy)验证 Transaction。这里所谓“程序描述的背书策略”是指哪些节点,多少节点,需要保证给定智能合约执行的正确性。这种结构允许 Transaction 并行执行,提高了效率,因为非确定性的(non-determinism)、不一致(inconsistent)的结果可以在排序(ordering)前被过滤掉,使得 Fabric 可以支持标准编程语言(standard programming languages),智能合约可以用 Go 或者 Node.js 来写,将来也支持 Java。

当我们面对隐私保护需求的时候,可能有不同的解决方法。Fabric 列出了下面几种:

1) Fabric 认为,一种是数据加密。但由于加密数据被部署到每个节点上,只要给定足够的时间和计算资源,加密可以被破解。(这显然是Fabirc的设计者想当然,但 Fabric 把它作为 Permissioned 体系结构存在意义的证据)。

2) Fabric 认为,另一种是零知识证明,但零知识证明需要相当可观的时间和计算资源。

所以,为了解决数据的访问控制与隐私保护问题,Fabric提出了一种称为 channel 的体系结构,只有参加 channel 的 nodes 有权访问 smart contract(Fabric 称为 chaincode)和数据。(在我印象中,76年现代密码学的开山之作就是说怎么干这事,说是 Fabric 提出的,不太合适,但 Fabric 确实是用这种方法在网络中隔离出一个个的联盟)。

Fabric 的网络结构

下面是一个 Fabric 示例网络结构图。图中的字母:R代表 organizations,图中共有 R1、R2、R3 和 R4四个组织(organizations)。P代表 Peer node,P1 隶属于 R1。S 代表 Smart Contract,L 代表 Ledger,图中 L1,S5 物理部署于 P1 上。C 代表 channel。NC 是n etwork configuration。CC 是 channel configuration。CA 是 Certificate Authority。A 代表 Client application,这里是用户操作的界面。O 是 ordering service,或者叫 orderer。

放眼过去,是不是觉得很杂乱?不要急,接下来 Fabric 会告诉我们怎么一步步形成这样的复杂体系结构。先来看图中的 R4 以及它的网络配置文件 NC4,以及排序服务O4,和提供身份服务的 CA4。NC4 包含初始网络管理能力设置的策略。简单点说,就是 R4 有权配置网络。CA 的功能比较简单,基本上众所周知,就不再赘述了。

接下来增加一个新的组织 R1 和为 R1 内用户提供身份服务的 CA1。此时,可以由 R4 修改配置文件 NC4,令 R1 具有和 R4 一样的管理权限。

在联盟的基础上,就可以创建 channel 了。C1 表示 channel ,根据CC1 创建。它是联盟内部成员之间的主要通信机制。这里联盟内有 R1 和 R2,CC1 由它们控制,R4 不能参与。注意,C1 需要与 O4 相连。这样的目的是,只要能连上 O4,就能与 C1 连接的节点通信。

接下来,Peer node P1 连接到 channel,它可以通过 C1 与 O4 通信。注意,L1 物理部署在P1上,从数据存储角度,可以把 L1 看做待访问资源。逻辑上,L1 可以被所有能够连接到 C1 的节点访问。加入过程是通过 P1 发送一个连接 C1 的请求给 O4,然后 O4 根据 CC1 的策略设置决定 P1 可否连接 C1。

接下来,智能合约 S5 可以被安装到 P1 上,P1 可以看到 S5 的代码。R1 中的一个 Client Application A1 可以加入 C1,并通过 P1 执行 S5 来访问 L1。这时,由于 A1 是 R1 的成员,它可以选择连接O4 或者 R1,通过它们中的哪个都可以连接上 P1。S5 由 R1 实现,并在 P1 上安装。而且 S5 还要在 C1 上安装,以便别的 Client Application 可以找到它。

我们可以继续加入资源P2到C1上:

把上图中的C1简化掉,得到下图:

然后可以再增加一个联盟如下图:

然后再在新联盟内建立一个 channel 如下图:

在新 channel 上连接新的资源 P3 如下图:

此时,P2 既可以被 C1 内节点访问,也可以被 C2 内节点访问,可以把 P3 上的资源同步到 P2 上,如下图:

这样就得到了开始看到的网络结构图。

通过上述网络结构可以看到,Fabric 的访问控制机制大体上分为两层,一层是关于安全的,或者叫成员服务,也就是说画个圈,把成员划进来。另一层是关于隐私的,意思是一个 Transaction 可以指定由所有成员中的一部分来执行,这样别人就看不到程序和数据了。

Fabric 的通信流程

我们先看看Client Application请求资源的流程,如下图:

首先,通过 orderers ,Peers 确保 Ledger 总是保持最新状态。以 A调用 S1 来查询或者更像 L1 为例,P1 收到合法调用请求后,调用 S1 生成一个应答。A 在收到应答。如果是查询请求就结束了。如果是更新请求,A 在它收到的所有应答基础上构造 Transaction 发给 O1 。O1 收集网络上的 Transactions,并且分发给所有 peers,包括P1 。peers 验证 Transaction,通过后更新 L1,然后生成一个事件。

接下来,我们再看看通信的具体流程:

endorsing peer 主要是给 client 背书的。它的功能是验证,然后再签名,有些 endorsing peer 可能不在线,有些可能不理 client。client 在收集到足够的(达到背书策略要求的)背书 endorsing peer 后,把 transaction 发给 orderer。orderer 再把 transaction 发给具体执行智能合约的 committing peers。这里 Fabric 说得不够细致,orderer 在这样的通信流程中是很重要的,如何保证 orderer 在处理这些来自不同节点的信息的时序性呢。Fabric 没说清楚,我们只能假设它做到了。但这是隐患,在分布式系统中保持全局时序一致性并不容易。

我们知道,更新 Transaction 和查询 Transaction 是不同的,更新涉及到写入操作,需要所有相关节点达成共识后才能执行,一个 peer 是不能更新 Ledger 的。所以,为了实现共识,Fabric 更新涉及到3个阶段。

Phase 1: Proposal:Transaction proposals 被每个返回背书 proposal 的 peer 独立执行。

A1生成 Transaction T1 带 proposal P,然后发给 channel C 上的 P1 和 P2 。P1 执行 S1 使用 T1 带 P,以 R1 带 E1 相应。P2 执行 S1 使用 T1 带 P,以 R2 带 E2 相应。A1 收到这两个响应。

Phase 2: Packaging:orderer 的第一个角色是给 proposed ledger updates 打包。

A1 发送由 E1 和 E2 背书的 Transaction T1 给O1。并行的 A2 发送由 E1 背书的 Transaction T2 给 O1。O1 把来自 A1 的 T1 和来自 A2 的 T2,以及其它可能得 Transactions 打包 到 Block B2 中。我们可以看到 transaction order 是T1、T2、T3、T4、T6、T5。

Phase 3: Validation:orderer 的第二个角色是把 Block 分发给 peers。

O1 把 block B2 发给 peer P1 和 P2 。P1 处理 B2,添加一个新的 block 到 P1 的 L1 上。并行地,P2 也处理 B2 ,添加一个新的 block 到 P2 的 L1 上。一旦这一过程完成,L1 就在 P1 和 P2 上被一致更新了。然后它们分别通知自己连接的 applications ,Transaction就被处理了。

账本示例:fabcar

fabcar 是一个 Fabric 的例子应用,执行它会创建如下 Ledger 。该例子创建一个 car 的集合,有不同的颜色、制造商、牌子、所有者。

账本 L 包括一个 world state W 和一个区块链 B 。W 包含4个状态,key 是 CAR1、CAR2、CAR3 和 CAR4。B包含两个blocks:0 和 1。Block 1 包含4个 Transactions T1、T2、T3、T4。

总结

看完 Fabric 结构流程等介绍,笔者的第一个感觉是 Fabric 对标的是 Ethereum ,它所有的技术、结构等的设计都是为了解决 Ethereum 中的问题,可以看到它确实做到了。

所以,给人一种直观的感觉是 Fabric 不像是一个通用企业级架构,而是一个企业级的解决方案。Fabric 定义的 Transactions 有两类,一种叫 Deploy transactions,是用来部署 chaincode 的。另一种叫 Invoke transactions,是用来执行已经部署的 chaincode 的。从这里的 Deploy transactions 设计可以看出,Fabric 已经有把 Transaction 本身作为 on-chain 的设计思想了,但总体上却大量依赖配置文件,并未充分利用区块链本身实现对区块链的配置。

因此让人感觉虽然 Fabric 可以实现预设的功能,但如果想稍作改动(实际情况中的常态),配置文件的管理可能隐藏很多潜在问题。Fabric 中的 Ordering service 是一个关键。它为 clients 和 peers 提供了共享的通信 channel,为包含 Transaction 的消息提供广播服务。Client 连接 channel ,可以广播消息到所有 peers 。换句话说,channel以相同的逻辑顺序将同样的消息发送给所有与其相连的 peers 。

简单来说它的功能就是按照当前配置文件中设定的网络结构,或者说控制结构规则将收到的消息或者交易转发给相应的节点。order 非常像现在网络中的路由器,或者说入口网关。Fabric 的并行化更像是传统电脑中的进程级的并行,针对的改进对象是单用户没有并行功能的系统。

想成为数据科学家?这5个基本统计学概念不能不知道!

译者:TalkingData 赵磊

原文作者:George Seif

原文链接:t.cn/EzFQvOi

如果说数据科学是一门艺术,那统计学可谓是这门艺术的敲门砖,从高层次的角度来看,统计是利用数学对数据进行技术分析。一个很基本的数据可视化如条形图,就能解读出一些高级的信息。

而如果通过统计学,我们就能以一种更加以信息驱动和更有针对性的方式来操作数据,所用到的数据的方法,可以帮助我们对数据形成具体的结论,而不是靠拍脑袋的猜测。

通过使用统计学,我们可以更深入细致地去了解数据的构造,并基于该结构,还可以用其他数据科学来获取更多的信息,将结果最大化。本文将和大家分享数据科学家们需要了解的5个基本统计概念,以及如何更有效地运用它们,希望对小伙伴们有所帮助。

//统计特征//

统计特征大概是数据科学家种最常用的统计概念了,它通常是数据科学家们在研究数据集时应用的第一种统计技术,包括偏差、方差、平均值、中位数、百分位数等等。比较容易让人理解以及在代码中去实现,如下图:

一个简单的箱型图

中线是数据的中位数,由于中位数对离群值的鲁棒性更强,因此中位数比平均值用得更多。第一个四分位数本质上是第25百分位数,表示数据中25%的点低于这个值。第三个四分位数是第75百分位数,表示数据中75%的点都低于这个值。最小值和最大值表示数据范围的上、下端。

这个箱型图完美地阐述了我们能用基本统计特征做什么:

  • 当框图很短时,它意味着许多数据点是相似的,因为在小范围内有许多值;
  • 当框图很长时,它意味着许多数据点是完全不同的,因为这些值分布在一个较广的范围内;
  • 如果中值更接近底部,就可以知道大多数数据的值更低;
  • 如果中值更接近顶部,就可以知道大多数数据都有更高的值;
  • 基本上,如果中值线不在方框中间,那么它就表示数据有偏斜;
  • 是否有长尾?这意味着你的数据有很高的标准差和方差,说明这些值是分散的,高度不同。如果在盒子的一边有长尾而在另一边没有,那么数据可能只在一个方向上有很大的变化;

以上这些信息都来自一些简单的、容易计算的统计特征,当需要对数据进行快速而有效的查看时,可以尝试这些方法。

//概率分布//

我们可以将概率定义为某个事件发生的概率百分比。在数据科学中,通常在0到1之间进行量化,0表示确信不会发生,1表示确信它会发生。概率分布是一个函数,表示实验中所有可能值的概率。

详情请看下面的图表:

均匀分布是本文三个分布中最基本的分布,它只有一个只出现在某个范围内的值,而超出这个范围的任何值都是0。通常,它是一种“开关”分布。我们也可以把它看作是一个有两个类别的分类变量:0或其他值。分类变量可能有多个非0的值,但我们仍然可以把它想象成多个均匀分布的分段函数。

正态分布,通常被称为高斯分布,由均值和标准差定义。均值在空间上平移分布,标准差控制分散程度。与其他分布的重要的区别(比如泊松分布)是,其所有方向上的标准差都是一样的。

泊松分布与正态分布相似,但增加了偏斜因子。在偏态值较低的情况下,泊松分布会像正态分布一样向各个方向均匀发散。但当偏度值较大时,我们的数据在不同方向的发散会有所不同;在一个方向,它将非常分散,而在另一个方向,它将高度集中。

虽然有很多的分布可以深入研究,但上述三个分布已经可以为我们带来很多探索的价值,比如:可以用均匀分布快速地查看和解释分类变量。如果看到一个高斯分布,就能知道可以用很多算法去处理它。有了泊松分布,就必须小心谨慎地选择一种对空间发散的变化具有鲁棒性的算法。

// 降维//

降维这个术语很容易理解:我们有一个数据集,希望减少它的维数。在数据科学中,它是特征变量的数量。

请看下面的图表:

降维

立方体代表数据集,它有三个维度,总共有1000个点。虽然1000个点的计算在今天很容易处理,但是,更大范围的点我们仍然会遇到很多问题。若是仅从二维的角度来看数据,例如从立方体的一边可以看到,划分所有的颜色很容易,通过降维,我们可以将三维数据投射到二维平面上。这有效地将我们需要计算的点数减少了100,大大节省了计算量。

特征剪枝是另外一种降维的方法。通过特征剪枝,可以删除对分析不重要的任何特征。例如,在研究数据集之后可能会发现在10个特性中,7个特性与输出强相关,而其他3个特性的相关性很低。那么,这3个低相关特性可能不值得计算,可以根据分析在不影响输出的情况下将它们删除。

当前用于降维的最常见技术是PCA,它本质上是创建了特征的向量表示,显示它们对输出的重要性,比如相关性。PCA可以用于上面讨论的两种降维方式。

过采样和欠采样是用于分类问题的技术。有时分类数据集可能会严重倾斜到一边。例如,类1有2000个样本,但类2只有200个。这将对很多常用于建模并预测的机器学习技术带来影响,但过采样和欠采样可以改变这一点。

示例请看下面的图表:

欠采样与过采样

上图中蓝色类比橙色类拥有更多的样本,在这种情况下,有两个预处理选项可以帮助于机器学习模型的训练。

欠采样意味着将只从多数类中,只使用与少数类样本数相同的数量,并且这个方案应当保证采样后类别的概率分布与之前相同。操作并不复杂,其实只是通过取更少的样本来平衡数据集。

过采样意味着将创建少数类的副本,以便拥有与多数类相同的样本。创建副本时应当保证少数类的分布不变。这个方案只是把我们的数据集变得更均衡,而不是得到更多的数据。

//贝叶斯统计//

如果要充分理解为什么要使用贝叶斯统计,那么首先需要了解频率统计不足之处。频率统计是大多数人听到“概率”这个词时会想到的统计方法。它应用数学来分析某些事件发生的概率,具体来说,我们使用的数据都是先验的。

举例说明:一个骰子掷出6的概率是多少,大多数人会说是1 / 6。确实,如果我们做频率分析,会通过一些数据比如某人掷骰子10000次,然后计算每个数字出现的频率;大概是1 / 6

但如果骰子是经过改造的,落地后总会是6的那面朝上呢?频率分析只考虑了先验的数据,并没有考虑骰子被改造过这个因素。

贝叶斯统计确实考虑到了这个问题,可以用贝叶定理来说明这一点:

方程中的概率P(H)是频率分析;表示根据之前的先验数据,事件发生的概率是多少。方程中的P(E|H)被称为似然,本质上是根据频率分析得到的信息的条件下,我们得到的结论是正确的概率。例如,滚动骰子10000次,而前1000次全部得到6,就可以认定骰子是被改造过的,P(E)是实际结论成立的概率。

如果频率分析得很好,那么就可以得出:对于骰子6的一面朝上的猜测是正确的,即考虑了骰子是被改造的。

从方程的布局可以看出,贝叶斯统计考虑了所有的因素。当觉得之前的数据不能很好地代表未来的数据和结果时,就可以去使用贝叶斯统计。

TalkingData CTO 到任,快来认识下吧

大家好,我是TalkingData的程序员小D。是的,我又来客串小编啦!今天呢,主要是想跟大家分享一个我司的大新闻——

前Splunk全球工程副总裁王亭先生加入TalkingData并担任CTO(首席技术官),全面负责产品研发管理工作。

就是这位,快来认识下吧!

TalkingData首席技术官 王亭

王亭先生在企业软件产品研发、技术创新及团队管理方面有着非常丰富的实践经验,曾在多家世界500强公司及北美知名大数据公司承担重要管理工作。

在加入TalkingData前,王亭先生就任于大数据业内首家上市的知名创新公司Splunk,担任高级工程总监以及全球工程副总裁,主导Splunk首个美国以外的上海研发中心从0到1的组建,打造起一支世界级研发团队,成功交付SaaS分析产品以及移动解决方案创新;后又调任硅谷总部负责Splunk数据生态产品和解决方案研发。

此外,王亭先生还曾担任SAP Business Intelligence Group全球副总裁,主导Business Objects Dashboards和Crystal Reports两项关键产品研发以及新一代SAP数据可视化平台创新;并曾任EMC Documentum Group中国研发负责人,管理企业搜索、核心工程及内容管理创新的研发团队。

对于这一重要的人事任命,TalkingData CEO崔晓波先生可谓信心满满,他在内部信中提到:“王亭先生的加入将显著提升TalkingData在数据工程、数据科学、数据产品等方面的核心能力。王亭先生拥有深厚的行业经验以及管理经验,也将帮助TalkingData提升研发管理水平以及团队效率。”

在9月举办的T11 2018暨TalkingData数据智能峰会上,我们重磅发布了SmartDP 2.0——TalkingData数据中台。此次王亭先生就任CTO,不仅将强化TalkingData的产品研发能力,也将重点推动数据中台战略后续的发展和落地。

小D代表全体TDer热烈欢迎王亭先生加入!在王亭先生的带领下,小D和TalkingData全体产品研发小伙伴们也会更加努力,为大家带来更高更快更强的数据能力,敬请大家拭目以待。

新闻播报完毕,我们下回再见!

技术专栏丨基于Core ML的通用性机器学习开发框架探索

Core ML 概览

机器学习不仅是目前最火的技术,同时也是人工智能最核心的内容。机器学习是一种能让计算机无需不断被显示编程,而自我学习的人工智能技术。不通过某个具体的编程算法,而是在大量的数据样本中找到一个合适的模式或者规律,从而让计算机能够不断的自我发展和完善自我的算法。

一般情况下,机器学习模型都是庞大且复杂的,截止到目前,能够直接进行模型训练的方式和架构还暂未出现,当前的方法是将训练好的模型文件应用在移动设备上,使用预制的框架加载与使用模型,或者通过API 的方式联网远程预测等。

相对来说,通过远程预测的方式可以保证安全性,但却严重依赖网络环境,为了避免不确定的网络环境所带来的预测失败或无法预测等异常情况,可以将模型文件直接应用在移动设备上,这样不仅能够保证时效性,也无需再依赖网络环境,这种方法对于推理预测来说有了保证。

自 iOS 11 开始,苹果在 iOS 系统中引入了一种全新的,直接依附于硬件平台的机器学习框架——Core ML,该框架使机器学习模型在 iOS 系统平台下预测推理可以快速并易于实现。借助 Core ML,可以将已训练好的机器学习模型,集成到自己的应用当中,以实现智能化的应用程序,提升用户体验等。

已训练模型 (trained model),指的是对一组训练数据应用了某个机器学习算法后,所生成的一组结果。举个例子,通过移动设备上附带的传感器数据来训练一个能够识别用户行为类型(走、跑、乘车等)的模型,将该模型应用于应用程序中后,该模型可以对用户使用移动设备时所做出的行为进行预测(该模型目前已在 TalkingData SDK 中实现并应用)。

在iOS体系中,Core ML 是领域特定 (domain-specific) 框架和功能的基础所在。Core ML 为 Vision 提供了图像处理的支持,为 Foundation 提供了自然语言处理的支持(例如 NSLinguisticTagger 类),为 GameplayKit 提供了对学习决策树 (learned decision tree) 进行分析的支持。Core ML 本身是基于底层基本类型而建立的,包括 Accelerate、BNNS 以及 Metal Performance Shaders 等。

Core ML 针对设备的性能进行了优化,最大限度地减少了内存占用和功耗。因其在设备上运行有着严格要求,这不仅保护了用户数据隐私,而且当网络连接丢失时,还能够保证应用能正常工作和响应。

Core ML的缺点

Core ML本身是非常优秀的,它使得将机器学习甚至深度学习模型移植到移动设备上变为了可能。但是不得不说的是,Core ML 也有一定的局限性:

  • Core ML 目前仅能进行预测,无法进行模型的训练。训练模型只能在 PC 上或者云上训练,之后再转为 Core ML 支持的格式才可使用;
  • Core ML 目前所支持的深度学习隐藏层运算函数有限;
  • Core ML 目前的方式不利于模型的更新。当模型集成进应用程序后,如果要更新模型或模型发生了异常,只能通过线下更新模型,并且之后还需要重新提交应用,进行审核;
  • Core ML 目前的模型接口函数的调用,缺少统一性的 API 管理,大多数的模型在移植进 iOS 应用程序后,所产生的 API 大同小异,但 Xcode 都会产生一整套重复的接口文件等。

鉴于以上问题,经过调研和不断的试验,最终找到了一个较为合适,但不敢说是完美的方案。

通用性的模型加载预测框架

在 iOS11 中,所有的预训练模型 .model文 件,在 App 中的存在格式都是经过 Xcode 自动转换过的 .mlmodelc 文件,该文件是 Core ML 框架加载和使用的参数文件,本项目也正是借助此特性,在线下载已经训练好的预训练模型,然后使用 Core ML 提供的 API 来进行文件转换,之后进行加载使用。

这样避免了应用程序最初就带有预训练模型,避免了初始应用程序包过大,给用户造成下载应用程序的忧患。根据上述调研结果,设想该框架的整体架构如下:

通过 URL 请求,下载经过压缩的预训练模型,在压缩之前,模型已经是完整的符合 Core ML 要求的 .model 格式。下载完成后,进行文件解压缩,同时使用 Core ML 提供的模型编译 API ,完成对 .model 模型文件的编译,产生 Core ML 直接可以使用的 .mlmodelc文件并存储在本地磁盘,等待随时的加载使用。

当开发者调用该框架启动 API 后,该框架使用 Core ML 提供的模型加载 API 预加载模型到内存,开发者根据自己的需求在适当的时机将符合格式的数据传递给模型预测 API,模型进行预测推理后给出结果,开发者根据结果实现自我业务逻辑等。

工作流程

经过试验后,整理出了一套可以直接在应用程序中使用的开发框架,开发者不需要过多的设定,仅仅需要在应用程序中配置好所需要使用的模型下载地址,之后在合适的时机调用框架的启动接口即可。当一个机器学习任务来临的时候,调用该框架的预测接口,传入数据(例如图像)即可获得预测结果,直接使用。

使用示例

以 MobileNet 图像识别模型为例,使用Swift进行相关代码编写。

  • 在项目中新建一个 plist 文件,假设命名为 MobileNet-Model.plist ,定义 MobileNet 模型基本信息与下载地址,如下图:

  • 初始化框架对象:

  • 启动框架并传入模型定义plist:

  • 传入数据进行预测与结果使用:

示例结果:

总 结

通过该框架,可以减轻开发者繁重的机器学习模型集成压力,开发者只需要关注模型所需数据的格式即可快速开发有关机器学习任务。

目前该框架可用于大多数的图像分类模型,基本用法同上述示例,接下来我们将进一步的扩展和优化该框架,使其能够适应更多的模型,让移动端的机器学习应用开发更加的得心应手。

备受瞩目的智能营销到底带来了什么?营销人才会被替代吗?

营销是最常见的经济活动之一,因为有商品,就得有营销。

在商业活动和科技不断发展的过程中,营销也在不断发展变化。从最简单的招牌、广告,再到广告植入、热点营销、社群营销……营销无处不在,变化多端。

随着移动互联网和大数据技术的日益广泛应用,这个古老的行业正在嬗变:人类历史上从未出现过的大规模精准营销正在成为现实。

信息不对称一直是经济活动中的重要问题。正如在营销领域,人们经常抱怨:“我知道我一半的广告投放费用是在浪费,可是我不知道哪一半是在浪费。”在商品极大丰富、人群需求日益多元的今天,这一问题更为突出。智能营销的发展,使得精准营销正成为可能,将商品信息精准推送给有需求的消费者,这不仅将改变诸多企业,也将改变消费者的生活。

智能营销能带来什么

随着数据维度的不断丰富,应用场景的不断增多,尤其是移动化所带来的位置数据、物联网数据的日趋丰富,数据营销也在快速演进,中国的智能营销时代正在到来。

宝洁首席品牌官Marc Pritchard曾感慨:“尽管在美国市场我们的广告花费就达到了惊人的2000亿美元,但是我们行业的整体增长却严重贫血。”

清华大学经济管理学院营销系助理教授梁屹天说,传统的广告投放方法最大的问题是广告主不知道自己投的广告是否有用,“我知道我一半的广告投放费用是在浪费,可是我不知道哪一半是在浪费。”

但随着科技的发展,这种状况正在被改变。最近几年,在营销行业最火的概念,非MarTech莫属。这一新营销方式不仅在改变诸多行业,也在改变广大消费者的生活。

MarTech是什么

假设,一位老人在某搜索引擎上搜索“健康险”,B保险公司出现在首位,老人点击进入浏览了该公司的各种保险品种,并在“老年健康险”的页面停留最久,填写注册了自己的手机号,但在输入身份证号的时候放弃了。

与此同时,这位老人的行为已被B保险公司所使用的数据公司提供的平台监测到,并通过分析为老人打一个标签,也就是所谓的用户分群。通过特殊标签打包分析后,平台就会给包括这位老人在内的同一标签用户推送“老年健康险”优惠券,这种精准推送就是智能营销的一种。

上述过程就可以被看作是MarTech的一个应用场景。

梁屹天解释,通俗地讲,MarTech就是以数据和多场景的落地能力作为驱动去做营销方案,把推送的内容和消费者作一个匹配,也就是说找到适合的人,推送给他们可能会喜欢的服务,而不仅限于内容。

关于MarTech,要从9年前说起。彼时,Google发布了首个实时竞价广告系统AdEx 2.0,Adobe收购分析工具公司Omniture,开始在数字营销领域开展业务。这两个事件,被业界认为是营销技术出现的标志。

在营销行业的专家看来,在此前后,大数据技术的发展,为MarTech奠定了基础。随着大数据的应用日益广泛,营销人员不再需要按照以往的营销路数去猜客户喜欢什么,而是利用大数据去预测客户需要什么。

当前,开展MarTech业务的公司无不竭尽全力进行数据搜集与整合应用。

TalkingData合伙人兼副总裁高铎表示,拥有足够广度和深度的数据是进入MarTech行业的第一道壁垒,第二道壁垒是如何使用和分析这些数据的技术,第三道壁垒是将数据和技术结合,进而应用在一些场景里解决问题。

TalkingData基于大数据能力推出的“智

营销人才会被取代吗

当MarTech技术发展到一定程度,是否就不需要专业的营销人才了呢?

梁屹天表示,现在一些拥有海量规模大数据的公司并不擅于使用数据。“比如国内某知名游戏公司,尽管拥有庞大的数据,但我惊讶地发现这家企业的很多重要决策都是团队拍脑袋决定的,比如网游里面道具的定价。”

“尽管这家公司可以通过MarTech来给用户进行画像,了解玩游戏的人是哪些群体,有什么特征,进而可以利用这个群体的画像做精准的推送广告内容,但也仅到这个层面。”梁屹天说,“道具如何定价更合理还是没有科学的解决方案。”

梁屹天认为,在未来五到十年,甚至在更长的时间,无论MarTech技术成熟到哪一步,他认为对于经济、营销等专业的复合型人才的需求不会减少反而会增加。

高铎也持相同的观点:“数据公司可以使用计算机自动对某个产品的用户群体画像,但营销的目的不是画像,而是如何增加新客户以及做好老客户的运营,所以如何使用画像才是关键,这不是单纯用技术就能解决的,还要有专业的人才参与。”

中国更有潜力

全球数据营销行业的领军人物、MarTech发起人Scott Brinker用每年的营销科技全景图记录了这一行业的变迁。

2011年,全球仅有150家数据营销公司,包括网站管理、早期的广告技术、搜索营销、邮件营销等公司。

此后,这一领域的公司几乎每年都以翻倍的速度快速增长。2018年,全球从事数据营销业务的企业数量已达7000家。这些公司涵盖了广告和促销、内容和体验、社交与关系、商业和销售、数据、管理等不同领域。

据媒体统计,目前,中国数字经济规模达到22万亿元人民币,预计未来10年会增长到100万亿元,还有大约80万亿元的增长空间。

在8亿网民的推动下,中国的数据营销亦发展迅速。RTBChina发布的报告显示,仅程序化广告技术企业,国内就已经超过200家。

除了备受资本青睐,MarTech也受到互联网巨头的重视。2017年,腾讯在上海举办2017腾讯智慧峰会上就邀请了MarTech概念创始人Scott Brinker发表主题为“MarTech推动智慧营销”的演讲。

随着数据维度的不断丰富,应用场景的不断增多,尤其是移动化所带来的位置数据、物联网数据的日趋丰富,数据营销也在快速演进,中国的智能营销时代正在到来。

高铎认为,MarTech在中国发展更有潜力,因为中国的营销场景是最丰富的,尽管在技术上可能会和国际先进水平有差距,但在应用上中国应该会做得更好。

比如TalkingData与腾讯云联合发布的针对线下商业场景的智能商业选址产品——智选。这是一款将海量数据与机器学习有机整合,旨在解决实体门店的选址、商圈经营等场景问题,为智慧零售及多元化线下产业助力的数据智能产品,帮助企业选择出最合适的地址,而原来开店选址需要大量人力跑到现场,测算车流,了解房屋价格,以及周边消费水平等。

TalkingData 智选

本文转自:《瞭望东方周刊》

作者:徐颖

注:本文略有删改

咨询专栏丨三张PPT讲清如何搭建App数据管理体系

在券商互联网+的浪潮之下,越来越多的证券公司主动拥抱了互联网。互联网的发展给传统券商业务带来了机遇,同时也带来了一些挑战,促使业务部门不得不改变自己原有的工作方式。

传统的证券业务部门在互联网+的进程中,要获得更高的数据赋能,除了转变思路,学习互联网的渠道和运营营销方式,也需要主动习得互联网公司的数据能力。同时,也存在一些仍然不知道应该看什么指标、不同团队如何在关注不同指标的同时协调工作,也不知道如何去拆解指标如何把跟踪数据这件事融入到日常的工作中去的现象。

针对这个问题,本文给出三个自己的思考:

• 应该关心什么数据指标

• 如何开展数据工作

• 提升这些指标的一些要点

No.1 我们应该关心什么指标——搭建三级立体指标体系

一个业务会涉及诸多部门,各部门也有不同的层级。大家关心的点不同,但又需要统一方向,统一目标,向着同一个方向前进。同时,不同岗位的工作的落脚点也是不一样的,不同的工作内容需要有明确可以评估和据此改进的指标。这就需要我们日常跟踪的数据指标是有统有分、有层次,能落到不同的岗位职务上。

利用这个叫做“指标金字塔”的指标分层概念可以帮助解决这个问题。“指标金字塔”将我们平时需要关心的指标分为三个等级,每个等级在工作中有不同的意义和指导作用。

1、基础核心指标:

KPI、OKR 相关(一级指标)

位于最顶端的指标是核心指标,通常与整体业务线的年度目标一致。它可能是营收、月活人数、日活人数、交易活跃人数、AUM、新开户人数等等。通常这个指标是高层业务决策人经过一系列深思熟虑后制定的,服务于公司整体发展需要,也最能体现用户的核心需求,反映整个业务的走向。一段时期内只有一个工作重心,而这个工作重心评估的标准就是我们的核心指标,指标最好不要超过三个。

一级指标的提升是整个部门乃至公司配合的结果,涉及到产品、运营、开发和设计所有相关团队。这是所有相关人员都应该知悉及不断跟进的数据,是各个部门的负责人一起沟通、讨论的话题中心。同时,广大的各层级员工也需要认可这个目标。

基础核心指标跟踪的周期通常以季度为计,季度结束后做全面的总结和预估。

2、重点业务指标:

重要功能、业务目标相关(二级指标)

第二级指标通常涉及的人更少,但可能也是跨团队的指标。为支撑核心目标完成,通常我们会规划在一段时间内做几个重点业务,如理财商城或融资融券业务的使用人数、次数、交易额等。产品功能/业务涉及的产品、开发人员以及上线推广的运营人员负责这个业务指标的不同环节,需要跨团队的配合,从前期基础业务流程的梳理和准备,到产品流程的设计和开发,最后由运营推广人员进行上线相应的推广、客户服务,此后产品团队还需要对产品上线后的数据和用户反馈进行迭代,持续优化。

重点业务指标可以由多个部门共同承担,或者进行相应拆分,也可根据不同的业务内容由单一部门负责。

此等级指标的跟踪周期通常是月,各部门可根据每月完成进度调整下月的工作节奏。

3、常规操作指标:

产品、运营单次效果指标(三级指标)

第三级指标通常与我们日常工作内容相关,跟踪常规的迭代和运营效果,服务核心业务,也可能只是为了维护日常的产品功能和用户服务。这类指标是我们最常见的数据,如单个版本上线后的 DAU,或某次运营推广活动的 PV、UV、转化率等。

常规操作指标与一个项目的管理人员和执行人员的相关,用于优化具体的执行细节或者执行方案,通常每天由不同的人来跟进。

对产品经理来说,任何一个小的版本的产品优化都可以在上线后一周至两周内监测其产品使用人数、产品留存人数、点击率,用以验证这个小的产品优化是否真的有效。这是一个操作指标的跟进。

下面举个例子,指标金字塔如何进行拆解:

指标的拆解更多的需要我们先理解业务的逻辑,跟着理想用户行为路线将大指标拆解为小指标。以上图为例,如一个 App 目前的核心指标是客户人数,在这个路线上,从用户下载到成为活跃用户,再到转化成我们真正的客户,其经历的两个重要环节,就可以大致分为产品转化和运营转化。产品转化,通过刺激用户首次使用产品,持续使用产品,将用户变成一个活跃用户。在运营转化环节,运营通过产品运营、用户运营、活动运营等多种运营手段,将一个活跃用户转化成客户。在一系列活动运营的设置中,单次的活动转化客户人数就是一个可操作指标。

层层分解和落地,就能让最核心的高高在上的指标和我们日常的工作联系起来。

No.2 如何开展数据工作——建立数据流程

建立数据的工作流程的目的不是要一定按照固定的规范行事,流程只是个形式,流程的目的是为了让一线工作人员们有意识、有安排、有节奏的去开展工作,也更能方便团队内部和外部的配合。

数据工作流程大致为:提出业务需求——拆解数据需求——数据预处理——数据跟踪反馈——分析总结这五个环节。每个环节的时间节点和负责人都要一一明确。

以典型的互联网公司为例,通常一个版本的迭代涉及到需求确认、排期、设计、前后端开发、埋点、测试等工作。

版本需求大约提前一个月确定,包括产品和运营的需求。需求确定之后,进入到开发期,产品经理需要将其中的数据需求进行拆解,统一规划并部署,在上线前将需要检测的数据和提取方式、相应的埋点规则与开发人员沟通好,并测试埋点是否按照要求完成。上线后能看到指定的数据,如果数据出现异常,负责埋点的数据工作人员需要及时与开发人员进行沟通修正。

埋点工作通常是由产品经理在综合考虑业务需求后,纳入产品需求和规划开发的一部分一起做的。但如果是运营活动的 H5 页面、帖子页面,此时拆解数据需求和做数据预处理的就可能是运营人员自己。在一些分工更细的公司,从承接数据需求,到数据处理和数据展示可能都由专门的数据团队负责。虽然流程各环节实施的人和时间节点都可以依据具体的业务而定,但一定要明确达成共识的流程可以落地。

同样用一个新产品上线的案例来说明:

  • App 计划上线一个新的功能,叫 AI 智能选股。产品经理将此产品的各项需求收集在一起,进行规划和流程设计,出具产品文档,详细到具体的实现方式,并说明埋点和数据监测方式。
  • 全团队进行需求评估,AI 智能选股是否满足业务和用户的需求,优先级是否高,是否安排开发资源等。
  • 通过需求评估后,将此功能纳入产品开发排期,确定上线版本,同时评估是否有足够开发资源和运营资源。
  • 进入开发期,设计——开发(包括数据埋点及监测开发)——测试(包括数据埋点及监测测试)。
  • AI 选股产品上线后,在首页设置 icon 入口,检测其点击数据,如两周内的点击率是多少、比之前同位置 icon 点击更高还是更低、相较于这个首页流量的点击占比提高还是降低,看是否有异常。监测其他入口和各路径、流程的转化率。
  • 总结、分析,包括 AI 选股产品的整体使用人数、使用时长、留存情况等数量和趋势、以后的迭代方向、用户反馈等等。

No.3 如何提高业务指标——培养数据思维和数据习惯

1、从上到下培养数据习惯

从每天的站会、每周的周会,到每一次部门会议、业务会议,把数据表现的回顾挂在嘴边是培养大家关注数据结果的习惯的开始。这个习惯一定要领导们身体力行。

数据是我们一切工作结果的衡量标准,也是我们优化工作的参考,更是我们决策的依据。指标无大小,大会议分析大指标,小会议分析小指标。当我们都习惯了以客观的数据为依据去评估工作的时候,整个公司才会有统一的判断标准和方向。

2、时时反馈,事事反馈

要有定期的数据汇报,可以是每周正式的周报,也可以是非正式的通告。数据反馈能让从开发人员到运营人员都清楚自己工作的成果是什么。不断增长和向好的数据,会让大家认可自己日常琐碎和重复的工作。

如果数据表现不好,也会促使大家去思考原因何在以及如何改进。这会极大地增加全体员工的意义感和参与感,哪怕只是上线一个小功能的点击走势,也能让大家对自己工作的结果心中有数。数据结果是一种纽带,把大家串联在一起,这是可以随时随地、非正式的地进行分享的。

3、明确工作职责,落实到指标上

虽然提升业务指标的要点其实已经完全融入到了平时对核心指标的关注、数据工作流程和团队间工作协调上,但还是需要明确不同的团队和个人的工作职责,并且落实到相关指标上。

单个指标有诸多可控和不可控的因素,但可以用更多元化的考核机制来灵活的处理这个问题。例如新转化用户这个指标,可以拆分成转化率和流量两个细分指标,流量*转化率=新转化用户。产品和运营可以共同对新转化用户这个指标负责,但在不同的环节上有各自的侧重。

4、建设一个强大的数据中台

最后一点是,一个强大的数据中台能够让数据工作更有条理、更直接、更快捷。对有开发能力的公司来说,定制化一个能实时看到数据反馈、可视化指标结果以及为运营和产品同事提供一些便捷的数据工具的强大数据中台,是一个非常值得投入的事情。甚至可以将营销平台、埋点管理、用户管理系统作为这个数据平台的联动系统,实时的对营销活动、产品热力度、推送效果等运营产品数据效果给出效果展示和数据分析。这也能极大地为运营和产品团队赋予数据能力。

作为国内领先的数据智能服务商,TalkingData为各行业企业提供全面的数据应用和数据解决方案。全新升级的TalkingData 移动运营平台5.0即涵盖数据指标体系、智能路径分析等多种分析报表平台,还提供可视化营销策略分析、客群分组测试等多种智能营销支持。

结语

搭建数据指标体系、建立数据流程、培养数据思维和数据习惯,是业务部门构建数据管理体系的“基础三件套”。数据是管理工具,也是业务工具。数据的基础工作更值得好好投入,让我们的管理和业务都在数据助力之下走入快车道。

必须收藏丨万字长文,带你了解跨平台移动应用开发工具

TalkingData 张永超 译

原文链接:
https://instabug.com/blog/cross-platform-development/?utm_source=reddit&utm_medium=social&utm_content=cross_platform_development

在如今的电子世界当中,运行着各类操作系统,如何让应用适配每个操作系统平台,是开发者们一直在思考的问题。因为平台、技术、工具的有多样性,让适配变得无比的困难与繁杂,甚至需要花费大量的时间和资金去进行研究。本文将介绍目前比较流行的可以开发跨平台应用的开发工具,希望能够帮助开发者们实现全平台覆盖。

本文较长,其中大量资源网址值得收藏!

移动应用开发概述

Web应用

Web应用是运行在网页上并存储在远端服务器上的应用,此类应用通过设备上的网页浏览器加载与展示。

即便在某些情况下网页应用运行良好,但仍无法避免会出现一些问题,比如需要连接到网络才能在设备上运行,因为所需的资源并未存储在本地设备上,而是在远端服务器上。另外,此类应用无法在移动商店上直接使用,导致用户很难找到和下载使用。

Hybrid跨平台应用

Hybrid应用又称为混合应用,此类应用基本上使用每个平台的浏览器内置组件进行包装和打包,以达到在每个平台上运行的目的,应用就像该平台上的Native应用一样。混合应用主要使用的语言为HTML5、JavaScript和CSS。

混合跨平台应用解决了Web应用面临的问题,因为混合应用在本地运行时无需网络连接,而且还能在应用商店上发布,可以让用户轻松找到,从而增强应用的可发现性、增加用户量等。

混合跨平台应用开发工具:Apache Cordova、Ionic、Adobe PhoneGap等。

Native应用

原生应用是为了在特定平台或操作系统上工作而开发的应用。

对于iOS来说,开发者使用的是Swift或Objective-C编写iOS应用,而对于Android来说,开发者使用的是Java或Kotlin编写Android应用。从移动开发工具来看,iOS开发者经常使用Apple的Xcode或者第三方的AppCode等工具,而Android开发者经常使用Android Studio作为它们的主力开发IDE。

Native 跨平台应用

原生跨平台工具允许开发者编写一次代码,然后将该代码转换为适配多个操作系统的本地代码,让开发者以最小的成本在不同的平台上发布移动应用。原生跨平台应用是混合应用和本地应用的完美结合,不仅提供了混合应用的代码重用功能,而且性能也与本地应用类似。

原生跨平台应用开发工具:React Native、Xamarin、Titanium等。

跨平台移动应用开发

跨平台移动应用开发是创建可以使用单个代码库,在多个平台上部署或发布的移动应用开发过程,跨平台移动应用开发无需使用每个平台的对应的本地技术去进行多次开发。

跨平台开发有以下优点:

  • 可重用代码:跨平台开发工具允许只编写一次代码,然后将代码导出到需要操作的系统和平台上,无需为每个平台单独编写创建代码;
  • 便利性:跨平台开发工具能够省去学习许多编程语言的麻烦,开发者只需要理解领会一种语言即可;
  • 可维护代码:当需要修改或更新应用时,开发者只需更新一个代码库,就可以将更新同步反映在平台所有的应用上;
  • 成本效率:跨平台开发可以让单个开发团队能够在多个平台上进行工作,且大多数的跨平台开发工具都是免费的。
  • 市场覆盖率:通过多平台发布应用,可以让其增加曝光量,提升用户基数,从而提高投资回报率和经济利益。

虽然跨平台开发工具拥有很多优势,但在某些场景下的缺点也相当明显:

  • 性能:即便一些跨平台开发工具提供了接近本地应用的性能,但仍有不足,如果所开发的应用属于最高优先级,不建议使用跨平台开发工具。
  • 3D和图形:与性能上的缺点类似,跨平台开发工具无法提供最佳图形和最佳的用户体验,且无法访问核心OS库(如图形),如果所开发的应用严重依赖于图形,比如移动游戏类应用就不建议使用跨平台开发工具。
  • 单平台应用:如果所开发的应用尽在单一平台(如iOS或Android)上发布,那么还是应该使用本地开发的应用,在这种场景下,只需要一个团队使用一种技术即可,没有必要去损失性能。
  • 特定与平台的功能:虽然跨平台开发工具提供了不同平台之间共享的许多基本功能,但它们可能缺少Apple、Google和Microsoft的操作系统上提供的某些特定功能。
  • 特定与设备的功能:跨平台开发工具可以让开发者访问的不同功能,如相机或GPS,但如果所开发的应用需要直接访问和处理设备的硬件,本地开发应用是更好的选择。
  • 更新延迟:在一些特定平台发布更新时,可能需要等一段时间才能在所有平台开发工具中反应这些更新。

跨平台开发技术栈

虽然跨平台开发工具可以帮助开发者节省学习不同技术的时间和工作量,但仍然需要熟练掌握每种工具,使用的技术有:

  • React Native:JavaScript(JSX)、ES6、React.JS
  • Xamarin: C#
  • Cordova: HTML、CSS 、JavaScript

常用跨平台开发工具

  • Ionic
    地址:https://ionicframework.com/
  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Titanium
    地址:
    https://www.appcelerator.com/Titanium/
  • Framework7
    地址:http://framework7.io/
  • Apache Weex
    地址:https://weex.apache.org/
  • Flutter
    地址:https://flutter.io/
  • Native Script
    地址:https://www.nativescript.org/
  • Jasonette
    地址:http://jasonette.com/
  • ManifoldJS
    地址:https://github.com/pwa-builder/ManifoldJS

三大主流跨平台开发工具

React Native

React Native是由Facebook基于其React JavaScript库创建的跨平台本地移动应用开发框架。主要使用JavaScript与JSX(JavaScript的扩展),ES6(ECMAScript 6),JavaScript的主要更新(包括许多新功能)和React.JS(用于构建用户界面的JavaScript库)。

React Native允许开发者使用React Native组件构建移动应用,然后再将其编译为本地应用,这些应用几乎与使用本地工具编写的应用完全相同。

React Native的优点

使用React Native进行跨平台移动应用开发的优点包括:

  • 可重用代码:可开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店: 可以在各个平台的应用商店中发布应用。
  • 性能:React Native可将应用编译为本地应用,这与使用本地工具创建的应用几乎完全相同,使其比必须在特定于平台的Web组件中运行代码的混合应用更快。
  • 本地UI组件:React Native允许开发者使用React Native UI组件创建视图,这些组件被编译为特定于平台的UI组件,与使用HTML标记的其他跨平台工具不同。通过现成的组件,可以节省大量的时间。
  • 热重新加载:React Native中提供一项允许更改代码在iOS和Android应用中立即生效的功能,可以进行可视化更改。
  • 测试:调试React Native应用非常容易,因为它发布了本地应用版本,可以使用Expo这样的工具在物理设备上进行测试,无需在Xcode或Android Studio中打开它们。
  • 本地代码:与大多数其他跨平台开发工具不同,React Native允许开发者单独修改已发布的本地应用,它可以选择在React Native代码和本地代码之间进行组合,无论是Swift,Objective-C,或者是Java。如果想使用特定于平台的代码为不同平台实现单独的可视组件,就非常有用。
  • 可靠性:React Native由Facebook创建,许多世界顶级移动应用都在使用React Native,比如Facebook,Instagram,SoundCloud和Skype。
  • 免费:开源。

React Native的缺点

虽然React Native是目前最好的跨平台开发工具之一,但React Native仍然具有一些缺点:

  • 新技术:学习JSX和ECMAScript并不是一件容易的事,可能比其他熟悉的技术(如HTML和CSS)要花费更多时间。
  • 原生UI组件:虽然UI组件是React Native的最大优势之一,但目前只有少数几种现成的可用。
  • 本地代码:在某些情况下,开发者可能需要在移动应用中编写本地或平台特定的代码,特别是如需访问设备硬件(如相机或GPS),会破坏跨平台开发的目的,对小型团队来说React Native的作用不大。
  • 性能:虽然与大多数其他跨平台开发框架相比,React Native在性能方面表现优异,但比起使用特定于平台的工具和语言的本地应用进行开发来说仍有不足。

React Native 开发工具

  • Atom
    地址:https://atom.io/
  • Nuclide
    地址:https://nuclide.io/
  • Visual Studio Code
    地址:https://code.visualstudio.com/
  • React Native Tools
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native

React Native 开发组件

  • Redux
    地址:https://redux.js.org/
  • Expo
    地址:https://expo.io/
  • Ignite
    地址:https://infinite.red/ignite
  • Flow
    地址:https://flow.org/
  • ESLint
    地址:https://eslint.org/
  • ReduxSauce
    地址:
    https://github.com/infinitered/reduxsauce

React Native UI组件

  • Snowflake
    地址:
    https://github.com/bartonhammond/snowflake
  • NativeBase
    地址:https://nativebase.io/

React Native 测试工具

  • Enzyme
    地址:
    https://github.com/airbnb/enzyme
  • Reactotron
    地址:https://infinite.red/reactotron
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Xamarin

Xamarin是一个跨平台的移动应用开发框架,由微软基于Mono(一个免费的开源.NET框架),使用C#创建本地应用。

Xamarin 优点

Xamarin跨平台移动应用开发具有多个优势,包括:

  • 可重用代码:开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 完整的开发堆栈:许多开发者认为Xamarin是最完整的跨平台移动应用开发框架。拥有自己的专用堆栈,C#作为编程语言;Visual Studio作为IDE,与Xamarin完全集成;.NET作为开发平台;Xamarin测试云进行测试;以及Xamarin.Insights用于分析。
  • 性能:Xamarin在性能方面也几乎与本地应用相同。 Xamarin比混合应用更快,因为混合应用必须在特定于平台的Web组件中运行代码。
  • 本地UI组件:使用Xamarin Native UI组件创建视图,这些组件通过Xamarin.Forms编译为特定于平台的UI组件,Xamarin.Forms包含面向.NET开发者的完整跨平台UI工具包,或可以通过Native UI开发。
  • 插件和API:Xamarin提供了一组允许访问硬件功能的插件和API。它还支持通过链接本地库进行自定义。 测试:通过在物理设备上安装Xamarin.Forms Live Player应用,开发者可以使用实时预览立即测试和调试应用,并可以实时同步应用与设备。
  • 可靠性:Xamarin于2016年被微软收购,截至目前,已在120多个国家/地区拥有超过140万名开发者。所以它绝对可靠且拥有良好的维护。
  • Xamarin大学:Xamarin提供由Xamarin专家指导的实时、互动的移动开发培训,涵盖10个方面的80多个课程,让开发者可以轻松地学习。
  • 免费:开源。

Xamarin 缺点

虽然Xamarin可以应用许多场景,但它也是有一些缺点的:

  • 应用大小:通常已知Xamarin应用大小比本地应用更大,因此在内存管理方面不是很理想。
  • 更新延迟:Xamarin的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 本地代码:当使用Xamarin.iOS或Xamarin.Android开发具有原生外观的移动应用时,将需要一些本地语言的基本知识,如Objective-C、Swift和Java。
  • 图形:虽然Xamarin使用单个代码库为多个平台构建应用,但它主要在平台之间共享代码逻辑,而UI组件又是特定于平台的。这使得Xamarin并不适合严重依赖图形的应用,比如手机游戏。

Xamarin开发工具

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/vs/mac/
  • XCode
    地址:
    https://developer.apple.com/xcode/

Xamarin 开发组件

  • NuGet
    地址:https://www.nuget.org/
  • Xamarin Inspector
    地址:
    https://docs.microsoft.com/zh-cn/xamarin/tools/inspector/install?tabs=windows
  • Prism
    地址:
    https://github.com/PrismLibrary/Prism
  • MFractor
    地址:https://www.mfractor.com/
  • Resharper
    地址:
    https://www.jetbrains.com/resharper/

Xamarin 测试工具

  • NUnit
    地址:http://nunit.org/
  • xUnit.net
    地址:https://xunit.github.io/
  • Visual Studio Unit Testing Framework
    地址:
    https://docs.microsoft.com/zh-cn/visualstudio/test/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Apache Cordova

Apache Cordova是一个跨平台的移动应用开发框架,用于使用包括HTML,CSS和JavaScript在内的Web技术,构建混合移动应用。

Apache Cordova 优点

使用Apache Cordova进行跨平台移动应用开发的一些优势包括:

  • 可重用代码:可以开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 多平台支持:Apache Cordova支持大多数开发者所使用的移动平台和操作系统,包括Android,iOS,Windows 8.1,iPhone 8.1和10,OS X,几乎可以覆盖所有移动用户。
  • 大量插件:Cordova提供各种插件。
  • 所用技术:Cordova不是一种编程语言,因此开发者可以使用已知的Web技术(如HTML,CSS和JavaScript)进行应用开发。还可以使用自身熟悉的工具,包括所使用的编辑器。
  • 免费:开源。

Apache Cordova 缺点

和任何跨平台移动应用开发工具一样,Cordova也缺点,包括:

  • 性能:使用Apache Cordova创建的移动应用,会因性能问题而受到影响,因为它是一种混合的跨平台移动应用开发工具。
  • 开发工具:由于Apache Cordova使用HTML,CSS和JavaScript等Web技术,因此用于Apache Cordova的大多数开发工具都针对Web开发进行了优化,而非移动应用开发。
  • 测试:在Apache Cordova中调试代码会比较繁琐,虽然可以使用开发工具修复任何代码上的bug,但需要使用特定于平台的工具来修复特定平台中发生的问题。
  • 技术:即便开发者可能熟练掌握了HTML,CSS和JavaScript等网络技术,但仍需要具备Web和移动应用的经验才能创建Cordova移动应用。
  • 支持的平台:Cordova多年来已经弃用了许多支持的平台,包括BlackBerry,Firefox OS,Symbian,Ubuntu Touch,webOS,Windows Phone 8.1和Windows Phone 10.虽然Cordova可能很难弃用iOS和Android,但仍然无法保证它继续支持任何其他当前所有平台。
  • 更新延迟:Cordova的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 插件:虽然Cordova提供了比其他任何跨平台开发工具中都多的插件,但它仍然无法与本机移动应用开发工具相比。

Apache Cordova 框架

  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Monaca
    地址:https://monaca.io/
  • Onsen UI
    地址:https://onsen.io/
  • Cocoon
    地址:https://cocoon.io/
  • Framework7
    地址:http://framework7.io/
  • Evothings Studio
    地址:https://evothings.com/
  • Mobiscroll
    地址:https://mobiscroll.com/

Apache Cordova IDES

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/zh-hans/vs/features/cordova/
  • Cordova Tools Visual Studio Extensions
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.cordova-tools
  • App Builder
    地址:
    https://www.davidesperalta.com/appbuilder
  • NSB/AppStudio
    地址:https://www.nsbasic.com/

Apache Cordova CLIS

  • Cordova CLI
    地址:
    https://github.com/apache/cordova-cli
  • Node.js
    地址:https://nodejs.org/en/
  • NPM
    地址:
    https://www.npmjs.com/package/cordova
  • Cordova Plugman
    地址:
    https://github.com/apache/cordova-plugman
  • Cordova Coho
    地址:
    https://github.com/apache/cordova-coho

Apache Cordova 类库

  • Apache Cordova JS
    地址:
    https://github.com/apache/cordova-js
  • Apache Cordova Lib
    地址:
    https://github.com/apache/cordova-lib
  • Apache Cordova Common
    地址:
    https://github.com/apache/cordova-common
  • Apache Cordova Create
    地址:
    https://github.com/apache/cordova-create
  • Apache Cordova Fetch
    地址:
    https://github.com/apache/cordova-fetch
  • Apache Cordova Serve
    地址:
    https://github.com/apache/cordova-serve

Apache Cordova 测试工具

  • Apache Cordova Plugin Test Framework
    地址:
    https://github.com/apache/cordova-plugin-test-framework
  • Apache Cordova Paramedic
    地址:
    https://github.com/apache/cordova-paramedic
  • Apache Cordova Mobile Spec Suite
    地址:
    https://github.com/apache/cordova-mobile-spec
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

总结

跨平台开发工具在开发周期中可以为开发者节省大量的时间,并可以使用最少的资源在不同的平台上发布应用,最大程度的去覆盖用户。但即便如此,它也无法替代本地开发应用的替代品,鱼和熊掌不可得兼,需要根据自身实际情况与场景去衡量利弊。

如何确定最适合的跨平台开发工具呢?最好的方法就是每个工具都去尝试一遍,如果时间有限,那么对一些顶级跨平台开发工具进行研究就足够了,比如本文例举的这些,希望对您有用。

重磅丨《2018年数据生态报告》发布,5大方面助力领跑数据智能时代

近日, TalkingData联合中关村大数据产业联盟、中国国际大数据大会组委会在“2018年第五届中国国际大数据大会”主会场高峰论坛上共同发布《2018年数据智能生态报告》,TalkingData CEO助理、腾云大学校长、中关村大数据产业联盟数字生态行研中心首席研究专家杨慧博士对报告进行了详细解读,针对数据智能的发展趋势给出相应的应对策略,帮助企业更好驾驭数据智能,领跑数据智能时代。

《2018年数据智能生态报告》结合TalkingData在助力行业发展变革中积累的经验,梳理了当下中国数据智能市场的发展历程和未来走向,给出了数据智能、数据智能平台的定义和时代的特性。本报告洞察了数据智能时代的本质,分析了数据智能市场行业全景及痛点,并为不同类型的企业提供应对策略,倡议积极推动行业合作,共建数据智能平台。

现今无论是互联网企业还是传统行业的企业,都非常重视对于数据的收集、处理、算法的精炼以及最终对数据价值的应用。但是如何在这样一个以数据智能时代中,采取有效的措施和行动真正实现数据价值的提炼,利用数据智能去改变企业决策、改善人类生活?这是我们需要共同来探讨的。

一、数据智能的定义与本质

著名图灵奖得主Jim Gray提出的四大范式,可以很好地帮助我们梳理科学的演进。其中前三大范式,在人类文明发展的历史长河中帮助我们更好的记录、归纳和模拟现实世界;而进入数据智能时代,在机器学习、分布式计算等技术发展的基础上,数据逐渐呈现出高维度、高阶态、异构性的形势,能够对海量数据进行分析、处理和挖掘,并且通过建模、工程等方式来解决实际的预测和决策问题,最终实现决策的行动,则为“数据智能”。

数据智能也和数据科学、数据工程、数据分析等概念息息相关,但数据智能作为一个独立的概念,和其它几个名词最大的区别在于:

  • 数据智能的目的是“预测”和“决策”,而非“分析”或者“展示”。

  • 由于数据智能指向决策,所以用来判断数据智能的效率和价值就在于其决策的结果产生的可衡量的商业价值。
  • 数据智能产出的过程中需要一个强有力的能够承载和调动一系列智能数据、核心模型以及面向不同情境的数据处理能力的数据智能平台。
  • 最终呈现出有封装的、有交互界面的可以一定程度上替代人工决策的数据智能产品。

从商业和经济的本质上来说,数据智能平台指数级地加速了数据和人的智慧,其价值体现在两个方面:第一方面体现在聚合效应,即从数据源到数据加工、数据分析、数据应用最终形成数据产品过程中,实际上遵循价值“微笑曲线”;数据智能通过聚合各个环节的剩余价值,从而提升整条价值链的价值。

第二方面体现在加速效应。在数据的获取和应用的这些环节,数据的价值链已经从单一的线性结构逐渐演变成为模块与模块之间互相交叉融合的复杂架构。数据的每一个环节都都能够得到数据智能平台的加速,产生更多价值。综上,通过打通数据价值链,可以集中剩余价值、降低数据成本、提高资源配置,从而获得数据智能所带来的价值红利。

二、数据智能平台的使命与能力

数据智能平台/数据中台的使命有两件事:帮助企业更好的“看现在”——对现有数据的治理;帮助企业更好的“看未来”——对数据价值的挖掘对未来的预测;“看现在”的目的最终是为了更好的“看未来”,这是因为在数据智能时代,数据的量级和异构的程度都极其复杂,千里之行始于足下,因此这是企业实现数据智能的第一步,也是决定数据智能价值实现最为关键的基础。具体进一步来说,这两个能力拆开后又包括了以下这些能力要素:为了更好“看现在”连接、共享、安全;以及为了更好“看未来”的管理、科学与工程。

1、连接,提高数据维度及饱和度。连接不强调对数据的拥有,而强调能够触及和返回的数据的广度、丰富程度。将不同来源的数据汇聚和连接起来形成更丰富的数据维度,是数据智能平台的使命。

2、共享,通过OPAL实现数据价值流转。共享能力是评估一个数据智能平台是否合格的首要标准。共享不代表要完全的透明,而是通过像OPAL(Open Algorithms,开放算法库)这样的技术框架去构建一个合理的、区分权限的、能够保护数据同时让知识的价值流转的机制。

3、安全,推动数据安全合规标准的建立。安全合规是重中之重。一个数据智能平台是中立的、合法合规的,它中间涉及到的各项任务都应该是安全且合规的,具有安全管理、用户管理、平台接入与使用的审计、调优和保障高可用性和容灾的能力。

4、管理,实现企业的数据资产化、资源化。管理是数据智能平台实现价值的起步,让数据的排列有序、结构趋同,可以被进一步的分域、保存、备份、重新组合,形成更多的协同价值。

5、科学,提升决策的科学性与准确性。数据科学是探索数据价值的流程,也是数据价值被挖掘的核心过程。数据的价值不是一次成型的,数据价值的挖掘依赖与不断假设、分析、验证、校准的反复迭代过程,最终才能凝聚沉淀成模型和解决的方案。

6、工程,实现数据价值的快速转化。数据能够直接变成决策,中间需要工程来构建环境,实现汇聚、仿真和自动化。工程这个因素将数据和算法、工具和能力有机的结合起来,最终形成一个封装的、内部自成体系的数据智能产品。

有了以上六个能力因素,数据智能平台才得以成为一个独特的平台,也成为企业想要快速构成数据智能产品、实现客户价值的必需平台。

三、数据智能市场的发展与痛点

随着互联网技术、人工智能等科技的飞速进步,数据量级的增长、计算能力的提升、存储的便捷化等推动数据智能市场蓬勃发展。数据市场从以传统IT企业为代表的软件时代,到以互联网企业为代表的数据时代,再到以数据智能企业的生态时代,数据的支撑和驱动因素越发成熟。随着终端的智能化、数据异构化、商业问题复杂性的提高,数据智能市场也向着万亿级别的市场规模进发。

对企业客户来说,企业数字化转型的不同阶段面临着不同痛点问题,但是总结来说会有如下几类:

第一、业务管理者或高管不知道怎么构建数据业务 / 数据能力;

第二、缺人,缺人,还是缺人;不知道从哪里获取这类人才,或者人才掌握的是上一阶段发展所需的知识;

第三、客户没有透彻地理解数据能力和企业业务能力之间的关系:无法与客户商业决策所对应的商业指标绑定;

第四、相应数据虽形成闭环但是数据闭环本身太小或者太过封闭,能够解决的问题过少、过小。

客户侧出现的问题,体现了整个数据行业目前面对的深层次问题。那么为什么要有数据智能平台呢?有数据智能平台的在位企业才能帮助客户解决上述问题。对于数据行业的从业者来说,数据获取已经不是问题,但是单一数据源的维度价值有限、数据需要共享才有价值;其次,数字业务推陈出新速度非常快,各数据源及应用厂商各自造轮子,很难形成规模优势,缺少行业的分工和合作;法律法规包括网络安全法、个人信息保护规范等还在不断完善,数据安全成为桎梏所有数据价值共享的主要鸿沟;数据与商业场景割裂,缺乏行业洞察,很难进行有效转化;最后,专业数据人才缺乏,大多数都集中在数据行业的从业企业中,留给传统企业进行数字化转型和提升的人才十分有限。目前高校等培养机构供给还处在缓慢加速的过程中,行业人才空缺加大。因而需要这样一个数据智能平台来通过能力的共创、复用、沉淀等,促进企业前端业务或者数据智能产品的效率、协同和创新。

为了解决以上的痛点问题,无论是对于客户企业还是对于数据行业的在位企业来说,都需要出现一家企业、一个团队来主导数据智能平台/数据中台的建设,这个新的数据智能平台/数据中台的存在,才能打破传统价值分工、重构数据行业的生态全景,全面提高行业的价值产生的能力。

四、数据智能行业全景与玩家分类

数据行业诞生以来,大多数企业在不同的商业模式上进行试水。如果把整个行业分为标准化/产品化、客制化/服务化的纵向坐标以及数据和软件工具的横向坐标,究竟是将数据作为护城河,还是产出成型高效的软件应用工具,如何在数据加工程度和软件工具、客制化和标准化中找到一个平衡,也是当下数据企业思考与探索的问题。我们可以以此为维度,分为以下六种商业模式:数据源、数据交易、市场智能、SaaS、数据产品和解决方案。处于不同商业模式的企业在整个数据智能行业中的身份与角色也不尽相同,他们有着不同的速赢关键因素和策略(见报告详解);但是在智能数据时代,这些不同类型的企业都在不约而同的自主发展数据智能平台,或者与行业中的数据智能平台形成深度的合作。

更多的合作呼唤更灵活的合作方式。不同于普通的平台类企业,数据智能平台需要同时包含数据、工具、算法和服务多个要素,不同要素的组合需要用不同的商业模式进行变现,甚至会改变价值分布、突破传统的、单向的客户关系甚至是竞争关系。因此数据智能平台需要更加开放和灵活的商业模式支持不同行业、不同业务和不同定位的合作伙伴进行合作,形成协同作用。突破传统的技术合作伙伴或者是联合建模合作伙伴、数据智能产品合作伙伴的合作方式,真正跨越简单的客户的概念的新型客户类型,与数据智能平台/数据中台类企业构建按照效果分成的成效合作伙伴关系。

五、数据智能的发展趋势与应对策略

数据智能还有很多需要研究和解决的问题。但是在变道初期如果不能快速跟上,必将会错失在一次新的产业革命(甚至是一个新的文明时代)中的赶超良机。因此,必须要认清形势,把握趋势,积极谋划,推动发展。具体来说,未来中国数据智能行业的发展会呈“两化”趋势——生态化和开源化。

只有集中了生态化和开源化的力量,数据智能才会开放互联的打通与连接各个维度的数据,进而打造成中国最大的智能数据中台。如此才能更好的去解决面向不同商业决策的痛点问题,支持多渠道多场景的数据分析与运营,产出包括智慧金融、智能营销、商业洞察等等行业成熟的解决方案与应用组合,将数据智能潮流推向新的高潮。