BigQuery UDF 内存在多行上超出错误，但在单行上工作正常

Question

我正在编写一个 UDF 来处理 Google Analytics 数据，并在我尝试处理多行时收到“UDF 内存不足”错误消息。我下载了原始数据并找到了最大的记录，并尝试在其上运行我的 UDF 查询，并成功。一些行有多达 500 个嵌套命中，命中记录的大小（到目前为止，原始 GA 数据的每一行的最大组成部分）似乎确实会影响我在收到错误之前可以处理多少行.

例如查询

select 
    user.ga_user_id, 
    ga_session_id, 
        ...
from 
    temp_ga_processing(
        select 
            fullVisitorId, 
            visitNumber, 
                   ...            
        from [79689075.ga_sessions_20160201] limit 100)

返回错误，但是

from [79689075.ga_sessions_20160201] where totals.hits = 500 limit 1) 

没有。

我的印象是任何内存限制都是每行的？我尝试了几种技术，例如在emit(return_dict); 之前设置row = null;（其中return_dict 是处理后的数据）但无济于事。

UDF 本身并没有做任何花哨的事情；我会把它贴在这里，但它的长度约为 45 kB。它基本上做了很多事情：

function temp_ga_processing(row, emit) {
  topic_id = -1;
  hit_numbers = [];
  first_page_load_hits = [];
  return_dict = {};
  return_dict["user"] = {};
  return_dict["user"]["ga_user_id"] = row.fullVisitorId;
  return_dict["ga_session_id"] = row.fullVisitorId.concat("-".concat(row.visitNumber));
  for(i=0;i<row.hits.length;i++) {
    hit_dict = {};
    hit_dict["page"] = {};
    hit_dict["time"] = row.hits[i].time;
    hit_dict["type"] = row.hits[i].type;
    hit_dict["page"]["engaged_10s"] = false;
    hit_dict["page"]["engaged_30s"] = false;
    hit_dict["page"]["engaged_60s"] = false;

    add_hit = true;
    for(j=0;j<row.hits[i].customMetrics.length;j++) {
      if(row.hits[i].customDimensions[j] != null) {
        if(row.hits[i].customMetrics[j]["index"] == 3) {
          metrics = {"video_play_time": row.hits[i].customMetrics[j]["value"]};
          hit_dict["metrics"] = metrics;
          metrics = null;
          row.hits[i].customDimensions[j] = null;
        }
      }
    }

    hit_dict["topic"] = {};
    hit_dict["doctor"] = {};
    hit_dict["doctor_location"] = {};
    hit_dict["content"] = {};

    if(row.hits[i].customDimensions != null) {
      for(j=0;j<row.hits[i].customDimensions.length;j++) {
        if(row.hits[i].customDimensions[j] != null) {
          if(row.hits[i].customDimensions[j]["index"] == 1) {
            hit_dict["topic"] = {"name": row.hits[i].customDimensions[j]["value"]};
            row.hits[i].customDimensions[j] = null;
            continue;
          }
          if(row.hits[i].customDimensions[j]["index"] == 3) {
            if(row.hits[i].customDimensions[j]["value"].search("doctor") > -1) {
              return_dict["logged_in_as_doctor"] = true;
            }
          }
          // and so on...
        }
      }
    }
    if(row.hits[i]["eventInfo"]["eventCategory"] == "page load time" && row.hits[i]["eventInfo"]["eventLabel"].search("OUTLIER") == -1) {
      elre = /(?:onLoad|pl|page):(\d+)/.exec(row.hits[i]["eventInfo"]["eventLabel"]);
      if(elre != null) {
        if(parseInt(elre[0].split(":")[1]) <= 60000) {
          first_page_load_hits.push(parseFloat(row.hits[i].hitNumber));
          if(hit_dict["page"]["page_load"] == null) {
            hit_dict["page"]["page_load"] = {};
          }
          hit_dict["page"]["page_load"]["sample"] = 1;
          page_load_time_re = /(?:onLoad|pl|page):(\d+)/.exec(row.hits[i]["eventInfo"]["eventLabel"]);
          if(page_load_time_re != null) {
            hit_dict["page"]["page_load"]["page_load_time"] = parseFloat(page_load_time_re[0].split(':')[1])/1000;
          }
        }
        // and so on...  
      }
    }    
  row = null;
  emit return_dict;
}

作业ID是realself-main:bquijob_4c30bd3d_152fbfcd7fd

Answer 1

2016 年 8 月更新：我们推出了一项更新，允许 JavaScript 工作线程使用两倍的 RAM。我们将继续监视因 JS OOM 失败的作业，看看是否需要增加更多；同时，如果您还有其他工作因 OOM 失败，请告诉我们。谢谢！

更新：这个问题与我们对 UDF 代码大小的限制有关。看起来 V8 的 UDF 代码的优化+重新编译过程生成的数据段大于我们的限制，但这仅在 UDF 运行“足够”行数时发生。本周我将与 V8 团队会面，以进一步深入了解细节。

@Grayson - 我能够成功地在整个 20160201 表上运行你的工作；查询需要 1-2 分钟才能执行。您能否确认这对您有效？

---

我们收到了一些类似问题的报告，这些问题似乎与已处理的 # 行有关。很抱歉给您带来麻烦；我将对我们的 JavaScript 运行时进行一些分析，以尝试找出内存是否泄漏以及在何处泄漏。请继续关注分析。

与此同时，如果您能够隔离导致错误的任何特定行，那也将非常有帮助。

Answer 2

如果 UDF 有很多 if/then 级别，那么它会在除非常小的数据集之外的任何数据集上失败，例如：
如果 () {
.... if() {
.........if () {
等等

我们必须追踪并删除最深的 if/then 语句。

但是，这还不够。此外，当您将数据传递到 UDF 时，对所有变量运行“GROUP EACH BY”。这将迫使 BQ 将输出发送给多个“工人”。否则也会失败。

我已经在这个烦人的错误上浪费了 3 天的时间。啊。

Answer 3

我喜欢在 BigQuery 中解析我的日志的概念，但我也遇到了同样的问题，我明白了

错误：查询执行期间资源超出。

作业 ID 是 bigquery-looker:bquijob_260be029_153dd96cfdb，如果这有帮助的话。

我编写了一个非常基本的解析器，它进行简单的匹配并返回行。在 10K 行数据集上运行良好，但在尝试针对 3M 行日志文件运行时资源不足。

有什么解决方法的建议吗？

这里是javascript代码。

function parseLogRow(row, emit) {

  r =  (row.logrow ? row.logrow : "") + (typeof row.l2 !== "undefined" ? " " + row.l2 : "") + (row.l3 ? " " + row.l3 : "")
  ts = null
  category = null
  user = null
  message = null
  db = null
  found = false
  if (r) {
      m = r.match(/^(\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d\.\d\d\d (\+|\-)\d\d\d\d) \[([^|]*)\|([^|]*)\|([^\]]*)\] :: (.*)/ )
      if( m){
        ts = new Date(m[1])/1000
        category = m[3] || null
        user = m[4] || null
        db = m[5] || null
        message = m[6] || null
        found = true
      }
      else {
        message = r
        found = false
      }
   }

  emit({
    ts:  ts,
    category: category,
    user: user,
    db: db,
    message: message,
    found: found
    });
}

bigquery.defineFunction(
  'parseLogRow',                           // Name of the function exported to SQL
  ['logrow',"l2","l3"],                    // Names of input columns
  [
    {'name': 'ts', 'type': 'timestamp'},  // Output schema
    {'name': 'category', 'type': 'string'},
    {'name': 'user', 'type': 'string'},
    {'name': 'db', 'type': 'string'},
    {'name': 'message', 'type': 'string'},
    {'name': 'found', 'type': 'boolean'},
  ],
  parseLogRow                          // Reference to JavaScript UDF
);