hadoop fs -cp /path/to/your/hive/table/hdfs/dir/date=2026-03-20 /path/to/your/hive/table/hdfs/dir/date=2026-03-21

（2）光复制目录没用，数据仍然是查询不到的，需要用在Hive命令行交互模式下，执行以下命令让复制出来的数据"生效"

msck repair table 表名;

该命令用于修复表的元数据。
直接在 HDFS 上创建了分区目录，但未通过 ALTER TABLE ADD PARTITION 命令注册到 Hive 元数据中，运行msck命令后，这些分区会被自动发现并添加到元数据。

这个效果是怎么实现的呢？按如下步骤操作——
以MacOS为例，安装：

brew install git-delta

全局配置到git，修改 ~/.gitconfig 文件，添加如下内容：

[core]

    pager = delta

[interactive]

    diffFilter = delta --color-only

[delta]

    syntax-theme = Monokai Extended

    line-numbers = true

    side-by-side = true

我们首先要知道几个背景知识：
➤ whisper.cpp 是一个开源的 C/C++ 实现，用于运行 OpenAI 的 Whisper 模型。Whisper 是一种先进的自动语音识别（Automatic Speech Recognition, ASR）神经网络模型，能够将音频转换为文本。它支持多种语言，识别效果精准，并且可以完全离线运行，无需互联网连接。这个项目特别适合嵌入到各种应用程序中，因为它是轻量级的实现，可以在 CPU 上高效运行。
➤ whisper.cpp-cli 是对 whisper.cpp 命令行工具的 Python 封装。
➤ OpenAI 的 Whisper 模型是一个先进的自动语音识别系统。它是基于 Transformer 架构的神经网络模型，主要用于将音频转换为文本。Whisper 由 OpenAI 开源开发，使用了大规模的多语言数据集进行训练（包括 68 万小时的音频数据，支持 98 种语言），因此具有出色的准确性和鲁棒性，能够处理多种口音、背景噪音和技术术语。
文章来源：https://www.codelast.com/
因此，我们需要安装的是 whisper.cpp-cli，并且要下载好 Whisper 模型文件，这样就能使用 whisper.cpp-cli 来调用Whisper模型文件进行语音识别了。
为了不影响系统里安装的软件，我们通常都会用micromamba、uv之类的Python包管理器创建一个新的env（环境），然后在里面再安装其他的Python包。这里我们用uv，你也可以用其他的包管理器来创建env。

mkdir whisper
cd whisper
uv venv . --python 3.8  # 创建一个新环境
source bin/activate  # 激活环境
uv pip install pip  # 安装pip
pip install whisper.cpp-cli  # 安装whisper.cpp-cli

这样我们就安装好了相关软件。
文章来源：https://www.codelast.com/
把 mp3 转成 16 kHz 的 wav 文件：

ffmpeg -y -i /home/codelast/st.mp3 -ar 16000 /home/codelast/st.wav

注意，16 kHz 是Whisper要求的。

然后我们就可以开始做语音识别了：

 whisper-cpp -m ../whisper.cpp/download/x-ggml-model.zh.bin -f /home/codelast/st.wav -l zh --output-txt

这个命令的参数：
-m：指定使用 x-ggml-model.zh.bin 这个模型来做语音识别（模型文件要提前从 Hugging Face 上下载好）
-f：指定输入文件，对 st.wav 这个音频文件进行语音识别
-l：指定输出语言为中文
--output-txt：直接输出txt文本。
文章来源：https://www.codelast.com/
输出内容示例如下：

whisper_init_from_file_with_params_no_state: loading model from '../whisper.cpp/download/x-ggml-model.zh.bin'

whisper_model_load: loading model

whisper_model_load: n_vocab       = 51865

whisper_model_load: n_audio_ctx   = 1500

whisper_model_load: n_audio_state = 768

whisper_model_load: n_audio_head  = 12

whisper_model_load: n_audio_layer = 12

whisper_model_load: n_text_ctx    = 448

whisper_model_load: n_text_state  = 768

whisper_model_load: n_text_head   = 12

whisper_model_load: n_text_layer  = 12

whisper_model_load: n_mels        = 80

whisper_model_load: ftype         = 1

whisper_model_load: qntvr         = 0

whisper_model_load: type          = 3 (small)

whisper_model_load: adding 1608 extra tokens

whisper_model_load: n_langs       = 99

whisper_model_load:      CPU total size =   487.01 MB

whisper_model_load: model size    =  487.01 MB

whisper_init_state: kv self size  =   49.55 MB

whisper_init_state: kv cross size =   55.30 MB

whisper_init_state: compute buffer (conv)   =   22.54 MB

 whisper_init_state: compute buffer (encode) =  2 80.20 MB

whisper_init_state: compute buffer (cross)  =    6.31 MB

whisper_init_state: compute buffer (decode) =   97.40 MB

 

system_info: n_threads = 4 / 8 | AVX = 1 | AVX2 = 1 | AVX512 = 0 | FMA = 1 | NEON = 0 | ARM_FMA = 0 | METAL = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 0 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | CUDA = 0 | COREML = 0 | OPENVINO = 0

 

main: processing '/home/codelast/st.wav' (23957094 samples, 1497.3 sec), 4 threads, 1 processors, 5 beams + best of 5, lang = zh, task = transcribe, timestamps = 1 ...

 

 

[00:00:00.000 --> 00:00:19.040]  这里是识别文字第一句

[00:00:19.040 --> 00:00:40.280]  这里是识别文字第二句
......

可以看到，输出的内容是带有时间轴标识的。
细看会发现，Whisper输出的中文有时会有错别字，我们可以用AI进一步纠错，想怎么处理你就可以随意发挥了。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

 

本来嘛，点进这个页面，会看到正常的counter数据，但是，出问题的情况下，点进去看到的是这种情况：

同时，在shell命令行你也会发现，该job没有任何counter信息输出。
从错误信息页上，你得不到关于错误的任何有效信息，那个"Error Details"里也没有。
虽然counter无法显示，但M-R job是可以正常跑完、正常输出数据的。
文章来源：https://www.codelast.com/
经过测试，我这个case的的问题是：在程序中添加了数量比较多的Hadoop counter造成的。
什么算多？我不知道。我的程序里有240多个counter就出问题了，当我把counter缩减了一半，最终只有120多个counter的时候，counter信息统计就正常了。
如果你遇到了类似问题，可以首先检查一下job中的counter数量是否太多。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

有时候，一个用了好久、一直好用的方法突然失灵，并且还折腾了几天，真的会逼疯人。
前几天我就遇到了这种破事：在Ubuntu开发机上自己升级IntelliJ idea到最新版之后，就无法再启动它。
启动时永远会崩溃，无论是重启系统、删除IntelliJ idea的本地缓存，或者使用回旧版，都无法再启动它（仿佛什么文件被"污染"了，再也回不去了），十分烦人。经过几天各种方法的尝试，终于解决了问题，我的解决办法不具有普适性，但如果你遇到了此类问题，或许可以为你提供一些解决思路。

OS：Ubuntu 20.04.6 LTS
JDK：1.8.0_382
原来安装的IntelliJ idea版本：idea-IC-232.8660.185
从JetBrains官网上下载的新版IntelliJ idea版本：idea-IC-233.14808.21
我当时不是利用IDE里的升级功能来升级的，而是自己下载了新版的压缩包，解压出来一个 idea-IC-233.14808.21 目录，直接进入 bin 目录下执行 idea.sh 来跑的新版。众所周知，这样跑起来之后，新版会自动把旧版里的配置引入进来，只要没有问题，是可以无缝切换到新版不需要重新配置的。
文章来源：https://www.codelast.com/
然而，启动新版的时候挂了，最后看到命令行报错：

[error occurred during error reporting (), id 0x6, SIGABRT (0x6) at pc=0x00007fed3c5cf00b]

Aborted (core dumped)

进不了IDE主界面。同时在/home目录下生成了一个内容超长的错误报告文件 java_error_in_idea_xxx.log
我一开始并没有看这个log文件，而是按网上搜到的方法，分别尝试了：
1、重启系统
2、删除IntelliJ idea的缓存
3、使用回旧版IntelliJ idea
4、仿照这个类似的问题，卸载了snap又重新安装
以上方法都没用。
实在没辙了，只能硬着头皮看崩溃产生的日志文件 java_error_in_idea_xxx.log，没想到一看就发现了端倪。
开头有一段内容是：

# Problematic frame:

# C  [x86_64-linux-gnu-tree-sitter-cpp.so+0x38ec09]  tree_sitter_cpp_external_scanner_deserialize+0x179

虽然我不知道它是什么确切的意思，但是这里写的是"问题帧"，说明崩溃和它有关。
文章来源：https://www.codelast.com/

再往下看日志，会看到：

---------------  T H R E A D  ---------------

 

Current thread (0x00007fec7c02b370):  JavaThread "AWT-EventQueue-0" [_thread_in_native, id=352672, stack(0x00007feb95ae5000,0x00007feb95be6000)]

 

Stack: [0x00007feb95ae5000,0x00007feb95be6000],  sp=0x00007feb95be0310,  free space=1004k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C  [x86_64-linux-gnu-tree-sitter-cpp.so+0x38ec09]  tree_sitter_cpp_external_scanner_deserialize+0x179

C  [x86_64-linux-gnu-tree-sitter.so+0x30b3e]  ts_parser_reset+0x30e

C  [x86_64-linux-gnu-tree-sitter.so+0x2e329]  ts_parser_set_language+0x399

C  [x86_64-linux-gnu-tree-sitter.so+0xb4875]  Java_org_treesitter_TSParser_ts_1parser_1set_1language+0x25

j  org.treesitter.TSParser.ts_parser_set_language(JJ)Z+0

j  org.treesitter.TSParser.setLanguage(Lorg/treesitter/TSLanguage;)Z+10

j  ai.codegeex.plugin.lang.agent.d.a()V+64

j  ai.codegeex.plugin.lang.agent.d.<init>()V+365

j  ai.codegeex.plugin.lang.agent.d.a()Lai/codegeex/plugin/lang/agent/d;+10

j  ai.codegeex.plugin.lang.agent.CodegeexAgentCompletionService.e()V+0

j  ai.codegeex.plugin.lang.agent.CodegeexAgentCompletionService.<init>()V+266

可见，和出问题的"x86_64-linux-gnu-tree-sitter-cpp.so+0x38ec09"有关系的插件，第一个出现的就是"ai.codegeex.plugin"，这个对应的就是我安装的CodeGeeX插件。

所以我怀疑，删除这个插件可以解决IntelliJ idea启动崩溃的问题。

在Ubuntu系统上，插件安装在这个目录下：~/.local/share/JetBrains/IdeaIC2023.3

其中，IdeaIC2023.3是IntelliJ idea的版本号，每升级一个版本，~/.local/share/JetBrains 目录下都会生成一个新的目录。

在这个目录下，会看到有一个名为"CodeGeeX"的目录，这个目录就是CodeGeeX插件的安装目录，删除它即可。

然后再次尝试启动IntelliJ idea，发现已经可以正常启动了。
虽然我现在还不知道为什么CodeGeeX插件会引起这个问题，但是如果你像我一样，实在找不到IDE崩溃的原因时，删除可能有问题的插件或许是解决问题的一个办法。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

brew install grc

安装完成后，修改 ~/.bash_profile 文件，添加一行：

alias diff='/usr/local/bin/grc /usr/bin/diff'

然后重新打开终端，再用 diff file1 file2 命令试一下，大概会是下面这样的效果：

文章来源：https://www.codelast.com/
➤ colordiff 软件：直接输出彩色的diff
嫌上面安装 grc 的方法烦？可以直接安装 colordiff 软件：

brew install colordiff

再用 colordiff file1 file2 命令来显示diff，大概会是下面这样的效果：

可以看到这个效果和 grc + diff 差不多，所以考虑到简单，直接用colordiff就好了。
文章来源：https://www.codelast.com/
➤ icdiff：左右双屏的diff对比工具，很直观
上面的diff命令，都是上下形式来展示，我觉得看起来很难受。icdiff 软件可以改变这种情况。安装：

brew install icdiff

命令 icdiff file1 file2 的效果如下：

看到没，不仅左右对照，而且还彩色高亮显示，超级直观！
文章来源：https://www.codelast.com/
➤ vim -d：基于vim的左右双屏对比
使用 vim -d file1 file2 命令，就可以在vim中左右双屏展示差异了：

但是注意：当一行内容太长的时候，vim在diff模式下不会把内容自动换行显示，看起来很不方便，你可以用 :set wrap 命令来开启自动换行。
如果要让光标在左右屏之间切换，按两下快捷键 Ctrl+w 即可。
缺点：当一行内容超长的时候，即使开启了自动换行，在一行内跳转也是极不方便的，而且鼠标又不能滚动文本，我觉得不爽。
文章来源：https://www.codelast.com/
➤ code --diff：基于VSCode的左右双屏对比
什么？你天天使用的VSCode也能用做 diff 工具？没错：
code --diff file1 file2
这样就能在VSCode编辑器里展示出两个文件的 diff 啦：

如果你想修改diff显示的颜色，你甚至可以修改VSCode的配置(settings.json)来实现：

"workbench.colorCustomizations": {
    "diffEditor.insertedTextBackground": "#fc00ce7c",
    "diffEditor.removedTextBackground": "#4542f97c",
    "diffEditor.insertedLineBackground": "#d9f4db66",
    "diffEditor.removedLineBackground": "#e6dbe066",
}

在这个例子中，workbench.colorCustomizations 里的配置都是我添加的。
diffEditor.insertedTextBackground 配置的是 file1 里的diff内容的颜色；
diffEditor.removedTextBackground 配置的是 file2 里的diff内容的颜色；
diffEditor.insertedLineBackground 配置的是 file1 里的diff行的背景色；
diffEditor.removedLineBackground 配置的是 file2 里的diff行的背景色。
文章来源：https://www.codelast.com/
➤ Meld：图形化的双屏/三屏diff对比工具
MacOS下的Meld是另一个图形化diff工具。这个软件类似于Linux下的 meld 软件，它不仅可以对比两个文件的 diff，还可以对比三个文件的diff。
不过我在M2 CPU的MacOS上用起来，时不时会crash一次，所以就不想再用了。

文章来源：https://www.codelast.com/
➤ 超长文本行的diff高亮显示
上面提到的命令行的diff工具，在遇到超长文本行+某些内容的时候，在显示diff的时候都有这样那样的问题。
例如，file1 的第一行和 file2 的第一行都有一万个字符，但它们仅仅在其中的5个字符有差异，那么diff工具理论上应该高亮显示出那5个字符。
但实际上，当这行的内容有些特殊的时候，命令行diff工具可能会高亮显示出整行，而不是那5个字符；或者高亮显示的是多于那5个字符的一块区域。总之它有可能没法精确地标识出diff的部分。
这里举一个例子：
1.txt 和 2.txt 的第一行都超长，它们只在几个字符上有差异：

可见VSCode正确地只高亮了有差异的部分。
文章来源：https://www.codelast.com/
如果用 icdiff 1.txt 2.txt 来查看差异，就非常扯蛋了，它没能像VSCode一样仅标识出diff的部分，而是把整行都标识成了diff，辣眼睛：

在这种情况下，VSCode和Meld都可以正确标识出diff的内容。
所以图形化diff工具还是有用的，别只迷信命令行。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

Homebrew 是一个自由和开源的软件包管理系统，专为 macOS 设计，用于简化软件安装过程。它允许用户容易地安装、更新和卸载各种软件包，包括命令行工具、开发工具和常用库。Homebrew 通过 GitHub 维护，并且它的软件包是从 GitHub 仓库中获取的。

➤ 安装 Homebrew 并保持最新
在macOS里，为了方便快捷地安装各种软件包，首先你要装好Homebrew。
安装Homebrew的过程此处不赘述，请参考Homebrew官网。
如果你早已安装过，那么注意要保持它最新：

brew update

这个过程可能耗时较长。
如果你不更新，可能会在用 brew install xxx 安装软件包的时候，看到类似于下面的提示：

==> Searching for similarly named formulae...

Error: No similarly named formulae found.

Error: No available formula or cask with the name "grc".

==> Searching for a previously deleted formula (in the last month)...

Error: No previously deleted formula found.

==> Searching taps on GitHub...

Error: No formulae found in taps.

文章来源：https://www.codelast.com/
➤ 设置 GitHub 密钥，让Homebrew可以正常安装软件
如果你没有设置过 GitHub 密钥，当你执行 brew install xxx 命令来安装软件的时候，会报错：

Error: GitHub

The GitHub credentials in the macOS keychain may be invalid.

Clear them with:

  printf "protocol=https\nhost=github.com\n" | git credential-osxkeychain erase

Or create a personal access token:

  https://github.com/settings/tokens/new?scopes=gist,public_repo&description=Homebrew

and then set the token as: export HOMEBREW_GITHUB_API_TOKEN="your_new_token"

大概意思就是，你需要到上面的这个GitHub链接里设置、生成一个token，然后把 HOMEBREW_GITHUB_API_TOKEN 这个环境变量设置成你生成的那个token。
照做就得了。生成token之后，编辑 ~/.bash_profile 文件，添加一行：

export HOMEBREW_GITHUB_API_TOKEN=xxx

其中，xxx 代表你在GitHub上生成的那个 token。
这样做之后，你理应可以用 brew install 来正常安装软件了。
文章来源：https://www.codelast.com/
➤ Homebrew加速：设置国内镜像
由于Homebrew默认使用的是GitHub上的仓库，对于国内用户来说，访问速度可能会比较慢。国内有一些机构提供了Homebrew的镜像，可以用来加速软件包的下载和安装：中科大镜像、清华镜像、阿里云镜像等。
以阿里云镜像为例：
替换 brew.git：

git -C "$(brew --repo)" remote set-url origin https://mirrors.aliyun.com/homebrew/brew.git

替换 homebrew-core.git：

git -C "$(brew --repo homebrew/core)" remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-core.git

替换 homebrew-cask.git（如果需要）：

git -C "$(brew --repo homebrew/cask)" remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-cask.git

然后再执行 brew update 来更新本地仓库。

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

dyld[52840]: Library not loaded: /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib

  Referenced from: <此处内容省略> /usr/local/Cellar/openssh/7.8p1/bin/ssh

  Reason: tried: '/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib' (no such file), '/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib' (no such file), '/usr/local/lib/libcrypto.1.0.0.dylib' (no such file), '/usr/lib/libcrypto.1.0.0.dylib' (no such file, not in dyld cache), '/usr/local/Cellar/openssl@3/3.2.0_1/lib/libcrypto.1.0.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/Cellar/openssl@3/3.2.0_1/lib/libcrypto.1.0.0.dylib' (no such file), '/usr/local/Cellar/openssl@3/3.2.0_1/lib/libcrypto.1.0.0.dylib' (no such file), '/usr/local/lib/libcrypto.1.0.0.dylib' (no such file), '/usr/lib/libcrypto.1.0.0.dylib' (no such file, not in dyld cache)

brew update
brew upgrade openssh

brew uninstall --ignore-dependencies openssh
brew install openssh

用Apache Pig处理大数据时，经常会有这种需求：把输入数据按指定的字段group，并且每个group内只输出时间最新的一条记录。

举个例子。有数据文件 input.txt ：

10      a       1,2,3
9       b       1,2
8       a       2,3,4
13      a       1,2,3,4
6       b       1

该数据的三个字段分别代表：time（时间戳），userId（用户id），userInterest（用户兴趣id）
现在，要找出每个用户时间最新的userInterest，应该怎么做？
即：对用户 a，最新的时间戳是13，userInterest是1,2,3,4；对用户 b，最新的时间戳是9，userInterest是1,2。
直接上代码：

A = LOAD 'input.txt' AS (time: long, userId: chararray, userInterest: chararray);
A = FOREACH A GENERATE time, userId, userInterest;
B = GROUP A BY userId;
-- 每个userId取时间最新的一条记录
C = FOREACH B {
    SORTED = ORDER A BY time DESC;
    ONE_RECORD = LIMIT SORTED 1;
    GENERATE FLATTEN(ONE_RECORD);
};
DUMP C;

在嵌套的FOREACH语句中，首先用ORDER BY对同一个group内的数据进行了降序排序，再用LIMIT取一条记录，由于是按time降序排序，因此LIMIT 1取到的就是时间戳最大的那条记录，即时间最新的记录。
输出：

(13,a,1,2,3,4)

(9,b,1,2)

可见这个结果和我们前面人工判断出来的正确结果一致。

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

在Apache Pig中，怎样把 2023-10-11_10:57:56 这种格式的时间字符串，转成整型的时间戳？
话不多说，直接上代码。
假设输入数据文件 1.txt，其格式是一行一个时间字符串。

A = LOAD '1.txt' AS (dt: chararray);
A = FOREACH A GENERATE ToDate(dt, 'yyyy-MM-dd_HH:mm:ss') AS date;
B = FOREACH A GENERATE ToUnixTime(date) AS ts;
DUMP B;

输出结果形如：

1696993076

可见，这样得到的时间戳单位是“秒”。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

static class QuerySegmentResultFromKVReducer extends Reducer<Text, NullWritable, NullWritable, NullWritable> {

  @Override
  protected void setup(Reducer.Context context) throws IOException, InterruptedException {
  }

  @Override
  protected void cleanup(Reducer.Context context) throws IOException, InterruptedException {
  }

  @Override
  protected void reduce(Text key, Iterable<NullWritable> values, Context context) throws IOException, InterruptedException {
    //TODO:
  }
}

在这里，reducer输出的key、value类型都是NullWritable，我们不用关心，这不是本文的关注点。

如果reduce()方法漏掉了 @Override 注解，并且把  Reducer<Text, NullWritable, NullWritable, NullWritable> 错误地写成了 Reducer<Text, Text, NullWritable, NullWritable>，会发现编译并不报错。
但是，当你跑这个job的时候，诡异的事情就来了。你会发现，你在“TODO:”那里写的reduce逻辑并没有执行，即使没有用 context.write() 方法把任何数据输出到HDFS上，Hadoop counter仍然显示该job输出了和reducer输入一样多的数据。
从现象上看，就像是执行了一个默认的Reducer，把reducer的输入数据原样输出。
文章来源：https://www.codelast.com/
所以这里不得不强调，一定不要漏写 @Override 注解！有这个注解的时候，IDE就会提示错误，编译就会失败！

在本文的例子中，如果reduce()方法没有写 @Override 注解，那么当reducer类错误地定义成了extends Reducer<Text, Text, NullWritable, NullWritable>的时候，IDE并不会发现reduce()方法有错，从而让你误以为一切正常。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

  -D "mapreduce.map.memory.mb=8192" \
  -D "mapreduce.reduce.memory.mb=8192" \
  -D "mapreduce.map.java.opts=-Xmx6144m" \
  -D "mapreduce.reduce.java.opts=-Xmx6144m" \

对Apache Pig M-R job，在Pig代码中添加如下语句：

SET mapreduce.map.memory.mb 8192;
SET mapreduce.reduce.memory.mb 8192;
SET mapreduce.map.java.opts -Xmx6144m;
SET mapreduce.reduce.java.opts -Xmx6144m;

其中，第1、2个参数需要你根据Hadoop集群的情况自行调整，第3、4个参数设置成第1、2个参数的70%～80%

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：

{

 "model_version_status": [

  {

   "version": "1684833957",

   "state": "AVAILABLE",

   "status": {

    "error_code": "OK",

    "error_message": ""

   }

  }

 ]

}

其中，version就是我们要找的东西。
到你保存.pb模型的父目录下（可能是HDFS或本地磁盘），无脑搜version对应的关键字 1684833957，找到哪个目录，就是我们要找的.pb模型所在的目录。
通常这个目录下会有一个 saved_model.pb 文件，以及一个 variables 子目录。
为什么可以这样做？因为version里的时间戳就是导出 .pb 模型的时间戳，这个时间戳精确到秒，一般情况下，两个模型几乎不太可能在同一秒生成，所以这个时间戳是唯一的，因此只要能找到这个目录名，那么目录里的 .pb 模型几乎肯定是我们要找的模型。

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：