离线数仓开发基础，开发语言（Hive SQL，Shell、Python），开发环境隔离，完整开发流程（面试高频追问）

在数据仓库开发中，HiveSQL是核心开发语言，主要用于数据清洗、转换和汇总。

Shell脚本（15%）用于调度任务封装，Python（10%）处理复杂业务逻辑和质量校验。

数仓表数据存储在HDFS上，表结构元数据存放在MySQL等关系型数据库中，通过Hive进行管理。

开发与生产环境严格隔离，通常分为开发、测试和生产三层，通过数据库名、HDFS目录和权限控制实现隔离。

开发人员在生产环境仅需只读权限（SELECT），数据修复通过调度系统或DBA执行，确保安全可追溯。

完整开发流程包括本地IDE编写、调试验证、Git提交、测试部署和生产调度执行，保障代码质量和数据安全。

数仓里写的是Hive sql 还是什么呢

核心答案：Hive SQL 是主力，但不是全部

在离线数仓中，90% 以上的代码是 Hive SQL，但完整的数据开发工作远不止写 SQL。

1. 日常写的代码（按占比排序）

代码类型	占比	具体内容	使用场景
Hive SQL	70%	DDL（建表）、DML（ETL 清洗/转换/汇总）、DQL（复杂查询分析）	数据分层加工（ODS→DWD→DWS→ADS）、监管报表逻辑
Shell 脚本	15%	调度任务封装、参数传递、上下游依赖判断、重试逻辑、邮件告警	包裹 Hive SQL，让调度系统（如 DolphinScheduler）能调用
Python	10%	数据质量校验、异常检测、复杂业务逻辑（如机器学习预处理）、API 调用	不适合 SQL 实现的场景，比如调用第三方接口、复杂循环、正则匹配复杂的文本清洗
Spark SQL / PySpark	5%	用 Spark 引擎执行 SQL（比 Hive 快），或写 PySpark 做复杂数据处理	性能要求高的场景，或实时/准实时任务

2. 为什么 Hive SQL 是绝对主力？

门槛低：数仓团队绝大多数成员都会 SQL，培训成本低
生态成熟：Hive 对 SQL 的支持越来越完善（支持 CTE、窗口函数、UDF 等），能覆盖 95% 以上的 ETL 场景
维护方便：SQL 比 Java/Python 更易读，新人上手快，代码评审容易
监管友好：监管报送逻辑用 SQL 写，业务人员也能看懂大致逻辑（虽然不写但能 review）

3. 那 Shell 和 Python 具体写什么？

Shell 脚本示例（调用 Hive SQL）：

bash

#!/bin/bash
# 这是调度系统每天凌晨3点调用的脚本

bizdate=$1   # 从调度系统传入业务日期

# 执行 Hive SQL（通过 -e 或 -f）
hive -e "
INSERT OVERWRITE TABLE dwd_user_daily PARTITION(dt='$bizdate')
SELECT user_id, user_name, phone, update_time
FROM ods_user_daily
WHERE dt='$bizdate';
"

# 检查执行状态
#if [ $? -eq 0 ];
#报错：Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.shellcheckSC2181
#这是一个 Shell 脚本的静态检查警告（shellcheck SC2181），提示你不要通过 $? 间接检查命令的退出状态，而是应该直接使用命令本身作为条件。

#用变量保存 $? 后，shellcheck 就不会报 SC2181 了，因为 $? 必须在命令执行后立即捕获，否则会被后续命令覆盖。
# 中间可以插入其他逻辑
ret=$?
if [ $ret -eq 0 ]; then
    echo "ETL 成功" >> /log/etl.log
else
    echo "ETL 失败，触发告警" >> /log/etl.log
    python /script/send_alert.py "ETL任务失败"
fi

Python 示例（数据质量校验）：

python

#!/usr/bin/env python
# 校验今日数据量是否异常

import subprocess
from pyhive import hive

def send_alert(message):
    """发送告警"""
    print(f"[ALERT] {message}")
    subprocess.run(["python", "/script/send_alert.py", message])

#bizdate 建议通过命令行参数传入（sys.argv[1]），和前面的 Shell 脚本保持一致。
# 从调度系统获取业务日期（示例写死，实际可从参数或环境变量获取）
bizdate = "2026-06-17"

print(f"开始处理业务日期：{bizdate}")
#生产环境中建议加上 try...except 捕获数据库连接异常，避免脚本因连接失败而崩溃。
try:
    conn = hive.connect(host='hive-server', port=10000)
except Exception as e:
    print(f"数据库连接失败: {e}")
    exit(1)

cursor = conn.cursor()
cursor.execute(f"SELECT COUNT(*) FROM dwd_user_daily WHERE dt='{bizdate}'")
today_count = cursor.fetchone()[0]

if today_count < 1000000:   # 阈值设为100万
    send_alert(f"数据量异常，今日只有 {today_count} 条")

cursor.close()
conn.close()

4. 那你们用的是什么执行引擎？

Hive 本身是个翻译器，它把 SQL 翻译成 MapReduce/Spark/Tez 作业去跑。

场景	用的引擎
你们银行项目用的是什么引擎？	我们用的 Hive on Spark（比 Hive on MR 快 3-5 倍）
为什么不用 Hive on MR？	MR 每次都要落盘，IO 瓶颈太严重，银行数据量大（日增几亿条），MR 跑不动
那什么时候用纯 Hive？	小表测试、数据量不大的临时查询用 Hive on MR；生产大任务全部切到 Hive on Spark

5. 面试时怎么答

“在离线数仓中，核心开发语言是 Hive SQL，占比大概 70% 以上。数据清洗、转换、汇总、监管报表加工都是用 Hive SQL 实现。

除此之外，我们会用 Shell 脚本 封装 SQL，交给 DolphinScheduler 等调度系统执行，并在脚本里做状态判断和重试逻辑。

Python 主要用在数据质量校验、复杂文本清洗、API 调用等 SQL 不方便实现的场景。

执行引擎方面，我们用的是 Hive on Spark，比传统的 Hive on MapReduce 快很多，能保证每天大批量 ETL 任务在凌晨跑完。”

6. 如果面试官问“那你们会写 Java 吗？”

“数仓开发团队通常不直接写 Java。

Hive 的 UDF（自定义函数）有时候需要 Java 写，但如果有现成的 UDF 库，我们会优先复用。

整体来说，数仓开发的核心技能栈是 SQL + Shell + Python，而不是 Java。”

7. 一句话总结

“数仓里写的是 Hive SQL，配合 Shell 做调度封装，Python 做质量校验和复杂逻辑补充。执行引擎是 Hive on Spark。”

数仓的表存在哪，HDFS吗

数仓的表最终是存在 HDFS 上的，但中间还有一层“映射关系”需要理清楚。

一句话先回答你

是的，Hive 数仓的表数据最终是以文件形式存储在 HDFS 上的。

但 Hive 本身只存“表结构”（元数据），不存数据；

真正的数据文件在 HDFS 的指定目录下。

1. 拆开讲：Hive 的“两层结构”

层次	存什么	存在哪	作用
元数据（Metastore）	表名、字段、分区、存储路径、数据类型等	关系型数据库（如 MySQL）	Hive 启动时读取这些信息，知道表结构长什么样
数据文件	表的实际数据（行记录）	HDFS（如 `/user/hive/warehouse/db_name/table_name/`）	真正存放数据的地方，查询时 Hive 从这里读文件

举个例子：
你在 Hive 里建了一张表：

sql

CREATE TABLE dwd_user (
    user_id STRING,
    user_name STRING,
    phone STRING
) PARTITIONED BY (dt STRING);

元数据：MySQL 里会记录“表名叫 dwd_user，有三个字段 user_id/user_name/phone，分区字段是 dt，存储路径是 /user/hive/warehouse/dwd_user/”
数据：HDFS 上会生成目录 /user/hive/warehouse/dwd_user/dt=2026-06-17/，里面存着这个分区的数据文件（可能是 ORC、Parquet 或 TextFile 格式）

2. 那表数据具体在 HDFS 的什么位置？

默认情况下，Hive 的表数据存储在 HDFS 的 /user/hive/warehouse/ 目录下。

表类型	HDFS 路径示例
内部表	`/user/hive/warehouse/db_name/table_name/`
外部表	建表时指定的任意 HDFS 路径（如 `/data/logs/`）
分区表	`/user/hive/warehouse/db_name/table_name/dt=2026-06-17/`
分桶表	分区目录下还有多个文件（如 `00000_0`、`00001_0`）

你可以用 HDFS 命令直接查看：

bash

hdfs dfs -ls /user/hive/warehouse/dwd_user/dt=2026-06-17/

3. 那“表存在哪里”这个问题，面试时怎么答最全面？

Hive 表的数据最终是存储在 HDFS 上的，但 Hive 本身并不存储数据，它只存储元数据（表结构、分区信息、存储路径等），这些元数据存放在 MySQL 等关系型数据库中。

举个例子，我在 Hive 里建一张分区表，Hive 会在 MySQL 里记录这张表的元数据，同时在 HDFS 的 /user/hive/warehouse/ 目录下创建对应的数据目录，实际的数据文件（如 ORC 文件）就放在这个目录下。查询时，Hive 会先从 MySQL 读取元数据，然后去 HDFS 上读取数据文件进行运算。

所以，表数据在 HDFS，表结构在 MySQL，Hive 是中间层，负责把 SQL 翻译成对 HDFS 文件的读写操作。

4. 两种表类型（面试补充加分项）

表类型	数据存储位置	删除表时数据是否删除	适用场景
内部表（Managed Table）	Hive 默认路径 `/user/hive/warehouse/`	会删除	临时表、测试表、数据生命周期由 Hive 管理
外部表（External Table）	建表时指定的任意 HDFS 路径（如 `/data/logs/`）	不会删除，只删除元数据	生产表、共享数据源（如日志、上游系统推送的数据）

实际生产：银行数仓中，ODS 层通常建外部表（数据由上游系统管理，Hive 只读不删），DWD/DWS/ADS 层建内部表（数据由 Hive 管理，便于统一维护）。

5. 一句话总结（背下来）

数仓的表数据在 HDFS 上，表结构（元数据）在 MySQL 里，Hive 是连接两者的桥梁。生产上 ODS 层用外部表，DWD/DWS/ADS 层用内部表。

如果面试官追问：“那 Hive 内部表和外部表的性能有区别吗？” 需要我帮你准备吗？😊

不是都信创改造了，怎么还再用MySQL。表数据在 HDFS，表结构在 MySQL

要回答这个问题，关键在于区分清楚：信创改造替换的是哪个“库”？业务数据库和Hive元数据库是两个东西。

信创改造，本质上是把原来跑在国外的、不可控的软件和硬件，换成国内自主研发、安全可控的。这个大方向是确定的。

为什么“元数据还在用MySQL”？

你简历里提到的“从MySQL迁移至GBase或GoldenDB”，正是信创改造的核心动作之一。但在现实中，这个改造不是一刀切的，尤其在Hive的元数据层面。

这背后有好几个很现实的原因：

元数据是“老大难”：Hive Metastore就像整个数据仓库的“大脑”，记录着所有表在哪里、叫什么、有什么字段。它太核心了，动它就等于给飞行中的飞机换引擎，风险极高。
MySQL停服带来的信创压力：你的质疑非常合理，因为MySQL 5.7在2023年已经停止官方支持，存在安全漏洞无法修复的风险，这本身就是信创改造的巨大驱动力。很多企业正在被这个问题倒逼着改造。
“先外围，后核心”的现实路径：国企的信创改造普遍采取“逐步替换”的策略。先替换业务数据存储（比如你说的GBase、GoldenDB），因为Hive的元数据太核心，往往会放在改造的后期。你看到的，可能正是一个“改造进行中”的状态。
国产数据库的兼容性正在解决这个问题：改造之所以难，是因为过去Hive官方支持的元数据库主要是MySQL、Oracle等几种。但现在，像达梦这样的国产数据库，已经可以通过配置（甚至模拟Oracle模式）来支撑Hive元数据了，这在一些政务大数据项目中已有实践。这说明技术壁垒正在被打破。

面试时可以这样回答（层层递进版）

“这个问题问得很深。您提到的信创改造和我说的元数据库MySQL不矛盾。
首先，信创改造确实在发生，比如我项目里就把MySQL的业务数据迁到了GBase/GoldenDB。
其次，MySQL停服是真实风险，所以替换势在必行。但我们当时采用的是先外围、后核心的稳妥策略，先把业务数据的存储换了，而Hive的元数据库因为涉及所有表的核心定义，迁移风险更高，因此会放在更靠后的阶段，这是个逐步替换的过程。
最后，其实现在国产数据库也在解决这个问题，比如达梦就可以通过配置支持Hive元数据了，这印证了‘元数据库信创化’是可行的，只是需要时间窗口。”

Hive SQL 用什么写，是有编辑器还是写在Linux中

这个问题问得非常实在！很多初级开发者都会困惑“代码到底写在哪”，我来帮你把真实生产环境中的完整工具链讲清楚。

核心答案：几种方式都有，看场景

Hive SQL 的编写和执行，根据开发阶段和任务类型不同，会用不同的工具。

第一层：临时查询 / 调试（Ad-hoc Query）

场景：查一下昨天分区有多少条数据、验证一下某个SQL逻辑对不对、临时取数。

工具：

工具	怎么用	优点	场景
Hive CLI	直接在 Linux 终端输入 `hive -e "SELECT * FROM table"`	最快，适合简单查询	查数据量、看表结构
Beeline	`beeline -u "jdbc:hive2://..." -n username -p password`	HiveServer2 的 JDBC 客户端，支持多用户认证	生产环境访问（比 Hive CLI 更安全）
Hue / Zeppelin	浏览器打开 Web 页面，在 Notebook 里写 SQL	界面友好、可视化、支持图表	数据分析师查数、快速看报表

生产中实际操作：我们一般用 Beeline 连生产环境（因为有 Kerberos 认证），用 Hue 做临时查询（界面方便，不用记命令）。

示例（Beeline 登录）：

bash

beeline -u "jdbc:hive2://hive-server:10000/default" -n your_name -p your_pwd
> SELECT COUNT(*) FROM dwd_user WHERE dt='2026-06-17';

第二层：ETL 任务开发（写完整的 SQL 脚本）

场景：写一个完整的 ETL 脚本（比如 ODS→DWD 的清洗逻辑），需要保存、版本管理、提交到调度系统。

工具：

工具	怎么用	优点	场景
IDE（DataGrip / DBeaver / Navicat）	在本地电脑上连 Hive，写 SQL、执行、调试	有语法高亮、自动补全、错误提示，效率高	开发阶段写复杂 SQL
VS Code + 插件	安装 Hive/SQL 插件，连 HiveServer2	轻量级，配合 Git 做版本管理	开发+版本控制
直接在 Linux 上写 .sql 文件	`vim /etl/script/ods_to_dwd.sql`，然后 `hive -f` 执行	最原始，但调度系统最终执行的就是这些文件	生产部署、调度任务

生产中实际操作：我们在本地用 DataGrip 或 DBeaver 连开发环境的 Hive，写 SQL、调试、优化；确认没问题后，把 SQL 保存成 .sql 文件，传到 Linux 服务器上，交给调度系统（如 DolphinScheduler）定时执行。

第三层：生产调度任务（上线部署）

场景：每天凌晨自动跑的 ETL 任务，已经部署到生产环境。

工具链：

环节	用什么	说明
SQL 脚本存放	Linux 服务器上的 `.sql` 文件（如 `/etl/dwd/user_dwd.sql`）	调度系统直接调用
调度执行	DolphinScheduler / Airflow / Azkaban	定时触发，调用 Shell 脚本 → Shell 执行 `hive -f /path/script.sql`
日志查看	Linux 上 `tail -f /log/etl.log`，或调度系统的 Web 界面	看任务成功/失败、报错信息

完整调度流程：

bash

# DolphinScheduler 每天凌晨 3 点调用这个 Shell 脚本
#!/bin/bash
bizdate=$1   # 调度系统传入日期

# 执行 Hive SQL
hive -f /etl/dwd/user_dwd.sql --hivevar dt=$bizdate

# 检查执行状态
if [ $? -eq 0 ]; then
    echo "ETL 成功，日期：$bizdate" >> /log/etl.log
else
    echo "ETL 失败，日期：$bizdate" >> /log/etl.log
    python /script/send_alert.py "ETL 任务失败"
fi

面试时怎么答

“Hive SQL 的编写和执行，根据开发阶段不同会用不同工具：

开发阶段，我会用 DataGrip 或 DBeaver 这类数据库客户端连到开发环境的 Hive，写 SQL 调试，有语法高亮和错误提示，效率很高。

临时查询，我会用 Beeline 命令行或 Hue Web 界面，快速查数据、验证逻辑。

生产部署，SQL 脚本会保存成 .sql 文件放在 Linux 服务器上，由 DolphinScheduler 等调度系统定时触发执行，执行日志在 Linux 上查看。

所以不是单一工具，而是开发用 IDE，调试用命令行，生产用调度系统，三者配合。”

补充一句（面试加分）

“我们所有的 SQL 脚本都通过 Git 做版本管理，每次修改都有记录。

发布到生产环境时，先提交 Git 仓库，再从仓库拉取到 Linux 服务器，保证代码可追溯。”

一句话总结

“开发时用 DataGrip 写，调试用 Beeline/Hue 查，生产时存成 .sql 文件由调度系统跑。”

Hive 的开发环境和生产环境是分开的吗？怎么做隔离的

这个问题问得非常专业,直接关系到数据安全、代码质量和生产稳定性,是面试官很看重的工程化能力。我帮你把完整的答案整理好。

核心答案：是的,必须分开,而且通常分三层环境

在生产级数仓中,开发环境和生产环境严格隔离是最基本的要求。

银行场景下更是如此——开发人员的误操作(比如 DROP TABLE)如果发生在生产环境,后果不堪设想。

1. 环境分层(三套环境)

环境	用途	数据量	访问权限
开发环境(Dev)	写SQL、调试逻辑、验证字段	小数据集(采样或脱敏)	开发人员可读写
测试环境(UAT/Test)	模拟生产跑批、验证调度依赖、性能测试	中等规模(近三个月脱敏数据)	测试人员+开发负责人
生产环境(Prod)	正式跑批、对外提供数据	全量真实数据	严格限制,只有调度系统账号和DBA可写,开发人员只读

中小团队可能没有独立的测试环境,但开发和生产至少是分开的,这是底线。

2. 怎么做到隔离?(四种隔离手段)

隔离维度	做法	效果
Hive 数据库隔离	同一套 Hive 集群里建不同的数据库:`db_dev`、`db_test`、`db_prod`	逻辑隔离,表名不会冲突,访问权限可以分开控制
HDFS 目录隔离	开发数据存在 `/user/hive/warehouse/dev/` 下,生产在 `/user/hive/warehouse/prod/`	物理路径分开,即使误操作也不会覆盖生产数据文件
权限控制(Ranger/Sentry)	开发账号只能读写 `dev` 库,对 `prod` 库只有 `SELECT` 权限,不能 `DROP`/`INSERT OVERWRITE`	防止开发人员误删生产表
调度系统隔离	开发任务在开发调度机上跑,生产任务在生产调度机上跑,互不干扰	避免开发测试任务触发生产告警或占用生产资源

3. 实际生产中的操作流程

开发人员的完整流程：

bash

# Step 1: 在 Dev 环境写 SQL,用开发数据验证
-- 连接 Dev Hive
use dev_db;
-- 写逻辑,调试,确认结果正确
INSERT OVERWRITE TABLE dev_db.dwd_user_daily PARTITION(dt='2026-06-19')
SELECT ... FROM dev_db.ods_user_daily WHERE dt='2026-06-19';

# Step 2: 验证通过后,提交 Git,走代码评审
git add /etl/script/user_dwd.sql
git commit -m "新增用户DWD层清洗逻辑"
git push origin dev

# Step 3: 发布到测试环境,用测试数据跑一次
# （运维或负责发布的人员操作）
hive -f /etl/script/user_dwd.sql --hivevar env=test --hivevar dt=2026-06-19

# Step 4: 测试通过后,发布到生产环境
# （只有运维或调度系统账号能操作,开发人员没有写入权限）
hive -f /etl/script/user_dwd.sql --hivevar env=prod --hivevar dt=${bizdate}

4. SQL 脚本里怎么区分环境?

一种常见的做法是在 SQL 脚本中用变量控制库名：

sql

-- user_dwd.sql
-- 环境变量: ${env} = dev / test / prod

INSERT OVERWRITE TABLE ${env}_db.dwd_user_daily PARTITION(dt='${dt}')
SELECT 
    user_id,
    user_name,
    phone,
    update_time
FROM ${env}_db.ods_user_daily 
WHERE dt = '${dt}';

调度系统传入不同的 env 参数,SQL 就能跑在不同环境的库上,代码完全复用。

5. 你们银行项目具体怎么做的?

“我们当时用了一套 Hive 集群,但通过数据库名做了隔离：

ods_xxx / dwd_xxx 是生产库

ods_xxx_dev / dwd_xxx_dev 是开发库

开发人员在自己的 Dev 库上调试,确认无误后,将 SQL 脚本提交到 Git 仓库,然后由调度系统(DolphinScheduler)通过不同的 --hivevar 参数分别跑测试和生产。

权限上,我们用了 Apache Ranger 做细粒度控制：开发账号对生产表只有 SELECT 权限,不能 DROP 或 INSERT OVERWRITE,防止误操作。”

6. 面试时怎么答

“是的,开发环境和生产环境必须严格隔离,我们通常分三套：开发、测试、生产。

隔离手段主要有四个层面：

Hive 数据库隔离：建不同的库,如 dev_db 和 prod_db;

HDFS 目录隔离：开发和生产数据存在不同路径下;

权限控制：开发人员对生产库只有只读权限,不能删表或覆盖数据;

调度系统隔离：开发任务和跑批任务使用不同的调度配置。

开发人员在 Dev 环境写完 SQL 后,通过 Git 提交代码,运维或调度系统用不同的环境变量发布到测试和生产,保证生产环境只跑验证过的代码。”

7. 一句话总结

开发环境用来验证逻辑,生产环境用来正式跑批,通过数据库名隔离 + 权限控制 + 调度系统变量实现三层隔离,保证生产数据的安全和稳定。

那如果开发人员需要在生产环境查数据验证怎么办？只读权限够用吗？

直接回答：只读权限完全够用，而且这是标准做法

开发人员在生产环境只需要只读权限（SELECT），不需要写入权限。验证数据、排查问题都可以通过只读查询完成。

1. 开发人员在生产环境做什么？

操作	是否需要写权限	说明
查数据量、看样本数据	❌ 不需要	`SELECT COUNT()`、`SELECT LIMIT 100`
验证报表结果对不对	❌ 不需要	`SELECT SUM(amount) FROM ads_table WHERE dt='2026-06-19'`
排查数据异常（为什么少了100万）	❌ 不需要	`SELECT dt, COUNT(*) FROM table GROUP BY dt`
看表结构、分区信息	❌ 不需要	`DESC table`、`SHOW PARTITIONS table`
修改数据、修复错误	✅ 需要	`INSERT OVERWRITE`、`UPDATE`、`DELETE`

结论：95% 以上的日常验证工作，只读权限就能完成。真正需要写操作的场景只有“数据修复”，那应该由运维/调度系统账号或DBA来操作，而不是开发人员直接执行。

2. 如果查出来数据不对，开发人员怎么修？

正确的流程（开发人员不能直接写生产）：

text

开发人员发现生产数据有问题
    ↓
在开发环境定位问题（查开发数据验证逻辑）
    ↓
修复 SQL 脚本
    ↓
提交 Git + 代码评审
    ↓
在测试环境跑一遍验证
    ↓
通知运维/调度系统负责人
    ↓
运维通过调度系统重跑生产任务（使用修复后的脚本）

关键点：开发人员不直接操作生产数据，而是通过脚本修复 + 调度系统执行的方式完成数据修复。这样所有操作都有日志记录，可追溯、可回滚。

3. 那如果紧急情况（比如监管报送马上要交，数据出错了）怎么办？

银行场景下，紧急修复确实存在。但即使是紧急情况，也有规范流程：

做法	是否推荐	说明
开发人员直接连生产执行 `INSERT OVERWRITE`	❌ 不推荐	风险太高，万一写错条件会把整张表清空
开发人员写好修复脚本，提交 DBA/运维审核后执行	✅ 推荐	有审核、有备份、可回滚
通过调度系统重跑修复任务	✅ 推荐	调度系统有日志、有告警、可追溯

如果一定要让开发人员有写入权限（极少数情况），至少要满足：

操作前备份表（CREATE TABLE backup_table AS SELECT * FROM target_table）
限制只能操作特定分区（如 WHERE dt='2026-06-19'），不能全表覆盖
操作后立即撤销写权限

4. 面试时怎么答（完整版）

“开发人员在生产环境查数据验证，只读权限完全够用。

我们日常验证都是通过 SELECT 查询来完成——查数据量、查汇总结果、查样本数据，这些都只需要只读权限。

如果发现数据有问题，开发人员不直接在生产环境改数，而是在开发环境修复 SQL 脚本，提交 Git 走代码评审，然后由调度系统重新跑批，或者由 DBA/运维 执行修复脚本。这样所有操作都有日志记录，可追溯、可回滚。

银行场景下，监管报送的数据准确性要求极高，不允许开发人员随意在生产环境写数据，这是保障数据安全的基本红线。”

5. 补充一句

“我们会在生产环境给开发人员开一个只读账号，权限仅限于 SELECT，不能 DROP、INSERT、UPDATE、DELETE。同时通过 Ranger 做细粒度权限控制，比如只允许查询特定库、特定表，不能访问客户敏感字段（如身份证号、手机号），既保证开发人员能查数验证，又保证数据安全和合规。”

6. 一句话总结

开发人员在生产环境只需要只读权限，查数据验证完全够用。修复数据通过调度系统或 DBA 执行，不直接写生产，保证安全可追溯。

转载自CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/Irene1991/article/details/162118437

离线数仓开发基础，开发语言（Hive SQL，Shell、Python），开发环境隔离，完整开发流程（面试高频追问）

数仓里写的是Hive sql 还是什么呢

核心答案：Hive SQL 是主力，但不是全部

1. 日常写的代码（按占比排序）

2. 为什么 Hive SQL 是绝对主力？

3. 那 Shell 和 Python 具体写什么？

4. 那你们用的是什么执行引擎？

5. 面试时怎么答

6. 如果面试官问“那你们会写 Java 吗？”

7. 一句话总结

数仓的表存在哪，HDFS吗

一句话先回答你

1. 拆开讲：Hive 的“两层结构”

2. 那表数据具体在 HDFS 的什么位置？

3. 那“表存在哪里”这个问题，面试时怎么答最全面？

4. 两种表类型（面试补充加分项）

5. 一句话总结（背下来）

不是都信创改造了，怎么还再用MySQL。表数据在 HDFS，表结构在 MySQL

为什么“元数据还在用MySQL”？

面试时可以这样回答（层层递进版）

Hive SQL 用什么写，是有编辑器还是写在Linux中

核心答案：几种方式都有，看场景

第一层：临时查询 / 调试（Ad-hoc Query）

第二层：ETL 任务开发（写完整的 SQL 脚本）

第三层：生产调度任务（上线部署）

面试时怎么答

补充一句（面试加分）

一句话总结

Hive 的开发环境和生产环境是分开的吗？怎么做隔离的

核心答案：是的,必须分开,而且通常分三层环境

1. 环境分层(三套环境)

2. 怎么做到隔离?(四种隔离手段)

3. 实际生产中的操作流程

4. SQL 脚本里怎么区分环境?

5. 你们银行项目具体怎么做的?

6. 面试时怎么答

7. 一句话总结

那如果开发人员需要在生产环境查数据验证怎么办？只读权限够用吗？

直接回答：只读权限完全够用，而且这是标准做法

1. 开发人员在生产环境做什么？

2. 如果查出来数据不对，开发人员怎么修？

3. 那如果紧急情况（比如监管报送马上要交，数据出错了）怎么办？

4. 面试时怎么答（完整版）

5. 补充一句

6. 一句话总结

评论

评论列表

微信小程序

QQ小程序

关于作者