干弱电这行十多年了，最近几年“城市大脑”和“一网统管”的活儿越来越多。不少朋友问我，这数据中台到底该怎么搭，才能让领导看了点头、下面用着顺手？今天咱就掰扯掰扯，把这几年踩过的坑和攒下的经验说说。
先别急着上设备、买软件。数据中台的核心不是技术多牛，而是数据能不能打通。很多项目一上来就堆服务器、搞大数据平台，结果发现各个部门的数据格式、接口标准、网络环境全都不一样——城管用的是老系统，应急那边是独立专网，公安的数据根本不敢往外连。这时候你才发现，最难的活儿不是建平台，是做对接。我一般建议先花一个月做数据摸底，把每个部门的数据类型、更新频率、网络隔离情况摸清楚，画一张“数据血缘图”，再定中台的顶层设计。这一步省不了，省了后期准翻车。
数据中台的架构，我习惯分成三层说：采集层、治理层、服务层。
采集层要解决“怎么把数据拿过来”。别看现在物联网设备多，很多老项目的数据还在Excel里躺着，甚至靠手写表格。这时候得考虑用轻量级的ETL工具或者API网关，能自动抓的自动抓，不能自动的设个手工导入接口。别一上来就搞实时流式处理，成本高不说，很多业务场景根本不需要秒级更新，每天一次批量同步就够用。
治理层是核心，也是最容易出问题的。说白了就是清洗、标准化、打标签。比如“事件位置”，城管叫“坐标”，应急叫“经纬度”，公安叫“GPS”，你得统一成一种格式。这里有个土办法：建一个“数据字典库”，把每个字段的别名、单位、取值范围都列出来，让各部门确认签字。别嫌麻烦，后面所有应用都靠这个字典活着。
服务层就是对外接口。很多项目做成“数据黑箱”，只给个表格看报表，业务系统根本调不了数据。正确做法是提供标准API，让各应用能按需调用。比如城管App要查某个井盖的维修记录，直接调中台的接口就行，不用再去翻原始库。
说个实际施工时踩过的坑。有次在南方某城市做一网统管，前期规划得好好的，结果一接入公安的视频流，发现他们用的是H.265的专网编码，我们的解码器不支持。临时换设备，工期拖了半个月，预算还超了。后来学乖了，做方案时一定把各系统的硬件兼容性列个表，尤其注意老设备的编码格式、协议版本。签合同前让厂家出个互认测试报告，哪怕多花几天，也比后期改方案强。
省钱技巧也得说说。很多甲方一上来就要买全套商用大数据平台，几十万起步。其实中小城市的数据量没那么大，用开源框架搭一套完全够用。比如用Apache NiFi做数据采集，用Kafka做消息队列，用Flink做流处理，再配个MySQL或者PostgreSQL存元数据。整套下来硬件加开发，十万以内能搞定。当然，安全性和权限管理得自己多下功夫，别省出漏洞来。我一般建议核心业务数据用商用库，非核心的用开源，混搭着来最划算。
最后说下运维。数据中台建成后，最怕没人管。很多项目验收完就没人维护，数据越积越乱，半年后跑不动了。建议在方案里就加上数据治理岗位的预算，哪怕只配一个兼职的，每天检查数据质量、更新字典、清理冗余。定期做个数据健康报告给领导看，让他们知道这系统在干活。另外，备份策略一定要做，我见过因为硬盘坏了导致半年数据全丢的，那叫一个惨。
总的来说，城市大脑的数据中台，建起来不难，难的是让数据真正流动起来。别光盯着技术指标，多花心思在数据治理和部门协调上。干这行十几年，我最大的体会是：技术是手段，业务是目的，别本末倒置。
