rtmp规范1.0全面指南
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了rtmp规范1.0全面指南相关的知识，希望对你有一定的参考价值。
参考技术ARTMP（real time messaging protocol）协议
本文为Adobe rtmp规范1.0的中文介绍，其中内容大部分都是翻译自rtmp官方文档 rtmp_specification_1.0.pdf
Adobe的实时消息传输协议（ RTMP ）通过可靠的流传输（如 TCP [RFC0793] ）提供双向消息多路传输服务，用于在端到端之间传输带有时序信息的视频，音频和数据消息的并行流。 穿过多层流， RTMP 消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级，例如：一段实时视频服务会选择丢弃给缓慢的客户的视频信息确保音频信息可以及时被接收。 RTMP消息块流 包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。
有效负载：Payload
包含在包中的数据，就像音频样本或者压缩的视频数据。
包：Packet
一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义。
端口：Port
在 TCP/IP 协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用，用于 OSI 传输层的传输选择（ TSEL ）就是端口。
传输地址：Transport address
网络地址和端口的组合识别一个传输层终端端口，例如一个IP地址和TCP端口，数据包从一个源传输层地址传送到目标段的传输层地址。
消息流：Message stream
一个通信的逻辑通道，允许消息流通。
消息流ID：Message stream ID
每一个消息拥有一个分配的ID识别跟随的消息流。
消息块：Chunk
消息的片段，消息被分成小的部分，在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送，穿过多层流。
消息块流：Chunk stream
一个通信的逻辑通道，允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器，也可以相反。
消息块流ID：Chunk stream ID
每一个消息块有一个分配的ID用于识别更随的消息块流。
复合技术：Multiplexing
把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。
逆复合技术：DeMultiplexing
复合的反向过程，交叉存取组装的音频视频数据，使他们成为最初的音视频数据
远程过程调用：Remote Procedure Call (RPC)
允许客户端或服务器在对等端调用子例程或过程的请求。
Action Message Format (AMF)
一种紧凑的二进制格式，用于序列化 ActionScript object graphs 。 可以透过 AMF overHTTP 的方式将 flash 端资料编码后传回server，server端的 remoting adaptor 接收到资料后则会译码回正确的 native 对象，交给正确的程序处理。
所有的整数字段都被引入到了字节顺序当中，字节0是第一个显示出来的，也是一个词和一个字段中最重要的。这种顺序就是通常所说的“大端”。如果没有特殊说明，在本文档中数字常量都是用十进制表示。
除另有规定外， RTMP 中的所有数据都是字节对齐的。例如，一个16位字段可能处于奇数字节偏移处。 在指定填充的地方，填充字节应该是0。
RTMP 中的时间戳相对于未指定的时期是以整数毫秒为单位给出的。 通常，每个流将以时间戳0开始，但这不是必需的，只要两个终端在时间点上达成一致。 请注意，这意味着跨多个流（尤其是来自不同主机）的任何同步都需要一些 RTMP 外的其他机制。
时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测，和流控制。
由于时间戳长度为32位，因此它们每隔49天，17小时，2分钟，47.296秒滚动一次。 由于流可以连续运行，可能持续数年， RTMP 应用程序应该在处理时间戳时使用序列号算法 [RFC1982] ，并且应该能够处理回绕。 例如，假定所有相邻的时间戳都在 2^31 - 1 毫秒之间，所以10000会在4000000000之后，而3000000000会在4000000000之前。
时间戳增量delta也被指定为相对于先前时间戳的无符号整数毫秒数。 时间戳增量delta可以是24位或32位。
本节介绍实时消息传送协议块流（ RTMP块流 ）。 它为更高级别的多媒体流协议提供复用和打包服务。 虽然 RTMP Chunk Stream 旨在与实时消息传送协议配合使用，但它可以处理发送消息流的任何协议。 每条消息都包含时间戳和有效负载类型标识。 RTMP Chunk Stream 和 RTMP 一起适用于各种音频 - 视频应用，从一对一和一对多实时广播到视频点播服务，再到交互式会议应用。
当与可靠的传输协议（如 TCP [RFC0793] ）一起使用时， RTMP块流 提供了保证所有消息在多个流中按时间排序的端到端传送。 RTMP块流 不提供任何优先级或类似的控制形式，但可以由更高级别的协议提供这种优先级。
可以拆分成块以支持复用的消息格式取决于更高级别的协议。 但是，消息格式应该包含下列创建块所必需的字段。
时间戳：
消息的时间戳，这个字段可以传输4个字节。
长度：
消息的有效负载的长度，如果消息头不能被省略，它应该包含在长度中，这个字段在消息块包头中占有3个字节。
类型ID：
协议控制消息的类型字段的范围是被保留的，这些传播信息的消息由 RTMP消息块 和高层协议处理，所有其他的类型ID可被高层协议使用，对 RTMP消息块 来说当做不透明的值，实际上， RTMP Chunk Stream 中的任何内容都不需要将这些值用作类型; 所有（非协议）消息可以是相同类型的，或者应用程序可以使用类型id来区分同步踪迹而不是类型。 该字段占用块头中的1个字节。
消息流ID:
消息流ID可以是任意的值。 复合到相同块流上的不同消息流可以基于它们的消息流ID进行逆复合操作。 除此之外，就 RTMP 块流而言，这是一个不透明的值。 该字段以小尾数格式占用块头中的4个字节。
RTMP 连接始于握手。 rtmp 握手与其他协议的握手不同; 它由三个相同大小的块组成，而不是由可变大小的块组成。
客户端（连接已初始化的终端）和服务器都发送相同的三个块。 为了说明，由客户端发送的3个块分别为 C0 , C1 , C2 ，由服务端发送的3个块分别为 S0 , S1 , S2 。
握手以客户端发送 C0 和 C1 消息块位开始，客户端必须等到 S1 到达在发送 C2 。客户端必须等到 S2 接收到才可以发送其他的数据；服务端必须等到 C0 到达才发送 S0 和 S1 ，在 C1 之后也会等待。服务端必须等到 C1 到达才发送 S2 ，服务端必须等到 C2 到达后才发送其他数据。
C0 和 S0 都是单个8位字节，可以看成一个8位整形字段。
8比特版本：在C0中，这个字段识别客户端需求的RTMP的版本，在S0中，这个字段识别服务器端选择的RTMP的版本，被定义的是版本3，0到2是早前的版本使用的，4到31保留用于未来使用，32到255还没有被允许。不能区分客户的请求的版本的服务应该以3返回，客户端可以选择降级到版本3，或放弃握手。
C1 和 S1 包长度为1536个8位字节，包含以下字段：
time（4个字节） ：这个字段包含时间戳，被当做后续消息块从终端发送的时间点，也许是0，或者一些任意的值。为了同步多路消息块流，终端或许希望发送其他消息块流的时间戳的当前值。
zero（4各个字节） ：这个字段必须全0。
random data（1528个字节） ：这个字段可以包含任何任意的值，因为每个终端必须区分自己初始化的握手的返回数据和对方初始化的握手的返回数据，这个数据应该发送一些随机数。但是没有必要用密码保护随机数和动态值。
C2 和 S2 包长度为1536个8位字节，分别类似于 S1 和 C1 的原样返回，由一下几个字段组成：
time（4个字节） ：
这个字段必须包含由对端发送的 S1 （对应 C2 ）或者 C1 （对应 S2 ）的时间戳.
time2（4个字节） ：
这个字段必须包含先前的由对端发送的数据包（ S1 或者 C1 ）被读取的时间戳。
random echo（1528个字节） ：
这个字段必须包含在对端发送的 S1 （对应 C2 ）或 S2 （对应 C1 ）数据包中的随机数据字段。 任何一方都可以使用 time 和 time2 字段与当前时间戳一起快速估算连接的带宽和/或延迟，但这不太可能有用。
下面的表格描述了握手过程的几个阶段
握手后，连接复用一个或多个消息块流。每个块流从一个消息流携带一种类型的消息。每个创建的块都有一个与其关联的唯一ID，称为块流ID。这些块通过网络传输。发送时，每个块必须在下一个块之前全部发送。在接收端，根据块流ID将块组合成消息。
分块允许将较高级别协议中的大的型消息分解为较小的消息，例如防止较大的低优先级消息（例如视频）阻塞较小的高优先级消息（如音频或控制）。
分块还允许以较少的开销发送小消息，因为分块头包含信息的压缩表示信息，这些压缩消息本来应该包含在消息本身的。
块大小是可配置的。它可以使用 Set Chunk Size 控制消息进行设置。
每一个消息块有头部和数据组成，头部自身可以被分割成三个部分：
消息块基本头（1到3个字节） ：这个字段编码了消息块流的ID和消息块的类型，消息块类型决定了消息包头的编码格式，长度完全取决于可变长的消息块流ID。
消息块消息头（0,3,7或11字节） ：这个字段编码正在传送的消息的信息，长度可以利用在消息块头中详细的消息块类型来决定。
扩展时间戳（0或4字节） ：此字段在某些情况下是存在的，取决于消息块消息头中的编码时间戳或时间戳增量字段。
消息块块数据（可变大小） ：该块的有效负载，直至配置的最大块大小。
消息块基本头对消息块流的ID和消息块的类型进行编码（在下面的图表中用 fmt 表示），消息块类型决定了编码的消息头的格式，消息块基本头字段可以是1,2或者3个字节长，取决于消息块流ID。
该协议支持多达65597个ID为3-65599的流。 ID0,1和2被保留。 值0指示2字节形式和64-319范围内的ID（ the second byte + 64 ）。 值1表示3字节形式，ID在64-65599（ (the third byte) * 256 + the second byte + 64 ）范围内。 在3-63范围内的值表示完整的流ID。 块ID为2的流ID保留，用于低级别的协议控制消息和命令。
在消息块基本头中0-5比特(最不重要的)代表了消息块流ID。
消息块流ID 2-63 可以被编码成这个字段的单字节的版本号。
块流ID 64-319可以以2字节的形式被编码。 ID计算为（第二个字节+ 64）。
可以在此字段的3字节版本中对块流ID 64-65599进行编码。 ID计算为（（第三字节）* 256 +（第二字节）+64）。
cs id（6比特） ：这个字段包含了消息块流ID，值从2到63，值0和1用于代表这个字段的2个或者3个字节的版本号。
fmt（2比特） ：这个字段标识消息块消息头使用的四种格式之一。见下一小节
cs id -64（8或者16个比特） ：
这个字段包含了消息块流ID减64，例如ID 365在 cs id 段用1表示，在16比特的 cs id -64 段用301表示。
值为64到319的消息块流ID可以被2字节或者3字节的版本号来表示。
在消息块消息头中有四种不同的格式，由消息块基本头的 fmt 字段选择。应该使用最简洁的表达方式表示每一个消息块消息头。
类型0的消息块有11个字节长，这个类型必须在消息块流开始时和消息流的时间戳回溯时使用
时间戳（3个字节） ：对于类型0的块，消息的绝对时间戳发送到此处。 如果时间戳大于或等于16777215（十六进制 0xFFFFFF ），则该字段必须是16777215，表示存在扩展时间戳字段以编码完整的32位时间戳。 否则，这个字段应该是整个时间戳。
类型1的消息块有7个字节长，消息流ID没有被包含，这个消息块得到和先前消息块同样的流ID，带有可变长的消息的流（例如许多视频格式）在类型0消息块后应该使用这种格式作为每一个消息的第一个消息块。
类型2块头长度为3个字节。 流ID和消息长度都不包含在内; 该块与前面的块具有相同的流ID和消息长度。 具有固定大小消息的流（例如，某些音频和数据格式）应该在第一个消息之后使用这种格式作为每个消息的第一个块。
类型3 的消息块没有头，流ID，消息长度和时间戳delta，这个类型的消息块在之前的消息块中取值，当单一的消息被分裂成消息块，所有的消息块除了第一个，其余都应该使用这种类型，流由同样大小的消息组成。
块消息头中每个字段的描述：
Extended Timestamp 字段用于编码大于16777215（ 0xFFFFFF ）的时间戳或时间戳增量; 也就是说，对于时间戳或时间戳增量，它们不适合类型0,1或2块的24位字段。 该字段对完整的32位时间戳或时间戳增量进行编码。 这个字段用于表示将类型0块的时间戳字段或类型1或2块的时间戳增量字段设置为16777215（ 0xFFFFFF ）。 当相同块流ID的最新类型0,1或2的块指示存在扩展时间戳字段时，该字段出现在类型3的块中。
共有2个示例
本例给出了一个简单的音频消息流，这个例子示范了信息的冗余。
下表显示了在此流中生成的块。 从消息3开始，数据传输得到优化。 除此之外，每消息只有1字节的开销。
本例说明一个很长的消息被分割成很多消息块。
这里是分割出来的消息块
消息块1的包头数据详细介绍了307个字节的消息的全部。
注意这两个例子，类型3消息块可以用作两种不同的方式，第一种是表示一条消息的延续，第二种是表示一条新消息的开始，这个新消息可以从已经存在的数据中衍生出来。
RTMP 块流使用消息类型ID 1,2,3,5和6作为协议控制消息。 这些消息包含 RTMP Chunk Stream 协议所需的信息。
这些协议控制消息务必具有消息流ID 0 （称为控制流）并且以块流ID 2 发送。协议控制消息一旦被接收就会立即生效，同时时间戳被忽略。
协议控制消息1：设置消息块大小。用来通知对方新的最大的消息块大小。
消息块的大小可以被设置成一个默认的值，128字节，但是客户端或者服务端可以改变这个值，并且发送消息通知对方更新。例如：假设一个客户端想要发送131字节的音频数据，消息块的大小为128字节，在这种情况下，客户端可以发送这个协议控制消息给服务端以通知消息块的大小被设置成了131字节，那么客户端就可以用一个消息块发送音频数据。
最大块大小应该不能小于128个字节，并且必须不能小于1个字节。 每个方向的最大块大小都是独立维护的。
0 ： 这一位必须为0。
chunk size 块大小（31位） ：该字段保存新的最大块大小（以字节为单位），这将用于发件人的所有后续块，直至另行通知。 有效大小为1到2147483647（ 0x7FFFFFFF ）（含）; 但是，大于16777215（ 0xFFFFFF ）的所有大小都是等效的，因为没有块大于一条消息，并且没有消息大于16777215字节。
协议控制消息2：中止消息。用于通知对方是否正在等待块完成消息，然后丢弃部分接收到的消息。 对方接收块流ID作为该协议消息的有效载荷。 应用程序可能会在关闭时发送此消息，以指示不需要进一步处理消息。
chunk stream ID 块流ID （32 位） ： 该字段保存块流ID，对应的当前消息将被丢弃。
客户端或服务器在收到等于窗口大小的字节后，必须向对端发送 Acknowledgement 确认。 窗口大小是发送方未收到接收方确认而发送的最大字节数。 该消息指定了序列号，它是到当前为止收到的字节数。
sequence number 序列号（32 位） ：字段表示到当前为止收到的字节数。
客户端或服务器发送此消息以通知对方在发送 Acknowledgement 确认之间使用的窗口大小。 发送人希望在发送窗口大小字节后得到对方的确认。
客户端或服务器发送此消息来限制另一方的输出带宽。 收到此消息的另一方通过将已发送但未确认的数据量限制为此消息中指示的窗口大小这种方式用来限制其输出带宽。如果窗口大小与发送给此消息发送者的最后一个窗口大小不同，那么接收此消息的另一方应该使用 "Window Acknowledgement Size" 消息进行响应。
限制类型 Limit Type 是以下值之一：
本部分主要介绍 RTMP 消息的格式，在网络实体之间使用较低级传输层（如 RTMP块流 ）传输这些消息。
虽然 RTMP 旨在与 RTMP块流 一起使用，但它可以使用任何其他传输协议发送消息。 RTMP Chunk Stream 和 RTMP 一起适用于各种音视频应用，从一对一和一对多实时广播到视频点播服务，再到交互式会议应用。
服务器和客户端通过网络发送 RTMP 消息以相互通信。 消息可能包括音频，视频，数据或任何其他消息。
RTMP 消息有两部分，头部和有效负载。
消息头包含以下字段：
消息的另一部分是有效负载，它是消息中包含的实际数据。 例如，它可能是一些音频样本或压缩的视频数据。
RTMP使用消息类型ID 4 作为用户控制消息。 这些消息包含RTMP流层使用的信息。 带有ID 1,2,3,5和6的协议消息由RTMP块流协议使用。
用户控制消息应该使用消息流ID 0（称为控制流），并且当通过RTMP块流发送时，在消息流ID 2上发送。用户控制消息在流中被接收时生效， 他们的时间戳被忽略。
客户端或服务器发送此消息以通知对端用户控制事件。 该消息携带事件类型和事件数据。
消息数据 Event Data 的前2个字节用于标识事件类型 Event Type 。 事件类型后面跟着事件数据。 事件数据字段的大小是可变的。 但是，在消息必须通过RTMP块流层的情况下，最大块的大小应该足够大，以允许这些消息适合单个块。
本节介绍在服务器和客户端之间用于相互通信的不同类型的消息和命令。
在服务器和客户端之间交换的不同类型的消息包括用于发送音频数据的音频消息，用于发送视频数据的视频消息，用于发送任何用户数据的数据消息，共享对象消息和命令消息。 共享对象消息提供了一种通用的方式来管理多个客户端和服务器之间的分布式数据。 命令消息在客户端和服务器之间传送 AMF 编码的命令。 客户端或服务器可以通过流使用命令消息请求对方的远程过程调用（ RPC ）。
服务器和客户端通过网络发送消息以相互通信。 消息可以是任何类型，包括音频消息，视频消息，命令消息，共享对象消息，数据消息和用户控制消息。
命令消息在客户端和服务器之间传送 AMF 编码命令。 这些消息的 AMF0 编码的消息类型值为20， AMF3 编码的消息类型值为17。 这些消息被发送来执行一些操作，例如 connect ， createStream ， publish ， play ， pause 等。 诸如 onstatus ， result 等命令消息用于通知发送者有关请求的命令的状态。 命令消息由命令名称，事务ID和包含相关参数的命令对象组成。 客户端或服务器可以通过流使用命令消息请求对方的远程过程调用（ RPC ）。
客户端或服务器发送此消息用于向对方发送元数据或任何用户数据。 元数据包括有关数据（音频，视频等）的详细信息，如创建时间，持续时间，主题等。 AMF0 的消息类型值为18， AMF3 的消息类型值为15。
共享对象是一个Flash对象（name-value对的集合），在多个客户端，实例等之间同步的。 AMF0 的消息类型19和 AMF3 的消息类型16保留用于共享对象事件。 每条消息可以包含多个事件。
支持以下事件类型：
客户端或服务器发送此消息来向对等方发送音频数据。 消息类型值8保留给音频消息。
客户端或服务器发送此消息以向对等方发送视频数据。 消息类型值9保留给视频消息。
聚合消息是单个消息。消息类型22用于聚合消息。
聚合消息的消息流ID会覆盖聚合内的子消息的消息流ID。
聚合消息的时间戳与第一个子消息之间的差异是用于将子消息的时间戳重新归一化为流时间尺度的偏移量。 将偏移量添加到每个子消息的时间戳以达到标准化的流时间。 第一个子消息的时间戳应该与聚合消息的时间戳相同，所以偏移量应该为零。
后向指针包含前一个消息的大小，包括其头部。 它被包含来匹配 FLV 文件的格式并用于向后搜索。
使用聚合消息有几个性能优势：
客户端或服务器发送此消息以通知对端关于用户控制事件。
支持以下用户控制事件类型：
客户端和服务器交换 AMF 编码的命令。发送方发送一条命令消息，其中包含命令名称，事务ID和包含相关参数的命令对象。例如， connect 命令包含 \'app\' 参数，它告诉客户端连接到的服务器应用程序名称。接收方处理该命令并以相同的事务ID发送响应。响应字符串可以是 _result ， _error 或方法名称，例如 verifyClient 或 contactExternalServer 。
_result 或 _error 命令字符串表示响应。事务ID指示响应引用的未完成的命令。它与 IMAP 和许多其他协议中的标签相同。命令字符串中的方法名称指示发送方正试图在接收方端运行方法。
以下类对象用于发送各种命令：
NetConnection 管理客户端应用程序和服务器之间的双向连接。 另外，它为异步远程方法调用提供支持。
以下命令可以在 NetConnection 上发送：
客户端向服务端发送连接（ connect ）命令请求连接一个服务器应用实例。以下为命令的结构：
以下是连接命令的命令对象中使用的 name-value 对的描述：
audioCodecs 属性的标志值：
videoCodecs 属性的标志值：
videoFunction 属性的标志值：
对象编码( object Encoding )属性的值：
以下是服务端到客户端命令的结构：
以下是连接命令中的消息流：
命令执行期间的消息流是：
NetConnection 对象的调用方法在接收端运行远程过程调用（ RPC ）。 被调用的 RPC 名称作为参数传递给 call 命令。
从发送方到接收方的命令结构如下：
响应的命令结构如下：
客户端将此命令发送到服务器以创建用于消息通信的逻辑通道。音频，视频和元数据的发布是通过使用 createStream 命令创建的流通道执行的。
NetConnection 是默认通信通道，其流ID为0。协议和一些命令消息（包括 createStream ）使用默认通信通道。
从客户端到服务器的命令结构如下所示：
从服务器到客户端的命令结构如下：
NetStream 定义了流式音频，视频和数据消息可以通过将客户端连接到服务器的 NetConnection 流动的通道。 一个 NetConnection 对象可以为多个数据流支持多个 NetStream 。
以下命令可以由客户端在 NetStream 上发送到服务器：
服务器使用 \'onStatus\' 命令将 NetStream 状态更新发送到客户端：
客户端将此命令发送到服务器以播放流。 播放列表也可以使用此命令多次创建。
如果您想要创建一个可在不同直播流或录像流之间切换的动态播放列表，请多次调用 play ，每次给 reset 传递 false 。相反，如果要立即播放指定的数据流，请清空播放队列中的其他流，给 reset 传递 true 。
从客户端到服务器的命令结构如下所示：
Play 命令中的消息流：
数仓建设规范指南
本文将全面讲解数仓建设规范，从数据模型规范，到数仓公共规范，数仓各层规范，最后到数仓命名规范，包括表命名，指标字段命名规范等！
目录：
一、数据模型架构原则
数仓分层原则
主题域划分原则
数据模型设计原则
二、数仓公共开发规范
层次调用规范
数据类型规范
数据冗余规范
NULL字段处理规范
指标口径规范
数据表处理规范
表的生命周期管理
三、数仓各层开发规范
ODS层设计规范
公共维度层设计规范
DWD明细层设计规范
DWS公共汇总层设计规范
四、数仓命名规范
词根设计规范
表命名规范
指标命名规范
一、数据模型架构原则
1. 数仓分层原则
优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长。那么问题来了，一直在讲数仓要分层，那数仓分几层最好？
目前市场上主流的分层方式眼花缭乱，不过看事情不能只看表面，还要看到内在的规律，不能为了分层而分层，没有最好的，只有适合的。
分层是以解决当前业务快速的数据支撑为目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。
一个好的分层架构，要有以下好处：
清晰数据结构；
数据血缘追踪；
减少重复开发；
数据关系条理化；
屏蔽原始数据的影响。
数仓分层要结合公司业务进行，并且需要清晰明确各层职责，一般采用如下分层结构：
数仓建模在哪层建设呢？我们以维度建模为例，建模是在数据源层的下一层进行建设，在上图中，就是在DW层进行数仓建模，所以DW层是数仓建设的核心层。
下面详细阐述下每层建设规范，和上图的分层稍微有些区别：
1. 数据源层：ODS（Operational Data Store）
ODS 层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。
2. 数据仓库层：DW（Data Warehouse）
数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。
DW 层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和 DWS（Data WareHouse Servce） 层。
1) 数据明细层：DWD（Data Warehouse Detail）
该层一般保持和 ODS 层一样的数据粒度，并且提供一定的数据质量保证。DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。
同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性 。
2) 数据中间层：DWM（Data WareHouse Middle）
该层会在 DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
在实际计算中，如果直接从 DWD 或者 ODS 计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在 DWM 层先计算出多个小的中间表，然后再拼接成一张 DWS 的宽表。由于宽和窄的界限不易界定，也可以去掉 DWM 这一层，只留 DWS 层，将所有的数据再放在 DWS 亦可。
3) 数据服务层：DWS（Data WareHouse Servce）
DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。DWS 层应覆盖 80% 的应用场景。又称数据集市或宽表。
按照业务划分，如主题域流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP 分析，数据分发等。
一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
3. 数据应用层：APP（Application）
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、 PostgreSql、Redis 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。
4. 维表层（Dimension）
如果维表过多，也可针对维表设计单独一层，维表层主要包含两部分数据：
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
2. 主题域划分原则
1) 按照业务或业务过程划分
业务容易理解，就是指的功能模块/业务线。
业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程。不过需要注意的是，一个业务过程是一个不可拆分的行为事件，通俗的讲，业务过程就是企业活动中的事件。
2) 按照数据域划分
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程下，可以定义指标，维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
3. 数据模型设计原则
1) 高内聚、低耦合
即主题内部高内聚、 不同主题间低耦合。明细层按照业务过程划分主题，汇总层按照“实体+ 活动”划分不同分析主题，应用层根据应用需求划分不同应用主题。
2) 核心模型和扩展模型要分离
建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性与可维护性。
3) 公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用实现，不要让公共逻辑多处同时存在。
4) 成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
5) 数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变。
二、数仓公共开发规范
1. 层次调用规范
稳定业务按照标准的数据流向进行开发，即 ODS –> DWD –> DWS –> APP。非稳定业务或探索性需求，可以遵循 ODS -> DWD -> APP 或者 ODS -> DWD -> DWM ->APP 两个模型数据流。
在保障了数据链路的合理性之后，也必须保证模型分层引用原则：
正常流向：ODS -> DWD -> DWM -> DWS -> APP，当出现 ODS -> DWD -> DWS -> APP 这种关系时，说明主题域未覆盖全。应将 DWD 数据落到 DWM 中，对于使用频度非常低的表允许 DWD -> DWS。
尽量避免出现 DWS 宽表中使用 DWD 又使用（该 DWD 所归属主题域）DWM 的表。
同一主题域内对于 DWM 生成 DWM 的表，原则上要尽量避免，否则会影响 ETL 的效率。
DWM、DWS 和 APP 中禁止直接使用 ODS 的表， ODS 的表只能被 DWD 引用。
禁止出现反向依赖，例如 DWM 的表依赖 DWS 的表。
举例：
2. 数据类型规范
需统一规定不同的数据的数据类型，严格按照规定的数据类型执行：
金额：double 或 使用 decimal(28,6) 控制精度等，明确单位是分还是元。
字符串：string。
id类：bigint。
时间：string。
状态：string
3. 数据冗余规范
宽表的冗余字段要确保：
冗余字段要使用高频，下游3个或以上使用。
冗余字段引入不应造成本身数据产生过多的延后。
冗余字段和已有字段的重复率不应过大，原则上不应超过60%，如需要可以选择join或原表拓展。
4. NULL字段处理规范
对于维度字段，需设置为-1
对于指标字段，需设置为 0
5. 指标口径规范
保证主题域内，指标口径一致，无歧义。
通过数据分层，提供统一的数据出口，统一对外输出的数据口径，避免同一指标不同口径的情况发生。
1) 指标梳理
指标口径的不一致使得数据使用的成本极高，经常出现口径打架、反复核对数据的问题。在数据治理中，我们将需求梳理到的所有指标进行进一步梳理，明确其口径，如果存在两个指标名称相同，但口径不一致，先判断是否是进行合并，如需要同时存在，那么在命名上必须能够区分开。
2) 指标管理
指标管理分为原子指标维护和派生指标维护。
原子指标：
选择原子指标的归属产线、业务板块、数据域、业务过程
选择原子指标的统计数据来源于该业务过程下的原始数据源
录入原子指标的英文名称、中文名称、概述
填写指标函数
系统根据指标函数自动生成原子指标的定义表达式
系统根据指标定义表达式以及数据源表生成原子指标SQL
派生指标：
在原子指标的基础之上选择了一些维度或者修饰限定词。
6. 数据表处理规范
1) 增量表
新增数据，增量数据是上次导出之后的新数据。
记录每次增加的量，而不是总量；
增量表，只报变化量，无变化不用报；
每天一个分区。
2) 全量表
每天的所有的最新状态的数据。
全量表，有无变化，都要报；
每次上报的数据都是所有的数据（变化的 + 没有变化的）；
只有一个分区。
3) 快照表
按日分区，记录截止数据日期的全量数据。
快照表，有无变化，都要报；
每次上报的数据都是所有的数据（变化的 + 没有变化的）；
一天一个分区。
4) 拉链表
记录截止数据日期的全量数据。
记录一个事物从开始，一直到当前状态的所有变化的信息；
拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总 量；
当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
只有一个分区。
7. 表的生命周期管理
这部分主要是要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。
1) 历史数据等级划分
主要将历史数据划分P0、Pl、P2、P3 四个等级，其具体定义如下：
P0 ：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团 KPI 数据、 IPO 关联表。
Pl ：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。
P2 ：重要的业务数据和重要的应用数据，具有可恢复性，如交易线 ETL 产生的中间过程数据。
P3 ：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些 SNS 产品报表。
2) 表类型划分
事件型流水表（增量表）
事件型流水表（增量表）指数据无重复或者无主键数据，如日志。
事件型镜像表（增量表）
事件型镜像表（增量表）指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。
维表
维表包括维度与维度属性数据，如用户表、商品表。
Merge 全量表
Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区 中。例如，用户表、交易表等都可以进行 Merge 操作。
ETL 临时表
ETL 临时表是指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。
TT 临时数据
TT 拉取的数据和 DbSync 产生的临时数据最终会流转到 DS 层，ODS 层数据作为原始数据保留下来，从而使得 TT&DbSync 上游数据成为临时数据。这类数据不建议保留很长时间，生命周期默认设置为 93天，可以根据实际情况适当减少保留天数。
7. 普通全量表
很多小业务数据或者产品数据，BI一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。
通过上述历史数据等级划分与表类型划分，生成相应的生命周期管理矩阵，如下表所示：
三、数仓各层开发规范
1. ODS层设计规范
同步规范：
一个系统源表只允许同步一次；
全量初始化同步和增量同步处理逻辑要清晰；
以统计日期和时间进行分区存储；
目标表字段在源表不存在时要自动填充处理。
表分类与生命周期：
ods流水全量表：
不可再生的永久保存；
日志可按留存要求；
按需设置保留特殊日期数据；
按需设置保留特殊月份数据；
ods镜像型全量表：
推荐按天存储；
对历史变化进行保留；
最新数据存储在最大分区；
历史数据按需保留；
ods增量数据：
推荐按天存储；
有对应全量表的，建议只保留14天数据；
无对应全量表的，永久保留；
ods的etl过程中的临时表：
推荐按需保留；
最多保留7天；
建议用完即删，下次使用再生成；
BDSync非去重数据：
通过中间层保留，默认用完即删，不建议保留。
数据质量：
全量表必须配置唯一性字段标识；
对分区空数据进行监控；
对枚举类型字段，进行枚举值变化和分布监控；
ods表数据量级和记录数做环比监控；
ods全表都必须要有注释；
2. 公共维度层设计规范
1) 设计准则
一致性
共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致（历史原因不一致，要做好版本控制）
维度的组合与拆分
组合原则：
将维度与关联性强的字段进行组合，一起查询，一起展示，两个维度必须具有天然的关系，如：商品的基本属性和所属品牌。
无相关性：如一些使用频率较小的杂项维度，可以构建一个集合杂项维度的特殊属性。
行为维度：经过计算的度量，但下游当维度处理，例：点击量 0-1000,100-1000等，可以做聚合分类。
拆分与冗余：
针对重要性，业务相关性、源、使用频率等可分为核心表、扩展表。
数据记录较大的维度，可以适当冗余一些子集。
2) 存储及生命周期管理
建议按天分区。
3个月内最大访问跨度<=4天时，建议保留最近7天分区；
3个月内最大访问跨度<=12天时，建议保留最近15天分区；
3个月内最大访问跨度<=30天时，建议保留最近33天分区；
3个月内最大访问跨度<=90天时，建议保留最近120天分区；
3个月内最大访问跨度<=180天时，建议保留最近240天分区；
3个月内最大访问跨度<=300天时，建议保留最近400天分区；
3. DWD明细层设计规范
1) 存储及生命周期管理
建议按天分区。
3个月内最大访问跨度<=4天时，建议保留最近7天分区；
3个月内最大访问跨度<=12天时，建议保留最近15天分区；
3个月内最大访问跨度<=30天时，建议保留最近33天分区；
3个月内最大访问跨度<=90天时，建议保留最近120天分区；
3个月内最大访问跨度<=180天时，建议保留最近240天分区；
3个月内最大访问跨度<=300天时，建议保留最近400天分区；
2) 事务型事实表设计准则
基于数据应用需求的分析设计事务型事实表，结合下游较大的针对某个业务过程和分析指标需求，可考虑基于某个事件过程构建事务型实时表；
一般选用事件的发生日期或时间作为分区字段，便于扫描和裁剪；
冗余子集原则，有利于降低后续IO开销；
明细层事实表维度退化，减少后续使用join成本。
3) 周期快照事实表
周期快照事实表中的每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件。
粒度是周期性的，不是个体的事务。
通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许的。
4) 累积快照事实表
多个业务过程联合分析而构建的事实表，如采购单的流转环节。
用于分析事件时间和时间之间的间隔周期。
少量的且当前事务型不支持的，如关闭、发货等相关的统计。
4. DWS公共汇总层设计规范
数据仓库的性能是数据仓库建设是否成功的重要标准之一。聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同用访问明细数据带来的结果不一致问题。
1) 聚集的基本原则
一致性。聚集表必须提供与查询明细粒度数据一致的查询结果。
避免单一表设计。不要在同一个表中存储不同层次的聚集数据。
聚集粒度可不同。聚集并不需要保持与原始明细粒度数据一样的粒度，聚集只关心所需要查询的维度。
2) 聚集的基本步骤
第一步：确定聚集维度
在原始明细模型中会存在多个描述事实的维度，如日期、商品类别、卖家等，这时候需要确定根据什么维度聚集，如果只关心商品的交易额情况，那么就可以根据商品维度聚集数据。
第二步：确定一致性上钻
这时候要关心是按月汇总还是按天汇总，是按照商品汇总还是按照类目汇总，如果按照类目汇总，还需要关心是按照大类汇总还是小类汇总。当然，我们要做的只是了解用户需要什么，然后按照他们想要的进行聚集。
第三步：确定聚集事实
在原始明细模型中可能会有多个事实的度量，比如在交易中有交易额、交易数量等，这时候要明确是按照交易额汇总还是按照成交数量汇总。
3) 公共汇总层设计原则
除了聚集基本的原则外，公共汇总层还必须遵循以下原则：
数据公用性。汇总的聚集会有第三者使用吗？基于某个维度的聚集是不是经常用于数据分析中？如果答案是肯定的，那么就有必要把明细数据经过汇总沉淀到聚集表中。
不跨数据域。数据域是在较高层次上对数据进行分类聚集的抽象。如以业务
区分统计周期。在表的命名上要能说明数据的统计周期，如
_Id表示最近1天，_td表示截至当天，_nd表示最近N天。
四、数仓命名规范
1. 词根设计规范
词根属于数仓建设中的规范，属于元数据管理的范畴，现在把这个划到数据治理的一部分。完整的数仓建设是包含数据治理的，只是现在谈到数仓偏向于数据建模， 而谈到数据治理，更多的是关于数据规范、数据管理。
表命名，其实在很大程度上是对元数据描述的一种体现，表命名规范越完善，我 们能从表名获取到的信息就越多。比如：一部分业务是关于货架的，英文名是：rack， rack 就是一个词根，那我们就在所有的表、字段等用到的地方都叫 rack，不要叫成 别的什么。这就是词根的作用，用来统一命名，表达同一个含义。
指标体系中有很多“率”的指标，都可以拆解成 XXX+率，率可以叫 rate，那我 们所有的指标都叫做 XXX+rate。
词根：可以用来统一表名、字段名、主题域名等等。
举例：以流程图的方式来展示，更加直观和易懂，本图侧重 dwm 层表的命名 规范，其余命名是类似的道理：
第一个判断条件是该表的用途，是中间表、原始日志还是业务展示用的表 如果该表被判断为中间表，就会走入下一个判断条件：表是否有 group 操作 通过是否有 group 操作来判断该表该划分在 dwd 层还是 dwm 和 dws 层 如果不是 dwd 层，则需要判断该表是否是多个行为的汇总表（即宽表） 最后再分别填上事业群、部门、业务线、自定义名称和更新频率等信息即可。
分层：表的使用范围
事业群和部门：生产该表或者该数据的团队
业务线：表明该数据是哪个产品或者业务线相关
主题域：分析问题的角度，对象实体
自定义：一般会尽可能多描述该表的信息，比如活跃表、留存表等
更新周期：比如说天级还是月级更新
数仓表的命名规范如下：
1. 数仓层次:
公用维度：dim
DM层：dm
ODS层：ods
DWD层：dwd
DWS层：dws
2. 周期/数据范围：
日快照：d
增量：i
全量：f
周：w
拉链表：l
非分区全量表：a
2. 表命名规范
1) 常规表
常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去 完善的表。
规范：分层前缀[dwd|dws|ads]_部门_业务域_主题域_XXX_更新周期|数据范围
业务域、主题域我们都可以用词根的方式枚举清楚，不断完善。
更新周期主要的是时间粒度、日、月、年、周等。
2) 中间表
中间表一般出现在 Job 中，是 Job 中临时存储的中间数据的表，中间表的作 用域只限于当前 Job 执行过程中，Job 一旦执行完成，该中间表的使命就完 成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天 的中间表数据，用来排查问题）。
规范：mid_table_name_[0~9|dim]
table_name 是我们任务中目标表的名字，通常来说一个任务只有一个目标表。这里加上表名，是为了防止自由发挥的时候表名冲突，而末尾大家可以选择自由发挥，起一些有意义的名字，或者简单粗暴，使用数字代替，各有优劣吧，谨慎选择。
通常会遇到需要补全维度的表，这里使用 dim 结尾。
如果要保留历史的中间表，可以加上日期或者时间戳。
3) 临时表
临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表。
规范：tmp_xxx
只要加上 tmp 开头即可，其他名字随意，注意 tmp 开头的表不要用来实际使用，只是测试验证而已。
4) 维度表
维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。
规范：dim_xxx
维度表，统一以 dim 开头，后面加上，对该指标的描述。
5) 手工表
手工表是手工维护的表，手工初始化一次之后，一般不会自动改变，后面变更，也是手工来维护。
一般来说，手工的数据粒度是偏细的，所以暂时统一放在 dwd 层，后面如果有目标值或者其他类型手工数据，再根据实际情况分层。
规范：dwd_业务域_manual_xxx
手工表，增加特殊的主题域，manual，表示手工维护表。
3. 指标命名规范
1) 公共规则
所有单词小写
单词之间下划线分割（反例：appName 或 AppName）
可读性优于长度 (词根，避免出现同一个指标，命名一致性)
禁止使用 sql 关键字，如字段名与关键字冲突时 +col
数量字段后缀 _cnt 等标识...
金额字段后缀 _price 标识
天分区使用字段 dt，格式统一（yyyymmdd 或 yyyy-mm-dd）
小时分区使用字段 hh，范围（00-23）
分钟分区使用字段 mi，范围（00-59）
布尔类型标识：is_业务，不允许出现空值
2) 指标命名规范
结合指标的特性以及词根管理规范，将指标进行结构化处理。
基础指标词根，即所有指标必须包含以下基础词根：
业务修饰词，用于描述业务场景的词汇，例如trade-交易。
3.日期修饰词，用于修饰业务发生的时间区间。
4.聚合修饰词，对结果进行聚集操作。
5.基础指标，单一的业务修饰词+基础指标词根构建基础指标 ，例如：交易金额-trade_amt。
6.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量-install_poi_cnt。
7.普通指标命名规范，与字段命名规范一致，由词汇转换即可以。
参考
本文档规范依据来源参考：
《大数据之路：阿里巴巴大数据实践》
《数仓工具箱：维度建模权威指南》
《OneData建设：美团SaaS数仓建设》
以上是关于rtmp规范1.0全面指南的主要内容，如果未能解决你的问题，请参考以下文章