1. 前言
数据湖作为大数据平台的底层支撑架构，从存储、元数据、计算框架维度提供了良好的支撑。在BI时代，支撑好海量数据存储的稳定性、扩展性、成本是关键技术竞争力；随着AI的兴起，特别是 LLM 大模型计算的热潮，对数据湖也带来在性能、安全性上更多的需求，阿里云数据湖在该领域已有多年探索，希望能够通过本次分享给业界在 BI+AI 的基础设施建设上带来更多思路。
2. 数据湖支撑场景回顾
回顾数据湖发展历程，最早是由AWS掀起以S3对象存储为底座的数据湖支撑大数据分析，并且将数据湖和数据仓库进行分析比较，推动BI on数据湖浪潮，随着SnowFlake的上市，引爆基于数据湖构建云原生的数仓SaaS服务的高潮。伴随AI兴起，不少AI厂家也基于数据湖来构建应用，它们需要扩展HDFS、POSIX接口来支撑AI引擎机器分析。近期AIGC/LLM热点爆发，也给数据湖带来更多场景需求。
支撑场景的不断扩展，也带来对数据湖分析文件类型的变化，在BI场景下主要还是DB类文件，格式相对简单，就像炒素菜对厨艺要求不那么高一样，对计算的要求很普通，离线离线分析通常X86就可以搞定；在AI场景下则会分析文本、图片、音频、视频等，格式变复杂，就类似炒荤菜对厨艺有较高要求那样，需要更强的计算，采用GPU可以更高效的处理数据；而LLM场景下，则是多种类型组合，就类似做满汉全席大餐的厨艺要求，典型需要配置顶级的GPU来处理。因此，场景背后除了数据存储外，更多隐含了数据分析的计算价值。
3. 支撑大数据分析场景关键技术
阿里云以对象存储OSS为存储底座的数据湖，见证了接入自研大数据分析系统MaxCompute（原ODPS）和开源大数据系统EMR的过程，也为支撑好场景提供了关键技术。
3.1 接入自研大数据分析MaxCompute（MC）
OSS数据湖存储对接BI时，对访问权限的“安全设计”一直放在首位。客户的OSS桶作为MaxCompute的外表支持数据分析，如果把桶的所有内容都开放给MC，存在权限过大的问题，如何只分享/test前缀内容给MC呢？最初采用RAM Policy、Bucket Policy来授权，但存在复用OSS域名且Bucket Policy粒度大问题，每次修改Policy都会影响其他的配置策略；后来优化为Access Point技术，可为MC访问/test前缀分配单独域名，并绑定细粒度权限。通过该方法实现细粒度控制，在体验方面也得到提升。
数据分析引擎安全接入访问数据后，很显然会存在与客户应用争抢资源的问题，因为两者会同时访问数据湖，如何保证客户应用的带宽、QPS不受BI分析引擎的影响？简单的方法是各业务口头协商通过分时复用，减少两者争抢资源冲突是一种方案，但时间控制较难，无法保证两者不会同时访问，且存在波峰重叠情况。
为了解决此问题，引入了子账号级“流控技术”，通过为子账号限制“带宽、QPS”，保证对客户应用影响在可控范围内。
尽管提供流控技术，毕竟有客户应用和分析引擎的同时访问，为了加速计算速度需要提供更大的带宽，从而保证BI分析引擎在指定时间完成分析，同时减少计算节点等待数据拉取的时间，降低BI分析成本。当前，OSS在北京地域提供“100+Gbps/租户”性能，支撑数据分析应用对带宽的需求。
3.2 接入开源大数据分析EMR
OSS支撑阿里自研的MaxCompute，底层对象存储的接口无需修改，因为计算引擎会适配。但对接到Hadoop生态开源体系的数据分析引擎时，则存在需要扩展HDFS的问题。众所周知，Hadoop历史上不少计算框架诞生时对象接口还未诞生，所以几乎都是采用HDFS。国外不少企业在基于对象接口新技术开发，但国内挺多企业还在基于历史的开源框架来做生产，也没有更多资源来投入接口改造，小公司甚至都不知道使用那些HDFS接口，该如何改造。若数据湖提供Hadoop依赖的HDFS接口，帮助应用平滑迁移，必然赢得客户支持。
为此，数据湖通过从对象存储OSS扩展出服务化HDFS接口，实100%兼容，让应用平滑迁移。从而客户无需维再护HDFS集群，同时还减少计算节点成本和运维难题，支撑客户聚焦数据湖之上的业务成功。
要支撑好HDFS接口的100%兼容，底层又要依赖对象存储，那么就要“做好对象存储接口适配HDFS的优化工作”。基于数据湖存储提供OSS-HDFS的架构，底层全部直接对接对象存储，中间提供HDFS的目录结构，在计算引擎上安装OSS-HDFS SDK，该SDK把元数据发送到目录结构模块，数据直接发送到对象存储，从而充分利用OSS的能力，而目录结构模块也会直接使用OSS接口来完成数据管理工作。采用该架构，通过HDFS目录结构支持rename原子化，并且对象存储也为它提供批量接口来帮助目录结构实现管理上的优化。
3.3 数据湖基于对象存储而不是开源HDFS构建的思考
数据湖存储通过同时支持对象接口和HDFS 接口很好的支持了开源生态，但业界也有不少讨论，为什么用对象存储来构建数据湖，而不是用开源HDFS构建数据湖？
通过如下3个关键竞争力点来分析：
1、稳定性能力。对象存储提供同城冗余（多次抵抗住数据中心级灾难）和本地冗余类型，现在OSS本地冗余类型可线上自助申请转换为同城冗余；同城冗余类型达到12个9的数据可靠性，以及99.995%的可用性SLA，这比开源HDFS提供了商业化承诺的稳定性能力。
2、扩展能力。对象存储通过桶/对象的多层扩展性设计，支持单桶EB级存储、对象数万亿级能力。主要通过“无状态服务接入层”实现灵活增加机器来提高上传和下载的性能，“索引分区层”实现把 Bucket 的元数据进行动态分裂和负载均衡调度来水平扩展支持万亿对象，“持久层”实现分布式存储管理更多的机器提供容量和性能的水平扩展。而开源HDFS则在超过100PB、100亿文件时，就会存在管理运维难题，通过Federation技术来扩展则需要业务层解决联邦成员之间的均衡问题，很难做出通用的均衡方案。
3、成本竞争力。对象存储提供丰富的存储类型，OS从标准类型（0.12元/GB/月）分级到深度冷归档（0.0075元/GB/月），实现16倍成本优化。基于数据冷热统计，支撑数据生命周期的Policy配置，由对象存储自动完成数据移动。通过开通对象存储访问日志分析，可以掌握数据冷热信息，后续会通过Cloud Lens for OSS呈现，帮助完成生命周期策略配置决策。而HDFS是纯粹的软件，无法提供如此能力。
4. 支撑AI场景
目前的AI框架几乎都是基于POSIX文件系统实现，基于对象存储接口实现很少或正在开发中。通过对象存储提供的文件系统插件（例如ossfs），可支持简单文件操作，但支持模型训练需要的复杂接口还有差距。同时要支持好AI的文件系统，为提供更优性价比的存储，通常底层会采用对象存储，也就是说基于对象存储构建POSIS文件系统，从某种角度看算是对象存储扩展出POSIX能力。此时，文件系统和对象存储之间的数据流动效率，则是支撑好AI框架访问数据的关键。
AI业务存在多机分布式训练提高效率的场景，因此对热点数据集有高性能需求。热点数据集需求为单位密度性能，表现为读、写、加载checkpoint时的高带宽，典型如100TB容量提供大于100Gbps带宽；而且性能弹性特征明显，高峰主要是训练（Training）、推理（Inference）场景，其他场景性能变低。
云原生环境的独立性能加速层。在无容器时代，计算需要加速通常利用本地盘实现，此时cache加速就在计算节点内部署。容器时代，节点多采用无状态架构、不持久化数据，便于快速伸缩，为加速访问可采用独立服务器部署Cache。在OSS服务此场景时，OSS为加速热点数据的读访问，提供服务化的加速器，无需客户部署，并且放置在客户容器所在AZ，从而减少网络开销，并按需使用付费、灵活申请释放，降低客户使用成本。
5. 支撑LLM场景
AIGC&LLM场景，GPU成为刚需，也带来新的发展思路。趋势一，就是“通过GPU部署客户端直通存储”减少绕行CPU和OS驱动的开销，提高性能、减少CPU的计算成本；优化存储通路，可采用RMDA技术，减少网络栈的性能影响。
大模型时代，GPU是稀缺资源，因此不再是计算随数据而引动，而是数据随GPU走。考虑到计算环境建设的行业性、隔离性，需支持不同 GPU 部署站点的混合云环境，但数据集需要共享，因此数据要在不同安全隔离环境间快速移动，提供“在线、离线的数据迁移服务”是重要的趋势。
6. 总结和展望
基于对象存储规模效应，通过大力出奇迹、构建价格洼地，打通汇聚数据的通道，自然天生就是数据湖。基于海量数据就可支撑各种数据分析引擎，构建应用场景生态，对象存储从服务公网访问的“网站、网盘、短视频，演进到服务内网的 BI、AI、LLM”场景，不断拓展边界。为提高分析引擎运行效率，数据湖要提供稳定安全的底座，开发各类适配引擎的功能，优化性价比，持续挖掘数据价值。
未来展望一，就是持续优化性价比。业界大量容盘是趋势，但厂家spec中有个“冷知识”，硬盘年访问带宽 小于550TB/Y，按7*24小时工作计算，则平均带宽小于 18.3MB/s；如超过该值，硬盘寿命会受到影响，导致高年故障率（AFR）。同时硬盘容量增长，并不会带来性能提升，因此单位容量IOPS和Throughput降低。如何做好调度，将对象存储海量硬盘的能力充分发挥，性能挖潜将是非常重要的工作。
未来展望二，支撑数据分析引擎间的互通互利。不同数据分析引擎有各自特色，同一份数据被多引擎、多维度分析，能充分挖掘价值。数据湖可以通过元数据管理，提供引擎的认证、注册管理，保证引擎的安全可信、质量管控；同时支持数据格式管理，不同分析引擎可以通过理解格式，掌握分析数据的结果；并通过权限管理，授权引擎可以互访数据。长远来看，可以更好的支撑数据交换、数据交易等场景。
