GDPR/隐私合规——用户画像怎么做数据脱敏和权限控制？

-- 画像数据脱敏处理
 
-- 1. 手机号脱敏：只存Hash值，不存明文
SELECT
  user_id,
  MD5(phone_number) AS phone_hash,        -- 用于ID Mapping关联
  CONCAT(LEFT(phone_number,3), '****',
    RIGHT(phone_number,4)) AS phone_mask,  -- 用于展示：138****1234
  -- 不要在画像表里存明文手机号！
FROM ods_user_register;
 
-- 2. IP地址模糊化：只保留前三段
SELECT
  user_id,
  REGEXP_REPLACE(ip_address, '(\\d+)$', '0') AS ip_masked,
  -- 192.168.1.123 -> 192.168.1.0
FROM dwd_user_event;
 
-- 3. GPS坐标降精度：保留到城市级别
SELECT
  user_id,
  ROUND(latitude, 1) AS lat_city,   -- 小数点1位 = 约11公里精度
  ROUND(longitude, 1) AS lng_city,  -- 够定位到城市，不会定位到个人
FROM dwd_user_location;

-- 通过Hive视图实现列级权限控制
 
-- 运营看到的画像视图（脱敏版）
CREATE VIEW v_user_profile_ops AS
SELECT
  MD5(user_id) AS user_id_hash,   -- 脱敏的用户ID
  gender, age_group, country,      -- 标签值可以看
  value_level, lifecycle_stage,
  login_cnt_7d, total_amount_usd
  -- 注意：没有phone_number, email, device_id
FROM ads_user_profile
WHERE dt = '${bizdate}';
 
-- 给运营角色授权这个视图，而不是授权原始表
GRANT SELECT ON v_user_profile_ops TO ROLE ops_role;

被遗忘权：用户要求删除数据怎么办

GDPR第17条规定用户有「被遗忘权」——用户可以要求删除自己的所有数据。这对画像系统的影响很大，因为用户数据散布在ODS、DWD、DWS、ADS各层，还同步到了Redis和ES。

# 用户数据删除流程
def delete_user_data(user_id):
    """
    GDPR被遗忘权：删除指定用户的所有画像数据
    必须在收到请求后30天内完成
    """
    # 1. 记录删除请求（审计日志）
    log_deletion_request(user_id, request_time=datetime.now())
    
    # 2. 删除各层Hive数据（用INSERT OVERWRITE过滤掉该用户）
    for table in ['ads_user_profile', 'dws_user_active_7d',
                  'dwd_user_event', 'dim_user_base']:
        spark.sql(f"""
          INSERT OVERWRITE TABLE {table} PARTITION (dt)
          SELECT * FROM {table} WHERE user_id != '{user_id}'
        """)
    
    # 3. 删除Redis中的画像数据
    redis.delete(f'user:profile:{user_id}')
    redis.delete(f'user:realtime:{user_id}')
    
    # 4. 删除ES中的数据
    es.delete_by_query(index='user_profile', body={
        'query': {'term': {'user_id': user_id}}})
    
    # 5. 记录删除完成（审计日志）
    log_deletion_complete(user_id, complete_time=datetime.now())

技术难点：Hive是不可变存储，删除单条数据需要INSERT OVERWRITE整个分区——代价很高。如果画像表有365天的分区，删除一个用户要重写365个分区。优化方案：①只删除最近N天的分区（比如90天），更早的分区数据已经过了保留期限会自动清理；②用Delta Lake/Iceberg做存储层，原生支持DELETE操作，不需要全分区重写。

面试高频追问

追问一：GDPR对画像系统影响最大的是什么？

影响最大的是三个方面：①合法基础——做画像必须有用户同意或合法利益作为法律依据，不能偷偷做；②数据最小化——只收集业务必需的数据，不能「先收集了以后再想用途」；③被遗忘权——用户要求删除时必须能在30天内删干净。对技术架构来说，最大的影响是被遗忘权——需要在所有存储系统中追踪和删除特定用户的数据，这要求数据血缘必须清晰。

追问二：出海业务怎么区分不同地区的合规要求？

我们的做法是按用户的注册国家/地区做合规分区。欧洲用户（GDPR覆盖的EEA国家）执行最严格的标准：明确同意才能做画像、必须支持数据导出和删除、数据存储在欧洲Region。美国用户按CCPA标准：需要提供Opt-Out选项，允许用户拒绝个人信息出售。其他地区按公司统一的隐私政策处理。技术上在画像表里加一个compliance_region字段，下游处理时按Region做差异化。

追问三：匿名化和脱敏有什么区别？

脱敏是隐藏部分信息但仍可能通过组合还原身份（比如手机号中间四位用星号代替，但前后三位+四位仍可能识别），是一种弱保护。匿名化是彻底去除所有可识别信息，无法还原身份（比如只保留聚合统计数据），是一种强保护。GDPR认为匿名化数据不受GDPR约束，但脱敏数据仍然受约束。所以聚合后的群体画像不受GDPR约束，但用户级别的画像标签即使脱敏了也受约束。

实战踩坑

我在某出海硬件品牌遇到过一次合规事件：产品团队直接把用户的精确GPS坐标存入了画像表，用于分析用户的线下活动轨迹。被欧洲的合规审计发现后，被要求在2周内修复——删除所有精确GPS数据，改为只存城市级别的模糊位置。

修复过程很痛苦：要回溯3个月的画像数据，把所有GPS字段降精度处理。因为画像表很大（千万用户 x 90天分区），全量重写花了2天时间。

教训：数据合规必须在设计阶段就考虑，不能事后补救。GPS坐标在ODS层采集时就应该降精度，不应该让明文精确坐标进入DWD和ADS层。数据一旦写入了多个系统（Hive+Redis+ES），回溯清理的成本远高于源头控制的成本。

总结

画像合规三件事：数据分级（L1高敏感到L4无敏感）、脱敏处理（Hash/掩码/模糊化）、权限控制（角色+视图+列级授权）。被遗忘权的技术实现要考虑多存储系统的数据清除。核心原则是「最小必要」——源头控制远好于事后补救。面试时能讲出合规改造的真实经历和踩坑，说明你做过的是真正面向生产的画像系统。

最后一篇来做一个收尾：用户画像项目的技术选型怎么讲？为什么选这套方案？

你们的画像系统做过合规改造吗？最大的挑战是什么？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长