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

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

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

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

图16 改造后的广告数据湖方案架构

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

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

图17 数据湖部署示意图

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

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

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

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

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

图18 改造前的方案

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

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

图19 改造后的数据湖解决方案

总体上，我们没有改变客户的数据链路流转，只是在OSS的基础上，增加了DLA组件，对OSS的数据进行二次加工处理。DLA提供了标准SQL计算引擎，同时支持接入各类异构数据源。基于DLA对OSS的数据进行处理后，生成业务直接可用的数据。

但是DLA的问题在于无法支撑低延迟需求的交互式分析场景，为了解决这个问题，我们引入了云原生数据仓库ADB来解决交互式分析的延迟性问题；同时，在最前端引入QuickBI作为客户的可视化分析工具。YJ方案是图14所示的湖仓一体化解决方案在游戏行业的一个经典落地案例。

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

图20 YM智能数据服务SaaS模式示意

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

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

图21 基于数据湖的数据智能服务

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

个人认为数据湖是比传统大数据平台更为完善的大数据处理基础支撑设施，完善在数据湖是更贴近客户业务的技术存在。所有数据湖所包括的、且超出大数据平台存在的特性，例如元数据、数据资产目录、权限管理、数据生命周期管理、数据集成和数据开发、数据治理和质量管理等，无一不是为了更好的贴近业务，更好的方便客户使用。

数据湖所强调的一些基本的技术特性，例如弹性、存储计算独立扩展、统一的存储引擎、多模式计算引擎等等，也是为了满足业务需求，并且给业务方提供最具性价比的TCO。

数据湖的建设过程应该与业务紧密结合；但是数据湖的建设过程与传统的数据仓库，甚至是大热的数据中台应该是有所区别的。区别在于，数据湖应该以一种更敏捷的方式去构建，“边建边用，边用边治理”。为了更好的理解数据湖建设的敏捷性，我们先来看一下传统数仓的构建过程。

业界对于传统数仓的构建提出了“自下而上”和“自顶而下”两种模式，分别由Inmon和KimBall两位大牛提出。具体的过程就不详述了，不然可以再写出几百页，这里只简单阐述基本思想。

Inmon提出自下而上（EDW-DM）的数据仓库建设模式，即操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层；ODS层中的数据，根据预先设计好的EDW（企业级数据仓库）范式进行加工处理，然后进入到EDW。EDW一般是企业/组织的通用数据模型，不方便上层应用直接做数据分析；因此，各个业务部门会再次根据自己的需要，从EDW中处理出数据集市层（DM）。

优势：易于维护，高度集成；劣势：结构一旦确定，灵活性不足，且为了适应业务，部署周期较长。此类方式构造的数仓，适合于比较成熟稳定的业务，例如金融。

KimBall提出自顶而下（DM-DW）的数据架构，通过将操作型或事务型系统的数据源，抽取或加载到ODS层；然后通过ODS的数据，利用维度建模方法建设多维主题数据集市（DM）。各个DM，通过一致性的维度联系在一起，最终形成企业/组织通用的数据仓库。

优势：构建迅速，最快的看到投资回报率，敏捷灵活；劣势：作为企业资源不太好维护，结构复杂，数据集市集成困难。常应用于中小企业或互联网行业。

其实上述只是一个理论上的过程，其实无论是先构造EDW，还是先构造DM，都离不开对于数据的摸底，以及在数仓构建之前的数据模型的设计，包括当前大热的“数据中台”，都逃不出下图所示的基本建设过程。

图22 数据仓库/数据中台建设基本流程

上述过程，对于一个快速成长的互联网企业来说，太重了，很多情况下是无法落地的，最现实的问题就是第二步模型抽象，很多情况下，业务是在试错、在探索，根本不清楚未来的方向在哪里，也就根本不可能提炼出通用的数据模型；没有数据模型，后面的一切操作也就无从谈起，这也是很多高速成长的企业觉得数据仓库/数据中台无法落地、无法满足需求的重要原因之一。

数据湖应该是一种更为“敏捷”的构建方式，我们建议采用如下步骤来构建数据湖。

图23 数据湖建设基本流程

对比图22，依然是五步，但是这五步是一个全面的简化和“可落地”的改进。

建议的存储选型是分布式对象存储系统（如S3/OSS/OBS）；计算引擎上建议重点考虑批处理需求和SQL处理能力，因为在实践中，这两类能力是数据处理的关键，关于流计算引擎后面会再讨论一下。无论是计算还是存储，建议优先考虑serverless的形式；后续可以在应用中逐步演进，真的需要独立资源池了，再考虑构建专属集群。

数据湖强调对原始数据的存储，强调对数据的探索式分析与应用，但这绝对不是说数据湖不需要数据模型；恰恰相反，对业务的理解与抽象，将极大的推动数据湖的发展与应用，数据湖技术使得数据的处理与建模，保留了极大的敏捷性，能快速适应业务的发展与变化。

从技术视角来看，数据湖不同于大数据平台还在于数据湖为了支撑数据的全生命周期管理与应用，需要具备相对完善的数据管理、类目管理、流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等能力。

在计算能力上，目前主流的数据湖方案都支持SQL和可编程的批处理两种模式（对机器学习的支持，可以采用Spark或者Flink的内置能力）；在处理范式上，几乎都采用基于有向无环图的工作流的模式，并提供了对应的集成开发环境。对于流式计算的支持，目前各个数据湖解决方案采取了不同的方式。在讨论具体的方式之前，我们先对流计算做一个分类：

二者的本质不同在于，模式一处理数据时，数据往往还没有存储到数据湖中，仅仅是在网路/内存中流动；模式二处理数据时，数据已经存储到数据湖中了。综上，我个人建议采用如下图模式：

图24 数据湖数据流向示意图

如图24所示，在需要数据湖具备模式一的处理能力时，还是应该引入类Kafka中间件，作为数据转发的基础设施。完整的数据湖解决方案方案应该提供将原始数据导流至Kafka的能力。

流式引擎具备从类Kafka组件中读取数据的能力。流式计算引擎在处理数据过后，根据需要，可以将结果写入OSS/RDBMS/NoSQL/DW，供应用访问。某种意义上，模式一的流计算引擎并非一定要作为数据湖不可分割的一部分存在，只需要在应用需要时，能够方便的引入即可。但是，这里需要指出的是：

对于模式二，本质上更接近于批处理。现在许多经典的大数据组件已经提供了支持方式，如HUDI/IceBerg/Delta等，均支持Spark、Presto等经典的计算引擎。以HUDI为例，通过支持特殊类型的表（COW/MOR），提供访问快照数据（指定版本）、增量数据、准实时数据的能力。目前AWS、腾讯等已经将HUDI集成到了其EMR服务中，阿里云的DLA也正在计划推出DLA on HUDI的能力。

让我们再回到本文开头的第一章，我们说过，数据湖的主要用户是数据科学家和数据分析师，探索式分析和机器学习是这类人群的常见操作；流式计算（实时模式）多用于在线业务，严格来看，并非数据湖目标用户的刚需。但是，流式计算（实时模式）是目前大多数互联网公司在线业务的重要组成部分，而数据湖作为企业/组织内部的数据集中存放地，需要在架构上保持一定的扩展能力，可以很方便的进行扩展，整合流式计算能力。

数据湖作为新一代大数据分析处理的基础设施，需要超越传统的大数据平台。个人认为目前在以下方面，是数据湖解决方案未来可能的发展方向。

关于什么是云原生架构，众说纷纭，很难找到统一的定义。但是具体到数据湖这个场景，个人认为就是以下三点特征：

2）足够用的数据管理能力

数据湖需要提供更为强大的数据管理能力，包括但不限于数据源管理、数据类目管理、处理流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等。

3）大数据的能力，数据库的体验

目前绝大多数数据分析人员都只有数据库的使用经验，大数据平台的能力虽强，但是对于用户来说并不友好，数据科学家和数据数据分析师应该关注数据、算法、模型及其与业务场景的适配，而不是花大量的时间精力去学习大数据平台的开发。数据湖要想快速发展，如何为用户提供良好的使用体验是关键。基于SQL的数据库应用开发已经深入人心，如何将数据湖的能力通过SQL的形式释放出来，是未来的一个主要方向。

4）完善的数据集成与数据开发能力

对各种异构数据源的管理与支持，对异构数据的全量/增量迁移支持，对各种数据格式的支持都是需要不断完善的方向。同时，需要具备一个完备的、可视化的、可扩展的集成开发环境。

5）与业务的深度融合与集成

典型数据湖架构的构成基本已经成为了业界共识：分布式对象存储+多模态计算引擎+数据管理。决定数据湖方案是否胜出的关键恰恰在于数据管理，无论是原始数据的管理、数据类目的管理、数据模型的管理、数据权限的管理还是处理任务的管理，都离不开与业务的适配和集成；未来，会有越来越多的行业数据湖解决方案涌现出来，与数据科学家和数据分析师形成良性发展与互动。如何在数据湖解决方案中预置行业数据模型、ETL流程、分析模型和定制算法，可能是未来数据湖领域差异化竞争的一个关键点。