2024年 – 第11页

储能 8月 8,2024

什么是储能系统的有功功率(定义、作用和测量方法）

储能系统的有功功率是一个关键概念，涉及到储能系统在实际运行中的能量转换效率和输出能力。以下将详细解析有功功率的定义、作用及其测量方法。

有功功率的定义

基本定义

有功功率是指储能系统在某一时刻向电网（或负载）输送或从电网吸收的电能的速率。它代表了储能系统实际做功的能力，即电能转换为其他形式能量（如机械能、热能等）的速率13。
有功功率是衡量储能系统性能的重要指标，直接影响到系统的能量转换效率和输出能力。理解有功功率的定义有助于更好地评估和优化储能系统的性能。

物理层面

从物理层面来看，有功功率是由电路中的电阻消耗能量而产生的。具体来说，有功功率的大小与电阻大小有关，且等于电流的平方值和电阻值的乘积1。这一公式简单明了地解释了有功功率的产生机制，有助于工程师在设计和优化储能系统时，更好地理解和控制有功功率。

有功功率的作用

提高电网功率因数

储能系统可以通过向电网注入适当的无功功率来补偿负载所需的无功，从而减小电流与电压之间的相位差，提高功率因数911。提高电网功率因数不仅能提升电能利用效率，还能减少无功功率的传输损耗，增强电网的稳定性和可靠性。

优化电能质量

储能系统能够对电网中的电压波动进行调节和稳定，维持电压的稳定，改善功率因数911。稳定的电压有助于减少因电压波动引起的电流和功率变化，从而改善功率因数，提升电网的整体性能。

灵活的功率调节

通过先进的电力电子变换器，储能系统可以实现有功功率和无功功率的独立、快速和精确调节，以适应电网的实时需求和负载特性911。灵活的功率调节能力使储能系统能够快速响应电网的需求变化，提高电网的运行效率和稳定性。

平滑功率波动

储能系统可以吸收或释放能量，平滑冲击性负载等引起的功率波动，减小其对功率因数的不利影响911。平滑功率波动有助于减少电网中的瞬态扰动，提高电网的稳定性和可靠性，减少对传统发电设备的依赖。

有功功率的测量方法

基本测量方法

有功功率的测量通常基于瞬时功率积分的平均值。通过模拟乘法器获取电压和电流的乘积，得到瞬时功率，再用固定的时间对瞬时功率进行积分，即可获得瞬时功率的平均值6。
这种方法简单且适用于大多数电力系统应用场景，但需要注意电压和电流的相位差对测量结果的影响。

实时监测技术

现代储能系统配备先进的传感器和监测技术，能够实时采集和分析电压、电流等参数，准确计算有功功率19。实时监测技术提高了有功功率测量的准确性和实时性，有助于储能系统的高效运行和优化管理。

储能系统的有功功率是指其在某一时刻向电网输送或从电网吸收的电能速率，代表系统实际做功的能力。它对于提高电网功率因数、优化电能质量、实现灵活的功率调节等方面具有重要作用。通过合理的测量和管理，储能系统能够有效提升电网的运行效率和稳定性。

作者 east

RTOS, 嵌入式 8月 6,2024

FreeRTOS 与其他实时操作系统在性能方面存在一定的差异。
Zephyr 与 FreeRTOS 的实时性测试比较分析显示，以任务切换时间为例，Zephyr 为 6.9 微秒，FreeRTOS 为 2.2 微秒。
在与 uCOS 的比较中，FreeRTOS 内核 ROM 和耗费 RAM 比 uCOS 小，特别是 RAM。FreeRTOS 可以用协程减少 RAM 消耗，而 uCOS 只能用任务。FreeRTOS 可以有优先度一样的任务，按时间片轮流处理，理论上能管理超过 64 个任务，uCOS 每个任务只有独一无二的优先级，只能管理 64 个。不过，FreeRTOS 比 uCOS 简单，任务间通讯只支持 Queque、Semaphores、Mutex，uCOS 还支持 Flag、MailBox 等。uCOS 的支持也更多，除操作系统外，还支持 FS、USB、GUI、CAN 等，可靠性也更高且耐优化。
UCOS-II/II、FreeRTOS、RTX 四大 RTOS 系统性能对比测试中，主要使用 RTOS 的信号量测试任务切换速度，并建立三个任务。
在与 RT-Smart 的比较中，FreeRTOS 非常轻巧，占用内存和处理器资源较少，适合对资源要求严格的嵌入式应用，具有可预测性和低延迟，适合处理实时任务。而 RT-Smart 通常具有更高的性能和可靠性，支持多核处理器，提供更多的功能和服务，以满足复杂的嵌入式应用需求，但也更复杂。
总的来说，FreeRTOS 在资源占用和某些特定场景下的性能表现具有优势，但在功能丰富性和某些特定方面可能不如其他一些实时操作系统，具体的性能差异取决于具体的应用需求和硬件环境。

FreeRTOS 与 Zephyr 的实时性差异

FreeRTOS 和 Zephyr 在实时性方面存在一定的差异。Zephyr 在线程调度方面的功能更加强大、灵活，可以更好地满足不同场景下的需求。例如，在任务切换时间方面，Zephyr 目前的任务切换时间为 6.9 微秒，而 FreeRTOS 仅为 2.2 微秒。Zephyr 在设计时考虑到了时间片等多种因素，实现相对复杂，可能暂时难以找到优化的方法。但这并不意味着 Zephyr 在所有场景下的实时性能都不如 FreeRTOS ，具体表现还需根据实际应用场景和系统配置来综合评估。比如在某些对任务调度精度要求较高的复杂系统中，Zephyr 的灵活性可能会带来更好的性能表现；而在资源受限且对任务切换速度要求极高的简单系统中，FreeRTOS 则可能更具优势。

FreeRTOS 与 uCOS 的内核资源比较

FreeRTOS 和 uCOS 在内核资源方面有所不同。FreeRTOS 的内核 ROM 和耗费 RAM 相对较小，特别是 RAM 资源。在单片机这种资源稀缺的环境中，uCOS 至少需要 5K 以上的 RAM ，而 FreeRTOS 用 2 – 3K 就能运行良好。这使得 FreeRTOS 在资源受限的系统中具有明显优势。例如，在一些小型的嵌入式设备中，有限的内存资源使得 FreeRTOS 成为更合适的选择，能够在保证系统基本功能的同时，最大限度地节省内存开销。而 uCOS 虽然资源需求较大，但其在功能的丰富性和稳定性方面可能具有一定优势，适用于对系统性能要求较高、资源相对充足的应用场景。

FreeRTOS 与 uCOS 的任务管理对比

FreeRTOS 和 uCOS 在任务管理方面存在一些差异。FreeRTOS 可以有优先度相同的任务，这些任务按时间片轮流处理，理论上可以管理超过 64 个任务。而 uCOS 每个任务都有独一无二的优先级，且最多只能管理 64 个任务。此外，FreeRTOS 可以用协程，减少 RAM 消耗，共用 STACK ；uCOS 则只能用任务，每个任务有一个独立的 STACK 。例如，在一个需要同时处理多个同等重要任务的系统中，FreeRTOS 的任务管理方式能够更有效地分配资源，提高系统的并行处理能力。而在对任务优先级要求严格、资源相对丰富的系统中，uCOS 的任务管理方式可能更能保证关键任务的及时响应。

FreeRTOS 与 RT-Smart 的性能特点

FreeRTOS 是一个小型的、实时的嵌入式操作系统，主要用于资源受限的嵌入式系统和物联网设备。它占用内存和处理器资源较少，具有可预测性和低延迟，适合处理实时任务。但相对较简单，没有图形用户界面或复杂的多任务管理功能。而 RT-Smart 是一款实时嵌入式操作系统，广泛应用于工业自动化、汽车电子、通信设备等领域。它通常具有更高的性能和可靠性，支持多核处理器，提供更多的功能和服务，以满足复杂的嵌入式应用需求。但也更为复杂。例如，在简单的传感器数据采集和处理系统中，FreeRTOS 足以胜任，能以较低的资源消耗实现基本功能。而在复杂的工业控制系统中，RT-Smart 的高性能和丰富功能则能更好地保障系统的稳定运行和高效处理。

FreeRTOS 与其他 RTOS 的功能差异

FreeRTOS 与其他实时操作系统相比，具有自身的特点和优势。例如，与 MQX 相比，FreeRTOS 开源免费，小巧简单，多平台支持，用户众多。但功能相对较少，实时性在某些严格要求的应用中可能不如专用的商业 RTOS 。与 μC/OS 相比，FreeRTOS 可移植性好，中断处理和任务调度支持较好，线程安全，但内存管理相对简单，学习曲线较高。在实际应用中，应根据具体需求和项目特点选择合适的实时操作系统。比如，对于预算有限、对功能要求不高的小型项目，FreeRTOS 可能是更经济实惠的选择；而对于大型、复杂、对性能和功能有较高要求的项目，可能需要考虑其他更强大的实时操作系统。
结论：综上所述，FreeRTOS 在与其他实时操作系统的性能比较中，具有在资源占用、任务管理等方面的独特特点。在实际应用中，应根据具体的项目需求、资源状况、性能要求等多方面因素，综合考量选择最适合的实时操作系统，以实现系统的高效稳定运行。

作者 east

python 8月 6,2024

python3报错 name ‘unicode’ is not defined

一份在python2运行正常的代码，在python3运行报错：

 # 首先尝试最常见的预期格式
    if isinstance(date_input, unicode):  # Python 2.7特有的检查
        date_input = date_input.encode('utf-8')  # 转换unicode为str

原来在 Python 3.x 中，字符串默认为 Unicode 字符串，因此不再需要对 unicode 类型进行特殊处理。所以在python3不用对date_input 做特殊处理，删除上面那2行果然运行正常了。

作者 east

Hive 8月 5,2024

Hive SQL解决读取分区字符不规范导致全表扫描的问题

接手旧的项目，看到下面的hive sql

INSERT overwrite  table saas.ods_t_iot partition(ds=${yesdate})
select pid,ptime,pvalue from sass.ods_t_iot_source b
where b.dt=${yes_date} and pid like '10%'
union all 
select pid,ptime,pvalue from sass.ods_t_iot_source a
where  a.dt=${yes_date} and pid like 'IOT.10%';

执行时间居然要5、6个小时以上才跑出结果，虽然sass.ods_t_iot_source每天有9亿多条数据，但是简单的查询和插入，没有复杂计算和shuffle，但觉不应该这样才对。

后来排查发现，ds=${yesdate}，例如
yesdate 是2024-08-05，替换为变量的值是ds=2024-08-05，但由于ds实际分区日期是字符串，上面会导致全表扫描sass.ods_t_iot_source的数据，而不是只读某一天的分区。由于 sass.ods_t_iot_source 有多天数据，数量庞大，所以效率才会这样低下。

修改后的sql如下：

INSERT overwrite  table saas.ods_t_iot partition(ds='${yesdate}')
select pid,ptime,pvalue from sass.ods_t_iot_source b
where b.dt='${yes_date}' and pid like '10%'
union all 
select pid,ptime,pvalue from sass.ods_t_iot_source a
where  a.dt='${yes_date}' and pid like 'IOT.10%';

修改后几分钟后就跑出结果。

作者 east

运维 8月 2,2024

笔记本电脑设备管理器找不到以太网适配器的原因分析和解决方案

可能的原因：

驱动程序问题：适配器的驱动程序可能已损坏、过时或未正确安装。
硬件故障：适配器本身可能存在物理损坏。
配置问题：BIOS/UEFI设置可能禁用了以太网适配器。
操作系统问题：系统文件损坏或者不兼容。
连接问题：适配器可能没有正确连接到主板上。
电脑没有配置：有的没有网口的笔记本电脑是没有以太网卡的，需要通过扩展坞来访问，可以具体咨询电脑厂商的技术支持。

解决方案：

重启电脑：有时候简单的重启就能解决问题。
检查硬件连接：
- 如果是可拆卸的笔记本，尝试重新插入适配器模块。
- 检查适配器的物理连接是否松动。
检查BIOS/UEFI设置：
- 重启电脑并进入BIOS/UEFI设置（通常按F2、F10、Del等键）。
- 查找与网络相关的设置，并确保以太网适配器没有被禁用。
- 保存更改并退出。
更新或重新安装驱动程序：
- 打开“设备管理器”，找到“网络适配器”类别。
- 如果适配器显示为灰色，右击它选择“启用设备”。
- 如果适配器列表为空，尝试右击空白处选择“扫描检测硬件改动”。
- 如果适配器出现但有黄色感叹号，右击它选择“更新驱动程序”。
- 如果无法自动更新，访问制造商网站下载最新驱动程序并手动安装。
使用系统还原：
- 如果您之前创建了系统还原点，可以尝试回滚到一个较早的时间点。
- 开始菜单 > “控制面板” > “系统和安全” > “系统” > “系统保护” > “系统还原”。
检查操作系统问题：
- 使用Windows自带的故障排除工具进行诊断。
- 运行命令提示符作为管理员，输入sfc /scannow来检查和修复系统文件。
专业维修：
- 如果以上方法都无法解决问题，可能是硬件故障，需要专业的技术支持人员检查。

作者 east

运维 8月 2,2024

联想笔记本电脑用了扩展坞不到以太网适配器原因分析及解决方案

可能的原因：

扩展坞问题：扩展坞本身可能存在问题，如硬件故障或不兼容。
驱动程序问题：扩展坞所需的驱动程序可能未正确安装或已损坏。
连接问题：Type-C接口或线缆可能存在接触不良或故障。
系统设置问题：某些系统设置可能会导致适配器不可见。
BIOS/UEFI设置问题：BIOS/UEFI中的某些设置可能会影响扩展坞的功能。
操作系统的兼容性问题：您的操作系统可能不完全支持扩展坞上的以太网适配器。

解决方案：

检查扩展坞和线缆：
- 确保Type-C线缆和扩展坞之间的连接牢固且无损。
- 尝试更换Type-C线缆或使用不同的Type-C端口。
- 确认扩展坞上的以太网接口指示灯是否正常工作。
检查驱动程序：
- 访问联想官网，查找适用于您笔记本型号和扩展坞的最新驱动程序。
- 下载并安装最新的以太网适配器驱动程序。
- 如果扩展坞附带有驱动程序或软件，请确保它们也被正确安装。
检查BIOS/UEFI设置：
- 重启电脑并进入BIOS/UEFI设置。
- 检查与USB或Type-C端口相关的设置，确保它们处于启用状态。
- 保存更改并退出。
系统故障排除：
- 在“设备管理器”中，展开“网络适配器”类别，查看是否能看到通过扩展坞连接的适配器。
- 如果看到适配器但有黄色警告标志，尝试更新驱动程序或禁用后重新启用适配器。
- 如果适配器完全不可见，尝试“扫描检测硬件改动”来刷新设备列表。
运行Windows故障排除工具：
- 打开“设置” > “更新与安全” > “故障排除”。
- 寻找“以太网连接”或“网络适配器”的故障排除选项并运行它。
检查操作系统版本：
- 确保您的操作系统是最新的，并且安装了所有必要的更新。
尝试其他扩展坞或电脑：
- 将扩展坞连接到另一台电脑上测试，看是否能正常工作。
- 将另一台已知工作的扩展坞连接到您的笔记本电脑上，确认是否能识别以太网适配器。

如果上述步骤都不能解决问题，建议通过联想官方网站联系联想的技术支持获取更进一步的帮助。他们可能会建议您进行更深入的硬件检查或提供具体的解决方案。

作者 east

运维 7月 25,2024

解决aide严重影响大数据计算时间问题

大数据离线数仓上线后，由于源头数据倍增到几十亿，发现有的耗时任务跑了几个小时也跑不出结果。明明服务器配置不错，计算内存也还可以。调大计算资源内存后也发现无济于事。

后来发现服务器有aide在运行，严重影响磁盘IO。

iotop -oP
Total DISK READ : 234.02 M/s | Total DISK WRITE : 27.09 M/s
Actual DISK READ: 238.46 M/s | Actual DISK WRITE: 11.52 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND

49757 be/4 unbound 239.94 K/s 0.00 B/s 0.00 % 99.99 % du -sk /data/dfs/dn/current/BP-1594034144-10.0.0.1-1704683739059
33597 be/4 root 7.50 M/s 0.00 B/s 0.00 % 83.99 % aide –check
54216 be/4 root 9.19 M/s 0.00 B/s 0.00 % 83.77 % aide –check
13435 be/4 root 1622.13 K/s 0.00 B/s 0.00 % 83.35 % aide –check
7996 be/4 root 3.06 M/s 0.00 B/s 0.00 % 82.80 % aide –check
25673 be/4 root 8.77 M/s 0.00 B/s 0.00 % 82.68 % aide –check
25721 be/4 root 9.50 M/s 0.00 B/s 0.00 % 81.80 % aide –check
60644 be/4 root 2.11 M/s 0.00 B/s 0.00 % 81.00 % aide –check
44128 be/4 root 10.46 M/s 0.00 B/s 0.00 % 80.85 % aide –check
3670 be/4 root 10.14 M/s 0.00 B/s 0.00 % 80.18 % aide –check
38900 be/4 root 3.06 M/s 0.00 B/s 0.00 % 79.62 % aide –check
46920 be/4 root 9.72 M/s 0.00 B/s 0.00 % 79.49 % aide –check
36099 be/4 root 10.14 M/s 0.00 B/s 0.00 % 79.35 % aide –check
32724 be/4 root 10.46 M/s 0.00 B/s 0.00 % 79.04 % aide –check
21047 be/4 root 9.50 M/s 0.00 B/s 0.00 % 78.96 % aide –check
51881 be/4 root 12.46 M/s 0.00 B/s 0.00 % 77.87 % aide –check
13147 be/4 root 10.77 M/s 0.00 B/s 0.00 % 77.56 % aide –check
36436 be/4 root 10.56 M/s 0.00 B/s 0.00 % 77.34 % aide –check

原来， AIDE 是一款入侵检测工具，它的作用是监控文件系统的完整性，防止未经授权的更改。听起来很不错，对吧？但问题就出在这里。AIDE 在工作时，需要频繁地读取和比对磁盘上的大量文件信息，这就导致了磁盘 IO 操作的大幅增加。

而大数据计算过程，如果内存不够时，需要缓存到磁盘，这时AIDE占用了大量磁盘IO，就会严重拖慢整个大数据计算的进度。

不运行AIDE后，发现耗时的离线计算运行时间缩短为之前的几分之一。

作者 east

Spark 7月 18,2024

解决pyspark的py4j.protocol.Py4JError: An error occurred while calling o84.getstate错误

在pyspark使用了udf，然后就报错下面错误：

 File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\serializers.py", line 587, in dumps
return cloudpickle.dumps(obj, 2)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 863, in dumps
cp.dump(obj)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 260, in dump
return Pickler.dump(self, obj)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 409, in dump
self.save(obj)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 736, in save_tuple
save(element)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 400, in save_function
self.save_function_tuple(obj)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 549, in save_function_tuple
save(state)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 821, in save_dict
self._batch_setitems(obj.items())
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 847, in _batch_setitems
save(v)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 821, in save_dict
self._batch_setitems(obj.items())
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 847, in _batch_setitems
save(v)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 521, in save
self.save_reduce(obj=obj, *rv)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 634, in save_reduce
save(state)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 821, in save_dict
self._batch_setitems(obj.items())
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 852, in _batch_setitems
save(v)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 496, in save
rv = reduce(self.proto)
File "D:\ProgramData\Anaconda3\lib\site-packages\py4j\java_gateway.py", line 1257, in call
answer, self.gateway_client, self.target_id, self.name)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\sql\utils.py", line 63, in deco
return f(*a, **kw)
File "D:\ProgramData\Anaconda3\lib\site-packages\py4j\protocol.py", line 332, in get_return_value
format(target_id, ".", name, value))
py4j.protocol.Py4JError: An error occurred while calling o84.getstate. Trace:
py4j.Py4JException: Method getstate([]) does not exist
at py4j.reflection.ReflectionEngine.getMethod(ReflectionEngine.java:318)
at py4j.reflection.ReflectionEngine.getMethod(ReflectionEngine.java:326)
at py4j.Gateway.invoke(Gateway.java:274)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.GatewayConnection.run(GatewayConnection.java:238)
at java.lang.Thread.run(Thread.java:748)

Traceback (most recent call last):
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\serializers.py", line 587, in dumps
return cloudpickle.dumps(obj, 2)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 863, in dumps
cp.dump(obj)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 260, in dump
return Pickler.dump(self, obj)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 409, in dump
self.save(obj)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 736, in save_tuple
save(element)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 400, in save_function
self.save_function_tuple(obj)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\cloudpickle.py", line 549, in save_function_tuple
save(state)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 821, in save_dict
self._batch_setitems(obj.items())
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 847, in _batch_setitems
save(v)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 821, in save_dict
self._batch_setitems(obj.items())
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 847, in _batch_setitems
save(v)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 521, in save
self.save_reduce(obj=obj, *rv)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 634, in save_reduce
save(state)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 476, in save
f(self, obj) # Call unbound method with explicit self
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 821, in save_dict
self._batch_setitems(obj.items())
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 852, in _batch_setitems
save(v)
File "D:\ProgramData\Anaconda3\lib\pickle.py", line 496, in save
rv = reduce(self.proto)
File "D:\ProgramData\Anaconda3\lib\site-packages\py4j\java_gateway.py", line 1257, in call
answer, self.gateway_client, self.target_id, self.name)
File "D:\ProgramData\Anaconda3\lib\site-packages\pyspark\sql\utils.py", line 63, in deco
return f(*a, **kw)
File "D:\ProgramData\Anaconda3\lib\site-packages\py4j\protocol.py", line 332, in get_return_value
format(target_id, ".", name, value))
py4j.protocol.Py4JError: An error occurred while calling o84.getstate. Trace:
py4j.Py4JException: Method getstate([]) does not exist
at py4j.reflection.ReflectionEngine.getMethod(ReflectionEngine.java:318)
at py4j.reflection.ReflectionEngine.getMethod(ReflectionEngine.java:326)
at py4j.Gateway.invoke(Gateway.java:274)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.GatewayConnection.run(GatewayConnection.java:238)
at java.lang.Thread.run(Thread.java:748)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

刚开始以为pyspark的包有问题，后来仔细研究一下，才发现是下面的问题：

这个错误通常发生在尝试在 PySpark 中注册一个用户定义的函数（UDF）时，而该函数使用了不支持序列化的对象或方法。错误信息中的 __getstate__ 方法缺失提示 Py4J 无法正确地将 Python 对象转换为 Java 对象，这通常是因为 UDF 内部引用了 Spark DataFrame 函数或某些类实例，这些在 Py4J 上下文里是不可序列化的。

原来是在UDF用了lag 函数，这是不允许的，因为 UDF 必须是可序列化的，而 DataFrame 函数是不允许。

由于需要使用lag函数，解决方法是不用UDF来实现。

作者 east

储能 7月 15,2024

独立储能电站调峰和调频的区别

在独立储能电站中，调峰（peak shaving）和调频（frequency regulation）是两种不同的服务，它们各自在电力系统的稳定运行中扮演着重要角色。下面我将详细解释两者之间的区别：

调峰（Peak Shaving）

目的：调峰的主要目的是处理电力需求的峰值，即削峰填谷，减少电力系统在高峰时段的负荷压力。这有助于避免在高峰时段增加额外的发电容量，从而节省成本。
运作机制：在高峰用电时段，储能系统释放之前储存的能量，向电网供电，以补充发电量不足的情况；而在低谷时段，储能系统则从电网吸收多余的能量进行充电，储存起来供后续使用。
周期性：调峰通常与一天内或一周内的负荷曲线相关联，如工作日的白天用电高峰和夜晚用电低谷。
响应时间：调峰响应时间相对较长，因为它的操作通常基于预测的负荷曲线和预先规划的策略。

调频（Frequency Regulation）

目的：调频的主要目的是保持电网频率的稳定。由于电力系统中的供需必须时刻平衡，任何供需的瞬时不平衡都会导致频率波动。调频确保了这一平衡，保持电力系统的频率在一个允许的范围内，通常是50Hz或60Hz。
运作机制：储能系统在检测到电网频率偏移时，能够迅速响应，提供或吸收能量以帮助恢复频率至设定点。这种响应通常是在毫秒级或秒级完成的，比调峰更快速。
周期性：调频的周期性较短，可能在几分钟甚至几秒钟内多次发生，因为它应对的是瞬时的供需变化。
响应时间：调频要求极快的响应时间，以便及时纠正频率偏差，避免系统稳定性问题。

总结

调峰关注的是长期负荷管理，处理的是可预测的负荷高峰和低谷。
调频关注的是即时的供需平衡，处理的是不可预测的、瞬时的供需波动。

独立储能电站通过参与调峰和调频服务，不仅提高了电力系统的灵活性和可靠性，还为自己创造了额外的收入来源，因为这些服务在市场上往往是有偿的。例如，四川的“两个细则”中就提出了对独立储能进行调峰补偿，补偿标准为400元/MWh，这表明了调峰服务的市场价值。

作者 east

mysql 7月 15,2024

mysql使用 docker-compose 方式部署时区不是东八区的解决方案

mysql使用docker-compose安装后，发现时区不是东八区，导致一些服务有些出现问题。

查询时区：

SHOW VARIABLES LIKE ‘%time_zone%’;

MySQL 使用的是 UTC 时区，而不是东八区（CST）。在 Docker 容器中运行的 MySQL 实例也会使用 UTC 时区。要解决这个问题，您需要在 MySQL 配置文件中设置时区为东八区。

解决方案：

修改 my.cnf 配置文件，添加以下行以设置时区为东八区（CST）：在 [mysqld] 部分添加：

default-time_zone = '+08:00'

mysql库 /opt/mysql-master/conf/my.cnf

示例：

[mysqld]

...

default-time_zone = '+08:00'

重新启动 MySQL 容器以应用更改。

docker-compose -f /opt/mysql-master/docker-compose.yml down docker-compose -f /opt/mysql-master/docker-compose.yml up -d

现在，您的 MySQL 实例应该已经使用东八区（CST）时区了。您可以通过登录到 MySQL 并运行以下命令来验证时区设置：

SHOW VARIABLES LIKE 'time_zone';

输出应显示 time_zone 为 +08:00。

作者 east

数据仓库 7月 15,2024

大数据质量监控方法与实现

一、引言

在大数据时代，数据的质量直接关系到企业决策的准确性和业务发展的稳定性。本文旨在详细介绍大数据环境下数据质量的标准、监控方法以及相应的代码实现，确保数据的准确性、完整性、一致性和可靠性。我们将结合具体中间件和代码示例，全面阐述如何实现高效的数据质量监控。

二、数据质量标准

数据质量通常通过以下几个维度来衡量：

准确性：数据应真实反映实际情况，无错误或偏差。
完整性：数据应包含所有必需的信息，无遗漏。
一致性：同一实体在不同数据源或不同时间点的数据应保持一致。
时效性：数据应及时更新，满足业务需求。
可用性：数据应易于访问和使用，无格式或权限障碍。

三、数据质量监控方法

数据质量监控可以从多个层次进行，包括任务基线级别、任务级别与表级别、字段级别以及报表级别。

1. 任务基线级别监控

任务基线级别监控主要关注整个数据流水线（ETL任务）的运行状态和产出情况。

监控内容：
- 所有任务运行时长：与昨天运行时长对比，异常则报警。
- 结果任务产出时间：与基线规定时间对比，未按时产出则预警。

实现方式：

使用Apache Airflow等调度工具管理ETL任务，通过任务日志和执行时间监控任务运行时长和产出时间。
配置Airflow的DAG（Directed Acyclic Graph）依赖关系，确保任务按序执行。

2. 任务级别 & 表级别监控

任务级别和表级别监控关注单个任务或表的运行状态和产出数据。

监控内容：
- 任务运行时长：与昨天运行时长对比。
- 任务产出时间：与任务规定产出时间对比。
- 表产出大小：与昨日分区大小对比。

实现方式：

在ETL任务中添加日志记录功能，记录任务开始时间、结束时间和产出数据大小。
使用Shell脚本或Python脚本定期检查日志文件，对比任务运行时长、产出时间和产出大小，异常则发送邮件或消息通知。

3. 字段级别监控

字段级别监控关注具体数据字段的质量，包括指标字段和维度字段。

监控内容：
- 指标字段：均值、最大值、最小值、中位数等，与昨天、近7天、近30天的数据进行对比。
- 维度字段：维度覆盖率、维度占比、维度下指标的波动。

实现方式：

使用Apache Spark进行大规模数据处理，通过Spark SQL计算字段的统计指标。
结合Deequ等开源数据质量监控工具，编写DQC（Data Quality Center）任务，自动化监控字段质量。

代码示例：使用Deequ监控字段质量

import com.amazon.deequ.VerificationSuite
import com.amazon.deequ.checks.Check
import com.amazon.deequ.checks.CheckLevel

val verificationSuite = VerificationSuite()
  .onData(spark.table("your_table"))
  .addCheck(
    Check(CheckLevel.Error, "Mean of metric field")
      .isComplete("metric_field")
      .hasMeanEqualTo(0.5, 0.01)
  )
  .addCheck(
    Check(CheckLevel.Warning, "Dimension coverage of gender")
      .isComplete("gender")
      .hasMin("gender", 0.9)
  )

val result = verificationSuite.run()
result.show()

4. 报表级别监控

报表级别监控将监控结果可视化，便于项目组所有人直观查看数据变化。

实现方式：
- 使用Tableau、Power BI等数据可视化工具，将监控结果绘制成趋势图、仪表盘等。
- 配置定时任务，自动更新报表数据。

作者 east

年度归档2024