专题 · Deep Dive
把散在 MySQL、MongoDB、HBase、Elasticsearch 里的多源数据，收成一层可复用的数据能力——底层技术统一、数据能力平台化、上层业务快速复用。
给要在多个业务系统之上做数据平台的工程同学：不止讲四层为什么这么分，每一层还写清楚用什么做——包括最容易守不住的那条线：让业务直连数据库。
数据只接一次，业务只写自己的差异。
一条链这个平台的起点不是「数据量大」，是同一件事被不同团队做了一遍又一遍。业务在长，数据源也在长，中间没人统一管。
关系数据在 MySQL，结构多变的在 MongoDB，海量明细在 HBase，要检索的在 ES。谁都没错，合在一起就是孤岛。
新业务要用旧数据，就得自己写一遍对接：四个业务对接同一份数据，就是四套连接、四套字段映射、四套权限处理。做过的取数逻辑别人也用不上——智慧搜写过的，综合轨迹那边只能复制过来改改再用。业务还在一个个加，平台就永远在补旧账，新业务要等的时间也不会变短。
底层技术只建一次 → 抽取、碰撞、合并、分析做成公共能力 → 上面的业务只写自己的业务，不再碰存储。
「数据多、数据杂」只是现象，不是问题。真正要回答的是下面三件事，每一件都对应架构里的一层。
数据来源这么多、类型还不一样，逐业务对接只会越接越乱，必须有一层把「从哪取、怎么拼、按什么口径」收在一起。复用不是把代码抄给对面，是让对方调同一个能力、得到同一个口径。
四种存储的查询写法、事务能力、分页规则都不一样。这个差异总得有人吞：不在能力层吞掉，每个业务就得各吞一遍。业务还在持续增加，如果新业务要改平台才能接进来，平台就成了瓶颈——扩展的方向必须是业务侧只写差异。
同一个人在四个库里都有记录，两个应用查出来不一样，业务方立刻就不信这个平台了。谁能查、能查哪些、查过留不留记录，放在各个应用里自己写一遍等于没做；得有一层谁也绕不过去。
三条：数据入口只留一个、新业务真的少写代码、字段说法和权限有人统一管。第二条最关键——平台这条路要是比直连还慢，业务一定绕过去。
新业务要数据，不用再自己去对接数据源，改成在平台上配一下就行。这条路必须比直连更快，不然人家一定绕过去。
换数据库、换组件的时候，业务代码一行都不用动。要是要动，说明这层是空的。
同一个字段全公司只留一份说法；谁能看什么、谁查过什么，都在固定那一层管住，出了事查得出来。
平台好不好，不看架构图，看一个新需求进来要写多少取数代码。以「查某人近三个月的轨迹并关联比对」为例。
所有外部请求先过 Nginx 与 Gateway，实时通信另走 Netty 长连接；业务应用不自己对外开口子。
入口收口，才有地方统一做鉴权、限流、审计和灰度。每个应用自己开入口，这四件事就会被做 N 遍，而且每一遍口径都不完全一样。
常见追问
是单点，所以要横向多实例 + Nginx 上游探活。收口的代价就是入口必须做得比任何应用都稳，这是设计约束不是可选项。
每一格都是实名组件与它的分工。口径是通用的：换掉「公安」两个字，任何多源数据平台都能照着这套分层判断。
这些坑跟行业无关，换任何一套多源数据平台都会原样遇到。顺序照着链路走：对接 → 分层 → 拼数据 → 统一说法 → 公共能力 → 底座 → 查一条完整链路。
最典型也最贵的一种浪费：同一份数据被四个业务各对接一遍，四套连接配置、四套字段映射、四套异常处理。改一次源表结构，要通知四个团队。
怎么改的对接数据源这件事只允许出现在抽取积木里。业务侧只描述「要什么」，不描述「从哪取」。新业务如果还需要写对接代码，说明积木没建够。
应用代码里出现「这个查 ES、那个查 HBase」，说明差异没被吸收。后果是换存储等于改所有业务，平台层形同虚设。
怎么改的查询语义在能力层定义（按实体取、按时间取、按关键词取），存储只在能力层内部路由。评审时只看一条：业务代码里有没有存储名字。
积木只把查询字符串挪了个位置，参数还是业务拼。看起来有平台，实际什么都没复用，业务换个数据源照样全改。
怎么改的每块积木必须有配置化输入输出契约，并且能独立换掉底层实现而业务不感知。做不到就只是把 DAO 换了个目录。
智慧搜里这个人叫 A，综合轨迹里少了一段。用户不会理解为「数据源不同」，只会理解为「这个平台不准」，信任一旦丢了很难回。
怎么改的实体归一放在合并积木里统一做，并且规定主源与优先级；两个应用必须调同一份归一结果，不允许各自拼。
某个业务为了快，自己写了一套登录和权限。上线时没人拦，半年后它就成了全站唯一没有审计入口的地方。
怎么改的认证与权限由接入层强制，绕过就没有路由；同时把接入成本做到足够低——多数绕过是因为规范比野路子麻烦。
底座团队把日志格式、发布流程、目录结构都做成硬性门槛，业务发现绕开平台更快，于是平台开始空心化：文档上全覆盖，实际没人走。
怎么改的底座只统一「不做会各自长一套」的部分：注册、配置、限流。其余以省事吸引人，不以审批强制人，并定期看真实接入率。
同一个接口既要秒级响应又要跑大范围统计，结果是两头都不达标：在线查询被慢任务拖住，统计任务又在等一个不可能快起来的接口。
怎么改的实时通道与批量路径分开：Netty 与短查询走在线，重统计走独立的批处理入口并明确延迟预期。能力层可以共用定义，执行路径不要共用。
这一期能确定的是结构口径，不是实测数字。平台规模类指标源材料里没有记录，全部留成回填位。
不编数字。数据源数量、日增量、总数据量、查询 P95、任务成功率、接入业务数、重复开发下降幅度，都要拿真实运维数据补上——补上之前，任何「支撑了 N 个业务、日均 X 亿条」的说法都不作数。
这个项目最后带得走的不是「用过哪几个库」，是下面这三条判断——下次再建平台，它们会先起作用。
换存储要不要改业务代码，是检验中间层真伪的唯一标准。要改，那层就是虚的；数据能力层的意义就是把选型差异关在自己身上。
重复开发真正发生在「各自对接数据源」这一步，而不是代码层面；积木只是把这一步变成配置，省下的成本比代码复用大一个量级。业务绕过平台直连库，多数不是意识问题而是平台那条路更慢更麻烦——所以治理靠降低合规成本，不靠宣讲：统一注册、配置、限流就够，把规范做成硬性门槛，业务会绕着走，平台空心化。
来源统一 → 能力复用 → 业务扩展，这个顺序不能换。跳过第一步直接建扩展机制，等于在散沙上盖楼，越扩展越乱。
以后再设计数据平台，我先问这三个问题。
决定要不要能力层，也衡量复用是不是真的。
决定合并逻辑放哪，直连是平台设计缺陷的信号，不是纪律问题。
决定能不能审计。
单次需求确实快，代价是查询语义散落在各应用里。半年后同一个人在不同应用口径不一致、换索引要改所有业务、审计无从下手——这三件事比省下的两天贵得多。
接口封装吸收的是调用复杂度，积木吸收的是数据源差异。判据只有一条：底层换存储，业务要不要改代码。要改，就还只是封装。
先定主源与优先级，再在合并积木里做实体归一，最后规定所有应用只能调归一结果。技术上不难，难的是让业务方接受自己那份不是权威版本。
平台主要服务在线查询与数据服务，四类存储已经覆盖事务、灵活结构、海量明细和相关性检索。引入用不上的组件只会多出运维面，所以按数据特点分工。
取决于它需要几种新积木，而不是对接几个数据源。数据源对接已经收口在抽取里，新业务只做业务语义——这也是判断平台是否真的在发挥作用的指标。
成立。四层里只有积木的具体种类是行业相关的（碰撞在公安业务高频），底座、能力收口、多模存储分工、公共能力复用这套判断跟行业无关。