MaxCompute表设计最佳实践

MaxCompute表设计最佳实践

产生大量小文件的操作

MaxCompute表的小文件会影响存储和计算性能，因此我们先介绍下什么样的操作会产生大量小文件，从 而在做表设计的时候考虑避开此类操作。

• 使用MaxCompute Tunnel SDK上传数据，上传过程中，每commit一次就会产生一个文件。这时每 个文件过小(比如几K)，并且频繁上传(比如5秒上传)一次，则一小时就会产生720个小文件，一 天就会产生17280个小文件。
• 使用MaxCompute Tunnel SDK上传数据，create了session但是没有upload数据直接做了 commit，产生大量空目录(服务侧等同于小文件)。
• 使用MaxCompute Console命令行工具Tunnel命令上传时，将本地大文件切分过小，导致上传后产 生文件数过多，文件过小。
• 通过DataHub做数据归档，Datahub 的每个shard写 MaxCompute 有两个条件:数据总量达到 64MB，commit 一次到 MaxCompute，形成一个文件。或者每隔 5 分钟一次 commit，形成一个 文件。那么:开的shard数多(比如20个shard)，每个shard数据在5分钟内都远远达不到64M，比 如就是几百K，就会产生大量小文件。那么一天就会产生241220=5760个小文件。
• 通过Dataworks等数据开发工具进行数据增量插入(insert into)到MaxCompute的表(或者表分 区)里时，每个insert into都会产生一个文件，若每次insert into 10条，每天累计insert insert 10000条记录，则会产生1000个小文件。
• 通过阿里云DTS将数据从RDS等数据库同步到MaxCompute，DTS进行数据同步时，会创建全量表和 增量表，增量表进程数据插入过程中会因为每次数据插入条数较少而commit比较完整一次数据同步， 从而在增量表中造成小文件问题，比如每隔5分支执行一次同步，每次同步的数据量为10条，一天内的 增量为10000条，则会产生1000个小文件。此种场景，需要在数据同步完成后进行全量极限表和增量 数据表的merge。
• 源数据采集客户端太多，源数据通过T unnel直接进入到一个分区，每个源数据采集客户端提交一次数 据，都会在同一分区下产生一个独立的文件导致产生大量小文件。
• SLS 触发 FunctionCompute持续高频往MaxCompute中心接入文件，小文件流式数据进入 MaxCompute。

根据数据划分项目空间

项目空间(Project)是MaxCompute最高层的对象，按项目空间进行资源的分配、隔离和管理，实现了 多租户的管理能力。

• 如果多个应用需要共享“数据”，则推荐使用同一个项目空间。
• 如果多个应用所需“数据”是无关的，则推荐使用不同的项目空间。 项目空间间的表和分区可以通过Package授权的方式进行交换。

“维度表”设计的最佳实践:

一般情况下描述属性的表设计为维度表。维度表可以和任意表组的任意表进行关联，并且创建时不需要配 置分区信息，但是对单表数据量大小有所限制。维度表的设计和使用注意以下几点:

• 一般要求维度表单表不超过1000万。
• 维度表的数据不应该被大量更新。
• 维度表和其他表进行Join操作时可以使用mapjoin。

拉链表设计 – 极限存储的应用

极限存储功能待发布，在此介绍主要提供设计思想。 基于MaxCompute的拉链表设计背景 在数据仓库的数据模型设计过程中，经常会遇到这样的需求:

• 数据量比较大。 表中的部分字段会被update,如用户的地址，产品的描述信息，订单的状态、手机号码等等。
• 需要查看某一个时间点或者时间段的历史快照信息。(比如，查看某一个订单在历史某一个时间点的 状态，比如，查看某一个用户在过去某一段时间内，更新过几次等等)
• 变化的比例和频率不是很大，比如，总共有1000万的会员，每天新增和发生变化的有10万左右，如果表每天