小打卡架构师 申羡
本次分享主要有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
