基础概念
这些词天天出现在会议和文档里——先统一语言，再谈进阶。
🛒 跨境电商统一场景设定：一家跨境电商公司，在 Amazon / eBay / TikTok Shop 多平台开店，覆盖美 / 德 / 日站点，SKU 10 万+、日订单约 50 万、多币种结算——本页所有概念都放进这个场景讲。
- 一行一条记录、一列一个属性，结构由 schema 约束
- 物理真实存着数据——视图、快照都以它为底
🛒 跨境电商亚马逊平台每天的订单写进 dwd_orders 表：一行一笔订单，列有 sku_id、site、金额、币种、下单时间。
- 一段被命名的 SELECT，访问时实时计算，不占存储
- 用途：简化常用查询；给业务开放视图而不暴露底表
- 复杂视图每次现算，数据量大就改用物化视图
🛒 跨境电商给运营只开放 v_orders_us 视图（仅美国站、隐藏采购成本列）——日常查询不用写长 SQL，也看不到成本。
- 查询快（不用现算），代价是占存储 + 要刷新
- PostgreSQL 的 MATERIALIZED VIEW、SQL Server 的索引视图都是它
🛒 跨境电商GMV 大盘每 10 分钟被几百次刷新——把「站点×日汇总」做成物化视图，看板秒开、主库负载不抖。
- 预编译、可带参数 / 事务 / 流程控制，一次编写反复调用
- 适合批量多步作业；缺点是难版本管理与调试
- 现代数仓多用「调度工具 + 版本化 SQL」替代，但要看得懂
🛒 跨境电商财务每月算各站点佣金与仓储费的老脚本是个存储过程；数仓改造后换成 Airflow 调度 + Git 管理的 SQL，改口径不再靠口口相传。
- 给数据拍「照片」：对账、审计、误删恢复都靠它
- SQL Server 系统版本临时表、每日快照备份都能回到历史时点
🛒 跨境电商财务月中对账要「11 月 1 日零点的海外仓库存表」——查系统版本临时表 AS OF 那一刻，不用翻备份。
- 像书的目录：按高频查询列建，定位数据免全表扫
- 代价是占存储、拖慢写入——不是越多越好
- PostgreSQL 常用 B-tree；SQL Server 还有列存储索引应对分析查询
🛒 跨境电商运营天天按 ASIN 查单品——商品维表在 ASIN 列上建 B-tree 索引，查询秒回。
- 按列值（常为日期）切分区，查询只扫命中的分区
- 数仓大表标配，WHERE 带分区键是第一优化习惯
🛒 跨境电商dwd_orders 按 dt 分区：查黑五当天只扫 1 个分区，而不是全年 365 天 × 50 万单的全量。
- 热数据：近 90 天高频查询，放高性能存储
- 冷数据：历史低频，转低成本存储或归档层
- 分区 + 生命周期规则自动沉降，是成本优化主手段
🛒 跨境电商近 90 天订单明细留在 PostgreSQL 主库（SSD 表空间）；两年前的历史订单按年分表归档到廉价存储，主库瘦身一半。
- 表结构、字段口径、血缘、负责人、更新时间都是它
- 指标字典与血缘管理管理的正是元数据（见🛡️数据治理）
🛒 跨境电商新同事问「revenue_usd 含不含 VAT」——元数据里口径、负责人、最近变更一查便知，不用翻群聊考古。
数据库
六类数据库各有分工：先分清「事务型」与「分析型」，再看数据量级决定 BI 连接形态。
🛒 跨境电商公司的真实选型题：业务库 MySQL 扛不住 BI 大查询、ES 搜索要自建、订单明细 10 亿行没地方跑——六类数据库各解决一块。
- 代表：MySQL、PostgreSQL、Oracle、SQL Server
- 表格 + SQL + 事务（ACID），schema 严格、一致性强
- BI 视角：业务明细的源头；量小可直连，量大请连从库或数仓
🛒 跨境电商订单管理、库存系统的底层就是 MySQL / PostgreSQL——下单扣库存必须事务，超卖就是事故。
- 代表：MongoDB（文档）、Redis（KV）、Elasticsearch（搜索）、Cassandra（宽列）
- schema 灵活、水平扩展、高并发读写
- BI 视角：不擅长 join 聚合，先 ETL 进数仓再分析
🛒 跨境电商商品评论与客服聊天记录存 MongoDB；前台搜索「wireless earbuds」的联想补全由 Elasticsearch 扛。
- 代表：Hive、ClickHouse、Doris、StarRocks、Greenplum
- 分片存多机并行计算，列存 + 向量化，PB 级吞吐
- BI 视角：亿级明细秒级聚合，BI 直连 ADS 层的最佳拍档
🛒 跨境电商全平台 10 亿行订单明细做利润下钻——ClickHouse 秒级聚合，MySQL 早躺平了。
- 代表：阿里云 MaxCompute / Hologres、BigQuery、Azure Synapse
- 存算分离、弹性扩缩容、按量计费
- BI 视角：按量弹性扛查询潮汐——分析库规模再上一档时的演进方向
🛒 跨境电商公司当前用 SQL Server / PostgreSQL 集群扛分析；等订单明细再涨一个量级，按量付费的云数仓就是下一步演进选项。
- 代表：InfluxDB、TimescaleDB、Prometheus
- 按时间分区、高写入吞吐、数据自动过期（TTL）
- BI 视角：监控大盘与 IoT 曲线的源头，通常聚合后进数仓
🛒 跨境电商海外仓的温湿度传感器、广告展示的分钟级数据进 InfluxDB——按小时聚合后再进数仓做趋势分析。
- 代表：Neo4j、NebulaGraph、JanusGraph
- 节点 + 边建模，关系遍历远快于多表 join
- BI 视角：风控关系网络等专项分析，结论再回 BI 呈现
🛒 跨境电商风控团队用 Neo4j 画「买家—收货地址—支付卡」关系图，揪出同一张卡关联 47 个账号的刷单团伙。
🧭 场景选型速记
- 在线事务（下单、支付、改库存）→ 关系型数据库，要的是一致性与事务。
- 高并发读写（缓存、日志、搜索）→ NoSQL，要的是吞吐与灵活。
- 海量数据分析（离线数仓、实时大屏）→ 分布式 MPP，要的是并行算力。
- 弹性波动的分析负载（BI 查询潮汐）→ 云数仓，要的是按量付费与免运维。
🛒 跨境电商这家公司最终形态：业务库 SQL Server / PostgreSQL + 缓存 Redis + 搜索 ES + 分析库 PostgreSQL 集群——各司其职，谁也不挤谁的活。
📏 数据量级 × BI 连接选型
同一个 BI 工具，连什么库、怎么连，主要由数据量级决定——量级一变，连接形态就该跟着变。
🌱 百万行以内（< 1GB）
推荐：MySQL / PostgreSQL 直连 BI，起步用 Excel/CSV 也不丢人。
🛒 跨境电商单站点新店起步：一个 Amazon US 店铺一年订单约 30 万行，MySQL 直连 Tableau 完全够用。
🌿 百万 ~ 千万行（1 - 100GB）
推荐：主库读写分离，BI 连从库；或开始上云数仓。
🛒 跨境电商三站点放量：日订单 2 万、年订单 700 万行——BI 连只读从库，ETL 每晚同步一次，主库零压力。
🌳 千万 ~ 亿级（100GB - 1TB）
推荐：MPP（Doris / StarRocks / ClickHouse）或云数仓（阿里云 Hologres / MaxCompute）。
🛒 跨境电商全平台扩张：10 个站点日订单 30 万——订单明细进 Doris / StarRocks 集群，Power BI 直连 ADS 汇总层。
🏔️ 亿级以上 / TB - PB（平台级）
推荐：ClickHouse / Doris / StarRocks 集群，MPP 架构打底。
🛒 跨境电商平台型大卖：年订单 10 亿行 + 广告点击流——ETL 与 BI 查询队列隔离、冷热分层存储，实时大屏独立服务。
🔌 BI 连接四原则
- 永不直连生产业务库 —— BI 的大范围聚合会拖垮订单支付，连从库或数仓。
- 连查询层，不连加工层 —— BI 指向 ADS / DWS 汇总结果，明细留给下钻。
- Live 还是 Extract 看场景 —— 实时性优先选直连，性能成本敏感选 T+1 抽取，两者可混用。
- 量级跨档主动迁移 —— 跨过千万 / 亿级就换架构，别等 BI 卡死再救火。
🛒 跨境电商真实教训：同事曾把 BI 直连生产订单库，一个全年聚合查询把店铺后台拖到接口超时——此后 BI 一律连数仓，写进规范。
数据库管理
数据开发不等于 DBA，但这六件事必须心里有数——出问题时你知道找谁、查什么。
🛒 跨境电商运营早上反映「大盘很卡、导出失败」——从下面六个方向逐一排查，十有八九能定位。
- JDBC / ODBC 驱动与连接池配置
- DBeaver、SSMS 等客户端日常管理与排查
🛒 跨境电商用 DBeaver 同时管着订单库（SQL Server）与分析库（PostgreSQL）十几套实例；BI 服务器的连接池上限调到 50，扛住早高峰。
- 账号分级与最小权限原则
- 库 / 表 / 列级授权，敏感列单独管控
🛒 跨境电商BI 服务账号只给 ADS 层只读权限；采购成本列按部门列级授权，运营看得到售价看不到底价。
- 全量 + 增量定期备份策略
- SQL Server 完整恢复模式 + 日志备份，可恢复到任意时点（PITR）
🛒 跨境电商同事误删了 dim_product 的半个分区——DBA 用日志备份把数据恢复到 10 分钟前，虚惊一场，从此删表必双人复核。
- 慢查询日志定位问题 SQL
- EXPLAIN / 执行计划分析，索引 / 分区裁剪优化
🛒 跨境电商大盘变慢，用 PostgreSQL 的 EXPLAIN ANALYZE 定位：某个看板每次全表扫——补上分区裁剪后，查询从 40 秒降到 4 秒。
- 表分区与冷热分层存储
- 过期数据按分区归档清理
🛒 跨境电商三年前的平台日志表按年分区归档、迁移到廉价存储——主库瘦身 40%，备份时间也短了一半。
- 主从复制 / 集群部署，故障自动切换
- 跨区域容灾与恢复演练
🛒 跨境电商黑五凌晨主库所在可用区故障——PostgreSQL 流复制从库 30 秒内自动提升，实时大屏没断，值班同学睡了个好觉。
常用 SQL
分析师与数据开发的日常 80% 都在这些语句里——按场景记住骨架，细节用时再查。
🛒 跨境电商分析师小王每天要给运营出「各站点 Best Seller」和复购分析——下面 6 段 SQL 就是他的一周。
🔍 基础查询
SELECT + WHERE + ORDER BY，加分区条件是数仓查询的第一习惯
-- 按条件筛选 + 排序 + 限量 SELECT order_id, user_id, amount, created_at FROM dwd_orders WHERE dt = '2026-11-01' -- 分区裁剪，避免全表扫 AND amount > 0 ORDER BY amount DESC LIMIT 100;
🛒 跨境电商查美国站黑五当天金额大于 $100 的订单明细，给运营复盘爆款。
📊 聚合统计
GROUP BY 分组 + HAVING 过滤聚合结果，UV / GMV 一把出
SELECT province,
COUNT(DISTINCT user_id) AS uv,
SUM(amount) AS gmv
FROM dwd_orders
WHERE dt >= '2026-11-01'
GROUP BY province
HAVING SUM(amount) > 100000
ORDER BY gmv DESC;
🛒 跨境电商统计美 / 德 / 日三个站点近 30 天的 UV 与 GMV，周会看板数据源。
🔗 多表连接
LEFT JOIN 最常用；维表过滤条件放 ON 里，防止左表被意外截断
SELECT o.order_id, o.amount,
u.user_level
FROM dwd_orders o
LEFT JOIN dim_user u
ON o.user_id = u.user_id
AND u.status = 1; -- 维表条件放 ON，不放 WHERE
🛒 跨境电商订单明细 left join 用户维表，把会员等级挂到每笔订单上做分层分析。
🪟 窗口函数
分组排名 / 累计计算，分析师进阶必备（ROW_NUMBER / RANK / SUM OVER）
-- 每个站点 GMV Top3 类目
SELECT *
FROM (
SELECT site, category, gmv,
ROW_NUMBER() OVER (
PARTITION BY site
ORDER BY gmv DESC) AS rk
FROM ads_site_category
) t
WHERE rk <= 3;
🛒 跨境电商每个站点 GMV Top3 的类目——周会固定看板，一行窗口函数搞定。
♻️ CTE + MERGE
WITH 让逻辑分层可读；MERGE 一条语句完成增量更新，数仓日常
WITH inc AS ( SELECT user_id, MAX(pay_time) AS last_pay FROM ods_pays WHERE dt = '2026-11-01' GROUP BY user_id ) MERGE INTO dim_user t USING inc s ON t.user_id = s.user_id WHEN MATCHED THEN UPDATE SET t.last_pay = s.last_pay WHEN NOT MATCHED THEN INSERT (user_id, last_pay) VALUES (s.user_id, s.last_pay);
🛒 跨境电商每晚把当天支付增量 MERGE 进用户维表的「最近支付时间」，为复购分析打底。
🏗️ 建表规范 DDL
「层级_主题_粒度」命名，声明分区，把优化写进表结构（PostgreSQL 语法）
CREATE TABLE IF NOT EXISTS dwd_orders ( order_id VARCHAR(64), user_id VARCHAR(64), amount NUMERIC(18,2), created_at TIMESTAMPTZ ) PARTITION BY RANGE (created_at); COMMENT ON TABLE dwd_orders IS '订单明细表：一个支付事件一行，金额统一 USD'; CREATE INDEX idx_orders_user ON dwd_orders (user_id);
🛒 跨境电商新建 dwd_orders 时写好 COMMENT——半年后没人记得这表是干嘛的，注释就是文档。
ETL
数据的「中央厨房」：抽取（Extract）→ 加工（Transform）→ 装盘（Load）——数仓的粮是从这里来的。
🛒 跨境电商每天凌晨，三个平台的订单、库存、物流数据要汇到一个地方统一加工——这个「搬运 + 加工」的活就是 ETL，数仓分层只是它的加工车间。
- 数据孤岛：订单在平台 API、库存在 ERP、物流在服务商系统——格式各异、口径不一
- 人肉搬运不可持续：手工拼 Excel 又慢又错，口径漂移没人发现
- 工具化之后：流程可视化、可调度、可监控、可复用，团队可协作
- 额外收益：统一口径的必经关口 + 天然的操作留痕（可审计）
🛒 跨境电商三平台订单格式三种、币种三种、时区三个——没有 ETL，运营的日报就得靠人肉拼 Excel，天天拼还天天错；上了 ETL，日报自动出、口径有人管。
- 数据获取（API 对接、自动下载、爬虫、数据源管理）就是 ETL 里的 Extract
- 也是数仓 ODS 层的入口——「进得来」才谈得上后面的加工
- 岗位细分：有的公司单设「数据采集 / ETL 工程师」，但大类都归数据开发
- 具体技能见 🔗 个人技能页 · 数据获取
🛒 跨境电商Amazon / eBay / TikTok Shop 三平台的订单与库存拉取，就是这家公司数据开发的起点——获取不稳定，后面的分层建模全是空中楼阁。
- 抽取：从源库 / API / 文件全量或增量拉数据
- 转换：清洗、去重、格式标准化、口径映射、关联补全
- 加载：写入目标表，全量覆盖或增量 MERGE
- 配套：依赖编排、失败重试、告警、质量校验
🛒 跨境电商每晚把 Amazon 订单 API 增量拉下来 → 币种统一 USD、订单状态映射 → MERGE 进 dwd_orders——一步都不能少。
- 图形化设计 Transformation（转换）与 Job（作业），拖步骤连线
- 连数据库、文件、API 都行，复杂逻辑可嵌 Java 脚本
- 免费开源、社区大——中小团队快速上手的首选
- 后继者 Apache Hop 延续可视化管线路线
🛒 跨境电商用 Kettle 拖了个作业：每天 1 点从平台 MySQL 抽订单 → 过滤测试单 → 写入数仓 staging。图形化流程，业务同事一看就懂。
- 数据集成（同步）+ DataStudio 开发 + 调度运维 + 数据质量 + 数据地图
- 与 MaxCompute / Hologres 深度集成，适合上云团队规模化开发
🛒 跨境电商公司上阿里云后用 DataWorks：三平台同步任务在数据集成里配好，调度依赖拖 DAG，质量规则内嵌——运维省了一个专人。
- requests 拉平台 API + pandas 清洗 + SQLAlchemy 入库，多来源入库几百行搞定
- 优点：灵活度最高、零额外学习成本、源少源杂时落地最快
- 缺点：可视化 / 调度 / 监控要自己搭（配 Airflow 或 cron），逻辑散在脚本里难交接
🛒 跨境电商起步期用 Python 脚本每晚拉 3 个平台 API 入 PostgreSQL，50 行代码稳定跑了一年；数据源涨到 7 个后迁 DataWorks，脚本继续处理长尾接口。
- Airbyte：300+ 连接器 + Web UI + CDC，开源 EL 平台人气王
- Apache Hop：Kettle 官方后继者，可视化管线；NiFi：流式数据流可视化编排
- dbt：用 SQL 写转换（T），ELT 事实标准；Meltano / Singer：CLI 驱动的 ELT
- DataX / SeaTunnel：国产高性能同步引擎，离线实时都能跑
🛒 跨境电商同步类任务选 DataX / SeaTunnel，连接器多了换 Airbyte，转换层统一交给 dbt——开源组合拳完全不输商业产品。
- 传统 ETL：先加工再入库（Kettle / Informatica）
- 现代 ELT：先入库后用 SQL 加工，算力交给数据库 / 分析引擎
- 趋势：ELT + dbt，SQL 版本化管理转换逻辑
🛒 跨境电商老的 Kettle 流程先把三平台数据加工好再写库；现在原样入 staging 层、SQL 在库内加工——改口径不用重跑抽取。
- Airflow 是调度编排的事实标准（开源界使用最广），Python 是数据生态第一语言——组合本身就在主航道上
- 这套组合 = code-first ETL：逻辑即代码，可 Git 版本化、可测试、可评审、可复用
- 真正的取舍是「灵活性 ↔ 可视化」：代码路线灵活上限高，新人上手与交接成本也高
- 落伍的不是 Python + Airflow，是人肉 Excel 和无版本化的散装脚本
🛒 跨境电商这套组合在跨境团队撑起日均 50 万单的加工链路：先 Python 脚本验证可行性、再 Airflow 编排固化——小步演进而非一步上平台，完全不落伍。
- Python + Airflow：灵活度最高、可版本化可测试；门槛高、可视化弱——适合工程能力强、逻辑复杂多变的团队
- Kettle：可视化拖拽上手最快、免费；调度与监控弱——适合中小团队快速集成
- DataWorks：调度、质量、告警、数据地图开箱即用；绑定阿里云生态——适合上云规模化团队
🛒 跨境电商同一个「三平台订单入仓」：工程团队用 Python+Airflow 三天搞定且好演进；业务自服务选 Kettle 拖拖拽拽；上了阿里云就直接 DataWorks。
✅ 你在 Airflow 手搓的能力，工具里都有对应
- DAG 依赖与先后顺序 —— Airflow dependencies ↔ DataWorks 调度依赖图 ↔ Kettle Job 流程编排。
- 任务优先级 —— Airflow priority_weight + pools ↔ DataWorks 任务优先级 + 资源组 ↔ Kettle 较弱（靠脚本排序）。
- 数据质量检查与门禁 —— 你自建校验任务 + 阻断 ↔ DataWorks 内置质量规则 + 强规则阻断 ↔ Kettle 校验步骤 + 条件分支。
- 邮件报警 —— Airflow SMTP / on_failure_callback ↔ DataWorks 邮件 / 钉钉 / 短信告警 ↔ Kettle 邮件作业条目。
🛒 跨境电商结论：你在 Airflow 里实现的正是 ETL 平台的四大核心能力（编排、优先级、质量门禁、告警）——换工具不是能力升级，而是「自建灵活」与「开箱省心」之间的取舍；先想清楚要哪一头。
🛡️ ETL 实战守则
- 增量要有水位 —— 用时间戳 / 自增 ID 记录同步进度，重跑不重复、不漏单。
- 失败必须告警 —— 自动重试 + 通知到人，别等业务发现报表空了才知道。
- 回补要有限流 —— 回补历史（backfill）限速执行，别把源库和目标库同时打挂。
- 能幂等就幂等 —— 任何任务重跑结果一致，这是深夜敢按重试按钮的底气。
🛒 跨境电商平台 API 限流导致漏了 2 小时订单——把同步水位回拨重跑，幂等设计保证数据不多不少，第二天报表照常 6 点出。
数仓分层
自下而上四层职责清晰：下层管可信，上层管好用——改一层不塌一片。
🛒 跨境电商一笔德国站订单的旅程：平台 API 拉来原始 JSON → ODS 原样落地 → DWD 清洗成一行一笔（币种统一 USD）→ DWS 汇到站点日表 → ADS 供利润看板。
🛒 四层在这家公司长什么样
- ODS：Amazon / eBay / TikTok Shop 的原始订单 JSON 原样落地，只补 dt 与 platform 字段。
- DWD：清洗成一行一笔支付：币种统一 USD、时区统一站点本地、退款单独一行。
- DWS：站点 × 类目 × 日 的 GMV / 订单量汇总表，广告与利润看板共用。
- ADS：「站点日利润表」直接对接看板——收入、成本、头程、佣金一屏看清。
建模方法论
分层解决「数据放哪」，建模解决「数据长什么样」——数仓的灵魂是维度建模（Kimball《数据仓库工具箱》）。
🛒 跨境电商拿「订单支付」这一个业务过程，完整走一遍四步法——学完就能套到自己公司的任一业务上。
- 围绕业务过程建模，不围绕报表建模
- 粒度声明必须先于一切——粒度一错，全盘返工
🛒 跨境电商业务过程=订单支付；粒度=一笔支付一行（退款另起一行）；维度=用户/商品/站点/时间；事实=金额、数量、运费。
- 事实表：业务过程的可加度量（订单金额、点击次数）
- 维度表：分析视角（谁、何时、何地、什么商品）
🛒 跨境电商fct_orders 存金额与数量这些「数字」；dim_user / dim_product / dim_site 提供「按谁看、按什么看」的视角。
- 星型：维度保持扁平，冗余换简单，BI 友好（首选）
- 雪花：维度再规范化，省空间但 join 变多
🛒 跨境电商dim_product 里不把「类目→子类目→类目树」拆成三张表——扁平星型让 BI 拖表就能分析。
- Type 1 直接覆盖，不留历史
- Type 2 加生效时间 + 当前标记，留全历史（最常用）
🛒 跨境电商用户从「普通会员」升到「VIP」——Type2 保留旧记录，历史订单仍按下单当时的会员等级归因，复购分析才不失真。
- start_date / end_date 记录每条状态的生命周期
- 查当日取 end_date='9999-12-31'；全量快照存不起时的历史方案
🛒 跨境电商dim_product 拉链存储：查黑五当天的售价与标题，取当天生效的那条——价格变动全程可回放。
- 日期 / 用户 / 商品维度全仓唯一，口径不打架
- 总线矩阵规划「业务过程 × 维度」，就是数仓的迭代路线图
🛒 跨境电商同一个 dim_site 被订单、广告、物流三个主题复用——总线矩阵上「哪些过程×哪些维度」一查，下季度开发计划就出来了。
调度与实时
批处理跑得稳，实时跑得快——先批后流，按业务对时效的真实需求选型。
🛒 跨境电商黑五大促：T+1 报表照常出、实时大屏不能停、库存超卖要秒级告警——这一页就是当天背后的机制。
- Airflow / DolphinScheduler：DAG 依赖编排、失败重试与告警
- DAG 里埋质量门禁——坏数据不流向下游
🛒 跨境电商Airflow 每日 1 点：拉平台 API → 清洗 → 汇总 → 质量校验 → 钉钉通知。黑五全程零人工值守。
- Flink CDC / Debezium / Canal 直接读 binlog
- 取代全量扫表抽取，对业务库压力最小
🛒 跨境电商独立站 Shopify 的库存变动通过 Flink CDC 秒级进数仓——超卖风险告警从「第二天」提前到「几秒内」。
- Kafka 削峰解耦 + Flink 窗口计算
- exactly-once 语义：不重不丢
🛒 跨境电商黑五实时 GMV 大屏：Kafka 收三平台订单流，Flink 按站点做 5 秒滚动窗口聚合——CEO 盯着的那个屏。
- Lambda：批流各自加工，稳但维护两套逻辑
- Kappa：一切皆流，回溯靠重放；趋势是流批一体（Flink 一套代码）
🛒 跨境电商实时大屏和 T+1 报表曾用两套逻辑，GMV 总差一点；流批一体后一套 Flink SQL，口径天然一致。
- ODS（Kafka 原始流）→ DWD（清洗明细）→ DWS（实时聚合）→ ADS
- 实时粒度要克制：只做真正需要秒级的场景
🛒 跨境电商实时链路也分层：Kafka 原始流 → 清洗明细流 → 站点分钟级聚合 → 大屏与库存告警——离线的纪律照搬。
数据湖与湖仓
湖存原始、仓管结构——湖仓一体让「存得起」和「用得好」不再二选一。
🛒 跨境电商三年订单明细 + 广告点击 + 客服聊天记录越堆越多，分析库的存储与备份成本一路涨——湖仓一体是省钱与灵活的答案。
- 对象存储（S3 / OSS）+ 开放格式，schema 用时再定义
- 便宜、灵活；没有治理就容易变「数据沼泽」
🛒 跨境电商三年全量订单、广告点击、客服聊天记录先扔进 S3 的 Iceberg 表——先存下来，分析需求来了再定义结构。
- Iceberg（中立开放、生态最广）/ Hudi（upsert 与 CDC 友好）/ Delta Lake（Databricks 原生）
- 共同能力：ACID 事务、时间旅行、schema 演进
🛒 跨境电商订单明细选 Iceberg：Spark 和 Trino 共用同一张表，平台改字段也不怕，时间旅行回溯历史状态。
- 数仓贵而严 → 数据湖便宜而乱 → 湖仓一体：湖上长出仓的能力
- 一套存储同时服务 BI 与 AI
🛒 跨境电商明细放湖（Iceberg），聚合在仓——Trino / Doris 直读湖上明细，存储费降了、看板速度没降。
- BigQuery、Trino 等主流引擎均已支持外部 Iceberg 表
- 存算分离之后，进一步「存管分离」
🛒 跨境电商用 Iceberg 开放格式存核心明细：未来想换引擎（迁 Doris / StarRocks）数据不用搬家，谈判也有底气。
- 训练数据、非结构化数据与结构化数据同仓管理
- 湖仓正在成为 AI 的数据底座——也是 BI + AI 的交汇点
🛒 跨境电商「爆款预测」模型直接读湖上的特征表（历史销量 + 广告 + 评论情感），BI 看板与 AI 模型同源不打架。
性能优化
数据开发的加班大半来自慢任务——按这五个方向顺序排查，别上来就加资源。
🛒 跨境电商黑五当天上午，利润看板突然卡死——下面五个方向按顺序排查，第 1 步就找到了答案。
- WHERE 必带分区键（dt / 日期），命中分区裁剪
- 跑之前先 EXPLAIN，看扫描量对不对得起结果
🛒 跨境电商查德国站某一周数据：WHERE dt BETWEEN 命中 7 个分区，扫描量降 99%——忘记带 dt 的同事已被请喝奶茶。
- 先隔离：热点 key 单独处理，再并回结果
- 再打散：加盐聚合；或两阶段聚合（先局部后全局）
🛒 跨境电商美国站某热门手机壳 SKU 占了三成订单——聚合严重倾斜。隔离热点 SKU 单独算，再加盐打散其余，任务 40 分钟变 6 分钟。
- 写入侧按分区合并（coalesce / Iceberg rewrite）
- 定时 compaction 任务兜底
🛒 跨境电商大促期间 5 分钟级微批写 Iceberg，一天产生上万小文件——每晚定时 compaction 合并，第二天元数据操作恢复丝滑。
- 小表广播（broadcast join）免 shuffle
- 大表 join 大表：先过滤再关联，空 key 提前剔除
🛒 跨境电商10 万行的站点维表广播 join 10 亿行订单——免 shuffle，任务从 8 分钟缩到 1 分钟。
- 队列优先级分离：ETL 高、即席查询低
- SQL Server Resource Governor / PostgreSQL 队列隔离负载，慢查询日志找大头
🛒 跨境电商ETL 跑在独立从库、分析师即席查询限流排队——互不拖累，月底成本和性能汇报一目了然。
- 慢任务上血缘看下游影响
- 没人消费的表及时下线（呼应🛡️数据治理）
🛒 跨境电商广告点击中间表半年没人查——血缘确认无下游后果断下线，一批算力和一份维护负担同时省掉。
核心工作
把「进得来」的原始数据，加工成「用得上」的分析底表。
🛒 跨境电商这四件事就是数据开发在跨境电商团队里的每一天——上面所有知识最终都落在这四件事上。
📥 数据获取
对接各平台开放 API、脚本化自动下载、必要时爬虫——把数据「进得来」，是数据开发的第一个动作（也是 ETL 的 E，详见上方 ETL 页签）。
🛒 跨境电商每晚 1 点自动拉取三平台订单与库存——「进得来」才轮得到后面的分层与加工。
🧱 数仓分层设计
按 ODS → DWD → DWS → ADS 分层建模，职责清晰、复用性强；同一口径只加工一次，下游全部引用。
🛒 跨境电商三平台 × 三站点订单统一进 dwd_orders 一张明细表——广告组、财务、运营的看板全部引用它，口径再也不打架。
☁️ 分析型数据库（SQL Server / PostgreSQL）
基于 SQL Server / PostgreSQL 建模开发：索引、分区、读写分离与参数调优并用，支撑 BI 高并发查询负载。
🛒 跨境电商黑五看板查询高峰——报表全部走只读从库，主库专心写订单，高峰扛得住、主库零压力。
🧹 数据清洗（SQL / Python）
去重、补缺、异常值处理与格式标准化，把脏数据挡在明细层之前，输出分析级可信数据。
🛒 跨境电商三个平台的订单状态叫法不一（Cancelled / Void / Refund）——清洗层统一映射成枚举，退款分析不再各说各话。
📥 数据入库
加工后的数据规范化入库，支持全量与增量两种写入方式，任务幂等、失败可重跑。
🛒 跨境电商每晚增量写 dwd_orders，任务幂等——黑五凌晨失败重跑三次也不会多算一笔订单。
开发原则
🛒 跨境电商每条原则背后都是一次真实的返工教训——比如「增量优先」，来自一次全量重跑把月度任务拖到中午、全公司看板延迟的下午。
- 增量优先 —— 能增量不全量：任务时长、存储与计算成本一起省。
- 幂等可重跑 —— 任何任务重跑结果一致，失败补数不心虚。
- 命名即文档 —— 表名按「层级_主题_粒度」命名，看名字就知道数据能用在哪。
- 底表复用 —— 同一口径只建一张表，下游引用不重复加工，杜绝「同义不同源」。
🛒 跨境电商命名即文档：新同事看到 ads_site_daily_profit 这个名字，不用问人就写对了取数 SQL——省下的都是沟通成本。
相关：🛡️ 数据治理（口径与血缘） · 📊 BI 与数据体系（建模与看板） · 🔗 个人技能（全链路总览）