06-用户画像 + es映射+写入数据

es映射

创建用映射表

外部表删除时不会删除行数据,只删除元数据
内部表数据会全部删除
一下创建的是外部表

-- 创建映射表,指向es
create external table db_ods.es_users(
    id int,
    username string,
    gender string
)stored by 'org.elasticsearch.hadoop.hive.EsStorageHandler'
tblproperties(
    'es.nodes' = '192.168.88.166:9200',
    'es.index.auto.create' = 'true',
    'es.resource' = 'es_users',
    'es.mapping.name' = 'id:id,username:username,gender:gender',
    'es.index.refresh_interval' = '-1',
    'es.index.number_of_replicas' = '0'
    );

启动es服务
su es
cd
elasticsearch -d

将数据映射到es

-- 将数据写入es中,会在es上创建一个es.resource指定索引库
-- into 追加
-- overwrite 是覆盖
-- 向映射表中插入数据
insert into db_ods.es_users select id,username,gender from db_ods.tbl_users;

或者cd 到当前目录下使用下面的命令运行

hive -f sql文件

es 语法:

语法格式

  • es.nodes 表示es的节点,多个用“,”分开;
  • es.index.auto.create 表示如果索引不存在自动创建;
  • es.index.number_of_replicas 表示指定副本分片存储的数量 0-副本不存数据
  • es.index.refresh_interval 表示内存数据刷新时间-1表示时间不是1s,而是es会根据写入数据情况自己刷新
  • es.resource 表示指定的索引和类型;
  • es.mapping.name 表示其他字段的对应(可以不写,插入时按顺序依次对应即可);
  • es.batch.write.retry.count 表示数据写入失败时重试次数
  • es.batch.write.retry.wait 表示数据写入重试等待时间

向es中写入数据

from pyspark.sql import SparkSession

ss = SparkSession.builder.getOrCreate()

df = ss.createDataFrame([[1,'张三22222',20,'男']],schema='id int,name string,age int,gender string')
df.show()

# 将数据写入es
options={
    'es.nodes':'192.168.88.166:9200',
    'es.resource':'tf_tb_user',
    'es.mapping.id':'id',
    'es.write.operation':'upsert', # 配合mapping一起使用
}
# mode指定写入模式
df.write.save(format='es',**options,mode='append')

语法格式:
df.write.format(‘es’)
.option(‘es.nodes’, ‘up01:9200’)
.option(‘es.resource’, ‘tfec_tbl_users_test02’)
.option(‘es.mapping.id’, ‘id’)
.option(‘es.write.operation’, ‘upsert’)
.mode(‘append’)
.save()

<think>我们面临的核心挑战是:每天1亿条日志(约1157条/秒),10年历史数据(约3650亿条),需要支持高效查询和全局用户画像构建。解决方案需兼顾存储效率、查询性能和扩展性。###一、分层存储架构设计采用分层存储策略,根据数据热度和查询需求划分存储层级:1.**热数据层**(近3个月):-存储:分布式列式存储(如**ApacheParquet**onHDFS/Hudi)[^1]-特点:列压缩率高(可节省60%存储),支持谓词下推优化查询-分区:按天分区+用户ID哈希分桶(避免小文件)2.**温数据层**(4个月-2年):-存储:**云对象存储**(如AWSS3/阿里云OSS)配合Hudi表格式-优化:Z-Order索引加速多维查询(如`(时间,用户ID)`)[^2]3.**冷数据层**(2年以上):-存储:压缩归档至对象存储(Glacier/OSS归档型)-机制:建立标签元数据索引,查询时仅解压必要数据>**存储估算**:>单条日志平均1KB→日增量100GB→10年总量约365TB(未压缩)。>采用Parquet+Snappy压缩后(压缩比≈4:1)→**实际存储约91TB**。###二、数据组织优化####1.时空混合分区策略```sql--分区结构示例s3://logs/├──tenant=com_A/│├──dt=20230101/││├──bucket=0000/--按user_id哈希分桶││├──...││└──bucket=1023/│├──dt=20230102/│└──...└──tenant=com_B/```-**时间分区**:按天分区(10年→3650分区,可接受)-**哈希分桶**:对`user_id`哈希分桶(如1024桶),显著提升点查效率####2.多级索引体系|索引类型|实现方式|适用场景||----------------|-----------------------------|----------------------||分区索引|HiveMetastore分区元数据|按时间范围过滤||布隆过滤器|Parquet文件内置|user_id存在性判断||Z-Order索引|Hudi全局索引[^3]|多维查询(时间+用户+事件)|###三、查询加速方案####1.预聚合画像宽表```sql--用户画像宽表示例(每日增量更新)CREATETABLEuser_profile(user_idSTRING,--基础属性age_rangeINT,genderINT,--行为统计last_30d_pvBIGINT,--近30天浏览量total_pvBIGINT,--历史总浏览量preferred_categoryARRAY<STRING>--偏好品类TOP3)PARTITIONEDBY(dtSTRING)STOREDASPARQUET;```-**更新机制**:每日批处理作业(Spark)增量更新-**存储优化**:列式存储+字典编码(如gender映射为0/1)####2.实时画像更新```mermaidgraphLRA[Kafka日志流]-->B(Flink实时计算)B-->C{行为类型}C-->|浏览|D[更新Redis中的短期兴趣]C-->|购买|E[更新HBase长期画像]D-->F[合并到Elasticsearch]E-->F```-**短期兴趣**:Redis存储近7天行为特征(数据结构:`user_id->{category:score}`)-**长期画像**:HBase存储全量画像(RowKey:`user_id+timestamp`)###四、性能优化关键技术####1.存储格式优化|格式|压缩率|查询速度|适用场景||---------------|--------|----------|------------------||Parquet|★★★★|★★★☆|批量画像分析||ORC|★★★☆|★★★★|复杂嵌套查询||HFile(HBase)|★★☆|★★★★★|用户点查|####2.计算引擎选择-**批处理**:SparkSQL(优势:复杂画像计算)-**交互查询**:Presto/Trino(优势:亚秒级响应)-**实时计算**:Flink(优势:低延迟状态更新)####3.缓存策略```python#Redis缓存画像热点数据示例defget_user_profile(user_id):cache_key=f"profile:{user_id}"ifredis.exists(cache_key):returnjson.loads(redis.get(cache_key))else:#从HBase读取并缓存profile=hbase.get(user_id)redis.setex(cache_key,3600,json.dumps(profile))returnprofile```###五、十年数据迁移方案1.**历史数据迁移**:-阶段1:将原始日志转换为Parquet格式(Spark作业)-阶段2:按`(dt,user_id_bucket)`重组数据2.**增量数据处理**:-KafkaConnect实时摄入新日志-Flink实时写入Hudi表[^4]>**关键指标**:>-查询延迟:点查<100ms,全量画像分析<10min>-存储成本:冷热分层降低40%成本---§§相关问题§§1.如何验证用户画像数据的一致性?2.在分层存储架构中如何设计数据生命周期策略?3.Z-Order索引在用户画像查询中的具体实现原理是什么?4.实时画像更新时如何解决状态数据容错问题?5.用户隐私数据画像系统中应该如何合规处理?</think>### 存储方案设计与性能优化策略 #### 一、分层存储架构 为平衡历史数据规模与实时查询性能,采用三级存储体系: 1. **热数据层**(近3个月) - 存储引擎:**分布式列式存储**(Apache Parquet on HDFS- 优化:Z-Order索引加速多维查询(如`(时间, 用户ID, 事件类型)`)[^2] - 容量估算:1亿条/日 &times; 90天 &times; 1KB/条 ≈ 9TB 2. **温数据层**(4个月-2年) - 存储引擎:**云对象存储**(AWS S3/阿里云OSS)配合Hudi表格式 - 优化:增量合并(Merge-on-Read)减少IO[^1] - 分区策略:按月分区 + 用户ID分桶(1024桶) 3. **冷数据层**(3年+- 存储格式:**高压缩列存**(ORC with ZLIB) - 优化:建立标签元数据索引,仅解压必要列 - 成本控制:自动归档至低频存储(如AWS Glacier) > **容量估算**: > 10年总量:1亿条/日 &times; 3650天 &times; 1KB/条 = 3.65PB > 列存压缩后:≈1.1PB(压缩比3.3:1) #### 二、数据组织优化 ```sql -- 分区表示例(Hive格式) CREATE TABLE user_behavior ( user_id BIGINT, event_time TIMESTAMP, event_type STRING, device_hash STRING, -- 其他字段... ) PARTITIONED BY ( dt STRING, -- 按天分区(格式yyyyMMdd) bucket INT -- 用户ID哈希分桶(0-1023) ) STORED AS PARQUET TBLPROPERTIES ( 'parquet.compression'='SNAPPY', 'hoodie.compact.inline'='true' -- Hudi自动压缩 ); ``` **设计要点**: 1. **时空混合分区** - 一级分区:按天(3650个分区可接受) - 二级分桶:`user_id % 1024` 避免小文件问题 2. **全局索引** - 布隆过滤器:快速判断user_id存在性 - 倒排索引:对标签键值建立反向映射 #### 三、查询性能优化 1. **预计算加速** 建立画像宽表,每日增量更新: ```sql CREATE MATERIALIZED VIEW user_profile AS SELECT user_id, COUNT_IF(event_type='purchase') AS purchase_cnt_30d, ARRAY_AGG_DISTINCT(category) AS top_categories FROM behavior_log WHERE dt >= DATE_SUB(CURRENT_DATE, 30) GROUP BY user_id; ``` 2. **多级缓存策略** ```mermaid graph LR A[查询请求] --> B{Redis缓存?} B -->|命中| C[返回缓存结果] B -->|未命中| D[查询HBase] D --> E[写入Redis缓存] E --> C D --> F{是否热点数据?} F -->|是| G[加载到Alluxio内存层] ``` 3. **查询引擎选择** | 场景 | 推荐引擎 | 延迟 | 优势 | |---------------------|---------------|------------|--------------------------| | 点查(单用户画像) | HBase + Phoenix | <100ms | 行键快速定位 | | 群体分析 | Presto on Hudi | 1-10s | 分布式SQL计算 | | 全量历史扫描 | Spark | 分钟级 | 批量处理能力 | #### 四、画像生成架构 采用 **Lambda+Kappa 混合架构** [^1]: ```mermaid graph TD A[Kafka] -->|实时流| B(Flink) A -->|离线| C(Spark) B --> D[Redis实时画像] C --> E[Hudi历史画像] D --> F[画像融合服务] E --> F F --> G[Elasticsearch] G --> H[查询接口] ``` - **实时层**:Flink处理当日数据,更新短期标签(如在线状态) - **批处理层**:Spark每日合并历史数据,计算长期标签(如消费习惯) - **融合服务**:合并实时/离线视图,解决数据冲突[^4] #### 五、关键性能指标 1. **写入吞吐**:Kafka分片数 ≥ `(峰值流量/单分区吞吐)` - 示例:1157条/秒 ÷ 5万条/秒/分区 → 至少24分区 2. **查询延迟**: -用户画像:< 200ms(通过HBase行键查询) - 群体圈选:< 5s(Presto聚合+Z-Order索引) 3. **压缩效率**: - Parquet+Snappy:原始日志压缩至25%大小 - ORC+ZLIB:历史数据压缩至15%大小 > **成本优化提示**: > 冷数据存储采用EC编码(纠删码),存储成本可降低40%[^3] ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值