Atlas基于云器Lakehouse升级数据平台，实现业务效率与平台稳定性的双重提升

导读

Atlas 是一家富有创新精神的新加坡旅游科技初创公司，由连续创业企业家 Mary 及其团队于 2019 年底成立。公司利用互联网技术高效聚合和分发全球廉价航空公司的特价机票，服务于全球旅游业生态系统。技术部门需要与包括航空公司、在线旅行社（OTA）、机票代理、技术和预订公司、支付公司等参与者进行数据交换，以提供卓越的客户服务。近期Atlas进行了数据平台升级，在原来的数据架构基础上引入新一代湖仓一体SaaS数据平台。

引入云器数据平台 Lakehouse 后，在销售转化漏斗运营分析等场景能够给运营人员提供即时新鲜度的数据，以及低延迟高并发的稳定的查询服务；在使用云器Lakehouse之后，优化了原来采购了固定资源规格的存储服务的限制，从存放7天的数据优化成无限扩展可以低成本存放 365 天的数据，能支撑业务方的历史数据的查询需求的范围也变得更加宽泛，极大扩展数据价值挖掘的范围，支撑起更长客户的生命周期管理。

Atlas 作为一家提供高质量最优惠飞行路线方案出行服务的公司，其业务范围涉及 「在线票务预订服务、最优惠路线规划、辅营服务升级推荐」 等方面。作为整个产业链上的数据中心枢纽，Atlas 采集汇聚了航空公司、OTA 平台等多方数据，对公司上下游、内外部提供数据分析及交换共享服务。

在公司创立之初，本着 「用数据支持科学决策」 的理念，公司迅速成立了数据平台小组，敏捷搭建了第一代数据平台，快速支撑公司业务上线，为上下游决策链提供重要的数据支撑。数据平台小组面对的持续挑战有三点：

1. 数据规模持续扩大

   伴随着公司业务的蓬勃发展，数据采集来源的范围愈加广阔：航司票务数据、购票平台订单、用户行为日志，第三方平台数据等，使得数据集成规模慢慢扩大，数据增量最大峰值也不断刷新出新的高度，如用户搜索日志数据已经达到 6~7 亿+ /日。

2. 业务需求多元发展

   公司业务需求也在向丰富多元化拓展，航旅业务分析场景在向多维立体化的方向演进，分析脚本的复杂度逐步提升。

3. 时效性要求逐渐升高

   另一方面，一部分决策业务对数据的及时有效性也提出了更高的要求，从原先按日更新和统计的频率，逐步变为了每天多次更新，如：每若干小时、每半小时，每 5 分钟甚至更短的更新频率。

挑战具体的说，是数据平台必须应对从低频数据更新转向高频，以及每日数据增量的持续扩大，这两者共同导致了巨大的存储开销。为了首先解决数据及时性的重要且紧迫问题，数据平台组在原有的离线架构基础上，基于Flink 快速搭建了实时数据加工链路。这一改进确实解决了数据及时性问题，并且暂时满足了业务需求。然而，这也使得数据架构演进为离线和实时两套链路共存的状态，形成了典型的 Lambda 组装架构。

图1：Atlas原有数据平台架构

客观地评估目前的架构，我们认为它能支持已知的需求，但也有确定的瓶颈和问题。举例说明：实时和离线双链路的割裂性随着时间的推移，会逐渐产生内部不可调和的矛盾：

1. 统计口径难以被统一 ： 实时链路与离线链路由于有两条处理链路，对于相同统计指标的计算结果，不可避免会有数据结果不一致的情况发生。此类问题花费了业务人员和数据技术团队非常多的资源和时间，包括排查、配合、沟通、确认根因，影响效率。

2. 「难以收敛」的数据治理需求： 数据规模的扩大与数据治理的复杂性成正比，多条数据链路和不一致的数据口径让数据治理工作难以收敛。原本计划用于支撑业务扩张的技术资源被锁定在数据治理的工作中，较难做出有效改善，两方面同时作用成为了一个恶性循环。

3. 开发复杂性问题： 两个链路间进行切换调试上线。由于离线和实时是两种不同的技术，有着不同的开发语言和开发工具，因此这个过程总是需要离线和实时两边的人员做技术对接，同时还有可能牵扯到业务理解不同，拉上业务方一起重新理解需求，进一步损耗企业内部资源。

4. 维护复杂性问题： 由多套组件所组成的 Lambda 架构，每个组件都需要一定的运维手段来进行维护。存储与计算的扩缩容、日志的清理、任务的运维监控等，均由多种不同的工具所承载。例如出现数据运行故障，排查问题需要跨越一个个系统查找可能的原因。平台维护复杂性高、维护频率高、工作负载大，也同样是令人头疼的事情。

图2：Atlas原数据架构

数据平台项目组评估认为，系统的复杂度引起的一系列问题，长期来看不能通过扩张人力解决，切换到一个更简化的架构方案定为下一阶段的主要任务。并且现实的压力也很快就出现了，有两点外部因素的改变推动升级任务要尽快完成。

一、随业务发展，数据量在加速膨胀。公司数据平台在 Lambda 架构下平稳运转，业务发展进一步提速，数据量加速地膨胀。大约半年的蜜月期过后，用户搜索日志数据已经突破 8 亿+ /日，航空公司票务采集数据突破 7 亿+ /日，数据平台开始暴露了第一个业务阻塞性问题：在 BI 分析即时查询的场景下，由于过大的数据量，使得某些聚合分析无法稳定计算，统计数据接口频繁超时，这对业务侧产生了一些不小的负面影响，使得公司内部运营和外部服务的质量均受到了挑战。

二、AI 的出现带来了新的创新机会时间窗口。而此时，却又正值 AI 技术风口到来之际，Atlas 正欲向着结合 AI 新技术领域探索与产品力的提升的大方向上进发，公司的业务发展节奏绝对不能受此影响而陷入停滞。公司高层几番讨论过后，把目光的焦点放在了对数据平台架构升级这件事情上。主要考虑以下几个核心目标：

1. 首要的任务便是 解决燃眉之急的接口调用超时问题。 现有平台上 Clickhouse 在面向 BI 分析查询的场景下，所提供的查询服务响应时间出现了明显波动，超过 1 分钟便会导致服务超时。其本质原因是 CK 在多表关联查询场景下的性能并不十分理想。这个问题处理不好会直接影响每日下游的票务搜索查询分析服务，进而影响 B 端客户的体验。这一条是最严重的一条，需要最优先被解决。

2. 其次是 从整体平台架构上来看，企业数据资产存在着割裂性：

1. 当前的平台架构包含了实时、离线、在线分析查询等多种数据处理引擎，使得同一份 Raw Data 在不同的加工链路中流转，在不同的计算引擎中冗余存储。此外，数据质量、数据完整性标准不一，使得企业的数据治理难度上升了一个梯度，连同下游的业务分析指标存在不一致。这一条间接影响了已有业务上的决策活动；

2. 而且数据仓库各组件之间开放性不足，如果单独构建数据湖以满足开放性，又与数据仓库之间存在着重复建设，会进一步加剧企业数据资产 「湖」 与 「仓」 之间的割裂性。数据仓库内的结构化数据，与数据湖中的半结构化、非结构化数据，无法做到安全的共享或是权限的统一管理。因此也难以承接公司未来面向 AI 方向上的需求。这一条间接影响了未来公司业务的发展节奏。

3. 在运维方向上，公司平台组管理层提出： 原有数据平台需要自运维、自组合、自拼装， 这也是耗费较大的人力成本的重要因素之一，同时也是业务方领导认为技术同学总把关注点和精力放在平台技术和运维上，难以聚焦业务价值提升本身的一个关键因素。这一条可以间接解放技术侧资源，释放到业务价值上。

图3：Atlas原数据架构割裂问题

从更长期发展的角度考虑，作为一家出海数据型服务公司，Atlas 对数据的智能化以及数据价值发现和挖掘等方面有超出一般初创公司的要求。尤其在 2023 年大模型技术出现后，随着线上购票客户对产品用户体验的要求一再升级，单程、转机、往返票价的实时精准预测需求应运而生，公司对数据的实时性、智能化也有着更强的诉求。这些都需要新的数据平台能够很好地 支撑 AI 算法相关业务 的开展。对此，公司提出 3 个关键性要素：

1. 开放性 ：数据平台不再是单一的数据仓库，要有数据湖的开放属性。即能够对统一数据湖中的数据进行多种类别的工作负载，包括 AI 计算。Atlas 自身采集的数据也逐渐向图片、文本、日志等半结构化/非结构化数据扩展，数据入湖后可以从大模型 prompt 到一些私有模型训练，以满足预测多种路线方案的数据应用需求。对于当前已经使用其他的算法框架如：Spark，TensorFlow 等，需要平台有元数据和底层数据文件开放的支撑能力，这样就同时需要新的平台具备外插计算引擎的能力。

2. 可扩展性 ：数据平台需要在存储上做到灵活可扩展，满足持续增长的数据体量。在计算上需要支持按峰谷时段进行弹性伸缩，在伸展阶段计算性能尽量做到保持线性增长。

3. 统一性 ：数据平台能够数据仓库和数据湖做统一的数据权限管理，使用统一的元数据系统对数据仓库和数据湖做统一的抽象。因此需要一个具备湖仓一体数据管理能力的计算平台。

需求的梳理

综上所述，Atlas 的对于企业数据平台架构升级的直接痛点与潜在因素整理如下。

方案的选择和验证

确认了以上几点作为目标和要解决的问题后，公司平台技术团队与业务团队达成一致的目标，即升级数据平台。技术团队认真做了平台架构的选型和对比，设计完整的方案。在经历了几番尝试和验证后，最终尝试到了云器的 Lakehouse 湖仓一体化平台，并且在验证的基础上也做了和 Spark 及 MPP 架构一些产品的对比，如下：

图4：产品对比

云器的解决方案团队首先针对 Atlas 的现有架构进行数据集成方案的设计。由于票务数据与搜索日志的上游链路的数据源都统一汇总到 Kafka，因此开发一个程序从 Kafka 读取数据并每分钟落盘到 OSS 上 1 个文件，再使用云器 Studio OSS 数据同步 功能将数据写入 Lakehouse，在这个操作过程中 ODS 层保留原始 Json 数据，在 DWD 层完成 Json 文件格式的转化和后续的汇聚。此方案满足了实时场景从源头 kafka 到最终数据平台消费端，数据新鲜度在 10 分钟内的需求，并逐步向 5 分钟逼近，最重要的是成本远小于一个进程常驻的实时处理任务；交互式分析场景 8 亿条数据多维聚合与关联查询性能能够满足应用侧需求。且由于数据传输在 OSS 内部，避开 「公网」 网络传输，因此也降低了整体的存储和网络传输成本。

图5：基于云器Lakehouse的数据集成链路

在 Atlas 的数据体系中，原始数据的采集和存储传输均是使用 Json 格式进行的，通过云器 Lakehouse 的 from_json 函数进行一次性字段展平。按照生产实际情况，数据以 Json 格式 Kafka 写入 OSS，5 分钟间隔从 OSS 离线同步到 Lakehouse，数据落盘后及通过 SQL Volume Load 直接完成 Json 数据的拆表及字段打平。完成数据解析后链路 SQL 关联、聚合、去重等加工计算，到数据应用侧的 Ad Hoc、BI 查询、API 调用延迟满足 10 分钟 ~ 5 分钟的要求。

图6：基于云器Lakehouse的数据存储

在计算引擎的查询性能方面，我们选定一个典型场景对引擎进行了验证测试，测试数据从 OSS 进行加载到云器 Lakehouse 后，在 通用型虚拟计算集群（General Purpose Virtual Cluster） 中进行预处理，然后生产结果表在云器 分析型虚拟计算集群（Analytical Purpose Virtual Cluster） 中直接供业务系统进行查询。以下是一些性能验证情况。首先我们验证的是超过 7 亿条数据的查询情况，在与原有平台相同或更低的资源规格下，引擎可以在 10 秒内返回数据。对此，平台组进行了多种类型的多轮查询验证，在未进行过性能调优的基础上，基本上能按照线性的扩展要求，通过扩大计算资源规格，能够相应地按比例减少计算消耗的时间，因此获得了令技术团队和业务团队都十分满意的性能指标。

图7：云器Lakehouse查询性能验证效果

接着继续进行数据层面的优化，最终 7 亿条数据 5 个 key 的开窗用时大约 3 分钟，比调研过的同类实时数仓产品 2 亿条的 case 还快了一少半。令人满意的是，在整个查询计算的过程中，云器做到了资源的按量收费，和计算资源的自动弹性伸缩。对此，平台组还专门对虚拟计算集群进行了专项的验证，从结果上来看，计算资源基本上都是毫秒级拉起，分钟内销毁。确保了计算成本尽量的最小化。

同时，从数据湖与数据沧湖元数据统一管理的层面，云器 Lakehouse 既能存储和管理以结构化的数据，又能存储管理半/非结构化的数据。这样就使得数据平台升级成了湖仓一体的架构。在这个方面，公司算法团队也协助进行了一些验证。通过云器的 Python SDK 与 Catalog SDK，访问到了底层同一份的原始数据文件，经过简单的程序处理，最终与数仓中 SQL 处理结果相一致。满足了公司统一数据管理，简化平台架构，简化数据治理的诉求。

数据平台的迁移和实施

公司经过平台产品方案的选定，迅速启动相关的数据迁移工作，整个迁移工作在云器交付团队的帮助下，用时大约半个月时间，可以说效率比较不错。

图8：迁移时间轴

迁移工作中一些主要的关键点，这里做了一些梳理，首先云器作为一个全托管的数据平台，全程为客户提供技术兜底，效果兜底。云器的团队和 Atlas 的团队一起完成了平滑的湖仓对接和迁移验证，还通过自身的专业能力和经验，沉淀了一套完整的搬站迁移 SOP 标准流程和搬站工具，涵盖了 schema 转换迁移、任务迁移、数据迁移、数据正确性校验等多个方面。在这个过程中，也解决了一些问题，比如：

1. 存量任务迁移：数据迁移往往比较简单，有很多自研工具或者生态工具可以使用，任务迁移往往挑战比较多，云器LH语法层面兼容 Spark3 SQL 语法标准并在其上做了很多扩展，其他的如果是 RDD 开发 / Java 开发 / 其他方言 SQL，会涉及到语法转换问题，存在一定工作量，这部分使用了工具进行转化。

2. 迁移实施过程中需要对正确性 / 性能等指标的验收确认等工作，这部分使用工具化进行的，在这个过程中专门研发搬站迁移工具，目前已经比较成熟能够从开源大数据平台和商业化大数据平台进行数据迁移和搬站工作，包括流量并发评估，元数据 Schema 读取、任务迁移、数据迁移、数据比对等功能，已经相对比较成熟。

3. 作为数据开发和运维工程师，是否有一套完整的工作台是非常关注的指标，在云器提供产品手册，包括基本语法，功能介绍，最佳实践等的基础上，我们深度使用了云器的一站式平台产品 Studio 进行数据的集成、开发、治理和调度，能大幅提高数据迁移和数仓建设的效率。

图9：云器产品能力介绍

在整个迁移过程中，系统特性方面进行梳理和总结，重点解决了以下几个方面的问题作为重点关注点：

升级后的效果和业务价值

1. 性能达到质变效果：在原先的架构中，对于 7~8 亿条搜索数据的关联分组聚合查询，常常无法及时返回结果。在使用云器 Lakehouse 后，查询时间仅需约 10 秒，为业务运营分析提供了稳定且高效的查询服务。

2. 「无限」 存储：之前，Atlas 采购了固定资源规格的存储服务，仅能存放约近 7 天的数据量。而切换到云器 Lakehouse 后，不仅存储单价成本更低，还支持理论上的 「无限」 扩展。现在，我们可以存放近一年的数据，满足了业务侧对历史数据查询需求的更广泛范围。

3. 全托管、免运维：过去，数据平台维护人员需要人工清理磁盘、删除日志、扩容服务器，排查计算引擎的偶发问题。而现在，这些任务均由云器 Lakehouse 产品及其 SRE 团队负责。Atlas 解放了技术人力资源，省时省力，让平台维护工作变得更加轻松。

4. 减少 「内耗」 成本：对比原来的数据架构，存储和计算的成本均得到有效控制，开发语言的统一也使得实时和离线任务的转化不再需要 「两三拨人」 参与，湖上建仓引用同一份数据，数据治理问题也迎刃而解。并且在数据架构优化的基础上，进一步压缩优化了运维成本。使用 SaaS 数据平台产品后，引擎能力的提升以及 SaaS 按量付费，所带来的直接成本降低达 50% 以上，由于平台运维方向的优化，仅不到一个人就可以在云器产品化基础上做到了高效生产运维和安全生产。

5. 业务扩展：以前业务人员的取数需求，分析查询慢，甚至跑不出来。现在可以快速产出结果，由于具备线性扩展性，既不需要担心未来数据量更大时会重蹈覆辙，也可以通过增大计算集群规格来缩短查询时间。

6. 稳定性提升：原平台需要平台组成员自行拼装搭建，在遇到一些技术瓶颈时往往通过查找社区相关问题或提问，得不到有效的保障。使用云器 Lakehouse 后，其产品从设计模式上就重视考虑云原生分布式架构，然后根据多年生产运维经验组件专家服务值班团队，常态化 7x24 保障集群稳定与安全。同时对于新功能的发布，也设计了一套灰度发布上线的机制，对于一些我们尝鲜的新功能，会做隔离性保护。目前已经支撑 Atlas 在十一国庆和春节期间的报表数据加工和业务查询洪峰，从效果来看，目前对于 SLA 的保障是比较有信心的。

展望和期待

同样作为创业公司，云器科技愿意与我们一起探索人工智能的场景建设，共同成长，相互支持，互为陪跑。在产品研发过程中，云器科技采用了湖仓的底层架构，旨在解决这些问题。尽管当时大型语言模型并不像现在这样热门，但 Atlas 仍然选择了这个方向，进行了开放式的设计。数据存储在数仓中，但同时也是开放的，可以被其他引擎消费。而云器在设计产品扩展性时，也很好地兼顾了这一点。在计算灵活性和可扩展性方面，Atlas 采用混合编程模式，例如 Python 和 SQL 的结合，以确保计算的开放性和管理性。这样，我们的平台具备了扩展性，能够应对未来更多的技术突破和迭代。

Atlas 还计划同云器科技一起探索更多有趣的场景。其中之一是使用 AI 和机器学习来准确预测航空公司的定价区间。结合云器科技提供的面向 AI 的数据基础设施具备的湖仓一体，AI workload 整合，统一的数据管理等基础能力，基于航空公司提供的航班、机票和辅助服务信息，进行 远/近期 - 直达/转机 - 单程/往返 多段航程的票价预测、行李托运 / 餐食服务预测、最优惠路线规划等。