一、技术架构
OPPO 大数据场景丰富，拥有海外的 AWS 功能云，国内自建机房，机器规模超过万台，在印度则是使用混合云模式。
首先来介绍一下 AWS 上功能云 EMR 的实践。
1. 云原生计算架构
OPPO 早期全部采用 EMR，其存在以下一些问题：
- 首先，弹性伸缩迟滞。上图中展示了资源的分配效率（不是真正的资源利用率和机器的物理利用率），以及资源弹性趋势图。可以看到，凌晨高峰时资源使用率瞬间变高，回收资源持续了很长时间，效率低，弹性差。
- 另外，编码机器选型固化。云上的机器基本都是 Intel 的 x86 机型，无论是 AWS 还是阿里云提出的 ARM 机型从单价上就便宜 20-30%，但是 EMR 产品不兼容 ARM 机型。
- 最后是调度算法固定。
为了解决上述问题，OPPO 自研了极致弹性计算架构——Yarn on EKS。EKS 是AWS 提供的托管型 Kubernetes 服务。Kubernetes 难以满足大规模快速调度的需求，无法做到快速调度、机器可掌控、资源可控制。因此我们选用了 Yarn on EKS。
业界有很多开源的 RSS 解决方案，包括阿里巴巴的 RSS 平台和腾讯的 Uniform 平台。OPPO 的云需求较少，因此投入比较低。我们的架构 base 在分布式内存Alluxio 上，在 AWS 上实现弹性的 Alluxio 集群。思路是只做 shuffle 服务，存储交给性能高的、更合适的存储系统，开始是 HDFS、Cubefs 分布式文件系统，后面选用了 Alluxio。内部测试系统性能比较高，包括弹性 RSS 服务，可以根据压力自动调整弹性。
资源调度优化，核心在于计算架构资源。自研架构下，资源利用率弹性效率高，每个小时都有一个波峰波谷，平均物理资源利用率达到 80% 以上，长时间维持在 80-90% 上下。
另外，组件全云化。除了 Yarn 和 Spark，大数据链路中还有许多其他关键的组件和工具，包括任务调度和工作流管理。调度采用的是 Airflow，并对其进行了一些自定义修改，以适应特定的任务调度需求或环境。Airflow 的 worker 基本是常驻资源，每一个业务来了之后都会申请 2 个 worker，费用昂贵，所以将其改为弹性的资源配置，有任务需要执行时才进行资源配置。
上图展示了我们自研架构的资源看板。从右下方的弹性效率图可以看到，每小时都会有波峰波谷，物理资源的平均利用率可以达到 80% 以上。
上图是成本看板。原本 AWS 两天才会出一次账单，使用自研架构后，每个小时就会出一个账单，包括单价花费以及每个机型的使用时间。
2. Data&AI 一体化数据湖架构
整体架构如上图所示。主要解决的问题包括：
- 数据秒级入湖，在公司内部替代了部分资源的使用，达到了降本的效果。
- 自动化管理，Iceberg 缺少一层服务层，业务需要自己管理。
- 兼容非结构化数据，我们做了一个 DAA Catalog 来兼容非结构化数据的管理。
采用分布式内存来解决实时性问题，虽然线上集群规模较大，但内存闲置比较多，使用分布式内存可以将内存资源更好地利用起来，在数据湖上用这种方式解决了数据实时入湖的问题。数据实时写入分布式内存的 block 里面，然后 Dump 服务会定时管理这些 block 何时落到 Iceberg 底层的存储上。
DAA Catalog 主要包括两个模块：Metastore 和管理模块。Metastore 类似于 HMS，主要解决元数据生命周期管理的问题。管理模块的功能主要包括：数据安全和数据血缘、dump 服务和动态聚合、非结构化数据的版本管理，以及非结构化数据的转换服务。
实现秒级实时的做法是，在内存里把数据做成 real-data，底层是 base-data。另外很多 dele-data 也是放在内存里，这样 Dump 的时候自动合并。分布内存管理使用的是 Alluxio，但是对功能进行了魔改，Alluxio2.9 开源版本的通信传输效率不好，我们通过修改使性能得到了显著提升。另外还实现了 Alluxio 流式读写，数据可以逐条写入。
Data & AI 中，Data 指的是结构化的数据，AI 的数据全是非结构化的数据。
结构化数据的处理最初是基于 Iceberg，目前可兼容多种接口协议。自动化管理包括cluster、dumper、indexer、combiner 等。另外对索引能力也做了增强。
我们在结构化数据的处理上尝试了很多优化。因为是分布式内存的缓存，缓存上的性能加速，数据的索引，热表缓存和数据预热在内存里。
上图展示了一个比较特殊的案例，是搜推业务在实时样本拼接时遇到的一个问题，HBase 成本较高，且性能也不能满足需求。提出的解决方案是多数据源主键实时 Join。涉及到的样本数据，单条数据量比较大，平均一兆左右，把数据的索引放到分布式内存中，数据实时过来后在内存里的 hash partition 找到相关的索引去拼接，类似于 MOR 机制。
非结构化数据的管理，主要问题在于元数据，我们希望非结构化数据能够像结构化数据那样方便地使用。另外一个问题是数据格式转换，有些处理方式还比较原始，落到湖上之后会有 Trans-Service，例如将图片数据转换成 h5 或 dataset 格式，dataset 格式参照 Updataset 协议，提供一个统一的上层 API。
图中元数据转换使用的是我们自己的 AndesGPT，也可以调用 ChatGPT。元数据embedding 到数据库里面，方便上层自然语言式的查询和搜索。
上图是一个管理示例，我们可以像 SQL 查询一样去查询图片、文本数据的详情。
DataPrompter，在公司内部的聊天系统中，在对话框里 @机器人可以很方便地查询各种数据指标。开发过程中遇到的问题是，每输入一个表格，需要人工编织很多详细的 prompt，使 GPT 更好地去认识数据，写更精准的 SQL，海量的数据需要一个一个地制作 prompt，这就会构成瓶颈。入湖之后，根据元数据包括一些普通的信息都自动生成转换范例 prompt，从而使大模型能够更好地理解湖仓上的数据。
在此基础上，还会将历史查询的业务含义反馈到 prompt 里，以及业务方的测试反馈。
Databricks 提供 Model Pre-Trainingt 的 TensorBoard 模型，把湖仓上的元数据进行训练，后期我们也会使用这种模式进行模型微调。
数据入湖阶段，大语言模型为更好地写出更精准的 SQL，会把 SQL 的规则编写到prompt 里面。另外，表结构、字段和指标口径说明打开直接写进去。模型输出OutputCommand 关注点和格式要求，输出 SQL 对应写法要求和标准。
二、应用落地
1. 实时特征平台
实时特征平台的架构如上图所示。
通过主键实时 Join，实现了每秒拼接单机 qps-7k，延伸到多台机器实现了线性的扩展。
2. 机器学习训练数据加速
下面介绍机器学习训练湖仓数据加速的方法。首先是搜推算法训练数据加速，很多数据是裸的文本数据，txt 格式，上层的 Python 读取的时候会涉及到序列化性能慢的问题，我们将文本数据转换为 Parquet 格式，并使用 Arrow 库来读取。经过线上测试，性能会有 10 倍的提升。
大模型的训练加速，会将裸的图片数据转换成分割好的 tar 包的 Dataset 的数据格式，通过缓存加速大模型训练数据的读取。训练时图片数据加载还是个瓶颈，图片数据的数据量比较大，如果用比较大的 tar 包性能会比较差。通过转换为小的 dataset 能得到数倍的性能提升。
3. 混合云场景应用
混合云在印度业务中有使用，但由于没有太多算法的业务，机器规模较小。以混合云上数据湖仓数据任务灵活编排。DAA-Catalog 统一管理混合云数据复制迁移。
通过混合云模式，混合云数据任务迁移中，带宽是主要的瓶颈，迁移的时候通过找到数据和计算对带宽依赖最小的子图的方式去迁移，同时也会考虑底层的数据一致性，使得数据入湖底层路径透明。
DataPrompt 落地的情况，Datachart 架构流程如图，底层是湖仓的数据，先确定是否为数据分析问题然后转化为 SQL 执行，数据在湖仓上解决不了的话就联网分析。Glacier 湖仓服务会找到这个表的 Prompt 推给大语言模型，进行自然语言数据分析。
上图中展示了内部的使用情况。通过数据对比可以得出，大语言模型在数据分析上是比较有帮助的。
三、展望
未来仍会注重大数据方面的开发和发展。在公有云架构方面进一步深挖，公有云实施的弹性架构为公司节省了大量财务支出，单任务计算成本相比 EMR 降低了约 80% 左右，后续将尝试更多手段，继续深化这块领域的技术。公有云架构 Spark on GPU 的加速已经实现，进一步要对接 Shuttle Service。Spark on GPU 的收益为，性能提升 4 倍，成本降低约 50%。引擎向量化 Gluten+Velox 的概念，业内比较火热，各大公司都在尝试，开发中存在一些问题，所以目前没有过多的投入，但是未来的一个方向。持续降本增效永远是底层技术的主题，降本和稳定性是两条生命线，降本是否可以牺牲一定的稳定性这一问题仍需思考。
另外一个方向是 Data & AI 湖仓架构，很多业界顶尖公司都在推动这一理念。但是元数据管理存在痛点，活跃度低的表仍需解决冲突问题，向上与大模型应用结合。半结构化数据通过统一接口访问，封装了 dataset 的接口，向下需与 Paimon 结合，兼容更多底层格式，方便用户查找和训练数据。