我见过太多一上来就学 Spring Boot、学机器学习的同学张口闭口“大数据”结果连一个 CSV 文件里的中文乱码都搞不定也说不清楚为什么自己电脑里“系统数据”突然占了 100 个 G。这些问题听起来很基础却实实在在卡住了不少人。今天这篇我想结合自己跟计算机打了十多年交道的经验把数据在计算机里的表示、存储、流转和保护这条主线完整地串一遍。不管你是刚入行的程序员、转行做数据分析的还是搞运维和网络的老手把这块地基补扎实后面的技术栈学起来会顺很多。整个内容不需要你背公式我会把背后“为什么是这样”的逻辑一起讲清楚读完你至少能回答数据在机器里到底是什么形态、为什么经常出错、数据又是怎么从收集到展示的。1. 数据到底是什么从一道“薛定谔的缓存”说起1.1 信息与数据先别急着写代码上周末朋友在微信里发我一个截图说服务器接口突然返回一串数字问我是不是出 Bug 了。我一看那串数字是把一个 JSON 对象序列化后的结果本身没毛病。这个例子刚好说明数据是一堆客观存在的符号而信息是人对它的解释。同一串 01000001按 ASCII 解读是字母 A按无符号整数解读是 65按 RGB 的一个颜色分量解读又是另一种结果。所以学数据基础第一步不是背二进制而是建立这种“数据没有固定含义”的敏感度。数据库里的字段也好接口返回的 JSON 也好只有当你知道它的类型、单位和业务含义时它才能变成信息。比如传感器返回一个 0.87可能是温度 87 度也可能是湿度 0.87。因此数据治理的第一步永远是定义元数据。你连这个字段代表什么都不说清楚后面分析就是在沙滩上盖楼。1.2 计算机眼里只有0和1进制到底怎么换算为什么计算机非要用二进制因为底层电路最容易实现两种稳定状态有电/没电高电平/低电平。用十进制需要分辨十种电压成本高也不可靠。所以 CPU、内存、硬盘内部的一切归根到底都是 0 和 1。虽然我们平时写代码用的是十进制、写颜色用的是十六进制但到了硬件那一层全是电平信号。二进制写起来太长。一个 IP 地址 255.255.255.0 用二进制写是 11111111.11111111.11111111.00000000。为了让人好读我们常用十六进制代替每 4 位二进制对应一位十六进制。比如 4 位二进制 1111 等于十进制 15十六进制写 F。0xFF 就是 2550xAB 就是 171。这点在开发中太常见了颜色值、内存地址、注册表、抓包数据全是十六进制。你要是看不懂调试都会比别人慢半拍。进制的换算我建议不要死记公式。你只需要懂一个套路从右往左每一位乘以基数的 N 次方再相加。比如二进制 11010110 换成十进制1×2^7 1×2^6 0×2^5 1×2^4 0×2^3 1×2^2 1×2^1 0×2^0 128 64 16 4 2 214。反过来十进制转其他进制不停地除以基数取余数从下往上写余数。这个方法对二、八、十六进制都通用写一遍就熟了。另外注意一个经常被坑的点十进制转二进制整数部分通常能精确转但小数部分不一定。比如十进制 0.1 转二进制会得到一个无限循环的 0.000110011001100...。计算机存储浮点数时只能截断这解释了为什么 0.1 0.2 在许多编程语言里不等于 0.3。先把这个刻在脑子里后面碰到浮点误差就不会一脸懵。2. 数据的“皮囊”编码、类型与结构2.1 字符编码ASCII到Unicode的坑文本也是一种数据但文本编码的坑几乎所有人都会踩。最早的 ASCII 编码只用了 7 位定义了 128 个符号对英文够用但中文一个都 Hold 不住。于是国内有了 GB2312、GBK繁体地区有 Big5。各家编码互不兼容经常出现同一个字节流用不同编码打开就是不同的字。后来统一世界的 Unicode 来了把全世界字符映射到码点然后为了节省空间出现了 UTF-8、UTF-16 等存储方式。UTF-8 是变长编码纯英文和 ASCII 一样是 1 字节中文一般是 3 字节。乱码的根因很简单写入时的编码和读取时的编码不一致。比如某网站在导出 CSV 时用了 GBK你用默认 UTF-8 的 Excel 打开中文就变成“锟斤拷”。我自己有个习惯跨系统、跨平台的项目一律 UTF-8数据库连接串里明确指定 characterEncodingutf8当拿到一个旧文件时先用文本编辑器 VSCode 或 Notepad 查看右下角编码再决定用什么方式打开。如果你要给别人发 Excel 能直接打开的 CSV建议用带 BOM 的 UTF-8 导出否则 Windows 版 Excel 容易识别成 ANSI 导致乱码。这个细节做数据分析的人几乎都遇到过。2.2 数据类型为什么Excel里“12”可能是文本类型是给计算机看的。同样是 8 位二进制 01000001如果声明为整数运算会按整数处理如果声明为字符就按字符处理。所以类型决定了“二进制怎么解释”和“能做什么操作”。这一点特别基础但特别多人忽略。最常见的数据类型有整数、浮点数、字符串、布尔值还有日期时间。每种类型在内存中占的字节数和取值范围不同。比如 Java 里的 int 占 4 字节范围约 21 亿到-21 亿long 占 8 字节。如果用 int 存一个超过范围的整数就溢出变成负数。Excel 里一个数值如果被格式化成了文本SUM 求和时就会把它忽略掉。你可以在单元格左上角看到绿色三角的警告用“分列”或“文本转数字”批量改回来。这算典型的数据类型错误。浮点数尤其要小心。银行金额计算如果直接拿 float 做累加账面上会出现 0.0000004 的误差对账对不上。正确做法是用高精度的定点数或字符串比如 Python 的 decimal、Java 的 BigDecimal、数据库里的 DECIMAL(10,2)。一句话总结文本类型防误解整数类型防溢出浮点类型防误差日期类型防时区。无数生产事故最后查下来就是这四个里的一个。2.3 数据结构从数组到图数据的组织方式数据存在计算机里不是一坨乱麻而是按特定结构组织的。数据结构这门课的核心就是研究用什么样的“架子”装数据能让读写最快。虽然很多人觉得它是纯理论但它是你好多工具选型的底层依据。最基本的划分是线性与非线性。数组是连续内存按下标随机访问快但插入删除慢链表是节点串连插入删除快但要查找节点得一个个走。栈是后进先出实现递归、撤销操作队列是先进先出做任务排队、消息缓冲。再往上树适合表达层级关系比如文件目录、公司组织架构图适合表达复杂网络比如社交关系、路线规划。这些不是面试题是你每天用的列表、队列、数据库索引的根基。实际开发里语言内置的数据结构已经封装好了。比如 Python 的 list 本质是动态数组dict 本质是哈希表。哈希表用哈希函数把键映射到数组下标所以 dict 查找接近 O(1)但要注意哈希冲突、扩容等细节。SQL 数据库索引常用 B 树为什么不用哈希做索引因为等值查找哈希快但范围查找哈希就傻眼了B 树天然支持按范围扫描。这就是学了数据结构和没学的区别——你至少要知道为什么 MySQL 的 InnoDB 用 B 树。3. 数据怎么进到计算机采集、输入与预处理3.1 数据采集的几种典型来源讲到数据很多人只想到鼠标键盘输入但其实在生产系统里数据来源五花八门。最常见的是传感器和采集卡比如温度、压力、振动信号通过数据采集卡把模拟信号转成数字信号。这里有两个关键参数采样率和分辨率。采样率决定一秒采多少个点分辨率决定每个点用多少 bit 表示。你采样率不够高频信号就会被“混叠”成假的低频信号数据看似有其实是错的。选采集卡这两个参数比品牌更重要。第二种是程序接口也就是 API。行情、天气、物流状态都是服务端把数据以 JSON 或 XML 返回给客户端。你调 API 时除了拿数据还要注意限流、鉴权、重试返回的 JSON 也要校验字段是否缺失或类型不对。很多业务问题源头就是上游接口悄悄改了字段名下游没发现整个报表就诡异了。第三种最常见但最容易被忽略日志、文件和手工录入。比如服务器访问日志、Excel 表格、别人填的问卷。这些来源的数据往往最脏格式不统一下一节专门讲清洗。搞清楚数据从哪里来才知道该用什么方式接、可能有哪些坑这是数据链路的第一步。3.2 数据预处理脏数据怎么变干净脏数据不是脏在伦理上而是脏在质量上。典型问题缺失值空行、重复记录、格式不一致2024/1/1 和 2024-01-01 混着、异常值年龄 300。数据预处理就是把这些脏东西弄掉否则后续统计结果全是错的。有个说法数据处理工作里清洗要占 60% 以上的工作量。这句话不是夸张。如果你只在 Excel 里做事可以用 SUMIF/COUNTIF 这类函数按条件统计。比如 A 列是产品名称B 列是销售额你想统计名称中包含“正式”的销售额用 SUMIF(A:A,正式,B:B) 就行。注意通配符星号在 SUMIF 里是支持的。如果数据超过几十万行Excel 会卡建议用 Python pandasdf.drop_duplicates() 去重df[col].fillna(0) 补缺失再用条件筛选把异常值剔除。清洗完了别急着分析先输出一份数据质量报告看看每列缺失率、唯一值数量、范围心里有底再往下走。3.3 数据的实时读取以TDengine为例的时序数据处理有些场景下数据是源源不断的时间序列比如服务器监控指标、IoT 传感器数据。传统关系数据库写入太慢时间序列数据库更合适。TDengine 是一个我实测过得比较顺手的时序数据库它的思路是把同一张表按时间分片利用时序数据天然的顺序性把写入和查询做得很快。但要注意它和普通数据库的“立即返回”语义有一定差别。用 TDengine 这类数据库时有一个基础概念要清楚写入成功到底是落盘了还是只是写进了内存很多实时数据库为了提高吞吐会先把数据放进 WAL 日志和缓存稍后再批量落盘。如果你刚 insert 了一条数据立刻去查询可能因为数据还在缓存层而未读取到。强一致场景要设置相匹配的落盘策略比如调整同步和异步参数。这个坑不少人都踩过。所以我的习惯是任何数据库、任何存储系统第一件事看它的持久性级别不能在没搞懂的前提下拿生产数据做实验。4. 数据要存到哪里存储层次与数据库基础4.1 从寄存器到云盘存储金字塔计算机组成原理里最反常识的一点就是存储速度的差距。CPU 里寄存器最快几乎和处理器同频然后是 SRAM 做的一级二级缓存接着是 DRAM 做主存也就是内存再往下是 SSD/HDD最后是网络存储和云盘。从寄存器到云盘速度大概差了几千倍到几万倍容量和单位成本也一路降。所以操作系统和 CPU 用缓存、预取、局部性原理来填平这道鸿沟。举个实际例子一个 Java 程序频繁读写同一个变量这个变量会被 CPU 缓存命中速度极快但如果频繁读写一个很大的字节数组数据可能在内存和磁盘之间换入换出程序就变得很慢。你会遇到“感觉机器没跑满但程序就是慢”这时要怀疑是不是存储层次的问题。排查性能不只要看 CPU 使用率还要看内存带宽、磁盘 IO 和 Cache Miss。4.2 文件存储 vs 数据库怎么选说到存数据最朴素的方式是存文件CSV、JSON、XML、二进制格式。优点是简单、可读、容易分发缺点是并发读写和查询复杂。数据量小、单机使用、不需要事务控制时文件或 SQLite 就是最佳选择。比如很多桌面工具把配置存成 JSON就很合理。一旦上了多人协作、复杂查询、事务一致性的场景就该上数据库了。关系型数据库把数据组织成二维表格行和列适合订单、用户、财务这类结构化数据。非关系型数据库如 Redis 是内存键值适合缓存和计数器MongoDB 是文档型适合半结构化的 JSON 数据图数据库适合关系复杂的数据。选型不是看谁火而是看你的数据形态和访问模式。结构化强、强一致优先选关系型高并发读多写少、允许最终一致可以考虑缓存和 NoSQL。这里我再补一句数据库也是由文件组成的。MySQL 的每张表对应一堆 .ibd 文件PostgreSQL 有 base 目录。所以当磁盘空间不足时不只是查个表的问题你的整个库都可能起不来。因此磁盘监控和存储选型永远是一条绳上的蚂蚱。4.3 一次“磁盘空间莫名被占满”的排查实录很多朋友电脑上明明没装什么东西磁盘却被占满了。脱掉外衣数据不仅是你手动保存的文档还包括系统日志、缓存、休眠文件、Windows.old、数据库临时文件。我曾在 macOS 上看到“系统数据”占了 100 多个 G打开存储管理发现是 iOS 备份和微信等的缓存手动删掉后瞬间多出 40G。Windows 上 C 盘满常见原因是页面文件和休眠文件。你可以在命令行执行 powercfg /h off 关休眠或者用 TreeSize 这类工具扫大目录。另外提醒磁盘几乎满的时候数据库写入会报磁盘无空间服务直接飘红日志也会疯狂报错。所以运维监控不仅看 CPU 和内存至少还要看磁盘剩余容量和 inode 数量。这是一个非常基础却老有人忘的事。数据存储是一个容器问题容器满了再好的数据架构也得停摆。5. 数据怎么跑起来计算、分析、可视化5.1 从传感器到报表一条数据流水线当数据从采集点一路走到业务报表会经过一座流水线采集 - 传输 - 存储 - 清洗 - 聚合 - 分析 - 可视化。每个环节都可能丢数据、改数据、拖慢速度因此理解这张链路是数据基础的核心。你遇到的“数据怎么不准”绝大多数都能在这条链路上找到答案。小场景下比如一个门店的销售数据可能就是 Excel 手工录单汇总的时候用透视表。大一点会用到消息队列接收埋点日志存到数据仓库再用 SQL 做 ETL最后接一个 BI 工具。你不需要一开始就把整套最重的架构搭出来但脑子里要有这样一条线。比如数据为什么不准你可以从这条线上游到下游逐一排查是采集端漏采了还是传输丢了还是清洗时误删了还是报表聚合口径不对。这个过程靠的就是对数据基础流程的熟悉。5.2 数据可视化为什么别只用饼图数据可视化的本质是把数据映射成图形的颜色、位置、长度、面积。它是给人类看的不是给机器看的所以选图必须匹配你想回答的问题。想表达趋势变化用折线图想对比排名用柱状图想看占比用饼图但饼图分类不要超过五类否则眼睛分不清角度差异想看数据分布用直方图和箱线图箱线图还能帮你看异常值。工具上简单汇报足够用 Excel 的图表网页大屏可以用 ECharts它上手极快官方示例几百个直接复制改数据就能用。ECharts 里我常用的是折线、柱状、地图和仪表盘它还有个好处是数据更新后动画渐变交互更友好。不过注意图表漂亮不等于数据靠谱。坐标轴不从 0 开始的折线图会人为放大波动面积图用的比例不对也会误导人。做可视化之前先把数据口径和上下文写清楚否则就是画了一张漂亮的假图。5.3 “数据大”不等于“大数据”从Excel到分布式很多初学者对“大数据”有误解以为数据多就是大数据。其实 Excel 单表上限 104 万行处理超过这个规模就力不从心了但只多了几十万行根本不算大数据。真正的大数据指的是数据规模大到一台机器装不下、处理不动需要分布式存储和分布式计算。这时候才需要 HDFS、Spark 这些东西。但分布式不是银弹。无论多大规模的数据底层仍然是那几件事数据如何表示、如何存储、如何索引、如何聚合。你在 Excel 里能搞明白 SUMIF在 SQL 里能搞明白 GROUP BY再去理解 MapReduce 的 Shuffle就会容易得多。所以我的建议是不要一上来就追大数据框架先把单机数据处理练到滚瓜烂熟计算机组成原理和数据结构这两门基础课补一补后面学什么都快。6. 数据的命根子安全、备份与恢复6.1 备份策略三二一原则数据最怕的不是丢而是“丢的时候才发现没备份”。我现在个人习惯是重要资料至少三份放在两种不同介质上其中一份放在异地。这个叫“3-2-1”备份原则。三份副本原始数据加两份备份两种介质比如一块移动硬盘加一个云盘一份异地防止火灾、水灾把家里机器端了。备份不能靠人肉定时拷贝要脚本化。Windows 上可以用计划任务配合 robocopymacOS 里可以用 Time Machine 加云同步Linux 上写 cron 配合 rsync。数据库要开 binlog 和定期物理备份。千万别把同步软件当成备份Dropbox 同步一个文件被误删所有端都会同时删掉。同步是镜像备份是带时间戳的历史二者要分开理解。这句话值得单独加粗。6.2 误删数据怎么办从回收站到binlog误删数据怎么办第一反应先停止写入防止覆盖。系统文件在回收站里可以恢复云盘一般有一段时间的版本历史数据库表被误删如果你有文件系统快照或备份能从快照恢复。生产数据库则要看 binlog 或者 WAL把删除之前的操作回放出来。我早年在一家公司遇到过一档子事同事在测试环境里执行 DELETE 忘加 WHERE把表删空了。幸好这个环境搭建时配置了每日备份也只丢了一天的业务数据。如果连备份都没开那就是事故。从那以后我对生产环境的安全性有了阴影凡是关键操作前必备份批量 UPDATE/DELETE 必包事务且带上 WHERE 条件数量核对。别看这些动作琐碎关键时候能救命。另外很多浏览器在下载文件时会提示“你尝试预览的文件可能对你的计算机有害。如果你信任此文件以及其来源请打开”。这种提示里的“来源”两个字很重要。来源不可信的文件即使再诱人也别运行因为它可能是一段恶意代码不是数据而是破坏数据的。数据安全不只是数据本身还有数据生态的边界。6.3 系统崩溃与数据完整性数据安全不只有备份还包括完整性。突然蓝屏、断电、程序进程被杀都可能让正在写入的数据只有一部分落盘文件损坏。数据库为了保证不出现半笔交易引入了事务和日志先写日志再改数据。如果崩溃启动时用日志回放恢复。SQLite 这类嵌入式数据库常用 WAL 模式把未提交的数据写在单独的日志里崩溃恢复更可靠。电脑意外蓝屏后重启正常了不要侥幸。你应该检查一下正在编辑的文档和数据库有没有损坏最好触发一次文件系统检查。机械硬盘如果有坏道开机可能会出现卡顿和怪声这时候第一件事是把重要数据拷出来再分析磁盘健康。数据完整性远比一台电脑值钱这个优先级永远不要搞反。7. 一些从小白到进阶的建议个人经验7.1 我踩过的三个数据坑说到经验我把自己这些年的三个经典教训写在这里希望你们不要重蹈覆辙。第一个字符编码乱码。刚工作那年我搭了一个网站后台从外部系统拿 CSV 中文直接按 UTF-8 读结果全是问号后来才发现对方是用 GB18030 编码的。我花了一个下午才知道原来文本文件内容一样编码不同读到内存里完全是两码事。第二个金额用浮点数。一次内部资金核算程序我用 double 做金额累加跑了几万笔后有 0.01 的差异。因为浮点数不是十进制精确表示的累加越多误差越明显。之后我所有金钱相关字段统一改成 DECIMAL程序也避免了这种问题。第三个没有备份就删除。有一回清理服务器磁盘把 /data 下一个看似没用的目录删了结果里面是运维的日志采集脚本第二天线上数据断流。从那以后我养成了两个习惯删除前先改名或者备份批量删除前先看磁盘空间和文件内容。数据无小事谨慎永远是对的。7.2 想学好数据基础可以按这个路线练最后给想系统学习的朋友一个路线。第一用 Excel 练数据透视表、常用函数和图表第二学 SQL把过滤、分组、连接、子查询弄熟第三用 Python 读写文件、清洗数据、画简单图表第四回炉经典基础课比如《计算机组成原理》中存储和编码部分、数据结构里的数组链表树。学的时候一定要动手做小项目比如写一个程序读取一个 CSV统计各分类销售额并生成柱状图。这个过程涵盖了采集、解析、清洗、聚合、可视化比死记硬背管用得多。等这套链路走通了你再看任何高并发、大数据、分布式架构都只是把这套单机基本功放大到多台机器上而已。数据基础不难但它决定了一栋楼能盖多高。今天就先聊到这里踩过数据坑的朋友欢迎回来分享你的经历。