大数据技术提升与学习指南

如果你想提升大数据技术能力，寻找专业指导，持续学习，并找到一份满意的工作，欢迎加入我的知识星球。我开通知识星球已有大半年时间，星球上沉淀了大量有价值的内容。星球的定位是专注于大数据内容的干货输出，帮助大家提升大数据技术，带领大家共同学习。星球内容及语雀文档均经过精心总结和整理。

知识星球内包含1200份资料，涵盖常见面试问题、调优资料、大厂实践、公众号原创文章、代码等，供大家自取。此外，还为星球成员整理了一份详细的语雀知识库，包含常见面试问题总结、项目视频、技术总结、各项调优资料等。加入星球后支持三天无理由退款，不满意可随时无条件退款。

进入星球后，您将享受以下服务：

1. 提供最全的大数据知识库，不限设备，随时随地查看在线文档。
2. 免费答疑解惑、交流技术。
3. 面试指导、模拟面试。
4. 各类PDF文档下载、星球代码下载。
5. 提供简历模板，简历修改指导服务，星球成员免费提供简历修改指导。

基础平台搭建

1. 熟悉业务

（1）业务的战略目标或愿景是什么

（2）业务线或产品线有哪些

（3）梳理各业务场景、业务架构

（4）业务现状如何，有哪些业务痛点

• 例如运营方想通过用户标签或产品标签快速圈选目标人群、目标商品，但痛点是取数的链路长、取数效率低。可以从几方面解决：
  • 采用数据仓库解决方案——提前与业务方沟通，把所需数据提前准备好，存放在数仓的ADS层（由DIM和DWS加工得到），供业务方自助取数。
  • 采用湖仓一体解决方案——仓外挂湖，也就是把数据仓库中的表数据与Hive、Hudi或Iceberg中的数据做链接，即数仓表的外表。可行的技术栈是：Doris作数仓，Hudi或Iceberg作数据湖（DataX+FlinkCDC实现全量+增量业务数据导入湖中），在Doris建模时链接湖中的数据。

（5）需求收集

• 与业务方开会，收集业务方的各种需求。在符合战略目标或愿景的前提下，为收集到的各种需求分配优先级，然后根据资源限制（人力资源、资金、开发复杂度）把最高优先级的数量做限制，例如当前把最急需的需求控制在3个以内。

（6）需求调研

• 业务调研
  • 业务调研的流程分三个步骤：
    • 输入调研模板。
    • 针对产品和运营进行调研。
    • 归纳产出：业务过程&数据域。
• 需求分析
  • 需求分析的三个步骤：
    • 输入调研模板，研究报表&数据体系。
    • 与分析师&运营讨论收集信息。
    • 归纳产出：指标体系。
• 数据调研
  • 数据调研需要做好数据探查工作，需要了解数据库类型、数据来源、全量数据情况及数据每年增长情况、更新机制；还需要了解数据是否结构化、是否清洗、是接口调用还是直接访问库、有哪些类型的数据、数据结构是怎样的。
    • 数据开发、模型建设之前，先了解数据结构、数据内容、数据特性，对数据有一个整体把控。
    • 探查一下本次需求能不能实现，怎么实现，有没有隐藏bug，数据质量如何。

（7）产出

• 概念图：业务架构图
  • 各业务模块之间、业务内部子模块之间的交互关系（层级关系、包含关系、平行关系、主次关系）。
• 逻辑图：业务关联（E-R模型+流程图）
  • 概念模型：E-R图（Entity-Relationship Model）
    • 作用：E-R模型用于描述产品或业务内部各模块之间的关系，能帮助快速学习业务逻辑和产品逻辑，也能从中发现业务或产品中存在的问题。
    • 绘制E-R图步骤：
      1. 确定对产品或业务实体有重大影响的实体。例如：用户、订单、商品、优惠券或积分、物料、耗材。
      2. 确定能影响到产品或业务正常运转的关键属性。随着业务或产品发展，可能有一些属性独立出来变成实体，例如“收货地址”。
      3. 确定实体之间的关系。需要多人配合一起讨论，找出实体之间存在的所有联系。
    • E-R图的使用建议：
      1. 在新接触一个业务或产品时，先使用E-R图帮助建立相关的概念，为下一步要绘制的流程图预备知识。
      2. 在落实到新产品或新业务开发时，通过E-R图理清一款产品或一项业务需要哪些功能、服务于哪些用户、需要搭配什么系统。
  • 逻辑模型：流程图（对业务的发展变化过程可视化）
    • 流程图与E-R图的区别：流程图关注的是整件事情的各种处理过程以及各过程之间的逻辑关系和时间顺序，所以流程图关注的是动态的事情，E-R图关注的是最终态的事情。
    • 绘制流程图的六个元素：
      1. 参与者：可以是用户、部门、系统、定时任务。
      2. 活动：做的事情、任务、活动，这些内容是流程图要重点展示的。
      3. 次序、顺序：用箭头表示活动或环节的先后发生顺序和依赖关系。由于有并行的任务，所以有同向的多个箭头；并行之后也可以在某个环节合并成为一个环节，所以有汇合的箭头。
      4. 输入：活动或任务的输入可以是依赖的信息或者上游的任务。依赖的信息举例：为用户推荐商品，就必须依赖用户最近的浏览历史、购买历史。
      5. 输出：每个活动或任务结束后产生的结果。当前活动或流程的输出可以作为下一个流程的输入，可以向多个活动或流程输出结果。
      6. 标准化：就是用标准的符号表示流程图的内容。例如矩形表示活动或流程，圆角矩形表示整个流程图的开始或结束，箭头表示活动之间的顺序，菱形表示数据。
    • 带泳道和阶段的流程图：
      • 当业务流程涉及几个阶段，参与方涉及多人、跨部门，并且需要让每个参与方清楚各自负责的步骤，此时需要带泳道和阶段的流程图。
      • 
      • 
• 物理模型：继概念模型和逻辑模型之后，物理模型的数据库、表映射业务架构。

2. 数据规模测算

数据规模测算

• 1. 根据数据平台的数据特点来预估
  • 数据特点包括数据来源、种类、结构（结构化、半结构化、非结构化）、粒度、时效性。
• 2. 根据存储容量和数据增长速度预估
  • 根据数据平台现有的存储容量和数据增长速度，可以初步预估未来一段时间内的数据规模，以满足业务需求、避免资源浪费和过度投资，合理分配存储、计算和网络带宽资源。
  • 收集历史数据，包括计算资源、存储资源、网络带宽的使用量和峰值，以便掌握业务对资源的需求波动情况，然后进行容量规划和估算。
• 3. 需要考虑到数据质量问题
  • 有质量问题的数据包括：未去重的数据、无效的数据、错误的数据等。这些有问题的数据会影响存储和计算规模。
• 4. 结合业务场景和实际需求进行预估
  • 根据业务场景和实际需求，结合前面三步的分析结果，对数据平台的未来数据规模做预估；同时，要持续监控各种资源的使用情况，以便调整和优化资源的分配。例如，如果业务场景中涉及到海量数据的处理和分析，那么数据平台的存储容量和处理能力就需要相应提高，也就是考虑平台的可扩展性。
• 5. 考虑数据安全和隐私保护问题
  • 需要考虑数据的加密、备份、恢复等方面对存储和处理的制约，还有相关法律法规对数据安全和隐私保护的要求。

任务数评估

• 方法概述——基于历史任务做分析，统计各类数据处理任务的数量波动，从中发现趋势，根据趋势做预估。如果是新建的平台尚未有历史任务，那么用以下方法：根据该平台将要承载的业务需求做预估，例如预估固定报表有几张、制作每张报表所需的数据量是多大、每个报表的加工链路有几个算子、集群的资源是多少，然后在该平台模拟一些数据处理任务，以观察任务运行期间对资源的消耗情况。当发现集群在同时运行XXXX个任务时占满了集群的所有资源，此时的XXXX值可作为最大并发任务数。
• 步骤
  1. 理清数据处理需求：根据数据平台的处理需求以及之前做的数据规模预估结果，粗略算出需要运行的任务类型和数量，包括OLAP任务、批处理任务、流处理任务的数量和任务周期。
  2. 考虑数据来源和多样性：根据数据的来源、格式、大小、频率等，粗略估算需要运行的任务数量和类型。
  3. 根据数据平台的数据处理能力评估：也就是要根据容量评估，具体包括计算资源、存储资源、网络资源等，以确定能够同时运行的任务数量和类型。
  4. 要考虑任务调度和并发控制：这是为了保证所有任务按照预定顺序和优先级运行，避免任务之间的冲突和竞争。
  • 为什么要考虑任务之间的依赖关系和并发控制？第一个原因，如果任务之间的依赖关系处理不当，会导致任务执行效率低或者出现错误，就提高整体的作业数量。第二个原因，如果并发控制不好，会导致任务之间的竞争和冲突，从而降低任务执行的稳定性。

容量评估

• 如何评估
  • 收集历史数据，包括计算资源、存储资源、网络带宽的使用量和峰值，以便掌握业务对资源的需求波动情况，然后进行容量规划和估算。
• 存储资源
  • 单条数据大小 * 日数据量 * 周期 * 副本数。
  • HHD。
  • SSD。
• 机器存储节点数
  • 数据总量 / （单台服务器总磁盘大小 * 0.8）。
• CPU
  • 单台配置推荐64核，CPU和内存之间建议1：2或者1：4。
• 内存
  • 单台推荐128G或256G。
• 网络带宽
  • 10亿级别，千兆网卡可以支持，推荐万兆网卡。
• 大数据机器集群规划

数据特征

• 数据格式
• 数据压缩
• 序列化方式
• 文件类型

产出文档

• CPU内存、核数、单块磁盘大小、挂载数量、机器数量、成本预算相关文档。

3. 技术架构设计

可选的数据平台架构

• Lambda架构：离线数据链路；流式数据链路。
  • 
• Kappa架构：批流一体。
  • Pulsar + Flink。
  • Flink + MPP。
  • 存算一体。
  • 存算分离。
• IOTA架构
  • IOTA大数据架构是一种基于AI生态下的、全新的数据架构模式，这个概念由易观于2018年首次提出。IOTA的整体思路是设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的计算效率，同时满足计算的需要，可以使用各种Ad-hoc Query来查询底层数据。
  • 去ETL化：ETL和相关开发一直是大数据处理的痛点，IOTA架构通过Common Data Model的设计，专注在某一个具体领域的数据计算，从而可以从SDK端开始计算，中央端只做采集、建立索引和查询，提高整体数据分析的效率。
  • Ad-hoc即时查询：鉴于整体的计算流程机制，在手机端、智能IOT事件发生之时，就可以直接传送到云端进入real time data区，可以被前端的Query Engine来查询。此时用户可以使用各种各样的查询，直接查到前几秒发生的事件，而不用在等待ETL或者Streaming的数据研发和处理。
  • 边缘计算（Edge-Computing）：将过去统一到中央进行整体计算，分散到数据产生、存储和查询端，数据产生既符合Common Data Model。同时，也给予Realtime model feedback，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。
• LakeHouse架构：湖仓一体。
  • 仓外挂湖。
  • 湖上建仓。
  • 
  • 湖中建仓。

如何选型

• 1. 考虑数据架构适用的数据处理场景，例如离线数仓、实时计算、实时数仓、批流一体、湖仓一体、DataOps。
• 2. 同一功能的不同框架之间的对比：适用的数据处理场景、更新是否频繁、数据处理（查询或写入）性能、容错性、是否易用、是否要求高并发点查、exactly-once、是否方便运维（包括故障排查）。
• 3. 选定框架或组件之后，做好相关的压力测试（最好做一次全链路压测以提前发现薄弱环节），然后出具压力测试报告。
• 4. 产出：生成《选型建议》，涵盖四项内容：
  • 一、各框架或组件的对比文档。
  • 二、从第3步的压测报告中选取各项关键指标的对比结果，做出选型建议。
  • 三、技术架构图。
  • 四、完整的Demo演示：数据的全链路处理流程演示。

架构实现方式

• Hadoop生态。
• MPP。
• Hadoop + MPP。
• 数据湖 + MPP。

4. 机器节点的规划

集群各节点规划

安装、部署和运维

参数调整

LDAP、权限管理

5. 高可用多机房部署

多机房规划

容灾、备份

数据仓库建设

数据采集模块

采集方式

• 离线定时采集
  • Sqoop。
• 实时采集、增量采集
  • 日志：Flume、Logstash。
  • 数据库。
  • DataX。
  • FlinkCDC。
  • Canal、Maxwell。
  • CloudCanal。
  • TIS。
• 离线、实时、增量采集
  • SeaTunnel。
• 可配置的流任务开发平台（在Web页配置）
  • 对接Kafka满足大部分的流处理需求任务。
  • 例如：埋点数据上报到Kafka之后，只需要在Web页面配置Flink的源topic、字段声明及加工逻辑、sink目标表、数据校验规则、告警规则。

一致性保证（如何确保Exactly Once）

• 框架本身是否已实现
  • Kafka是否已实现、如何实现：Kafka的客户端支持消息写入topic的幂等性。
  • Flink是否已实现、如何实现：
    • 两阶段提交事务。
    • 预写日志事务。
    • LabelID + State + CheckpointInterval flush。
• 流处理任务的监控
  • 数据源端（Kafka）监控指标有哪些：
  • Sink端（湖、仓中的表）监控指标有哪些：

数据仓库建设

• 分成哪几层，每层的功能是什么

  • 分层的意义
    • 隔离原始数据。
    • 不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。不必改一次业务就需要重新接入数据。另外，随着业务的变化，只需要调整底层的数据，对应用层对业务的调整零感知。
    • 清晰数据结构体系。
    • 每一个数据分层都有它的作用域，这样在使用表的时候能更方便的定位和理解。
    • 数据血缘追踪。
    • 由于最终给业务呈现的是一个能直接使用的业务表，但是表的数据来源有很多，如果有一张来源表出问题了，我们希望能够快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低。
    • 减少重复开发和资源浪费。
    • 规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算；清晰明了的结构使得开发、维护的成本降低；减少重复计算和存储的资源浪费。
    • 复杂问题简单化。
    • 将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
    • 数据安全。
    • 通过分层，可以更方便地对不同层，不同的数据模型进行权限管理，特定业务场景下，对不同的开发人员和业务人员屏蔽一些敏感的数据。
  • 每一层的作用
    • ODS：存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区，数据原则上全量保存。
    • DWD：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。数据粒度一般保持和ODS层一样的，并且提供一定的数据质量保证。同时为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。同时在此层会采用明细宽表，复用关联计算，减少数据扫描（逻辑事实表）。
    • DWS：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。（汇总数据层 + 主题宽表）公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
    • DIM：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。维度层的表通常也被称为维度逻辑表。高基数维度数据一般是用户资料表、商品资料表等类似的资料表。数据量可能是千万级或者上亿级别。低基数维度数据一般是配置表，比如枚举值对应的中文含义，比如国家、城市、县市、街道等维表。数据量可能是个位数或者几千几万。
    • ADS：这是应用服务层，一般就直接对接OLAP分析，或者业务层数据调用接口了。这是最顶层，一般都是结果类型数据，可以直接拿去使用或者展示的数据了。也是对数据抽离分析程度最高的一层数据。这一层是需求最明确的一层，根据业务需求来决定数据维度和结果分析。类似代码最外层，接口是相对最固化的。

• 分层原则

  • （1）清晰简洁原则：分层设计应该简洁明了，每个层次的功能和任务应该清晰明确，不重复，避免冗余和混淆。
  • （2）独立可扩展原则：每个层次应该是独立的，可以单独进行扩展和修改，而不会对其他层次造成影响。
  • （3）数据一致性原则：分层设计应该保证数据的一致性和完整性，确保数据在不同的层次之间能够正确地传递和转换。
  • （4）性能和效率原则：分层设计应该考虑到数据的查询和分析性能，合理地设计和构建汇总层，以提高数据的查询速度和分析效率。
  • （5）灵活性和可用性原则：分层设计应该提供灵活的数据查询和报表功能，以满足用户的不同需求和要求。

• 模型选择

  • 维度模型（自下而上）。
  • 星型模型。
  • 雪花模型。
  • 星座模型。
  • ER模型。
  • 3NF。
  • Data Vault模型。
    • Hubs：表示实体或业务概念。
    • Links：表示实体之间的关系。
    • Satellites：存储描述实体和关系的属性数据。
  • Anchor模型。

• 模型设计原则

  • 1. 高内聚，低耦合。
    • 所谓的"高内聚低耦合"是指同一个主题内部高内聚，不同主题之间低耦合。
  • 2. 模型分离。
    • 建立核心模型和扩展模型体系。在业务建设过程中，我们通常会对一些核心业务建设核心模型，在核心模型中的字段主要用来支撑一些通用的主流的核心业务，同时也会针对一些特殊和定制化的少量需求建设扩展模型，在这种情况下，我们应当避免将扩展模型中的字段侵入到核心模型中，以免破坏核心模型架构的可维护性和通用性。
  • 3. 公共处理逻辑下沉。
    • 越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用实现，不要让公共逻辑多处同时存在。
  • 4. 成本与性能平衡。
    • 适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
  • 5. 数据可回滚。
    • 处理逻辑不变，在不同时间可多次运行，多次运行如果结果不一致要明确原因。
  • 6. 一致性。
    • 具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。
  • 7. 命名清晰、可理解。
    • 表命名需清晰、一致，表名易于理解和使用。

• 模型阶段性划分

  • 业务模型
    • 业务模型主要解决业务层面的分解和程序化。
    • （1）划分业务：根据业务部门进行划分，理清部门之间的关系。
    • （2）熟悉业务：了解详细业务逻辑和数据处理逻辑，提供业务/数据处理流程文档、数据源访问信息。
    • （3）明确数据需求：提供页面原型、需求文档、指标口径文档：
      • ①用户查询方式：导出到数据库，导出文件，提供数据服务。
      • ②用户查询频率及数据延迟。
      • ③历史数据保存期限。
    • 
    • （4）项目开发评估：确定项目人员分配、项目周期，评估项目风险。
  • 领域模型
    • 对业务模型进行抽象处理。
    • 运用实体建模法，将业务模型抽象化，合并类似的概念，细化概念。
    • 将业务抽象成实体、事件和说明这三部分，理清实体与实体之间的关联，生成概念模型并整理为ER图。
    • 
    • 
  • 主题域的划分
  • 逻辑模型
    • 将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
    • 实例化每一个抽象的实体，并丰富实体的一些细致的属性。
    • 找出抽象实体间的联系，并将其实例化。
    • 找出抽象事件的关系，并对其进行说明。
    • 表的结构和属性、表之间的关系。
    • 
    • 提供与生产一致版本的数据结构，准确完善的数据字典，符合分析需求的样本数据；并能对样本数据分析中的问题进行及时准确的回复跟踪。并产出逻辑模型文档。
  • 物理模型
    • 解决逻辑模型针对不同关系型数据库的物理化以及性能问题。
    • 数据结构性质、表的存储和压缩。
    • ETL工具。
    • 数仓组件。
    • 
    • 代码开发。
    • 脚本编写。
    • 性能要求。
    • 任务调度。
    • 性能优化。
    • 
    • 业务模型主要解决业务层面的分解和程序化。领域模型是为了建立实体以及它们的属性和关系。如：主题域的划分、维度、事实。逻辑数据模型定义了数据元素的结构，并设置了它们之间的关系。如：表的字段信息、表之间的逻辑关系。物理数据模型描述了数据模型在数据库中具体的实现方式。如：代码设计与开发、性能优化，日志收集，表的存储与压缩格式。

• 建模流程

  • 数据建模是一个“通过良好的结构设计，建设满足要求的数据集合”的过程。
    • 
    • 
    • 
  • 流程
    1. 系统边界关系模型设计。
    • 要做的决策类型有哪些？
    • 决策者感兴趣的是什么问题？
    • 这些问题需要什么样的信息？
    • 要得到这些信息需要包含原有数据库系统的哪些部分的数据？
    2. 事件流产生业务模型设计。
    3. 数据域的划分。
    • 数据分域分为三个步骤：收集、提炼、归纳。
      • 1. 收集：业务数据需求、存量数据梳理。
      • 2. 提炼：业务过程、业务梳理。
      • 3. 归纳：数据域。
    4. 总线矩阵。
    • 
    • 主题域。
    • 业务过程。
    • 维度。
    • 颗粒度。
    • 度量值。
    • 
    5. 明确指标统计。
    • 统一指标命名。
    • 统一指标计算口径。
    • 指标拆解、指标分级。
    • 原子指标。
    • 派生指标。
    • 
    • 一级指标。
      • （1）一级指标（Tier 1 Metrics）：公司战略层面指标。一级指标必须是全公司都认可的、衡量业绩的核心指标。
    • 二级指标。
      • （2）二级指标（Tier 2 Metrics）：业务策略层面指标。二级指标是针对一级指标的路径分析拆解，是流程中的指标。一般是部门领导人所关心的指标。
    • 三级指标。
      • （3）三级指标（Tier 3 Metrics）：业务执行层面指标。三级指标是针对二级指标的路径分析拆解，通常以子流程或个体的方式定义。一般作为问题分析的重要关注点。
    • 衍生指标。
    • 一级指标。
    • 二级指标。
    • 三级指标。
    • 如何拆解。
      • 公式拆解法：是指通过一级指标的计算公式进行二级指标的拆解。
      • 漏斗拆解法：是指通过用户的使用流程或者步骤逐步拆解二级指标。
      • 
      • 维度拆解法：是指将一级指标按照不同维度细分的方式进行拆解。
      • 
    • 指标拆解步骤。
      • 第一步，找到主指标，明确指标定义和计算公式。
      • GMV = 购买人数 X 客单价。
      • 第二步，找到与主指标的直接关系的子指标。核心业务转化流程拆解。这一步也很重要，因为很多指标不止一种拆解方法。到底怎么拆合适呢？要看拆完以后，是否有对应主指标的子指标。如果有的话，就能根据指标变化做改善。如果没有，那拆了也白拆。
        • （1）梳理业务转化流程。
        • 
        • （2）「购买人数」拆解。
        • 购买人数 = 活跃用户数 X 商品详情页触达率 X 加购率 X 订单提交率 X 支付成功率。
        • （3）拆解结果。
        • 
      • 第三步，对子指标再进行继续拆解，同时确认各级指标都有数据采集。这一步是确认拆解是否可以继续进行的关键一步，因为指标的背后是数据采集，如果没有数据采集，那拆解就进行不下去了。（如下图）
        • （1）「活跃用户数」拆解。
        • 活跃用户数 = 新活跃用户人数 + 老活跃用户人数。
        • （2）拆解结果。
        • 
      • 第四步，列出拆解公式，进行数据对比。这里呈现的就是最终结果，可以去进行分析了。
    • 指标生命周期管理。
    • 统一外部数据输出归口。
    • 建立指标字典。
    6. 规范化定义。
    • 词根规范。
    • 行业术语（一般指翻译不太准的）。
    • 数据分析师协作。
    • 业务方协作。
    • 词根评审。
      • 是否必要。
      • 是否存在。
    • 词根维护。
      • id。
      • 所属分类。
      • 英文词根。
      • 中文词根。
      • 使用频率。
      • 数据类型。
      • 长度。
      • 责任人。
      • 评审日期。
    • 数据字典。
      • 用途。
        • 数据字典是各类数据描述的集合 -数据字典是进行详细的数据收集和数据分析所获得的主要结果 -数据字典在数据库设计中占有很重要的地位。
      • 内容。
        • 数据项；数据结构；数据流；数据存储；处理过程。数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。
      • 字典数据表模板。
        • 
      • 字典类型表模板。
        • 
    • 命名规范。
      • 库命名。
      • 表命名。
      • 指标命名。
      • 任务命名。
    • 建模评审规范。
      • 指导理论。
        • 数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性维度和事实。参考阿里OneData建模。
        • 
      • 模型层次。
        • 参考数仓分层逻辑。
      • 实施步骤。
        • 选择已经确定业务进行梳理，了解业务流程（参考产品数据文档）。
        • ER关系：输出ER关系图，了解实体关系，验证数据是否一致 PDM。
        • 现有数据流梳理：输出数据流程图 PDM。
        • 结合提数模型，指标，产品需求文档等，优化目前模型：基于上一步PDM输出优化模型，记录优化点；（数据流跟数据模型结合）。
        • 基于以上文档进行评审，不通过进行迭代。
        • 评审通过后进行开发，上线：开发在目前系统上实施，优先级降低，任务时间戳开。
    • 开发规范。
      • 开发原则。
        • 支持重跑。
        • 数据生命周期合理。
        • 任务迭代不会严重影响任务产出时间。
      • 公共规范。
        • 所有单词小写 单词之间下划线分割（反例：appName 或 AppName） 可读性优于长度 (词根，避免出现同一个指标，命名一致性) 禁止使用 sql 关键字，如字段名与关键字冲突时 +col 数量字段后缀 _cnt 等标识... 金额字段后缀 price 标识 天分区使用字段 dt，格式统一（yyyymmdd 或 yyyy-mm-dd） 小时分区使用字段 hh，范围（00-23） 分钟分区使用字段 mi，范围（00-59） 布尔类型标识：is{业务}，不允许出现空值。
      • SQL编写规范。
        • 多表连接时，使用表的别名来引用列。如 t1.user_id t2.user_name。
        • 表名前面需要加上项目名，一个是比较清晰，另一个是如果需要把该任务整段代码移到其他项目去跑的时候（比如分析查询项目），需要手动加上项目名，否则会报错。
        • 不要出现select * 这样的操作。
        • 增加必要注释，以增强代码的可读性。
      • 层次调用规范。
        • 禁止反向调用。
        • ODS 只能被 DWD 调用。
        • DWD 可以被 DWS 和 ADS 调用。
        • DWS 只能被 ADS 调用。
        • 数据应用可以调用 DWD、DWS、ADS，但建议优先考虑使用汇总度高的
          end