Tumgik
chengxuyuanwenku · 2 years
Text
全民大规模新冠检测方案的一些想法
今天吃饭的时候和同事聊起最近上海深圳等超大城市全民新冠检测的问题。我认为现有方案有极大的改进空间。
千万级的全民检测,需要动用的资源是非常可观的,如果我们能优化这个过程,收益也会极其可观。现有的集体检测已经是相对独立个体分别检测做过优化了:通常是很多人放在一起混检,这样减少了检测成本。但我认为这是远远不够的。
现在自测盒的成本已经很低,至少一个自测盒的零售价格远低于我自己去医院做一次检测。所以我认为,如果全民自测的话,单从检测成本上来说,可能也是划算的。而且,对于群体检测,完全可以全家用同一个检测盒,这样如果是阳性,家庭成员就算没有全部感染,也最少是个密接。这比社区混检有效很多。
至于自测盒可能准确度不高的问题,完全可以自行多次自测来弥补。而目前采取的社区集体混检的形式,反而造成了人群密集,增加了病毒传染的风险。
但是,在千万级人口的城市中全民自测,显然结果是不可信的,这是我下面想谈的主要问题:如何设计一个方案,即降低了全民检测的成本,又能保持结果的可信度。即:如果有人自测发现自己阳性(或干脆不想自测),因为恐惧隔离而瞒报的问题。
我认为,当上千万人口中感染者其实不多,大多数社区中并无感染者时,最要紧的是快速排除掉无感染的社区。所以,加入自测环节,不是期盼人们自觉上报感染,而是用自测环节排除掉无感染社区,从而降低整体的成本。
以小区为单位,每个家庭每天发一个自测盒,全家共用一个居家自测,连续测试多天。
若自测发现阳性,鼓励主动上报。每个小区首先主动上报阳性的若干家庭,可以享受高标准隔离,例如,可以安排在高档酒店单独隔离。如果高标准隔离场所资源有限,后续自主上报者,也可以获得额外的物质奖励。
若整个小区无一例阳性上报,则不再对该小区做额外处置。
若小区至少有一例上报,则退化回原有的社区混检方案。在这个检测中再次发现的额外感染者(无主动上报),去集体方舱隔离。
注意,在这个方案中,并不信任自测主动上报阳性的个例,只是用来触发小区混检的启动。即,用来排除无风险小区,而不是用来找到具体感染者。但是,主动上报是有好处的(享受更好的隔离条件),而隐瞒不报或干脆不测是有风险的(在条件较差的地方隔离)。
From: https://blog.codingnow.com/2022/03/covid19_testing.html
0 notes
chengxuyuanwenku · 2 years
Text
神策数据发布职业教育 & 素质教育解决方案,帮助企业打造增长闭环
Tumblr media Tumblr media
教育数字化从业者们,你是否正在被以下问题困扰:
搭建了数据系统却用不出价值?
复杂多样的分析结果难以赋能业务?
团队缺乏应用数据的意识与能力?
为了帮助大家打破困局,神策数据基于对职业教育、素质教育深入研究,结合服务数百家教育企业的数字化实践经验总结,推出全新职���教育 & 素质教育解决方案,并首度全网公开。本解决方案从职业教育 & 素质教育的业务增长逻辑出发,基于核心增长目标,为企业提供数据层到组织层的全方位保障,助力教培企业顺利跑通每一个业务场景增长闭环,最大化实现数据价值。
Tumblr media
接下来,我们将从 5 大核心增长目标,4 层关键驱动要素,进一步了解神策数据职业教育 & 素质教育解决方案。
一、职业教育 & 素质教育数字化经营 5 大核心增长目标
1、从获客到承接,全面提升有效线索数
在《教育行业线索转化全链路解决方案》中,我们已经明确线索对教培企业销售工作开展的重要性,因此提升线索数量和质量是相当重要的增长目标之一。在用户从自然流量转变为有效线索的过程中,决定因素有两个:
第一,找得准,即获客渠道的精准性。是指在众多拉新方式中,谋求渠道价值最大化。
一方面,进行高价值人群扩展。通过神策分析定位已转化的核心用户群,下载人群包回传至广告平台,利用广告平台的智能拓展能力,找到匹配的相似人群进行精准投放。另一方面,精准对比各渠道 ROI。不仅关注渠道“展点消”等基础指标,更要直观对比不同渠道、账号、计划、创意维度下的线索获取成本,从而优化投放预算。
第二,接得住,即流量承接方式的优化效率。投放物料效果的好坏,会直接影响转化率和获客成本,最合理的评估方式是通过 A/B 测试,快速迭代和优化落地页。另外,神策数据职业教育 & 素质教育解决方案能够实现新用户从站外到站内行为路径贯通,有效定位线索流失原因,进而调整承接策略。
Tumblr media
2、基于线索分层培育体系,提高首单转化率
当前,教培企业大多面临着“大量公海线索难以管理,传统电销方式不仅耗费人力还打扰用户”的困境,因此,设计一套可落地的线索分层培育体系是十分必要的。
在线索分配层面,基于用户行为对线索成熟度进行划分,采取相应的运营策略,以达到高价值线索及时沟通、销售资源合理分配的目标。
Tumblr media
在线索管理层面,基于数据安全合规要求,采集线索的行为、属性、跟进记录,不断丰富用户画像,并及时同步至一线销售人员,比如 CRM 的客户档案、企微的客情卡等。
Tumblr media
3、数据驱动学习产品体验升级,学习服务提效保质
教培机构的口碑依赖于学员对课程服务的评价,因此,基于学习主体与客体的全面分析,是改进课程、驱动学习产品体验升级的重要依据。
比如,针对学员到课率低的情况,设计个性化的自动督学提醒,不仅有助于提升完课率,还能让学员体验到更加个性化的学习服务,增强学习产品的竞争力。
Tumblr media
4、量化关键行为,提高学员复购率
当学员与课程产品交互越多,用户画像就会越丰富,班主任对学员的复购、进阶意向也就掌握得更精准,通过量化学员关键行为,及时跟进高意向学员,并对不同群体采取差异化销售策略,以此提高学员复购率。
Tumblr media
5、活动策略高效赋能,提升转介绍转化率
在该场景中,神策数据职业教育 & 素质教育解决方案能够帮助教培企业利用社交关系低成本获客,提升转介绍活动效果。那么如何设计一场高转化、低成本的转介绍活动呢?神策数据从活动前、活动中、活动后给出解决方案:
活动前:根据历史活动参与情况找到适合的 KOC 作为活动参与者,并对关键活动页面设计指标体系;
活动中:监测活动效果,对异常问题及时诊断排查;
活动后:分析活动对用户活跃层级、消费层级的整体影响,选出活动最受欢迎的课程和老师,迭代下一轮活动策略。
Tumblr media
二、职业教育 & 素质教育数字化经营 4 层关键驱动要素
数据层:神策数据自成立以来,坚持为客户提供私有化部署,最大限度打消客户数据安全顾虑,现已通过标准化的流程与设计,能够有效满足企业在全场景、多应用环境下的部署、升级、服务治理与监控等需求;作为行业开源数据采集 SDK 先行者,神策数据持续对 50 多款 SDK、超 30 万行代码进行维护与迭代,为打造用户行为数据采集 SDK 标准体系贡献力量;除此之外,神策数据支持客户端、服务器、第三方等全端数据采集,秒级导入,秒级查询。
产品层:神策数据为企业提供完整的产品矩阵,包括用户行为分析平台、广告分析平台、A/B 测试平台、智能预警、用户标签画像平台、智能运营平台,全方位保障数字化决策的可靠性以及策略落地后的闭环复盘。
业务层:神策数据拥有丰富的教育行业交付经验,现已服务百余家知名教培企业,能够充分理解教培业务,为企业提供个性化、数字化发展规划与支持。
组织层:神策数据为教培企业提供多种服务模式,包括训练营、专题咨询、场景陪跑,致力于帮助更多教培企业培养数字化优秀人才,驱动整个行业积极发展。
关于神策数据
神策数据(Sensors Data),全称神策网络科技(北京)有限公司,是国内专业的大数据分析和营销科技服务提供商,为企业提供神策营销云、神策分析云、神策数据根基平台三大产品方案,通过全渠道的数据采集与全域用户 ID 打通,全场景多维度数据分析,全通道的精准用户触达,帮助企业实现数字化经营。
神策数据立足大数据及用户行为分析的技术与实践前沿,提出基于数据流的企业运营框架——SDAF,即 Sense(感知)、Decision(决策)、Action(行动)、Feedback(反馈)的数据闭环,并致力为客户打造基于 SDAF 运营框架的数据闭环。业务现已覆盖以互联网、品牌零售、金融、融合媒体、企业服务、高科技、汽车、互联网+ 等为代表的 30 多个主要行业,并可支持企业多个职能部门,目前已服务付费客户 2000 余家。公司总部在北京,并在上海、深圳、合肥、武汉、成都、中国台北等地均拥有本地化的服务团队,覆盖全国及东南亚市场,同时,公司拥有专业的服务团队,为客户提供与营销和大数据相关的咨询、解决方案和专业服务。
Tumblr media
From: http://www.sensorsdata.cn/blog/20220329/
0 notes
chengxuyuanwenku · 2 years
Text
新国货品牌数字营销系列报告丨加速连锁餐饮赢战数字化未来
Tumblr media Tumblr media
疫情冲击之下,众多新国货连锁餐饮品牌多措并举,在逆境中加速数字化转型。通过积极开展线上业务,对消费者全生命周期价值进行充分挖掘。连锁餐饮品牌具有天然的数字营销优势,其线下门店触点都是品牌自身强管控的,能够快速将线下客流往线上迁移。但需要强调的是,作为毛利率比较低的一个行业,连锁餐饮品牌数字化转型的资金更应该花在“刀刃”上。
神策研究院联合魔镜市场情报共同发布《新国货品牌数字营销系列研究报告》,旨在通过对细分行业的深入分析,为新国货品牌建立长期竞争力提供指引。本文将围绕新国货连锁餐饮消费者趋势、营销趋势,结合数字营销现状及案例剖析,希望能为国货连锁餐饮品牌在制胜路上提供有效参考。
一、新国货连锁餐饮行业数字营销背景
中国连锁餐饮发展经历了“单店作坊、全国布局、深耕产业、数字化”四个阶段,目前已经进入 4.0 数字化阶段,呈现线上化、零售化、消费者偏好多元化的趋势。
Tumblr media
当前,中国连锁餐饮发展特点可以总结为三点:
第一,增长迅速,餐饮行业迎来“堂食 + 外卖”双主场时代;
第二,线上线下融合发展已成为发展趋势,餐饮品牌利用互联网平台不断延伸服务半径;
第三,下沉市场餐饮消费潜力提升,订单量和交易额均有明显增长。
与此同时,Z 世代崛起成为餐饮行业消费主力军,他们对餐饮的需求更加多样化,加速“一人食、轻食”的流行;相比以往的餐饮消费群体,年轻群体的消费呈现碎片化、多元化的趋势,对于“健康”的需求愈发明显,且在疫情影响之下不断向家庭场景拓展。
Tumblr media
在营销侧,新国货连锁餐饮品牌国风潮盛行:打造国潮 IP,向消费者传递古典中国风的品牌形象;推出国风门店,打造古色古香的就餐环境;玩转跨界联名,在产品设计、包装设计、宣���上与中国传统文化元素相结合,引领国潮。另外,短视频平台也逐渐成为餐饮品牌偏爱的营销渠道,微信生态也成为其私域流量的主要运营阵地。
二、新国货连锁餐饮数字营销现状及案例
基于神策数据 SDAF 数字化运营成熟度模型,对连锁餐饮品牌数字化营销评估结果发现:
国货连锁餐饮品牌的数字化营销能力处于中游水平,各领域均有较大提升空间,从细项上来看,国货连锁餐饮在【数据决策能力】得分略低,应重点加强;领军者在模型各方面均较领先,其中【数字洞察能力】和【数字运营能力】是关键;主流品牌的数字化营销能力还偏弱,各领域的建设力度均不够。
Tumblr media
进一步来看,国货连锁餐饮品牌需加强场景洞察能力,主要体现在客户分层和客户运营场景提炼上;餐饮行业对线下触点强管控,天然具有将线下客户向线上迁移的优势,因此善于用户运营;国货餐饮品牌在数据驱动思维和数据反馈闭环的建立上还有较大的提升空间。
案例:某新国货连锁餐饮品牌将“数字化”上升为增长战略,不断提升用户数字化率
2020 年是该品牌的数字化建设元年,通过整合会员及用户数字化部、O2O 与外卖部、信息中心,成立数字化增长中心,将“数字化”上升为增长战略,并上线微信小程序,推出基于微信生态的线上付费会员折扣卡,加强与用户之间的链接。
其中,在使用微信搭建客户池时,该品牌根据用户定位为用户推荐最近的门店企微社群二维码,用户进群可享受多种福利,实现用户复购率和忠诚度的全面提升。同时,该品牌依托微信生态 UnionID,打通企业微信和 CRM 系统,形成用户数字标签,针对特定人群包实行个性化营销策略,实现“千群千面”的数字化营销。
Tumblr media
三、新国货连锁餐饮品牌制胜启示
1、新国货连锁餐饮品牌通过聚焦业务在线化、用户数字化、运营数字化三方面提升数字营销思维,如下图所示:
Tumblr media
2、在实现消费者全生命周期价值运营时,不同规模的连锁餐饮品牌需关注不同的重点:小而美的企业聚焦数字化链条前端板块,规模化的企业更聚焦双中台的搭建。
Tumblr media
3、新国货连锁餐饮品牌应对消费者生命周期进行分层,从而实现消费者全生命周期的精细化运营。
Tumblr media
4、消费者全生命周期运营的基础是构建动静结合的全域会员用户标签体系,颗粒度越细,越容易产生更好的落地效果。
Tumblr media
点击下载:《新国货品牌数字营销系列研究报告》完整版
关于神策数据
神策数据(Sensors Data),全称神策网络科技(北京)有限公司,是国内专业的大数据分析和营销科技服务提供商,为企业提供神策营销云、神策分析云、神策数据根基平台三大产品方案,通过全渠道的数据采集与全域用户 ID 打通,全场景多维度数据分析,全通道的精准用户触达,帮助企业实现数字化经营。
神策数据立足大数据及用户行为分析的技术与实践前沿,提出基于数据流的企业运营框架——SDAF,即 Sense(感知)、Decision(决策)、Action(行动)、Feedback(反馈)的数据闭环,并致力为客户打造基于 SDAF 运营框架的数据闭环。业务现已覆盖以互联网、品牌零售、金融、融合媒体、企业服务、高科技、汽车、互联网+ 等为代表的 30 多个主要行业,并可支持企业多个职能部门,目前已服务付费客户 2000 余家。公司总部在北京,并在上海、深圳、合肥、武汉、成都、中国台北等地均拥有本地化的服务团队,覆盖全国及东南亚市场,同时,公司拥有专业的服务团队,为客户提供与营销和大数据相关的咨询、解决方案和专业服务。
Tumblr media
From: http://www.sensorsdata.cn/blog/20220329-2/
0 notes
chengxuyuanwenku · 2 years
Text
【躲过裁员,成功上岸】发现小公司有不好的苗头,赶紧学习!
读者反馈:今年这波裁员有点凶,但在我们公司去年已经有了些不好的苗头,为了不让自己那么拉胯🌶,躲不过各种坑坑洼洼。跟着小傅哥的博客内容补全了自己很多的知识,包括:中间件、字节码、DDD项目、设计模式以及面试手册等,终于算是有了一点点竞争力。赶在这波裁员时上岸了!可能也有运气的存在,继续努力吧!
技术是长期积累沉淀的,并不是一蹴而就的,更不是成为一堆没用资料的收藏家。只有跟随还在一线编码的硬核号主,吸收实战经验才能快速成长。- 看大厂架构师写的资料,真香!
资料包括:Java 面经手册、重学Java设计模式(PDF)、手撸Spring、字节码编程、从大学到毕业的资料汇总、Lottery 分布式秒杀抽奖实战项目 - 把小傅哥的好东西都拿出来了!
学习地址:https://bugstack.cn
有价值的干货资料介绍
1 Java 面经手册
全书共计5章29节,417页11.5万字,耗时4个月完成。涵盖数据结构、算法逻辑、并发编程、JVM以及简历和互联网大厂面试等内容。
《Java 面经手册》是一本以面试题为入口讲解 Java 核心技术的 PDF 书籍,书中内容也极力的向你证实代码是对数学逻辑的具体实现。为什么这么说? 当你仔细阅读书籍时,会发现这里有很多数学知识,包括:扰动函数、负载因子、拉链寻址、开放寻址、斐波那契(Fibonacci)散列法还有黄金分割点的使用等等。
编码只是在确定了研发设计后的具体实现,而设计的部分包括:数据结构、算法逻辑以及设计模式等,而这部分数据结构和算法逻辑在 Java 的核心 API 中体现的淋漓尽致。那么,也就解释了为什么这些内容成为了热点面试题,虽然可能我们都会觉得这样的面试像是造火箭。
2 重学Java设计模式 - PDF版
全书共计22个真实业务场景对应59组案例工程、编写了18万字271页的PDF、开始耗时50天打造完成。
本书是作者小傅哥,基于互联网真实案例编写的Java设计模式实践图书。全书以解决方案为核心,从实际开发业务中抽离出交易、营销、规则引擎、中间件、框架源码等22个真实场景,对设计模式进行全面、彻底的分析。帮助读者灵活地使用各种设计模式,从容应对复杂变化的业务需求,编写出易维护、可扩展的代码结构。
3 字节码编程
全书共计107页,11万7千字,20个章节涵盖���个字节码框架和JavaAgent使用并附带整套案例源码!
讲道理,市面上以及网络搜索中都基本很少有成体系的关于字节码编程的知识,这主要由于大部分开发人员其实很少接触这部分内容,包括;ASM、Javassist、Byte-buddy以及JavaAgent,没有很大的市场也就没有很多的资料。但大家其实已经从其他的框架或者中间件中使用到,就像你用到的;Cglib、混沌工程、非入侵的全链路监控以及你是否使用过jetbrains-agent.jar做了某项实验?
4 Spring 手撸专栏
在写了部分关于 Spring核心源码 的面经内容后,我决定要去手撸一个Spring了。为啥这么干呢?因为所有我想写的内容,都希望它是以理科思维理解为目的方式学会,而不是靠着硬背记住。而编写面经的过程中涉及到的每一篇Spring源码内容分析,在即使去掉部分非主流逻辑后,依然会显得非常庞大。
此专栏是一本以开发简化版Spring学习其原理和内核的知识内容,不仅是代码编写实现也更注重内容上的需求分析和方案设计,所以在学习的过程要结合这些内容一起来实践,并调试对应的代码。粉丝伙伴在阅读的过程中,千万不要害怕在学习的过程中遇到问题,这些都是正常的! 希望你可以一直坚持把这些内容事必躬亲、亲历亲为的学完,加油!
5 IDEA Plugin 开发手册
此开发手册,分为4章12节循序渐进的通过实践案例开发的方式,串联 IDEA Plugin 开发的各项常用技术点,为读者讲解如何开发一个 IDEA 插件。
IDEA 插件开发可以帮助研发人员提升能效,解决一些实际场景中的共性问题。但最近在折腾IDEA插件开发的时候,市面的资料确实不多,也没有成体系完整的开发指导手册,所以就遇到了很多不知道就不会的事情,需要一点点查询搜索源码、验证API接口,最终把各项功能实现,当然在这个过程中也确实踩了不少坑!接下来在这个专栏会把一些关于 IDEA 插件开发用到的各项知识做成案例输出出来,帮助有需要的研发伙伴,一起建设 IDEA Plugin。
6. Lottery 抽奖系统 - 基于领域驱动设计的四层架构实践
Lottery 抽奖系统 项目是一款互联网面向C端人群营销活动类的抽奖系统,可以提供抽奖活动玩法策略的创建、参与、记账、发奖等逻辑功能。在使用的过程中运营人员通过创建概率类奖品的抽奖玩法,对用户进行拉新、促活、留存,通常这样的系统会用在电商、外卖、出行、公众号运营等各类场景中。
此系统架构为 DDD 领域驱动设计的四层架构实现方式,以重视代码实现落地的方式向读者介绍和展示如何开发这样的代码。
在 Domain 领域层逐步通过拆解系统流程设计,按照职责边界的领域模块进行设计和开发,最终在应用层进行逻辑功能编排。
这个系统中会体现出很多的设计模式思想和最终的实现,只有把 DDD 和设计模式结合起来,才能开发出更加易于扩展和维护的代码结构。
7. SpringBoot 中间件小册
全小册19个章节,包括16个中间件的设计和开发,包括测试案例共30个代码库提供给读者学习使用。小册实现的中间件场景涵盖:技术框架、数据服务、数据组件、分布式技术、服务治理、字节码、IDEA插件七个方面,贯穿整个互联网系统架构中常用的核心内容。非常值得了解、学习、实践到掌握。
技术框架:包括 Spring、SpringBoot 配置加载、自定义注解、扫描注册Bean等,以及 ORM 框架设计原理和实现。这部分技术主要是把开发的中间件与框架结合,开发相应的组件或者包装为各类 SpringBoot Starter 的能力学习。
数据服务:Mysql、Redis、Elasticsearch,都是数据服务,通常需要开发各类组件对数据服务的使用进行封装,Mysql 我们知道有 JDBC,Redis 我们知道有 Jedis,但 Elasticsearch 有 x-pack 你是否了解。
数据组件:这类组件的开发就是为了简化对数据服务的使用,Mysql+JDBC+ORM,可以非常方便的使用数据库服务,那么 Elasticsearch 是否也可以做相应的组件研发,让它的查询也能像使用 MyBatis 一样呢?二折页的技术能力就需要对 MyBatis 等 ORM 框架的实现原理熟悉,同时需要了解 JDBC 的概念。
分布式技术:RPC 框架、注册中心、分布式任务,都是现有互联网分布式架构中非常重要的技术,而对于如何实现一个 RPC 框架,也技术是研发人员要掌握的重点,同时如何使用注册中心、怎么下发分布式调度任务,等等,这些技术的学习能让对现有的框架使用有更深入的认识。
服务治理:熔断、降级、限流、切量、黑白名单以及对现有方法的非入侵式扩展增强等,都可以成为是服务治理类组件,原本这类技术在早期是与业务逻辑代码融合的,后来逐步被拆解出来,开发成对应的组件。所以我们可以学习到,关于这类组件的包装、集成是如何做的。
字节码&插件:在互联网的系统应用运维过程中,你一定会接触到各类的监控系统,而很多监控系统是非入侵的全链路监控,那么这些是如何实现的呢?其实它们是基于字节码插桩,对系统方法的增强,采集相应的运行时信息,进行监控的。再到扩展 JVMTI、IDEA 插件开发,都是为了整个研发过程的可持续交付和上线提高交付质量和降低人效的。
小傅哥所编写的这些技术资料,皆是亲自验证、体系梳理、逐步总结的技术内容,所以在学习的过程中一定要对照源码对应的案例进行学习,这样才能让你有更大的收获。
最后,我想说:能力,是你前行的最大保障。哪怕你是兢兢业业的工作者,也要拥有能留下的本事和跳出去的能力,才会相对安稳度过动荡和一次次的动荡。
本文参与了 SegmentFault 思否征文「如何“反杀”面试官?」,欢迎正在阅读的你也加入。
From: https://segmentfault.com/a/1190000041622957
0 notes
chengxuyuanwenku · 2 years
Text
周报速递|视频号成腾讯财报新宠;央行推进金融数字化转型
Tumblr media Tumblr media
神策研究院数字化趋势周报栏目主要发布当周数字化相关宏观趋势、行业动态及行业观点汇总,并融合神策研究院洞察,希望通过这一栏目帮助读者了解最新的行业动态并判断未来行业发展趋势。
01 宏观
神策研究院洞察
金���数字化转型迈入深化发展新阶段。基于上一阶段金融数字化积累的经验与成果,结合数字经济发展的新趋势、新动向,金融数字化转型的部署将使得更多成果逐步落地,为实体经济的高质量服务带来助力。
人民银行:开展金融数字化转型提升工程
近日人民银行金融科技委员会召开会议,研究部署 2022 年重点任务。会议提出,开展金融数字化转型提升工程,推动金融数字化转型从多点突破迈入深化发展新阶段。会议强调,2022 年要多措并举推动《金融科技(FinTech)发展规划(2022—2025 年)》落地实施,高质量推进金融数字化转型。
“数字营销质量与透明度提升计划” 2022 年工作计划发布
为打击互联网广告数据造假和作弊行为,营造透明、真实、绿色的互联网广告生态环境,落实国家数字经济产业生态建设工作布局,2022 年 3 月 14 日,中国信息通信研究院、中国广告协会、中国互联网协会联合 47 家高校、科研院所与企事业单位共同发起“数字营销质量与透明度提升计划”。
微信 PC 版 3.6.0 正式发布:支持添加好友功能
近日,微信发布 Windows 微信 3.6.0 正式版更新,备受期待的“加好友”功能终于来了。用户可直接点击搜索栏后的“+”搜索和添加好友。值得一提的是,在 3.6.0 版中用户拖拽发送图片或文件给好友时,还能同时给好友留言,描述文件内容更加方便。
经测试,如果想要识别二维码,只需启动微信截图(Alt+A),点击工具栏中新增加的“识别图中二维码”按钮,就能开启识码,为日常工作带来更多便利。
02 行业动态
互联网
神策研究院洞察
腾讯财报显示其与私域关联业务带来的收入增量越来越大。结合腾讯在小程序、企业微信的调整,以及其企业服务收入变化等,已经显示出私域带来的巨大价值。视频号来到了流量爆发的前夕,今年将是视频号商业化发力的一年。
天翼云默默稳居云终端市场的龙头地位,业绩亮眼。云计算、5G 等技术的发展加速了云终端的应用,市场规模不断增长,产品技术与能力也在逐步趋于成熟。中国电信作为通信运营商,使天翼云拥有天然的网络资源池优势,也使其具备深入到全国各地的服务团队。另外电信的央企身份背书也带来了天然加成,更易获得有安全诉求厂商的青睐。
视频号成腾讯财报新宠
腾讯刚刚发布了其截止 2021 年 12 月 31 日的第四季度和全年财报。在刚刚过去的第四季度,腾讯营收 1441.88 亿元,同比增长 8%,全年营收 5601.18 亿,同比增长 16%。
透过财报,我们看到了一系列私域相关的重大变化,尤其是:视频号被提及次数超过了微信,使用时长和播放量同比翻倍,且视频号直播开始带来收入,暗示这个产品重要程度更甚。而和私域相关的广告业务,也超过腾讯朋友圈广告收入 1/3。在财报中,腾讯越加重视 To B 业务,其中信息也暗示出了腾讯对私域业务的目标有了新调整。
被“忽略”的云巨头:天翼云营收三位增长从何而来
3 月 17 日,中国电信发布了 2021 年度业绩报告,2021 年全年,中国电信实现营业收入人民币 4396 亿元,同比增长 11.7%;产业数字化业务收入达到人民币 989 亿元,同比增长 19.4%。
作为运营商云,天翼云的市场风格相对低调,以至于偶尔被“忽略”,业绩是强有力的证明,证明了天翼云更受到当下以政企客户为主的云计算客户的欢迎。财报也提到,天翼云在政务、公共事业、互联网、工业制造等领域,赢得多个亿元以上云业务和 CDN 业务项目订单。
京东云计算投资成立数字科技新公司
企查查 APP 显示,3 月 19 日,京东(梨树)数字科技有限公司成立,法定代表人为王楠,注册资本 1000 万元人民币,经营范围包含:5G 通信技术服务;云计算设备销售;物联网设备销售;互联网设备销售等。企查查股权穿透显示,该公司由京东云计算有限公司间接全资控股。
电子商务
神策研究院洞察
透视财报,拼多多正由“高增长”转向“高质量增长”。从拼多多 2021 财报和最近动向来看,其战略方向正由重营销转向重科研,结合拼多多之前设立的“百亿农研专项”,能观其正有条不紊地加码产业链前端投入,发展农业科技的核心技术。
拼多多:2021 年 Q4 营销费用同比下降 23%,全年研发费用同比增长 30%
拼多多发布 2021 年四季度及全年财报。财报显示,拼多多 2021 年 Q4 营销费用同比下降 23% 至 113.658 亿元,全年研发费用同比增长 30% 至 89.926 亿元。去年 8 月,拼多多宣布设立“百亿农研专项”,并将二、三季度的利润全部投入到该专项。拼多多董事长兼 CEO 陈磊表示,去年四季度的利润也将用于农研科技领域。
企业服务
神策研究院洞察
钉钉此次品牌升级意味着其云钉一体战略的贯彻落地。钉钉凭借早期的先发优势与之后的快速进化能力,无论从产品力、用户规模还是产业覆盖广度上,都在行业内处于绝对领先者的位置。从长期来看,企业协同办公这场入口级企业应用的争夺战,势必会在钉钉与企业微信之间展开。
钉钉召开 2022 发布会:品牌全新升级,首次发布生态战略
3 月 22 日,钉钉召开“科技向实·万物生长” 2022 发布会,发布新的品牌主张,从“让工作学习更简单”的效率工具,走向价值深化的方向。此次大会上,钉钉首次明确回答了自��和生态的关系:钉钉只做一件事,就是 PaaS 化。
PaaS 化指的是钉钉只做基础能力和基础产品,并将这些能力和产品作为底座开放给生态。钉钉将保持协同办公和应用开发平台的定位不变,继续战略投入文档、音视频、项目、会议等基础产品,其他如行业应用、人财物产供销研等场景的专业应用等,都交给生态做。同时,钉钉会将硬件全面生态化。
以“融智聚力 共赢 BIP”为主题的 2022 用友生态大会在线上召开
3 月 23 日,以“融智聚力 共赢 BIP”为主题的 2022 用友生态大会在线上召开。作为用友“技术共生 商业共赢”的长期战略合作伙伴,华为云在此次会上带来了与用友联合打造的业界首个云 ERP 本地化部署解决方案——NC Cloud 智能边缘小站(简称 NCC IES)。华为云全球生态部总裁康宁受邀参会并发表《凝心聚力,共创商业新价值》主题演讲。
DevSecOps 头部厂商悬镜安全完成 B 轮数亿元融资
钛媒体 App 3 月 22 日消息,DevSecOps 敏捷安全头部厂商悬镜安全正式宣布完成数亿元人民币 B 轮融资,本轮融资由源码资本领投、GGV 纪源资本跟投、红杉中国继续加持。
悬镜安全将进一步深化在中国软件供应链安全关键技术创新研发及上下游产业生态前瞻性布局上的战略投入,凭借领先的下一代敏捷安全框架,在 DevSecOps 敏捷安全、软件供应链安全和云原生安全等新兴应用场景下,打造闭环的第三代悬镜 DevSecOps 智适应威胁管理体系,持续升级在华北、华东、华南、华中、西南、港澳等地区的规模化产品服务交付和运营能力,深度覆盖金融电商、能源电力、智能制造、电信运营商及泛互联网等企业级安全市场。
Adobe 现平均每天处理超过 1PB 的客户数据
近日,Adobe 发布了实时 CDP (客户数据平台) 的创新功能,包括以市场领先的规模收集、丰富和分发数据,协助企业持续改进与受众的互动方式。Adobe 现为来自 24 万亿个受众细分市场交付实时数据,每天处理的数据量超过 1PB。最新采用 Adobe 实时 CDP 的部分品牌包括可口可乐、通用汽车等。
03 行业之声
艾瑞咨询发布《2022 年中国 CRM 行业研究报告》
近两年,在新冠疫情等因素影响下,企业数字化转型加速,作为企业级应用软件中的热门选手,CRM 在我国的发展空间及增长潜力被普遍看好。身处供应、需求、投资之变局的 CRM 行业,在市场认知、服务能力、技术形态等方面,目前仍存在较多痛难点。本报告将阐明我国 CRM 市场发展现状和行业应用,并结合市场变化及痛点,预测评估 CRM 行业的核心发展趋势。
Adobe:2022 年亚太地区网络趋势报告
亚太地区处于有利地位,可以利用其技术领先地位,加速进入一个几乎无法想象的数字和社会变革的新时代。亚太发达经济体将改善连通性、政府刺激措施、不断提高的技术技能、高额研发支出和热情的数字消费者群结合起来,这样就拥有了数字化转型和创新的完美条件。
在新兴和发展中经济体,新冠危机不仅加速数字行为,而且还首次使数百万人上网,以实现非接触社交。这个新的互联网用户群不受历史技术惯例的限制,在数字行为方面实现了跨越式发展,选择了移动优先的互联网服务体验。
申明:以上信息来源于钛媒体、morketing、互联网智能建造、199IT 互联网数据中心、艾瑞咨询、36 氪、Techweb、DO news、新浪科技、中国信通院、51 CTO。本站对文章内包含的所有信息的准确性或完整性不作任何陈述或保证,对基于此等信息的所有责任声明免责。
关于神策数据
神策数据(Sensors Data),全称神策网络科技(北京)有限公司,是国内专业的大数据分析和营销科技服务提供商,为企业提供神策营销云、神策分析云、神策数据根基平台三大产品方案,通过全渠道的数据采集与全域用户 ID 打通,全场景多维度数据分析,全通道的精准用户触达,帮助企业实现数字化经营。
神策数据立足大数据及用户行为分析的技术与实践前沿,提出基于数据流的企业运营框架——SDAF,即 Sense(感知)、Decision(决策)、Action(行动)、Feedback(反馈)的数据闭环,并致力为客户打造基于 SDAF 运营框架的数据闭环。业务现已覆盖以互联网、品牌零售、金融、融合媒体、企业服务、高科技、汽车、互联网+ 等为代表的 30 多个主要行业,并可支持企业多个职能部门,目前已服务付费客户 2000 余家。公司总部在北京,并在上海、深圳、合肥、武汉、成都、中国台北等地均拥有本地化的服务团队,覆盖全国及东南亚市场,同时,公司拥有专业的服务团队,为客户提供与营销和大数据相关的咨询、解决方案和专业服务。
Tumblr media
From: http://www.sensorsdata.cn/blog/20220328/
0 notes
chengxuyuanwenku · 2 years
Text
2022招聘季|从招聘方的角度理解求职
0 起因
前些日子,有位同学找我咨询求职问题。他本科专业其实不错,但是第一份工作没找好,所以只好报了家培训班,想社招之路走得更稳一些。结业之前,他担心培训班就业辅导不够,也找了几位外部导师帮忙。其中就包括我。
熟悉我的人都知道,我比较反对报培训班,因为:
性价比太低。
培训班里真正有实战经验的很少,大部分都是纸上谈兵。
这次咨询也基本印证了我的观点。所以我想再分享一下,到底招聘方的情况是怎样的,他们有哪些需求,准备简历的时候应该注意什么,面试的时候又应该注意什么。
1 企业要招人
1.0 产生需求
某天,老板想做个产品。我们假设公司里已经有靠谱的技术团队和技术管理,那么,技术主管很快就会梳理需求,落实到岗位和个人,如果他发现,目前的人力无法应对满足需求,就会启动招聘。
1.1 产生岗位描述(JD)
岗位描述(简称 JD),即这个岗位职责是什么、需要哪些职业技能、工作地点和福利待遇等,是招聘前必须准备好的物料。
产品确定、需求确定,所以岗位需求和岗位职责基本也是确定的。 此时技术主管一般会找来以前的 JD,改一改职责和需求,完成新的 JD。然后 ta 会把 JD 发给招聘负责人(多半是 HR),上传到招聘网站、开发者社区、公司招聘库等等。
比如 Code.fun 加入我们 就是一份很典型的 JD。
1.2 筛简历
一段时间后,HR、技术主管会从各种渠道获得一大批简历。于是他们就要从这一大堆简历快速筛选出能满足岗位需要的候选人。
怎么筛呢?一般是关键词。 拿我某项工作来举例,我当时负责开发的 Showman 产品,是浏览器插件,界面部分采用 Vue,需要兼容 Puppeteer API。那么在我招聘的时候,就会很重视候选人这几方面的经历。因为匹配度越高,他能顺利接手工作、快速度过适应期的可能性就越大。
找到关键词之后,HR 可能会接受简历,转发给岗位负责人,即初筛。而岗位负责人则会结合候选人的教育经历、职业经理、项目经验等,判断这些关键词的可靠性与含金量,最终再筛选出其中最合适的一些人进入面试环节。
1.3 面试
招聘方从成百上千的简历中筛选出了若干的“看起来”比较合适的候选人,接下来,就要约过来面试聊聊,看看哪些人真正合适。
面试的过程,其实是验证简历的过程。 张三简历里说,他开发过浏览器插件,但是这个插件有多少用户、运营过多久,在开发过程中解决过多少问题,并没有写得非常详细;即使写得很细,也未必跟他有关系。所以作为面试官,我就需要再面试中弄清楚,这项职业经历对他来说,是加分还是减分,甚至是一票否决。
除了验证简历,面试还可以让招聘方初步了解候选人的非职业特性,比如沟通能力、语言概括能力、接人待物能力,等等。这些东西在招聘中占比不大,不过在诸多候选人的技术能力拉不开差距的时候,也会是必要的判断依据。
1.4 多轮面试
单场面试时间有限,通常做不到面面俱到。所以面试通常不止一轮。每个面试官关注的点不一样,比如 A 关注项目经验、B 关注代码实现能力、C 关注职业规划等。最终 ABC 的观点会汇总到一起,给每个候选人一个总评。
接下来,面试进行到一定阶段,总评过关的人数积累到一定数目,公司就会给其中比较出色的几位发 offer,然后就是入职试用转正,略过不谈。
2 我们应该怎么做
2.1 简历要有针对性
正如前文所说,企业收到的简历量很大,筛简历的压力也很大。通常来说,招聘方负责人会花在每个简历上的时间很短,基本上就扫一遍,有必要的关键词就再看仔细一点,没有就直接扔掉。
很多同学只做一套简历,投所有企业所有岗位。在这种情况下希望渺茫:A 公司招数据可视化,B 公司招小程序开发,C 公司主做移动端,三家公司的岗位要求差异很大,一套简历很难覆盖不同公司的不同需求。
有同学说那我简历里把所有技术关键词都写上可以么?很遗憾,招聘方也不是傻子,你的工作年限和项目经验、技术专长不符,也难逃直接扔掉的命运。或者简历太长,重点不突出,要费力查找关键词,招聘方多半也会直接扔掉。
当然,为每家公司单独准备一份简历成本太高,也不现实。所以,推荐的做法是:
准备一份比较通用的简历,不要太长,写上自己最擅长的东西,最能凸显自己特长的经历,用来海投,碰运气。
对自己比较中意、比较重视的公司,单独准备简历,突出该公司招聘岗位需要的知识、技能、项目经验等,专门投递。
同时精投的公司不宜过多,避免面试扎堆,影响准备时间。
2.1.1 特殊技巧
(我再想想要不要写……)
2.2 简历要尽可能真实,面试前也要做好准备
前文也提过,面试是验证简历的过程。能够走到面试这一步,说明招聘方认为候选人的履历可以满足岗位需求,接下来就是要对简历验真,以及判断候选人的发展潜力和综合排名。
所以简历里的内容可以适度美化,但一定不要做假。为什么呢?面试时间有限,面试官不会针对简历中的每一项进行审查,而是对自己关注的、擅长的领域盘问,也就是大概抽查 20% 的内容,给整份简历打分。
如果候选人简历有做假,面试时被面试官发现,ta 可不会只扣这一条的分,而是整份简历都显得不可靠,都要扣分。即使剩下的部分都是真实的,但是没有被抽检到,就不会改变面试官的判断。甚至,如果连问两条都不符合预期,可能就会直接中止面试。
面试前的准备也要尽量做好。比如你参考上一条建议,优化了简历内容,突出以前的某段项目经历以匹配特定关键词。那么这个时候最好回顾一下,审视一下当时的技术方案有何得失,哪里值得改进,自己的工作有何值得称道的地方,等等。然后搜搜看该领域目前的发展状况。不要面试官问起来,这个想不起那个不知道,好好的加分项直接被干成减分项。
2.3 项目经验要择优表现
通常来说,简历不要太长,因为筛简历的人不会有那么多时间认真仔细的读。有人说不要超过一页,我觉得不用这么极端,但是三页绝对是极限了。短简历更容易突出重点、突出优势。
所以通常来说,我们要对项目经验进行取舍,不要把每个项目都罗列出来,即使是海投简历,也要选择会增加自己竞争优势的项目,写到简历里。
比如,某位培训班同学的简历里,介绍 ta 做过的某个全栈项目,混用 MySQL + MangoDB,koa2 + express。这就很奇怪,这两组技术产品定位冲突,在实际生产中,几乎不会混用。所以这样的项目经验就只能减分。还有,在一些同学的简历里看到,他们这两年都还在用 easyui、jquery 做项目,我当然不否认这些传统框架也能完成产品需求,但是写到简历里,就不要指望它们还能帮你加分。
如果,极端情况,你的项目经验都很差,那我建议你抓紧时间参与一些能给自己加分的项目,不管是开源的、商用的、独立项目都可以,别憨憨的写一堆没价值的项目,然后抱怨拿不到面试机会。
2.4 职业经历/项目经历要能让面试官感知到你的优势
很多同学写简历写到职业经历和项目经历时会写的特别平铺直叙、没有重点、缺少关键信息。比如,做过 OA 系统,就把自己负责的模块都列举一下,或者把流程叙述一遍。这样的信息对面试官来说毫无意义:OA 系统大部分人都用过或了解,公司内的工作流程基本也大同小异。这样的简历基本难逃扫一眼直接丢掉的命运。
提升面试官感知有三个方法:
列数字。比如:“我使用了xx方法,使得首页打开速度提升了 40%”,或者“我们把测试覆盖率做到 100%”,等等,让面试官一下就能形成具体认知
举方案。有一些成型的优秀方案,但不是套个库就行,实施起来有一些难度,就很适合写到这里。比如:应用设计模式、分布式多线程、灰度增量,等等。如果能配合上面的“列数字”方法,效果更佳
引用其他人的评价。有时候我们想写数字,但是无奈不负责统计,拿不到数字,乱写又担心被面试官挑战,也可以写别人的评价,比如:“产品总监评价此功能至少带来 5% 的总访问量提升”
提醒大家,如果你要用这个方法吸引招聘方注意,那就要做好相应的准备,避免偷鸡不成蚀把米。比如,你要写数字,就要知道数字是怎么统计出来的;你要写方案,就要写有说服力的方案。
2.5 面试时找机会突出自己的优势
目前来看,招聘方占据优势,是买方市场。招聘方会在众多候选人当中选择最好的几个发出 offer。所以我们在面试时,不仅要证明简历上写的都是真实可靠的,还要抓住机会,展现自己的优势。不然,平平淡淡拿到一个中等分数,可能在招聘方的眼里,只是一块“鸡肋”。
别的岗位就不说了,只说技术开发岗。
通常来说,技术研发,简历外,通常需要在面试中展现的能力主要有:
沟通能力
业务理解能力
主动学习的习惯和能力
积极思考的习惯
解决问题的韧性和积极性
这些条件可能不足以形成一票通过/否决,但会影响你在同一批候选人里的排名,也要尽量好好表现。另外,不同的公司、职级、岗位,可能也有不同的权重,我就不详细解说了。
总结
大家在求职面试时,不仅考虑到自己,也要多多站在招聘方的角度想一想,对方的环境、对方的需求、对方的判断方式,你应该怎么应对。哪些东西可以不写/说,哪些东西应该强调,哪些东西会加分,哪些东西会减分。一件事情做与不做,是这么做还是那样做,一篇文章一个问答,我们是否要照做,都可以用这个方式来判断。
希望大家都能找到满意的工作。有任何想法和意见,也欢迎留言讨论。
本文参与了 SegmentFault 思否征文「如何“反杀”面试官?」,欢迎正在阅读的你也加入。
本文原载于 我的博客,两边同步沟通,欢迎访问。
From: https://segmentfault.com/a/1190000041617937
0 notes
chengxuyuanwenku · 2 years
Text
Apache Hudi 0.7.0 和 0.8.0 新功能已在 Amazon EMR 中可用
Apache Hudi 是一个开源事务性数据湖框架,通过提供记录级插入、更新和删除功能,极大地简化了增量数据处理和数据管道开发。如果您要在 Amazon Simple Storage Service (Amazon S3) 或 HDFS 上构建数据湖,此记录级别功能将非常有用。您可以使用它来遵守数据隐私法规,并简化处理来自流式处理数据源的迟到记录或更新记录的数据提取管道,或者使用更改数据捕获 (CDC) 从事务处理系统提取数据。Apache Hudi 支持与 Apache Spark、Apache Hive、Presto 和 Trino 等开源大数据分析框架集成。它允许您以开放格式(如 Apache Parquet 和 Apache Avro)维护 Amazon S3 或 HDFS 中的数据。
从发行版 5.28.0 开始,Amazon EMR 将在您安装 Spark、Hive、Presto 或 Trino 时默认安装 Hudi 组件。自从将 Apache Hudi 纳入 Amazon EMR 以来,Apache Hudi 已经添加了几项改进和错误修复。Apache Hudi 于 2020 年 6 月被评为顶级 Apache 项目。
在这篇文章中,我们总结了自 Apache Hudi 发行版 0.7.0 和 0.8.0 以来添加的一些关键新特性和功能。自 Amazon EMR 5.33.0 和 6.3.0 发布以来,已推出 Hudi 的以下新特性和功能:
聚类
基于元数据的文件列表
Amazon CloudWatch 集成
Optimistic Concurrency Control
Amazon EMR 配置支持和改进
Apache Flink 集成
Kafka 提交回调
其他改进功能
聚类
我们看看更多需要将高吞吐量引入数据湖的使用场景。但是,更快的数据摄入通常会导致较小的数据文件大小,这往往会对查询性能产生不利影响,因为大量的小文件会增加返回结果所需的成本高昂的 I/O 操作。我们看到的另一个问题是,摄入期间的数据组织与查询数据时效率最高的组织不同。例如,通过 OrderDate 接收电子商务订单很方便,但是在查询时,最好将单个客户的订单存储在一起。
Apache Hudi 0.7.0 版本引入了一项新功能,允许您对 Hudi 表进行聚类。Hudi 中的聚类是一个框架,它提供了一种可插式策略来更改和重组数据布局,同时优化文件大小。借助聚类,您现在可以优化查询性能,而不必权衡数据摄入吞吐量。
您可以根据不同的使用场景要求,通过聚类使用不同的方法来重写数据:
利用数据本地性提高查询性能 – 这会通过对一个或多个用户指定列中的数据进行排序来更改磁盘上的数据布局。通过这种方法,我们可以使用 Parquet 文件格式执行谓词下推并跳过不需要的文件和 Parquet 行组,以提高查询性能。此策略还可以控制文件大小来避免小文件。
提高数据新鲜度 – 此要求假定数据本地性在摄取时并不重要或已得到处理。它非常适合于新鲜数据很重要的使用场景,在这种情况下,使用几个小文件提取数据,然后使用聚类框架进行拼接或合并。
您可以异步或同步运行聚类表服务。它还引入了新的操作类型 REPLACE,用于标识 Hudi 元数据时间轴中的聚类操作。
在以下示例中,我们使用 Amazon EMR 发行版 6.3.0 创建了两个写时复制 (CoW) Hudi 表:amazon_reviews 和 amazon_reviews_clustered。
我们使用 spark-shell 来创建 Hudi 表。通过在 Amazon EMR 主节点上运行以下命令来启动 Spark shell:
spark-shell --conf "spark.serializer=org.apache.spark.serializer.KryoSerializer" --conf "spark.sql.hive.convertMetastoreParquet=false" --jars /usr/lib/hudi/hudi-spark-bundle.jar
然后,我们在不启用聚类的情况下使用 BULK_INSERT 操作创建 Hudi 表 amazon_reviews:
import org.apache.hudi.DataSourceWriteOptions import org.apache.hudi.config.HoodieWriteConfig import org.apache.hudi.HoodieDataSourceHelpers import org.apache.spark.sql.SaveMode val srcPath = "s3://amazon-reviews-pds/parquet/" val tableName = "amazon_reviews" val tablePath = "s3://emr-hudi-test-data/hudi/hudi_080/" + tableName val inputDF = spark.read.format("parquet").load(srcPath) inputDF.write.format("hudi") .option(HoodieWriteConfig.TABLE_NAME, tableName) .option(DataSourceWriteOptions.OPERATION_OPT_KEY, DataSourceWriteOptions.BULK_INSERT_OPERATION_OPT_VAL) .option(DataSourceWriteOptions.TABLE_TYPE_OPT_KEY, DataSourceWriteOptions.COW_TABLE_TYPE_OPT_VAL) .option(DataSourceWriteOptions.RECORDKEY_FIELD_OPT_KEY, "review_id") .option(DataSourceWriteOptions.PARTITIONPATH_FIELD_OPT_KEY, "product_category") .option(DataSourceWriteOptions.PRECOMBINE_FIELD_OPT_KEY, "review_date") .option(DataSourceWriteOptions.HIVE_SYNC_ENABLED_OPT_KEY, "true") .option(DataSourceWriteOptions.HIVE_DATABASE_OPT_KEY, "hudi_test") .option(DataSourceWriteOptions.HIVE_TABLE_OPT_KEY, tableName) .option(DataSourceWriteOptions.HIVE_PARTITION_FIELDS_OPT_KEY, "product_category") .option(DataSourceWriteOptions.HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY, "org.apache.hudi.hive.MultiPartKeysValueExtractor") .mode(SaveMode.Overwrite) .save(tablePath)
然后,我们使用 BULK_INSERT 操作创建 Hudi 表 amazon_reviews_clustered 并内联按列 star_rating 和 total_votes 启用和排序的聚类:
import org.apache.hudi.DataSourceWriteOptions import org.apache.hudi.config.HoodieWriteConfig import org.apache.hudi.config.HoodieClusteringConfig import org.apache.hudi.HoodieDataSourceHelpers import org.apache.spark.sql.SaveMode val srcPath = "s3://amazon-reviews-pds/parquet/" val tableName = "amazon_reviews_clustered" val tablePath = "s3://emr-hudi-test-data/hudi/hudi_080/" + tableName val inputDF = spark.read.format("parquet").load(srcPath) inputDF.write .format("hudi") .option(HoodieWriteConfig.TABLE_NAME, tableName) .option(DataSourceWriteOptions.OPERATION_OPT_KEY, DataSourceWriteOptions.BULK_INSERT_OPERATION_OPT_VAL) .option(DataSourceWriteOptions.TABLE_TYPE_OPT_KEY, DataSourceWriteOptions.COW_TABLE_TYPE_OPT_VAL) .option(DataSourceWriteOptions.RECORDKEY_FIELD_OPT_KEY, "review_id") .option(DataSourceWriteOptions.PARTITIONPATH_FIELD_OPT_KEY, "product_category") .option(DataSourceWriteOptions.PRECOMBINE_FIELD_OPT_KEY, "review_date") .option(HoodieClusteringConfig.INLINE_CLUSTERING_PROP, "true") .option(HoodieClusteringConfig.INLINE_CLUSTERING_MAX_COMMIT_PROP, "0") .option(HoodieClusteringConfig.CLUSTERING_TARGET_PARTITIONS, "43") .option(HoodieClusteringConfig.CLUSTERING_MAX_NUM_GROUPS, "100") .option(HoodieClusteringConfig.CLUSTERING_SORT_COLUMNS_PROPERTY, "star_rating,total_votes") .option(DataSourceWriteOptions.HIVE_SYNC_ENABLED_OPT_KEY, "true") .option(DataSourceWriteOptions.HIVE_DATABASE_OPT_KEY, "hudi_test") .option(DataSourceWriteOptions.HIVE_TABLE_OPT_KEY, tableName) .option(DataSourceWriteOptions.HIVE_PARTITION_FIELDS_OPT_KEY, "product_category") .option(DataSourceWriteOptions.HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY, "org.apache.hudi.hive.MultiPartKeysValueExtractor") .mode(SaveMode.Overwrite) .save(tablePath)
让我们来查询这两个表并验证性能差异。为了验证性能,我们将使用 Spark SQL CLI,后者是一种方便的工具,可以在本地模式下运行 Hive 元存储服务并执行从命令行输入的查询。要启动 Spark SQL CLI,我们执行以下命令:
spark-sql --conf "spark.serializer=org.apache.spark.serializer.KryoSerializer" —conf "spark.hadoop.mapreduce.input.pathFilter.class=org.apache.hudi.hadoop.HoodieROTablePathFilter" —jars /usr/lib/hudi/hudi-spark-bundle.jar
我们在每次运行之间重新启动 Spark SQL CLI (spark-sql) 会话,以避免可能会影响查询性能的缓存或热执行器。
让我们在 spark-sql 接口中运行以下命令,对非聚类 Hudi 表运行查询:
spark-sql> USE hudi_test; spark-sql> select review_id from amazon_reviews where star_rating > 3 and total_votes > 10;
我们还从 spark-sql 接口对聚类表运行同样的查询:
spark-sql> USE hudi_test; spark-sql> select review_id from amazon_reviews_clustered where star_rating > 3 and total_votes > 10;
我们比较两个不同 Hudi 表的基础文件扫描性能。以下屏幕截图是 Spark UI 的输出,其中显示了针对相同数量的输出行扫描的文件中的更改。首先,我们看到为非聚类 Hudi 表扫描的文件。
Tumblr media
接下来,我们看看为聚类 Hudi 表扫描的文件。
Tumblr media
Spark 扫描的文件数量从 1,542 个文件(对于非聚类 Hudi 数据集)减少到 85 个文件(对于完全相同数据的聚类 Hudi 数据集)。此外,扫描的记录数量从 160,796,570 条减少到 78,845,795 条。
我们在 Spark SQL、Hive 和 PrestoDB 间针对 Spark SQL、Hive 和 PrestoDB amazon_reviews(非聚类)和 amazon_reviews_clustered(聚类)比较了上述查询的性能。使用的集群配置是 1 个 leader (m5.4xlarge) 和 2 个内核 (m5.4xlarge)。
以下图表提供了对 Hudi 表(非聚类)和 Hudi 表(聚类)使用不同引擎的查询性能比较。
Tumblr media
我们发现,在为 Hudi 表启用聚类后,所有三个查询引擎的查询性能都有所提高,幅度从 28% 到 63% 不等。下表提供了 Hudi 表的查询性能的详细信息,包括启用和禁用聚类的情况。
查询引擎 非聚簇表 聚簇表 查询运行时改进 时间(以秒为单位) 时间(以秒为单位) Spark SQL 21.6 15.4 28.7 % Hive 96.3 47 51.3 % PrestoDB 11.7 4.3 63.25 %
基于元数据的文件列表
Hudi 写入操作(如压缩、清理和全局索引)以及查询都会执行文件系统列表,以获取数据集中分区和文件的当前视图。对于小型数据集,这应该不会对性能产生重大影响。但是,在处理大数据时,此列出操作可能会在读取文件时对性能产生负面影响。例如,如果将 HDFS 作为底层数据存储,大量文件或分区的列表操作会使 HDFS NameNode 不堪重负,并影响作业的稳定性。在将 Amazon S3 用作底层数据存储的情况下,包含大量文件的 N 个分区的 O(N) 调用非常耗时,还可能导致节流错误。
在 Apache Hudi 0.7.0 版本中,您可以通过为 Hudi 表启用基于元数据的列表来更改此行为。此分区和文件列表存储在内部元数据表中,该表是使用 Hudi Merge on Read (MoR) 表实现的。此元数据表可以充分利用 Hudi MoR 表的所有优势,其中包括低延迟更新功能,以及自动提交元数据更新并在写入失败时轻松回滚的功能。它还使元数据与 Hudi 表保持同步变得容易,因为两者都使用时间轴来实现可追溯性。此文件列表索引使用 HFiles 进行存储,并使用基本和日志文件格式进行增量更新。HFile 格式允许基于记录键对特定记录进行点查找。目标是将对 N 个分区的 O(N) 列表调用减少到 O(1) get 调用以读取元数据。
我们比较了启用元数据清单和未启用元数据清单的 Hudi 数据集的查询性能。在此示例中,我们在 Amazon EMR 发行版 6.3.0 中使用了更大的 3TB 数据集。我们使用以下代码段通过设置 HoodieMetadataConfig.METADATA_ENABLE_PROP (hoodie.metadata.enable) config 来创建已启用和未启用元数据的数据集:
val srcPath = "s3://gbrahmi-demo/3-tb-data_store_sales-parquet/" val tableName = "tpcds_store_sales_3TB_hudi_080" val tablePath = "s3://emr-hudi-test-data/hudi/hudi_080/" + tableName val inputDF = spark.read.format("parquet").load(srcPath) inputDF.write .format("hudi") .option(HoodieWriteConfig.TABLE_NAME, tableName) .option(HoodieMetadataConfig.METADATA_ENABLE_PROP, "true") .option(DataSourceWriteOptions.OPERATION_OPT_KEY, DataSourceWriteOptions.BULK_INSERT_OPERATION_OPT_VAL) .option(DataSourceWriteOptions.TABLE_TYPE_OPT_KEY, DataSourceWriteOptions.COW_TABLE_TYPE_OPT_VAL) .option(DataSourceWriteOptions.RECORDKEY_FIELD_OPT_KEY, "ss_item_sk,ss_ticket_number") .option(DataSourceWriteOptions.PARTITIONPATH_FIELD_OPT_KEY, "ss_sold_date_sk") .option(DataSourceWriteOptions.PRECOMBINE_FIELD_OPT_KEY, "ss_ticket_number") .option(DataSourceWriteOptions.KEYGENERATOR_CLASS_OPT_KEY, "org.apache.hudi.keygen.ComplexKeyGenerator") .option(DataSourceWriteOptions.HIVE_SYNC_ENABLED_OPT_KEY, "true") .option(DataSourceWriteOptions.HIVE_DATABASE_OPT_KEY, "hudi_test") .option(DataSourceWriteOptions.HIVE_TABLE_OPT_KEY, tableName) .option(DataSourceWriteOptions.HIVE_PARTITION_FIELDS_OPT_KEY, "ss_sold_date_sk") .option(DataSourceWriteOptions.HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY, "org.apache.hudi.hive.MultiPartKeysValueExtractor") .mode(SaveMode.Overwrite) .save(tablePath)
在查询引擎方面,我们可以通过以下方法启用它:
Spark 数据源:
spark.read.format("hudi") .option(HoodieMetadataConfig.METADATA_ENABLE_PROP, "true") .load(tablePath + "/*")
Spark SQL CLI:
spark-sql --conf "spark.hadoop.hoodie.metadata.enable=true" --jars /usr/lib/hudi/hudi-spark-bundle.jar
Hive:
hive> SET hoodie.metadata.enable = true;
PrestoDB:
presto:default> set session hive.prefer_metadata_to_list_hudi_files=true;
我们使用以下查询来比较通过 Hive 和 PrestoDB 的查询性能:
select count(*) from tpcds_store_sales_3TB_hudi_080 where ss_quantity > 50;
以下图表提供了查询性能比较。
Tumblr media
我们发现,通过元数据清单,Hive 引擎的查询执行运行时间减少了约 25%,PrestoDB 减少了约 32%。下表提供了带和不带元数据清单的查询执行运行时的详细信息。
查询引擎 禁用元数据 启用元数据 查询运行时改进 时间(以秒为单位) 时间(以秒为单位) Hive 415.28533 310.02367 25.35% Presto 72 48.6 32.50%
元数据清单注意事项
对于 Hudi 0.7.0 和 0.8.0,您可能看不到通过 Spark SQL(含元数据清单)进行查询的明显改进,因为 Hudi 依靠 Spark 的 inMemoryFileIndex 来列出实际文件列表,并且无法使用元数据。您可能会观察到改进,因为 HoodieROPathFilter 使用元数据进行过滤。但是,在 Hudi 0.9.0 版本中,我们为 Hudi 引入了自定义 FileIndex 实现,以使用元数据来列出文件,而不是依赖 Spark。因此,从 0.9.0 开始,您将观察到 Spark SQL 查询的性能显著提高。
Amazon CloudWatch 集成
Apache Hudi 提供了 MetricsReporter 实现,例如 JmxMetricsReporter、MetricsGraphiteReporter 和 DatadogMetricsReporter,您可以使用它们将指标发布到用户指定的接收器。Amazon EMR(其发行版 6.4.0 具备 Hudi 0.8.0)推出了 CloudWatchMetricsReporter,供您向 Amazon CloudWatch 发布这些指标。它有助于发布 Hudi 写入器指标,例如提交持续时间、回滚持续时间、文件级指标(每次提交添加或删除的文件数)、记录级指标(每次提交插入或更新的记录)和分区级指标(每次提交插入或更新的分区)。这在调试 Hudi 作业以及制定集群扩缩决策时非常有用。
您可以通过以下配置启用 CloudWatch 指标:
hoodie.metrics.on = true hoodie.metrics.reporter.type = CLOUDWATCH
下表总结了您可以根据需要更改的其他配置。
配置 描述 值 hoodie.metrics.cloudwatch.report.period.seconds 向 CloudWatch 报告指标的频率(以秒为单位) 默认值为 60 秒,对于 CloudWatch 提供的默认 1 分钟分辨率来说,没有问题 hoodie.metrics.cloudwatch.metric.prefix 要添加到每个指标名称的前缀 默认值为空(无前缀) hoodie.metrics.cloudwatch.namespace 在其中发布指标�� CloudWatch 命名空间 默认值为 Hudi hoodie.metrics.cloudwatch.maxDatumsPerRequest 一次向 CloudWatch 发出的请求中包含的基准数上限 默认值为 20,与 CloudWatch 的默认值相同
以下屏幕截图显示了针对特定 Hudi 表发布的一些指标,包括指标的类型及其名称。这些是 dropwizard 指标;gauge 表示某个时间点的精确值,而 counter 表示一个简单的递增或递减整数。
Tumblr media
下面的 gauge 指标图表示一段时间内写入表的记录总数。
Tumblr media
下面的 counter 指标图表表示随着时间的推移而增加的提交次数。
Tumblr media
Optimistic Concurrency Control
在 Hudi 0.8.0 中引入的一项主要功能是 Optimistic Concurrency Control (OCC),它允许多个写入器同时将数据提取到同一 Hudi 表中,该功能自 Amazon EMR 6.4.0 版本以来一直可用。这是文件级 OCC,这意味着对于同时发生在同一个表中的任意两个提交(或写入器),如果这两个提交(或写入器)没有写入重叠的文件,则允许它们成功。该功能需要获取锁,为此您可以使用 Zookeeper 或 HiveMetaStore。有关所提供保证的更多信息,请参阅并发控制。
Amazon EMR 集群安装了 Zookeeper,您可以将其用作锁提供程序,从同一集群执行并发写入。为方便使用,Amazon EMR 在新推出的 /etc/hudi/conf/hudi-defaults.conf 文件(请参阅下一节)中通过以下属性预配置锁提供程序:
hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.ZookeeperBasedLockProvider hoodie.write.lock.zookeeper.url=<EMR Zookeeper URL> hoodie.write.lock.zookeeper.port=<EMR Zookeeper Port> hoodie.write.lock.zookeeper.base_path=/hudi
尽管锁定提供程序已预先配置,但用户仍然需要通过 Hudi 作业选项或在集群级别通过 Amazon EMR 配置 API 来处理 OCC 的启用:
hoodie.write.concurrency.mode = optimistic_concurrency_control hoodie.cleaner.policy.failed.writes = LAZY (Performs cleaning of failed writes lazily instead of inline with every write) hoodie.write.lock.zookeeper.lock_key = <Key to uniquely identify the Hudi table> (Table Name is a good option)
Amazon EMR 配置支持和改进
Amazon EMR 发行版 6.4.0 引入了通过配置功能配置和重新配置 Hudi 的功能。现在,作业和表中所需的 Hudi 配置可在集群级别通过 hudi-defaults classification or /etc/hudi/conf/hudi-defaults.conf 文件进行配置,类似于 Spark 和 Hive 等其他应用程序。以下代码是启用基于元数据的列表和 CloudWatch 指标的 hudi-defaults 分类的示例。
[{ "Classification": "hudi-defaults", "Properties": { "hoodie.metadata.enable": "true", "hoodie.metadata.insert.parallelism": "3000", "hoodie.metrics.on": "true", "hoodie.metrics.reporter.type": "CLOUDWATCH" } }]
Amazon EMR 会自动为一些配置设置合适的默认值,从而让客户无需传递这些值,以改善用户体验:
HIVE_URL_OPT_KEY 已配置为集群的 Hive 服务器 URL,不再需要指定。这在 Spark 集群模式下运行作业时特别有用,在此模式下,用户以前必须确定并自己指定 Amazon EMR 主 IP。
特定于 HBase 的配置,这些配置对于将 HBase 索引与 Hudi 结合使用非常有用。
如并发控制部分所述,Zookeeper 锁定提供程序特定配置可让您更轻松地使用 OCC。
引入了其他更改,以减少用户需要传递的配置数量,并在可能的情况下自动推断:
现在可以使用 partitionBy API 来指定分区列。
启用 Hive Sync 时,不再需要传递 HIVE_TABLE_OPT_KEY、HIVE_PARTITION_FIELDS_OPT_KEY 或 HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY。这些配置可以从 Hudi 表名和分区字段本身推断出来。
如果您使用的是 SimpleKeyGenerator 或 ComplexKeyGenerator,KEYGENERATOR_CLASS_OPT_KEY 不是强制传递的,并且可以根据有单个还是多个记录键列来推断。
Apache Flink 集成
Apache Hudi 一开始就与 Apache Spark 进行了非常紧密的集成。在 0.7.0 版本中,我们现在利用集成使用 Apache Flink 提取数据。它需要将 Spark 与内部表格格式、写入器和表服务代码分离,以供业内其他不断发展的引擎(如 Flink)使用。
Hudi 0.7.0 通过 HooodieFlinkStreamer 提供初始 Flink 支持,借助它,您可以使用 Apache Flink 流式传输来自 Kafka 主题的数据以编写 CoW 表。例如,您可以使用以下 Flink 命令开始阅读在端口 9092 上运行的 Kafka 代理 broker-1、broker-2 和 broker-3 中的 ExampleTopic 主题:
./bin/flink run -c org.apache.hudi.HoodieFlinkStreamer \ -m yarn-cluster -d -yjm 1024 -ytm 1024 -p 4 -ys 3 \ -ynm hudi_on_flink_example \ /usr/lib/hudi/hudi-flink-bundle.jar \ --kafka-topic ExampleTopic \ --kafka-group-id <kafka-group-id> \ --kafka-bootstrap-servers broker-1:9092,broker-2:9092,broker-3:9092 \ --table-type COPY_ON_WRITE \ --target-table hudi_flink_table \ --target-base-path s3://emr-hudi-test-data/hudi/hudi_070/hudi_flink_table \ --props hdfs:///hudi/flink/config/hudi-jobConf.properties \ --checkpoint-interval 6000 \ --flink-checkpoint-path hdfs:///hudi/hudi-flink-checkpoint-dir
在 Hudi 0.8.0 中,Flink 集成性能和可扩展性有了重大改进,并且引入了新功能,例如用于源和接收器的 SQL 连接器、用于 MoR 的写入器、用于 CoW 和 MoR 的批处理读取器、用于 MoR 的流式传输读取器以及带 Bootstrap 框架支持的状态支持的索引。有关 Flink 集成设计的更多信息,请参阅 Apache Hudi 遇见 Apache Flink。要开始使用 Flink SQL,请参阅 Flink 指南。
Kafka 提交回调
以前的 Apache Hudi 版本 (0.6.0) 引入了写入提交回调功能。有了此功能,Hudi 可以在每次成功提交到 Hudi 数据集时发送回调消息。在以前的版本中,写提交回调支持 HTTP 方法。在 Apache Hudi 0.7.0 版本中,Hudi 现在也支持 Kafka 的写入提交回调。现在,使用 Kafka 为每次成功提交发送��调消息,可以让您在每次 Hudi 数据集看到新提交时构建异步数据管道或业务处理逻辑。现在,您可以构建增量 ETL 管道来处理到达 Hudi 数据湖的新事件。
Kafka 提交回调的实现使用 HoodieWriteCommitKafkaCallback 作为 the hoodie.write.commit.callback.class。除了设置提交回调类之外,您还可以为 Kafka Bootstrap 框架服务器和主题配置设置额外的参数。
以下是一个代码段,写入 Hudi 数据集时,提交回调消息会发布到托管在 Kafka 代理 b-1.demo-hudi.xxxxxx.xxx.kafka.us-east-1.amazonaws.com、b-2.demo-hudi.xxxxxx.xxx.kafka.us-east-1.amazonaws.com 和 b-3.demo-hudi.xxxxxx.xxx.kafka.us-east-1.amazonaws.com 上的 Kafka ExampleTopic 主题:
import org.apache.hudi.QuickstartUtils._ import scala.collection.JavaConversions._ import org.apache.spark.sql.SaveMode._ import org.apache.hudi.DataSourceReadOptions._ import org.apache.hudi.DataSourceWriteOptions._ import org.apache.hudi.config.HoodieWriteConfig._ val tableName = "trips_data_kafka_callback" val tablePath = "s3://gbrahmi-sample-bucket/hudi-dataset/hudi_kafka_callback/" + tableName val dataGen = new DataGenerator(Array("2021/05/01")) val updates = convertToStringList(dataGen.generateInserts(10)) val df = spark.read.json(spark.sparkContext.parallelize(updates, 1)) df.write.format("hudi"). option(TABLE_NAME, tableName). option(PRECOMBINE_FIELD_OPT_KEY, "ts"). option(RECORDKEY_FIELD_OPT_KEY, "uuid"). option("hoodie.write.commit.callback.on", "true"). option("hoodie.write.commit.callback.class", "org.apache.hudi.utilities.callback.kafka.HoodieWriteCommitKafkaCallback"). option("hoodie.write.commit.callback.kafka.bootstrap.servers", "b-1.demo-hudi.xxxxxx.xxx.kafka.us-east-1.amazonaws.com:9092,b-2.demo-hudi.xxxxxx.xxx.kafka.us-east-1.amazonaws.com:9092,b-3.demo-hudi.xxxxxx.xxx.kafka.us-east-1.amazonaws.com:9092"). option("hoodie.write.commit.callback.kafka.topic", "ExampleTopic"). option("hoodie.write.commit.callback.kafka.acks", "all"). option("hoodie.write.commit.callback.kafka.retries", 3). mode(Append). save(tablePath)
以下是这些消息在 Kafka 主题中的显示方式:
{"commitTime":"20210508210230","tableName":"trips_data_kafka_callback","basePath":"s3:// gbrahmi-sample-bucket/hudi-dataset/hudi_kafka_callback/trips_data_kafka_callback"}
下游管道现在可以轻松地从 Kafka 查询这些事件,并将增量数据处理到派生的 Hudi 表中。
Tumblr media
其他改进功能
除了上述改进之外,还有一些其他的变化值得一提。在写入器方面,有以下改进:
支持 Spark 3 – 支持使用 Apache Spark 3 写入和查询数据,从 Apache Hudi 0.7.0 开始提供。这适用于 hudi-spark-bundle 的 Scala 2.12 捆绑。
插入覆盖和插入覆盖表写入操作 – Apache Hudi 0.7.0 引入了两个新操作:insert_overwrite 和 insert_overwrite_table 以支持整个表或分区在每次执行时会被覆盖的批处理 ETL 作业。您可以使用这些操作而非 upsert 操作,而且运行成本必须更低。
删除分区 – 从 0.7.0 开始,新的 API 现在可用于删除整个分区。这有助于避免使用记录级删除。
Java 写入器支持 – Hudi 0.7.0 通过 HoodieJavaWriteClient 类引入了基于 Java 的写入支持。
同样,在查询集成方面,也进行了以下改进:
结构化串流读取 – Hudi 0.8.0 通过 HoodieStreamSource 类引入了 Spark 结构化串流源实现。您可以使用它来支持从 Hudi 表中进行串流读取。
MoR 上的增量查询 – 从 Hudi 0.7.0 开始,我们现在有了对 MoR 表的增量查询支持,您可以使用该查询通过下游应用程序以递增方式提取数据。
结论
借助 Apachi Hudi 中引入的新功能,您能够结合使用 Kafka 提交回调以及 Flink 与 Apache Hudi 的集成和 Amazon EMR 等功能来构建分离的解决方案。您还可以通过使用聚类表和元数据表的功能来提高 Hudi 数据湖的整体性能。
关于作者
Tumblr media
Udit Mehrotra 是 Amazon Web Services 的一名软件开发工程师和 Apache Hudi PMC 成员/提交者。他致力于开发 Amazon EMR 前沿功能,并参与了 Apache Hudi、Apache Spark、Apache Hadoop 和 Apache Hive 等开源项目。闲暇之余,他喜欢弹吉他、旅行、刷剧以及和朋友一起出去玩。
Tumblr media
Gagan Brahmi 是一名解决方案构架师,在 Amazon Web Services 主要从事大数据和分析工作。Gagan 拥有超过 16 年的信息技术行业从业经验。他帮助客户在 AWS 上设计和构建高度可扩展、高性能且安全的基于云的解决方案。
From: https://aws.amazon.com/cn/blogs/china/new-features-from-apache-hudi-0-7-0-and-0-8-0-available-on-amazon-emr/
0 notes
chengxuyuanwenku · 2 years
Text
HMS Core视频编辑服务:AI着色, 忆往昔看今朝
近期热播的电视剧《人世间》,讲述了70年代无数普通人的故事,细腻的人物形象和真实的故事感动着我们。原来在那个年代,我们的父母和祖辈都在为新中国的美好生活而奋斗着,为国家舍弃了小家团聚的机会;原来在那个年代,拥有一张合照也不是容易的事情。
多年来,随着影像技术的迭代更新,人们的多彩生活被即时记录着。同时,给黑白图像增添色彩的技术也层出不穷,HMS Core视频编辑服务便是其一。通过其AI着色能力,可以智能填充黑白照片及视频的色彩,让黑白图像变得鲜活多彩!
当然,除了AI着色能力外,视频编辑服务还提供了专属滤镜、人物跟踪、一键染发、动态图片和人脸遮挡功能。移动应用集成这些能力之后,用户便可以随心复刻心仪图片的滤镜效果,实现百变发色,还可以锁定视频中的特定人物,让静态图片鲜活生动……
除此之外,视频编辑服务还支持多视频/图片的导入,可随时调整片段的顺序时长,实现多分辨率导出,最高支持输出4k的视频分辨率和60fps的帧率。
使用场景:随时随地剪大片
视频编辑服务的功能丰富,可以服务的场景也是各具特色,具体可以使用在以下场景:
视频剪辑:轻松完成视频裁剪、拼接、特效、音乐的处理,快速高效的制作短视频;
旅游出行:实现视频随剪随传,快速简单的制作旅行vlog,分享、记录自己的精彩生活;
社交互动:剪接、特效、滤镜的功能,用户可以随时随地制作精彩大片;
电商产品展示:商家快速剪辑,搭配字幕、特效和背景音乐等元素,让商品特性更加直观立体。
集成方式:多种接口灵活选择
目前,HMS Core为开发者提供了两种���频编辑服务的集成方式:
1.视频编辑UI SDK,提供产品级UI界面,集成简单。
2.视频编辑原子能力SDK,提供数百个底层能力接口,包含多个AI算法能力接口,可根据业务场景灵活选择。
这两种方式均提供导入、编辑、渲染、导出、媒体资源管理等一站式视频编辑能力,提供性能优异、简单易用、高兼容性的接口,帮助您轻松构建应用。您可根据使用场景选择不同的集成方式获取视频编辑能力。
了解更多详情>>
访问华为开发者联盟官网 获取开发指导文档 华为移动服务开源仓库地址:GitHub、Gitee
关注我们,第一时间了解 HMS Core 最新技术资讯~
From: https://segmentfault.com/a/1190000041607999
0 notes
chengxuyuanwenku · 2 years
Text
基于AWS Batch搭建量化回测系统
1.前言
在量化交易策略的开发工作中,需要历史数据来验证交易策略的表现,这种模式称之为回测。历史数据会随着时间的推移增长,策略研究员也会研究新的交易因子,结合交易品种的数量,会催生大量的回测任务计算需求。这种计算任务对于计算资源的需求,非常适合利用云上的弹性计算资源来实现。 本文会介绍一种基于AWS Batch服务建立的量化回测系统,利用AWS Batch服务,可以利用容器化技术,快速调度计算资源,完成回测任务。
2.方案介绍
方案架构图如下所示,用户会使用Sagemaker Jupyter Notebook进行代码编写和任务提交等操作。在这个方案中,用户的回测任务提交只需要以下三个步骤:
将策略代码打包成为docker镜像
推送到托管服务ECR中
提交任务到AWS Batch
AWS Batch会根据提交的参数,自动分配计算资源,下载特定品种的历史数据,回测完成后,上传结果数据到S3存储桶,并自动回收计算资源。
Tumblr media
3.服务介绍
本方案主要使用了AWS Batch作为计算资源的调度服务,要了解方案必须要对AWS Batch的以下几个概念有所了解:
3.1AWS Batch
AWS Batch可帮助运行任意规模的批量计算工作负载,该服务根据工作负载的数量和规模自动预配置计算资源并优化工作负载分配,通过使用AWS Batch,不再需要安装或管理批量计算软件,从而使您可以将时间放在分析结果和解决问题。
compute environment
计算环境是一组用于运行任务的托管或非托管计算资源。使用托管计算环境,您可以在多个详细级别指定所需的计算类型(Fargate 或 EC2)。您可以设置使用特定类型 EC2 实例的计算环境。AWS Batch根据需要高效地启动、管理和终止计算类型。
queue
当您提交AWS Batch作业时,会将其提交到特定的任务队列中,然后作业驻留在那里直到被安排到计算环境中为止。
Job Definition
Job Definition指定作业的运行方式。您可以把任务定义看成是任务中的资源的蓝图。您可以为您的任务提供 IAM 角色,以提供对其他AWS资源的费用。您还可以指定内存和 CPU 要求。任务定义还可以控制容器属性、环境变量和持久性存储的挂载点。任务定义中的许多规范可以通过在提交单个任务时指定新值来覆盖。
Jobs
提交到 AWS Batch 的工作单位 (如 shell 脚本、Linux 可执行文件或 Docker 容器映像)。会作为一个容器化应用程序运行在AWS Fargate或 Amazon EC2 上,使用您在Job Definition中指定的参数。
3.2 SageMaker Notebook实例
Amazon SageMaker Notebook 实例是一个机器学习 (ML) 计算实例,运行 Jupyter Notebook 应用程序。Jupyter Notebook 提供一种网页形式的简单 IDE,可以在网页中交互式地编写代码和运行代码,直接返回逐段代码的运行结果。同时 Notebook 中还可以穿插必要的说明文档和图片,便于对代码进行说明和解释
4.环境准备
为了实验方便,我们推荐使用Cloudformation快速创建环境。在这个环节中,我们将通过预先准备好的 CloudFormation 模板创建实验的基础网络环境和实验资源。通过以下代码下载template.yaml。
curl -LJO https://raw.githubusercontent.com/forhead/build_backtest_with_aws_batch/main/content/template.yaml
通过此链接直接导航到 CloudFormation 控制台创建新堆栈的界面:CloudFormation。
在控制台选择Upload a template file,然后点击Chose file,选择上一步中下载的模板
Tumblr media
上传完成后点击Next
在下一步中,列出了模板所需的参数。在Stack name 选项中填入 backtest,其他参数保持默认,然后点击Next:
直接点击Next到最终的审核步骤
滑到最下方,勾选I acknowledge that AWS CloudFormation might create IAM resources with custom names.,然后点击Create stack按钮:
Tumblr media
大概等待5分钟左右,堆栈创建成功
5.方案实现
下面跟着我们一步步的搭建基于AWS Batch的量化回测方案。
首先执行以下代码,下载backtest.ipynb
curl -LJO https://raw.githubusercontent.com/forhead/build_backtest_with_aws_batch/main/content/backtest.ipynb
打开notebook-instances的链接,找到创建的Notebook实例,选择Open Jupyter
Tumblr media
打开后,点击上传按钮,上传backtest.ipynb文件
Tumblr media
上传完成后,打开Notebook,可以看到以下的界面,点击运行可以执行Notebook中的代码块
Tumblr media
首先执行以下代码,用来定义环境变量
import boto3 aws_account_id = boto3.client('sts').get_caller_identity().get('Account') repository_name = 'backtest-repo' aws_region = 'us-east-1' s3_source = 'backtest-source-2022-03-07' # 用于存储数据源,请按照自己的习惯修改修改名称 s3_dest = 'backtest-dest-2022-03-07' # 用于存储计算结果,请按照自己的习惯修改名称
创建两个S3存储桶,分别用来作为数据源存储股票历史数据,以及存储回测结果
import boto3 s3 = boto3.client('s3',region_name=aws_region) # 创建存储桶 s3.create_bucket(Bucket=s3_source) s3.create_bucket(Bucket=s3_dest) # 确认存储桶创建成功 if s3.head_bucket(Bucket=s3_source)['ResponseMetadata']['HTTPStatusCode']==200: print(s3_source,' created') if s3.head_bucket(Bucket=s3_dest)['ResponseMetadata']['HTTPStatusCode']==200: print(s3_dest,' created')
上传历史数据到S3存储桶
! rm -rf /home/ec2-user/SageMaker/build_backtest_with_aws_batch ! git clone https://github.com/forhead/build_backtest_with_aws_batch.git ! aws s3 sync build_backtest_with_aws_batch/data_source s3://{s3_source}/
因为AWS Batch执行任务基于容器来运行,所以只需要让代码可以接受参数,在参数中定义”历史数据存储桶位置”,”历史数据文件名”以及”结果存储桶位置”。
!mkdir batch %%writefile batch/backtest.py #!/usr/bin/env python from __future__ import (absolute_import, division, print_function, unicode_literals) import datetime import boto3 import json import numpy as np import pandas as pd import os.path import sys import pytz import time from os.path import exists import backtrader as bt class MyStrategy(bt.Strategy): ## 1、全局参数 params=(('maperiod', 15), ('printlog', False),) ## 2、初始化 def __init__(self): # 初始化交易指令、买卖价格和手续费 self.order = None self.buyprice = None self.buycomm = None # 添加15日移动均线指标。Backtrader 集成了 talib,可以自动算出一些常见的技术指标 self.sma = bt.indicators.SimpleMovingAverage(self.datas[0], period=self.params.maperiod) ## 3、策略核心逻辑 def next(self): # 记录收盘价 # self.log('收盘价:%.2f' % self.datas[0].close[0]) if self.order: # 检查是否有指令等待执行 return # 检查是否持仓 if not self.position: # 没有持仓 # 执行买入条件判断:收盘价格上涨突破15日均线 if self.datas[0].close > self.sma[0]: self.size = int(self.broker.cash / self.datas[0].close[0]) self.log('买入委托:%.2f * %.0f' % (self.datas[0].close[0], self.size)) #执行买入 self.order = self.buy(size=self.size) else: # 执行卖出条件判断:收盘价格跌破15日均线 if self.datas[0].close < self.sma[0]: self.log('卖出委托:%.2f * %.0f' % (self.datas[0].close[0], self.size)) #执行卖出 self.order = self.sell(size=self.size) ## 4、日志记录 # 交易记录日志(可选,默认不输出结果) def log(self, txt, dt=None, doprint=False): if self.params.printlog or doprint: dt = dt or self.datas[0].datetime.date(0) print(f'{dt.isoformat()},{txt}') # 记录交易执行情况(可选,默认不输出结果) def notify_order(self, order): # 如果 order 为 submitted/accepted,返回空 if order.status in [order.Submitted, order.Accepted]: return # 如果 order 为 buy/sell executed,报告价格结果 if order.status in [order.Completed]: if order.isbuy(): self.log(f'买入:\n价格:%.2f,\ 现金流:-%.2f,\ 手续费:%.2f' % (order.executed.price, order.executed.value, order.executed.comm)) self.buyprice = order.executed.price self.buycomm = order.executed.comm else: self.log(f'卖出:\n价格:%.2f,\ 现金流:%.2f,\ 手续费:%.2f' % (order.executed.price, order.executed.price*self.size, order.executed.comm)) self.bar_executed = len(self) # 如果指令取消/交易失败, 报告结果 elif order.status in [order.Canceled, order.Margin, order.Rejected]: self.log('交易失败') self.order = None # 记录交易收益情况(可省略,默认不输出结果) def notify_trade(self,trade): if not trade.isclosed: return self.log(f'策略收益:\n毛收益 {trade.pnl:.2f}, 净收益 {trade.pnlcomm:.2f}') # 回测结束后输出结果(可省略,默认输出结果) def stop(self): self.log('(MA均线: %2d日) 期末总资金 %.2f' % (self.params.maperiod, self.broker.getvalue()), doprint=True) def downloadFile(bucket_name, object_name, file_name): s3 = boto3.client('s3',region_name='us-east-1') s3.download_file(bucket_name, object_name, file_name) def uploadFile(file_name,bucket_name, key_name): s3 = boto3.client('s3',region_name='us-east-1') s3.upload_file(file_name,bucket_name, key_name) def readData(file_name): df = pd.read_csv(file_name) df['ticker'] = df['ticker'].apply(lambda x: str(x)) df['ticker'] = df['ticker'].apply(lambda x: '0'*(6-len(x)) + x) df['openprice'] = df['openprice'] * df['accumadjfactor'] / df['accumadjfactor'].iloc[-1] df['closeprice'] = df['closeprice'] * df['accumadjfactor'] / df['accumadjfactor'].iloc[-1] df['highestprice'] = df['highestprice'] * df['accumadjfactor'] / df['accumadjfactor'].iloc[-1] df['lowestprice'] = df['lowestprice'] * df['accumadjfactor'] / df['accumadjfactor'].iloc[-1] df = df[df['isopen'] == True] df.drop('isopen', 1, inplace=True) df.drop('accumadjfactor', 1, inplace=True) df.set_index('tradedate', inplace=True) df.rename(columns={'openprice': 'open'}, inplace=True) df.rename(columns={'closeprice': 'close'}, inplace=True) df.rename(columns={'highestprice': 'high'}, inplace=True) df.rename(columns={'lowestprice': 'low'}, inplace=True) df.rename(columns={'turnovervol': 'volume'}, inplace=True) df['openinterest'] = 0 # A股回测中一般并不考虑利率,通常可以直接设为 0 return df if __name__ == '__main__': # 创建 Cerebro 对象 cerebro = bt.Cerebro() # 读取输入参数,读取s3数据源数据,然后转化为dataframe source_bucket_name = sys.argv[1] source_file_name = sys.argv[2] dest_bucket_name = sys.argv[3] dest_file_name = source_file_name[:-3]+time.strftime("%Y-%m-%d-%H_%M_%S",time.localtime(time.time())) downloadFile(source_bucket_name, source_file_name, source_file_name) while not os.path.exists(source_file_name): time.sleep(5) df = readData(source_file_name) # 创建 Data Feed df.index = pd.to_datetime(df.index) start = df.index[0] end = df.index[-1] print(start, '-', end) data = bt.feeds.PandasData(dataname=df, fromdate=start, todate=end) # 将 Data Feed 添加至 Cerebro cerebro.adddata(data) # 添加策略 Cerebro cerebro.addstrategy(MyStrategy, maperiod=15, printlog=True) # 设置初始资金 cerebro.broker.setcash(100000.0) # 设置手续费为万二 cerebro.broker.setcommission(commission=0.0002) # 在开始时 print 初始账户价值 print('Starting Portfolio Value: %.2f' % cerebro.broker.getvalue()) # 运行回测流程 cerebro.run() # 在结束时写入结果到S3存储桶 f = open(dest_file_name, "a") f.write('Final Portfolio Value: %.2f\n' % cerebro.broker.getvalue()) f.write('Return: %.4f' % (float(cerebro.broker.getvalue())/1e5 - 1)) f.close() uploadFile(dest_file_name,dest_bucket_name,dest_file_name) sys.exit(0)
安装backtrader相关模块
!pip install --upgrade pip !pip install backtrader !pip install matplotlib==3.2.0 !pip show backtrader
验证代码可行性
!python batch/backtest.py {s3_source} 600519.csv {s3_dest} 
除了可以看到大量输出外,还可以在存储结果的S3存储桶(这里是 backtest-dest-2022-03-07)中看到结果文件
Tumblr media
下载后可以看到类似以下的输出:
Final Portfolio Value: 164109.44 Return: 0.6411
创建一个镜像仓库,并推送容器镜像,依次执行notebook中的代码
import boto3 ecr = boto3.client('ecr', region_name=aws_region) ecr.create_repository(repositoryName=repository_name)
创建Dockerfile
%%writefile batch/Dockerfile FROM python:3.8 RUN pip --no-cache-dir install \ backtrader\ boto3 \ pandas RUN pip install matplotlib==3.2.0 ENV PYTHONUNBUFFERED=TRUE ENV PYTHONDONTWRITEBYTECODE=TRUE COPY backtest.py / RUN chmod -R 777 backtest.py
将容器推送到远程的ECR镜像仓库
!docker build batch -t {repository_name} !docker tag {repository_name} {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/{repository_name} !aws ecr get-login-password | docker login --username AWS --password-stdin {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com !docker push {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/{repository_name}
至此,我们已经成功将回测程序容器化,并且推送到ECR的镜像服务器上。打开以下地址 Repositories,可以看到创建的镜像仓库。
Tumblr media
打开 Compute environments,点击Create,创建计算环境。填写计算环境名称 backtest-env
Tumblr media
选择Fargate,其他全部选择默认即可,点击创建,计算环境创建完毕
Tumblr media
创建Job Queue。 选择左侧的Job queues菜单,然后在右边点击Create按钮。
Tumblr media
输出名称,backtest-queue,然后再选择compute environment的下拉框中选择上一步创建的计算环境,点击创建后等待Queue的状态变成VALID。
Tumblr media
创建Job Definition。点击Job definitions,创建任务定义,选择Single-node模式,取名backtest_600519, timeout选择300s
Tumblr media
平台选择Fargate,Execution role选择ecsTaskExecutionRole, 并开启 Assign public IP开关,
Tumblr media
在Repositories找到创建的镜像仓库 backtest-repo,点击进去后拷贝URI地址
Tumblr media
把拷贝的URI地址设置为Image地址,并将执行指令设置到Command中
python backtest.py backtest-source-2022-03-07 600519.csv backtest-dest-2022-03-07
Tumblr media
设置Job Role的执行角色为 ecsTaskExecutionRole,并指定重试次数为一次
Tumblr media Tumblr media
提交任务。选中创建的Job Definition,点击Submit new job,创建任务,如下图所示
Tumblr media
按照以下截图设置任务名称后,其他都设置默认值,提交任务
Tumblr media
在Jobs页面等待任务的状态变成 SUCCEEDED 后,代表任务完成。去S3存储桶查看,可以发现已经有了结果文件
Tumblr media
6.进阶部分
上面创建了基础的AWS Batch所需的环境,并且提交了单个任务。下面我们要实现的是提交多个回测任务,并行计算。有了前面的基础之后,我们再次回到Sage Maker Notebook。 在上面的实验中,在提交任务(Job)的时候,我们可以选择更改Command属性,来覆盖Job Definition中的执行指令。利用这一个特性,可以通过遍历所有已经存在的历史数据文件名,来批量生成Command,提交任务覆盖Job Definition中的Command,在本次实验中,我们可以执行以下代码来批量提交回测任务
import boto3 batch_client = boto3.client('batch') def submit_job(job_name, queue_name, job_definition, command): response = batch_client.submit_job( jobName=job_name, jobQueue= queue_name, jobDefinition=job_definition, containerOverrides={ 'command': command } ) # 在AWS Batch中定义好的任务queue quene_name = 'backtest-queue' # 在AWS Batch中定义好的job definition名 job_definition = 'backtest_strategy_1' # 存储桶名 s3_source = 'backtest-source-2022-03-07' # 用于存储数据源,请按照自己的习惯修改修改名称 s3_dest = 'backtest-dest-2022-03-07' # 用于存储计算结果,请按照自己的习惯修改名称 source_file_list=['600519.csv','600559.csv','600560.csv'] # 循环提交所有的任务,通过复用job definition,覆盖Command的方式提交Job for file in source_file_list: # 依据文件名生成不同的Job任务的执行指令 #"python","backtest.py","backtest-source-2022-03-07","600519.csv","backtest-dest-2022-03-07" command = ["python","backtest.py",s3_source,file,s3_dest] job_name = job_definition + '_for_'+file[:-4] # Job名称为 jobDefinition_for_filename submit_job(job_name,quene_name,job_definition,command)
提交任务后,可以看到提交的三个任务已经成功,并且在S3存储桶中,也有三个结果文件,如下所示:
Tumblr media Tumblr media
7.总结
在本篇文章中,我们基于AWS Batch实现了批量运行Backtest的方案,所有的backtest任务结束后,计算资源都会自动回收,充分利用了云的弹性。 除了在文章中展示的方案内容,我们还可以利用AWS的托管服务实现以下的功能:
基于IAM做了权限的管控和资源隔离
基于SNS做事件通知
基于Lambda定时任务清理Job
基于Cloudwatch做资源使用效率监控,优化资源利用率
本篇作者
Tumblr media
倪赛龙
AWS解决方案架构师,负责基于AWS云计算方案的架构咨询和设计实现,同时致力于无服务计算的应用和推广。
From: https://aws.amazon.com/cn/blogs/china/building-a-quantitative-backtesting-system-based-on-aws-batch/
0 notes
chengxuyuanwenku · 2 years
Text
Amazon Redshift 的新功能 — 2021 年回顾
从客户的需求出发,我们正在投资 Redshift,以在以下三个主要领域推出新功能:
每个人都能轻松进行分析
分析您的所有数据
提供任何规模的性能
客户告诉我们,自己企业中的数据仓库用户正在从管理员、开发人员、分析师和数据科学家扩展到业务线 (LoB) 用户,因此,我们将继续投资,使每个人都能更轻松地使用 Redshift。客户还告诉我们,他们希望摆脱数据孤岛,跨数据湖、数据库和数据仓库访问数据,并使用 SQL 和机器学习 (ML) 分析这些数据。因此,我们将继续投资,让客户分析其所有数据。最后,客户告诉我们,他们希望获得任何规模(从 TB 级到 PB 级数据)分析的最佳性价比。因此,我们将继续针对任何规模的性能推出新功能。接下来,我们将深入探讨其中每一个支柱,并介绍我们在 2021 年推出的关键功能。
Tumblr media
Amazon Redshift 关键创新
Redshift 为所有人提供简单的分析
为所有人提供简单的分析需要更简单的入门体验、自动化可管理性和可视化用户界面,使技术和非技术用户都能更轻松、更快捷地快速入门,在数据仓库中操作和分析数据。我们推出了 Redshift Serverless(预览版)、Query Editor V2 和自动具体化视图(预览版)等新功能,并在 2021 年增强了数据 API,使客户能够更轻松地运行其数据仓库。
Redshift Serverless(预览版)使您可以在几秒钟内轻松运行和扩展分析,而无需预置和管理数据仓库集群。借助无服务器选项,所有用户(包括数据分析师、开发人员、业务用户和数据科学家)只需将数据加载到数据仓库中并进行查询,即可使用 Redshift 在几秒钟内从数据中获取见解。客户只需在 AWS 管理控制台中单击几下,即可启动数据仓库并开始使用 Redshift Serverless 选项分析数据。无需选择节点类型、节点计数或其他配置。客户可以利用预加载的样本数据集和示例查询,立即启动分析。他们可以通过 Amazon Redshift 数据共享从桌面 Amazon Simple Storage Service (S3) 创建数据库、架构和表并加载自己的数据,也可以还原现有的 Amazon Redshift 预置集群快照。此外,还可以直接查询其 Amazon S3 数据湖中开放格式(例如 Parquet 或 ORC)的数据,以及其运营数据库(例如 Amazon Aurora 和 Amazon RDS)中的数据。客户只需按实际用量付费,他们可以通过精细的成本控制来管理成本。
Redshift Query Editor V2 是一款基于 Web 的工具,供数据分析师、数据科学家和数据库开发人员探索、分析和协作处理 Redshift 数据仓库与数据湖中的数据。客户可以使用 Query Editor 的可视化界面来创建和浏览架构与表,加载数据,编写 SQL 查询和存储过程,以及通过图表可视化查询结果。他们可以共享和协作处理查询与分析,并使用内置版本控制功能跟踪更改。Query Editor V2 还支持 SQL Notebook(预览版),它提供新的 Notebook 界面,允许数据分析师和数据科学家等用户编写查询,在单个文档上组织多个 SQL 查询和注释,以及通过共用 Notebook 与团队成员进行协作。
Tumblr media
Amazon Redshift Query Editor V2
长期以来,客户一直将 Amazon Redshift 具体化视图 (MV) 用于基于对一个或多个基表的 SQL 查询的预先计算结果集,以提高查询性能,特别是对于经常使用的查询,例如控制面板和报告中的查询。2021 年,我们推出了预览版自动具体化视图 (AutoMV),通过自动创建和维护具体化视图,无需用户付出任何努力即可提高查询性能(减少总执行时间)。客户告诉我们,虽然 MV 提供了显著性能优势,但对于分析架构、数据和工作负载来确定哪些查询可能从拥有 MV 中受益或哪些 MV 不再受益而应该删除,需要掌握相关知识,投入时间和精力。AutoMV 让 Redshift 持续监控集群以识别候选 MV 并评估收益与成本。它创建的 MV 具有很高的收益成本比,同时确保现有工作负载不会受到此过程的负面影响。AutoMV 会持续监控系统,并删除不再有益的 MV。所有这些对用户和应用程序都是透明的。由于自动查询重写,控制面板等应用程序无需任何代码更改就能受益,这使得现有查询即使在没有显式引用的情况下也能从 MV 中受益。客户还可以将 MV 设置为自动刷新,以便 MV 始终拥有最新数据,从而增加便利性。
客户还要求我们简化和自动执行数据仓库维护任务(例如架构或表设计),以便他们能够从集群中获得最佳性能。在过去几年中,我们投入了大量资金来实现这些维护任务的自动化。例如,自动表格优化 (ATO) 会选择最佳排序和分配键来确定数据的最佳物理布局,从而最大限度地提高性能。我们扩展了 ATO,修改了列压缩编码,以实现高性能并降低存储利用率。在过去几年中,我们还引入了各种功能(例如自动 vacuum 删除和自动分析),以确保客户数据仓库继续以最佳性能运行。
2020 年推出的 Data API 也引入了重要增强功能(例如,多语句查询执行、支持用于开发可重用代码的参数,以及 2021 年更多区域的推出),使客户能够更轻松地以编程方式访问 Redshift 中的数据。借助 Data API,Redshift 使客户能够使用所有类型的传统、云原生、容器化、基于无服务器 Web 服务的应用程序和事件驱动型应用程序轻松访问数据。它简化了 AWS SDK 支持的编程语言和平台(例如 Python、Go、Java、Node.js、PHP、Ruby 和 C++)的数据访问、摄取和输出。使用 Data API,无需配置驱动程序和管理数据库连接。相反,客户只需调用数据 API 提供的安全 API 端点,即可对 Amazon Redshift 集群运行 SQL 命令。Data API 负责管理数据库连接和缓冲数据。Data API 具有异步特性,因此,可以稍后检索结果并将其存储 24 小时。
最后,在每个人都能进行轻松分析这个支柱中,我们于 2021 年推出了 Grafana Redshift Plugin,帮助客户更深入地了解其集群性能。Grafana 是一款深受欢迎的开源工具,用于在线运行分析和监控系统。Grafana Redshift Plugin 允许客户查询系统表和视图,以获取其 Redshift 集群上最完整的运营指标集。该插件在开源 Grafana 存储库以及我们的 Amazon Managed Grafana 服务中提供。我们还发布了默认深度操作控制面板以利用此功能。
Redshift 使客户能够分析其所有数据
Redshift 为客户提供了最佳数据湖和专门构建的数据存储,例如数据库和数据仓库。它使客户能够以低成本以开放、基于标准的数据格式(如 parquet 和 JSON)在数据湖中存储任意数量的数据,并在不加载或转换的情况下对其运行 SQL 查询。此外,它还允许客户使用复杂的查询优化、高性能存储上的列式存储以及大规模并行查询执行,对数 TB 到 PB 级结构化和半结构化数据运行高性能复杂的分析查询。Redshift 允许客户访问事务数据库中的实时数据,将其作为商业智能 (BI) 和报告应用程序的一部分,以实现运营分析。客户可以通过以下方式打破数据孤岛:无缝查询数据湖、数据仓库和数据库中的数据;使团队能够使用自己喜欢的工具或技术运行分析和机器学习;并通过适当的安全和数据治理控制来管理有权访问数据的人员。我们在 2021 年推出了数据共享、AWS Data Exchange 集成和 Redshift ML 等新功能,使客户能够更轻松地分析其所有数据。
借助 Amazon Redshift 数据共享,客户可以将 Amazon Redshift 在单个集群中提供的易用性、性能和成本优势扩展到多集群部署,同时能够共享数据。它支持跨 Amazon Redshift 集群的即时、精细和快速数据访问,而无需复制或移动数据。数据共享提供对数据的实时访问,以便用户在数据仓库更新时始终看到最新且一致的信息。客户可以安全地与同一区域或不同区域内相同或不同 AWS 账户中的 Amazon Redshift 集群共享实时数据。数据共享具有多项性能增强功能(包括结果缓存和并发扩缩),这使客户能够支持更广泛的分析应用程序集,并在查询共享数据时满足关键性能 SLA。客户可以将数据共享用于诸如工作负载隔离之类的使用案例,并提供收费,以及在团队和外部各方内部/之间提供安全且受管控的协作。
客户还要求我们在内外部数据市场上为他们提供帮助,以便他们能够支持使用案例,如数据即服务和板载第三方数据。我们推出了适用于 Amazon Redshift 的 AWS Data Exchange 公开预览版,这是一项新功能,使客户能够在 AWS Data Exchange 中查找和订阅第三方数据,以便他们在几分钟内在 Amazon Redshift 数据仓库中进行查询。数据提供商可以在 AWS Data Exchange 目录中列出和提供包含 Amazon Redshift 数据集的产品,从而授予订阅者对存储在 Amazon Redshift 中数据的直接、只读访问权限。借助此功能,客户能够使用这些第三方数据集快速查询、分析和构建应用程序。适用于 Amazon Redshift 的 AWS Data Exchange 允许客户将在 AWS Data Exchange 中找到的第三方数据与 Amazon Redshift 云数据仓库中的第一方数据合并,而无需 ETL。由于客户直接查询提供商数据仓库,因此,他们可以确定自己使用的是所提供的最新数据。此外,授权、计费和付款管理都是自动进行:在数据订阅开始时授予对 Amazon Redshift 数据的访问权限,在订阅结束时移除此类权限,自动生成发票,并通过 AWS Marketplace 自动收取和支付款项。
客户还要求我们提供帮助,以便轻松地在专用数据存储的数据之上直接训练和部署机器学习模型(例如预测、自然语言处理、对象检测和图像分类),而无需执行复杂的数据移动或学习新工具。我们在今年年初推出了 Redshift ML,使客户能够使用熟悉的 SQL 命令创建、训练和部署机器学习模型。借助 Amazon Redshift ML,客户无需移动数据或学习新技能,即可利用 Amazon SageMaker,这是一项完全托管式机器学习服务。此外,由 Amazon SageMaker 提供支持的 Amazon Redshift ML 允许客户使用 SQL 语句,根据其在 Amazon Redshift 中的数据创建和训练机器学习模型,然后直接在查询和报告中将这些模型用于流失预测和欺诈风险评分等使用案例中。Amazon Redshift ML 会自动发现最佳模型,并使用 Amazon SageMaker Autopilot 根据训练数据对其进行调整。SageMaker Autopilot 在回归、二进制或多类分类模型之间进行选择。或者,客户可以选择特定模型类型(如 Xtreme Gradient Boosted 树 (XGBoost) 或多层感知器 (MLP))、回归或分类之类的问题类型,以及预处理器或超参数。Amazon Redshift ML 使用客户参数在 Amazon Redshift 数据仓库中构建、训练和部署模型。客户可以像调用用户定义函数 (UDF) 一样,使用 SQL 查询从这些经过训练的模型中获得预测,并利用 Amazon Redshift 的所有优势,包括大规模并行处理功能。客户还可以将预先训练的 SageMaker Autopilot、XGBoost 或 MLP 模型导入自己的 Amazon Redshift 集群中,以进行本地推理。对于从预测到个性化的高级分析使用案例,Redshift ML 支持受监督和无监督的机器学习。
客户希望将来自运营数据库的实时数据与 Amazon Redshift 数据仓库中的数据以及 Amazon S3 数据湖环境中的数据结合起来,以获得企业中所有数据的统一分析视图。我们推出了 Amazon Redshift 联合查询,让客户能够将来自事务数据库的实时数据作为其 BI 和报告应用程序的一部分进行整合,从而实现运营分析。Amazon Redshift 中的智能优化器将计算的一部分向下推送并直接分配到远程运营数据库中,以减少通过网络移动的数据,从而帮助提高性能。Amazon Redshift 利用其大规模并行处理功能进一步加快查询的后续执行,对此类执行进行了补充。联合查询还允许客户直接查询运营数据库、动态应用转换以及将数据加载到目标表中,而无需复杂的 ETL 管道,从而更轻松地将数据提取到 Amazon Redshift 中。2021 年,除了现有 Amazon Aurora PostgreSQL 和 Amazon RDS for PostgreSQL 数据库之外,我们还增加了对 Amazon Aurora MySQL 和 Amazon RDS for MySQL 数据库的支持,以便客户通过联合查询访问更多数据源,从而进行更丰富的分析。
最后,在 2021 年的分析所有数据这个支柱中,我们添加了诸如 SUPER、GEOGRAPHY 和 VARBYTE 之类的数据类型,使客户能够将半结构化数据原生存储在 Redshift 数据仓库中,以便他们大规模、高性能地分析所有数据。SUPER 数据类型允许客户摄取 JSON 和半结构化数据,并将其存储在 Amazon Redshift 数据仓库中。Amazon Redshift 还支持 SQL 上 PartiQL 兼容的关系型、半结构化和嵌套数据访问。使用 Amazon Redshift 中的 SUPER 数据类型和 PartiQL,客户可以执行高级分析,将经典结构化 SQL 数据(如字符串、数字和时间戳)与半结构化 SUPER 数据(如 JSON)结合在一起,从而实现卓越的性能、灵活性和易用性。GEOGRAPHY 数据类型基于 Redshift 对空间分析的支持而构建,提供对更多第三方空间和 GIS 应用程序的支持。此外,它还添加了 GEOMETRY 数据类型以及 Redshift 中已有的 70 多种空间函数。GEOGRAPHY 数据类型用于要求具有地理特���的更高精度空间数据结果的查询,这些地理特征可以用地球的球体模型表示,并使用纬度和经度作为空间坐标系统进行引用。VARBYTE 是一种可变大小的数据类型,用于存储和表示可变长度的二进制字符串。
Redshift 提供任何规模的性能
自从我们在 2012 年推出 Amazon Redshift 以来,任何规模的性能一直是我们为成千上万客户创造价值的基本原则,这些客户每天都信任我们,从自己的数据中获取业务见解。我们的客户遍及各个行业,规模不等(从初创公司到财富 500 强企业),我们致力于为任何使用案例提供最佳性价比。多年来,我们推出了一些功能,例如,通过并发扩缩在需要时动态添加集群容量,通过自动工作负载管理 (WLM) 确保高效使用集群资源,以及自动调整数据布局、分配密钥和查询计划以提供给定工作负载的最佳性能。2021 年,我们推出了诸如 AQUA、写入并发扩缩以及进一步增强 RA3 节点等功能,以继续改善 Redshift 的性价比。
我们在 2019 年推出了 RA3 节点类型,作为一项允许独立扩展计算和存储的技术。我们还介绍了包括 Codeacademy、OpenVault、Yelp 和 Nielsen 在内的客户如何利用带有托管存储的 Amazon Redshift RA3 节点来扩展其云数据仓库并降低成本。RA3 利用 Redshift Managed Storage (RMS) 作为其持久存储层,以允许将数据提交回 Amazon S3 的存储容量几乎不受限制。这启用了数据共享和 AQUA 等新功能,在其中,将 RMS 用作跨多个集群的共享存储。RA3 节点有三种尺寸(16XL、4XL 和 XLPlus)可供选择,以平衡性价比。2021 年,我们推出了单节点 RA3 XLPlus 集群,帮助客户经济高效地将其较小的数据仓库工作负载迁移到 RA3,并利用更好的性价比。我们还引入了自助式 DS2 到 RA3 RI 迁移功能,该功能允许以固定成本在同等节点类型之间转换 RI。
Amazon Redshift 的 AQUA (Advanced Query Accelerator) 是一种新的分布式硬件加速缓存,通过自动提升某些查询类型,使 Amazon Redshift 的运行速度比其他企业云数据仓库快一个数量级。AQUA 使用 AWS 设计的处理器和经过调整以加快数据加密和压缩速度的 AWS Nitro 芯片,以及在 FPGA 中实施的自定义分析处理器来加快扫描、筛选和聚合等操作。 AQUA 可用于 RA3.16xLarge、RA3.4xLarge 或 RA3.xlPlus 节点,无需额外付费,也无需更改代码。
并发扩缩于 2019 年推出,旨在处理尖峰和不可预测的读取工作负载,而无需预置任何容量。Redshift 为主集群每运行 24 小时的使用量提供一小时的免费并发扩缩。它还提供成本控制,以监控和限制并发扩缩的使用量与相关成本。除了读取查询之外,支持写入查询一直是客户支持 ETL 工作负载的一项重要要求。2021 年,我们推出了预览版 Redshift 并发扩缩写入查询支持,其中包含 INSERT、DELETE、UPDATE 和 COPY 等常见操作,以处理 ETL 工作负载中不可预测的峰值。如果您当前正在使用并发扩缩,则会在集群中自动启用此新功能。您可以使用 Amazon Redshift 控制台来监控并发扩缩使用情况,并在使用量超出定义的限制时收到警报。您还可以使用 AWS Command Line Interface (CLI) 和 AWS API,以编程方式创建、修改和删除使用限制。
最后,我们将继续确保 AWS 提供全面的安全功能来满足最苛刻的要求,且 Amazon Redshift 将继续提供开箱即用的数据安全性,无需额外费用。我们在 2021 年推出了新的安全功能,例如跨 VPC 支持和默认 IAM 角色,以继续使 Redshift 对客户工作负载更加安全。
总结
在让客户更轻松、更简单、更快地分析其所有数据方面,速度至关重要,我们正在加速创新,为 Redshift 引入新功能。我们将继续在全球更多 AWS 区域推出 Redshift 功能,以确保所有客户都能使用所有功能。我们已经介绍了上述主要功能,您可在此处查看完整列表。我们期待您使用其中一些功能,继续在数据和分析方面进行创新。
关于作者
Tumblr media
Manan Goel 是 AWS 分析服务(包括 Amazon Redshift 和 AWS AQUA)产品上市领导者。他拥有超过 25 年的经验,精通数据库、数据仓库、商业智能和分析。Manan 拥有杜克大学工商管理硕士学位和电子与通信工程学士学位。
From: https://aws.amazon.com/cn/blogs/china/whats-new-in-amazon-redshift-2021-a-year-in-review/
0 notes
chengxuyuanwenku · 2 years
Text
React Router v6 探索
前言
没事翻了翻 React Router 的文档,发现已推到了 v6.2.2 版本,这个版本做了很大的改动,让我们一起看看吧
为什么推出 v6
推出 v6 的最大原因是 React Hooks 的出现
v6 写的代码要比 v5 代码更加紧凑和优雅
我们通过代码来感受下,这是 v6 写的伪代码
import { Routes, Route, useParams } from "react-router-dom"; function App() { return ( <Routes> <Route path="blog/:id" element={<Head />} /> </Routes> ); } function Head() { let { id } = useParams(); return ( <> <Footer /> </> ); } function Footer() { let { id } = useParams(); }
这是 v5 写的伪代码
import * as React from "react"; import { Switch, Route } from "react-router-dom"; class App extends React.Component { render() { return ( <Switch> <Route path="head/:id" render={({ match }) => ( <Head id={match.params.id} /> )} /> </Switch> ); } } class Head extends React.Component { render() { return ( <> <Footer id={this.props.id} /> </> ); } } class Footer extends React.Component { render() { return ( <> <ButtonComponent id={this.props.id} /> </> ); } }
这个例子表明
Hooks 消除了使用 <Route render> 访问路由器内部状态的需要
手动传递 props 将该状态传播到子组件的需要
应用程序包体积更小
增加了哪些特性?
<Switch> 升级为 <Routes>
Routes 内的所有 <Route> 和 <Link> 是相对的。这使得 <Route path> 和 <Link to> 中的代码更精简、更可预测
路由是根据最佳匹配,而不是按顺序遍历,这避免了由于路由不可达而导致的错误
路由可以嵌套在一个地方,而不是分散在不同的组件中
新钩子 useRoutes 代替 react-router-config
之前:
import React, { lazy } from 'react'; import PrivateRoute from '@components/PrivateRoute/index'; const Dashboard = lazy(() => import('@pages/dashboard/index')); const Abount = lazy(() => import('@pages/abount/index')); const routes = [ { path: '/home', component: Dashboard }, { path: '/about', component: Abount }, ]; const RouteWithSubRoutes = route => ( <PrivateRoute path={route.path} component={route.component} routes={route.routes} /> ); const routeConfig = routes.map((route, i) => <RouteWithSubRoutes key={i} {...route} />); export default routeConfig;
现在
function App() { let element = useRoutes([ { path: '/', element: <Home /> }, { path: 'users', element: <Users />, children: [ { path: '/', element: <UsersIndex /> }, { path: ':id', element: <UserProfile /> }, { path: 'me', element: <OwnUserProfile /> }, ] } ]); return element; }
就感觉更优雅一些
用 useNavigate 代替 useHistory
之前
import { useHistory } from "react-router-dom"; function App() { let history = useHistory(); function handleClick() { history.push("/home"); } return ( <div> <button onClick={handleClick}>go home</button> </div> ); }
现在
import { useNavigate } from "react-router-dom"; function App() { let navigate = useNavigate(); function handleClick() { navigate("/home"); } return ( <div> <button onClick={handleClick}>go home</button> </div> ); }
这个变化不是很大
Route 的变化
4.1 <Route exact> 移除,使用 /* 代替
<Route path="/*" element={<Home />} />
`
4.2 <Route children> 使用 <Route element> 代替
import Profile from './Profile'; // v5 <Route path=":userId" component={<Profile />} /> // v6 <Route path=":userId" element={<Profile />} />
4.3 Outlet 我们使用一个 <Outlet> 元素作为占位符。在 <Outlet> 这种情况下,Users 组件如何呈现其子路由。因此,将根据当前位置 <Outlet> 呈现一个 <UserProfile> 或<OwnUserProfile> 元素
4.4
import { BrowserRouter, Routes, Route, Link, Outlet } from 'react-router-dom'; function App() { return ( <BrowserRouter> <Routes> <Route path="/" element={<Home />} /> <Route path="users" element={<Users />}> <Route path="/" element={<UsersIndex />} /> <Route path=":id" element={<UserProfile />} /> <Route path="me" element={<OwnUserProfile />} /> </Route> </Routes> </BrowserRouter> ); } function Users() { return ( <div> <nav> <Link to="me">My Profile</Link> </nav> <Outlet /> </div> ); }
体验 v6
这里我们使用 create-react-app 来创建项目,安装好之后,进入项目,安装 react-router-dom@6 依赖
$ npx create-react-app react-app $ cd react-app $ npm install react-router-dom@6
src/index.js 在编辑器中打开,BrowserRouter 从顶部附近导入 react-router-dom 并将 <APP> 包装在 <BrowserRouter>
// src/index.js import * as React from "react"; import * as ReactDOM from "react-dom"; import { BrowserRouter } from "react-router-dom"; import "./index.css"; import App from "./App"; import * as serviceWorker from "./serviceWorker"; ReactDOM.render( <BrowserRouter> <App /> </BrowserRouter>, document.getElementById("root") );
打开 src/App.js 并用一些路由替换默认标记
// App.js import * as React from "react"; import { Routes, Route, Link } from "react-router-dom"; import "./App.css"; function App() { return ( <div className="App"> <h1>Welcome to React Router!</h1> <Routes> <Route path="/" element={<Home />} /> <Route path="about" element={<About />} /> </Routes> </div> ); }
现在,仍在 src/App.js,创建你的路由组件
// src/App.js function Home() { return ( <> <main> <h2>Home</h2> </main> <nav> <Link to="/about">About</Link> </nav> </> ); } function About() { return ( <> <main> <h2>About</h2> </main> <nav> <Link to="/">Home</Link> </nav> </> ); }
运行 npm start ,您应该会看到 Home 标识
如何升级 v6
官方的迁移指南在这里:React Router v6 迁移指南
参考文章
React Router v6 Preview
React Router
结语
如果你正在用 Hook 重构你的应用,我的建议是可以尝试
重要的事
如果你觉得这篇内容对你挺有启发,别忘记点赞 + 关注
欢迎添加我的个人微信:Jiang9684,一起交流前端技术
我的博客地址
From: https://segmentfault.com/a/1190000041616895
0 notes
chengxuyuanwenku · 2 years
Text
利用Azure MFA 认证者电话应用程序认证Amazon WorkSpaces用户登录
Amazon WorkSpaces 是一个托管的虚拟桌面即服务(DaaS)解决方案。用户可以使用Amazon WorkSpaces来配置Windows或Linux虚拟桌面。
Multi Factor Authentication通过要求用户输入由您的虚拟或硬件MFA解决方案提供的验证码(第二个因素),为用户名和密码(第一个“因素”)增加了一层额外的保护。除非用户提供有效的MFA代码,否则这些因素将通过阻止对AWS服务的访问来提供额外的安全性。
Azure MFA是一种流行的多因素身份验证解决方案,通常是多步骤身份验证MFA的一部分。
Azure MFA提供以下验证形式:
Microsoft Authenticator 电话应用程序(通知或应用程序代码)
OATH硬件令牌
短信
语音通话
在我们的方案中,将Azure MFA与Microsoft Authenticator 应用程序一起使用将提供带外身份验证机制。在这篇文章中,我们将讨论有关配置Aws工作区以用作另一个身份验证因素(一个因素将是AD用户密码),以及使用组织拥有的MS Active Directory目录服务(AD DS)和Microsoft Authenticator 电话应用程序通知来通知Azure MFA的信息。 )。
在执行本文章中详述的任何步骤之前,请确保已部署并配置了“先决条件”下列出的所有要求。
先决条件
具有一个或多个域控制器的现有MS Active Directory域。
现有的Azure AD。
现有的Azure AD Connect将所需的用户帐户同步到Azure AD。
用户在手机上下载了MS Authenticator 应用程序的电话(Android / iOS)。
启用Azure MFA 和 Authenticator 应用程序推送通知。
Amazon WorkSpaces 使用Aws ADConnector 将身份验证代理到AD域中。
已加入域的NPS服务器与安装的Azure MFA扩展一起充当客户拥有的RADIUS服务器。
配置NPS Radius服务器:将Aws目录连接器IP添加为Radius客户端
从Amazon WorkSpaces控制台转到Directories,然后展开您需要MFA的目录。请注意从目录IP地址字段中的两个目录IP地址。
Tumblr media
使用您的随机密码生成器来生成一个随机秘码。这将用作Radius客户端(Aws)与NPS Radius服务器之间的共享密钥。当Radius客户端��Radius服务器对话时,Radius共享秘码用于所有需要隐藏数据的操作。
1. 登录NPS控制台, 在NPS控制台上, 右键单击“ RADIUS客户端和新建”。
Tumblr media
2. 输入一个友好的名称,这将帮助您识别Radius客户端。
3.在“ Aws Directory IP地址”字段中输入您先前记下的第一个IP。
4.对于共享机密,请选择“手动”,并提供先前生成的共享机密。
5.单击确定。
6.对先前在“ Aws目录IP地址”字段中记下的辅助IP重复相同的步骤,以添加第二个Radius客户端。
启用WorkSpaces多重身份验证
1.从Amazon WorkSpaces控制台转到Directories,然后选择需要MFA的Directory,然后展开“Actions”菜单,然后单击“Update Details”。
Tumblr media
2.选中“启用多重身份验证”复选框以启用它。
3.输入以下:
您的NPS服务器IP地址(如果多个)用逗号隔开。
添加用于Radius客户端的NPS上的共享机密。
对于协议,在编写时有四个选择:默认为PAP。
对于服务器超时(以秒为单位),您可以将其增加到最大50(允许的值在1到50之间,这是Aws等待RADIUS服务器响应的时间)。由于使用了超出范围的MFA,因此会增加超时,因此用户将需要一点时间来批准其手机应用程序上的请求,这意味着Radius服务器响应将被延迟。
对于“最大RADIUS请求重试次数”,您可以在0到10之间选择。值1、2或3将起作用。这指定与Radius服务器进行通信尝试的次数。
选择更新或更新并退出。当RADIUS状态更改为“已完成”(Aws测试凭据使用不带密码的用户名(awsfaketestuser),Aws希望Radius服务器发出“拒绝”消息)时,多因素身份验证可用。
PAP支持Azure MFA的所有身份验证方法:电话,单向短信,移动应用程序通知,OATH硬件令牌和移动应用程序验证代码。CHAPV2和EAP支持电话和移动应用通知。
配置NPS Radius服务器:添加连接请求策略
连接请求处理在充当Radius服务器的NPS服务器上进行。该策略将指示它如何识别来自Aws Radius客户端的请求,并在此特定策略下对其进行处理。
该策略还将决定是否执行主要因素身份验证(AD用户凭据)。
1.首先,我们将禁用默认的连接请求和网络策略(以确保它们不与我们自己的重叠)。
Tumblr media Tumblr media
2.现在,我们添加策略。在NPS控制台上,在“ NPS(Local)”>“Policies”上,右键单击“Connection and Request Policies and New”。
3.指定策略名称。
4.在“指定条件”下,向下滚动至“ Radius客户端属性”并添加客户端IPv4Address。此处输入的IP地址将是您先前在Aws Directory IP地址字段中记下的第一个IP。
Tumblr media
5.在“指定连接请求转发”上,选择“接受用户而不验证凭据”。
Tumblr media
6.重复相同的步骤,为您先前在Aws Directory IP地址字段中记录的辅助IP添加另一个策略。
测试WorkSpaces MFA
1.现在,与测试用户建立联系。在我们的测试中,使用的客户端将是Windows客户端版本。WorkSpaces 登录页面将提示用户输入MFA代码。用户在此字段中再次输入其AD密码。
Tumblr media
2.给它几秒钟,您的手机应该会收到通知。���那您可以批准登录。
Tumblr media
通过MFA身份验证后,WorkSpaces 客户端将让您登录到桌面。
总结
在此博客中,我们为您提供了有关如何设置Amazon WorkSpaces MFA电话身份验证的示例。身份验证有很多不同的类型,电话身份验证就是其中之一。我们建议客户启用MFA for WorkSpaces以提供附加的安全桌面访问。
本篇作者
Tumblr media
徐欣蕾
Amazon Web Services公司专业服务团队WorkSpaces顾问。
From: https://aws.amazon.com/cn/blogs/china/utilize-azure-mfa-authenticator-phone-app-2/
0 notes
chengxuyuanwenku · 2 years
Text
使用AWS 托管的普罗米修斯监控SAP HANA
介绍
SAP Solution Manager提供SAP商务套件和OS/DB的监控,很多企业发现Solution Manager 资源占用太重,所以都不愿意轻易部署在云端。AWS发布了Amazon Managed Service for Prometheus (AMP) ,它允许您创建一个完全托管的、安全的、与普罗米修斯(Prometheus) 兼容的环境来摄取、查询和存储 Prometheus 指标,并整合基于云原生的Amazon Managed Grafana,提供轻量级监控,不仅支持监控传统软件,OS/DB,云原生和集群,而且提供大屏。在本文中,我们将演示如何将 AMP 用于这些系统,例如 SAP HANA 在Amazon Elastic Compute Cloud (Amazon EC2)或本地环境上运行的任何其他单体应用。
  设置
在此示例中,我们将执行以下步骤:
使用AWS Launch Wizard for SAP在运行 SUSE Linux 的 EC2 实例上启动 SAP HANA
在 Prometheus 服务器上安装 SAP HANA DB Exporter,并使用 Prometheus 客户端库在/metrics下公开 Prometheus 端点。
创建一个 Amazon Prometheus 服务 (AMP) 工作区。
运行 Prometheus 服务器以通过代理将 SAP HANA 指标导出到 AMP。
在远程桌面上配置 Grafana 服务器以查询我们的 AMP 工作区。您也可以使用我们最近发布的用于 Grafana 的 Amazon Managed Service以查询 AMP。
  对应的架构可以可视化如下:
Tumblr media
图1 – 基于Prometheus的SAP HANA监控架构
  在此示例中,我们选择了美国东部(弗吉尼亚北部)us-east-1 区域。请访问AWS 区域服务列表以查看该服务支持的 AWS 区域。
  Amazone EC2上创建HANA
本演练的第一步是使用AWS Launch Wizard for SAP 创建基于EC2的HANA。
创建好的HANA DB EC2如下:
Tumblr media
  它将托管我们的应用程序并将其指标转发到我们稍后将创建的 AMP 工作区。我们建议使用附加到实例的 IAM 角色,我们可以附加策略AmazonPrometheusRemoteWriteAccess来为实例提供最低限度的权限。
Tumblr media
  SAP HANA DB Exporter安装
配置实例后,我们可以登录到我们的SAP HANA DB实例并安装 SAP HANA 数据库exporter。用 Python 编写的 Prometheus exporter,用于导出 SAP HANA 数据库指标。
  先决条件
一个正在运行且可访问的 SAP HANA 数据库(单容器或多容器)。建议在运行 HANA 数据库的同一台机器上运行exporter。理想情况下,每个数据库都应由一个exporter监控。
作为SAP HANA DB exporter,您有两个选择:
dbapi (SAP/官方)
pyhdb (非官方/开源)
SAP Host 代理在 HANA 监控视图上收集了一些指标。确保已安装并运行它以访问所有监控指标。
指标标文件(Metrics file): exporter使用附加文件来了解将要导出的指标。这里有更多关于指标文件的信息 。
  Exporter安装
可通过以下两种方式可获得对应的exporter:
  方式一:通过RPM获取
在 openSUSE 或 SUSE Linux Enterprise 上使用zypper包管理器:
zypper install prometheus-hanadb_exporter
方式二:采用手动克隆
Exporter是为与 Python3 一起使用而开发的。如果 SUSE linux版本的 repon 中没有Phthon3 ,请遵循Build Python from source 进行创建。
# zypper install git #If the git has not been installed git clone https://github.com/SUSE/hanadb_exporter cd hanadb_exporter # project root folder # pip install virtualenv #If the virtualenv has not been installed virtualenv virt source virt/bin/activate # uncomment one of the next two options (to use hdbcli, you will need to have the HANA client folder where this python package is available) # pip install pyhdb # pip install path-to-hdbcli-N.N.N.tar.gaz pip install . # pip install -e . # To install in development mode # deactivate # to exit from the virtualenv
  如果您愿意,可以将PyHDB SAP HANA 连接器作为RPM包安装(例如 Tumbleweed,但可用于其他版本):
# All the commands must be executed as root user zypper addrepo https://download.opensuse.org/repositories/network:/ha-clustering:/sap-deployments:/devel/openSUSE_Tumbleweed/network:ha-clustering:sap-deployments:devel.repo zypper ref zypper in python3-PyHDB
  配置 Exporter
创建config.json配置文件。 config.json.example中提供的config.json示例。这里配置文件中最重要的项目:
listen_address:prometheus exporter将被暴露的地址(默认为 0.0.0.0)
exposition_port:prometheus exporter将暴露的端口(默认为 9968)
multi_tenant:从其他租户导出指标。要使用它,必须使用系统数据库(端口 30013)完成连接
timeout:连接数据库的超时时间。在这段时间之后,应用程序将失败(即使在守护程序模式下)
hana.host:SAP HANA 数据库的地址
hana.port:暴露 SAP HANA 数据库的端口
hana.userkey:存储的用户密钥。如果您不想在配置文件中包含密码,这是安全选项。如果设置了这两个选项,则用户密钥和用户/密码是第一个默认值
hana.user:拥有 SAP HANA 数据库访问权限的现有用户
hana.password:现有用户的密码
hana.ssl:启用 SSL 连接(默认为 False)。仅适用于 dbapi 连接器
hana.ssl_validate_cert:启用 SSL 证书验证。 HANA 云必填字段。仅适用于 dbapi 连接器
hana.aws_secret_name:包含用户名和密码的秘密名称。如果 SAP HANA 数据库存储在 AWS 上,这是使用 AWS Secrets Manager 的安全选项。 aws_secret_name 和用户/密码是独占的,如果设置了这两个选项,则 aws_secret_name 是默认值
logging.config_file:Python 日志系统配置文件(默认 WARN 和 ERROR 级别的消息将发送到 syslog)
logging.log_file:日志文件(默认为/var/log/hanadb_exporter.log)
  日志配置文件遵循 python 标准日志系统样式: Python logging 。
使用默认配置文件,它将日志重定向到json 配置文件中分配的文件和系统日志(仅记录级别高达警告)。
  使用存储的用户密钥
如果我们想保持数据库安全,这是推荐的选项(对于开发环境,可以使用具有SYSTEM用户的用户/密码,因为它设置起来更快)。要使用userkey选项,必须安装 dbapi(通常存储在/hana/shared/PRD/hdbclient /hdbcli-NNNtar.gz并可以使用 pip3 安装)。它不能从其他不同的客户端使用(密钥存储在客户端本身)。这将引发hdbcli.dbapi .Error : (-10104, ‘Invalid value for KEY’)错误。为此,必须使用运行 python 的用户创建一个新的存储用户密钥。为此(请注意hdbclient与dbapi python 包相同):
/hana/shared/PRD/hdbclient/hdbuserstore set yourkey host:30013@SYSTEMDB hanadb_exporter pass
一些技巧:
将SYSTEMDB设置为默认数据库,这样Exporter将知道从哪里获取租户数据。
不要使用为备份创建的存储用户密钥,因为这是使用sidadm用户创建的。
建议使用只能访问监视表的用户,而不是使用 SYSTEM 用户。
如果使用具有监视角色的用户,则该用户必须存在于所有数据库中( SYSTEMDB+tenants )。
  创建具有监控角色的新用户
运行以下命令以创建具有监视角色的用户(这些命令必须在所有数据库中执行):
su - hdbadm hdbsql -u SYSTEM -p pass -d SYSTEMDB #(HDB for the tenant in this example) CREATE USER HANADB_EXPORTER_USER PASSWORD MyExporterPassword NO FORCE_FIRST_PASSWORD_CHANGE; CREATE ROLE HANADB_EXPORTER_ROLE; GRANT MONITORING TO HANADB_EXPORTER_ROLE; GRANT HANADB_EXPORTER_ROLE TO HANADB_EXPORTER_USER;
  运行Exporter
通过运行以下命令启动Exporter:
hanadb_exporter -c config.json -m metrics.json # Or python3 hanadb_exporter/main.py -c config.json -m metrics.json
如果config.json配置文件存储在/etc/hanadb_exporter中,则Exporter也可以使用以下命令启动:
hanadb_exporter --identifier config # Notice that the identifier matches with the config file without extension
  作为Daemon进程运行
hanadb_exporter可以使用systemd执行。为此,最好的选择是使用 rpm 包安装项目,如安装中所述。
  之后,我们需要创建配置文件/etc/hanadb_exporter/my-exporter.json(文件的名称是相关的,因为我们将使用它来启动守护程序)。 config.json 可以用作示例(示例文件也存储在/usr/etc/hanadb_exporter文件夹中)。
默认指标文件存储在/usr/etc/hanadb_exporter/metrics.json中。 如果新的metrics.json存储在/etc/hanadb_exporter中,这将被使用。
日志配置文件也可以更新以自定义更改新的配置文件logging.config_file条目(默认一个在/usr/etc/hanadb_exporter/logging_config.ini中可用)。
现在,Exporter可以作为守护进程启动。由于我们可以在一台机器上运行多个hanadb_exporter实例,该服务是使用模板文件创建的,因此必须向systemd提供额外的信息(这是在服务名称后添加@关键字和配置文件的名称之前在/etc/hanadb_exporter/{name} .json 中创建):
# All the command must be executed as root user systemctl start prometheus-hanadb_exporter@my-exporter # Check the status with systemctl status prometheus-hanadb_exporter@my-exporter # Enable the exporter to be started at boot time systemctl enable prometheus-hanadb_exporter@my-exporter
  创建 AMP 工作区
要创建工作区,只需在 AWS 控制台上打开 AMP 并输入工作区的名称。
Tumblr media
创建后,该服务应该为我们提供一个远程写入 URL 和一个查询 URL。
Tumblr media
  运行 Prometheus 服务器
要安装最新的稳定版 Prometheus,包括表达式浏览器,请参考Prometheus 指南。在此示例中,我们将在 Amazon Linux 上安装 Prometheus v2.26.0,如下所示:
wget https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz tar -xvf prometheus-2.26.0.linux-amd64.tar.gz sudo cp prometheus-2.26.0.linux-amd64/prometheus /usr/local/bin/
  创建一个名为prometheus.yaml的新文件,并使用 AWS 控制台上的 AMP 工作区中的工作区 ID 编辑remote_write配置。
global: scrape_interval: 15s external_labels: monitor: 'prometheus' scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:8000'] remote_write: - url: https://aps-workspaces.${AWS_REGION}.amazonaws.com/workspaces/${WORKSPACE_ID}/api/v1/remote_write sigv4: region: ${AWS_REGION} queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500
  我们终于准备好运行 Prometheus 并将我们的 SAP HANA 数据库指标发送到 AMP。
prometheus --config.file=prometheus.yml
我们的指标现在正在发送到AMP。您应该在 Prometheus 服务器控制台中看到输出。
  使用 Grafana 可视化指标
Grafana 是一个常用的 Prometheus 指标可视化平台。在本地机器上,让我们安装 Grafana并将我们的 AMP 工作区配置为数据源。
确保本地环境具有以下权限或更多权限以查询工作空间。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "aps:GetLabels", "aps:GetMetricMetadata", "aps:GetSeries", "aps:QueryMetrics" "aps:DescribeWorkspace" ], "Effect": "Allow", "Resource": "*" } ] }
我们将在运行 Grafana 之前启用 AWS SIGv4 身份验证,以便使用 IAM 权限签署对 AMP 的查询。
export AWS_SDK_LOAD_CONFIG=true export GF_AUTH_SIGV4_AUTH_ENABLED=true grafana-server --config=/usr/local/etc/grafana/grafana.ini \ --homepath /usr/local/share/grafana \ cfg:default.paths.logs=/usr/local/var/log/grafana \ cfg:default.paths.data=/usr/local/var/lib/grafana \ cfg:default.paths.plugins=/usr/local/var/lib/grafana/plugin
  登录 Grafana 并转到数据源配置页面/数据源,将您的 AMP 工作区添加为数据源。 URL 最后应该没有/api/v1/query 。
启用SigV4 auth ,然后选择适当的区域并保存。
Tumblr media
  SAP HANA 指标监控
SAP HANA现在应该显示并且可以使用了。
Tumblr media
  总结
在这篇文章中,我们详细介绍了在非容器化环境中使用最近发布的 Amazon Managed Service for Prometheus 并使用 SAP HANA DB Exporter 设置指标收集架构。要在您的 EC2 实例上自动收集指标,您可以使用所有相关的依赖项预配置 AMI,或使用 AWS Systems Manager。从提供的链接中了解有关Amazon Managed Service for Prometheus 、 Amazon Managed Grafana和OpenTelemetry的更多信息。
  版本说明
该博客的AMP版本(截至 2022 年 3月 23日)支持将 Prometheus 指标提取到工作区,以及这些指标的存储和查询。它还支持与 AWS Identity and Access Management、Amazon Virtual Private Cloud 和 AWS CloudTrail 的集成, 支持Tagging, 支持基于规则和报警的管理,详见Amazon Managed Service for Prometheus用户指南。
      本篇作者
Tumblr media
Ryan Yang
AWS 中国专业服务团队云基础架构师,在加入 AWS 之前,曾致力供职于 SAP和生态系统合作伙伴,并有15年以上的SAP大型项目的实施,升级和迁移经验。 现任职于 AWS 中国专业服务团队,主要为客户提供云上系统架构设计,SAP 上云迁移等咨询服务。
From: https://aws.amazon.com/cn/blogs/china/monitoring-sap-hana-with-aws-hosted-prometheus/
0 notes
chengxuyuanwenku · 2 years
Text
利用QuickSight实现AWS精细化成本管理
问题现状
Amazon QuickSight 是一项云规模的商业智能 (BI) 服务。云上成本一直是客户在上云体验中持续关注的方面,对于不管是业务快速发展期,还是成熟稳定期的客户,成本管理始终是工作中的重中之重。对于和AWS打交道多年的企业客户,已经熟悉了Cost Explorer, CUR (Cost & Usage Report) 和Trusted Advisor这些云上成本管理服务的基本使用,逐渐的对于成本管理提出了更多精细化的要求,大中华区企业支持团队在和企业客户的日常沟通和成本优化的工作支持中,越来越发现Quicksight可以有效的助力企业客户管理者从多维度,多视角获取成本现状和优化方向,从而做出有效决策,同时QuickSight内置的如时间聚合,统计函数等功能可以帮助客户从繁重的通过SQL Query语句来获取细粒度资源使用的工作中解脱出来,通过定制化的可视化的QuickSight视图获得精细化成本管理的体验。
QuickSight 常用概念
数据集(DataSet):在数据集层,您可以从不同的来源中提取数据,定义连接条件,应用初步过滤器,为列提供更友好的名称,并准备数据以在分析层中可视化。
分析(Analysis):您可以在分析中分析和可视化数据,完成后,您可以将分析作为仪表板(Dashboard)发布。在单个工作表中支持多达 30 个视觉对象,每个分析限制为 20 个工作表。
视觉对象(Visual):数据的图形化表示,包含字段列表(Fields list)  ,视觉对象类型(Visual types) 等部分。
准备数据源
(1) 在AWS账号中启用了CUR, 并设置了使用Athena查询报告
https://docs.aws.amazon.com/zh_cn/cur/latest/userguide/cur-query-athena.html
(2) 通过“AWS Trusted Advisor Explorer”解决方案将Trusted Advisor中的成本优化数据定期更新到S3并可以为Athena查询
https://aws.amazon.com/solutions/implementations/aws-trusted-advisor-explorer/
巧用QuickSight功能进行精细化管理:
堆积条形图(Stacked Bar Chart)
为每个父维度显示一个条,它在条中使用着色块以显示子维度中的每个项目的相对值。颜色块反映子维度中的每个项目相对于该度量总数的值,堆积条形图使用基于选定度量的最大值的比例。
堆积图案例1:
下图为使用垂直堆积条形图展现近三周内的每周AWS花费,可通过代表不同服务类别的色块的高低看出单周的每个服务的用量趋势:
Tumblr media
其中还利用了QuickSight时间聚合功能,更加灵活展示区间效果:
在分析(Analysis)中选择line_item_usage_start_date作为衡量用量时间的字段,聚合方式点选如Aggregate by Week可以有效展示每周用量的对比,客户有时考虑到按日对比用量代表率不足,按月对比用量时效性不佳,在一些运转频率较快的成本优化项目中会选用按周对比来做每周的成本回顾和决策。
另外,此时间聚合功能包含了“年/季度/月/周/日/时/分/秒“也可以有效的弥补Cost Explorer中只能按照“小时/天/月/”三种聚合维度展示的现状。
Tumblr media
堆积图案例2:
在低利用率资源的总量统计中,利用堆积条形图按照project聚合,可以快速看到每个project各自的低利用率的分布,快速落实到项目负责人进行进一步低利用率资源梳理,且通过足够长时段数据支撑来排除因为新上项目流量未打满从而造成的低利用率场景等:
Tumblr media
KPI (Key Performance Indicator)
使用关键绩效指标 (KPI) 可以直观呈现关键值与其目标值之间的比较。
KPI案例:
利用Trusted Advisor总结出的Monthly Estimated Savings, 可使用KPI显示每月的可节省成本的差值,清楚的显示近期的减少低资源利用的工作进展:
Tumblr media
数据透视表(Pivot Table)
可以使用数据透视表显示两个维度的交集的度量值,包含操作如:对数据透视表行或列中的值进行排序, 应用统计函数,为行和列添加总计和小计。
数据透视表案例1:
统计函数中,我们多会利用Difference和percentDifference函数计算出两个计费周期中的环比增幅,比如添加两个Calculated Field分别为ServiceWoW和ServiceWoW%, 内容分别定义为:
Difference( sum({line_item_unblended_cost}),[{bill_billing_period_start_date}ASC],-1,[{line_item_product_code}]) percentDifference( sum({line_item_unblended_cost}),[{bill_billing_period_start_date}ASC],-1,[{line_item_product_code}])
选择透视表,字段井(Field wells)中添加如下项目:
Tumblr media
点击ServiceWoW,选择“Sort descending”使服务按照cost增量从高到低排序:
Tumblr media
下图即为在透视表类型下单个服务每周用量环比值,将增幅最大的排在最上面,对于增幅较多的服务一目了然:
Tumblr media
通过替换上述示例中的Difference和percentDifference中{line_item_product_code}项目为{line_item_usage_account_id},或者{line_item_usage_type},可轻松获得两个相邻统计时段的账号层面的费用增长,使用类别层面的费用增长,并按需做排序,最可快看到主要增长来源。
数据透视表案例2:
利用ifelse函数实现未打特定tag的资源花费总量统计。
在Analysis中选择添加Calculated Field,名称为emptycost, 利用ifelse函数挑选出没有打上team tag,或者team tag内容为空的资源:
ifelse( (isnull({resource_tags_user_team}) OR {resource_tags_user_team}=''), {line_item_unblended_cost}, 0 )
同时添加另一个Calculated Field, 名称为emptycost%,以百分比形式展示
sum(emptycost)/sum({line_item_unblended_cost})
继续选用透视表类型作为Visual Type, 展示效果如下:
Tumblr media
可以关注到在透视表的行选项中,我们不仅选择了时间度量项,还加上了服务类别product_servicename, 同步实现通过点击时间度量项前面的“+”来展示每个服务的未打tag的cost比例:
Tumblr media
数据透视表案例3:
利用数据透视表计算功能实现未打特定tag的资源花费总量统计,这种方式会将未打team tag (下图中的null项)和打了team tag但是值为空(下图中的empty项)分开显示。
依旧选用透视表, 在Values项目上选择两次line_item_unblended_cost
Tumblr media
点击第二个line_item_unblended_cost, 选择Add table calculation – Percent of Total(Percent of Total 函数计算给定单元格占计算中包含的所有单元格总和的百分比), 利用内置函数功能自动显示成百分比形式。
Tumblr media
再调整resource_tags_user_team排序,Sort by a->z, 使“null”和“empty”显示到最前面:
Tumblr media
最终显示效果:
Tumblr media
相应的,当我们要显示每个服务的没打tag的花费占该服务总花费比例时,除了在Rows侧加上”product_servicename”以外,Values处依旧选择两次line_item_unblended_cost, 点击第二个line_item_unblended_cost,选择Add table calculation – Percent of total, 选择Calculate as – Table across(使用 Table across (表横向) 将沿数据透视表中的行应用计算,而不考虑分组), 从而达到目标。
Tumblr media
最终显示效果:
Tumblr media
结论:
通用巧妙选用视觉对象类型和QuickSight内置的时间聚合,计算函数等功能,可以高效的体现AWS成本增幅,闲置资源来源等,实现精细化成本管理的目标。
本篇作者
Tumblr media
Sunny Fang
AWS技术客户经理,主要支持金融,互联网行业客户的架构优化、成本管理、技术咨询等工作,并专注在大数据和容器方向的技术研究和实践。在加入AWS之前,曾就职于Citrix和微软等科技公司,拥有8年虚拟化与公有云领域的架构优化和支持经验。
From: https://aws.amazon.com/cn/blogs/china/implementing-aws-refined-cost-management-with-quicksight/
0 notes
chengxuyuanwenku · 2 years
Text
新国货美妆品牌数字营销能力升级“三步法”
Tumblr media Tumblr media
受疫情冲击,越来越多国货美妆品牌意识到数字化的重要性,逐渐由“流量思维”转向“用户思维”,纷纷开始试水私域运营,利用数字化工具加强 DTC(Direct-To-Consumer)能力。一方面,借助数字营销为品牌裂变式传播和品效跟踪提供可能;另一方面,为产品研发迭代提供数据驱动的决策依据。
Tumblr media
在神策数据《新国货美妆品牌数字营销研究报告》中,通过研究国货美妆行业线上市场表现情况、消费者趋势,结合数字营销现状及案例剖析,助力国货美妆品牌制胜。接下来将详细拆解数字营销能力升级“三步法”。
一、种草:新国货美妆品牌数字基建、数据分析、内容营销能力升级
在目标人群确定阶段,新国货美妆品牌基于大数据能力,根据不同人群的消费特征、品牌偏好、未来消费预测等,明确现有目标人群和未来目标人群,塑造品牌长期生命力。然后结合市场大数据分析和深入的消费者洞察,切入消费者细分需求,获得消费者青睐,比如红地球以养肤型粉底液出圈。
目前,品牌常用内容渠道覆盖微博、抖音、B 站、小红书、微信、淘宝直播等多个平台,各个平台的用户特征、内容形式和营销重点均有所不同。如下图所示:
Tumblr media
因此,品牌应在遵循数据安全与合规的基础上,找到最符合自身品牌调性、目标人群重合度最高的数字渠道,打造差异化的运营策略。
在具体实践中,基于市场数据洞察,新国货美妆品牌盛行跨界联名,不仅可以打造爆品、促进转化,还能够利用 IP 拓展不同圈层的消费人群,得到 IP 粉丝的关注,为品牌实现高效拉新。美妆产品往往以短平快的方式触达消费者,但越来越多的新国货美妆品牌开始在品牌建设做长期投入,通过创意想法、情感共鸣等视频引发热烈讨论,传递品牌价值主张,实现品效合一。
二、养草:新国货美妆品牌提升私域运营重视度,OMO 是未来品牌制胜决定因素之一
在私域运营场景中,品牌可以与消费者通过门店、电商平台建立链接,也可以与消费者直接链接。现阶段,深耕存量市场的私域流量已经成为新国货美妆品牌发展重点,通过私域运营推动消费者快速决策,并沉淀数字资产,反哺产研、营销策略制定。目前,新国货美妆品牌常用的“钩子”是通过派发小样实现私域拉新、唤醒沉睡用户和促进老客复购等。
但值得强调的是,美妆品牌自带属性决定其离不开线下场景,即使是线上起家的新国货美妆品牌,也有部分开始尝试拓展线下体验店,为消费者提供更好的体验服务。也就是说,新国货美妆品牌利用数字化技术联动线上线下场景,扩大用户覆盖范围,同时补充线上消费体验和提升品牌认知度。
三、拔草:智能技术支撑企业自播,围绕消费者提供全生命周期关怀能帮助品牌占领消费者心智
疫情影响之下,直播带货成为新国货美妆品牌大热的营销手段。除了与头部 KOL 合作外,品牌自播成为新的趋势,有利于和消费者实时互动,形成用户沉淀。
与此同时,依托逐渐成熟的 3D、VR 等智能化技术手段,直播带货玩法也在不断创新。比如某些品牌通过推出虚拟主播实现全天候直播,带有 IP 属性的虚拟主播可以随时为消费者解答产品疑惑,引导消费者在线试妆,带来沉浸式的消费体验。
另外,个保法下,私域的重要性不言而喻,品牌制胜的决定因素之一就是营销策略的制定。因此,建立完善的会员体系,围绕消费者提供全生命周期关怀,与消费者深度链接绑定,将会帮助新国货美妆品牌迅速占领消费者心智。
Tumblr media
综上,基于神策数据提出的企业数字化运营成熟度评估体系,《新国货美妆品牌数字营销研究报告》认为,国货美妆品牌在提升数字化运营能力上应把握完善数据基础能力、建立数据驱动文化、打造数字运营闭环体系三大举措,如下图所示:
Tumblr media
关于神策数据
神策数据(Sensors Data),全称神策网络科技(北京)有限公司,是国内专业的大数据分析和营销科技服务提供商,为企业提供神策营销云、神策分析云、神策数据根基平台三大产品方案,通过全渠道的数据采集与全域用户 ID 打通,全场景多维度数据分析,全通道的精准用户触达,帮助企业实现数字化经营。
神策数据立足大数据及用户行为分析的技术与实践前沿,提出基于数据流的企业运营框架——SDAF,即 Sense(感知)、Decision(决策)、Action(行动)、Feedback(反馈)的数据闭环,并致力为客户打造基于 SDAF 运营框架的数据闭环。业务现已覆盖以互联网、品牌零售、金融、融合媒体、企业服务、高科技、汽车、互联网+ 等为代表的 30 多个主要行业,并可支持企业多个职能部门,目前已服务付费客户 2000 余家。公司总部在北京,并在上海、深圳、合肥、武汉、成都、中国台北等地均拥有本地化的服务团队,覆盖全国及东南亚市场,同时,公司拥有专业的服务团队,为客户提供与营销和大数据相关的咨询、解决方案和专业服务。
Tumblr media
From: http://www.sensorsdata.cn/blog/20220325/
0 notes
chengxuyuanwenku · 2 years
Text
开源码力榜背后的算法模型
中国开源码力榜是由 SegmentFault 思否、开源社、腾源会、X-lab 实验室共同发起的中国开源开发者榜单。
来自 X-Lab 的 OpenDigger 团队对 GitHub 开放的归档日志进行分析,筛选出了 2021 全年 GitHub 协作影响力排名前 10,000 的账号,并号召了社区中数十位开发者及十余家合作社区,通过开放式协作共同核实标注信息、排除机器人账号,并在第一阶段甄选出了 99 位中国开发者。
中国开源码力榜发布后得到了很多开发者的关注,非常多开发者非常关心这个排名是如何产生的,背后的算法模型是什么样的?我们邀请了 OpenDigger 开源项目发起人赵生宇博士写了一篇博客来分享开源码力榜背后的算法模型。
赵生宇是开源社 2022 年度理事,同济大学计算机博士在读,Wuhan2020、OpenDigger 等开源项目发起人,在 2020 年入选中国开源先锋 33 人。
以下内容转载自赵生宇博士的博客《开源码力榜背后的算法模型》
近期与思否合作发布的中国开源码力榜受到了众多开发者的关注,而其中大部分开发者会更加好奇这个排名是如何产生的,背后的算法是什么,为什么有些开发者上榜了,而有些没有。这篇博客就会大家了解一下这个榜单背后的算法,并希望得到大家的一些反馈,可以持续优化该榜单,使其可以更加全面和公正。
开源价值网络
之前的三篇博客已经介绍了一种基于协作数据的开源价值网络的异质图 PageRank 算法,而本次使用的就是仅包含协作数据的 GitHub 全域开发者-项目的价值网络,其结构如下所示:
这是原先设计的价值网络的一个简化版本,没有纳入开发者对项目的关注度关系(star、fork)、开发者之间的关注关系(follow)和项目之间的依赖关系(dependent),主要是考虑到算力的问题,以及某些尚未支持的对于缺失数据的鲁棒问题。
在建立起完整的网络后,我们按月对全域的开发者和项目进行协同排序,并得到所有开发者和项目的价值排名。即我们可以得到 2015 年至今每个月全域中活跃的所有开发者和项目的排名情况,而中国开源码力榜使用的则是 2021 全年的开发者加和数据。
与传统 PageRank 相比
这个算法模型与传统的 PageRank 算法类似,是使用全域的关系数据来进行协同排序,有几个基本的价值主张:
1、越有价值的项目容易吸引到越有价值的开发者来贡献 2、越有价值的项目容易吸引到越多的开发者来贡献 3、越有价值的开发者会在越有价值的项目上活跃
而与传统 PageRank 算法不同的地方在于,在开源价值网络中,不同类型的节点(开发者、项目)的计算方式可以是不同的,而且这个算法引入了先验知识,即节点的固有属性作为一部分参考,而不仅仅使用网络关系的数据。
也就是说:在开源价值网络中,每个月的项目和开发者的价值,将不仅仅取决于开发者和项目当月的活跃情况,也有一部分是继承于上个月的数据,这使得整个算法得到的结果具有非常好的平滑性,而且也是因为我们相信开源的长期价值,是不仅仅依赖当下的情况的。
具体参数
在本次的模型中,我们使用了如下的一些参数:
1、开发者-项目活跃度,使用的是实验室在往年的中国开源年报、GitHub 洞察报告中使用的计算方式,即
$$ A=\sqrt{1 * C_{issue_comment} + 2 * C_{open_issue} + 3 * C_{open_pull} + 4 * C_{pull_review_comment} + 2 * C_{merged_pull}} $$
即 Issue 评论计 1 分,打开新 Issue 计 2 分,提交 PR 计 3 分,PR 上的 review 评论计 4 分,合入 PR 额外计 2 分,最��开方,用以修正过高的活跃度。 2、开发者和项目的初始价值,即第一次开始活跃时的价值均为 1。 3、开发者每个月有 50% 的价值来源于自身的历史价值,50% 来源于当月的开源价值网络。 4、项目每个月有 30% 的价值来源于自身的历史价值,70% 来源于当月的开源价值网络。
常见问题
为什么有些用户量和人气极高的项目作者没有入选,如 Vue 的作者尤大?
其实看完上面的说明,大家就应该明白了,本次的算法主要是以协作关系来计算的,并没有纳入如开源软件的用户数量这样的指标(当然,开源软件用户量一直是非常难以获取的,即便是项目自己可能也无法知道具体的数值)。所以对于那些有大批开发者持续活跃的项目来说,其较有优势,而对于用户量较大的项目,则无法体现,这与使用的数据和模型的参数有极大的关系,尤其是 Vue 是一个以尤大为核心相对独立维护的项目(可参考2019 年 Vue 项目协作网络图)。
为什么有些非常活跃的开发者没有出现在榜单中?
虽然我们对全域的开发者和项目进行的协同排序,但我们没有办法准确知道哪些账号是中国开发者,所以我们花了较大精力进行了人工标注,但依然难免疏漏,目前已经有标注的中国用户清单已沉淀到 OpenDigger 中,可以从这里看到。如果有新的账号希望标注为中国开发者,可以提 Issue给 OpenDigger,合入后之后的计算就会纳入进来。
未来改进
1、引入 star、fork 关系。在本次的榜单中,从算力角度考虑,我们没有引入 star 和 fork 等数据,因为类 PageRank 的迭代类算法的时间复杂度与图密度是正相关的,而 star 这种低成本的操作会使得整个图的密度非常快的提升,从而使运算时间大幅增加,尤其是在对数千万节点的协同排序时。
2、引入开发者之间的 follow 关系。开发者的 follow 关系对于识别开发者 KOL 有很好的指导意义,但这里有一个数学层面的问题,就是在解决不完全数据下的 Rank Sink 问题,目前还没有来得及实现,会考虑引入类似 LeaderRank 的方式来低成本解决单向关系导致的一些问题。
3、项目依赖关系。事实上从用户角度出发,如果无法有效得到用户数量,那么项目的依赖关系是一个非常适合的数据,可以用来标识项目之间的使用关系,尤其在语言生态内会极为有效。但同样有与上述开发者 follow 关系一样的问题,并且还有额外的一些其他工程问题。
以 Node.js 生态为例,已经发布到 npm 的包很好追踪其依赖关系,而只有仓库并未发布制品包的项目,就需要进一步以仓库中 package.json 文件的内容来解析其依赖关系,在全域上做这件事的成本是极高的。
以 Java 生态为例,Maven 中心仓的元数据中并不包含上游仓库地址的信息,所以制品和仓库的关联是较大的问题,而且 Java 的发布策略中,仓库与制品包多对多的情况较多,这使得构建项目依赖关系更加复杂。
如果有同学对上述问题比较熟悉,而且知道如何解决,请一定联系我~~
关于中国开源码力榜
中国开源码力榜是由 SegmentFault 思否、开源社、腾源会、X-lab 实验室共同发起的中国开源开发者榜单。
来自 X-lab 的 OpenDigger 团队对 GitHub 开放的归档日志进行分析,筛选出了 2021 全年 GitHub 协作影响力排名前 10,000 的账号,并号召了社区中数十位开发者及十余家合作社区,通过开放式协作共同核实标注信息、排除机器人账号,第一阶段选出了 99 位中国开发者。
榜单发布后,我们收到社区反馈,新增了一位符合标准的来自中国的“开源码丽”Huan (李卓桓),也请开源世界的每一位开发者通过 Github 项目地址能积极的向我们反馈,我们会不间断的进行更新。
通过中国开源码力榜,我们希望开源世界的超级码丽、开源项目背后的开发者们可以被更多人知道、认识和 respect。让更多人关注开源、关注开源开发者成长。
项目地址: https://github.com/OpenSourceWin
项目官网: http://opensource.win/
From: https://segmentfault.com/a/1190000041604918
0 notes
chengxuyuanwenku · 2 years
Text
业务数字化分析与业务领域建模设计
背景
随着第四次工业革命的蓬勃发展,数字化以其独特的方式和速度给各行各业带来前所未有的变化。它不仅对数字原生企业带来机遇,对于传统行业的冲击更甚。电商的崛起、出行习惯的改变、吃饭和买菜行为的变化都是身边鲜活的例子。数字化能力,尤其是业务数字化分析设计能力,成为传统行业能否在当前赛道上继续保持竞争力的关键。
但是面对一边是错综复杂的业务,一边是陈旧冗余的IT系统,如何让IT系统构建轻量化、弹性化的能力,成为现代业务的最大诉求。
业务数字化面对的挑战
在做业务数字化的过程中,用户不同的行业属性和组织结构,都会在业务数字化分析和建模上带来不同的挑战,但是从需求抽象的层面来看,大致包含以下4类。
从这4类挑战中,我们可以看出,在做业务数字化分析设计的过程中要切中“Alignment(定位)—Analysis(分析)—Abstract(抽象)“三个层面工作。
Alignment(定位)
这是一个提纲挈领的环节,我们更多的是探寻对问题认知的一致性和价值主张的方向,同时在这个过程中达成业务的利益相关方与IT的共识。
Analysis(分析)
这个环节关注在业务过程中用户的“活动轨迹”和他的痛点、痒点,以用户视角进行分析,同时对“活动”中涉及的内外部系统进行捕捉。
Abstract(抽象)
通过对价值主张的理解和业务活动的分析,我们最终要形成对系统能力的构建,而构建的依据就是通过对业务分析中发现的共性业务能力和痛点分类,进行抽象聚合。
如何做业务数字化分析及业务领域建模
这是一个从宏观到具象,从具象到抽象的过程。整个过程要充分运用如设计思维、干系人地图、用户画像、用户旅程等现代化的业务分析工具,同时结合领域驱动设计方法进行业务领域划分。从业务愿景出发到业务领域建模,并找到有价值的最小业务闭环进行模型验证,我们总结了6步分析建模法。
Tumblr media
·       业务愿景对齐
业务开展的首要基础就是愿景的清晰认知和定义。愿景要回答为什么要做这个业务这一根本问题,用来使团队目标一致,对价值主张形成共识。但是如何在短时间内快速拉齐项目干系人对业务愿景的认知,对业务价值所服务的“WHO-WHY-WHAT-HOW”形成明确目标呢?这里我们可以借用“电梯演讲”这一工具,形成思维的快速聚焦和凝练。
那什么是电梯演讲呢?电梯演讲,即elevator pitch, elevator speech,最初是一种宣讲/推销方法。目的是在短时间内(大约30秒到2分钟)向对方介绍/推销一个想法、产品、个人。对于想法、产品,通常会解释who the thing is for(服务对象), what it does(功能描述), why it is needed(用户痛点), and how it will get done(实现路径)。正是由于电梯演讲有其严谨且聚焦的逻辑框架来回答“WHO-WHY-WHAT-HOW”这些核心问题,所以在业务愿景对齐的过程中就可以快速的拉齐相关干系人的价值认知。
通常在这一过程中,我们会通过一个七段式的框架,引导业务干系人进行“发散-收敛”,来聚焦“WHO-WHY-WHAT-HOW”的问题。
Tumblr media
·       业务梳理及痛点分析
在业务梳理和痛点识别的过程中,我们会通过“用户旅程地图”来展开分析。用户旅程开展的前提是对系统用户及业务场景的分析。用户旅程地图的分析会关注以下几个方面:
达成用户目的的完整活动闭环
用户的体验
用户旅程(场景)中的各种接触点
用户达成目标面临的痛点、挑战
Tumblr media
·      业务领域建模
通过对业务涉及的所有用户旅程梳理,及前端触点和后台既有服务能力的分析,进行系统能力的抽象和聚合,构建业务领域模型。在建模过程中,通常依据以下步骤进行构建:
以用户为核心,抽象其系统角色及涉及的业务功能。
对不同用户旅程中涉及到的同类型服务,加以抽象聚合,形成特定的能力中心,确定能力中心职责及边界。
对业务功能相近的能力中心可划分到同一业务功能子域。
根据业务重要性及价值,定义出平台的核心子域、支撑子域、通用子域,结合平台演进路线设计和不同子域的演进方式。
Tumblr media
·      演进路线规划
数字化平台演进路线,一般需遵循业务价值优先(通常会优先覆盖核心域能力),同时兼顾技术实现复杂度的原则,起点通常会从一个有价值的业务场景切入。如果是全新的业务需求,可以微服务化的方式新建场景下的核心域能力;如果是既有业务,可用绞杀者模式对场景下涉及到的核心域能力剥离并微服务化,并随着平台演进的深入,“由点及面”的扩展丰富每一个能力中心。对于支撑域的演进策略,与核心域的思路类似,可依据场景和实现复杂度来进行设计。通用域的能力基于其成熟性和通用性,一般可以采用成熟套件的方式接入,直接使用。
Tumblr media
·      MVP设计
通过用户旅程分析得出的领域建模蓝图,是一个宏观全局化的思考产物,但是如何验证设计内容对实际业务的支持性呢?通常,我们会选取典型业务的典型场景或即将开展的新业务中的某一场景,按照用户旅程的思维结合对应所需的系统能力来设计端到端的完整业务价值闭环,我们把其称之为MVP(Minimal Viable Products),这一过程来贯穿整个领域模型设计。当然,这一过程不可能完全覆盖所有子域的所有能力中心,但是因其场景典型性,通常可理解为其代表了二八原则中八的部分,覆盖度有一定的保证。
对于MVP的选择,建议可以从以下几个方面进行考量:
以核心业务场景为优先,MVP设计要能形成端到端的业务闭环
试点具备一定的独立性,避免选择高耦合的相关系统
覆盖1-2个核心域,具备一定复杂性,验证系统能力可支撑业务实际需求
MVP试点开发周期一般不要超过3个月,可快速验证
适合组建小规模精英团队(2-Pizza Team)
参考文献
https://en.wikipedia.org/wiki/Elevator_pitch
https://en.wikipedia.org/wiki/User_journey
https://aws.amazon.com/blogs/mt/find-your-business-domains-to-start-refactoring-monolithic-applications/
https://aws.amazon.com/blogs/enterprise-strategy/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile-organizations-part-1/
本篇作者
Tumblr media
韩国庆
AWS业务架构师,SAFe SPC认证教练,熟悉领域驱动设计方法(DDD)和现代业务分析方法体系框架,对从产品愿景、用户旅程分析、用户故事地图到业务领域建模设计有丰富的实战经验,曾主导过零售、教育、医疗、社交等领域多个大型业务产品系统的业务架构设计。
Tumblr media
李雪阳
AWS—ProServe Product Manager , 负责ProServe客户的业务分析及产品研究与交付。针对产品全生命周期中所涉及的 用研、创意、原型及交付等均有涉猎,同时也参与帮助客户利用Amazon的能力进行创新咨询与设计。
From: https://aws.amazon.com/cn/blogs/china/business-digital-analysis-and-business-domain-modeling-design/
0 notes