【数据技术】关于HP Vertica MPP列式数据库资源池设置的一点心得
2024-05-15 07:12:04
年初上线的Vertica数据库出现了数据计算缓慢，页面查询缓慢的情况，然后跟着Vertica工程师调优了一周，有以下几点心得：
1.首先最重要的是数据存储系统的资源池分配一定要按需分配
要搞清楚相关的应用账户是以数据汇总计算为主，还是报表查询为主，不同的应用如果乱使用资源池，就会造成资源浪费或闲置的情况发生，具体来讲一般对于以底层大数据量级数据汇总、计算操作为主的业务应该设置的资源池模式为低并发、高内存；而以少数据量查询、多用户访问的应用应分配高并发、低内存，Vertica资源池中主要的资源是每个连接可分配的内存和并发连接数，这两个参数是互相影响的，如何寻求最佳平衡点是规划资源池的主要任务，决不可一概而论，否则将出现大量内存资源闲置或高并发得不到满足等待等情况的发生。
2.大数据量（千万级）、多列（50-100列）、多表关联查询的情况下数据的查询插入相当慢
利用vertica的SQL性能分析工具对大表关联的SQL语句进行分析。最消耗资源的SQL语句预计消耗78G内存，从SQL语句的执行计划可以看出多表关联的hash join消耗成本过高。因为hash join会做关联表的全表扫描，所以vertica建议大表关联应该尽量避免hash join ，可以通过关联前对其关联键做相同排序后走merge join非内存计算模型进行数据计算和分析。（具体例子见最后HP Vertica官方资料）
NOTICE 2001:
***** NOTICE OF LICENSE NON-COMPLIANCE *****
Continued use of this database is in violation of the current license agreement.
Maximum licensed raw data size: 20.00TB
Current raw data size: 269.63TB
License utilization: 1348%
IMMEDIATE ACTION IS REQUIRED, PLEASE CONTACT VERTICA
------------------------------
QUERY PLAN DESCRIPTION:
------------------------------
explain select
201502 ,
b.user_id ,
b.area_code ,
b.serv_number ,
b.brand_id ,
b.join_duration ,
b.product_id ,
b.user_status_id ,
b.sale_id ,
b.cell_sale_id ,
b.cell_id ,
b.cell_type_id ,
b.town_id ,
b.channel_id ,
b.channel_type_id ,
b.is_repeat_user ,
a.join_date ,
nvl(b.arrear_all_fee,0)/100 ,
nvl(b.arrear_fee,0)/100 ,
nvl(b.intime_pay_fee,0)/100 ,
b.act_cust_count ,
b.bill_cust_count ,
nvl(b.total_fee,0)/100 ,
nvl(b.total_fee_free,0)/100 ,
nvl(b.call_fee,0)/100 ,
nvl(b.call_fee_free,0)/100 ,
nvl(b.sms_p2p_count,0) ,
nvl(b.gprs_cmwap_use_b,0)/1024 ,
nvl(b.gprs_cmnet_use_b,0)/1024 ,
(nvl(b.gprs_cmwap_use_b,0)+ nvl(b.gprs_cmnet_use_b,0))/1024,
nvl(b.z_call_count,0) ,
0 ,
0 ,
0 ,
a.post_flag ,
0 ,
a.productprice_id ,
a.zfsl_date ,
b.restart_flag ,
b.in_cust_count ,
a.z_call_count ,
a.call_fee ,
a.call_fee_free ,
a.sms_p2p_count ,
a.gprs_ll ,
a.arrear_fee ,
nvl(a.sum_total_fee,0)+nvl(b.total_fee,0)/100 ,
a.delete_flag ,
b.mms_count ,
b.sms_mms_p2p_count ,
b.cust_rule_count ,
b.call_duration ,
b.call_duration_nofree ,
b.x_cust_count ,
b.cailing_flag ,
b.display_flag ,
nvl(a.user_status_id,'0') ,
nvl(a.bill_cust_count,'0') ,
nvl(a.bill_cust_count_last,'0') ,
nvl(a.z_call_count_last,0) ,
nvl(a.sms_p2p_count_last,0) ,
nvl(a.call_duration,0) ,
nvl(a.call_duration_nofree,0) ,
nvl(a.x_cust_count,'0') ,
a.call_fee_last ,
a.call_fee_free_last ,
nvl(a.sum_fact_fee,0) ,
nvl(a.bill_cust_count_last_2,'0'),
nvl(a.bill_cust_count_last_3,'0'),
b.start_date ,
a.ykf_flag ,
b.z_call_duration,
a.z_call_duration,
b.z_call_free_duration,
a.z_call_free_duration,
b.z_call_sms_duration ,
a.z_call_sms_duration ,
b.z_call_sms_free_duration ,
a.z_call_sms_free_duration ,
nvl(b.total_fee_no_sub1,0),
b.acct_fee ,
b.sms_fee ,
b.mnet_fee ,
nvl(a.acct_fee ,0),
nvl(a.sms_fee ,0),
nvl(a.mnet_fee ,0),
nvl(a.acct_fee_last_1,0),
nvl(a.sms_fee_last_1 ,0),
nvl(a.mnet_fee_last_1,0),
nvl(a.acct_fee_last_2,0),
nvl(a.sms_fee_last_2 ,0),
nvl(a.mnet_fee_last_2,0),
nvl(a.acct_fee_last_3,0),
nvl(a.sms_fee_last_3 ,0),
nvl(a.mnet_fee_last_3,0),
nvl(a.acct_fee_last_4,0),
nvl(a.sms_fee_last_4 ,0),
nvl(a.mnet_fee_last_4,0),
nvl(a.total_fee_free,0),
nvl(b.group_flag,'0'),
nvl(b.offer_id,0),
nvl(a.offer_id,0),
0
from masard.tb_ch_sc_user_mon a,
masard.tb_mk_sc_user_mid b
where trim(a.user_id) = trim(b.user_id)
and a.statis_month = 201501
and b.statis_month = 201502;
Access Path:
+-JOIN HASH [Cost: 47M, Rows: 288M (NO STATISTICS)] (PATH ID: 1) Inner (BROADCAST)
| Join Cond: (btrim((a.USER_ID)) = btrim((b.USER_ID)))
| Materialize at Output: a.USER_STATUS_ID, a.JOIN_DATE, a.ARREAR_FEE, a.BILL_CUST_COUNT, a.SUM_TOTAL_FEE, a.CALL_FEE, a.CALL_FEE_LAST, a.SMS_P2P_COUNT, a.SMS_P2P_COUNT_LAST, a.GPRS_LL, a.Z_CALL_COUNT, a.Z_CALL_COUNT_LAST, a.POST_FLAG, a.PRODUCTPRICE_ID, a.DELETE_FLAG, a.CALL_DURATION, a.X_CUST_COUNT, a.BILL_CUST_COUNT_LAST, a.BILL_CUST_COUNT_LAST_2, a.SUM_FACT_FEE, a.CALL_DURATION_NOFREE, a.TOTAL_FEE_FREE, a.CALL_FEE_FREE, a.CALL_FEE_FREE_LAST, a.BILL_CUST_COUNT_LAST_3, a.YKF_FLAG, a.Z_CALL_DURATION, a.Z_CALL_SMS_DURATION, a.Z_CALL_FREE_DURATION, a.Z_CALL_SMS_FREE_DURATION, a.ACCT_FEE, a.SMS_FEE, a.MNET_FEE, a.ACCT_FEE_LAST_1, a.SMS_FEE_LAST_1, a.MNET_FEE_LAST_1, a.ACCT_FEE_LAST_2, a.SMS_FEE_LAST_2, a.MNET_FEE_LAST_2, a.ACCT_FEE_LAST_3, a.SMS_FEE_LAST_3, a.MNET_FEE_LAST_3, a.ACCT_FEE_LAST_4, a.SMS_FEE_LAST_4, a.MNET_FEE_LAST_4, a.OFFER_ID, a.ZFSL_DATE
| Execute on: All Nodes
| +-- Outer -> STORAGE ACCESS for a [Cost: 21K, Rows: 288M (NO STATISTICS)] (PATH ID: 2)
| | Projection: MASARD.tb_ch_sc_user_mon_b0
| | Materialize: a.USER_ID
| | Filter: (a.STATIS_MONTH = 201501)
| | Execute on: All Nodes
| | Runtime Filter: (SIP1(HashJoin): btrim((a.USER_ID)))
| +-- Inner -> STORAGE ACCESS for b [Cost: 100K, Rows: 41M (NO STATISTICS)] (PATH ID: 3)
| | Projection: MASARD.tb_mk_sc_user_mid_b1
| | Materialize: b.USER_ID, b.AREA_CODE, b.SERV_NUMBER, b.BRAND_ID, b.JOIN_DURATION, b.PRODUCT_ID, b.USER_STATUS_ID, b.SALE_ID, b.CELL_SALE_ID, b.CELL_ID, b.CELL_TYPE_ID, b.TOWN_ID, b.CHANNEL_ID, b.CHANNEL_TYPE_ID, b.IS_REPEAT_USER, b.ARREAR_ALL_FEE, b.ARREAR_FEE, b.INTIME_PAY_FEE, b.ACT_CUST_COUNT, b.BILL_CUST_COUNT, b.TOTAL_FEE, b.CALL_FEE, b.SMS_P2P_COUNT, b.GPRS_CMWAP_USE_B, b.GPRS_CMNET_USE_B, b.Z_CALL_COUNT, b.IN_CUST_COUNT, b.MMS_COUNT, b.SMS_MMS_P2P_COUNT, b.CUST_RULE_COUNT, b.CALL_DURATION, b.X_CUST_COUNT, b.CAILING_FLAG, b.DISPLAY_FLAG, b.RESTART_FLAG, b.TOTAL_FEE_FREE, b.CALL_DURATION_NOFREE, b.CALL_FEE_FREE, b.START_DATE, b.Z_CALL_DURATION, b.Z_CALL_SMS_DURATION, b.Z_CALL_FREE_DURATION, b.Z_CALL_SMS_FREE_DURATION, b.TOTAL_FEE_NO_SUB1, b.ACCT_FEE, b.SMS_FEE, b.MNET_FEE, b.GROUP_FLAG, b.OFFER_ID
| | Filter: (b.STATIS_MONTH = 201502)
| | Execute on: All Nodes
------------------------------
-----------------------------------------------
NOTICE 2001:
***** NOTICE OF LICENSE NON-COMPLIANCE *****
NOTICE 4788: Statement is being profiled
HINT: Select * from v_monitor.execution_engine_profiles where transaction_id=49539595911191554 and statement_id=1;
NOTICE 3557: Initiator memory for query: [on pool general: 3396297 KB, minimum: 1239764 KB]
NOTICE 5077: Total memory required by query: [75651796 KB]
1.首先最重要的是数据存储系统的资源池分配一定要按需分配
要搞清楚相关的应用账户是以数据汇总计算为主，还是报表查询为主，不同的应用如果乱使用资源池，就会造成资源浪费或闲置的情况发生，具体来讲一般对于以底层大数据量级数据汇总、计算操作为主的业务应该设置的资源池模式为低并发、高内存；而以少数据量查询、多用户访问的应用应分配高并发、低内存，Vertica资源池中主要的资源是每个连接可分配的内存和并发连接数，这两个参数是互相影响的，如何寻求最佳平衡点是规划资源池的主要任务，决不可一概而论，否则将出现大量内存资源闲置或高并发得不到满足等待等情况的发生。
2.大数据量（千万级）、多列（50-100列）、多表关联查询的情况下数据的查询插入相当慢
利用vertica的SQL性能分析工具对大表关联的SQL语句进行分析。最消耗资源的SQL语句预计消耗78G内存，从SQL语句的执行计划可以看出多表关联的hash join消耗成本过高。因为hash join会做关联表的全表扫描，所以vertica建议大表关联应该尽量避免hash join ，可以通过关联前对其关联键做相同排序后走merge join非内存计算模型进行数据计算和分析。（具体例子见最后HP Vertica官方资料）
NOTICE 2001:
***** NOTICE OF LICENSE NON-COMPLIANCE *****
Continued use of this database is in violation of the current license agreement.
Maximum licensed raw data size: 20.00TB
Current raw data size: 269.63TB
License utilization: 1348%
IMMEDIATE ACTION IS REQUIRED, PLEASE CONTACT VERTICA
------------------------------
QUERY PLAN DESCRIPTION:
------------------------------
explain select
201502 ,
b.user_id ,
b.area_code ,
b.serv_number ,
b.brand_id ,
b.join_duration ,
b.product_id ,
b.user_status_id ,
b.sale_id ,
b.cell_sale_id ,
b.cell_id ,
b.cell_type_id ,
b.town_id ,
b.channel_id ,
b.channel_type_id ,
b.is_repeat_user ,
a.join_date ,
nvl(b.arrear_all_fee,0)/100 ,
nvl(b.arrear_fee,0)/100 ,
nvl(b.intime_pay_fee,0)/100 ,
b.act_cust_count ,
b.bill_cust_count ,
nvl(b.total_fee,0)/100 ,
nvl(b.total_fee_free,0)/100 ,
nvl(b.call_fee,0)/100 ,
nvl(b.call_fee_free,0)/100 ,
nvl(b.sms_p2p_count,0) ,
nvl(b.gprs_cmwap_use_b,0)/1024 ,
nvl(b.gprs_cmnet_use_b,0)/1024 ,
(nvl(b.gprs_cmwap_use_b,0)+ nvl(b.gprs_cmnet_use_b,0))/1024,
nvl(b.z_call_count,0) ,
0 ,
0 ,
0 ,
a.post_flag ,
0 ,
a.productprice_id ,
a.zfsl_date ,
b.restart_flag ,
b.in_cust_count ,
a.z_call_count ,
a.call_fee ,
a.call_fee_free ,
a.sms_p2p_count ,
a.gprs_ll ,
a.arrear_fee ,
nvl(a.sum_total_fee,0)+nvl(b.total_fee,0)/100 ,
a.delete_flag ,
b.mms_count ,
b.sms_mms_p2p_count ,
b.cust_rule_count ,
b.call_duration ,
b.call_duration_nofree ,
b.x_cust_count ,
b.cailing_flag ,
b.display_flag ,
nvl(a.user_status_id,'0') ,
nvl(a.bill_cust_count,'0') ,
nvl(a.bill_cust_count_last,'0') ,
nvl(a.z_call_count_last,0) ,
nvl(a.sms_p2p_count_last,0) ,
nvl(a.call_duration,0) ,
nvl(a.call_duration_nofree,0) ,
nvl(a.x_cust_count,'0') ,
a.call_fee_last ,
a.call_fee_free_last ,
nvl(a.sum_fact_fee,0) ,
nvl(a.bill_cust_count_last_2,'0'),
nvl(a.bill_cust_count_last_3,'0'),
b.start_date ,
a.ykf_flag ,
b.z_call_duration,
a.z_call_duration,
b.z_call_free_duration,
a.z_call_free_duration,
b.z_call_sms_duration ,
a.z_call_sms_duration ,
b.z_call_sms_free_duration ,
a.z_call_sms_free_duration ,
nvl(b.total_fee_no_sub1,0),
b.acct_fee ,
b.sms_fee ,
b.mnet_fee ,
nvl(a.acct_fee ,0),
nvl(a.sms_fee ,0),
nvl(a.mnet_fee ,0),
nvl(a.acct_fee_last_1,0),
nvl(a.sms_fee_last_1 ,0),
nvl(a.mnet_fee_last_1,0),
nvl(a.acct_fee_last_2,0),
nvl(a.sms_fee_last_2 ,0),
nvl(a.mnet_fee_last_2,0),
nvl(a.acct_fee_last_3,0),
nvl(a.sms_fee_last_3 ,0),
nvl(a.mnet_fee_last_3,0),
nvl(a.acct_fee_last_4,0),
nvl(a.sms_fee_last_4 ,0),
nvl(a.mnet_fee_last_4,0),
nvl(a.total_fee_free,0),
nvl(b.group_flag,'0'),
nvl(b.offer_id,0),
nvl(a.offer_id,0),
0
from masard.tb_ch_sc_user_mon a,
masard.tb_mk_sc_user_mid b
where trim(a.user_id) = trim(b.user_id)
and a.statis_month = 201501
and b.statis_month = 201502;
Access Path:
+-JOIN HASH [Cost: 47M, Rows: 288M (NO STATISTICS)] (PATH ID: 1) Inner (BROADCAST)
| Join Cond: (btrim((a.USER_ID)) = btrim((b.USER_ID)))
| Materialize at Output: a.USER_STATUS_ID, a.JOIN_DATE, a.ARREAR_FEE, a.BILL_CUST_COUNT, a.SUM_TOTAL_FEE, a.CALL_FEE, a.CALL_FEE_LAST, a.SMS_P2P_COUNT, a.SMS_P2P_COUNT_LAST, a.GPRS_LL, a.Z_CALL_COUNT, a.Z_CALL_COUNT_LAST, a.POST_FLAG, a.PRODUCTPRICE_ID, a.DELETE_FLAG, a.CALL_DURATION, a.X_CUST_COUNT, a.BILL_CUST_COUNT_LAST, a.BILL_CUST_COUNT_LAST_2, a.SUM_FACT_FEE, a.CALL_DURATION_NOFREE, a.TOTAL_FEE_FREE, a.CALL_FEE_FREE, a.CALL_FEE_FREE_LAST, a.BILL_CUST_COUNT_LAST_3, a.YKF_FLAG, a.Z_CALL_DURATION, a.Z_CALL_SMS_DURATION, a.Z_CALL_FREE_DURATION, a.Z_CALL_SMS_FREE_DURATION, a.ACCT_FEE, a.SMS_FEE, a.MNET_FEE, a.ACCT_FEE_LAST_1, a.SMS_FEE_LAST_1, a.MNET_FEE_LAST_1, a.ACCT_FEE_LAST_2, a.SMS_FEE_LAST_2, a.MNET_FEE_LAST_2, a.ACCT_FEE_LAST_3, a.SMS_FEE_LAST_3, a.MNET_FEE_LAST_3, a.ACCT_FEE_LAST_4, a.SMS_FEE_LAST_4, a.MNET_FEE_LAST_4, a.OFFER_ID, a.ZFSL_DATE
| Execute on: All Nodes
| +-- Outer -> STORAGE ACCESS for a [Cost: 21K, Rows: 288M (NO STATISTICS)] (PATH ID: 2)
| | Projection: MASARD.tb_ch_sc_user_mon_b0
| | Materialize: a.USER_ID
| | Filter: (a.STATIS_MONTH = 201501)
| | Execute on: All Nodes
| | Runtime Filter: (SIP1(HashJoin): btrim((a.USER_ID)))
| +-- Inner -> STORAGE ACCESS for b [Cost: 100K, Rows: 41M (NO STATISTICS)] (PATH ID: 3)
| | Projection: MASARD.tb_mk_sc_user_mid_b1
| | Materialize: b.USER_ID, b.AREA_CODE, b.SERV_NUMBER, b.BRAND_ID, b.JOIN_DURATION, b.PRODUCT_ID, b.USER_STATUS_ID, b.SALE_ID, b.CELL_SALE_ID, b.CELL_ID, b.CELL_TYPE_ID, b.TOWN_ID, b.CHANNEL_ID, b.CHANNEL_TYPE_ID, b.IS_REPEAT_USER, b.ARREAR_ALL_FEE, b.ARREAR_FEE, b.INTIME_PAY_FEE, b.ACT_CUST_COUNT, b.BILL_CUST_COUNT, b.TOTAL_FEE, b.CALL_FEE, b.SMS_P2P_COUNT, b.GPRS_CMWAP_USE_B, b.GPRS_CMNET_USE_B, b.Z_CALL_COUNT, b.IN_CUST_COUNT, b.MMS_COUNT, b.SMS_MMS_P2P_COUNT, b.CUST_RULE_COUNT, b.CALL_DURATION, b.X_CUST_COUNT, b.CAILING_FLAG, b.DISPLAY_FLAG, b.RESTART_FLAG, b.TOTAL_FEE_FREE, b.CALL_DURATION_NOFREE, b.CALL_FEE_FREE, b.START_DATE, b.Z_CALL_DURATION, b.Z_CALL_SMS_DURATION, b.Z_CALL_FREE_DURATION, b.Z_CALL_SMS_FREE_DURATION, b.TOTAL_FEE_NO_SUB1, b.ACCT_FEE, b.SMS_FEE, b.MNET_FEE, b.GROUP_FLAG, b.OFFER_ID
| | Filter: (b.STATIS_MONTH = 201502)
| | Execute on: All Nodes
------------------------------
-----------------------------------------------
NOTICE 2001:
***** NOTICE OF LICENSE NON-COMPLIANCE *****
NOTICE 4788: Statement is being profiled
HINT: Select * from v_monitor.execution_engine_profiles where transaction_id=49539595911191554 and statement_id=1;
NOTICE 3557: Initiator memory for query: [on pool general: 3396297 KB, minimum: 1239764 KB]
NOTICE 5077: Total memory required by query: [75651796 KB]
预计需要消耗内存75G左右。
meger join HP官方相关资料：
本文乃sunjinshuang原创文章，请勿转载。如须转载请详细标明转载出处。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14146064/viewspace-1629311/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14146064/viewspace-1629311/
【数据技术】关于HP Vertica MPP列式数据库资源池设置的一点心得相关推荐
- 2022-05-19 列式数据库-Clickhouse
什么事列式数据库,顾名思义它与平时的主流关系型数据库不太一致,例如mysql 它是行式数据库,什么意思呢? image.png 这就是普通的行式数据库的存储,一行是一条完整的数据; 接下来看看列式数据 ...
- 列式数据库，OLAP与OLTP
刚接触clickhouse,对于olap与oltp有点蒙圈.记录一下当前的认知,比较浅显,有志之士多补充修正. OLAP与OLTP OLTP:联机事务处理.主要用于数据库,对业务数据进行数据采集,cr ...
- 支持百亿数据场景，海量高性能列式数据库HiStore技术架构解析
支持百亿数据场景,海量高性能列式数据库HiStore技术架构解析 HiStore介绍 HiStore是阿里中间件团队研发的数据库产品,是一款基于独特的知识网格技术的列式数据库,定位于海量数据高压缩比列 ...
- 【大数据技术基础系列】列式数据库与基于行的数据库存储数据结构
目录 列式数据库与基于行的数据库 基于行的数据库系统物理结构布局
- 海量高性能列式数据库HiStore技术架构解析
HiStore 介绍 HiStore是阿里中间件团队研发的数据库产品,是一款基于独特的知识网格技术的列式数据库,定位于海量数据高压缩比列式存储,是低存 储成本,低维护成本,海量数据OLAP存储引擎;有 ...
- vertica 数据库 linux,配置访问列式数据库vertica的php环境
vertica是一个和Sybase IQ,infobright类似的列式数据库,没有用过Sybase IQ,就和infobright 3.4的社区版做了简单对比测试,在同样一个一亿条记录的表中,下面的 ...
- ClickHouse数据分析列式数据库概述
一． 概述 随着物联网IOT时代的来临,IOT设备感知和报警存储的数据越来越大,有用的价值数据需要数据分析师去分析.大数据分析成了非常重要的环节.当然近两年开启的开源大潮,为大数据分析工程师提供了十分 ...
- 行式数据库与列式数据库的对比
导语:随着大数据的发展,现在出现的列式存储和列式数据库.它与传统的行式数据库有很大区别的. 正文: 行式数据库是按照行存储的,行式数据库擅长随机读操作不适合用于大数据.像SQL server,Orac ...
- 行式数据库和列式数据库
导语:随着大数据的发展,现在出现的列式存储和列式数据库.它与传统的行式数据库有很大区别的. 正文: 行式数据库是按照行存储的,行式数据库擅长随机读操作不适合用于大数据.像SQL server,Orac ...
最新文章
- 网络工程师_记录的一些真题_2018上半年上午
- 10、计算机图形学——几何介绍（曲面的分类以及示例）
- HDU 2181 哈密顿绕行世界问题【DFS】
- html5调用手机摄像头，实现拍照上传功能
- 【Android】3.0 第3章 百度地图及其应用--预备知识
- cnpm在ubuntu19.10下面的安装以及vue.js中el的意思
- 暑期训练日志----2018.8.17
- 树（5）-----判断两颗树一样或者一棵树是否是另外一颗的子树
- 软件因丢失.dll文件（未找到）而无法启动？
- 阶段1 语言基础+高级_1-3-Java语言高级_07-网络编程_第4节 模拟BS服务器案例_1_模拟BS服务器分析...
- python判断闰年程序_python实现闰年
- Microsoft Store打不开解决办法
- 虎虎生威—新年版本（鼠标超人、烟花、浮动会闪的星星以及闪避值拉满的老虎）
- what is a rx ring/tx ring in router?
- speedoffice（Word）怎么修改字体颜色呢
- freemarker html 换行,java使用freemarker模板导出word，合并单元格，单元格内换行
- window 相关dll文件下载
- 百度云云虚拟主机新用户体验活动：6元购买3个月香港主机
- STM32直流减速电机控制篇(一)PWM调速
- Java剑开天门（四）