架构设计师（数据架构）

一 什么是数据架构

关于架构，大家都有了解和理解。通常一个业务或项目，在做架构设计时，可能会包含业务架构和技术架构。其中技术架构是我们作为开发角色，在做设计时重点的工作内容。但还有架构类型的划分方式，会包括业务架构、技术架构、数据架构和应用架构四种。

数据架构管理的内容包括管理对象、管理流程、管理组织，管理对象又包括数据标准、数据模型、数据库、数据质量。总之，数据架构就是由一定的管理组织，通过一系列管理流程，来实现对数据对象的管理。数据架构构成如下图所示：

二 为什么需要数据架构

“经验来源于实践”。经历过一个或多个中大型项目/产品生命周期的朋友，大多会有这样的经验。在项目早期时，为了快速验证，会以尽快上线运行为最主要的目标，架构设计会有数据结构部分，但不会过多设计。在项目快速发展之后，频繁的表结构变更、数据类型变化会带来一系列的问题，尤其是当可能发生拆库、分表等动作之后，带来几个典型的数据问题：

2.1 数据标准不一致

• 列名相同，数据类型不同；
• 列名相同，数据类型相同，长度不同；
• 列名定义没有统一标准，识别困难；
• 列名定义不统一，类型不统一，长度不同；

2.2 数据模型混乱

• 表、字段缺乏注释；
• 表无主键、允许为NULL列；
• 表关系不清晰；
• 不合理的冗余设计；

2.3 性能问题

• 对表结构、索引理解、使用不当；
• SQL的编写与开发者的技术水平有关，当sql编写不当且缺乏审核导致带入线上，就会导致性能问题

2.4 数据缺乏安全管理

表结构规范；

索引合理性设计、创建检查；

SQL质量；

数据安全管理（插入、删除、更新，以及批量查询动作）

三 数据架构生命周期

数据架构的重点是数据的标准化处理，这会贯穿于系统/项目的整个生命周期。包括数据架构设计阶段、开发阶段、迁移阶段、测试阶段等等。

四 数据冷热分离

4.1 大数据存储方案

关于大数据量的存储方案，常用的有分库分表方案，可以选用多种分库分表技术和中间件来实现。但有一个问题，当单表数据量到达多少的时候执行分库分表？

4.2 单表上限2000w的起源

一直有这样一种说法，MySQL 单表数据量大于 2000 万行，性能会明显下降。冷热分离之 OTS 表格存储实战这篇文章中给出了来源：这个传闻据说最早起源于百度。“具体情况大概是这样的，当年的 DBA 测试 MySQL性能时发现，当单表的量在 2000 万行量级的时候，SQL 操作的性能急剧下降，因此，结论由此而来。然后又据说百度的工程师流动到业界的其它公司，随之也带去了这个信息，所以，就在业界流传开这么一个说法。再后来，阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过2GB，才推荐进行分库分表。对此，有阿里的黄金铁律支撑，所以，很多人设计大数据存储时，多会以此为标准，进行分表操作。”

背后的原理，大家也可以仔细阅读这篇文章，简单来说，这个说法源于Mysql的InnoDB引擎的存储结构和索引结构。记录数过多时导致B+树高度过高从而需要多次IO，导致性能明显下降。

4.3 冷热分离

4.3.1 数据的冷热划分

首先，绝大部分场景，数据都可以分为“冷数据”和“热数据”。数据划分的原则，可以根据时间远近、热点/非热点用户等等。例如在以往项目中的实例，用户通常只访问一段时间之内的数据，例如近一周或一个月。如果数据不做划分，必然会导致一定程度上的性能、成本损耗。

4.3.2 冷热分离好处

通过合理的冷热分离设计，可以达到的好处：

• 降低单表数据量，提升单表性能；
• 大量业务冷数据转冷存，存储成本可以降低很多，至少50％＋。

五 冷热分离方案

需要考虑的包括存储方案、数据迁移方案，另外需要做历史查询时也需要支持聚合查询和自动的冷热查询路由。

5.1 存储方案

存储方案，包括本地方案和云方案。本地的存储介质，通常是硬盘，但通常机械硬盘会受限于磁盘空间和IO瓶颈，这也是单表限制的主要原因。所以一般处于性能提升的考虑，会使用固态硬盘（SSD）。但SSD成本较高（远高于机械硬盘），所以不适合海量数据存储，这时候就需要考虑磁盘阵列等等。另外，磁带也是一种方案，但仅适合历史数据的持久化保存，和必要时做数据恢复，本身并不适合查询。

如果能够接受云方案，那么可选的就有云硬盘作为DB的存储介质、或者是云服务上提供的冷热存储（blob、表格存储）。阿里云的OTS就是一种表格存储实现，其技术架构如下图所示：

5.2 迁移方案

数据有冷热划分，那么就会有界限、生命周期。新的数据写入时，其属性是“热”的；当到达某个时间节点或预设阈值时，就需要把数据迁移到“冷”数据存储。这里又涉及到几个问题：

• 冷热数据标记
• 迁移方法。时效性保障
• 数据一致性

另外，为了保证冷热数据迁移过程中业务系统的稳定性，在数据迁移的过程中还一定要做到：可灰度［降低影响，提前发现］，可一键回滚［快速止血］。

六 冷热分离核心问题与案例

6.1 关键问题

无论我们怎样选择冷热存储方案，首先，都还是需要一种存储介质。哪怕是云上的存储方案。冷热分离的具体实现，也会与存储介质的选择直接相关。举个栗子，数据从热存储到冷存储的迁移，最简单地来看，需要实现 2 个步骤：1、数据写入冷存储；2、热存储数据删除；而删除动作就与数据库的选择有很大关系。

6.1.1 大数据删除

大量的数据插入和数据删除，尤其是在有索引的大表上，这样的操作会很大程度地影响数据库读写性能；而且删除后，未必会立即释放旧数据所占的空间，在某些 db 下，甚至可能需要做一次数据整理才能真正释放。这会导致一个很严重的问题，如果不做整理操作，那么相当于这些旧数据物理上还占据着空间，最终必然也会导致磁盘空间不足。

6.1.2 查询包含热数据也有冷数据

这点可以理解为中间层路由的实现。什么时候查询热数据，什么时候查询冷数据，需要有一个规则层来控制。理想的情况，冷热数据都是分别查询，而且冷数据查询的频率（在整体查询中的比例）低一个或多个数量级，这样的分离说明是比较合理的。

6.2 几个案例

接下来，我们通过可以搜索到的几个文章中的案例，来了解不同存储方案下的冷热分离实现，并试图分析其中合理和不合理的地方。

6.2.1 mysql

6.2.1.1 案例概述

[数据库]-----记一次mysql分库的操作（冷热分离）_zhangSir134的博客-CSDN博客

案例中是采用数据分库的方式实现。也就是说，建立了生产库 和 历史库两个数据库，生产库存放热数据，历史库放冷数据。文中描述的架构如下图所示：

6.2.1.2 数据迁移

通常，迁移我们会采用定时任务的方式实现。也就是说，对于冷热数据的分割，会倾向于使用“天”的粒度。当然，根据实际的业务需求也可以进一步细分。

为了不影响常规业务，就需要在业务低谷时期执行这些非核心业务动作，所以会在每天凌晨执行迁移动作，在新的业务请求高峰到来之前完成迁移，降低影响。在任务的具体实现上，还需要特别注意，某些任务可能会依赖数据迁移的完成，这样就意味着存在任务之间的依赖关系，以及失败重试等等。并且为了确保数据的完整性和一致性，最好对迁移数据进行一致性校验，避免数据丢失和错误数据的产生。

6.2.1.3 多数据源的查询

这里的多数据源，就是指既有热数据，也有冷数据的查询。当然前面我们有过描述，理想情况下不应该有这样的情况存在，但在真实业务中很可能是不可避免的。这就要求：1）系统提供跨热、冷数据库的查询支持；2）冷数据查询性能明显低于热数据库的情况下，尽可能减小查询耗时。如果可能，最好能实现降低长尾耗时查询的比例。为了达到这个效果，就需要结合缓存策略或在功能上限制查询模式和查询范围，并在具体业务中做好引导和取舍。

6.2.2 Elasticsearch

Elasticsearch鍐风儹鍒嗙鍘熺悊鍜屽疄璺� - Elastic 涓枃绀惧尯 (连接有乱码，文章标题为：Elasticsearch冷热分离原理和实践)

6.2.2.1 节点异构

与 mysql 的冷热部署类似，这里的 es 也采用双集群模式，但强调出了节点异构。（其实这是必要环节和前提，简单来说，热库侧重实时业务读写能力，要求保障性能，空间足以存储热数据即可；而冷库则需要保障数据存储量级和一致，能够接受牺牲一定程度的读写性能，因为要存储大量历史数据，所以相比热裤，空间需要大很多。）

“部分是高性能的节点用于存储热点数据，部分是性能相对差些的大容量节点用于存储冷数据，却可以一方面保证热数据的性能，另一方面保证冷数据的存储，降低存储成本，这也是 Elasticsearch 冷热分离架构的基本思想”。

6.2.2.2 节点指定冷热属性

在 elasticsearch.yml 文件中增加配置的方式，为节点打上标签。

node.attr.{attribute}: {value}

其中 attribute 为用户自定义的任意标签名，value 为该节点对应的该标签的值，例如对于冷热分离，可以使用如下设置

node.attr.temperature: hot //热节点 node.attr.temperature: warm //冷节点

6.2.2.3 冷热索引设置

冷热数据做了分离，前面也提到二者适用于不同场景，那么在数据的索引上，也可以针对使用场景进行曲分设计，不必保持一致。

注意冷热数据与数据库主从的区别，冷热数据库会要求表/集合的结构一致，但索引可以有所区别。

6.2.2.4 索引生命周期

Elasticsearch 从 6.6 版本开始提供索引生命周期管理功能，索引生命周期管理可以通过 API 或者 kibana 界面配置。这一特性使得我们可以使用索引生命周期管理结合冷热分离架构实现索引数据的动态管理。

这里引述Elasticsearch冷热分离原理和实践中的描述：

索引的生命周期被分为：Hot phrase,Warm phase, Cold phase,Delete phrase四个阶段

• Hot phrase: 该阶段可以根据索引的文档数，大小，时长决定是否调用 rollover API 来滚动索引，详情可以参考[indices-rollover-index],因与本文关系不大不再详细赘述。
• Warm phrase: 当一个索引在 Hot phrase 被 roll over 后便会进入 Warm phrase，进入该阶段的索引会被设置为 read-only, 用户可以为这个索引设置要使用的 attribute， 如对于冷热分离策略，这里可以选择 temperature: warm 属性。另外还可以对索引进行 forceMerge, shrink 等操作，这两个操作具体可以参考官方文档。

• Cold phrase: 可以设置当索引 rollover 一段时间后进入 cold 阶段，这个阶段也可以设置一个属性。从冷热分离架构可以看出冷热属性是具备扩展性的，不仅可以指定 hot, warm, 也可以扩展增加 hot, warm, cold, freeze 等多个冷热属性。如果想使用三层的冷热分离的话这里可以指定为 temperature: cold, 此处还支持对索引的 freeze 操作，详情参考官方文档。
• Delete phrase: 可以设置索引 rollover 一段时间后进入 delete 阶段，进入该阶段的索引会自动被删除。

总结

本篇介绍了数据架构的概念、意义，以及数据的冷热分离，并阐述了冷热分离方案和注意事项；分析了几个冷热分离的实现案例，并整理了一些问题和解决方案。通过 mysql 和 Es 的两种冷热分离实现，阐述了不同存储方案上冷热分离实现上的共同点和差别。

回归本源，设计最终还是依赖于具体业务需求。后续还需要在实践中，通过足够的业务场景和数据量级支撑，来继续验证方案的可行性和潜在问题，不断进行完善升级。

参考文章

数据架构-什么是数据架构_冰山一角_新浪博客