通过本篇文章，你可以了解到从传统自建Spark架构升级到新一代湖仓架构的显著业务价值和轻便的实现过程:
云器Lakehouse引擎直接嵌入客户已有数据湖，免除数据搬迁，直接接入元数据，形成统一元数据基础层次，实现不搬迁数据湖进行湖上查询加速。
ETL场景下，云器Lakehouse 相比于 Spark 提升了 6X 倍的性能；BI场景下，云器Lakehouse 总体性能相较于原 Presto 查询方案提高 2-10X 倍。
动态库存管理支持秒级拉起，使TCO总成本降低至三分之一。
公司介绍
能者物流（以下简称 NinjaVan），东南亚前三的物流公司。成立于 2014 年，总部设于新加坡，是一家以科技为中心，主要服务于电子商务的区域物流与派送公司，通过自建系统、自营团队，为中国与东南亚各国企业提供无忧的跨境、清关与派送解决方案。目前，已发展成为东南亚地区增长最快、最后一公里派送覆盖范围最广的区域物流佼佼者。
能者物流在6个国家有 operation，43,000 员工，其中 IT 人员 200+。其中几十人在数据分析团队，分布在 6 个国家。以前是使用开源自建大数据平台，随着数据和查询复杂性的增长，业务平台的建设已无法支持业务的增长，开始看向数据平台托管类商业化产品做选型，同时考虑 cost cutting 的需求。
NinjaVan 分析
NinjaVan 架构现状
图：NinjaVan原系统架构
NinjaVan 在 GCP 上基于业务数据进行中心化数据平台建设，提供 Regional Business Intelligence 商业报表分析业务。在此前支撑这些应用和分析的，是 NinjaVan 基于 Lambda 架构，采用 Spark、Spark Streaming、Kafka、Airflow、Ranger、Presto、Metabase、JupyterHub 等多个开源大数据组件组装而成的数据平台。
该架构链路通过 Kafka+Spark Streaming 数据集成写入到 GCS 数据湖、存储为 DataLake DeltaTable。然后基于数据湖上的 Delta 格式数据通过 Ariflow 调度 Spark 进行离线计算，生成 Pure Parquet Datawarehouse Table。通过 Presto + HMS + Parquet 的组合技术栈支持分析，对接交互式分析到 Metabase BI 报表。并在此数据化架构基础上伴随部分 JupyetrHub 提交的 Spark 数据科学、数据挖掘等数据应用。这也是业界主流的数据架构，支持了 NinjaVan 一直以来的商业智能化发展。
架构特点分析
1.难以支撑稳定和及时的 BI 在线分析需求
随着数据量增大，Presto 的查询性能需求需要增设更多计算节点来处理更高的查询压力。然而，Presto 资源扩展的机制并不如一些云原生系统灵活，手动扩展过程较为复杂，节点之间的协调和配置需调整，特别是在保持一致性和低延迟的情况下更为困难。扩容响应时间往往在 10 分钟以上甚至更长时间，这样就很难响应业务并发不定时规则扩缩的需求。
NinjaVan 在使用 Presto 的过程中，伴随着业务的增长，在固定资源的情况下查询性能显著下降，尤其是在多表关联或复杂聚合查询中。这会导致长时间查询，增加了延迟和资源消耗，数据应用的用户体验受损，数据分析结果不能正常产出进一步影响业务实时性。
大规模集群中节点故障发生时，Presto 的容错机制相对较弱。某个节点崩溃可能导致查询失败或重新执行。此外，恢复数据可能需要大量时间，增加了服务的不可用时间。
2.难以处理峰谷场景，带来大量资源浪费
NinjaVan 的业务场景在夜晚有更多的离线 ETL 作业，在白天有更多的 BI 在线分析查询。在不同开源大数据方案组合和非一体化资源管控的情况下，难以做到精细化的库存资源管控。面对高峰时期会面临提前拉起过多的资源或者没有来得及拉起足够的起源应对流量的陡增，面对低谷场景会面临无法及时释放掉资源造成资源的浪费。
3.难以应对多组件带来的运维复杂性及降本难度
为了高效处理海量物流订单数据，NinjaVan 曾尝试在原有的数据平台架构基础上，引入新的大数据组件，修补之前遇到的问题。然而，不断堆叠的各类大数据组件，让整个平台的使用和运维非常复杂。因为在组装式的架构中，每个引擎都是独立开发和运维的，它们之间可能存在不同的系统设计优化方向。当业务需要调整引擎之间的配置时，例如重新平衡数据新鲜度、性能和成本之间的关系，需要进行复杂的修改和重复开发工作。这增加了调整的复杂性和耗时，使得数据架构调整的周期较长，效果也不是很令人满意。
4.难以迁移海量的数据和复杂的作业
为了高效处理海量物流订单数据，NinjaVan 曾尝试一些新的架构来优化离线加速和在线分析加速。然而，无论是往 Bigquery 等引擎上迁移，还是往阿里大数据平台体系做迁移，都面临产品对标对应的问题。比如 NinjaVan 有大量的 Ariflow pySpark 作业以及 Metabase 上使用了大量的 Presto Syntax Query。在做相应任务和 SQL 兼容迁移难度上受到非常大的挑战，迁移方案需要投入大量人力和资源进行作业改造、数据对比验证等，迁移成本极高。NinjaVan 急切需要一个多云适配且数据湖兼容的嵌入式迁移方案。
改造目标
NinjaVan 需要构造一个迁移代价低、性能优秀且具有资源弹性能力的 Lakehouse 一体化数据平台，获取迁移代价、性能、成本和易用性的最优解。
云器科技成立于 2021 年，是一家多云及一体化的数据平台提供商，团队成员主要由来自阿里云、字节、微软、Oracle 等国内外顶尖云计算与大数据企业的资深技术人员组成。自研基于增量计算的云湖仓——云器Lakehouse，能够让数据平台架构更简单、数据更开放、分析更灵活。
为了支撑 NinjaVan 十年来的业务增长，并在数据处理的时效性、性能、成本和易用性等方面获得显著优化，NinjaVan 经过反复的探讨和验证，最终发现如果继续基于开源路线，采取对原有数据平台打补丁的方式，无法从根本上解决上述问题，因此迫切需要引入一套针对 Lambda 开源组合架构替换的的全新的数据平台架构和技术体系。该方案需要以较低的代价迁移 NinjaVan 的存量业务，并获得显著的痛点解决效果。最终 NinjaVan 基于云器科技自研的 Lakehouse 一体化数据平台，为其需求找到了最佳解决方案。
云器解决方案
演进路径
图：NinjaVan项目演进整体路径
图：NinjaVan基于云器科技产品升级后的Lakehouse一体化数据平台架构
NinjaVan 基于云器科技产品升级后数据平台采用了湖仓一体的架构，以强大的数据湖兼容能力和优秀的湖上查询加速，结合多重技术优化，让 NinjaVan 能够以较低的成本以单引擎同时应对超大规模的离线计算和在线 BI 分析。云器引擎嵌入数据湖的数据架构升级方案，具体而言，新的数据平台在以下多方面进行了显著的技术创新，来实现这一目标。这个主要基于以下几点考虑：
需要使用湖仓一体存算分离架构的设计，让云器Lakehouse引擎能够直接嵌入客户已有数据湖，免除数据搬迁，直接接入元数据形成一个统一元数据基础层次。
直接兼容原有 workloads，无论是 spark 任务还是 SQL，都能做到兼容与渐进性迁移。
要求优秀的引擎性能，能够让客户的BI团队享受秒级实时的数据分析结果，增强业务实时度。
需要新平台根据负载动态可变的弹性集群伸缩能力，能够支持动态业务峰值的探索需求，按需使用，毫秒响应。
1.需要兼容数据湖数据格式，需要新引擎具备数据湖兼容能力
图：云器Lakehouse兼容主流开放存储格式
图：云器Lakehouse开放的多方案接入架构
NinjaVan 存储了近10年的海量存量数据，搬迁数据代价极大，同样线上业务也不能因为搬站而中断，从而引申出 2 个关键决策点。ETL 的存量 DeltaLake 数据需要一个低代价兼容方案，BI 在线翻译也同样需要直接基于湖的查询加速低代价方案，两者都希望尽可能减少迁移代价。云器提供了强大的数据湖兼容能力和开放性，多种数据湖嵌入方案，进行查询加速，基于数据湖的嵌入完全不需要搬迁存量数据。同样后续也可以顺滑的扩展到Lakehouse的内表数据（同样基于湖仓一体的存储），以获取更好的的查询性能。
External Schema：数据湖文件+Meta库 Lakehouse嵌入方案（Parquet File on DataLake+HMS）
Volume：数据湖文件 Lakehouse嵌入方案（Parquet File on DataLake）
External Table：数据湖文件+Meta文件 Lakehouse嵌入方案（Delta File on DataLake）
云器的数据湖兼容能力使 Lakehouse 引擎能够直接嵌入客户已有数据湖，免除海量存量数据的搬迁，直接接入元数据形成一个统一元数据管理。
2.直接兼容原有 workloads，需要 Zettapark 兼容能力 + sqlglot 兼容能力
NinjaVan 原来的 Airflow 方案中存在上千个 ETL task，在 Metabase 上有上千个存量报表，搬迁非常困难。云器通过 Zettapark 和 sqlglot 的兼容能力，在兼容绝大部分的 workloads 前提下，分别同时极大降低了 ETL 离线计算任务和 BI 在线分析报表的迁移代价。
2.1 Zettapark
图：云器 Airflow+pyspark接入方案 -> Zettapark
Zettapark 是一个用于处理云器 Lakehouse 数据的 Python 库。它提供了一个高级的 Python API，用于在云器 Lakehouse 中执行 SQL 查询、操作数据和处理结果。Zettapark 使得在 Python 中使用云器 Lakehouse 变得更加简单和高效。用户可以使用 Zettapark 执行 SQL 查询、操作数据和处理结果，就像在 Python 中使用 pandas 一样。
在Zettapark中执行pandas操作，会被翻译成SQL在云器Lakehouse中执行，从而达到分布式计算。
df_filtered = df.filter((F.col("a") + F.col("b")) < 10)SELECT a, b FROM ( SELECT col1 AS a, col2 AS b FROM VALUES (CAST(1 AS INT), CAST(3 AS INT)), (CAST(2 AS INT), CAST(10 AS INT))) WHERE ((a + b) < CAST(10 AS INT)) LIMIT 10;Zettapark 支持以极低的成本进行业务迁移（代码更改不到1%）
2.2 sqlglot
基于该方案用户只需将 PrestoDriver 替换为云器 Driver，无需改动 Metabase 上的存量报表。
图：云器 Metabase接入方案 -> 云器Driver + sqlglot
图：Presto Queries Syntax 兼容性 （接近99%语法兼容性支持）
3.需求极致性能与弹性，完成面向BI的稳定性和查询延迟的优化
为了进一步提升即席查询的响应效率，云器科技还针对查询性能进行了大量优化，如查询计划优化、采用 Share-everthing 架构提高读写性能、算子优化、向量执行等，从而获得了查询性能的大幅提升。优秀的引擎性能，能够让 NinjaVan 的 BI 团队享受大幅性能提升的分析结果，增强业务实时度。
图：云器Lakehouse数据平台查询优化的效果
4.通过库存管理能力及弹性扩缩容能力，建立面向负载弹性的资源使用新模式
4.1库存管理能力
云器Lakehouse 的库存管理能力支持根据库存水位动态识别库存的占用，保持实际库存以一个合适的比例略高于实际使用的资源比例。基于这个能力，云器Lakehouse 可以在库存足够的情况下在业务高峰动态自动扩容拉起对应的资源，同时也可以在业务低谷缩容后保持较低的资源库存以减少不必要的成本开销。
图：新的数据平台库存管理的效果
（绿色为购买的云资源，即库存；橙色为虚拟计算集群实际使用的资源）
4.2计算资源（Virtual Cluster）弹性扩缩容
虚拟计算集群（Virtual Cluster，简称：VC或集群）是云器Lakehouse 提供数据处理、分析的计算资源对象。虚拟计算集群提供在 Lakehouse 中执行 SQL 作业所需的 CPU、内存、本地临时存储（SSD 介质）等资源。集群具备快速创建/销毁、扩容/缩容、暂停/恢复等特点。
通过横向弹性扩容支持多并发查询。在库存足够的前提，云器Lakehouse 支持秒级扩容多个 replica 的 VC 以适配业务高峰（如 NinjaVan 的周初、月初等）BI 并发陡增的场景。
图：云器Lakehouse VC 弹性扩展能力架构图
同时除了以上几点，新的数据平台以一套引擎，统一离线、实时、交互式分析三种计算形态，统一数据存储和管理，统一数据开发、统一数据服务。NinjaVan 因此可以在一个一体化的数仓架构中用一套 SQL 同时开发离线和在线分析任务，降低了开发难度和运维成本，也减少了数据冗余和数据不一致等问题。同时也给未来的实时集成迁移改造的性能提升和成本优化铺好了路。
数据平台升级后的效果与价值
NinjaVan 积极探索全新的数据平台方案以低成本支撑 10 年快速增长的业务，从而满足 Business Intelligence 获取数据处理时效性、性能、成本和易用性的最优解。通过采用云器科技的 Lakehouse 一体化数据平台产品，NinjaVan 实现了以下主要的效果与价值：
技术价值
查询加速
ETL场景下，Lakehouse 基于数据湖的 Delta 文件进行湖上离线计算加速，相比于 Spark 提升了 6X 倍的性能。并且也可以低代价的扩展到 Lakehouse 的内表数据，同样基于云对象存储加 Lakehouse 自研的 compaction 和 meta stats 等，以获取更好的的查询性能。
图：Spark VC 云器Lakehouse ETL Pipeline平均耗时曲线
BI场景下，云器通过 ExternalSchema 进行了湖上 BI 在线分析查询加速，在随机抽样 1000 条 query 压测和 pattern 接近的 1000 条 query 压测场景中分别达到平均 5.3X 倍和 7.4X 倍的性能提升。总体性能相较于原 Presto 查询方案提高 2-10X倍。
图：云器Lakehouse数据平台查询优化的效果对比
成本大幅降低
动态库存管理极大解决了 NinjaVan 的峰谷情况（夜晚 ETL、白天 BI 查询）。以峰谷浮动明显的 BI 为例，库存管理可以支持 2min 内购买 ECS 拉起 Lakehouse 计算资源。当库存足够的情况下不同 VC 的扩容可以支持 1s 内拉起资源。Lakehouse 通过更优秀的性能和更优秀的资源控制使总成本降低至三分之一。
渐进式迁移
NinjaVan 通过 Lakehouse，在不需要搬迁数据的前提下，以平滑的方式接入了存量的 workloads。基于 Lakehouse 的数据湖兼容能力和生态兼容方案，NinjaVan 原方案上千个 ETL task 代码改动量小于 1%，Metabase 上的上千个存量报表无须修改通过替换 Lakehouse Driver+sqlglot 直接使用。同样也给后续进一步的性能和成本优化提供了空间。
业务价值
稳定快速的BI报表为业务高峰期提供更强大的支撑
云器Lakehouse 的性能提升和业务高峰的快速弹性扩容能力，大幅提升 NinjaVan 月初、周初业务大量数据集中分析的体验，显著降低了 BI 业务人员及 NinjaVan 合作伙伴对高峰期数据分析过慢延迟等问题的意见和投诉。
图：任务数量&VC replica数量
提升开发效率、简化使用门槛
平台一体化的架构免去了 NinjaVan 原先需对复杂的大数据组件进行维护的工作。在新的平台中，用户可以用一套 SQL 进行数据开发，以及 Lakehouse Studio 提供的业务观测告警等功能，让整个数据开发工作变得更简单，业务协作更高效，使 NinjaVan 的 BI 部门可以更专注于数据价值本身的分析和挖掘。
总结与展望
NinjaVan 的大数据平台建设随企业发展经历了 10 年，形成了当前基于开源自建的 Spark+Flink+Presto+DataLake 的架构，存在低性能、架构复杂、维护成本高的问题。NinjaVan 在思考下一代数据平台演进的时候，考虑与云器一起探索，经过 PoC 和部分生产验证，形成了基于湖仓一体、高性能、离线实时一体化的新一代架构，并最终达成 6 倍 ETL 性能提升，2x-10x BI 性能提升的业务效果。升级过程充分考虑了保护原有投资和低业务风险，做到了兼容模式引入新引擎，业务无感切换。
同时经过审慎思考放弃全自建模式，以托管为主+自建补充的方式，提升 SLA 并释放人力，更专注业务和创新。
NinjaVan 通过云器Lakehouse 在当前的业务场景下在使用体验、成本等方面已经取得了显著的效果。未来，基于新一代开放的 Data+AI 架构，NinjaVan 也将继续探索和应用新的技术和工具，不断提升数据的实时性和全域洞察以及利用云器Lakehouse 的 AI 能力挖掘、探索非结构化数据的价值，为企业决策提供更加有力的支持。