别再堆工具了！从 0 到 1 搭建小型生产级数据平台，只需要这份落地清单
作者：Echo_Wish
方向：大数据工程 / 数据平台架构 / 企业数字化实践
很多公司聊“大数据平台”，第一反应就是：
Kafka、Flink、Spark、Hive、ClickHouse、Airflow、DataLake……
一张架构图画出来，看起来非常高级。
但是到了真正落地的时候，问题来了：
数据从哪里来？怎么存？谁负责清洗？任务失败怎么办？数据错了怎么排查？
很多所谓“大数据平台”，最后变成了一堆组件的集合。
工具买了一堆，服务器部署了一堆，但是业务人员还是每天 Excel 导数据，开发人员还是手工跑 SQL。
其实，对于绝大多数中小企业来说，第一阶段根本不需要打造一个“互联网巨头级数据中台”。
真正有价值的是：
先搭建一个能稳定运行、可监控、可扩展的小型生产级数据平台。
今天我结合实际项目经验，整理一份：
从 0 到 1 搭建小型生产级数据平台落地清单。
包含：
- 技术选型
- 数据流程设计
- 核心脚本
- 上线检查点
- 常见踩坑
希望给正在做数据平台建设的朋友一点参考。
一、先明确目标：数据平台不是数据仓库
很多团队一开始就犯一个错误：
“我要建设数据平台。”
但是没有回答：
数据平台解决什么问题？
一个小型生产级数据平台，至少应该解决下面几个问题：
1. 数据自动采集
例如：
- MES生产数据
- ERP订单数据
- IoT设备数据
- 用户行为数据
不能每天人工导出。
2. 数据统一存储
不同系统的数据，需要进入统一的数据层。
例如：
ERP
|
MES
|
设备
|
日志
|
↓
数据平台
↓
报表
分析
算法
3. 数据加工治理
原始数据不能直接给业务使用。
例如：
生产系统：
order_id
create_time
qty
分析需要：
日期
产品
产量
良率
设备稼动率
中间需要加工。
4. 数据服务
最终目的不是存数据。
而是：
让业务快速获取数据。
比如：
老板：
“昨天三个车间产量是多少？”
以前：
找生产主管 → 导Excel → 汇总 → 半天。
现在：
打开BI：
实时查看。
二、小型生产级数据平台推荐架构
对于几十GB到几个TB规模的数据，我推荐：
不要一开始上复杂架构。
一个比较实用的架构：
数据源
ERP MES IoT API
|
↓
数据采集层
Python / DataX
|
↓
ODS原始层
MySQL / SQLServer
|
↓
数据处理层
Python / Spark
|
↓
数据仓库
PostgreSQL
ClickHouse
|
↓
数据服务
BI / API
核心思想：
简单，但是规范。
三、第一步：数据采集脚本
很多企业第一批数据来源：
SQL Server。
例如 MES 数据库：
生产订单表
work_order
----------------
id
product_code
qty
create_time
我们需要每天同步。
Python实现一个简单ETL：
import pymssql
import pymysql
from datetime import datetime
def extract():
conn = pymssql.connect(
server="192.168.1.10",
user="sa",
password="123456",
database="MES"
)
cursor = conn.cursor(as_dict=True)
sql = """
select *
from work_order
where create_time >= getdate()-1
"""
cursor.execute(sql)
data = cursor.fetchall()
conn.close()
return data
def load(data):
conn = pymysql.connect(
host="localhost",
user="root",
password="123456",
database="dw"
)
cursor = conn.cursor()
for row in data:
cursor.execute(
"""
insert into ods_work_order
values(%s,%s,%s,%s)
""",
(
row['id'],
row['product_code'],
row['qty'],
row['create_time']
))
conn.commit()
conn.close()
if __name__=="__main__":
data=extract()
load(data)
print(
"同步完成",
datetime.now()
)
看起来简单。
但是生产环境必须增加：
- 增量同步
- 日志记录
- 异常报警
- 重试机制
否则：
凌晨三点任务失败，没有人知道。
四、第二步：设计数据分层
很多新人喜欢：
一个数据库。
所有数据全部放一起。
结果：
三个月以后：
没人敢改。
推荐最少三层。
ODS 原始层
保存源数据。
特点：
不修改。
例如：
ods_mes_order
保存：
订单原始记录
DWD 明细层
清洗后的业务明细。
例如：
dwd_production_detail
增加：
车间
班组
产品分类
日期
ADS 应用层
给报表使用。
例如：
ads_daily_output
结果：
日期 产品 数量
8-1 A产品 2000
8-2 A产品 2300
五、第三步：任务调度
数据平台最怕：
靠人执行。
比如：
每天：
python sync.py
然后：
小王离职。
没人知道。
所以必须调度。
简单方案：
Linux Crontab。
例如：
每天凌晨2点执行。
crontab -e
添加：
0 2 * * *
/usr/bin/python3 /data/sync.py
>> /data/log/sync.log 2>&1
但是生产建议：
升级：
- Airflow
- DolphinScheduler
因为需要：
任务依赖。
例如：
订单同步
↓
订单清洗
↓
指标计算
↓
报表刷新
六、第四步：数据质量检查
这是很多平台最容易忽略的地方。
数据平台最大的风险：
不是没有数据。
而是：
错误数据。
比如：
今天生产量：
100000000件。
老板看到：
直接报警。
所以必须增加检查。
例如：
数量检查
select
count(*)
from dwd_product
where qty <0;
发现：
负数。
直接报警。
数据延迟检查
select
max(create_time)
from ods_order;
如果：
最新数据停留昨天。
说明同步失败。
数据完整性检查
例如：
订单必须有产品。
select *
from order_detail
where product_code is null;
七、第五步：日志和监控
生产系统一定要有：
“出了问题，我知道哪里坏了。”
至少记录：
ETL日志表
create table etl_log
(
id bigint,
task_name varchar(100),
start_time datetime,
end_time datetime,
status varchar(20),
message text
);
执行：
成功：
SUCCESS
失败：
FAILED
失败自动报警
例如：
Python：
try:
run_etl()
except Exception as e:
send_mail(
"ETL失败",
str(e)
)
不要等业务发现。
八、上线前检查清单
很多项目失败，不是技术问题。
而是上线前没有检查。
整理一个生产检查表。
数据层
✅ 是否有ODS/DWD/ADS分层？
✅ 是否保存历史数据？
✅ 是否支持增量更新？
ETL任务
✅ 是否支持失败重跑？
✅ 是否记录日志？
✅ 是否有异常报警？
数据质量
✅ 是否检查空值？
✅ 是否检查重复？
✅ 是否检查数据量变化？
权限安全
✅ 数据库账号是否分权限？
✅ 密码是否写代码？
✅ 是否限制生产访问？
运维
✅ 是否有备份？
✅ 是否有监控？
✅ 是否有恢复方案？
九、不要一开始追求“大”
我见过很多企业：
刚开始建设数据平台：
直接：
Kafka + Flink + Hadoop + K8S + LakeHouse。
结果：
三个月后：
没人维护。
为什么？
因为技术先进，不代表业务需要。
一个真正优秀的数据平台：
不是组件最多。
而是：
数据稳定进入，业务方便使用，出现问题快速定位。
对于大部分制造企业、零售企业、中小互联网公司：
第一阶段：
SQL Server + Python + 调度工具 + BI
完全够用。
等数据量增长：
再升级：
MySQL
↓
PostgreSQL
↓
ClickHouse
↓
湖仓架构
这是更加健康的发展路线。
十、写在最后
数据平台建设，本质不是买服务器，也不是堆技术。
它是一套：
数据采集能力 + 数据治理能力 + 数据服务能力。
从0到1最重要的不是：
“我要做一个多先进的平台。”
而是：
“今天采集的数据，半年以后还能不能找到？出了问题能不能快速定位？业务人员能不能真正使用？”
真正生产级的数据平台，往往不是最复杂的。
而是：
简单、稳定、可维护。
如果你正在建设企业数据平台，不妨先按照这份清单执行：
先跑通一条链路：
数据采集 → 数据存储 → 数据加工 → 数据展示。
跑通以后，再谈大数据。
这才是从0到1最靠谱的路线。
—— Echo_Wish
持续分享大数据、AI与企业数字化实践。
