TalkingData 区域性金融智能营销研讨会在珠海举办

区域性金融企业正在面临着收入增长缓慢、运营成本压力增加的挑战。TalkingData 认为,区域性金融企业可以通过数字化运营和智能化营销建设,降低金融企业的运营成本,提升营销效率,增加业务收入,为客户提供便捷的金融服务。

近日,TalkingData 在珠海举办区域性金融智能营销研讨会,本次研讨会仅面向区域性金融行业客户。共计40多家区域性金融企业的客户参加了本次研讨会,参会人员覆盖区域性金融企业副总裁、网络金融部总经理、互联网金融总经理、电子银行总经理、数据分析和运营总经理、市场营销总经理等金融行业高级管理人员和运营人员。

会议上,金融行业的业务专家、研究学者以及 TalkingData 产品咨询团队,从数据的场景化应用、数据中台的建设思路、智能营销平台的商业价值、数字化运营成功案例等方面,深入探讨了经典案例和实战经验。

TalkingData合伙人兼执行副总裁林逸飞

长江证券、重庆银行的专家分别介绍了自身的数字化营销实践经验,以及他们如何在服务客户方面定位自己,如何走差异化发展之路,实现基于数据驱动的增长。中国银行协会行业发展研究委员会副主任、中国人民大学重阳金融研究院副院长董希淼,在演讲中介绍了中小银行零售业务的困境和对策。

他指出,在互联网流量巨头、金融科技公司、领先的股份制商业银行、大型国有银行的巨大资源投入面前,区域性金融机构需要了解如何利用金融科技代替大量人员投入和大量资本投入,实现高效率、低成本的业务发展。

TalkingData 合伙人兼执行副总裁林逸飞指出,在线上获客成本日益增加的情况下,企业需要盘活流量,提升流量变现能力,从数据中萃取商业价值。在未来两年,随着流量对企业和系统的要求越来越高,中台的优势将真正的发挥出来。具体来说,中台可以对接多种流量,帮助企业在营销闭环里将数据简单化,让各种工具在其上各司其职,真正的打通流量运营。此外,中台还可以帮助企业快速上线算法、模型,并通过客户的真实反应验证、训练模型,实现营销的自动化和快速化。

TalkingData 认为,中台不仅仅是一个平台、一个工具,而是一套正规而立体的想法。TalkingData 对数据中台的定义是基于数据智能应用探索商业价值的平台,它需要具有数据管理、数据工程和数据科学的能力。

此次会议为区域性金融机构提供了一个开放、分享的平台,区域性银行及证券企业的科技部门与网络金融部门的相关负责人出席了本次会议,并在下午的两个主题研讨会上进行了热烈的交流。

此次能够邀请到这么多区域性金融机构的企业代表参与研讨,TalkingData 作为主办方感到非常荣幸。TalkingData 将继续借助以数据智能平台 SmartDP(TalkingData 数据中台)为核心的数据智能应用生态为金融企业赋能,帮助企业逐步实现以数据为驱动力的数字化转型。

TalkingData刘翔:从数据资产到价值量化,新零售转型之路应该这么走

近日,TalkingData 咨询部总经理刘翔出席了在上海康师傅通路创新中心举办的“前瞻创新 携手同行”康师傅开放日活动,为康师傅高层及核心员工分享了 TalkingData 以全闭环数字链路和数据中台策略大脑助力零售行业数字化转型的思路、经验与案例。

康师傅 通路创新中心

十年前,我们还在谈大数据的 4V 概念;而十年后的今天,大数据早已超越技术范畴,它已经成为商业模式创新的重要驱动力,并已成为很多领先企业的业务战略重点之一。大数据的应用落地快速深化,逐步走入数据智能时代。越来越多的企业开始关注大数据能够如何驱动商业模式创新,能够带来哪些新的利润点,能够创造怎样可量化的价值。

TalkingData咨询部总经理 刘翔

数据赋能下的零售业未来将往怎样的方向发展?刘翔从客户时间、近场触点、生态场景三大方面进行了总结。

  • 以往行业更关注流量,无论是线上流量还是线下流量。而刘翔认为,流量背后的本质是客户,而争夺客户的本质其实是占据客户的时间,如何引导并创造出更多的高频场景是很多客户非常关注的领域。
  • 近场触点上,从覆盖3-5公里商圈的超市和购物中心,到覆盖300米-500米的便利业态,到一步之遥的无人购物货架,到电梯的大屏,甚至到家庭客厅的智能电视,覆盖渠道也将越来越多并进行打通连接,实现立体式的触达。
  • 生态场景方面将走向高度融合,与客户的交互不再区分单纯的线上与线下。用数据去描摹人群、用数据去描述货品、用数据去还原场景,进而通过面向不同场景的数据模型产品可以重构人、货、场三者之间的关系,最终实现人、货、场的数据化重构。

现在越来越多企业把数据作为一种资产来看待。刘翔认为,对数据资产的管理要像理财一样,有明确的策略,去考虑如何多元化配置、如何持续增值。大数据时代,很多企业遇到的问题不是数据太少,而是数据太多太杂,缺乏有效管理、运营并产生价值。

而 TalkingData 在全闭环数字链路和数据中台策略大脑的基础上,基于为零售企业服务的丰富经验,总结出从数据到数据资产管理、从数据资产到价值量化、通过数据资产运营实现业务价值、通过数据闭环验证实现价值量化的解决方案,帮助企业通过数据中台打通各项内外部数据,对数据进行处理和建模,形成数据应用来供业务部门使用,将数据转化为可量化的商业价值。

刘翔通过几个典型案例介绍了这一解决方案的具体实践。其中,在与某餐饮企业的合作中,TalkingData 基于数据中台,结合该企业自有的产品物料、优惠活动、实时订单、历史销售等数据以及节假日等数据,形成销售预测模型,实现提前0.5小时预测该企业数千家门店细化到每个 SKU 单品的销量,预测准确率提升超过15%,同时也显著提高了门店人员排班效率。

而在与某知名服饰集团的合作中,TalkingData 帮助该企业整体搭建了数据资产管理平台,基于数字化运营框架,形成营销数据闭环,在今年夏季的营销活动中,圈选出90余个不同的人群,并和数十种权益、多渠道实现最优组合,进行精准营销触达,实现了高达94倍的 ROI 效果。

“数据是驱动而不是参考,试验不是发展策略之一,试验就是策略本身。”刘翔以亚马逊 CEO 贝佐斯的这句话作为此次分享的结语。未来,数据不只是决策的参考,而将成为全面的驱动力,驱动企业整体数字化的转型。

崔晓波出席国际金融论坛全球年会,总结金融科技三大发展阶段

近日,国际金融论坛(IFF)第15届全球年会在广州开幕。年会以“新全球化:未来之路——走向共同发展的新型经济全球化”为主题,邀请来自全球的200多位嘉宾,围绕新全球化时代未来发展方向、世界和中国面临的挑战与机遇、数字经济与金融科技等话题进行了深入探讨。

TalkingData创始人兼首席执行官 崔晓波

在本届IFF年会的环球金融科技峰会中,TalkingData 创始人兼首席执行官崔晓波先生受邀参与圆桌论坛,与意大利前总理达莱马、中国人民银行金融市场司副处长唐磊、中国人民大学金融科技与区块链大数据研究所联席所长李志杰、微软(中国)首席技术官韦青、蚂蚁金服数字银行资深架构师娄恒、拍拍贷联席 CEO 章峰一起,分享了对于金融科技领域发展的洞察与观点。

崔晓波认为,科技浪潮影响下的中国金融行业发展经历了三个阶段:

  • 第一阶段是移动化阶段,由于中国移动互联网的高速发展,国内一些金融机构走的非常靠前,在几年内金融行业整体都达到了非常高的移动化水平;
  • 第二阶段是数据化阶段,因为涉及数据安全与隐私保护的问题,又面临着业务场景与科技发展脱节的情况,金融行业在这一阶段的发展速度比较慢;
  • 第三阶段也就是智能化阶段,已经有一些金融机构开始在客服、风控等方面进行智能化的尝试,但是由于数据基础做的不够扎实,在数据存储、计算以及应用方面有巨大的挑战。

圆桌论坛全体嘉宾

此外,意大利前总理达莱马在分享中倡导拥抱区块链技术,他认为,区块链最重要的应用领域就是金融科技,能够帮助降低金融交易的成本、改变我们的生活。但也需要全球化的、更智能的监管,让像区块链这样的创新技术能在控制风险的同时让所有人获益。

中国人民银行金融市场司副司长、百行征信有限公司顾问唐磊则关注征信领域的发展,他认为征信领域是金融科技应用中最基础、也最前沿的一个领域。掌握征信数据的数量、准确度和及时性,在一定程度上决定了金融机构的风控能力,也形成了金融机构的核心竞争力。其他几位嘉宾也在分享中基于自身经验带来了极具洞察力和远瞻性的精彩发言。

国际金融论坛(IFF)是独立的、非盈利、非官方国际组织,由中国、美国、欧盟等20多个国家和地区,联合国及相关国际组织、全球金融机构和领导人共同发起成立。全球新规则的变革与影响已扩展到每一个国家,国际金融论坛(IFF)致力于为全球经济和金融领袖参与对话提供良好的交流平台,通过更广泛的合作对话机制,进一步探讨全球新规则的变革与影响,为世界经济和金融的未来提供前瞻性的思想和可能的途径。

TalkingData林逸飞:私域流量运营将成为未来零售企业生存之道

近日,由36氪《零售老板内参》主办的「创鉴未来——2018 WISE 零售未来峰会」在北京成功举办,TalkingData合伙人&执行副总裁林逸飞在大会上发表了题为《零售行业私域流量构筑》的主题演讲,与众多零售业大咖与行业精英分享了TalkingData在私域零售运营方面的洞察与经验。

如今,作为零售行业不可忽视的两大巨头,阿里和腾讯分别代表着中心化和去中心化两种不同的战略,阿里通过投资持续深入产业链的各个细分领域,腾讯借助社交积聚了巨大的流量矩阵势能。而在行业大势中努力求生存的零售企业则要面临两种战略的持续博弈。

林逸飞指出,在过去的五、六年中,所有线上交易流量已经接近线上交易容量的天花板,很难再有所突破。根据数据统计,在总体消费者人群中,线上习惯消费人群占比9%,线下习惯购物人群占比15%,而全渠道购物人群占比则高达76%。对于这部分购物人群的争夺,也将成为未来零售行业的主战场。

在刚刚过去的双十一中,全网线上销售额达到了3153亿,其中天猫与京东就横扫了其中的85%。但同时我们也能在各种公开信息中看到,在过去的五年里,阿里的线上获客成本翻了6倍,而京东的也翻了1.5倍。这说明,即便自身已经掌握大量流量,如果不能精耕细作的运营,想从中获客与创收也并非易事。

注:点击查看大图,下同。

那么,面对这样的行业现状和发展趋势,零售企业应该如何应对?尤其是在如今的“新零售”、“智慧零售”时代,在零售企业积极进行数字化转型的过程当中,是否能够建立起可管理的企业自有流量,并为业务提升带来实际驱动力呢?

基于丰富的零售行业服务经验,TalkingData提出了一个概念:私域流量运营。林逸飞通过这面这张图对零售企业私域流量运营的策略进行了详细解读。

林逸飞认为,首先要做的就是整合和打通交易/会员数据这样的内部数据与行为/社交数据这样的外部数据,形成数据资产赋能企业数据中台,也就是企业私域流量池。再用私域流量去赋能品牌策略中台,借助丰富的流量运营手段去实现流量放大,再将流量沉淀回私域流量池、将数据沉淀回数据资产,形成闭环持续赋能。

其中最重要的就是构建基础数据能力,能够用数据对每个流量进行跟踪、分析、优化、沉淀,形成数据运营闭环和私域流量运营闭环,并以数据闭环驱动流量闭环实现全局闭环运营。

随后,他以实际案例介绍了私域流量运营所实现的成效。

案例一:某服饰集团基于策略中台(CDP&CEP)的私域流量运营

一家在中国有几千家门店、一年4万SKU的服饰集团,在TalkingData的帮助下构建了整体策略中台,制定全渠道私域流量建设战略,提高私域流量数字化运营能力。通过线上与线下、自有与外部数据的整合打通,针对不同目标人群、选择不同媒体矩阵进行精准的营销触达,并根据评估优化投放效果,借助上下两环的闭环,该集团在今年夏季的一次营销活动中实现了51万购买人数、近4亿GMV、64万订单量以及94倍ROI的优异成绩。

案例二:某时尚女装品牌客户数据平台(CDP)驱动的跨界社交裂变流量运营

基于合作打造的数据平台,TalkingData帮助某高端时尚女装品牌进行了深入的客户人群的探索,并针对目标客群特点选择了小众流量渠道,用小程序裂变推广和H5裂变推广等方式,在不久前的双十一预热活动中,仅仅以3万元的活动成本,就实现了800多万元的销售额。

最后,林逸飞分享了基于TalkingData技术+平台构建的私域流量运营整体方案。在TalkingData数据、数据智能市场、数据中台与策略中台以及众多数据应用的基础上,帮助企业通过数据指导业务,目前在零售、汽车等等行业已经有很多合作企业。

林逸飞总结道,孙子兵法中有“善战者求之于势”的说法,零售是一个快速变化且硝烟四起的行业,零售企业需要洞察并制定大势之下的相应策略,更需要通过数据赋能企业运营,以应对变化多端的线上线下市场发展。

崔晓波再任京东数字科技JDD大赛导师,助力数字科技创新探索

11月20日,JDD-2018 京东数字科技全球探索者大会在中国国际展览中心新馆举办,总奖金达到220万元的 JDD-2018 京东数字科技全球探索者大赛也正式拉开帷幕。TalkingData 创始人兼首席执行官崔晓波出席了此次大赛的启动仪式,并将再次担任大赛导师,为参赛团队提供指导。

在去年举办的首届 JDD 大赛上,崔晓波与国际人工智能联合会主席杨强、红杉资本中国专家合伙人车品觉以及前微软亚洲研究院城市计算领域负责人、现京东智能城市研究院院长郑宇共同担任大赛商业组导师,还为参与“登录行为识别”赛题的参赛团队提供了48小时的贴身辅导。

崔晓波表示,很荣幸再次担任 JDD 大赛导师,希望在此次大赛中与更多顶尖参赛团队碰撞出新的火花。在会后的媒体专访中,崔晓波提到:“与一些偏学术研究的算法竞赛不同,JDD 大赛更具有实战性,不仅在赛题设计上会从实际商业场景遇到的实际问题出发,还能够将大赛中产生的解决思路与算法模型应用在实际生产环境中,这也是 TalkingData 非常看重 JDD 大赛的原因”。

TalkingData 近年来在国际数据科学社区以及算法竞赛活动中非常活跃,与国际领先竞赛平台与数据科学家社区 Kaggle 达成战略合作,前后两次联合举办国际算法大赛,还在Kaggle上建立了中国数据集专区。崔晓波认为:“算法竞赛是数据科学与行业应用结合的最前沿,一方面可以加速创新算法模型的产生、行业潜在应用场景的挖掘,另外也为发现数据科学家人才提供了平台和机遇。”

崔晓波还表示,美国与欧洲在数据科学方面拥有领先科研水平和丰富人才资源,而中国拥有大量数据集资源、应用场景和实际业务问题。通过与国际数据科学社区的交流互动以及与国际前沿科技企业的合作,TalkingData 致力于连接和融合双方资源优势,产生更大、更广泛的价值。

除了 JDD 大赛的合作之外,TalkingData 还与京东数字科技(原京东金融,下同)在大数据平台以及应用数据支撑等方面进行了密切合作,在包括信贷、反欺诈、风险管理以及营销等应用场景中有成功的落地案例。

JDD-2018 京东数字科技全球探索者大会由京东集团、京东数字科技联合主办,KDD China 为学术指导单位,APEC 中国工商理事会青年企业家委员会为支持单位。大会旨在连接科技界、产业界、金融界、学术界、投资界五大圈层,搭建一个全球化的开放平台,共同探索数字科技创新之道与实体经济数字化升级之路。大会上,京东数字科技 CEO 陈生强宣布京东金融品牌正式升级成为京东数字科技,将继续保持以金融业务为核心板块,并为更多的产业提供服务。

TalkingData CEO崔晓波:赋能合作伙伴 数据核心是连接

在近日举行的 JDD-2018 京东数字科技全球探索者大会上,“京东金融”品牌正式升级为“京东数字科技”。前来为 JDD-2018 大赛揭幕并再次担任导师的 TalkingData CEO崔晓波在接受采访时表示,京东金融和 TalkingData 在大数据平台、应用数据支撑及营销获客场景等方面有着较多合作案例。

崔晓波表示,近两年科技企业和持牌机构的合作呈现出逐渐深化的发展态势,并且合作模式正在不断推陈出新。

“无论是最早发展金融业务,还是如今大数据、AI 及区块链前沿的科技赋能,开展合作都能弥补传统持牌机构在研发上的不足。”崔晓波说,此前 TalkingData 与京东云达成战略合作,并实现了数据的互联互通,在智慧城市领域打造了多个成熟应用。

在崔晓波看来,京东云作为云基础设施提供商,在政务应用、智慧城市以及营销场景结合方面拥有较为领先的技术水平,TalkingData 与京东云在智慧城市特别是文旅大数据应用等方面开展业务试点,且拓展速度较快。

“我们向京东云提供了 SaaS 级别的数据应用,包括营销云、智能选址模式等,京东云也在使用我们的模块赋能其生态上的企业。”崔晓波说。

崔晓波认为,科技企业乃至互联网持牌机构都离不开三点:一是数据,二是先进的科技平台,三是运营赋能。“从基础能力上看,有些公司会更加专注于某一点。但从整体业务模式来看,基于业务场景实现的综合能力则是大趋势。”

在今年9月举办的“T11数据智能峰会”上,崔晓波强调了对开放生态的重视,并发布了 TalkingData 数据中台。他认为,“数据中台最核心的思想和检验标准是共享能力。所谓‘中台’,就是希望把需要共同使用的能力或算法模型能够放在共用的数据平台上,从而达到分享及资源优化的目的。”

在崔晓波看来,数据中台的核心是连接,而不是拥有。数据中台用新型的技术方法把数据连接在一起,构建在满足隐私保护及数据安全需求的基础之上,这是数据中台的基础,也就是“数联网”。

来源:新华网

解惑丨如何在边缘设备上适配大型神经网络?

原文作者:Bharath Raj

译者:TalkingData 赵磊

原文地址:http://t.cn/Rkofy1e

对于任何想要创建可扩展服务的人来说,部署有内存限制的深度学习算法都是一种挑战。从长远来看,相比昂贵的云服务,在边缘设备上离线部署模型更为便宜,而且还有其他好处。唯一的缺点是它们缺乏内存和计算能力。

本文探索了一些可以用来在内存受限的设备中适配神经网络的技术。因为“训练”和“推理”阶段用到了不同的技术,所以将把它们分开来讨论。

训练

某些应用程序需要在线学习。也就是说,模型要根据反馈或额外的数据进行改进。在边缘设备部署这样的应用程序会给您的模型带来一个切实的资源约束。这里有4种方法可以减少此类模型的内存消耗。

梯度检查点像 TensorFlow 这样的框架需要消耗大量的内存用于训练。在前向传播过程中,计算图中的每个节点的值都会被计算并保存在内存中,因为在反向传播时计算梯度时需要用到。

每个节点的值在前向传播后保存,以便在反向传播中计算梯度。源码:

https://github.com/openai/gradient-checkpointing

通常情况下,这是可以做到的,但当模型变得越来越复杂时,内存消耗会急剧增加。一个巧妙的回避解决方案是在需要时重新计算节点的值,而不是将它们保存到内存中。

重新计算节点值用以计算梯度。注意,我们需要分别做若干次前向传播来完成一个反向传播。源码:

https://github.com/openai/gradient-checkpointing

然而,如上所示,计算成本将显著增加。解决办法是在内存中只保存一些节点,而在需要时重新计算其他节点。这些保存的节点称为“检查点”。这极大地减少了因深层神经网络而积累的内存消耗。如图所示:

左边的第二个节点是检查点节点。它在减少了内存消耗的同时提供了合理的时间成本。源码:

https://github.com/openai/gradient-checkpointing

以速度换内存(重计算)根据上面的想法,可以重新计算某些操作用以节省时间。Memory Efficient DenseNet 实现就是一个很好的例子。

DenseNet 的一个 dense 块

原文:https://arxiv.org/abs/1608.06993

DenseNets 具有很高的参数效率,但内存效率也很低。之所以出现这种矛盾,是因为拼接和批标准化操作造成的。

为了使卷积在 GPU 上更高效,必须连续地设置这些值。因此,在连接之后,cudNN 在 GPU 上连续地排列这些值。这涉及到大量的冗余内存分配。类似地,正如本文所解释的那样,批标准化涉及到过多的内存分配。这两种操作都会造成内存以二次增长。DenseNets 有大量的拼接和批标准化,因此它们的内存效率很低。

将原始的拼接和批标准化操作

与它们的高效内存实现相比较原文:

https://arxiv.org/pdf/1707.06990.pdf

上述问题的一个简洁的解决方案涉及两个关键的观察。

首先,拼接和批标准化操作不是时间密集型的。因此,我们可以在需要的时候重新计算这些值,而不是保存所有冗余内存。其次,我们可以使用“共享内存空间”来转储输出,而不是为输出分配“新”内存空间。

我们可以重写这个共享空间来存储其他拼接操作的输出。也可以在需要的时候重新计算拼接操作来进行梯度计算。同理还可以将它扩展到批标准化操作。这个简单的技巧节省了大量的 GPU 内存,通过增加少量的计算时间来换取。

减少精度在一篇优秀的博客中,Pete Warden 解释了如何用8位浮点值训练神经网络。由于精度的降低,出现了一些问题,其中一部分如下:

如本文所述,“激活值、梯度和参数”有非常不同的范围。一个定点表征并不理想。这篇论文声称,一个“动态的固定点”表征将非常适合于低精度的神经网络。正如 Pete Warden 的另一篇博客所述,较低的精度意味着更大的偏差。通常,如果错误是完全随机的,那么它们很有可能相互抵消。然而,0被广泛用于 padding、dropout 和ReLU,在低精度浮点格式中,0的精确表示也许是不可能的,因此可能会在性能中引入总体偏差。神经网络的架构工程架构工程涉及到设计准确率、内存和速度最优的神经网络结构。有几种方法可以在空间和时间上优化卷积。

将 NxN 的卷积分解成 Nx1 和 1 xN 卷积的组合。这可以节省大量的空间,同时也提高了计算速度。在 Inception 网络的更新版本中使用了这种方案以及其他一些优化技巧。更详细的讨论,请查看这篇博客:https://towardsdatascience.com/a-simple-guide-to-the-versions-of-the-inception-network-7fc52b863202在 MobileNet 和 Xception Net 中使用深度可分离的卷积。关于卷积的类型的详细讨论,请查看这篇博客:https://towardsdatascience.com/types-of-convolutions-in-deep-learning-717013397f4d使用1×1卷积作为一个瓶颈来减少传入通道的数量。这种技术已经在几种流行的神经网络中使用了。

谷歌的 AutoML 的描述,视频:

https://www.youtube.com/watch?reload=9&v=Y2VF8tmLFHw

一个有趣的解决方案是让机器为特定的问题确定最佳的架构。神经架构搜索使用 ML 来为给定的分类问题找到最好的神经网络体系结构。当在 ImageNet 上使用时,它生成的网络(NASNet)是迄今为止创建的最佳性能模型之一。谷歌的 AutoML 也遵循同样的原则。

推理

为边缘设备推理拟合模型相对比较容易。本节将介绍可用于优化边缘设备神经网络的技术。

去除臃肿像 TensorFlow 这样的机器学习框架,消耗了大量的内存空间来创建计算图。这个额外的空间对于加速训练过程是很有用的,但是它不用于推理。因此,专门用于训练的计算图部分可以被删除,我们把这部分称为计算图的“臃肿”。

建议将模型检查点转换为冻结的推理图。这个过程会自动删除消耗内存的“臃肿”部分。当转换为一个冻结的推理图时,从模型检查点抛出“资源耗尽的错误”的计算图有时可以被适配进内存中。

修剪特征在 Scikit-Learn 上的一些机器学习模型(如随机森林和XGBoost)会输出一个名为特征重要度(feature_importance)的属性。这个属性代表了分类或回归任务的每个特性的重要性。我们可以简单地删除那些最不重要的特征。如果您的模型有大量的特征,而且不能通过任何其他方法来减少,这将非常有用。

一个特征重要度可视图的例子:

https://machinelearningmastery.com/feature-importance-and-feature-selection-with-xgboost-in-python/

类似地,在神经网络中,许多权重值接近于零。我们可以简单地删除这些连接。然而,删除层间的单个连接会形成稀疏的矩阵。创建高效推理引擎(硬件)方面的工作正在进行,它可以无缝地处理稀疏操作。然而,大多数 ML 框架都是将稀疏矩阵转换成密集的形式,然后再将它们发送到 GPU 上。

去掉一个无关紧要的过滤器,原文:

http://machinethink.net/blog/compressing-deep-neural-nets/

相反,可以移除无关紧要的神经元,并稍微对模型进行重新训练。对于 CNNs,也可以删除整个过滤器。研究和实验表明,通过使用这种方法,可以保留大部分的精确度,同时获得大规模的缩小。

权重共享为了更好地说明权重的共享,参考一下这篇深度压缩论文:https://arxiv.org/pdf/1510.00149.pdf中给出的例子。一个4×4的权重矩阵。它有16个32位浮点值。我们需要512位(16*32)来表示这个矩阵。

我们将权重值量化到4个级别,但是保留它们的32位性质。现在,4×4的权重矩阵只有4个唯一的值。4个唯一的值存储在一个单独的(共享)内存空间中。我们可以分别给这4个唯一值一个2位地址(可能的地址值为0、1、2和3)。

可以通过使用2位地址来引用权重。因此,这里获得了一个新的4×4矩阵,其中包含2位地址,矩阵中的每个位置都指向共享内存空间中的一个位置。这个方法需要160位(162+432)来表示整个矩阵,得到了3.2的大小减少因子。

不用说,这种规模的缩小伴随着时间复杂度的增加。但是,访问共享内存并不会消耗太多的时间。

量子化和更低的精度(推理)回想一下,在本篇文章的“训练”部分中提到了精度的降低。对于推理来说,精确度的降低并不像训练过程那么麻烦。权重可以被转换成更低的精度格式,并发送到推理过程中。但是,可能需要轻微的权重调整来防止精确度的急剧下降。

编码修剪和量子化的权重可以通过编码进一步优化。Huffman 编码可以用更少的位表示最频繁的权重值。因此,在比特级别上,一个 Huffman 编码的字符串比普通字符串占用更小的空间。

深度压缩探讨了使用无损压缩技术的编码,如 Huffman 。然而,研究也探讨了有损压缩技术的使用。这两种方法的缺点是翻译的开销。

推理优化器到目前为止,我们已经讨论了一些很有建设性的想法,但是若从头开始实现它们需要相当长的时间。这就是推理优化器发挥作用的地方。例如,Nvidia 的 TensorRT 包含了所有以上这些想法。并提供了一个经过训练的神经网络的“优化推理引擎”。

TensorRT:

https://developer.nvidia.com/tensorrt

此外,TensorRT 可以优化模型,使其能够更好地利用 Nvidia 的硬件。下面是一个使用 TensorRT 优化的模型更有效地利用了 Nvidia 的 V100 的例子。

在 Nvidia 的 V100 上使用 TensorRT 优化的模型:

https://devblogs.nvidia.com/tensorrt-3-faster-tensorflow-inference/

知识蒸馏我们可以“教”较小的模型来模拟更健壮、更大的模型,而无需花哨的优化技术。这项技术被称为“知识蒸馏”,它是谷歌“ Learn2Compress ”的重要组成部分。

Teacher-Student 模型:

https://ai.googleblog.com/2018/05/custom-on-device-ml-models.html

通过使用这种方法,我们可以强制使用更小的模型,这些模型可以适配在边缘设备上,以达到大型模型的性能水平。据统计,精确度的下降是最小的。

更多信息可以参考Hinton的论文:

https://arxiv.org/pdf/1503.02531.pdf

TalkingData-2018年8月移动游戏Benchmark

2018年8月移动游戏Benchmark解读

付费率:2018年8月,移动游戏用户的付费率分别在Android和iOS平台出现微降和微升的状况,其中,角色扮演类移动游戏的付费率在Android和iOS平台略有下降,降幅分别为0.4%和0.3%;

用户活跃度:2018年8月,Android平台移动游戏用户的活跃情况延续下滑态势,而iOS平台移动游戏用户的活跃情况则有所好转,其中,iOS平台休闲类移动游戏的周活跃率和月活跃率分别环比增长4.8%和1.0%;

用户留存率:2018年8月,Android和iOS平台移动游戏用户的一日玩家比例整体略有增长,且Android平台增幅高于iOS平台,其中,Android平台动作类移动游戏的一日玩家比例环比增长0.3%,其次日留存率环比增长0.2%,而7日留存率则环比下降11.8%;

使用时长&次数:2018年8月,Android和iOS平台移动游戏用户的游戏习惯较为平衡,未出现较大波动,其中,iOS平台动作类移动游戏的日均游戏次数环比上月下降1.1%,平均每次游戏时长则下降4.2%。

TalkingData高铎:展望智能营销 3.0

近日,第五届世界互联网大会·乌镇峰会成功举办,来自近百个国家和地区的政府代表、互联网企业领军人物、互联网名人、专家学者汇聚一堂,围绕“发展数字经济促进开放共享——携手共建网络空间命运共同体”的主题,积极贡献思想智慧,聚焦即将到来的互联网下半场——产业互联网,共同探讨和交流如何深化互联网和数字经济、传统产业合作。

TalkingData 副总裁高铎在《大数据与人工智能赋能实体经济——产业创新与投资专题对接会》上与现场嘉宾们分享了主题为《人工智能赋能数据营销 3.0》的演讲。

TalkingData副总裁 高铎

高铎认为,“智能营销是三个时代的共存:第一,被动式营销时代;第二,主动式营销时代,第三,全域式营销时代。在这三个时代里, Data+AI 贯穿始终,我们目前都在全域营销中寻求突破”。

智能营销1.0——PC 时代

智能营销 1.0( PC 终端为主要载体)是被动式广告为主,以搜索广告为代表。用户搜索关键词时,平台会推出相关广告,在用户体验上属于被动接受。其特点是 NLP 相关的 AI 技术和 RTB 为主导的广告技术,底层以 Cookie 为 PC 终端标识延展出在浏览器上生存的各类网盟广告。但由于 Cookie 固有的易变特征,此类广告只在短期内有效。

智能营销2.0 – 移动互联网时代

智能营销 2.0 (移动智能终端为主要载体)是主动式广告时代,以信息流广告为代表。平台根据用户阅读的内容和兴趣,主动推送广告内容。它的主要特点是结合用户使用行为,“不知不觉”地进行广告触达。其主要存在于各类内容 App 的使用场景中,由于具备相对稳定的智能终端广告标识,其广告的持久性和可拓展性都远超过 Cookie ,能持续跟踪广告的效果和根据行为特征快速锁定目标受众( TA )。

智能营销3.0 – 数据连接时代

智能营销 3.0 可以称之为全域式广告时代,它存在于用户身边的四个屏幕里:手机、PC、OTT 以及车载 AVN 屏幕。通过四屏设备的底层广告标识打通,基于人群兴趣偏好和关注点预测,在四屏的不同使用场景中进行广告推送。

其广告展示逻辑、竞价体系等方面和前两个时代都大体相当,其技术的核心在于不同终端底层广告标识的打通,通过相对安全稳定的数据连接技术,打通终端后,能够更详细、更全景的刻画人的行为特征。但是在中国,很少有设备厂商、系统厂商能够像苹果一样拥有相对完备的产品生态,TalkingData 作为数据智能公司,在底层数据连接上积淀多年,帮助很多客户构建基础的数据连接体系。

全域式广告时代的核心在于数据连接,背后需要考虑两个关键点:

其一,数据安全性,保证数据处理、传输和使用过程中是加密的、脱敏的、不可逆的。其二,数据使用灵活度,因为前端的业务在不同的屏幕,需要有足够的灵活度支持多元化业务。数据营销闭环

我们分析目前的智能营销,是 1.0、2.0、3.0 共存的。在营销的三个时代里,营销闭环的逻辑贯穿始终。具体说就是通过 TA 目标人群贯彻整个营销过程,自始至终我们简化为五个环节:

TA分析,作为一个品牌广告主,要投的时候目标人群在哪里,怎么找,怎么评估TA触达,找到了目标人群之后怎么去触达,怎么让他看到我带来品牌的感知能力和广告。TA评估,品牌广告主评估触达的效果、转换的效果。TA迭代,看到了效果,知道了哪些人群、以及哪些创意是有问题的,又有什么相应的能力去帮助迭代TA选择,迭代之后就可以进行跟进,结合原有的数据能力再一次选择新的人群。最后,高铎表示:“广告业的经典语录是,知道广告费一半浪费了,但不知道是哪一半。如果能通过数据做到全闭环透明营销,如果能通过数据连接能力实现多屏幕全域营销,就会对营销预算作出更加契合消费者行为的分配。”

技术专栏丨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分布式锁的小坑踩一踩