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