写点什么

典型的数据湖应用案例

  • 2022 年 7 月 19 日
  • 本文字数:4142 字

    阅读完需:约 14 分钟

典型的数据湖应用案例

1. 广告数据分析

近年来,流量获取的成本就越来越高,线上渠道获客成本的成倍增长让各行各业都面临着严峻的挑战。在互联网广告成本不断攀升的大背景下,以花钱买流量拉新为主要的经营策略必然行不通了。流量前端的优化已成强弩之末,利用数据工具提高流量到站后的目标转化,精细化运营广告投放的各个环节,才是改变现状更为直接有效的方式。说到底,要提高广告流量的转化率,必须依靠大数据分析。


为了能够提供更多的决策支撑依据,需要采取更多的埋点数据的收集和分析,包括但不限于渠道、投放时间、投放人群,以点击率为数据指标进行数据分析,从而给出更好的、更迅速的方案和建议,实现高效率高产出。因此,面对广告投放领域多维度、多媒体、多广告位等结构化、半结构化和非结构化数据采集、存储、分析和决策建议等要求,数据湖分析产品解决方案在广告主或者发布商进行新一代技术选型中上受到了很热烈的青睐。


DG 是一家全球领先的企业国际化智能营销服务商,基于先进的广告技术、大数据和运营能力,为客户提供全球高质量用户获取及流量变现服务。DG 从成立之初就决定以公有云为基础来构建其 IT 基础设施,最初 DG 选择了 AWS 云平台,主要将其广告数据在 S3 中以数据湖的形态进行存放,通过 Athena 进行交互式分析。然而随着互联网广告的飞速发展,广告行业带来了几大挑战,移动广告的发布与追踪系统必须解决几个关键问题:


  1. 并发性与峰值问题。在广告行业,流量高峰时常出现,瞬间的点击量可能达到数万,甚至数十万,这就要求系统具备非常好的可扩展性以快速响应和处理每一次点击

  2. 如何实现对海量数据的实时分析。为了监控广告投放效果,系统需要实时对用户的每一次点击和激活数据进行分析,同时把相关数据传输到下游的媒体;

  3. 平台的数据量在急剧增长,每天的业务日志数据在持续的产生和上传,曝光、点击、推送的数据在持续处理,每天新增的数据量已经在 10-50TB 左右,对整个数据处理系统提出了更高的要求。如何高效地完成对广告数据的离线/近实时统计,按照广告客户的维度要求进行聚合分析。


针对上述三点业务挑战,同时 DG 这个客户日增量数据正在急剧变大(当前日数据扫描量达到 100+TB),继续在 AWS 平台使用遇到 Athena 读取 S3 数据带宽瓶颈、数据分析滞后时间越来越长、为应对数据和分析需求增长而急剧攀升的投入成本等,经过认真、仔细的测试和分析,最终决定从 AWS 云平台全量搬站到阿里云平台,新架构图如下:



从 AWS 搬站到阿里云后,我们为该客户设计了“利用 Data Lake Analytics + OSS”极致分析能力来应对业务波峰波谷。一方面轻松应对来自品牌客户的临时分析。另一方面利用 Data Lake Analytics 的强大计算能力,分析按月、季度广告投放,精确计算出一个品牌下面会有多少个活动,每个活动分媒体,分市场,分频道,分 DMP 的投放效果,进一步增强了加和智能流量平台为品牌营销带来的销售转化率。


并且在广告投放与分析的总拥有成本上,Data Lake Analytics 提供的 Serverless 的弹性服务为按需收费,不需要购买固定的资源,完全契合业务潮汐带来的资源波动,满足弹性的分析需求,同时极大地降低了运维成本和使用成本。



总体上,DG 从 AWS 切换到阿里云后,极大地节省了硬件成本、人力成本和开发成本。由于采用 DLA serverless 云服务,DG 无需先期投入大量的资金去购买服务器、存储等硬件设备,也无需一次性购买大量的云服务,其基础设施的规模完全是按需扩展:需求高的时候增加服务数量,需求减少的时候减少服务数量,提高了资金的利用率。


使用阿里云平台带来的第二个显著好处是性能的提升。在 DG 业务的快速增长期以及后续多条业务线接入期,DG 在移动广告系统的访问量经常呈爆发式增长,然而原先 AWS 方案和平台在 Athena 读取 S3 数据遇到数据读取带宽的极大瓶颈,数据分析的时间变得越来越长,阿里云 DLA 联合 OSS 团队等进行了极大的优化和改造,同时,DLA 数据库分析在计算引擎上(与 TPC-DS 打榜世界第一的 AnalyticDB 共享计算引擎)比 Presto 原生计算引擎的能力提升数十倍性能,也极大的为 DG 提升了分析性能。

2. 游戏运营分析

数据湖是一类 TCO 表现极其优秀的大数据基础设施。对于很多快速增长的游戏公司而言,一个爆款游戏,往往在短期内相关数据增长极快;同时,公司的研发人员的技术栈很难在短期内与数据的增量和增速进行匹配;此时,呈爆发增长的数据很难被有效利用。数据湖是一个解决此类问题的技术选择。


YJ 是一家高速成长的游戏公司,公司希望能依托相关用户行为数据进行深入分析,指导游戏的开发和运营。数据分析背后的核心逻辑在于随着游戏行业市场竞争局面的扩大,玩家对于品质的要求越来越高,游戏项目的生命周期越来越短,直接影响项目的投入产出比,通过数据运营则可以有效的延长项目的生命周期,对各个阶段的业务走向进行精准把控。


而随着流量成本的日益上升,如何构建经济、高效的精细化数据运营体系,以更好的支撑业务发展,也变得愈发重要起来。数据运营体系就需要有其配套的基础支撑设施,如何选择这类基础支撑设施,是公司技术决策者需要思考的问题。思考的出发点包括:


  1. 要有足够的弹性。对于游戏而言,往往就是短时间爆发,数据量激增;因此,能否适应数据的爆发性增长,满足弹性需求是一个重点考量的点;无论是计算还是存储,都需要具备足够的弹性。

  2. 要有足够的性价比。对于用户行为数据,往往需要拉到一个很长的周期去分析去对比,比如留存率,不少情况下需要考虑 90 天甚至 180 天客户的留存率;因此,如何以最具性价比的方式长期存储海量数据是需要重点考虑的问题。

  3. 要有够用的分析能力,且具备可扩展性。许多情况下,用户行为体现在埋点数据中,埋点数据又需要与用户注册信息、登陆信息、账单等结构化数据关联分析;因此,在数据分析上,至少需要有大数据的 ETL 能力、异构数据源的接入能力和复杂分析的建模能力。

  4. 要与公司现有技术栈相匹配,且后续利于招聘。对于 YJ,其在技术选型的时候一个重要点就是其技术人员的技术栈,YJ 的技术团队大部分只熟悉传统的数据库开发,即 MySQL;并且人手紧张,做数据运营分析的技术人员只有 1 个,短时间内根本没有能力独立构建大数据分析的基础设施。从 YJ 的角度出发,最好绝大多数分析能够通过 SQL 完成;并且在招聘市场上,SQL 开发人员的数量也远高于大数据开发工程师的数量。针对客户的情况,我们帮助客户对现有方案做了改造。



改造前,客户所有的结构化数据都在一个高规格的 MySQL 里面;而玩家行为数据则是通过 LogTail 采集至日志服务(SLS)中,然后从日志服务中分别投递到 OSS 和 ES 里。这个架构的问题在于:


  1. 行为数据和结构化数据完全割裂,无法联动分析;

  2. 对于行为数据智能提供检索功能,无法做深层次的挖掘分析;

  3. OSS 仅仅作为数据存储资源使用,并没有挖掘出足够的数据价值。


事实上,我们分析客户现存架构其实已经具备了数据湖的雏形:全量数据已经在 OSS 中保存下来了,现在需要进一步补齐客户对于 OSS 中的数据的分析能力。而且数据湖基于 SQL 的数据处理模式也满足客户对于开发技术栈的需求。综上,我们对客户的架构做了如下调整,帮助客户构建了数据湖。



总体上,我们没有改变客户的数据链路流转,只是在 OSS 的基础上,增加了 DLA 组件,对 OSS 的数据进行二次加工处理。DLA 提供了标准 SQL 计算引擎,同时支持接入各类异构数据源。基于 DLA 对 OSS 的数据进行处理后,生成业务直接可用的数据。但是 DLA 的问题在于无法支撑低延迟需求的交互式分析场景,为了解决这个问题,我们引入了云原生数据仓库 ADB 来解决交互式分析的延迟性问题;同时,在最前端引入 QuickBI 作为客户的可视化分析工具。YJ 方案是图 14 所示的湖仓一体化解决方案在游戏行业的一个经典落地案例。


YM 是一家数据智能服务提供商,面向各类中小商家提供一系列数据分析运营服务。具体实现的技术逻辑如下图所示。



平台方提供多端 SDK 供用户(商家提供网页、APP、小程序等多种接入形式)接入各类埋点数据,平台方以 SaaS 的形式提供统一的数据接入服务和数据分析服务。商家通过访问各类数据分析服务来进行更细粒度的埋点数据分析,完成行为统计、客户画像、客户圈选、广告投放监测等基本分析功能。然而,这种 SaaS 模式下,会存在一定的问题:


  1. 由于商家类型和需求的多样化,平台提供 SaaS 类分析功能很难覆盖所有类型的商家,无法满足商家的定制化需求;如有些商家关注销量,有些关注客户运营,有些关注成本优化,很难满足所有的需求。

  2. 对于一些高级分析功能,如依赖于自定义标签的客户圈选、客户自定义扩展等功能,统一的数据分析服务无法满足的;特别是一些自定义的标签依赖于商家自定义的算法,无法满足客户的高级分析需求。

  3. 数据的资产化管理需求。在大数据时代,数据是一个企业/组织的资产已经成为了大家的共识,如何能让属于商家的数据合理、长期的沉淀下来,也是 SaaS 服务需要考虑的事情。


综上,我们在上图的基本模式上引入了数据湖模式,让数据湖作为商家沉淀数据、产出模型、分析运营的基础支撑设施。引入数据湖后的 SaaS 数据智能服务模式如下。



如图 21 所示,平台方为每个用户提供一键建湖服务,商家使用该功能构建自己的数据湖,“一键建湖”能力一方面帮助商家将所有埋点数据的数据模型(schema)同步至数据湖中;另一方面,将属于该商家的所有埋点数据全量同步至数据湖中,并基于“T+1”的模式,将每天的增量数据归档入湖。基于数据湖的服务模式在传统的数据分析服务的基础上,赋予了用户数据资产化、分析模型化和服务定制化三大能力:


  1. 数据资产化能力。利用数据湖,商家可以将属于自己的数据持续沉淀下来,保存多长时间的数据,耗费多少成本,完全由商家自主决定。数据湖还提供了数据资产管理能力,商家除了能管理原始数据外,还能将处理过的过程数据和结果数据分门别类保存,极大的提升了埋点数据的价值。

  2. 分析模型化能力。数据湖中不仅仅有原始数据,还有埋点数据的模型(schema)。埋点数据模型体现了全域数据智能服务平台对于业务逻辑的抽象,通过数据湖,除了将原始数据作为资产输出外,还将数据模型进行了输出,借助埋点数据模型,商家可以更深入的理解埋点数据背后所体现的用户行为逻辑,帮助商家更好的洞察客户行为,获取用户需求。

  3. 服务定制化能力。借助数据湖提供的数据集成和数据开发能力,基于对埋点数据模型的理解,商家可以定制数据处理过程,不断对原始数据进行迭代加工,从数据中提炼有价值的信息,最终获得超越原有数据分析服务的价值。

发布于: 刚刚阅读数: 4
用户头像

InfoQ签约作者 2020.11.10 加入

文章首发于公众号:五分钟学大数据。大数据领域原创技术号,深入大数据技术

评论

发布
暂无评论
典型的数据湖应用案例_数据湖_五分钟学大数据_InfoQ写作社区