首页 文章 精选 留言 我的

精选列表

搜索[安全加速 SCDN]，共10000篇文章
优秀的个人博客,低调大师

推理加速新选择！Xinference 1.16.0 支持瀚博 GPU 与持续批处理

Xorbits Inference（Xinference）是一个 性能强大且功能全面的 分布式 推理框架。可用于大语言模型（LLM），语音识别模型，多模态模型等各种模型的推理。通过 Xorbits Inference，你可以轻松地 一键部署你自己的模型或内置的前沿开源模型 - https://github.com/xorbitsai/inference。无论你是研究者，开发者，或是数据科学家，都可以通过 Xorbits Inference 与最前沿的 AI 模型，发掘更多可能。 Xinference 的功能和亮点有： 🌟 模型推理，轻而易举：大语言模型，语音识别模型，多模态模型的部署流程被大大简化。一个命令即可完成模型的部署工作。 ⚡️ 前沿模型，应有尽有：框架内置众多中英文的前沿大语言模型，包括 baichuan，chatglm2 等，一键即可体验！内置模型列表还在快速更新中！ 🖥 异构硬件，快如闪电：通过 ggml，同时使用你的 GPU 与 CPU 进行推理，降低延迟，提高吞吐！ ⚙️ 接口调用，灵活多样：提供多种使用模型的接口，包括 OpenAI 兼容的 RESTful API（包括 Function Calling），RPC，命令行，web UI 等等。方便模型的管理与交互。 🌐 集群计算，分布协同：支持分布式部署，通过内置的资源调度器，让不同大小的模型按需调度到不同机器，充分使用集群资源。 🔌 开放生态，无缝对接：与流行的三方库无缝对接，包括 LangChain， LlamaIndex， Dify，以及 Chatbox。 ———————————————————————— ———————————————————————— 🚀 Xinference v1.16.0 更新日志 ✅ 本次亮点 🧩 瀚博半导体 GPU（VACC）支持 新增对瀚博半导体 GPU 的支持，并扩展到 VLM（视觉语言模型） 场景，硬件生态进一步完善。 🍎 Apple MLX 后端支持持续批处理（Continuous Batching） MLX 聊天模型现已支持持续批处理，可并发处理请求，显著提升吞吐与并发性能。 🧠 新模型支持 * Qwen-Image-Layered * Fun-ASR-Nano-2512 * Fun-ASR-MLT-Nano-2512 ⚠️ Python 版本支持变更 从本版本开始，不再支持 Python 3.9，请使用 Python 3.10 及以上版本。 🌐 社区版更新 📦 安装方式 pip 安装：pip install 'xinference==1.16.0' Docker：拉取最新版镜像或在容器内使用 pip 更新 🆕 新模型支持 Qwen-Image-Layered Fun-ASR-Nano-2512 Fun-ASR-MLT-Nano-2512 ✨ 新特性 vLLM 后端：新增对 DeepSeek-V3.2 / DeepSeek-V3.2-Exp 的 vLLM 引擎支持 VACC（瀚博半导体 GPU）：支持 LLM 与 VLM 推理 MLX：聊天模型支持持续批处理，实现并发推理 Rerank：支持异步批处理（async batch） 模型启动：新增 architectures 字段 UI：图像模型支持通过环境变量与自定义参数配置 MiniMaxM2ForCausalLM：新增 vLLM 后端支持 🛠 功能增强 副本分配优化，GPU index 分配更连续 Docker 镜像升级至 CUDA 12.9，使用 vLLM v0.11.2 支持 torchaudio 2.9.0 模型元数据（JSON）持续更新（DeepSeek、GLM、LLaMA、Jina、Z-Image 等） 🐞 Bug 修复 修复 PaddleOCR-VL 输出异常 修复自定义 embedding / rerank 分析错误 修复 CPU 启动与多 worker 启动异常 修复 OCR API 返回为空的问题 修复 n_gpu 参数处理问题 📚 文档更新 更新新模型说明 补充 v1.15.0 发布文档 🏢 企业版更新 昇腾性能优化：进一步提升在昇腾平台上的推理性能与稳定性 微调功能增强：强化微调流程与能力，支持更复杂的企业级训练与调优需求 参考 中文：https://xinference.cn/release_notes/v1.16.0.html 英文：https://xinference.io/release_notes/v1.16.0.html ———————————————————————— ———————————————————————— 我们感谢每一位参与的社区伙伴对 Xinference 的帮助和支持，也欢迎更多使用者和开发者参与体验和使用 Xinference。 欢迎您在 https://github.com/xorbitsai/inference 给我们一个 星标，这样你就可以在 GitHub 上及时收到每个新版本的通知。
2025-12-30
优秀的个人博客,低调大师

数禾使用 Knative 加速 AI 模型服务部署丨KubeCon China 2023

作者：李鹏（阿里云）、魏文哲（数禾科技）， 此文基于 KubeCon China 2023 分享整理 摘要 AI 服务的数据、训练、推理等都需要消耗大量的计算资源以及运维成本，在数禾科技的金融业务场景下，模型存频繁迭代，线上也会同时部署多个版本的模型用于评估模型线上的真实效果，资源成本高。如何在保证服务质量基础之上提升 AI 服务运维效率并降低资源成本具有挑战性。 Knative 是一款基于 Kubernetes 之上的开源 Serverless 应用架构，提供基于请求的自动弹性、缩容到 0 以及灰度发布等功能。通过 Knative 部署 Serverless 应用可以做到专注于应用逻辑开发，资源按需使用。因此将 AI 服务与 Knative 技术相结合可以获得更高的效率并降低成本。 当前数禾科技通过 Knative 部署 500+AI 模型服务，资源成本节约比例 60%，平均部署周期由之前的 1 天缩短至 0.5 天。 在本次分享中，我们将向您展示如何基于 Knative 部署 AI 工作负载，具体内容包括： Knative 介绍 数禾基于 Knative 的最佳实践 如何在 Knative 部署 Stable Diffusion Knative 介绍 众所周知 Kubernetes 自 2014 年开源以来，受到众多厂商和开发者的关注，作为一款开源容器化编排系统，用户使用 K8s 可以做到降低运维成本、提高运维效率，并且其提供标准化 API，某种意义就是避免被云厂商绑定，进而形成了以 K8s 为核心的云原生生态。据 CNCF 2021 调查，96% 的企业正在使用或评估 Kubernetes。 随着云原生技术的演进，以应用为中心，资源按需使用的 Serverless 技术逐渐成为主流。Gartner 预测，2025 年将有 50% 以上的全球企业部署 Serverless。 我们知道以 AWS Lambda 为代表的 FaaS 将 Serverless 带火了。FaaS 确实简化了编程，只需要编写一段代码就可以直接运行，不需要开发者关心底层基础设施。但是 FaaS 当前也存在的明显的不足，包括开发模式侵入性强、函数运行时长限制，跨云平台的支持等。 而以 K8s 为代表的容器技术，恰恰已经很好的解决了这些问题。Serverless 的核心理念是聚焦业务逻辑，减少基础设施的关注。 那么如何面向开发者提供基于 K8s 开放标准的 Serverless 容器技术？ 答案是：Knative。 Knative 发展轨迹 Knative 是在 2018 的 Google Cloud Next 大会上发布的一款基于 Kubernetes 的开源 Serverless 容器编排框架。目标就是制定云原生、跨平台的 Serverless 应用编排标准，打造企业级 Serverless 平台。 阿里云容器服务也在最早 2019 的时候，已经提供 Knative 产品化能力，随着 2022 年 3 月加入到 CNCF，目前越拉越多的开发者拥抱 Knative。 Knative 概要介绍 Knative 核心模块主要包括部署工作负载的 Serving 和事件驱动框架 Eventing 。 Knative Serving 核心能力就是其简洁、高效的应用托管服务，这也是其支撑 Serverless 能力的基础。Knative 可以根据您应用的请求量在高峰时期自动扩容实例数，当请求量减少以后自动缩容实例数，可以非常自动化的帮助您节省成本。 Knative 的 Eventing 提供了完整的事件模型。事件接入以后通过 CloudEvent 标准在内部流转，结合 Broker/Trigger 机制给事件处理提供了非常理想的方式。 Knative 应用模型 Knative 应用模型是 Knative Service： Knative Service 中包含 2 部分配置，一部分用于配置工作负载，叫做 Configuration，每次 Configuration 内容更新都会创建一个新的 Revision。 另一部分 Route 主要负责 Knative 的流量管理。 我们看一下基于流量的灰度发布我们可以怎样做： 假设一开始我们创建了 V1 版本的 Revison，这时候如果有新的版本变更，那么我们只需要更新 Service 中的 Configuration，就会创建出 V2 版本，然后我们可以通过 Route 对 V1、V2 设置不同对流量比例，这里 v1 是 70%，v2 是 30%，那么流量就会分别按照 7:3 的比例分发到这两个版本上。一旦新到 V2 版本验证没有问题，那么我们接下来就可以通过调整比例继续灰度，直到新版本 V2 100%。在这个灰度到过程中，一旦发现新版本有异常，可以通过调整比例进行回滚操作。 除此以外，我们可以在 Route 到 Traffic 中对 Revison 打 Tag，打完 Tag 的 Revison，我们可以直接通过 Url 进行单独的版本测试，可以理解为金丝雀验证，对这个版本对调试不会影响正常对流量访问。 基于请求的自动弹性: KPA 为什么要做基于请求的自动弹性？ 基于 CPU 或者 Memory 的弹性，有时候并不能完全反映业务的真实使用情况，而基于并发数或者每秒处理请求数（QPS/RPS），对于 web 服务来说更能直接反映服务性能，Knative 提供了基于请求的自动弹性能力。 如何采集指标？ 要获得当前服务的请求数，Knative Serving 为每个 Pod 注入 QUEUE 代理容器(queue-proxy)，该容器负责收集用户容器并发数 (concurrency) 或请求数 (rps) 指标。Autoscaler 定时获取这些指标之后，会根据相应的算法，调整 Deployment 的 Pod 数量，从而实现基于请求的自动扩缩容。 如何计算弹性 Pod 数？ Autoscaler 会根据每个 Pod 的平均请求数（或并发数）进行所需 Pod 数计算。默认情况下 Knative 使用基于并发数的自动弹性，默认 Pod 的最大并发数为 100。此外 Knative 中还提供了一个叫 target-utilization-percentage 的概念，称之为目标使用率。 以基于并发数弹性为例，Pod 数计算方式如下： POD数=并发请求总数/(Pod最大并发数*目标使用率) 缩容到 0 的实现机制 使用 KPA 时中当无流量请求时，会将 Pod 数自动缩容到 0；当有请求时，会从 0 开始扩容 Pod。那么 Knative 中是如何实现这样的操作呢？答案是通过模式切换。 Knative 中定义了 2 种请求访问模式：Proxy 和 Serve。 Proxy 顾名思义，代理模式，也就是请求会通过 activator 组件进行代理转发。Serve 模式是请求直达模式，从网关直接请求到 Pod，不经过 activator 代理。如下图： 模式的切换是由 autoscaler 组件负责，当请求为 0 时，autoscaler 会将请求模式切换为 Proxy 模式。这时候请求会通过网关请求到 activator 组件，activator 收到请求之后会将请求放在队列中，同时推送指标通知 autoscaler 进行扩容，当 activator 检测到由扩容 Ready 的 Pod 之后，随即将请求进行转发。 应对突发流量 突发流量下如何快速弹资源 这里 KPA 涉及到 2 个与弹性相关的概念：Stable（稳定模式）和 Panic（恐慌模式），基于这 2 种模式，我们可以看到 KPA 如何快速弹资源。 首先稳定模式是基于稳定窗口期，默认是 60 秒。也就是计算在 60 秒时间段内，Pod 的平均并发数。 而恐慌模式是基于恐慌窗口期，恐慌窗口期是通过稳定窗口期与 panic-window-percentage 参数计算得到。*恐慌窗口期计算方式：恐慌窗口期=稳定窗口期 panic-window-percentage。 默认情况下也就是 6 秒。计算在 6 秒时间段内，Pod 的平均并发数。 KPA 中会基于稳定模式和恐慌模式 Pod 的平均并发数分别计算所需要的 Pod 数。 那么实际根据哪个值进行弹性生效呢？这里会依据恐慌模式下计算的 Pod 数是否超过恐慌阈值 PanicThreshold 进行判断。默认情况下，当恐慌模式下计算出来的 Pod 数大于或等于当前 Ready Pod 数的 2 倍，那么就会使用恐慌模式 Pod 数进行弹性生效，否则使用稳定模式 Pod 数。 显然，恐慌模式的设计是为了应对突发流量场景。至于弹性敏感度，则可以通过上述的可配置参数进行调节。 突发流量下如何避免 Pod 被打爆 KPA 中可以设置突发请求容量（target-burst-capacity）应对 Pod 被超预期的流量打爆。也就是通过这个参数值的计算，来调节请求是否切换到 Proxy 模式，从而面对突发流量时通过 activator 组件作为请求缓冲区，避免 Pod 被打爆。 减少冷启动的一些技巧 延迟缩容 对于启动成本较高的 Pod， KPA 中可以通过设置 Pod 延迟缩容时间以及 Pod 缩容到 0 保留期，来减少 Pod 扩缩容频率。 调低目标使用率，实现资源预热 Knative 中提供了目标阈值使用率的配置。通过调小该值可以提前扩容超过实际需要使用量的 Pod 数，在请求达到目标并发数之前进行扩容，间接的可以做到资源预热。 弹性策略配置 通过上面的介绍，我们对 Knative Pod Autoscaler 工作机制有了进一步的了解，那么接下来介绍如何配置 KPA。Knative 中配置 KPA 提供了两种方式：全局模式和 Revision 模式。 全局模式可以通过 ConfigMap：config-autoscaler 进行配置，参数如下： 阿里云容器服务 Knative 开源的产品一般都不能直接拿来产品化使用。Knative 产品化面临的问题包括： 管控组件多，运维复杂 算力多样性，如何按需调度到不同的资源规格上 云产品级别的网关能力 冷启动的问题如何解 。。 针对这些问题，我们提供了容器服务 Knative 产品。完全兼容社区 Knative，支持 AI 推理框架 KServe。增强弹性能力，支持保留资源池、精准弹性以及弹性预测；支持全托管 ALB、MSE 以及 ASM 网关；事件驱动方面与云产品 EventBridge 进行集成；此外与阿里云其它产品，如 ECI、arms、日志服务等进行了全方位的融合。 保留资源池 在原生的 KPA 能力之上，我们提供了保留资源池的能力。该功能可以应用在如下场景： ECS 与 ECI 混用。如果希望常态情况下使用 ECS 资源，突发流量使用 ECI， 那么我们可以通过保留资源池来实现。在常态下通过 ECS 资源承载流量，突发流量则新扩容出来的资源使用 ECI。 资源预热。对于完全使用 ECI 的场景，也可以通过保留资源池实现资源预热。当在业务波谷时使用低规格的保留实例替换默认的计算型实例，当第一个请求来临时使用保留实例提供服务，同时也会触发默认规格实例的扩容。当默认规格实例扩容完成以后所有新请求就会都转发到默认规格上，然后下线保留实例。通过这种无缝替换的方式实现了成本和效率的平衡，即降低了常驻实例的成本又不会有显著的冷启动时长。 精准弹性 单个 Pod 处理请求的吞吐率有限，如果多个请求转发到同一个 Pod，会导致服务端过载异常，因此需要精准的控制单个 Pod 请求并发处理数。尤其对一些 AIGC 场景下，单个请求会占用较多的 GPU 资源，需要严格的限制每个 Pod 并发处理的请求数。 Knative 与 MSE 云原生网关结合，提供基于并发数精准控制弹性的实现：mpa 弹性插件。 mpa 会从 MSE 网关获取并发数，并计算所需要的 Pod 数进行扩缩容，待 Pod ready 之后，MSE 网关将请求转发到相应的 Pod。 弹性预测 容器服务 AHPA（Advanced Horizontal Pod Autoscaler）可以根据业务历史指标，自动识别弹性周期并对容量进行预测，解决弹性滞后的问题。 当前 Knative 支持 AHPA（Advanced Horizontal Pod Autoscaler）的弹性能力，当请求具有周期性时，可通过弹性预测，实现预热资源。相比于调低阈值进行资源预热，通过 AHPA 可以最大程度的提升资源利用率。 通过 AHPA 可以做到： 资源提前准备：在请求到来之前，提前扩容 稳定可信：预测准备的 RPS 吞吐量足够覆盖实际需要的请求数 事件驱动 Knative 中通过 Eventing 提供事件驱动能力，在 Eventing 中通过 Broker/Trigger 进行事件流转和分发。 但直接使用原生的 Eventing 也面临一些问题： 如何覆盖足够多的事件源 如何保障事件流转过程中不丢 如何打造生产级别的事件驱动能力呢？我们与阿里云 EventBridge 进行结合。 EventBridge 是阿里云提供的一款无服务器事件总线服务， 阿里云 Knative Eventing 底层集成了 EventBridge， 提供了面向 Knative Eventing 使用的云产品级别事件驱动能力。 那么我们实际的业务场景中如何使用 Knative ？通过 Knative 又能我们带来哪些收益呢？接下来给大家介绍一下数禾科技使用 Knative 的最佳实践。 数禾基于 Knative 的最佳实践 数禾科技（全称“上海数禾信息科技有限公司”）成立于 2015 年 8 月，数禾科技以大数据和技术为驱动，为金融机构提供高效的智能零售金融解决方案，业务涵盖消费信贷、小微企业信贷、场景分期等多个领域，提供营销获客、风险防控、运营管理等服务。 数禾科技旗下还呗 APP 是一款基于消费多场景的分期服务平台，于 2016 年 2 月正式进入市场。通过与持牌金融机构合作，为大众提供个人消费信贷服务，并为小微企业主提供贷款资金支持。截至 2023 年 6 月，还呗累计激活用户 1.3 亿，为 1700 万用户提供合理信贷服务，助力用户“好借好还呗”。 模型发布痛点 模型上线阶段，资源浪费问题 为了保证我们的服务稳定，一般都会预留 buffer，通常都是按照超过我们实际使用规格储备资源。 创建的资源不是全时段用满资源，会看到线上的一些应用，尤其是一些离线 job 类型的应用，大部分时间整个 cpu 和内存的使用率都是很低的，只有某些时间段资源使用率才会上涨上去，有很明显的潮汐现象。 因为资源使用缺少足够的弹性，往往会造成资源大量的浪费。 模型下线阶段资源难回收的问题 线上的一个模型，可能会同时存在多个版本。 通过不同的版本来评估模型线上真实效果，如果某个版本评估效果不好，那么则会在决策流程中将这个版本拿掉。这时候这个模型实际就不再提供服务了，这时候如果资源不能及时下线，就会造成资源的浪费。 模型持续交付技术架构 模型平台部分 模型平台产出模型文件，然后将模型文件登记到 BetterCDS BetterCDS 会产生一个跟这个模型文件对应的制品 通过制品可以完成模型发布及模型版本的管理 Knative 管理模块 配置模型全局的 Knative 弹扩配置 每个模型都可以配置自己的 knative 的弹扩配置 CI 流水线 CI 流水线主要流程是拉取模型文件，通过 dockerfile，构建模型镜像 部署过程 流水线去更新 Knative Service，设置路由版本和镜像地址，更新 knative 的弹扩配置，knative 则会产生一个对应制品的版本的 revision Knative Service 更新过程 knative service 更新则会产生一个 revision 版本 revision 版本会产生一个 deployment 对象 流水线会观察 deployment 状态，如果所有 pod 都 ready 了，那么则认为这个版本就部署成功了 部署成功后为 revision 打一个 tag 来创建一个版本路由 模型多版本发布 通过 Knative 的 Configuration 实现了模型的多版本制品发布： 制品的多个版本跟 Configuration 的 Revision 版本一一对应。 制品包含模型版本镜像，通过更新 Knative Service 的镜像版本，产生于制品对应的 Revision。 模型多版本服务共存能力： 通过 Tag 的方式为 Revision 都创建了一个版本路由，根据不同的路由调用不同的版本服务。 因为有多版本同时存在，可以支持决策流程中调用不同的模型版本，以观察模型效果，同时由于多个路由版本的存在，可以支持多种流量策略。 还支持了支持一组 latest 路由，可以做到在不改变的决策流程的情况下，可以将 latest 路由切换到任意版本，就完成线上流量的切换。 基于请求的弹扩 为什么模型会采用基于请求数的弹扩策略： 模型大部分为计算密集型服务，模型 cpu 使用率跟请求数是正相关的，所以一旦请求激增，将导致 cpu 被打满，最终导致服务雪崩。 除了基于请求的弹扩，还有根据 cpu 和内存指标 HPA 弹扩，但是 HPA 弹扩也存在以下几点问题： a. 指标的弹扩链路较长：从服务暴露指标，Prometheus 采集到指标，指标上升，然后 hpa 根据指标计算出扩容的 pod 数，然后开始弹扩 pod，整体弹扩的链路比较长。 b. 指标不准确：例如 java 的 gc 会导致内存的周期性变化。 c. 指标不能反映真实的服务状态：从指标上升时，响应延迟就已经变很高了，也就是说通过指标发现超过阈值，就已经延后了，然后再开始弹扩 pod，到 podready 的时候也已经延后了。 因此我们需要将弹扩时间提前，使用请求数来触发模型弹扩，保证模型服务可以保持正常服务状态。 以下是一个 revision 版本请求从 100%-0% 的弹扩工作过程： Knative 弹扩链路如下： 流量从 service 请求到 pod。 PodAutoscaler 实时采集 Pod 中 queue-proxy 的流量请求指标，根据当前请求来计算出弹扩的 pod 数。 PodAutoscaler 控制 Deployment 进行 pod 弹扩，弹扩出来的 Pod 又会加入到这个 Service 下，就完成了 Pod 的扩容。 相较于指标弹扩，基于请求的弹扩策略，响应更快，灵敏度更高。能够保证服务的响应。针对过去资源下线的痛点，由于支持可以缩容到 0，那么我们可以将 revision 最小 pod 数调整为 0，在没有请求的情况下，就会自动缩容到 0。再结合弹性节点，缩容到 0 也就不会再占用资源，也实现了模型服务的 Serverless 能力。 BetterCDS 一站式模型发布 模型是通过流水线完成版本部署的，以下是 BetterCDS 发布流水线步骤过程。 部署版本步骤：触发 Knative 模型部署。 新增路由：新增 Knative 版本路由。 更新 latest 路由：更新 latest 路由作为流水线的参数，可以选择部署完成同时更新 latest 路由。 通过 Knative 弹扩配置管理模块可以配置每个模型可以配置全局的弹扩配置和版本的弹扩配置。 集群弹扩架构 容器应用运行在在我们的 ACK 和虚拟节点集群上，ecs 和弹性节点混合使用，平时业务由包年包月的 ecs 节点承载，弹性业务由按量付费的弹性节点承载，能够低成本实现高弹性。基于虚拟节点的弹性能力，即满足了弹性要求，又避免了资源浪费，降低使用成本。 ACK维护固定节点资源池根据常驻 Pod 和常规业务量储备 Node，包年包月成本更低 虚拟节点运行着弹性实例，提供弹性能力，因为无需关心节点，可以随用随弹扩弹性能力轻松应对突发流量和波峰波谷 对于 Job 和离线任务实时性要求不高的业务，因为有周期性，所以不会一直占用资源，成本优势高 免运维：弹性节点，Pod 用完即销毁 成果收益 通过 Knative 的弹性能力最大化提升了资源使用率，从资源和流量请求的曲线可以看出，我们的资源有波峰波谷，有明显的周期性，请求上升时 Pod 使用量上升，请求下降时 Pod 使用量下降。集群的峰值 Pod 个数接近 2000，成本较过去降低约 60%，资源节约十分可观。 得益于 Knative 的多版本发布能力，发布效率也得到了提升，从过去的小时级提升到了现在的分钟级。数禾的 Knative 模型实践也得到了权威的认证，被信通院云原生产业联盟评选为【云原生应用优秀案例】。 Knative 与 AIGC 作为 AIGC 领域的知名项目 Stable Diffusion，可以帮助用户快速、准确地生成想要的场景及图片。不过当前直接在 K8s 使用 Stable Diffusion 面临如下问题： 单个 Pod 处理请求的吞吐率有限，如果多个请求转发到同一个 Pod，会导致服务端过载异常，因此需要精准的控制单个 Pod 请求并发处理数。 GPU 资源很珍贵，期望做到按需使用资源，在业务低谷及时释放 GPU 资源。 基于上面两个问题，我们通过 Knative 可以做到基于并发精准弹性，资源不用时，缩容到 0。 此外 Knative 提供了开箱即用的可观测大盘，可以查看请求数、请求成功率、Pod 扩缩容趋势以及请求响应延迟等。
2023-12-21
优秀的个人博客,低调大师

混合云案例：利用 Databend Cloud 高效加速私有 Databend 的策略与实施

背景 Databend 是一款基于对象存储的存算分离湖仓产品，已成为云上大数据分析中高效且低成本的首选解决方案。目前，Databend 在多个用户场景中得到广泛应用，包括： 新媒体行业数据分析及大屏数据展示 云上 CDH 替代以减少本地磁盘和资源占用 性能明显提升的云上 Greenplum 替代方案 降低用户管理复杂度的云上 Clickhouse 替代方案 ... Databend 将数据持久化存储在对象存储中，计算层无状态且可随意扩展。同时，Databend 还充分利用云上对象存储的无需虚拟专用网络（VPC）的特性，实现了一个统一化的湖仓解决方案。 在云上构建大数据环境时，有两个昂贵的成本需要考虑： 本地磁盘成本，包括大量的闲置存储空间和冗余副本。 流量成本，跨 VPC 通信的带宽费用，通常 1G 带宽的成本都超过 0.5 元。 越来越多的云上用户选择利用 Databend 结合对象存储构建湖仓，以节省本地磁盘成本。由于对象存储无需 VPC，全球写入无需费用，内网请求无带宽费用，从而降低了云上大数据相关费用。 本文将介绍如何通过私有化部署 Databend 和结合公有云上的 Databend Cloud，将核心业务部署在私有环境中，然后借助 Databend Cloud 进行大规模计算和挖掘，用户可以减少 IT 建设成本，并实现强大的云端计算能力。 客户案例： 我们以一家位于阿里云杭州区的短视频内容产业客户为例。其核心业务涉及多平台内容投放，如抖音、快手、微信视频号等。客户在现有系统中部署了 Databend 服务，用于收集多个平台的数据投放情况和订单数据，并在数据平台上展示。这不仅让管理层直观地看到业务数据，也为营销策略提供了数据支持。 业务特征： 多个平台的数据投放：可能出现多个平台回来的订单数据，以及多个 API 的数据回传 数据全网打通：分析用户群体的活跃情况和投放效果 投放的留存分析及转化分析 挖倔分析及数据整理 挑战与解决方案： 该客户面临的主要挑战包括数据去重、多平台数据整合、投放留存分析和数据挖掘。 数据去重：由于多平台数据回传，可能存在重复数据。客户目前采用创建临时表的方式，接收传输的数据，并通过 SQL 与已入库数据进行比较，入库不重复数据，丢弃重复数据。 全网数据打通：需要对来自多个平台的用户进行匹配，计算用户活跃度和投放情况。由于业务只有 3 台 Databend 机器，有时会面临资源瓶颈。 投放留存和转化分析：可利用 Databend 的 bitmap 和漏斗函数进行方便的分析。 数据挖掘分析：利用 Databend 的索引特性，通过各种 SQL 查询实现高效的数据挖掘分析。 客户目前的挑战是处理大型 SQL 请求对现有资源造成较大压力，但又不希望扩大环境规模（受限于 IT 成本）。因此，结合 Databend Cloud 的使用，可以优化私有化 Databend 部署的成本。 接下来以 TPCH 中的表举例 基本架构如下 从阿里云市场关联 Databend Cloud 用户所在的区有对应的 Databend Cloud，计算和存储不要跨区 私有化环境表对应的 URI 在 Databend Cloud 中创建 attach 只读表 获取原表在存储上的位置 具体操作如下： 获取用户对应表的 URI 例如这里需要找到 tpch_100.lineitem 对应的 uri ，首先 SELECT regexp_substr(snapshot_location, '^\d+/\d+/') AS table_path FROM fuse_snapshot('tpch_100', 'lineitem') LIMIT 1; ┌──────────────────┐ │ table_path │ │ Nullable(String) │ ├──────────────────┤ │ 28/33/ │ └──────────────────┘ 1 row read in 0.013 sec. Processed 1 row, 227 B (79.57 row/s, 17.64 KiB/s) 其中 snapshot_location 是对应的 bucket 下的 root 下指定的位置，默认 root 为：空。 例如我的 oss 配为： SELECT * FROM system.configs WHERE name LIKE '%bucket' OR name LIKE '%root'; ┌───────────────────────────────────────────────────┐ │ group │ name │ value │ description │ │ String │ String │ String │ String │ ├─────────┼──────────────┼────────────┼─────────────┤ │ storage │ gcs.bucket │ │ │ │ storage │ gcs.root │ │ │ │ storage │ s3.bucket │ │ │ │ storage │ s3.root │ │ │ │ storage │ azblob.root │ │ │ │ storage │ hdfs.root │ │ │ │ storage │ obs.bucket │ │ │ │ storage │ obs.root │ │ │ │ storage │ oss.bucket │ wubx-bj01 │ │ │ storage │ oss.root │ wubx202310 │ │ │ storage │ webhdfs.root │ │ │ │ storage │ cos.bucket │ │ │ │ storage │ cos.root │ │ │ └───────────────────────────────────────────────────┘ 13 rows read in 0.009 sec. Processed 155 rows, 9.21 KiB (16.51 thousand rows/s, 981.20 KiB/s) 针对这个环境的 URI 为： 语法: [oss://bucket[/root]/table_path/] oss://wubx-bj01/wubx202310/28/33/ 创建只读表 登录 app.databend.cn 进入 worksheet 创建或是切换到指定库下创建表 attach table lineitem 'oss://wubx-bj01/wubx202310/28/33/' connection=( endpoint_url='https://oss-cn-beijing-internal.aliyuncs.com' access_key_id='x' access_key_secret='x' ) READ_ONLY; 通过 show tables; 确认表存在 show tables; select count(*) from lineietm; 测试 SQL 把 tpch100sf 中 lineitem 挂载到 Databend Cloud 中，测试 Q1 效果为： SELECT l_returnflag, l_linestatus, sum(l_quantity) AS sum_qty, sum(l_extendedprice) AS sum_base_price, sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge, avg(l_quantity) AS avg_qty, avg(l_extendedprice) AS avg_price, avg(l_discount) AS avg_disc, count(*) AS count_order FROM lineitem WHERE l_shipdate <= add_days(to_date('1998-12-01'), -90) GROUP BY l_returnflag, l_linestatus ORDER BY l_returnflag, l_linestatus; 成果展示 规格 TPCH-100 Q1 响应时间 阿里云 S6-8C32G 38.956s Databend Cloud(medium) 10.1s Databend Cloud(xlarge) 2.6s 总结 通过 Databend Cloud，用户可以实现私有化大数据处理与公有云平台的一致性，充分利用 Databend Cloud 的弹性计算能力，快速完成大规模的分析 SQL 计算，使用后即可以释放。这种方法不仅提高了效率，还在成本控制方面提供了显著优势，为用户在数据驱动决策方面提供了强有力的支持。 Connect With Us Databend 是一款开源、弹性、低成本，基于对象存储也可以做实时分析的新式数仓。期待您的关注，一起探索云原生数仓解决方案，打造新一代开源 Data Cloud。 👨‍💻‍Databend Cloud：databend.cn 📖Databend 文档：databend.rs/ 💻WeChat：Databend ✨GitHub：github.com/datafuselab…
2023-11-28

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册