我们团队做数据中台建设时接到一个让所有后端都皱眉头的需求把ClkLog埋点分析系统沉淀了两年多的历史数据整体迁移到新环境目标库从MySQL换成了达梦。ClkLog本身是开源可私有化部署的埋点分析系统数据模型不算复杂但真正要完整搬走涉及事件明细大表、预聚合结果、配置元数据三类数据一套迁移方案要同时照顾体量、增量、业务口径三头。这篇文章不准备讲高大上的方法论就把这次ClkLog埋点数据迁移从盘点、导出、改写、导入、校验到增量的完整过程写下来特别是从MySQL到达梦这步里踩过的方言和类型坑给同样在做埋点数据迁移、数据中台整合的团队做个参考。1. ClkLog这套埋点系统为什么最难的活是搬家1.1 三种典型的ClkLog数据迁移场景ClkLog的定位是开源的、可私有化部署的埋点分析系统采集端、分析端、可视化端拆得比较清楚。只要公司有前端页面或App端埋点需求部署一套之后就可以看到用户行为、漏斗转化、留存这些核心指标。可正因为私有化部署这个特性数据去哪儿、怎么换环境、怎么和其他系统整合就成了绕不开的话题。我这次遇到的需求是数据中台建设过程中要把ClkLog的数据并进统一数据环境而且目标库不是MySQL而是达梦。做之前我梳理了一下日常工作中ClkLog的数据迁移大致可以分三类迁移场景源库到目标库常见原因难度同构搬迁MySQL到MySQL测试环境转正式环境、服务器更换较低但要防丢数据异构数据库替换MySQL到达梦、PostgreSQL等数据中台统一存储、国产化适配较高类型和SQL方言都要处理平台替换自建或第三方埋点迁到ClkLog换埋点工具统一行为分析最高字段语义都要映射同构搬迁大部分人都会mysqldump倒一遍再source回去就完事风险点主要在大表超时和字符集。平台替换则是从别的系统的数据格式翻译成ClkLog的数据格式比如对方的时间戳是毫秒、你的表存的是秒对方的用户标识是手机号、你的模型用自增ID这些不是SQL层面能解决的。真正让很多团队头疼的其实是第二类——异构数据库替换。它表面上只是换了一个存储引擎实际上表结构语法、字段类型、内置函数、索引策略全部都要重新过一遍。1.2 埋点数据表的特点直接影响迁移方案ClkLog的表看起来不复杂但按数据性质划分其实是三类迁移策略完全不一样。第一类是事件明细表也就是原始埋点数据。每一条用户行为都占一行字段包括用户标识、事件名、发生时间、页面路径、设备信息再加上业务方自定义的各种属性参数。这类表的特点是体量巨大是整库的绝对大头按时间自然增长表结构相对固定但自定义属性这块经常是长文本或JSON存放。迁移时不能指望一次性灌进去必须做时间分片、分批提交。第二类是分析结果表比如漏斗、留存、热力图、用户路径这些预聚合出来的结果。它们的特点是行数不大但业务直接读它们出报表迁移后如果不重算数据就是历史快照和最新状态对不上。我的建议是结果表只做结构迁移数据等事件明细迁移完成后在目标环境重新跑一遍分析任务让ClkLog自己把结果算出来比人工搬运可靠得多。第三类是配置和元数据表比如埋点事件定义、字典、用户标签配置、报表看板配置。这些表体量很小但一旦丢失或者字段映射错位前端页面看到的事件名全变乱码分析口径直接崩掉。所以这类表必须优先迁移并且迁移后要有专门的核对步骤。这三类表的差异决定了整个迁移方案不能一把梭。我们最后定的策略是配置表优先搬、事件明细表分片搬、结果表不搬靠重算。后面所有执行步骤都是围绕这个策略展开的。2. 迁移前三件事盘点存量、摸清模型、选对工具2.1 先盘家底存量数据与业务口径清单很多人一上来就执行迁移这是大忌。迁移不是复制文件你连要搬多大的量、哪些表能丢、哪些表不能丢都没搞清楚后面一定翻车。我们做ClkLog数据迁移的第一步是盘家底核心是回答三个问题。第一个问题到底有哪些表在ClkLog的MySQL库里执行这个SQL把表清单、预估行数、占用空间列出来SELECT table_name, table_rows, ROUND((data_length index_length) / 1024 / 1024, 2) AS size_mb FROM information_schema.tables WHERE table_schema clklog ORDER BY size_mb DESC;这一步很快就能知道哪几张表是巨头。以我们的环境为例事件明细表占了整个库95%以上的空间还有一张用户属性表有接近千万行剩下的几十张配置表都很小。有了这个清单迁移顺序和分片策略基本就定了。第二个问题业务口径是什么埋点系统最怕的不是丢数据而是数据都在但口径变了。比如注册成功这个事件在业务方那里叫register_success到了ClkLog里埋点代码可能叫sign_up_ok页面路径/app/home和/home可能也是同一个页面。这类映射关系在数据库层是看不出来的必须在迁移前和业务方一起把口径清单整理出来迁移后按这份清单验证。第三个问题哪些数据可以不用搬这是很多团队忽略的。比如过期的临时表、几年前的日志表、可以重算的结果表都不值得花时间迁移。把不用搬的剔除掉迁移量能少20%到30%。做完上面这些立刻对原库做一次完整备份。工具上MySQL环境可以直接用mysqldump也可以在云平台做快照。这不是流程仪式是万一迁移中出了问题能退回来。我们当时的底线是原环境保留至少一周迁移期间任何一步不放心都能回滚。2.2 迁移工具选型手工SQL、DTS和ETL怎么选工具选型是迁移方案里最容易纠结的环节。我们评估了三类工具各自优缺点很明显。第一类手工导出SQL再导入目标库。优点是完全可控导出什么、改写什么、导入什么都清清楚楚适合一次性存量迁移缺点是在异构环境下要处理大量方言差异而且大数据量下直接执行SQL文本效率很低。适合小表不适合事件明细这种上亿行的大表。第二类达梦自带的DTS数据迁移工具。做MySQL到达梦时DTS能识别源库的表结构和数据自动做大部分类型映射生成目标库的建表语句。优点是自动化程度高几百张表不用手搓DDL缺点是遇到特殊字段比如JSON、自定义枚举还是需要人工介入而且增量同步能力偏弱。适合存量数据一次性迁移。第三类DataX这类ETL同步工具。配置一个readerMySQL和一个writer达梦把数据一条条读出来写进目标库。优点是灵活能写转换逻辑能在两边数据库之间直接搭桥不需要生成中间的SQL文件缺点是部署和调优有一定门槛字段多的时候写法要仔细。我们的实际选型是混合方案表结构用DTS生成的DDL做底稿人工改写有问题的部分存量数据用DTS跑一遍大表再拆成时间分片后续的增量数据用ETL定时同步。这个组合兼顾了效率和可控性。具体怎么落下面两章详细说。提示如果你们的迁移量很小比如总共不到100万行、几十张表那不用纠结工具手工导出SQL足够。工具选型的复杂度只在数据量上来之后才值得投入。3. 从MySQL导出到达梦导入一份可执行的迁移落地过程3.1 导出阶段mysqldump参数与数据分片策略存量迁移的第一步是从源库导出数据。当时我们面对的情况是配置类小表几十张可以直接整体导出事件明细表体量过大必须按时间分片。分片不只是为了让导出文件变小更关键的是让导入可以在任意分片上重试不至于一个大文件导入到一半失败后全部从头再来。对于小表导出结构用mysqldump -u clklog_user -p --no-data --single-transaction clklog clklog_schema.sql导出数据用mysqldump -u clklog_user -p --no-create-info --single-transaction clklog config_table_detail config_table_detail.sql--single-transaction的意思是导出过程中不锁表对线上正在采集埋点的库比较友好。--no-create-info是只导出数据不导出表结构。这两个参数看着基础但很多第一次做的人会漏掉其中一个导致导出文件里混着结构数据异构导入时反而更麻烦。对于事件明细这种大表我们按月分片导出。假设事件表名是event_log里面有时间字段event_timemysqldump -u clklog_user -p --no-create-info \ --whereevent_time 2024-01-01 AND event_time 2024-02-01 \ clklog event_log event_log_202401.sql每个月一个文件连续导上24个月。这里不用追求一条SQL导出全量分片文件多反而便于后面导入时多线程并发。还要注意一点mysqldump导出的SQL文件里INSERT语句会带上库名、带反引号、带ENGINEInnoDB这些MySQL专属写法这些在达梦里基本都不能直接用。所以异构场景下mysqldump导出的文件我们只当作数据备份和参考实际喂给达梦的数据走DTS或者CSV会更顺。3.2 导入阶段达梦兼容的DDL改写与数据装载真正往达梦导入时我们分了两步走先建表再装数据。建表这步强烈建议不要直接用mysqldump导出的建表语句而是用达梦DTS自动生成的DDL做底稿然后人工检查。以事件明细表为例MySQL里可能是这样的CREATE TABLE event_log ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 自增ID, user_id VARCHAR(64) COMMENT 用户ID, event_name VARCHAR(128) COMMENT 事件名, event_time DATETIME COMMENT 发生时间, page_path VARCHAR(512) COMMENT 页面路径, device_info TEXT COMMENT 设备信息, custom_props TEXT COMMENT 自定义属性JSON, PRIMARY KEY (id), KEY idx_event_time (event_time), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT埋点事件表;在达梦环境里要改成CREATE TABLE event_log ( id BIGINT IDENTITY(1,1) PRIMARY KEY, user_id VARCHAR(64), event_name VARCHAR(128), event_time DATETIME, page_path VARCHAR(512), device_info TEXT, custom_props TEXT ); CREATE INDEX idx_event_time ON event_log(event_time); CREATE INDEX idx_user_id ON event_log(user_id); COMMENT ON TABLE event_log IS 埋点事件表; COMMENT ON COLUMN event_log.event_name IS 事件名;差异很明显AUTO_INCREMENT变成了IDENTITY(1,1)表注释从DDL里抽出来变成COMMENT ON语句ENGINE和DEFAULT CHARSET直接去掉。如果表有分区MySQL的分区表达式和达梦的分区语法也要逐一转换比如MySQL的PARTITION BY RANGE (YEAR(event_time))到达梦要改成PARTITION BY RANGE (event_time) (PARTITION p1 VALUES LESS THAN (2024-01-01))不能照抄。数据装载这一步我们的大表没有用source执行SQL文件而是用达梦的批量装载工具dmfldr灌CSV。流程是先把MySQL表查出来导出为CSV再写一个简单的control文件然后执行装载dmfldr useridSYSDBA/123456localhost:5236 control/data/event_log.ctl data/data/event_log_202401.csvdmfldr的control文件里指定表名、字段分隔符、跳过行数这些信息。它的导入效率比逐条执行INSERT高一个量级。小表就直接在达梦管理工具里右键导入SQL文件或者disql执行都行怎么省事怎么来。4. 异构迁移的硬骨头方言差异、类型映射与SQL改写4.1 字段类型映射从TINYINT、DATETIME到TEXT的对照做过一次异构迁移就会明白类型映射是第一个坑。MySQL和达梦的数据类型大体对齐但细节上到处是玻璃渣。我们整理了一张常用映射表照着处理基本不会出大问题MySQL类型达梦推荐类型注意事项TINYINTSMALLINTMySQL的TINYINT(1)常被当作布尔类型达梦建议用BIT或直接SMALLINTINT / INTEGERINT范围一致BIGINTBIGINT主键常用注意自增实现方式不同DECIMAL(p,s)DECIMAL(p,s)精度需要保持一致FLOAT / DOUBLEFLOAT / DOUBLE精度敏感场景建议转DECIMALCHAR / VARCHARCHAR / VARCHAR注意VARCHAR长度单位差异MySQL按字符、达梦按字节TEXTTEXT / CLOB超长文本建议CLOBBLOBBLOB二进制数据DATETIMEDATETIME / TIMESTAMP时区处理要注意DATEDATE没问题JSONTEXT / CLOB达梦有JSON类型但为兼容性直接用文本更稳最容易被坑的是TEXT和JSON。MySQL的TEXT有长度上限达梦的TEXT理论上也够用但我们在迁移custom_props这种可能塞很多自定义参数的字段时直接改成了CLOB规避了字符集转换时的截断风险。JSON字段更麻烦ClkLog里面有些事件属性是用JSON存的MySQL里可以直接对JSON字段做查询但达梦默认不会把JSON当成JSONB那样去支持稳妥做法是迁成TEXT/CLOB然后靠应用层解析。VARCHAR的长度单位也要特别说明。MySQL的VARCHAR(255)表示255个字符达梦的VARCHAR(255)在UTF-8编码下通常按字节算一个中文占3个字节如果表里存中文255字节只能存85个汉字。遇到原来VARCHAR(255)的字段我们统一改成了VARCHAR(512)甚至VARCHAR(1024)宁可空间多一点也不能让长文本插入时被截断报错。4.2 函数与SQL方言差异ClkLog统计SQL的改写点类型对完了SQL语句又是新一轮问题。ClkLog的埋点分析查询里高频出现的几个函数在MySQL和达梦里写法不一样。最典型的是IFNULL和GROUP_CONCAT。MySQL里判断空值写IFNULL(event_name, 未知)达梦里更通用的是NVL(event_name, 未知)。如果目标库开了MySQL兼容模式IFNULL也能跑但我们当时的达梦库是默认Oracle模式所以所有IFNULL都要改成NVL。这个坑不致命但几十条报表SQL挨个检查很磨人。GROUP_CONCAT换成LISTAGG也有语法差异。MySQL写SELECT user_id, GROUP_CONCAT(page_path ORDER BY event_time SEPARATOR - ) FROM event_log GROUP BY user_id;达梦里要改成Oracle风格的LISTAGGSELECT user_id, LISTAGG(page_path, - ) WITHIN GROUP (ORDER BY event_time) FROM event_log GROUP BY user_id;我之前在数据中台整合时遇到过类似的情况一条日报SQL里用了DATE_FORMAT(event_time, %Y-%m-%d)做按天统计MySQL里很顺手到达梦就得改成TO_CHAR(event_time, YYYY-MM-DD)。LIMIT语法达梦倒是能兼容但大数据量分页时性能远不如Oracle风格的ROWNUM写法。这些改写点看起来琐碎实际执行时要盯住ClkLog常用的那几个分析场景事件概览、漏斗计算、用户留存。我们专门列了一个函数对照表发给团队约定迁移期间所有SQL先自检函数方言再上达梦执行。提示如果条件允许在达梦初始化时直接把COMPATIBLE_MODE设为MySQL兼容格式很多IFNULL、LIMIT、反引号的问题会自动消失。这个在迁移前就要和DBA确认清楚别等建完表才发现模式不对。5. 迁移完成不等于结束数据校验与业务口径兜底5.1 行级校验数量、抽样与异常边界数据导完很多人松了一口气其实最关键的校验环节才刚刚开始。我们在ClkLog数据迁移里做了三层校验全表行数校验、字段抽样校验、业务口径回归。行数校验最简单也最致命。对每一张迁移过的表在MySQL和达梦分别执行count两边数字对不上就是迁移丢了数据。事件明细这种大表count会很慢但这一步不能省。还可以用max和min校验ID边界确认没有整段缺失SELECT COUNT(*), MIN(id), MAX(id), MIN(event_time), MAX(event_time) FROM event_log;字段抽样校验是针对核心字段做抽查。比如随机抽1000条记录逐字段对比user_id、event_name、event_time、page_path是否一致。抽样不能光抽前面的要在全表分布上随机取否则查不出中间某个月分片漏数据的问题。异常边界检查我们吃了亏才补上。导入达梦后发现有几张表的create_time字段出现了很多1970-01-01明显是类型转换时TIMESTAMP默认值搞出来的脏数据。后来我们就加了一条规则凡是日期时间字段先统计最小值和最大值出现1970年、2038年、0000-00-00这些边界值一律标记为异常人工确认后再决定保留还是修正。5.2 业务层验证用ClkLog常用分析场景做回归行级校验通过只代表数据在不代表业务能跑。埋点分析系统和普通业务系统的差别在于它的数据最终要喂给分析模型。如果表结构变了、字段语义变了查询出来的漏斗、留存全是错的那迁移就是失败的。我们的做法是列一组回归用例全部来自ClkLog最常用的场景。第一个是事件概览按天统计某个事件的触发次数迁移前后跑出来的趋势线要能对上误差在接受范围内。第二个是漏斗分析比如从访问首页到注册成功再到下单支付每一步的人数要和迁移前的历史报表基本吻合。第三个是留存按周留存、按月留存的结果要有可解释性不能出现负数、超过100%、或者某天的留存为0的死数据。这些回归用例如果跑挂了优先排查三件事一是函数方言还有没有漏网之鱼二是索引没建全导致SQL走了全表扫描慢到超时三是某些字段在类型映射后精度丢失比如DECIMAL变成FLOAT之后四舍五入的误差被统计放大。我们实际操作中索引问题占了一半以上导完数据没建全索引分析查询又慢又容易超时一度误以为迁移出了问题。6. 回过头看ClkLog数据迁移中的取舍与复盘6.1 迁移过程中的三个高发问题与排查链路复盘这次ClkLog迁移有三个问题属于典型高频在这里把完整排查链路写出来方便遇到同类问题的团队直接对照。第一个问题导入后中文乱码。现象是埋点参数里的中文全部变成问号。排查链先查源库字符集确认是utf8mb4再查导出文件编码是不是UTF-8接着查达梦库的字符集参数是不是GBK最后查load时客户端工具和连接串指定的字符集。我们最后定位到的问题是dmfldr装载CSV时没有指定字符集工具默认按系统编码读中文就炸了。解决方法是control文件里显式加上CHARACTER_SETUTF-8重新装载后乱码消失。第二个问题建表时AUTO_INCREMENT报错。现象是把MySQL建表语句粘到达梦执行直接语法错误。排查链先看错误信息指向的具体位置多半是AUTO_INCREMENT和ENGINEInnoDB查达梦文档确认IDENTITY才是对的关键字再把所有建表语句统一改写去掉MySQL专属片段。这个没什么技术含量但量大的时候很容易烦躁建议写在DDL检查清单里逐条过。第三个问题大表导入到一半连接中断。现象是事件明细表导入时跑了十几分钟突然报连接断开已经导入的行数不确定。排查链先看达梦服务端日志是网络超时还是内存溢出再看客户端导入工具是否设置了自动提交大批量INSERT如果每个事务都默认提交会拖死整个会话最后是分批提交把一亿行的任务拆成按月分片每个分片独立导入独立验证。我们用dmfldr后这个问题就没再出现过它本身就是按批装载的比逐条INSERT抗风险能力强得多。6.2 后续扩展增量同步与双跑方案存量迁移完成后真正的考验是增量。ClkLog会持续采集新的埋点数据。如果MySQL還继续在跑达梦只是切了一片静止的历史数据两边数据会越差越多。我们结合数据中台整合的实际情况提供了两种增量方案。方案一在应用层双写让ClkLog在写入时同时往MySQL和达梦各写一份。优点是最实时两边数据从源头就一致缺点是要改采集端的代码而且如果达梦暂时还不稳定会把写入延迟放大。适合目标库转正之后短期的过渡。方案二用ETL定时做增量同步每隔5到10分钟把MySQL新增的数据同步到达梦。我们选了这种因为对采集链路侵入为零只在中间加一层同步任务。增量同步任务的一个关键配置是时间字段偏移量因为数据从产生到落库有延迟同步时要把当前时间往前拨几分钟避免漏掉刚好卡在边界上的记录。我们在正式切换前还做了一周双跑验证ClkLog的报表和分析任务同时在MySQL和达梦上跑每天对比核心指标连续一周无异常才把业务切过去MySQL降级为备份角色保留一个月后才下线。这套流程下来虽然整个迁移周期拉长了但线上业务一次事故都没出。从这次ClkLog写入迁移的经验来看埋点数据迁移难的不是搬数据这个动作而是你愿不愿意在迁移前花时间盘模型、选工具迁移后花时间做校验、做增量。这三件事做扎实无论源库是MySQL、目标库是达梦还是换成其他数据库底层的方法论都是通用的。最后再提醒一句迁移完成后一定要让业务方自己点开ClkLog的看板亲手验证几个最常用的分析报表。系统认为数据没问题不代表业务认这个验收环节千万别省。