hf200012-CSDN博客

原创零成本迁移，原地加速，成本降低60%：火花思维基于云器Lakehouse升级实践

火花思维技术团队通过引入云器Lakehouse引擎，成功解决了开源Spark在性能、成本和AI能力方面的瓶颈。采用分阶段升级策略，首先通过外表模式实现"零迁移、换引擎"，保持原有数据存储和平台不变，仅替换计算引擎。实际生产数据显示：高消耗任务性能提升3-10倍，计算成本降低60%以上，数据时效从T+1提升至H+1，且迁移工作量趋近于零。这一升级不仅实现了降本增效，还为后续Kappa架构演进和Data+AI应用奠定了基础，展现了"换引擎不换车"技术路径的有效性。

2026-03-25 09:23:31 379

原创当千亿数据遇上增量计算：拆解云器科技与快手的技术共创——从快手GIC实践，看新一代数据处理范式的真实落地

当上游数据在不断发生变更的时候，通过只计算数据变化的部分，与之前的查询结果合并，快速的生成对应的最新查询结果，是继批处理、流计算和交互计算之后的新一代数据处理流程，能避免Lambda架构的缺点，实现Kappa架构。查询的计算时间很大程度取决于执行了多少种复杂的计算，算子的组合复杂度（Join，agg，window等）是一个重要的衡量指标，例如在计算Outer Join的时候，增量数据需要与大量的历史数据进行连接，并且在右表更新时，需要回撤之前补NULL的部分计算结果，会导致链路产生大量的更新操作。

2026-03-25 09:18:35 560

原创美团 x 云器｜从美团BI平台升级看数据引擎架构升级演进路径

美团BI平台基于云器Lakehouse实现架构升级，从多引擎架构演进为统一单引擎架构。通过C++向量化执行、通用增量计算等技术创新，在同等资源下实现查询性能提升至原来的3倍；采用VirtualCluster虚拟集群技术，资源利用率提升60%；遵循"不搬数据、不改SQL、不迁任务"原则，实现平滑升级。该实践验证了新一代BI平台对统一引擎、高性能计算和资源弹性的核心诉求，为行业提供了可复制的技术路径。

2026-03-22 19:14:20 667

原创云器Lakehouse基于增量计算+实时湖仓构建小红书实验数仓生产新范式

随着移动互联网内容生态爆发，带来小红书日均千亿级的流量日志增长，与此同时，算法实验迭代的时效要求也在持续提高，传统的数据架构难以在低成本和低延迟之间取得很好的平衡。小红书与云器科技合作，基于增量计算与数据湖技术，以通用增量计算方案构建了一套近实时实验数仓体系。实践显示，该方案在满足实时业务需求的同时，带来了更少的资源投入，更准确一致的数据，更简洁的流批一体链路，更好的查询性能等优势，为后续大范围构建全域近实时数仓体系奠定基础。近年来，移动互联网用户的内容生态呈现出爆发式增长的趋势，一方面，用户规模持续扩张，

2025-05-19 21:16:14 1383

原创性能超越Spark 13.3 倍,比某MPP整体快数十秒 | 多项性能指标数倍于主流开源引擎 | 云器科技发布性能测试报告

🏅增量计算：云器Lakehouse支持秒级、分钟级、小时级的数据新鲜度调节。相较于Flink常驻任务，云器Lakehouse可通过调整时效性平衡资源成本，在近实时场景下可节省10倍~1000倍的成本。🏅实时分析：在基于宽表的实时分析场景下，云器Lakehouse相较Clickhouse表现出1.48倍性能提升。🏅离线批处理：在复杂批处理任务中，云器Lakehouse相较Spark表现出13.31倍性能提升。🏅即席查询：在交互式分析场景下，云器Lakehouse相较Trino表现出9.84倍性能提升。

2024-11-18 18:27:51 603

原创比流计算资源效率最高提升 1000 倍，“增量计算”新模式能否颠覆数据分析？

面向未来，我们认为结构化数据处理分析的趋势会是，由一个一体化的引擎，统一“流”、“批”和“交互分析”，进而提供统一接口、统一处理逻辑，提供多种优化指标的高覆盖度和灵活调整的能力。单表聚合场景和双流join场景，由于要考虑历史数据/状态，属于“带历史状态计算”，调度间隔时间的调整会很大程度上影响计算资源的消耗，从图12右1右2两张图可见，云器Lakehouse在10秒调度间隔下做到持平，在30秒或调至1小时的准实时调度间隔，性能的节省可以达到百倍甚至千倍。调度增量计算的时间间隔，是由用户根据需要调整设定的。

2024-11-10 11:54:03 1053

原创全面超越Spark，Clickhouse，比 Spark 快 900%，基于云器Lakehouse构建新一代一体化数据平台

这其中的背景是，数据的第一波增长源自于数据库，例如账单报表类的数据，虽然数据量较小，但对于银行等机构来说具有很高的价值。第三，大幅降低使用数据平台的门槛（通过自然语言和数据平台交互），数据平台可以突破原有的限制，开放给所有人，例如高管可能不会写 SQL 或编程，但通过大模型，可以轻松与系统进行沟通。云器科技的一体化平台，在数据分析部分，通过引入新的计算范式——增量计算，统一了流计算、批处理和交互分析，不同分析场景下，云器的性能比批处理引擎 Spark 快了九倍，同时超越交互分析产品 ClickHouse。

2024-10-17 21:22:20 1656

原创原来CDC数据同步可以这么简单，零代码可视化一键数据同步

这种方式比较简单直接，但存在两项弊端：其一，在数据量特别大的时候且业务复杂度高的情况下，涉及到比较复杂的关系查询，比如多表 join ，查询性能会遇到瓶颈，一条 SQL 可能需要很长的时间才返回，满足不了实时分析的交互诉求；本次演示数据中也模拟设计了类似情况，在源端两张表里去查询 ID ，可以看到同样的主键 ID 取值，在不同的表里分别会有一条记录，这会给同步过程带来了挑战：在合并写入到目标端时，如果是只按 ID 作为主键，这两条记录就会被尝试写入到一条记录中，会产生数据冲突的情况。

2024-10-13 22:14:56 1375

原创 AI Native Data Stack 系列终篇：数据平台变成智能操作系统之后，数据团队要去哪里？

AI Native Data Stack 的建设，表面上看是数据平台升级，往深处看，其实是企业组织能力升级。它要求企业重新理解几件事：数据不只是资产，也是 AI 推理的事实基础。语义不只是说明文档，也是机器理解业务的接口。模型不只是算法服务，也是需要治理的认知能力。智能体不只是对话入口，也可能成为业务流程里的执行单元。治理不只是合规要求，而是 AI 进入核心业务的前提。数据团队也不只是技术支撑部门，而会成为企业智能能力的建设者。

2026-08-15 21:05:21 399

原创 AI 时代，通用增量计算将从一种计算优化技术，演进为 AI 基础设施(AI Native Data Stack 系列五）

本文探讨了企业AI系统中增量计算的核心价值与技术边界。文章指出，企业AI面临的关键挑战不仅是数据访问能力，更是如何持续维护可信的派生状态：当源数据变化时，系统需要以可控成本高效更新相关结果，并明确标注状态版本和一致性边界。作者剖析了增量计算的本质是处理ΔD→ΔR的转换，同时强调其并非万能方案，需与批处理、流计算协同使用。通过小红书、美团、快手等案例，论证了大型业务对增量化的实际需求。最后提出分层架构：底层Lakehouse负责数据状态维护，上层系统处理语义解释、知识更新和业务决策，二者通过版本化状态和治理规

2026-08-15 21:02:44 194

原创从 ChatBI 到 Decision Agent：企业决策链路正在被 AI 重写(AI Native Data Stack 系列四）

《从数据到决策：DecisionAgent如何重构企业智能决策链路》文章提出企业数字化正从"数据基建"迈向"决策智能"阶段，通过四层架构构建AINativeDataStack： Lakehouse统一数据底座 SemanticLayer统一业务语义 DataAgent自动化数据工程 DecisionAgent实现决策闭环核心观点认为ChatBI仅解决"分析洞察"，而真正的决策需要完整行动链路（目标诊断→根因分析→方案模拟→执行反馈）。Decis

2026-07-16 10:16:34 354

原创 Data Agent：为什么 AI 不只是问数，而是开始接管数据工程(AI Native Data Stack 系列三）

本文系统探讨了AI时代数据工程范式的转型，提出DataAgent正在成为下一代数据工程操作系统的核心组件。文章指出：1. DataAgent超越传统ChatBI，具备业务意图理解、任务规划、工程实施、运行观测和持续优化的闭环能力；2. 其实现依赖三大基础架构：Lakehouse提供统一数据基础设施，SemanticLayer构建企业知识底座，AgentRuntime形成执行体系；3. 行业实践表明，DataAgent正从问答工具演变为能接管开发、运维全流程的生产系统；4. 未来数据工程将转向"Ag

2026-07-16 10:16:20 438

原创 Semantic Layer 的终局：AI 时代的 Enterprise Cognitive Layer（AI Native Data Stack 系列二）

企业AI应用面临的核心瓶颈并非模型能力，而是缺乏结构化的企业知识。当前ChatBI产品在基础查询时表现尚可，但面对连续业务追问（如分析销售额下降的具体原因）时往往失效，暴露出AI难以理解企业内部业务概念、规则和经验的问题。传统数据架构的Gold层解决了数据治理问题，但无法满足AI对业务语义的需求。语义层(Semantic Layer)正经历第三次演进：从BI时代的指标统一，到Lakehouse时代的数据消费层，最终发展为AI时代的"企业认知层"。这一层需要整合六大核心要素：业务实体中心

2026-07-15 22:43:58 363

原创 Medallion Architecture（大奖牌架构）之后，下一代企业数据平台长什么样？（AI Native Data Stack 系列一）

企业数据平台从传统数仓、Hadoop演进到Lakehouse架构，通过Medallion分层解决了数据孤岛、可信度和复用性问题。但AI时代暴露出新瓶颈：Gold层数据无法让AI真正理解业务逻辑和决策规则。下一代平台需在数据治理基础上构建"知识层"，通过语义模型、业务流程、决策规则等结构化表达企业认知，支撑AI推理与行动。主流厂商已开始布局语义层和本体论，未来架构将形成"数据+知识+Agent"的复合体系，其中Lakehouse仍是基石，而知识层将成为AI消费企业认知的

2026-07-15 22:43:06 343

原创企业过去建设的数据平台，本来就是给人用的，不是给 Agent 用的 [企业数据平台下一阶段终篇]

前六篇，我们一直在回答同一个问题：为什么企业的数据平台必须演进。从降本，到迁移；从旁路接入，到四个“不动”；这也是这一篇要回答的问题。很多企业今天都会有一种困惑：我有数据湖，有数仓，有 BI，有实时计算，也搭了不少数据服务。为什么到了 AI 这一步，平台还是显得不够用？问题不一定出在“数据不够多”，也不一定出在“算力不够强”。这不是一次简单的功能升级，而是一次基础设施假设的切换。

2026-06-25 14:47:14 319

原创你的 ChatBI 为什么总答不准？真问题可能不在模型，而在企业还没把语义层建起来

企业自然语言查询系统面临的核心挑战并非技术模型能力不足，而是缺乏有效的企业语义层建设。当前ChatBI演示效果良好，但在实际业务中常出现指标口径偏差、权限越界等深层问题，根源在于企业业务语义未被系统化建模。理想的语义层需包含业务本体、指标定义、权限治理等多维度结构，通过分层处理（语义理解→规划→执行）替代简单的NL2SQL转换。云器Lakehouse等实践表明，准确率提升需依赖可信数据底座、多智能体协作和治理前置。未来竞争关键不在于模型强弱，而在于谁能率先构建可理解、可演进的业务语义系统，这将成为企业AI落

2026-06-25 14:46:46 313

原创从 Medallion Architecture 到 AI Native Data Stack：企业数据平台如何从 BI 底座升级为 AI 决策底座

因为 AI 进来之后，企业面对的已经不只是“让更多人看懂数据”。这不是报表层的一次小修小补，更像一次“操作系统级”的重构。过去十年，企业数据平台主要在做一件事：从分散走向统一，从数据仓库走向 Lakehouse。未来三到五年，真正重要的变化，是它会继续从往上长，变成，再进一步变成。

2026-06-25 14:46:34 258

原创为什么统一引擎正在替代 Hadoop 时代的多引擎架构[企业数据平台下一阶段六]

《数据平台演进：从多引擎拼装到统一计算模型》本文探讨了数据平台架构的演进趋势，指出多引擎架构曾是Hadoop时代的必然选择，解决了计算能力、扩展性和开放生态问题。但随着企业数据规模增长和AI时代到来，多引擎带来的数据复制、开发运维复杂度、一致性问题日益凸显，尤其影响智能系统的决策可靠性。统一引擎的核心并非替代所有功能，而是通过统一计算模型（如增量计算）减少链路分裂，降低系统复杂度。案例显示，这种转型能提升性能、降低成本，并增强数据一致性。未来数据平台将趋向开放存储、统一中间层和语义化上层，从“拼能力”转向

2026-06-18 08:36:27 355

原创 AI时代的数据平台升级，为什么必须遵循“四个不动”原则[企业数据平台的下一阶段五]

摘要：数据平台升级的新范式——从"大迁移"到"持续演进" 传统数据平台升级依赖"大迁移"模式，但在AI时代面临根本性挑战：业务需求快速变化、计算负载日益复杂、迁移成本高昂。云器Lakehouse通过"四个不动"原则（数据、逻辑、消费、组织）重构升级路径，在火花思维、高途教育、美团等案例中验证了渐进式演进的价值。其核心在于：1）保持历史数据资产不动，通过外表加速实现引擎替换；2）保护企业积累的SQL逻辑和指标体系；3）确保消费层接

2026-06-18 08:36:05 246

原创企业数据平台真正昂贵的，不是机器，而是迁移成本[企业数据平台的下一阶段四]

本文揭示了企业在评估数据平台成本时普遍存在的误区——过度关注显性的运行成本（如云资源、存储等），而严重低估了系统迁移带来的隐性成本。文章指出，真实的平台成本应包括运行成本、变更成本、迁移成本和风险成本四个维度，其中迁移成本往往最为昂贵且容易被低估。通过具体案例测算，作者证明了一个典型企业数据平台的迁移成本（包括SQL重构、双系统并行、人工对账等）可能高达250万元，远超每年60万元的运行成本节省。这种成本主要由业务逻辑迁移、数据结构迁移、BI消费层迁移和组织迁移等多个层面构成，且会随着系统成熟度呈指数级增

2026-06-16 14:46:21 468

原创为什么“旁路接入 + 双发验证”会成为数据平台升级的新标准 [企业数据平台的下一阶段三]

企业数据平台升级面临"不敢停业务、不敢直接改系统"的困境，传统全量迁移风险高，局部改造易导致系统割裂。新兴的"旁路接入+双发验证"方案提供渐进式升级路径：在不影响现有系统前提下，通过数据旁路、计算旁路和语义旁路三层架构引入新系统，配合持续比对验证机制建立信任。这种方法将升级从高风险迁移工程转变为可观测、可验证的在线演进过程，尤其适合AI时代快速迭代的需求。以云器Lakehouse为代表的解决方案通过"数据不动、任务不搬"的方式实现平滑过渡，其公开案

2026-06-16 14:45:53 338

原创 [企业数据平台的下一阶段二]为什么越来越多企业，不敢再做“大迁移”

说到这里，也要讲清楚一个边界。这篇文章不是说，大迁移以后完全不会发生。在一些场景下，彻底替换仍然是必要的。比如旧平台已经无法维护、技术债高到失控、组织决心足够强，或者企业本身处在一次系统重构窗口期里，这些情况下，大迁移依然成立。但它不再适合作为默认选项了。更现实的顺序会变成：先验证能不能在存量之上演进；再判断是否需要扩大替换范围；最后才决定是否进入更彻底的重构阶段。也就是说，未来企业升级数据平台，不会一上来就讨论“迁不迁”，而会先讨论“能不能先不迁”。

2026-06-09 10:13:35 192

原创 [企业数据平台的下一阶段一] 当 Hadoop 拼装架构越来越难支撑 AI，企业真正可行的升级路线，往往不是推倒重来，而是在存量之上做原地加速、旁路验证和渐进式收敛

在很多企业里，Hive 有一份 schema，Kafka 有一份 schema，Elasticsearch、ClickHouse、Redis、应用库、指标平台，各自都有各自的定义。它能生成 SQL，不代表它真的理解业务。所以 Unified Engine 的价值，不是抽象地说“统一”，而是把原本散落在离线、交互式、BI、实时链路之间的重复建设，逐步收回来。但这组数字背后更值得讲的，其实是场景判断：它并不是要先完成平台替换，而是面对作业多、迁移风险高、又急需控制成本的现实约束，先用最轻的方式把收益做出来。

2026-06-09 10:13:04 347

原创本体论语境下的 Semantic Layer：它在企业 AI 与 Data Agent 构建中的真实作用

现代语义层的重点，已经不仅仅是字段的说明，而是实现度量指标代码化（metrics-as-code）。换句话说，它真正管理的是：指标定义聚合语义可复用的指标有向无环图（DAG）维度约束时间智能规则语义下推能力如果不明确这部分内容，很难全面理解语义层的实际工程价值。因为在企业里，最困难的往往不是“收入”这个名称如何对应，而是更细节的问题，比如：收入是以订单级别还是发票级别为粒度？毛销售额和净销售额的粒度是否一致？某个关键指标是否允许同时按照渠道、区域、产品线等多个维度切分？

2026-05-22 10:33:12 637

原创为啥ChatBI 很难真正能落地

企业级ChatBI落地面临的核心挑战在于语义治理而非自然语言转SQL。演示产品虽能快速生成查询，但实际应用中常因业务口径混乱（如同名指标在不同部门含义不同）导致结果失准。关键在于构建统一语义层，通过指标中心、实体建模、业务域约束等机制，将原始数据转化为AI可理解的业务对象。有效方案需包含指标注册、强制消歧、权限控制等核心功能，分阶段从高频场景向复杂分析扩展。ChatBI的本质并非对话界面，而是企业语义基础设施的体现，其竞争力取决于组织对业务语义的标准化程度。

2026-05-22 10:32:35 569

原创 Agent 应用范式下，企业数据基础设施正在重写：为什么云器 Lakehouse 会成为 AI 时代的数据底座

AI正加速从试验走向企业生产应用，Gartner预测到2026年80%企业将使用生成式AI，AI Agent市场规模将达526亿美元。传统数据基础设施面临三大挑战：时效性不足、语义层缺失、执行闭环能力弱。未来数据平台需向语义数据系统演进，具备统一增量计算、业务语义表达和AI原生能力。云器Lakehouse的创新在于将变化处理、语义理解和AI执行整合，为Agent应用提供实时、低成本的数据底座。企业数据基础设施正从BI支撑系统转型为Agent驱动的智能业务操作系统。

2026-05-15 21:11:07 590

原创从 Palantir Ontology 到企业 AI 决策系统

企业AI落地面临的核心挑战是模型难以真正理解业务语义并安全执行决策动作。Palantir的Ontology方法通过构建业务对象体系，将数据、规则、动作和治理统一建模，使AI能在受控环境下参与核心运营决策。该方法强调从静态语义层转向可执行的运营层，通过对象化建模、逻辑绑定、动作触发和闭环反馈，解决企业AI"能看不能做"的痛点。但该方案存在建模复杂度高、组织协同难、平台依赖强等实施门槛，更适合系统复杂、治理要求高的核心业务场景。企业AI向决策系统演进的关键在于构建统一的世界模型，而非单纯追求

2026-05-15 13:08:10 493

原创 Data Agent（ChatBI）生产落地：从“能演示”到“可规模化落地”

本文探讨了面向数据分析的对话式智能体(ChatBI/DataAgent)的发展现状与关键技术。文章指出，当前ChatBI正从基础的自然语言转SQL功能向"语义层+治理+Agent工程化"方向演进。为实现生产可用性，系统需具备正确性可控、口径一致、安全合规等工程属性，并推荐采用NL2DSL/NL2Metric架构路线，通过语义层约束模型输出。核心在于构建可治理的语义层，包含指标、维度、实体关系等元素，并配合检索增强生成(RAG)技术解决歧义问题。企业落地需从数据底座、语义层建设、权限治理、

2026-05-07 17:55:45 413

原创深入分析：Iceberg v3「删除向量（Deletion Vectors, DV）」如何缓解 CDC 场景写放大

把 v2 position delete files 在 CDC 下的“小文件爆炸”压到“单文件位图聚合”形态（减少 delete 表示层写放大）。把“删除/更新旧行”的数据层写入从“重写大数据文件”降为“写压缩 bitmap + 少量元数据”。降低了为了合并 delete files 而产生的运维性写放大（rewrite_position_delete_files/小文件合并压力）。UPDATE 的“新增行写入”仍然存在（新版本行必须落新文件）。

2026-04-21 23:39:18 316

原创 Apache Iceberg vs Apache Paimon ：数据湖表格式深度对比与选型指南

摘要： Apache Iceberg 和 Apache Paimon 是两种主流的数据湖表格式，分别针对不同场景优化。Iceberg 以开放性和多引擎兼容性为核心，v3 版本引入删除向量（BinaryDeletionVectors）、行级血缘（RowLineage）和半结构化支持（VARIANT），适合跨云、多引擎协作的企业级湖仓。Paimon 则基于 LSM-Tree 架构，专为流式处理设计，支持高效 Upsert、CDC 入湖和实时消费，与 Flink 深度集成，适合高频更新的流式场景。选型建议： I

2026-04-21 23:38:48 777

原创硬件越涨越贵，数据平台怎么省钱？拆解云器 Lakehouse 的降本底层逻辑

摘要：2025年起全球云服务和存储芯片价格大幅上涨，企业数据平台成本压力剧增。云器Lakehouse通过Serverless按秒计费、存算分离、一体化架构等方案有效降低TCO：1）计算成本节省50%+；2）存储扩容独立管理；3）网络费用优化；4）隐性运维成本减少。火花思维案例显示，该方案可实现零迁移成本、性能提升3-10倍的同时降低60%费用。建议企业从工作负载盘点入手，采用隔离资源池、智能缓存等策略，将固定成本转为可度量的按需支出模型。（149字）

2026-03-30 17:49:58 553

原创从“BI支撑”走到“AI驱动”：企业数据底座该怎么重做？

选 1~2 条最关键链路（实验/增长/风控/推荐等），把全量重算改成增量化，先把新鲜度做出来。把 Catalog、权限、口径这些治理要素统一起来，至少让数据资产“可发现、可解释、可复现”。选一个能闭环的 AI 场景（对话式分析、运营 Copilot、知识问答等），用 Data Agent 把流程跑起来，而不是只做Demo。等你这三件事跑顺了，再谈“统一智能基座”，就不是概念了。

2026-03-30 08:02:22 403

原创增量计算不是“更快的离线”：四个头部案例告诉你，数据架构升级真正的胜负手

摘要：本文通过分析美团、小红书、快手、数美科技四个企业的实践案例，揭示了增量计算在数据架构升级中的关键价值。研究表明，增量计算的核心优势在于将"变化"作为一等公民，通过"只为变化付费"机制，在分钟级/小时级延迟下实现成本、一致性和复杂度的平衡。四个案例分别展示了单引擎统一、近实时数仓、离线改增量和半结构化查询等典型场景，其共性在于通过增量计算消除"双体系"架构，降低组织协作成本。文章指出，增量计算的成功落地需要关注数据变化形态、成本曲线控制和存量资

2026-03-25 13:45:24 451

原创技术深度报道：解析云器Lakehouse如何实现超越Spark 10倍性能提升

在技术竞争的喧嚣中，我们常见各种性能指标的发布和对比，甚至争吵。”相比之下，即使启用AQE功能，Apache Spark的优化器在执行计划层面仍然无法进行这种深度优化，经常出现多读和重复读的情况，导致性能差距明显。“查询优化本质上是个NP完全问题，”关涛解释，“一个包含10个表的Join查询，理论上有超过17万种可能的Join顺序。同时，云器Lakehouse在存储层采用了现代湖仓一体化设计，基于自研的C++ Iceberg/Parquet读取器，直接消除了Java原生接口带来的JNI转换开销。

2025-03-27 20:20:49 1141

原创 NinjaVan x 云器Lakehouse: 从传统自建Spark架构升级到新一代湖仓架构

为了支撑 NinjaVan 十年来的业务增长，并在数据处理的时效性、性能、成本和易用性等方面获得显著优化，NinjaVan 经过反复的探讨和验证，最终发现如果继续基于开源路线，采取对原有数据平台打补丁的方式，无法从根本上解决上述问题，因此迫切需要引入一套针对 Lambda 开源组合架构替换的的全新的数据平台架构和技术体系。以前是使用开源自建大数据平台，随着数据和查询复杂性的增长，业务平台的建设已无法支持业务的增长，开始看向数据平台托管类商业化产品做选型，同时考虑 cost cutting 的需求。

2025-03-20 20:34:19 1467

原创云器Lakehouse：托管且开放的云湖仓，打造开源自建的全新升级之选

另外，借助一体化产品，端到端的集成工具有统一的使用体验，数据能够更容易的被业务方自助使用，扩大数据用户的覆盖范围，也能够扩展新兴场景。云器Lakehouse通过嵌入企业原有的数据湖的方案，在没有改动客户已有的数据管理体系情况下，通过元数据的打通，把云器Lakehouse嵌入其中，通过 serverless 的引擎方式，在原有的 Presto 报表分析和 Spark 的 ETL 场景中，把现有用户作业，通过调度系统，下发到云器Lakehouse 的 serverless engine 中，进行加工处理。

2024-12-06 13:46:27 1058

原创星盘跨境依托云器 Lakehouse 实现实时离线一体化、湖仓一体化数据架构升级，支持全域数据高效分析

在对多家厂商方案的沟通对比中，星盘关注到在大数据创业圈中具备良好口碑的云器科技，对云器实时离线一体、湖仓一体的极简数据架构理念非常认同，结合云器 Lakehouse 在实时计算 POC 中优秀的性能表现，最终选择云器 Lakehouse 作为新数据平台引擎。星盘作为出海跨境服务的初创企业，在近两年的业务发展中，以自身数据平台架构的升级为缩影，见证了跨境出海品牌对数据服务的强烈需求和跨境服务企业的巨大发展机遇。其中，开源厂商虽然能达成架构升级目标，但多个组件拼装、组合的方式显然会带来高昂的运维成本；

2024-11-21 21:56:37 996

Eclipse RCP入门

空空如也