跳过导航,前往主要内容
联系我们

形与势

可以持续扩展的数据平台,而不是反复重建的数据平台

一手好棋,价值不只在落子处,还为后续着法造出势。形不好的棋,越到后面越弱。

数据架构同理。临时拼凑的系统马上就能跑起来,却会限制之后的每一个选择,而且每一轮投入都比上一轮更贵。我们采用 lakehouse 架构:存储与计算分离,表保留历史版本,数据管道以源代码方式管理。后续每一步都是在平台上叠加,而不是推倒重来。

问题所在

数据已到极限的四个信号

如果其中两条以上成立,问题就不在于缺一个报表工具,而在于数据没有统一的归属地,背后也没有处理管道。

管理层数据依赖某一个人

汇总报表由人工从多个来源拼出来。别人无法核对,这个人休假时报表周期就会延后。

同一个指标,出现多个数字

各部门从不同系统取数,算法也各不相同。会议时间花在争论哪个数字对,而不是讨论下一步做什么。

数据送到管理层时已经过时

本期的决策依据的是上期的情况。这段时间差是机会成本,尽管它不会出现在任何财务报表上。

历史数据无法还原

业务系统会覆盖此前的状态。当需要解释某一期的数字,或审计有此要求时,数据无法重建。

分层

Bronze、Silver、Gold

数据依次经过三层,每层有各自的可靠性等级。这种分层让您可以定位错误数字的来源,而不必把整条管道重查一遍。

  1. Bronze

    原始层

    数据按从源端到达的原样载入,不做任何改动。错误记录和重复记录原样保留。

    为何需要这一层 当转换逻辑事后发现有误时,可以从头重新计算,无需再次向源系统索取数据。

  2. Silver

    清洗层

    统一数据类型,去除重复,跨来源对齐主键,并按同一套规则处理缺失值。

    为何需要这一层 数据工程师和分析人员从这一层取数。一行一条记录,一个主键一个含义。

  3. Gold

    服务层

    按业务主题汇总的表、预先计算好的指标,以及面向报表构建的维度模型。

    为何需要这一层 报表直接从这里读取,因此打开很快。每个指标只有一个定义,且已书面确定。

数据只按一个方向流动,自下而上。每一层都保留下层的版本,因此错误的数字可以回溯到源头。
技术栈

八个组件,全部开源

这份清单上没有授权费。成本在运维,而运维正是由我们承担的部分。

数据源

业务系统 Oracle、PostgreSQL、MySQL
非结构化数据 文件、日志、文档

数据接入

Airflow 按计划调度
Rust、Python 流式处理

存储

S3 上的 Iceberg Bronze、Silver、Gold
PostgreSQL 元数据

数据消费

Trino 分布式查询
Superset 报表、看板
数据单向流动,从业务系统流向分析层。没有回流箭头——分析层只读取,绝不写回源系统。
层 技术 作用
表格式 Apache Iceberg 带版本的表,可回读任意时间点的状态,变更表结构时无需重写全部数据。
存储 在越南境内运行的 S3 对象存储,与计算层分离,可独立扩容且成本低。
查询 Trino 对对象存储中的数据执行分布式查询,并可在同一条语句中与业务数据库关联。
编排 Apache Airflow 调度并监控数据管道,管理各步骤之间的依赖,失败的步骤可单独重跑而无需全部重来。
转换 dbt 转换逻辑用 SQL 编写,在 git 中管理,配有数据测试和自动生成的文档。
元数据 PostgreSQL 存放表目录、运行历史、数据质量日志和管道配置。
处理 Rust 与 Python 大部分管道和集成工作用 Python。对性能要求高或常驻运行的步骤用 Rust。
可视化 Apache Superset 报表与看板,按角色和组织单位控制访问权限。
处理语言

Python 覆盖广度,Rust 用于热点路径

按每个处理步骤的特点选择语言,而不是所有环节都用同一种语言。

大部分工作量用 Python

Python 拥有最广的数据类库生态,贵公司的技术团队通常已经熟悉它。数据接入管道、集成工作和大多数转换步骤都用 Python 编写。

对性能有要求的步骤用 Rust

常驻运行或处理大数据量的步骤——日志文件解析、事件流规范化、长期运行的服务——用 Rust 编写,可减少服务器资源占用,并消除一类内存错误。

运行良好的部分不做替换

我们不会建议把运行良好的 Python 组件迁到 Rust。只在收益可衡量的地方使用它,并且说明其代价:会写 Rust 的工程师更难找。

需要权衡的地方

开始之前要问的四个问题

数据项目失败的原因通常与技术无关:要么启动得太早,要么建得比实际需要大得多。

哪些单位不需要 lakehouse?
大多数都不需要。如果数据放得进一个关系型数据库,报表几秒钟就能跑完,那么加上 Iceberg、Trino 和 Airflow 只会抬高运维成本,并不解决任何问题。我们建议先用一个独立的 PostgreSQL 分析库,等到确实触及其上限时再扩展。
这套架构的真实成本是多少?
不是授权费——整套技术栈都是开源的。成本在运维:需要有人懂 Trino,能在非工作时间管道出故障时响应,并随着业务变化维护 dbt 逻辑。这部分由我们承担。
是否意味着要替换我们现在运行的系统?
不需要。分析层只读出数据,不会写回业务系统。即使整个数据平台停止运行,日常业务照常进行。这是架构上的硬性约束。
从哪里开始?
从一个确实有人在等数据的业务主题开始。我们把从数据源到报表的完整管道建起来,让贵公司先看到结果,再谈扩展。先把整个平台建好、再去找活给它干,是数据项目最常见的失败方式。

从一个业务主题开始

我们为一个确实有人在等数据的主题,建起从数据源到报表的完整管道。贵公司先看到结果,再决定是否扩展。