简介:本次分享主要有4块内容,小打卡介绍,小打卡数仓场景简介,小打卡数仓选型思路以及代表性案例分享。
小打卡架构师 申羡
本次分享主要有4块内容,小打卡介绍,小打卡数仓场景简介,小打卡数仓选型思路以及代表性案例分享。
首先介绍一下小打卡的业务场景,小打卡是当前领先的小程序兴趣社区。在这里能快速发现你感兴趣的圈子,加入圈子,有达人带你玩转各种兴趣,有同好一起分享、一起交流、一起成长。2017年8月公司成立至今,小打卡服务了7000多万用户,聚集绘画、瑜伽、健身、摄影、亲子、阅读、潮玩等品类500多万个兴趣圈子,产生了11亿条内容,11亿次点赞,两亿次评论。每天有数百万用户活跃在小打卡上,产生TB级的数据流入数仓。在这样的场景下,数仓承载了哪些服务呢?
目前小打卡数仓主要支持的场景包括BI商业决策,数字化运营、推荐系统、监控系统等。BI方面,因为DataWorks易用性,结合小打卡业务特点,在复杂决策场景下提供多维立方体数据,业务人员通过QuickBI自由组合关心的维度、指标。简单场景,进行基础的sql培训,帮助业务人员自身闭环,基本实现全员取数分析,极大地提升了工作效率。运营方面,提供分钟级乃至实时的内容审核服务,掐断问题内容过量传播的风险。推荐方面,实现了对用户行为的完整跟踪。结合阿里云实时计算能力,近期完成了推荐系统的实时化,做到用户行为秒级反馈,实现了对前端性能错误的全链路监控,事件级别流量可信度监控,以及核心业务流程的流量波动监控等。在数仓的开发维护中,依托DataWorks完备的工具,包含运维中心,智能监控、数据质量监控、数据管理、数据地图等,以极小的代价实现了所有的需求,以个位数的开发人员满足了500万日活的产品。
在数仓选型时,我们充分调研了自建数仓和基于阿里云构建数仓的优劣。初期小打卡数据量不足100g,每日所需的计算资源不足10cu,对数仓的主要诉求是低费用成本及运维成本,开发敏捷,可扩展性高。于是从费用成本、运维成本、开发效率、灵活性等方面,做了自建数仓和依托阿里云构建数仓的调研。
费用成本方面,阿里云服务特点是初期线性,后期阶梯,初期数据量小,所需计算资源小,适合按量付费,且可以使用阿里云提供的共享资源,成本极低。中后期随着数据量的增加,按量付费的费用上升,可以选用阿里云的计算套餐,购买独享资源。此后费用阶梯化,不同的数据规模选用不同的计算套餐。自建服务,特点是初期重、后期线性,在数仓搭建初期就需要一套完整的服务,有大量的资源不是用于业务计算,费用较高,后期规模上升,需要线性的增长集群规模,费用也线性上升。
运维成本方面,阿里云服务几乎没有运维成本,集群可用性由阿里云保证,不需要自身投入运维,计算任务由可视化的运维中心,任务自动依赖。此外,阿里云可以保证数据安全,提供资源管控,数据治理等一系列的运维工具。自建服务,不管是集群还是任务,都需要较高的运维成本,需要专人持续对集群服务器进行运维,需要使用开源工具,配置任务依赖。复杂的依赖,开发效率低。此外要保证数据安全,进行资源管理等,都需要自己开发一套工具,一次性成本以及持续成本较高。
开发效率方面,阿里云服务提供线上IDE,一站式完成各种任务开发提交部署,非技术人员掌握简单的sql,也能自主取数分析,自建服务需要自己完成任务开发,调度开发、个性开发等,非技术人员很难自主取数分析。
灵活性方面,阿里云服务支持云上弹性扩缩容,灵活方便。虽然早期工具层面的API开放有限,但近期已经开放出大量的API可以灵活的对资源和任务进行操作。自建服务,背靠开源生态,可以灵活的按照自己的需求进行开发,但资源的管理不够灵活便捷,开发成本高。结合以上几点,基于阿里云构建数仓,在开发人员成本,软硬件成本都有明显的优势。从初期直到现在,基于阿里云构建的数仓服务都有极高的消费比。初期只有一个开发人员的情况下,可以快速地搭建起数仓系统,且费用成本极低。
目前每天有TB级的增量数据,数百万DAU,数千个周期任务以及多条业务线,得益于DataWorks完备的工具链,使得开发人员仅需关心业务逻辑,只需个位数的数据团队,就能支撑起全部服务。当然在这个过程中我们也遇到了一些挑战,下面分享一下在数据量突增期间,保障数仓可用性的一些经验以及总结。2月份日活突然翻了三倍,数仓整体产出时间延迟到早上10点以后,为迅速恢复数仓可用,直接将计算资源翻倍。虽然简单粗放,但效果不错,将整体产出时间提前到6:30左右,但核心任务的产出时间无法保证,高峰期计算资源利用率较低,因此必须对任务精细化管理,对资源使用率低的原因进行了定位并解决。
我们先定义了核心任务的判定规则,筛选出符合规则的任务,依托DataWorks运维中心的基线管理机制,将核心任务纳入核心基线,通过基线的优先级,保证核心任务能优先得到资源、稳定产出。高峰期资源使用率较低,是由于使用了DataWorks的默认调度资源组,属于抢占式资源,除了自身任务外,还会受到其他租户的影响,造成任务调度的不及时,不稳定。因此购买了独占式的自定义调度资源组,并将所有任务切换到自定义资源组调度,之后,核心任务可以保证稳定在2点前产出,数仓整体任务能在4:30产出完毕,但我们的数据量是周期性递增,突发性波动的,如何保证数仓可用性问题不再发生,如何保证资源充裕的同时又不过量冗余呢?一方面利用DataWorks提供的资源使用情况可视化监控,结合对数据量变化的监控,资源的使用情况做到了可感知、可预判。另一方面,结合DataWorks提供的元数据表,以及资源优化功能,启动了任务回收机制,改变了数仓任务只增不减,无效任务长期占用资源的现状,但资源组升配仍然需要人工手动操作,这样就会存在资源升级不及时的风险。希望后续可以支持自动弹性调整资源,防止数仓不可用。
下面给大家分享一下小打卡基于实时计算的推荐系统实时化。推荐系统实时化,使数仓具备了用户行为实时反馈,内容特征实时更新,ab效果实时评估,推荐内容实时安全审核,内容质量实时把关等实时化能力。从以前的只能基于一天前的用户行为数据,内容特征数据,为用户提供推荐服务,变成基于秒级延迟的用户行为数据,以及内容特征进行推荐。推荐内容风险审核,也可以从小时级10分钟级进入秒级,业务调整空间,冲破了离线统计的桎梏,可以进行更广阔的尝试。
在推荐实时化后,产品结合实时化的能力,进行了诸多尝试,经过多次迭代后,CTR从5%变成了8%~10%,实现了翻倍的提升。在实时任务开发中,为了提高任务的可用性,实现方式经历了三个阶段,以累计pv实时统计为例。
第一阶段,依靠一个实时计算任务直接计算结果,一旦需要对任务重启,就需要重跑一遍历史全量数据,上游存储介质需要永久存储,追赶的时间很长,且期间提供的数据不可用。
第二阶段,实时任务只计算增量部分,离线任务计算存量部分。再依靠Java服务,将两部分数据整合,开发战线拉得很长。
目前也就是第三阶段,将整合增量数据以及存量数据的任务也交给了流计算处理。第一层流计算,负责计算增量数据。第二层流计算负责整合增量存量数据,也因此实时计算任务有了级联关系,但目前实时计算开发平台,将所有的任务平铺管理,在某些需要对级联任务统一运维的场景支持不太友好,希望后续可以支持可视化的依赖管理,以及级联运维的,我们能迅速尝试并落地实施数仓,得益于 Flink sql 强大的能力。
目前我们的流计算任务百分百使用 Flink sql 开发完成,暂未涉及到 Flink sql 解决不了的场景。
谢谢大家!
更多大数据客户实战案例:https://developer.aliyun.com/article/772449
原文链接:https://developer.aliyun.com/article/777583?
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。