Question

我正在尝试使用Databricks存储dbfs：/作为检查点和文件存储位置在Azure Databricks中进行结构化流传输。我正在将事件数据从Azure事件中心流式传输到dbfs上的镶木地板文件。

当我取消查询并重新启动时，我得到了可怕的非法状态异常。

由以下原因引起：java.lang.IllegalStateException：压缩批处理9（compactInterval：10）时不存在dbfs：/ test02 / _spark_metadata / 2

我正在尝试找出Azure事件中心conf conf startingPosition选项，检查点偏移量和提交日志以及存储位置_spark_metadata信息之间的关系。

为什么重启时会出现非法状态？Spark使用不同的日志和元数据信息吗？

有10个名为0到9的偏移日志文件。9个名为0到8的提交日志文件。显然，如果最后一批已被完全处理，则应该有另一个提交日志文件。

commmit日志文件似乎不包含任何相关信息，为什么我认为重要的是它们的纯存在（名称）。

commit log file:
v1
{"nextBatchWatermarkMs":0}

偏移日志仅包含有关每个分区的偏移的信息。

{
    "batchWatermarkMs": 0,
    "batchTimestampMs": 1542634173589,
    "conf": {
        "spark.sql.shuffle.partitions": "200",
        "spark.sql.streaming.stateStore.providerClass": "org.apache.spark.sql.execution.streaming.state.HDFSBackedStateStoreProvider",
        "spark.sql.streaming.multipleWatermarkPolicy": "min",
        "spark.sql.streaming.flatMapGroupsWithState.stateFormatVersion": "2"
    }
}
{
    "poc-test01": {
        "1": 3666,
        "0": 3664
    }
}

如果我理解正确，那么结构化流式处理有一个循环，它首先在offset /文件夹中写入一个预写日志。然后处理批处理数据。然后在commit /文件夹中写入一个Commit Log。每个批次都会触发一个新周期。

_spark_metadata /文件夹仅包含两个日志文件（0和1），每个文件都包含有关filepath /文件夹中两个镶木地板文件的信息。

{
    "path": "dbfs:/test02/part-00000-98c5def2-bdf3-4e56-af9f-ff0796344b01-c000.snappy.parquet",
    "size": 59180,
    "isDir": false,
    "modificationTime": 1542214122000,
    "blockReplication": 1,
    "blockSize": 536870912,
    "action": "add"
}
{
    "path": "dbfs:/test02/part-00001-a38dbf8b-240a-48d0-8438-f81f0506a79c-c000.snappy.parquet",
    "size": 59462,
    "isDir": false,
    "modificationTime": 1542214122000,
    "blockReplication": 1,
    "blockSize": 536870912,
    "action": "add"
}

文件路径/文件夹中有10个镶木地板文件，事件中心包含两个分区。

我现在最好的猜测是_spark_metadata /文件夹用于文件接收器中的幂等。 Spark应该能够跟踪从源偏移位置到_spark_metadata /文件夹所在的filepath /文件夹中的已创建文件的已处理批次。不知何故，这破了。

检查点和文件存储元数据处理的组合是否记录在某处？似乎像一个巨大的黑匣子，似乎可以正常工作。
这是结构化的流媒体错误还是文件接收器检查点错误？
如何返回上一个工作状态？

Databricks结构化流非法状态异常

0 个答案: