在大数据领域摸爬滚打这些年我越来越意识到一件事——数据架构的根基几乎全压在分布式存储这一层上。不管是几十个节点的分析集群还是几个TB起步的业务数仓分布式存储的选型和设计直接决定了这套系统能跑多稳、能撑多大。很多人一上来就谈计算引擎、谈SQL优化但底层存储设计不合理上面再怎么调优都是事倍功半。这篇内容我不打算讲那些纯理论的东西而是从实际设计角度把分布式存储在大数据数据架构里到底该怎么落地、有哪些坑、怎么做容量预估、选型时看哪些指标一次性讲透。不管你是刚接手大数据平台的数据工程师还是正在做技术选型的架构师这篇都值得花十分钟看完。1. 项目整体设计与思路拆解1.1 分布式存储解决的核心矛盾——为什么单机存不下了先讲一个最基础的问题为什么大数据场景必须要上分布式存储我在给不少团队做方案评审时经常被问到我们数据量也就几个T一台高性能服务器加个RAID阵列不就行了为什么要上HDFS或者MinIO这个问题其实问到了根子上。单机存储的瓶颈不只是容量不够这一个维度而是三个维度同时受限。第一个维度是容量。虽然单块硬盘已经能做到20TB以上一台48盘位的服务器满配可以到近1PB的裸容量听起来很大但那是把机器塞满的情况。实际部署中要考虑系统盘、日志盘、温备空间而且单台机器的故障爆炸半径太大——一台机器挂了如果它是唯一副本整个数据就全没了。第二个维度是带宽。单台服务器的网络带宽一般就是25GbE或者100GbE磁盘顺序读也许是够的但多业务并发读写时单机的IOPS和吞吐很容易被打满。第三个维度是扩展性。业务增长是不可预测的今天几个T明天可能就几十个T单机方案扩到顶之后只能换机器迁移成本极高。分布式存储就是为了解决这三个维度的问题而出现的。它的核心思想说起来就一句话——把数据切成很多份分散到多台机器上每台机器只承担一部分读写压力同时通过多副本机制保证单台机器故障时不丢数据。这个思想在GFS论文发表之后就奠定了大数据存储的基本范式后来的HDFS几乎是照着GFS的架构实现的而对象存储领域的MinIO、Ceph又在块和文件之外提供了另一种抽象。1.2 设计开始前必须先想清楚的三件事很多人拿到需求就直接开始搭集群、配参数这是最大的坑。我自己的经验是动手写任何配置文件之前必须先回答三个问题这三个问题的答案会直接影响存储方案的选择。第一个问题是数据的主要访问模式是什么是写入一次、多次读取典型的分析型场景还是频繁更新事务型场景是大文件顺序读为主还是大量小文件随机访问这两个问题的答案基本能确定你是选HDFS还是选对象存储。HDFS对一次写入、多次读取、大文件、流式访问的场景优化到了极致但如果你要频繁修改文件内容、要随机读写HDFS会非常痛苦。对象存储在这方面的灵活性好一些但又有一致性和延迟的问题。第二个问题是数据的重要程度有多高这决定了副本数怎么设。副本数为3是行业默认值但它不是拍脑袋定的而是同时坏两台机器不丢数据这个可靠性目标的数学结果。如果数据是能从源系统重新拉取的中间结果副本可以降到2甚至1如果是不可再生的核心业务数据你可能要考虑跨机房容灾也就是机架感知和副本摆放策略。第三个问题是未来三年的数据增量大概是多大这个问题不是为了得到一个精确数字而是为了避免集群半年就满了的窘境。我见过太多团队容量规划只看当前存量结果一年后存储使用率超过85%触发告警之后只能紧急扩节点或者做数据清理非常被动。把这三个问题想清楚再去看具体的存储组件思路就会清晰很多。下面我详细拆解分布式存储设计中的几个关键环节。2. 核心细节解析与实操要点2.1 数据分片策略——怎么把数据从一整块变成成千上万块分布式存储的第一步是分片sharding。不管底层的存储引擎是HDFS、MinIO、Ceph还是其他系统分片的思想是共通的把一份大数据切分成若干个小数据块分散存储到集群的不同节点上这样读写的时候可以并行进行多台机器的磁盘和网络带宽才能同时被利用起来。HDFS的分片单位是Block默认大小在旧版本是64MB后来改成了128MB。为什么默认是128MB而不是1MB或者1GB这个数字的设计逻辑是块太小的话一个文件会被切成太多块元数据量跟着变大NameNode内存压力飙升而且每个块都要对应一次网络通信和磁盘寻址效率反而低块太大的话并行度又不够MapReduce或Spark的task数量会受限一个块只能被一个task处理集群的算力不能被充分用起来。128MB是经过大量实践验证后在元数据开销和并行度之间取得的平衡点。MinIO这类对象存储的分片逻辑有所不同。MinIO把对象按照5MB到5TiB的区间做分片每个分片默认是5MiB或者10MiB等大小取决于配置分片之后通过erasure set纠删码集合的方式分布到不同的磁盘和节点上。这里的核心概念是纠删码erasure coding它和HDFS的多副本机制不太一样更像是一种数学上的冗余策略。用生活类比来解释纠删码的话可以想象成你把一份文件平均切成四份再通过某种算法生成两份校验数据一共六份分散存到六台机器上。只要六份中任意四份还在就能把原始文件完整还原出来。这样算下来存储开销是六分之四也就是1.5倍比三副本的3倍开销低很多但可靠性和三副本差不多。这就是为什么MinIO在存储成本上比HDFS有优势的原因之一。分片策略上还有一个容易忽略的点分片太大或太小都各有问题。分片太小单次请求的数据量有限网络RTT的影响会被放大分片太大单块数据恢复或重建时的耗时就会很长故障窗口期变大。所以做设计时要结合数据的平均大小、访问并发度、网络带宽这三个维度去权衡。2.2 多副本与数据一致性——数据不丢的秘密分片解决了存得下的问题但还留了一个问题某台机器上的磁盘坏了怎么办这个问题靠冗余机制来解决主流方案就两种多副本Replication和纠删码Erasure Coding。多副本方案的代表是HDFS。HDFS默认的副本因子是3也就是说每个Block会有三份拷贝分布在不同的DataNode上。这里有一个细节值得注意三份副本不是随便放的而是要遵循机架感知rack awareness策略。默认的放置策略是第一个副本放在客户端所在节点如果客户端不在集群内则随机挑一个节点第二个副本放在与第一个副本不同机架的某个节点第三个副本放在与第二个副本同一机架但不同节点的位置。这样设计的结果是一个机架整个宕掉数据仍然完整两台机器同时宕掉大概率也不会丢数据。这个策略的巧妙之处在于用最小的网络开销换来了最高的容错性。副本写流程也不像很多人想的那么简单。客户端写一个Block时并不是同时向三个副本节点发送数据而是采用流水线pipeline方式客户端先把数据发给第一个DataNode第一个DataNode收到一份同时把这份数据转发给第二个DataNode第二个再转发给第三个。这样一来数据在节点间的传输路径清晰而且每个节点只要负责一份写入和一份转发压力分散速度反而比并行写更快。如果不做机架感知三份副本可能落在同一个机架上机架交换机一挂整个数据就全部不可用了。MinIO走的是另一条路——纠删码。关于纠删码的原理前面用生活类比简单介绍过了这里补充一个计算层面的细节。MinIO的纠删码配置通常是NM模式N是数据分片数M是校验分片数。比如最常见的84配置意味着一个对象被切成8个数据分片额外生成4个校验分片总共12个分片分布在12块磁盘上。只要任意8块磁盘上的分片还在数据就能恢复。这种方案的理论存储开销是12/8 1.5倍远低于三副本的3倍但在恢复数据时需要做大量的数学运算CPU开销比单纯拷贝副本要大。数据一致性也是一个绕不开的话题。HDFS提供的是强一致性——写入成功后所有副本都已经是新数据任何客户端读到的都是最新版本。这一点对数据分析来说相对友好因为你不用担心读到脏数据。对象存储的一致性模型就比较多样了。MinIO在单站点部署下可以提供强一致性但如果是多站点双活部署或者使用了S3兼容网关缓存可能就会变成最终一致性。这块在架构设计时一定要提前确认清楚否则可能出现写入成功后立刻读取却读到旧数据的诡异问题。2.3 元数据服务——整个分布式系统的大脑分布式存储除了数据本身还有一个非常关键的组件元数据服务。所谓元数据就是数据的数据——文件叫什么名字、在哪个路径下、分成多少个块、每个块分别存储在哪个节点上、权限是什么、创建时间是什么时候。没有元数据服务数据就算都存好了也找不回来。HDFS的元数据服务是NameNodeNameNode在内存里维护了整个文件系统的目录树和Block与DataNode的映射关系。这个设计的优点和缺点都非常明显。优点是所有元数据集中在一处实现简单、一致性天然保证缺点是NameNode成了系统的单点瓶颈——虽然可以用Active/Standby模式做高可用但内存大小直接限制了整个集群能管理的文件数。这就是小文件问题的根源之一一个Block的元数据在NameNode内存里大约占150字节看似不多但如果你的集群有1亿个小文件仅元数据就要占掉大约15GB内存而且NameNode还要做其他事情内存压力会非常大。MinIO没有传统意义上的集中式元数据服务它的元数据是跟数据一起分布在各节点上的通过底层的etcd或者内嵌的kv存储来管理bucket和对象的元数据信息。这种去中心化的设计让MinIO没有了单一命名空间的瓶颈扩展性比HDFS的传统NameNode架构好但在事务性元数据操作上比如跨多个对象的原子操作能力会弱一些。这也是为什么MinIO很少作为主数据库的存储层而更多被用作数据湖的底座。在设计数据架构时元数据服务的选择往往会成为系统的隐性瓶颈。我的建议是如果文件数量预计会超过几亿优先考虑对象存储而非HDFS如果要用HDFS就要从设计层面控制文件总数能合并的小文件尽量合并。这个线在系统设计阶段就要设好否则到了运行期再改存储方案迁移成本高到你想哭。3. 方案选型与实操落地3.1 HDFS、MinIO、云对象存储——到底怎么选做数据架构设计时最常被问到的一个问题就是HDFS和MinIO我应该用哪个这两个确实是目前自建大数据平台时最常见的两个选择但它们的定位其实完全不同。HDFS定位是分布式文件系统提供的是POSIX风格的文件路径访问hdfs://namenode:8020/data/xxx它对Hadoop生态的支持是最天然的。Hive、Spark、Flink、HBase这些组件原生对接HDFS几乎不需要任何额外适配。如果你走的是一套完整的Hadoop大数据技术栈——离线数仓用Hive、计算用Spark、实时用Flink——那HDFS是你最顺理成章的选择学习成本低、踩坑资料多、团队招人也容易。MinIO定位是对象存储提供的是S3兼容接口s3://bucket/object它对Hadoop生态的适配是通过S3A文件系统实现的也就是在Hadoop的AbstractFileSystem层面加了一层S3协议的支持。用Spark或者Flink读写MinIO在功能上没有问题但性能会比原生HDFS略低尤其是在大量小文件读写的场景下S3A的list操作可能成为瓶颈。从成本角度算一笔账HDFS三副本模式存储开销是数据的3倍MinIO如果配置为84纠删码存储开销是1.5倍。如果数据量是1PBHDFS需要3PB的裸容量MinIO只需要1.5PB。按每TB综合成本2000元算包含服务器、机柜、电费摊销这个差距就是300万元人民币。但这还只是存储成本计算过程中MinIO恢复数据时CPU占用更高会影响同一节点上其他负载的性能这部分隐形成本是很难精确量化的。我的实操经验是这么划分的如果你要做的是离线数仓或者数据湖而且计算引擎以Spark/Flink为主我建议HDFS作为主存储因为生态成熟、写入吞吐高、和计算引擎的亲和力最好。如果你要做的是数据归档、备份、非结构化数据存储图片、日志文件、音视频或者你的业务需要频繁通过S3 API对外提供数据访问那我建议上MinIO。还有一种混合架构计算密集型数据放HDFS归档类和接口服务类数据放MinIO中间用定时任务做数据生命周期管理这也是一种非常务实的方案。到底选哪种关键还是回到我前面说的三个问题——访问模式、数据重要性、未来增量没有绝对的对错只有是否匹配业务场景。3.2 容量规划实操计算——从数据量推导出集群规模容量规划是分布式存储设计里最容易被忽视、又是最容易出问题的环节。我见过不少团队上线时节点数是够的跑了大半年之后存储使用率冲到90%应用写入直接阻塞。这其实不是运维问题是容量规划阶段就没算正确。我分享一下自己做容量规划的方法这个方法适用于HDFS和MinIO两种方案。核心公式是需要的裸存储容量 每日新增数据量 × 保留天数 × 冗余系数 × 扩展余量系数展开来说假设你的业务每天产生2TB的增量数据需要保留180天约6个月那么基础容量是2TB × 180 360TB。HDFS三副本的冗余系数是3所以裸容量需要360TB × 3 1080TB。考虑到要预留一定的扩展空间一般建议再加20%-30%的余量也就是总裸容量约为1300TB左右。如果单台DataNode配置了8块16TB的盘裸容量是128TB去掉系统盘和数据盘RAID损耗大约就是120TB那你就需要1300 / 120 ≈ 11台DataNode。MinIO的算法类似只是冗余系数不同。同样的数据量MinIO如果采用84纠删码冗余系数是1.5那么360TB的数据需要360 × 1.5 540TB裸容量加20%余量是648TB。如果每台机器也是8块16TB盘约120TB裸容量那需要约6台服务器。单看硬件采购成本MinIO方案确实省了快一半。这里有一个我踩过的坑想特别提醒一下千万别用当前数据量 预估增长来做容量规划必须用每日新增 × 保留周期来算因为大数据平台的特性是数据基本只增不减数据保留周期是由业务合规要求决定的这个周期可能比你预想的要长得多。还有一点HDFS使用率超过85%之后各DataNode之间的数据均衡会变得非常慢因为节点在存储不足的情况下会拒绝接收新的Block迁移。我建议把80%作为必须扩容的硬性阀值不是85%更不是90%。3.3 关键配置与部署实操——HDFS和MinIO的核心参数容量算完之后就到了实际的部署配置环节。HDFS和MinIO的部署配置各有各的关键参数我挑几个最重要的讲。先讲HDFS。部署HDFS时最核心的配置文件是hdfs-site.xml和core-site.xml。以下几个参数我每次都会过一遍dfs.replication副本数。默认是3我建议根据数据重要程度按目录设置全局设为3给临时数据目录单独设为2。dfs.blocksize块大小。默认128MB如果集群主要用于跑大规模数据扫描比如全表聚合可以调大到256MB减少元数据量、提高顺序读效率如果业务中有大量中等大小文件的随机读取保持128MB更合适。dfs.namenode.handler.countNameNode的RPC处理线程数。默认是10但节点数多、并发高的时候肯定不够一般按集群节点数× 0.5-1来设置。比如20个节点设成20左右比较合理。dfs.datanode.data.dir数据盘目录。这个参数要格外注意一定要把每块独立的物理盘配置为独立的目录不要做RAID后再给到HDFS否则无法充分利用多磁盘的并行IO能力也会让磁盘故障的爆炸半径变大。再讲MinIO。MinIO的部署相对简单因为它是一个单个二进制文件下载下来就能跑但生产环境部署时有几个配置项必须注意MINIO_ERASURE_SET_DRIVE_COUNT纠删码集合的盘数。这个值决定了纠删码如何分组实际生产环境我建议每个erasure set配置8或12块盘既能保证可靠性又能平衡性能。MINIO_STORAGE_CLASS_STANDARD设置标准存储类的纠删码参数比如EC:8表示8个数据分片配合默认的校验分片数可以精确控制存储冗余度。部署形态生产环境强烈建议用多节点多磁盘模式至少4节点起步。MinIO可以跑在Docker或Kubernetes里但在K8s里部署时要特别注意每个MinIO Pod必须绑定独立的持久卷声明PVC不要把多个MinIO Pod挂到同一个共享存储上——那等于在存储之上再做一层存储冗余策略会被完全破坏。这里还想提醒一点不管是HDFS还是MinIO部署完成之后都建议做一次写入和读取的性能基准测试用自己业务场景的数据量级测不要只看官方给的benchmark数字。官方测试用的是大文件顺序读写而你的业务如果以中等文件随机读为主实测性能可能会差出好几倍。测试的时候可以简单用Spark的TPC-DS测试集或者直接写个脚本并发读写一批文件观察吞吐量和延迟做到心里有数。4. 常见问题与排查技巧实录4.1 小文件问题——分布式存储的隐形杀手如果要我选一个分布式存储最常遇到的性能杀手小文件问题绝对排第一。HDFS上一个小于Block大小的文件占用的磁盘空间是它实际大小但占用的元数据资源和实际大小无关——每个文件不管多小在NameNode里都会占一个目录项和若干条Block记录。当小文件数量多到一定量级NameNode内存就会成为瓶颈整个集群的读写性能都会跟着急剧下降。我自己遇到过的典型案例是某业务把Kafka里的消息按小时落盘成JSON文件每小时产生约50000个几十KB的小文件一天就是120万个文件。跑了不到两个月NameNode堆内存使用率到了85%GC频繁HDFS的写入吞吐直接腰斩连带所有依赖HDFS的Hive任务一起变慢。针对小文件问题可以从三个层面去治理。第一个是源头控制在写入数据时尽量使用大文件写模式比如Flink的BucketingSink可以按时间滚动把频繁到达的消息聚合成较大的文件再写出。第二个是合并策略对已经存在的小文件可以定期用Spark跑一个合并任务按目录把几千个小文件读出来重写为若干个128MB左右的大文件合并完成后删除原文件。第三个是查询侧优化如果文件暂时合并不了至少要把Hive或Spark的分区数控制在合理范围内避免每个分区下产生太多零散文件。MinIO在小文件问题上相对友好一些因为它的对象元数据不是集中在单一节点内存里的但也不是完全没有代价——每个对象都会对应一次独立请求大量小对象会让请求数飙升API网关和磁盘的IOPS都会被耗掉。所以MinIO场景下更推荐使用批量写入比如批量归档日志时把多条记录合并成一个对象。4.2 数据倾斜与热点——节点之间的贫富差距分布式存储的另一个常见问题是数据倾斜。正常情况下数据应该均匀地分散到所有节点上但实际操作中往往会出现某些节点磁盘使用率远超其他节点的情况。数据倾斜的出现有几个典型原因。第一个是分片键设计不合理。HDFS的Block是按照文件追加模式切分的如果一个超大文件只被写入一个路径下且写入时没有采用合适的写入策略导致大量Block落在同一批节点上这些节点的存储使用率就会异常。MinIO的纠删码分组也有类似问题如果某一组磁盘的写入频率远高于其他组就会形成热点。第二个是哈希取模的雪崩效应这个更多出现在自研的上层存储方案里分片键选择不均匀自然会导致某些分片的数据量是其他分片的好几倍。排查数据倾斜最直接的手段是看监控。HDFS的NameNode Web UI上有一个DataNodes页面可以直观看到每个节点的存储使用率和Block数量MinIO的Console界面也有类似的节点容量展示。如果发现某台节点的使用率明显高于平均值15个百分点以上就说明存在数据热点。处理数据倾斜的手段主要有三种如果倾斜是因为某个目录的写入量特别大可以把这个目录的Block放置策略改为随机放置或者在客户端层面做写入分流如果是文件级别的倾斜可以把大文件重新分区再写一遍如果是节点本身有硬件差异比如某个节点的磁盘容量比其他节点小那属于容量规划问题只能通过扩容或者把该节点的数据迁移到其他节点来解决。HDFS自带的Balancer工具可以调整节点间的数据分布我建议在业务低峰期跑因为Balancer会消耗网络和磁盘IO可能影响在线业务。4.3 节点故障与数据恢复——真正的考验在故障之后分布式存储设计得再好节点故障也是不可避免的。我的经验是衡量一套存储系统是否可靠的标准不在于它会不会出故障而在于它出故障之后能否快速恢复以及在恢复期间是否影响正常业务。HDFS的节点故障处理相对成熟。DataNode宕机后NameNode会通过心跳超时机制感知到节点的下线然后自动把该节点上存储的Block标记为under-replicated副本数不足系统会在后台启动复制任务把这些Block的其他副本复制到其他健康的节点上。这个恢复过程的耗时取决于需要复制的数据量如果数据量大可能要跑好几个小时期间集群的写入性能会略有下降。实操中有个经验为了避免故障节点上的大量Block同时触发复制风暴可以调整dfs.namenode.replication.max-streams参数控制并发复制流量上限。MinIO的数据恢复机制则是通过纠删码自动重建。当某块磁盘或某个节点失效MinIO会实时使用现有的数据分片和校验分片重建丢失的分片这个过程是自动的对客户端透明。但要注意的是纠删码重建比简单复制副本开销大得多CPU会明显升高。所以生产环境部署MinIO时建议不要让存储节点同时承载密集计算任务否则重建期间CPU抢占可能会影响正常的数据读写业务。还有一类故障是静默数据损坏——磁盘本身没有完全坏掉但某些扇区读出来的数据已经错了。HDFS的BlockScanner和MinIO的bitrot保护机制默认开启都能检测到这类问题。检测到损坏的数据块之后系统会从其他正常副本或分片重建该块。这也是我要强调的不要以为磁盘没报错数据就是安全的定期做数据完整性校验极其重要。4.4 一致性问题的柔性与刚性——业务侧如何应对一致性是分布式存储设计里的一个灰色地带尤其是选了对象存储之后最终一致性模型会带来一些业务侧不容易发现的bug。举一个实际例子某个团队用MinIO做数据湖Flink任务从Kafka消费数据写入MinIO的delta目录下游Spark任务周期性扫描delta目录发现有新数据就做增量处理。上线后发现一个非常诡异的现象Spark任务偶尔读到的数据不完整有些文件能读到有些文件报了NoSuchKey错误。排查了很久才发现问题的根源在于Flink写完一个对象后就立刻更新了上游的offset而MinIO在极端场景下特别是对象刚写完还在做内部元数据同步时对下游的list和get请求可能还没有完全可见。这不是MinIO的bug而是最终一致性的固有特性。怎么应对我有几个建议。第一在Flink或者Spark的sink端增加一个写完即确认的机制——写入成功之后立即用一个轻量级请求比如HeadObject去验证这个对象是否可读确认后再提交offset。第二在下游读取侧尽量使用时间窗口而不是严格依赖文件出现的顺序给上游留出足够的数据同步时间窗口。第三如果业务场景对一致性要求极高比如金融交易明细就不要基于对象存储在应用层自己做架构直接上强一致性的分布式数据库会省去大量麻烦。在HDFS场景下强一致性让这些问题基本不存在但强一致性也带来了代价——写一条数据必须等所有副本都落盘后才能返回写入延迟比最终一致性系统要高。所以设计时要做的权衡是数据是否需要立刻被所有读取方看到如果能容忍几秒甚至几十秒的延迟那就可以考虑对象存储方案成本和扩展性都更优。4.5 数据归档与冷热分层——存储的降本增效之路最后聊一个很多团队在存储使用率达到临界点之后才想起来的问题冷热数据分层。分布式存储的成本和性能通常是矛盾的。热数据需要高吞吐低延迟放在SSD或者高性能HDD上副本数保持默认冷数据需要的是低成本、长期保存、偶尔访问就可以用更低配的存储介质或者迁移到廉价的归档存储里。HDFS本身没有天然的冷热分层能力但可以结合Hive的Partition策略来做把超过一定时间的历史分区标记为冷数据通过定时任务比如每天凌晨跑一个Spark job把这些数据从默认目录迁移到一个单独设置的归档目录归档目录可以设置dfs.replication2或者更低甚至可以用DistCp把数据导出到OSS或者MinIO。代码层面看这就是一个分区级的数据移动流程实现并不复杂但带来的成本节约非常可观。MinIO在冷热分层上有一个很好的功能——生命周期规则Lifecycle Management。你可以为bucket配置自动迁移规则比如超过30天的数据自动从标准存储类转为归档存储类或超过90天的数据自动删除。这个规则是系统级的不需要额外写任务部署好之后就一直生效。我在生产环境里常用的配置是热数据保存在本地MinIO的SSD路径上7天前的冷数据通过生命周期规则自动转移到容量盘或者用S3协议再复制到对象归档服务里。从整个数据架构的视角看冷热分层不只是运维侧的降本手段它还能改善热数据的访问性能——把冷数据移出主存储之后NameNode的元数据压力、DataNode的磁盘占用、集群的备份窗口都会得到明显改善热数据的读写在同样的硬件上反而会更快。做分布式存储设计这些年我最大的体会是方案选型和参数调优固然重要但更关键的是对整个系统的演化空间有预判。存储是数据架构里最底层的基座换存储的代价远比换计算引擎高得多。所以在设计时宁可多花几天把容量模型算清楚、把访问模式调研透、把故障恢复路径演练好也不要为了一时的快速上线在存储层埋下隐患。如果你现在正在做这个决策我的建议就一句话别只看技术社区里谁的热度高回到自己的数据特征和业务需求上来把最基础的那三个问题想明白你的存储设计大概率就差不到哪里去。
