AlienPaul
AlienPaul

Hudi 源码之数据写入逻辑

背景

本篇以Flink操作Hudi表为例，分析COW表和MOR表的upsert以及insert操作详细的执行流程。

StreamWriteFunction

Hudi Flink的StreamWriteFunction负责将数据流写入Hudi表。因此我们从StreamWriteFunction的处理数据方法processElement开始分析。

processElement方法将数据缓存到buckets中。bucket的按照一定规则定期flush数据。

@Override
public void processElement(I value, ProcessFunction.Context ctx, Collector out) throws Exception {
    bufferRecord((HoodieRecord) value);
}
 
 
DataBucket为数据写入缓存。缓存了需要写入某个partition path和fileID之下的一批record。
 
 
Bucket中的数据不是无限累加的。满足下面2个条件之一会触发flush bucket：
 
 
     
  
  1. 如果某个DataBucket数据累积够FlinkOptions#WRITE_BATCH_SIZE会flush这个bucket。
    2.  
  
  2. 如果缓存的数据总大小超过FlinkOptions#WRITE_TASK_MAX_SIZE，会flush缓存数据最多的bucket。
    3.  
 
 
 
上面逻辑在bufferRecord方法中，内容如下：
 
 
protected void bufferRecord(HoodieRecord value) {
    // 根据HoodieRecord的partitionPath和fileId构建bucketID
    final String bucketID = getBucketID(value);

    // 将数据封装为DataBucket，放入buckets中
    DataBucket bucket = this.buckets.computeIfAbsent(bucketID,
                                                     k -> new DataBucket(this.config.getDouble(FlinkOptions.WRITE_BATCH_SIZE), value));
    // 转换HoodieRecord为DataItem类型
    final DataItem item = DataItem.fromHoodieRecord(value);
    // 存放入bucket中
    bucket.records.add(item);

    // 检查bucket中数据总大小是否超过batch size限制
    // 为了提高性能，并非每次都精确计算record的大小。而是计算出第一条数据的大小之后，以后每次数据到来都沿用这个大小来累加
    // 内部有一个采样函数，有百分之一的概率重新计算当前record的大小，然后再次沿用这个值，一直重复
    boolean flushBucket = bucket.detector.detect(item);
    // 检查总buffer数据大小是否超过write task max size
    boolean flushBuffer = this.tracer.trace(bucket.detector.lastRecordSize);
    if (flushBucket) {
        // 如果需要flush这个bucket，调用flushBucket
        if (flushBucket(bucket)) {
            // 然后buffer总大小减去这个bucket的数据量
            this.tracer.countDown(bucket.detector.totalSize);
            // 重置这个bucket
            bucket.reset();
        }
    } else if (flushBuffer) {
        // find the max size bucket and flush it out
        // 如果需要flush数据最多的bucket
        // 找出totalSize最大的dataBucket
        DataBucket bucketToFlush = this.buckets.values().stream()
            .max(Comparator.comparingLong(b -> b.detector.totalSize))
            .orElseThrow(NoSuchElementException::new);
        // 然后flush这个bucket
        if (flushBucket(bucketToFlush)) {
            this.tracer.countDown(bucketToFlush.detector.totalSize);
            bucketToFlush.reset();
        } else {
            LOG.warn("The buffer size hits the threshold {}, but still flush the max size data bucket failed!", this.tracer.maxBufferSize);
        }
    }
}

 
 
接下来是flushBucket方法，内容如下：
 
 
private boolean flushBucket(DataBucket bucket) {
    // 获取上一次成功checkpoint的时间
    String instant = instantToWrite(true);

    if (instant == null) {
        // in case there are empty checkpoints that has no input data
        LOG.info("No inflight instant when flushing data, skip.");
        return false;
    }

    // 获取缓存的数据
    List records = bucket.writeBuffer();
    // 检查缓存的数据数量必须大于0
    ValidationUtils.checkState(records.size() > 0, "Data bucket to flush has no buffering records");
    // 如果需要在insert/upsert之前去除重复数据
    if (config.getBoolean(FlinkOptions.PRE_COMBINE)) {
        Properties props = new Properties();
        config.addAllToProperties(props);
        // 调用deduplicateRecords去除重复数据
        records = (List) FlinkWriteHelper.newInstance()
            .deduplicateRecords(records, (HoodieIndex) null, -1, this.writeClient.getConfig().getSchema(), props, recordMerger);
    }
    // 在flush之前执行预写入逻辑，赋给第一个record正确的partition path和fileID
    bucket.preWrite(records);
    // 调用writeFunction方法
    // writeFunction的创建下文分析
    final List writeStatus = new ArrayList<>(writeFunction.apply(records, instant));
    // 清空缓存
    records.clear();
    // 构建元数据写入事件
    final WriteMetadataEvent event = WriteMetadataEvent.builder()
        .taskID(taskID)
        .instantTime(instant) // the write instant may shift but the event still use the currentInstant.
        .writeStatus(writeStatus)
        .lastBatch(false)
        .endInput(false)
        .build();

    // 发送这个事件到coordinator
    this.eventGateway.sendEventToCoordinator(event);
    // 加入写入状态到writeStatuses集合
    writeStatuses.addAll(writeStatus);
    // 返回flush成功
    return true;
}

 
 
StreamWriteFunction会在snapshotState的时候调用flushRemaining方法，确保创建快照的时候将缓存的数据都发送出去。方法逻辑和flushBucket基本相同，不再赘述。
 
 
这里可以总结一下Flink Hudi刷写数据到磁盘的3个时机：
 
 
     
  
  1. 某个bucket数据量达到配置的bucket最大容量，刷写这个bucket
    2.  
  
  2. 所有bucket数据量总和达到了配置值，刷写数据量最多的bucket
    3.  
  
  3. Flink checkpoint的时候，刷写所有的缓存数据
    4.  
 
 
 
上面提到的writeFunction由initWriteFunction方法创建出来，根据不同的操作类型，创建出不同的writeFunction。代码逻辑如下:
 
 
private void initWriteFunction() {
    final String writeOperation = this.config.get(FlinkOptions.OPERATION);
    switch (WriteOperationType.fromValue(writeOperation)) {
        case INSERT:
            this.writeFunction = (records, instantTime) -> this.writeClient.insert(records, instantTime);
            break;
        case UPSERT:
            this.writeFunction = (records, instantTime) -> this.writeClient.upsert(records, instantTime);
            break;
        case INSERT_OVERWRITE:
            this.writeFunction = (records, instantTime) -> this.writeClient.insertOverwrite(records, instantTime);
            break;
        case INSERT_OVERWRITE_TABLE:
            this.writeFunction = (records, instantTime) -> this.writeClient.insertOverwriteTable(records, instantTime);
            break;
        default:
            throw new RuntimeException("Unsupported write operation : " + writeOperation);
    }
}

 
 
这里的writeClient为HoodieFlinkWriteClient。分为4种逻辑：
 
 
     
  
  • insert
    •  
  
  • upsert
    •  
  
  • insertOverwrite
    •  
  
  • insertOverwriteTable
    •  
 
 
 
下面以upsert操作为例分析writeClient.upsert方法。
 
 
COW Upsert逻辑
 
 
HoodieFlinkWriteClient
 
 
继续上一节末尾分析HoodieFlinkWriteClient的upsert方法。代码如下：
 
 
@Override
public List upsert(List> records, String instantTime) {
    // 创建HoodieTable
    HoodieTable>, List, List> table =
        initTable(WriteOperationType.UPSERT, Option.ofNullable(instantTime));
    // 校验schema是否和数据兼容
    table.validateUpsertSchema();
    // 配置operationType为UPSERT
    preWrite(instantTime, WriteOperationType.UPSERT, table.getMetaClient());
    HoodieWriteMetadata> result;
    // 根据不同的操作类型创建出对应的HoodieWriteHandle，它封装了各种操作类型的数据写入逻辑
    // AutoCloseableWriteHandle为包装类，在try块结束的时候调用writeHandle的closeGracefully关闭它
    try (AutoCloseableWriteHandle closeableHandle = new AutoCloseableWriteHandle(records, instantTime, table)) {
        // 调用table的upsert方法执行upsert，具体操作方法由closeableHandle.getWriteHandle()提供
        result = ((HoodieFlinkTable) table).upsert(context, closeableHandle.getWriteHandle(), instantTime, records);
    }
    // 更新监控信息
    if (result.getIndexLookupDuration().isPresent()) {
        metrics.updateIndexMetrics(LOOKUP_STR, result.getIndexLookupDuration().get().toMillis());
    }
    // 执行写入后逻辑，更新监控信息
    return postWrite(result, instantTime, table);
}

 
 
这个方法将upsert逻辑交给了HoodieFlinkTable去执行。负责具体怎么写入的处理逻辑在closeableHandle.getWriteHandle()中。接下来分别介绍WriteHandle的创建过程和HoodieFlinkTable的执行过程。
 
 
WriteHandle创建过程
 
 
在分析upsert方法之前， 需要先搞清楚什么条件下使用的具体是哪个writeHandle。这一段内容中我们分析writeHandle的创建逻辑。
 
 
Hudi提供了多种Handle，分别对应不同类型的写入方式。
 
 
writeHandle通过AutoCloseableWriteHandle创建出来。上一节代码中AutoCloseableWriteHandle的构造函数内容如下：
 
 
AutoCloseableWriteHandle(
    List> records,
    String instantTime,
    HoodieTable>, List, List> table
) {
    this.writeHandle = getOrCreateWriteHandle(records.get(0), getConfig(), instantTime, table, records.listIterator());
}

 
 
上面又调用了getOrCreateWriteHandle方法：
 
 
private HoodieWriteHandle getOrCreateWriteHandle(
    HoodieRecord record,
    HoodieWriteConfig config,
    String instantTime,
    HoodieTable>, List, List> table,
    Iterator> recordItr) {
    // caution: it's not a good practice to modify the handles internal.
    FlinkWriteHandleFactory.Factory>,
    List,
    List> writeHandleFactory = FlinkWriteHandleFactory.getFactory(table.getMetaClient().getTableConfig(), config);
    return writeHandleFactory.create(this.bucketToHandles, record, config, instantTime, table, recordItr);
}

 
 
这里使用writeHandleFactory工厂类创建writeHandle。FlinkWriteHandleFactory根据不同的table配置和写入配置，创建符合要求的writeHandleFactory。FlinkWriteHandleFactory.getFactory方法内容为：
 
 
public static  Factory getFactory(
    HoodieTableConfig tableConfig,
    HoodieWriteConfig writeConfig) {
    // 如果允许key重复
    if (writeConfig.allowDuplicateInserts()) {
        return ClusterWriteHandleFactory.getInstance();
    }
    // 如果是MOR类型表
    if (tableConfig.getTableType().equals(HoodieTableType.MERGE_ON_READ)) {
        return DeltaCommitWriteHandleFactory.getInstance();
    } else if (tableConfig.isCDCEnabled()) {
        // 如果启用了CDC
        return CdcWriteHandleFactory.getInstance();
    } else {
        // 如果是COW类型表
        return CommitWriteHandleFactory.getInstance();
    }
}

 
 
如果是COW类型表，返回的是CommitWriteHandleFactory（对于COW表而言每次写入都是commit，而MOR表写入时delta commit，只有compaction生成parquet文件的时候才是commit）。继续分析writeHandleFactory的create方法，它位于父类BaseCommitWriteHandleFactory中，代码如下：
 
 
@Override
public HoodieWriteHandle create(
    Map bucketToHandles,
    HoodieRecord record,
    HoodieWriteConfig config,
    String instantTime,
    HoodieTable table,
    Iterator> recordItr) {
    final HoodieRecordLocation loc = record.getCurrentLocation();
    final String fileID = loc.getFileId();
    final String partitionPath = record.getPartitionPath();

    Path writePath = bucketToHandles.get(fileID);
    // record对应的文件存在，创建replaceHandle
    if (writePath != null) {
        HoodieWriteHandle writeHandle =
            createReplaceHandle(config, instantTime, table, recordItr, partitionPath, fileID, writePath);
        bucketToHandles.put(fileID, ((MiniBatchHandle) writeHandle).getWritePath()); // override with new replace handle
        return writeHandle;
    }

    final HoodieWriteHandle writeHandle;
    // 新增数据，创建FlinkCreateHandle
    if (loc.getInstantTime().equals("I")) {
        writeHandle = new FlinkCreateHandle<>(config, instantTime, table, partitionPath,
                                              fileID, table.getTaskContextSupplier());
    } else {
        // 创建mergeHandle
        writeHandle = createMergeHandle(config, instantTime, table, recordItr, partitionPath, fileID);
    }
    bucketToHandles.put(fileID, ((MiniBatchHandle) writeHandle).getWritePath());
    return writeHandle;
}

 
 
对于CommitWriteHandleFactory而言，createReplaceHandle返回的是FlinkMergeAndReplaceHandle。createMergeHandle返回的是FlinkMergeHandle。
 
 
Handle的创建过程到这里分析完了。接下来分析HoodieFlinkCopyOnWriteTable。
 
 
HoodieFlinkCopyOnWriteTable
 
 
HoodieFlinkWriteClient的upsert方法调用了HoodieFlinkTable的upsert方法。HoodieFlinkTable顾名思义，代表了Flink下管理的Hudi table。它有两个子类：
 
 
     
  
  • HoodieFlinkCopyOnWriteTable：对应COW表
    •  
  
  • HoodieFlinkMergeOnReadTable：对应MOR表
    •  
 
 
 
由于本章是围绕COW表分析。我们查看HoodieFlinkCopyOnWriteTable的upsert方法：
 
 
public HoodieWriteMetadata> upsert(
    HoodieEngineContext context,
    HoodieWriteHandle writeHandle,
    String instantTime,
    List> records) {
    return new FlinkUpsertCommitActionExecutor<>(context, writeHandle, config, this, instantTime, records).execute();
}

 
 
FlinkUpsertCommitActionExecutor这个类负责执行upsert动作。它的execute方法又调用了FlinkWriteHelper的write方法：
 
 
@Override
public HoodieWriteMetadata execute() {
    return FlinkWriteHelper.newInstance().write(instantTime, inputRecords, context, table,
                                                config.shouldCombineBeforeUpsert(), config.getUpsertShuffleParallelism(), this, operationType);
}

 
 
逻辑流转到了FlinkWriteHelper中，下面对它展开分析。
 
 
FlinkWriteHelper
 
 
由于每条数据已经被标记了bucket ID（partition path和fileID），这里直接将数据交给executor(BaseFlinkCommitActionexecutor)执行写入操作。数据标记bucket ID的逻辑位于BucketAssignFunction，后面分析。
 
 
@Override
public HoodieWriteMetadata> write(String instantTime, List> inputRecords, HoodieEngineContext context,
                                                    HoodieTable>, List, List> table, boolean shouldCombine, int configuredShuffleParallelism,
                                                    BaseCommitActionExecutor>, List, List, R> executor, WriteOperationType operationType) {
    try {
        Instant lookupBegin = Instant.now();
        Duration indexLookupDuration = Duration.between(lookupBegin, Instant.now());
        // 执行写入操作
        HoodieWriteMetadata> result = executor.execute(inputRecords);
        result.setIndexLookupDuration(indexLookupDuration);
        return result;
    } catch (Throwable e) {
        if (e instanceof HoodieUpsertException) {
            throw (HoodieUpsertException) e;
        }
        throw new HoodieUpsertException("Failed to upsert for commit time " + instantTime, e);
    }
}

 
 
跟踪代码可以发现execute位于BaseFlinkCommitActionExecutor。我们继续分析。
 
 
BaseFlinkCommitActionExecutor
 
 
因为record被标记bucket ID之后，Flink能够按照bucket ID进行分发操作。这样executor处理的一批数据是属于同一个bucket的。
 
 
@Override
public HoodieWriteMetadata> execute(List> inputRecords) {
    HoodieWriteMetadata> result = new HoodieWriteMetadata<>();

    List writeStatuses = new LinkedList<>();
    // 获取这批数据的partition path和file ID
    // 因为数据是按照bucket ID进行分发，所以说同一批数据属于同一个bucket。这里只获取第一个数据的信息就可以了
    final HoodieRecord record = inputRecords.get(0);
    final String partitionPath = record.getPartitionPath();
    final String fileId = record.getCurrentLocation().getFileId();
    // 从instant time还原回bucket类型，是新增还是更新
    final BucketType bucketType = record.getCurrentLocation().getInstantTime().equals("I")
        ? BucketType.INSERT
        : BucketType.UPDATE;
    // 处理分区upsert
    handleUpsertPartition(
        instantTime,
        partitionPath,
        fileId,
        bucketType,
        inputRecords.iterator())
        .forEachRemaining(writeStatuses::addAll);
    // 设置写入操作元数据，包括写入状态和耗时
    setUpWriteMetadata(writeStatuses, result);
    return result;
}

 
 
继续分析handleUpsertPartition方法：
 
 
protected Iterator> handleUpsertPartition(
    String instantTime,
    String partitionPath,
    String fileIdHint,
    BucketType bucketType,
    Iterator recordItr) {
    try {
        if (this.writeHandle instanceof HoodieCreateHandle) {
            // During one checkpoint interval, an insert record could also be updated,
            // for example, for an operation sequence of a record:
            //    I, U,   | U, U
            // - batch1 - | - batch2 -
            // the first batch(batch1) operation triggers an INSERT bucket,
            // the second batch batch2 tries to reuse the same bucket
            // and append instead of UPDATE.
            return handleInsert(fileIdHint, recordItr);
        } else if (this.writeHandle instanceof HoodieMergeHandle) {
            return handleUpdate(partitionPath, fileIdHint, recordItr);
        } else {
            switch (bucketType) {
                case INSERT:
                    return handleInsert(fileIdHint, recordItr);
                case UPDATE:
                    return handleUpdate(partitionPath, fileIdHint, recordItr);
                default:
                    throw new AssertionError();
            }
        }
    } catch (Throwable t) {
        String msg = "Error upsetting bucketType " + bucketType + " for partition :" + partitionPath;
        LOG.error(msg, t);
        throw new HoodieUpsertException(msg, t);
    }
}

 
 
上面方法根据writeHandle类型确认调用insert逻辑还是update逻辑。如果根据writeHandle无法明确区分，则使用bucketType判断。
 
 
insert操作对应的是handleInsert方法：
 
 
@Override
public Iterator> handleInsert(String idPfx, Iterator> recordItr)
    throws Exception {
    // This is needed since sometimes some buckets are never picked in getPartition() and end up with 0 records
    if (!recordItr.hasNext()) {
        LOG.info("Empty partition");
        return Collections.singletonList((List) Collections.EMPTY_LIST).iterator();
    }
    return new FlinkLazyInsertIterable<>(recordItr, true, config, instantTime, table, idPfx,
                                         taskContextSupplier, new ExplicitWriteHandleFactory<>(writeHandle));
}

 
 
这里将record的iterator包装在了FlinkLazyInsertIterable中。FlinkLazyInsertIterable是一种延迟写入的迭代器。只有在遍历获取写入状态的时候才会真正执行数据写入。
 
 
update操作对应的是handleUpdate方法：
 
 
@Override
public Iterator> handleUpdate(String partitionPath, String fileId,
                                                Iterator> recordItr)
    throws IOException {
    // This is needed since sometimes some buckets are never picked in getPartition() and end up with 0 records
    if (!recordItr.hasNext()) {
        LOG.info("Empty partition with fileId => " + fileId);
        return Collections.singletonList((List) Collections.EMPTY_LIST).iterator();
    }
    // these are updates
    HoodieMergeHandle upsertHandle = (HoodieMergeHandle) this.writeHandle;
    return handleUpdateInternal(upsertHandle, fileId);
}

 
 
handleUpdateInternal方法逻辑在后面更新数据逻辑中分析。
 
 
插入数据逻辑
 
 
FlinkLazyInsertIterable
 
 
这里继续分析上面提到的FlinkLazyInsertIterable类。FlinkLazyInsertIterable继承了LazyIterableIterator。LazyIterableIterator在遍历的时候将数据写入底层文件。通过分析代码我们可以看到LazyIterableIterator的next方法调用了computeNext方法。
 
 
@Override
public O next() {
    try {
        return computeNext();
    } catch (Exception ex) {
        throw new RuntimeException(ex);
    }
}

 
 
computeNext方法的实现位于子类FlinkLazyInsertIterable中。这个方法执行了数据写入逻辑。代码如下：
 
 
@Override
protected List computeNext() {
    // Executor service used for launching writer thread.
    HoodieExecutor> bufferedIteratorExecutor = null;
    try {
        // 获取record的schema
        final Schema schema = new Schema.Parser().parse(hoodieConfig.getSchema());
        // 创建了批量执行器
        // 消费（写入）数据的逻辑由getExplicitInsertHandler提供
        // 消费前数据的变形（transform）操作由getTransformer提供，将record，schema和写入配置包装在一起
        bufferedIteratorExecutor = ExecutorFactory.create(hoodieConfig, inputItr, getExplicitInsertHandler(),
                                                          getTransformer(schema, hoodieConfig));
        // 执行写入
        final List result = bufferedIteratorExecutor.execute();
        checkState(result != null && !result.isEmpty());
        return result;
    } catch (Exception e) {
        throw new HoodieException(e);
    } finally {
        if (null != bufferedIteratorExecutor) {
            bufferedIteratorExecutor.shutdownNow();
            bufferedIteratorExecutor.awaitTermination();
        }
    }
}

 
 
数据的写入逻辑由getExplicitInsertHandler方法创建：
 
 
  private ExplicitWriteHandler getExplicitInsertHandler() {
    HoodieWriteHandle handle = ((ExplicitWriteHandleFactory) writeHandleFactory).getWriteHandle();
    return new ExplicitWriteHandler(handle);
  }

 
 
bufferedIteratorExecutor调用ExplicitWriteHandler的consumer方法处理数据。我们看下ExplicitWriteHandler的consume方法：
 
 
@Override
public void consume(HoodieLazyInsertIterable.HoodieInsertValueGenResult genResult) {
    final HoodieRecord insertPayload = genResult.getResult();
    handle.write(insertPayload, genResult.schema, new TypedProperties(genResult.props));
}

 
 
FlinkCreateHandle
 
 
它调用了HoodieWriteHandle的write方法，又调用了子类的doWrite方法。这里的HoodieWriteHandle实现类为FlinkCreateHandle。它的doWrite方法位于父类HoodieCreateHandle中，内容如下：
 
 
@Override
protected void doWrite(HoodieRecord record, Schema schema, TypedProperties props) {
    Option> recordMetadata = record.getMetadata();
    try {
        // 如果record不需要删除
        if (!HoodieOperation.isDelete(record.getOperation()) && !record.isDelete(schema, config.getProps())) {
            // 是否需要忽略
            if (record.shouldIgnore(schema, config.getProps())) {
                return;
            }

            // 为record增加metadata字段
            MetadataValues metadataValues = new MetadataValues().setFileName(path.getName());
            HoodieRecord populatedRecord =
                record.prependMetaFields(schema, writeSchemaWithMetaFields, metadataValues, config.getProps());

            // 判断是否写入metadata数据，CreateHandleFactory默认指定preserveMetadata为false
            if (preserveMetadata) {
                fileWriter.write(record.getRecordKey(), populatedRecord, writeSchemaWithMetaFields);
            } else {
                fileWriter.writeWithMetadata(record.getKey(), populatedRecord, writeSchemaWithMetaFields);
            }

            // Update the new location of record, so we know where to find it next
            // 解除sealed（密封）状态，密封的record无法setCurrentLocation和setNewLocation
            record.unseal();
            // 配置record的新location，绑定record和它从属的fileID
            record.setNewLocation(new HoodieRecordLocation(instantTime, writeStatus.getFileId()));
            // 重新密封
            record.seal();

            // 已写入数据条数加1
            recordsWritten++;
            // insert数据条数加1
            insertRecordsWritten++;
        } else {
            recordsDeleted++;
        }
        // 标记写入成功
        writeStatus.markSuccess(record, recordMetadata);
        // deflate record payload after recording success. This will help users access payload as a
        // part of marking
        // record successful.
        // 清空HoodieRecord的数据负载
        record.deflate();
    } catch (Throwable t) {
        // Not throwing exception from here, since we don't want to fail the entire job
        // for a single record
        writeStatus.markFailure(record, t, recordMetadata);
        LOG.error("Error writing record " + record, t);
    }
}

 
 
以上是写入数据的流程。接下来分析fileWriter的创建流程和具体的写入方法。
 
 
FileWriter创建流程
 
 
获取fileWriter的逻辑位于HoodieFileWriterFactory的getFileWriter方法，代码如下：
 
 
public static  HoodieFileWriter getFileWriter(
    String instantTime, Path path, Configuration conf, HoodieConfig config, Schema schema,
    TaskContextSupplier taskContextSupplier, HoodieRecordType recordType) throws IOException {
    final String extension = FSUtils.getFileExtension(path.getName());
    HoodieFileWriterFactory factory = getWriterFactory(recordType);
    return factory.getFileWriterByFormat(extension, instantTime, path, conf, config, schema, taskContextSupplier);
}

 
 
getWriterFactory方法根据record类型选用fileWriterFactory：
 
 
private static HoodieFileWriterFactory getWriterFactory(HoodieRecord.HoodieRecordType recordType) {
    switch (recordType) {
        case AVRO:
            return new HoodieAvroFileWriterFactory();
        case SPARK:
            try {
                Class clazz = ReflectionUtils.getClass("org.apache.hudi.io.storage.HoodieSparkFileWriterFactory");
                return (HoodieFileWriterFactory) clazz.newInstance();
            } catch (IllegalAccessException | IllegalArgumentException | InstantiationException e) {
                throw new HoodieException("Unable to create hoodie spark file writer factory", e);
            }
        default:
            throw new UnsupportedOperationException(recordType + " record type not supported yet.");
    }
}

 
 
通过上面代码可知AVRO类型返回的是HoodieAvroFileWriterFactory。获取到factory之后，在根据文件格式，确定创建哪种具体的writer：
 
 
protected  HoodieFileWriter getFileWriterByFormat(
    String extension, String instantTime, Path path, Configuration conf, HoodieConfig config, Schema schema,
    TaskContextSupplier taskContextSupplier) throws IOException {
    if (PARQUET.getFileExtension().equals(extension)) {
        // parquet格式
        return newParquetFileWriter(instantTime, path, conf, config, schema, taskContextSupplier);
    }
    if (HFILE.getFileExtension().equals(extension)) {
        // hfile格式
        return newHFileFileWriter(instantTime, path, conf, config, schema, taskContextSupplier);
    }
    if (ORC.getFileExtension().equals(extension)) {
        // orc格式
        return newOrcFileWriter(instantTime, path, conf, config, schema, taskContextSupplier);
    }
    throw new UnsupportedOperationException(extension + " format not supported yet.");
}

 
 
Writer写入流程
 
 
使用Flink写入COW表的时候数据格式为parquet，所以fileWriter的实现类为HoodieAvroParquetWriter。它的write方法位于父类HoodieAvroFileWriter中：
 
 
@Override
default void write(String recordKey, HoodieRecord record, Schema schema, Properties props) throws IOException {
    // 转换record为avro格式
    IndexedRecord avroPayload = record.toIndexedRecord(schema, props).get().getData();
    writeAvro(recordKey, avroPayload);
}

 
 
writeAvro方法：
 
 
@Override
public void writeAvro(String key, IndexedRecord object) throws IOException {
    super.write(object);
    if (populateMetaFields) {
        writeSupport.add(key);
    }
}

 
 
其中super.write调用的是HoodieBaseParquetWriter的write方法，又间接调用了HoodieBaseParquetWriter父类ParquetWriter的write方法。
 
 
写入metadata的方法为writeAvroWithMetadata，如下所示：
 
 
@Override
public void writeAvroWithMetadata(HoodieKey key, IndexedRecord avroRecord) throws IOException {
    if (populateMetaFields) {
        // 组装元数据到avroRecord中
        prepRecordWithMetadata(key, avroRecord, instantTime,
                               taskContextSupplier.getPartitionIdSupplier().get(), getWrittenRecordCount(), fileName);
        super.write(avroRecord);
        writeSupport.add(key.getRecordKey());
    } else {
        super.write(avroRecord);
    }
}

 
 
再往上追踪就到了org.apache.parquet.hadoop的write方法。Hoodie从插入数据开始到写入parquet文件的流程到此分析完毕。下面开始分析更新数据逻辑。
 
 
更新数据逻辑
 
 
handleUpdateInternal 数据更新
 
 
BaseFlinkCommitActionExecutor的handleUpdateInternal方法在upsert数据的时候调用，代码如下：
 
 
protected Iterator> handleUpdateInternal(HoodieMergeHandle upsertHandle, String fileId)
    throws IOException {
    if (upsertHandle.getOldFilePath() == null) {
        // update操作这种情况下，record一定已存在于某个file中，否则会有问题
        throw new HoodieUpsertException(
            "Error in finding the old file path at commit " + instantTime + " for fileId: " + fileId);
    } else {
        // 合并数据
        HoodieMergeHelper.newInstance().runMerge(table, upsertHandle);
    }

    // TODO(vc): This needs to be revisited
    if (upsertHandle.getPartitionPath() == null) {
        LOG.info("Upsert Handle has partition path as null " + upsertHandle.getOldFilePath() + ", "
                 + upsertHandle.writeStatuses());
    }

    return Collections.singletonList(upsertHandle.writeStatuses()).iterator();
}

 
 
upsert操作的核心是数据的合并。执行合并操作的runMerge内容较长，如下所示：
 
 
@Override
public void runMerge(HoodieTable table,
                     HoodieMergeHandle mergeHandle) throws IOException {
    // 获取写入配置
    HoodieWriteConfig writeConfig = table.getConfig();
    // 获取需要写入的baseFile
    HoodieBaseFile baseFile = mergeHandle.baseFileForMerge();

    // 获取hadoop的配置
    Configuration hadoopConf = new Configuration(table.getHadoopConf());
    // 获取RecordType，是AVRO还是SPARK
    HoodieRecord.HoodieRecordType recordType = table.getConfig().getRecordMerger().getRecordType();
    // 构建baseFile读取器
    HoodieFileReader baseFileReader = HoodieFileReaderFactory
        .getReaderFactory(recordType)
        .getFileReader(hadoopConf, mergeHandle.getOldFilePath());
    HoodieFileReader bootstrapFileReader = null;

    // 获取写入数据的schema，包含元数据字段
    Schema writerSchema = mergeHandle.getWriterSchemaWithMetaFields();
    // 获取baseFile的schema
    Schema readerSchema = baseFileReader.getSchema();

    // In case Advanced Schema Evolution is enabled we might need to rewrite currently
    // persisted records to adhere to an evolved schema
    // Hudi支持schema evolution，此步骤生成旧schema的record转换为新schema的record逻辑的Function
    Option> schemaEvolutionTransformerOpt =
        composeSchemaEvolutionTransformer(readerSchema, writerSchema, baseFile, writeConfig, table.getMetaClient());

    // Check whether the writer schema is simply a projection of the file's one, ie
    //   - Its field-set is a proper subset (of the reader schema)
    //   - There's no schema evolution transformation necessary
    // 检查writerSchema是不是readerSchema的投影
    // writerSchema的列是readerSchema列的子集，并且不存在schema evolution
    boolean isPureProjection = isStrictProjectionOf(readerSchema, writerSchema)
        && !schemaEvolutionTransformerOpt.isPresent();
    // Check whether we will need to rewrite target (already merged) records into the
    // writer's schema
    // 判断是否需要重写已merge的record为writerSchema
    boolean shouldRewriteInWriterSchema = writeConfig.shouldUseExternalSchemaTransformation()
        || !isPureProjection
        || baseFile.getBootstrapBaseFile().isPresent();

    HoodieExecutor wrapper = null;

    try {
        Iterator recordIterator;

        // In case writer's schema is simply a projection of the reader's one we can read
        // the records in the projected schema directly
        // 获取baseFile中record的迭代器
        // 如果writerSchema是readerSchema的投影，可以直接使用writerSchema来读取baseFile
        ClosableIterator baseFileRecordIterator =
            baseFileReader.getRecordIterator(isPureProjection ? writerSchema : readerSchema);
        Schema recordSchema;
        if (baseFile.getBootstrapBaseFile().isPresent()) {
            // 如果baseFile有bootstrapFile
            // 获取路径
            Path bootstrapFilePath = new Path(baseFile.getBootstrapBaseFile().get().getPath());
            // 获取配置
            Configuration bootstrapFileConfig = new Configuration(table.getHadoopConf());
            // 读取bootstrapFile
            bootstrapFileReader =
                HoodieFileReaderFactory.getReaderFactory(recordType).getFileReader(bootstrapFileConfig, bootstrapFilePath);

            // 合并迭代器，迭代的时候将baseFile和bootstrapFile对应的记录拼装在一起形成一条记录
            recordIterator = new MergingIterator<>(
                baseFileRecordIterator,
                bootstrapFileReader.getRecordIterator(),
                (left, right) ->
                left.joinWith(right, mergeHandle.getWriterSchemaWithMetaFields()));
            recordSchema = mergeHandle.getWriterSchemaWithMetaFields();
        } else {
            // 如果没有bootstrapFile，遍历baseFile
            recordIterator = baseFileRecordIterator;
            recordSchema = isPureProjection ? writerSchema : readerSchema;
        }

        // 判断是否buffer record。只有BOUNDED_IN_MEMORY和DISRUPTOR类型的executor才能buffer
        // 默认的SIMPLE类型不会buffer
        boolean isBufferingRecords = ExecutorFactory.isBufferingRecords(writeConfig);

        // new UpdateHandler(mergeHandle)为真正的合并逻辑
        wrapper = ExecutorFactory.create(writeConfig, recordIterator, new UpdateHandler(mergeHandle), record -> {
            // 这里是合并之前record的变换逻辑
            HoodieRecord newRecord;
            if (schemaEvolutionTransformerOpt.isPresent()) {
                // 如果使用schemaEvolution，执行变换
                newRecord = schemaEvolutionTransformerOpt.get().apply(record);
            } else if (shouldRewriteInWriterSchema) {
                // 需要重写数据为writerSchema
                newRecord = record.rewriteRecordWithNewSchema(recordSchema, writeConfig.getProps(), writerSchema);
            } else {
                // 否则无需变换
                newRecord = record;
            }

            // NOTE: Record have to be cloned here to make sure if it holds low-level engine-specific
            //       payload pointing into a shared, mutable (underlying) buffer we get a clean copy of
            //       it since these records will be put into queue of QueueBasedExecutorFactory.
            // 如果需要缓存数据，返回数据的副本
            return isBufferingRecords ? newRecord.copy() : newRecord;
        }, table.getPreExecuteRunnable());

        wrapper.execute();
    } catch (Exception e) {
        throw new HoodieException(e);
    } finally {
        // HUDI-2875: mergeHandle is not thread safe, we should totally terminate record inputting
        // and executor firstly and then close mergeHandle.
        baseFileReader.close();
        if (bootstrapFileReader != null) {
            bootstrapFileReader.close();
        }
        if (null != wrapper) {
            wrapper.shutdownNow();
            wrapper.awaitTermination();
        }
        mergeHandle.close();
    }
}

 
 
执行合并的时候，executor调用了UpdateHandler的consume方法。这个方法又调用了upsertHandle的write方法。和插入数据的executor逻辑类似不再赘述。接下来展开mergeHandle的write方法分析。对于Flink这里的mergeHandle为FlinkMergeHandle。它的write方法位于父类HoodieMergeHandle中。逻辑如下：
 
 
/**
 * Go through an old record. Here if we detect a newer version shows up, we write the new one to the file.
 */
public void write(HoodieRecord oldRecord) {
    // 获取新老schema，主要区别是有没有元数据字段
    Schema oldSchema = config.populateMetaFields() ? writeSchemaWithMetaFields : writeSchema;
    Schema newSchema = useWriterSchemaForCompaction ? writeSchemaWithMetaFields : writeSchema;
    // 是否复制旧数据
    boolean copyOldRecord = true;
    // 获取record key
    String key = oldRecord.getRecordKey(oldSchema, keyGeneratorOpt);
    // 获取hoodie.payload配置
    TypedProperties props = config.getPayloadConfig().getProps();
    // 如果是新数据
    if (keyToNewRecords.containsKey(key)) {
        // If we have duplicate records that we are updating, then the hoodie record will be deflated after
        // writing the first record. So make a copy of the record to be merged
        HoodieRecord newRecord = keyToNewRecords.get(key).newInstance();
        try {
            // 合并新老数据
            Option> mergeResult = recordMerger.merge(oldRecord, oldSchema, newRecord, newSchema, props);
            // 获取合并后的schema
            Schema combineRecordSchema = mergeResult.map(Pair::getRight).orElse(null);
            // 合并后的数据
            Option combinedRecord = mergeResult.map(Pair::getLeft);
            if (combinedRecord.isPresent() && combinedRecord.get().shouldIgnore(combineRecordSchema, props)) {
                // If it is an IGNORE_RECORD, just copy the old record, and do not update the new record.
                // 如果是可忽略的record，复制旧数据
                copyOldRecord = true;
                // 否则，将更新后的数据写入
            } else if (writeUpdateRecord(newRecord, oldRecord, combinedRecord, combineRecordSchema)) {
                /*
           * ONLY WHEN 1) we have an update for this key AND 2) We are able to successfully
           * write the combined new value
           *
           * We no longer need to copy the old record over.
           */
                // 不再复制旧数据
                copyOldRecord = false;
            }
            // 记录这个key，已经写入完成
            writtenRecordKeys.add(key);
        } catch (Exception e) {
            throw new HoodieUpsertException("Failed to combine/merge new record with old value in storage, for new record {"
                                            + keyToNewRecords.get(key) + "}, old value {" + oldRecord + "}", e);
        }
    }

    if (copyOldRecord) {
        // 如果需要复制旧数据
        try {
            // NOTE: We're enforcing preservation of the record metadata to keep existing semantic
            // 旧数据写入到文件
            writeToFile(new HoodieKey(key, partitionPath), oldRecord, oldSchema, props, true);
        } catch (IOException | RuntimeException e) {
            String errMsg = String.format("Failed to merge old record into new file for key %s from old file %s to new file %s with writerSchema %s",
                                          key, getOldFilePath(), newFilePath, writeSchemaWithMetaFields.toString(true));
            LOG.debug("Old record is " + oldRecord);
            throw new HoodieUpsertException(errMsg, e);
        }
        // 已写入的数据数加1
        recordsWritten++;
    }
}

 
 
合并操作的细节位于recordMerger.merge方法中。下一节继续分析。
 
 
HoodieAvroRecordMerger::merge 合并数据
 
 
合并方法将新旧两条record按照一定规则，合并成为一条record，合并过程中schema可能发生变更。分析如下：
 
 
@Override
public Option> merge(HoodieRecord older, Schema oldSchema, HoodieRecord newer, Schema newSchema, TypedProperties props) throws IOException {
    // 既然是HoodieAvroRecordMerger，必须检查新旧record的类型为AVRO
    ValidationUtils.checkArgument(older.getRecordType() == HoodieRecordType.AVRO);
    ValidationUtils.checkArgument(newer.getRecordType() == HoodieRecordType.AVRO);
    // 获取合并方式，默认是COMBINING
    Config.LegacyOperationMode legacyOperatingMode = Config.LegacyOperationMode.valueOf(
        props.getString(Config.LEGACY_OPERATING_MODE.key(), Config.LEGACY_OPERATING_MODE.defaultValue()));

    switch (legacyOperatingMode) {
        // 如果是PRE_COMBINING方式
        case PRE_COMBINING:
            HoodieRecord res = preCombine(older, newer, newSchema, props);
            // 合并后和谁相同，就用谁的schema
            if (res == older) {
                return Option.of(Pair.of(res, oldSchema));
            } else {
                return Option.of(Pair.of(res, newSchema));
            }
        // 如果是COMBINING方式
        case COMBINING:
            return combineAndGetUpdateValue(older, newer, newSchema, props)
                .map(r -> Pair.of(r, (((HoodieAvroIndexedRecord) r).getData()).getSchema()));

        default:
            throw new UnsupportedOperationException(String.format("Unsupported legacy operating mode (%s)", legacyOperatingMode));
    }
}

 
 
preCombine方法：
 
 
private HoodieRecord preCombine(HoodieRecord older, HoodieRecord newer, Schema schema, Properties props) {
    HoodieRecordPayload payload = unsafeCast(((HoodieAvroRecord) newer).getData().preCombine(((HoodieAvroRecord) older).getData(), schema, props));
    return new HoodieAvroRecord(newer.getKey(), payload, newer.getOperation());
}

 
 
combineAndGetUpdateValue方法：
 
 
private Option combineAndGetUpdateValue(HoodieRecord older, HoodieRecord newer, Schema schema, Properties props) throws IOException {
    Option previousAvroData = older.toIndexedRecord(schema, props).map(HoodieAvroIndexedRecord::getData);
    if (!previousAvroData.isPresent()) {
        return Option.empty();
    }

    return ((HoodieAvroRecord) newer).getData().combineAndGetUpdateValue(previousAvroData.get(), schema, props)
        .map(combinedAvroPayload -> new HoodieAvroIndexedRecord((IndexedRecord) combinedAvroPayload));
}

 
 
上面这两个方法分别间接调用了HoodieAvroRecord中data的preCombine和combineAndGetUpdateValue方法。这个data为Hudi的payload。下面以最为常用的OverwriteWithLatestAvroPayload和PartialUpdateAvroPayload为例，分别分析他们的preCombine和combineAndGetUpdateValue方法。
 
 
OverwriteWithLatestAvroPayload
 
 
Hudi的payload类型由hoodie.datasource.write.payload.class决定。默认为OverwriteWithLatestAvroPayload。它的逻辑比较简单。preCombine方法使用order field(preCombined字段)决定数据新旧。combineAndGetUpdateValue直接取用新数据的值。代码如下所示：
 
 
@Override
public OverwriteWithLatestAvroPayload preCombine(OverwriteWithLatestAvroPayload oldValue) {
    if (oldValue.recordBytes.length == 0) {
        // use natural order for delete record
        return this;
    }
    if (oldValue.orderingVal.compareTo(orderingVal) > 0) {
        // pick the payload with greatest ordering value
        return oldValue;
    } else {
        return this;
    }
}

@Override
public Option combineAndGetUpdateValue(IndexedRecord currentValue, Schema schema) throws IOException {
    return getInsertValue(schema);
}

@Override
public Option getInsertValue(Schema schema) throws IOException {
    if (recordBytes.length == 0 || isDeletedRecord) {
        return Option.empty();
    }

    return Option.of((IndexedRecord) HoodieAvroUtils.bytesToAvro(recordBytes, schema));
}

 
 
PartialUpdateAvroPayload
 
 
相比OverwriteWithLatestAvroPayload，PartialUpdateAvroPayload的逻辑要复杂的多。它的preCombine方法和combineAndGetUpdateValue逻辑比较相似，都是合并数据。具体可以参考源代码中的注释。简单总结为：例如排序字段(order field)是ts，那么对于record key相同的数据，ts大的会覆盖ts小的。除此之外还有其他的规则：如果新数据某个字段值为null，不会覆盖老数据；如果老数据某个字段值恰好是字段的默认值，它一定会被新数据替换。源代码中的例子如下：
 
 
/** 
 *  Illustration with simple data.
 *  let's say the order field is 'ts' and schema is :
 *  {
 *    [
 *      {"name":"id","type":"string"},
 *      {"name":"ts","type":"long"},
 *      {"name":"name","type":"string"},
 *      {"name":"price","type":"string"}
 *    ]
 *  }
 *
 *  case 1
 *  Current data:
 *      id      ts      name    price
 *      1       1       name_1  price_1
 *  Insert data:
 *      id      ts      name    price
 *      1       2       null    price_2
 *
 *  Result data after #preCombine or #combineAndGetUpdateValue:
 *      id      ts      name    price
 *      1       2       name_1  price_2
 *
 *  case 2
 *  Current data:
 *      id      ts      name    price
 *      1       2       name_1  null
 *  Insert data:
 *      id      ts      name    price
 *      1       1       null    price_1
 *
 *  Result data after preCombine or combineAndGetUpdateValue:
 *      id      ts      name    price
 *      1       2       name_1  price_1
 */

 
 
仔细分析的话，这两个方法还是有区别的：
 
 
     
  
  •  preCombine使用FlinkOptions中的precombine.field指定的field比较数据的新旧(在PayloadCreation的createPayload方法中指定)。
    •  
  
  •  combineAndGetUpdateValue使用hoodie.payload.ordering.field指定的field比较数据的新旧。
    •  
 
 
 
接下来首先分析preCombine调用逻辑。
 
 
preCombine 逻辑
 
 
@Override
public PartialUpdateAvroPayload preCombine(OverwriteWithLatestAvroPayload oldValue, Schema schema, Properties properties) {
    if (oldValue.recordBytes.length == 0) {
        // use natural order for delete record
        // 如果old没数据，使用新值
        return this;
    }
    // pick the payload with greater ordering value as insert record
    // 决定用新数据还是旧数据
    // 使用preCombined字段来比较大小，例如时间戳ts
    final boolean shouldPickOldRecord = oldValue.orderingVal.compareTo(orderingVal) > 0 ? true : false;
    try {
        // oldRecord转换为avro格式
        GenericRecord oldRecord = HoodieAvroUtils.bytesToAvro(oldValue.recordBytes, schema);
        // 新老数据合并
        Option mergedRecord = mergeOldRecord(oldRecord, schema, shouldPickOldRecord);
        if (mergedRecord.isPresent()) {
            // 返回合并后的payload
            return new PartialUpdateAvroPayload((GenericRecord) mergedRecord.get(),
                                                shouldPickOldRecord ? oldValue.orderingVal : this.orderingVal);
        }
    } catch (Exception ex) {
        return this;
    }
    return this;
}

 
 
合并新老数据mergeOldRecord方法：
 
 
private Option mergeOldRecord(IndexedRecord oldRecord,
                                             Schema schema,
                                             boolean isOldRecordNewer) throws IOException {
    // 获取新数据。如果payload无数据或者是被删除的数据，返回Option.empty()
    Option recordOption = getInsertValue(schema);
    if (!recordOption.isPresent()) {
        // use natural order for delete record
        return Option.empty();
    }

    if (isOldRecordNewer && schema.getField(HoodieRecord.COMMIT_TIME_METADATA_FIELD) != null) {
        // handling disorder, should use the metadata fields of the updating record
        // 如果旧数据较新，说明数据乱序
        // 如果有提交时间元数据
        return mergeDisorderRecordsWithMetadata(schema, (GenericRecord) oldRecord, (GenericRecord) recordOption.get());
    } else if (isOldRecordNewer) {
        // 否则，合并record，第2个参数的record优先级高于第3个参数的record
        return mergeRecords(schema, (GenericRecord) oldRecord, (GenericRecord) recordOption.get());
    } else {
        return mergeRecords(schema, (GenericRecord) recordOption.get(), (GenericRecord) oldRecord);
    }
}

 
 
带有元数据，合并乱序record的mergeDisorderRecordsWithMetadata方法：
 
 
protected Option mergeDisorderRecordsWithMetadata(
    Schema schema,
    GenericRecord oldRecord,
    GenericRecord updatingRecord) {
    // 如果是删除数据，返回empty
    if (isDeleteRecord(oldRecord)) {
        return Option.empty();
    } else {
        // 开始构建合并后的数据
        final GenericRecordBuilder builder = new GenericRecordBuilder(schema);
        List fields = schema.getFields();
        fields.forEach(field -> {
            final GenericRecord baseRecord;
            final GenericRecord mergedRecord;
            if (HoodieRecord.HOODIE_META_COLUMNS_NAME_TO_POS.containsKey(field.name())) {
                // this is a metadata field
                // 走到这里说明字段是一个元数据字段
                // 元数据字段使用新数据的元数据字段值
                baseRecord = updatingRecord;
                mergedRecord = oldRecord;
            } else {
                // 其他字段使用老数据的字段值
                baseRecord = oldRecord;
                mergedRecord = updatingRecord;
            }
            // 设置字段值
            setField(baseRecord, mergedRecord, builder, field);
        });
        // 返回构造完成的数据
        return Option.of(builder.build());
    }
}

 
 
设置字段值的逻辑位于OverwriteNonDefaultsWithLatestAvroPayload的setField方法：
 
 
protected void setField(
    GenericRecord baseRecord,
    GenericRecord mergedRecord,
    GenericRecordBuilder builder,
    Schema.Field field) {
    // 获取baseRecord的field字段值
    Object value = baseRecord.get(field.name());
    // 如果是String类型，调用toString
    value = field.schema().getType().equals(Schema.Type.STRING) && value != null ? value.toString() : value;
    // 获取字段的默认值
    Object defaultValue = field.defaultVal();
    // 下面的逻辑为，如果老数据字段值为字段默认值，替换为新数据字段值。否则采用老数据字段值
    if (!overwriteField(value, defaultValue)) {
        // 如果不需要覆盖字段值，使用baseRecord的值
        builder.set(field, value);
    } else {
        // 否则使用mergedRecord的值
        builder.set(field, mergedRecord.get(field.name()));
    }
}

// overwriteField方法位于OverwriteWithLatestAvroPayload类中
public Boolean overwriteField(Object value, Object defaultValue) {
    // 如果字段默认值是null并且实际值为null，返回true
    if (JsonProperties.NULL_VALUE.equals(defaultValue)) {
        return value == null;
    }
    // 否则当实际值和默认值相同的时候返回true
    return Objects.equals(value, defaultValue);
}

 
 
我们回到PartialUpdateAvroPayload的mergeOldRecord方法。继续分析OverwriteNonDefaultsWithLatestAvroPayload的mergeRecords方法。内容如下：
 
 
protected Option mergeRecords(Schema schema, GenericRecord baseRecord, GenericRecord mergedRecord) {
    if (isDeleteRecord(baseRecord)) {
        // 如果有_hoodie_is_deleted字段并且标记为true，说明是删除的数据，返回empty
        return Option.empty();
    } else {
        final GenericRecordBuilder builder = new GenericRecordBuilder(schema);
        List fields = schema.getFields();
        // 对于schema的字段逐个调用setField方法
        fields.forEach(field -> setField(baseRecord, mergedRecord, builder, field));
        return Option.of(builder.build());
    }
}

 
 
combineAndGetUpdateValue 逻辑
 
 
我们回到PartialUpdateAvroPayload的combineAndGetUpdateValue方法。内容如下：
 
 
@Override
public Option combineAndGetUpdateValue(IndexedRecord currentValue, Schema schema, Properties prop) throws IOException {
    return mergeOldRecord(currentValue, schema, isRecordNewer(orderingVal, currentValue, prop));
}

 
 
mergeOldRecord方法内容和上面的分析一致，不再赘述。
 
 
isRecordNewer方法判断record是否是较新的。逻辑如下:
 
 
private static boolean isRecordNewer(Comparable orderingVal, IndexedRecord record, Properties prop) {
    // 获取hoodie.payload.ordering.field配置值
    String orderingField = prop.getProperty(HoodiePayloadProps.PAYLOAD_ORDERING_FIELD_PROP_KEY);
    if (!StringUtils.isNullOrEmpty(orderingField)) {
        // 如果orderingField存在
        
        // 获取hoodie.datasource.write.keygenerator.consistent.logical.timestamp.enabled配置值，默认为false
        // 表示是否回转换成一致的timestamp格式
        boolean consistentLogicalTimestampEnabled = Boolean.parseBoolean(prop.getProperty(
            KeyGeneratorOptions.KEYGENERATOR_CONSISTENT_LOGICAL_TIMESTAMP_ENABLED.key(),
            KeyGeneratorOptions.KEYGENERATOR_CONSISTENT_LOGICAL_TIMESTAMP_ENABLED.defaultValue()));

        // 获取ordering field的值
        Comparable oldOrderingVal =
            (Comparable) HoodieAvroUtils.getNestedFieldVal(
            (GenericRecord) record,
            orderingField,
            true,
            consistentLogicalTimestampEnabled);

        // pick the payload with greater ordering value as insert record
        // 比较ordering field的值
        return oldOrderingVal != null
            && ReflectionUtils.isSameClass(oldOrderingVal, orderingVal)
            && oldOrderingVal.compareTo(orderingVal) > 0;
    }
    return false;
}

 
 
writeUpdateRecord 写入更新后数据
 
 
我们直接分析writeUpdateRecord方法：
 
 
protected boolean writeUpdateRecord(HoodieRecord newRecord, HoodieRecord oldRecord, Option combineRecordOpt, Schema writerSchema) throws IOException {
    boolean isDelete = false;
    if (combineRecordOpt.isPresent()) {
        updatedRecordsWritten++;
        if (oldRecord.getData() != combineRecordOpt.get().getData()) {
            // 如果旧数据和合并后的新数据不同，需要删除旧数据
            // the incoming record is chosen
            isDelete = HoodieOperation.isDelete(newRecord.getOperation());
        } else {
            // the incoming record is dropped
            // 否则不需要写入新数据
            return false;
        }
    }
    // 写入数据
    return writeRecord(newRecord, combineRecordOpt, writerSchema, config.getPayloadConfig().getProps(), isDelete);
}

 
 
最后的writeRecord方法将record写入文件。内容如下：
 
 
private boolean writeRecord(HoodieRecord newRecord, Option combineRecord, Schema schema, Properties prop, boolean isDelete) throws IOException {
    Option recordMetadata = newRecord.getMetadata();
    // 检查partition path必须匹配
    if (!partitionPath.equals(newRecord.getPartitionPath())) {
        HoodieUpsertException failureEx = new HoodieUpsertException("mismatched partition path, record partition: "
                                                                    + newRecord.getPartitionPath() + " but trying to insert into partition: " + partitionPath);
        writeStatus.markFailure(newRecord, failureEx, recordMetadata);
        return false;
    }
    try {
        if (combineRecord.isPresent() && !combineRecord.get().isDelete(schema, config.getProps()) && !isDelete) {
            // 如果不是删除数据，将数据写入文件
            writeToFile(newRecord.getKey(), combineRecord.get(), schema, prop, preserveMetadata && useWriterSchemaForCompaction);
            // 写入record计数加1
            recordsWritten++;
        } else {
            // 否则删除数据计数加1
            recordsDeleted++;
        }
        // 标记写入成功
        writeStatus.markSuccess(newRecord, recordMetadata);
        // deflate record payload after recording success. This will help users access payload as a
        // part of marking
        // record successful.
        // 清空payload
        newRecord.deflate();
        return true;
    } catch (Exception e) {
        LOG.error("Error writing record  " + newRecord, e);
        writeStatus.markFailure(newRecord, e, recordMetadata);
    }
    return false;
}

 
 
Flink COW Insert
 
 
Insert逻辑和Upsert的调用链很多是相同的，不同之处仅是实现类。这里只分析有差异的地方。整体来说COW表的insert操作直接写入新parquet文件就可以了，省略了合并数据的过程，逻辑较为简单。
 
 
Insert逻辑位于HoodieFlinkCopyOnWriteTable的insert方法。内容如下：
 
 
  public HoodieWriteMetadata> insert(
      HoodieEngineContext context,
      HoodieWriteHandle writeHandle,
      String instantTime,
      List> records) {
    return new FlinkInsertCommitActionExecutor<>(context, writeHandle, config, this, instantTime, records).execute();
  }

 
 
FlinkInsertCommitActionExecutor::execute方法：
 
 
@Override
public HoodieWriteMetadata> execute() {
    return FlinkWriteHelper.newInstance().write(instantTime, inputRecords, context, table,
                                                config.shouldCombineBeforeInsert(), config.getInsertShuffleParallelism(), this, operationType);
}

 
 
往后的逻辑和COW Upsert逻辑相同，不再赘述。
 
 
Bucket分配
 
 
BucketAssignFunction
 
 
我们从数据流入的processElement方法展开分析。
 
 
@Override
public void processElement(I value, Context ctx, Collector out) throws Exception {
    if (value instanceof IndexRecord) {
        IndexRecord indexRecord = (IndexRecord) value;
        this.indexState.update((HoodieRecordGlobalLocation) indexRecord.getCurrentLocation());
    } else {
        // 非索引类型数据，调用processRecord方法
        processRecord((HoodieRecord) value, out);
    }
}

 
 
processRecord方法为数据标记新的location。逻辑如下：
 
 
private void processRecord(HoodieRecord record, Collector out) throws Exception {
    // 1. put the record into the BucketAssigner;
    // 2. look up the state for location, if the record has a location, just send it out;
    // 3. if it is an INSERT, decide the location using the BucketAssigner then send it out.
    final HoodieKey hoodieKey = record.getKey();
    // 获取key和partition path
    final String recordKey = hoodieKey.getRecordKey();
    final String partitionPath = hoodieKey.getPartitionPath();
    final HoodieRecordLocation location;

    // Only changing records need looking up the index for the location,
    // append only records are always recognized as INSERT.
    // 从状态中获取上次record位置
    HoodieRecordGlobalLocation oldLoc = indexState.value();
    // upsert，upsert_prepped或者delete的时候isChangingRecords为true
    if (isChangingRecords && oldLoc != null) {
        // Set up the instant time as "U" to mark the bucket as an update bucket.
        // 如果partition path发生了变化
        // record的partition字段值发生变化会导致partition path发生变化
        if (!Objects.equals(oldLoc.getPartitionPath(), partitionPath)) {
            // 如果开启了全局索引，意思如果是新旧数据的partition path不同，是否更新旧数据的partition path
            if (globalIndex) {
                // if partition path changes, emit a delete record for old partition path,
                // then update the index state using location with new partition path.
                // 生成一个删除类型的数据，指向旧的partition path
                HoodieRecord deleteRecord = new HoodieAvroRecord<>(new HoodieKey(recordKey, oldLoc.getPartitionPath()),
                                                                      payloadCreation.createDeletePayload((BaseAvroPayload) record.getData()));

                deleteRecord.unseal();
                // 设置instant time为U
                deleteRecord.setCurrentLocation(oldLoc.toLocal("U"));
                deleteRecord.seal();

                out.collect((O) deleteRecord);
            }
            // 获取新数据的location
            location = getNewRecordLocation(partitionPath);
        } else {
            // 如果partition path没有发生变化
            location = oldLoc.toLocal("U");
            // 为update类型record创建或加入bucket
            this.bucketAssigner.addUpdate(partitionPath, location.getFileId());
        }
    } else {
        // 新增数据，创建新的location
        location = getNewRecordLocation(partitionPath);
    }
    // always refresh the index
    if (isChangingRecords) {
        // 如果数据更新，需要紧接着更新index状态变量
        updateIndexState(partitionPath, location);
    }

    // 配置record的location
    record.unseal();
    record.setCurrentLocation(location);
    record.seal();

    out.collect((O) record);
}

 
 
getNewRecordLocation为新数据分配一个location。方法内容如下：
 
 
private HoodieRecordLocation getNewRecordLocation(String partitionPath) {
    // 为新增的record查找或创建一个bucket
    final BucketInfo bucketInfo = this.bucketAssigner.addInsert(partitionPath);
    final HoodieRecordLocation location;
    switch (bucketInfo.getBucketType()) {
        // 根据bucket类型是insert或者update，构建record的位置信息HoodieRecordLocation
        case INSERT:
            // This is an insert bucket, use HoodieRecordLocation instant time as "I".
            // Downstream operators can then check the instant time to know whether
            // a record belongs to an insert bucket.
            location = new HoodieRecordLocation("I", bucketInfo.getFileIdPrefix());
            break;
        case UPDATE:
            location = new HoodieRecordLocation("U", bucketInfo.getFileIdPrefix());
            break;
        default:
            throw new AssertionError();
    }
    return location;
}

 
 
update和insert操作最终都指向了BucketAssigner。这个类是location分配的核心类。接下来重点分析。
 
 
BucketAssigner
 
 
BucketAssigner为record分配其所述的bucket，即数据即将被写入的location。Location信息封装在了BucketInfo类中。
 
 
BucketInfo有如下成员变量：
 
 
     
  
  • bucketType：bucket类型，是insert还是update。
    •  
  
  • fileIdPrefix：存储文件的fileId。
    •  
  
  • partitionPath：分区路径。
    •  
 
 
 
继续分析为update类型record分配bucket的addUpdate方法。逻辑如下：
 
 
public BucketInfo addUpdate(String partitionPath, String fileIdHint) {
    // 构建key，将partition path和fileID通过下划线拼装在一起
    final String key = StreamerUtil.generateBucketKey(partitionPath, fileIdHint);
    // bucketInfoMap缓存了key和bucket信息的对应关系
    if (!bucketInfoMap.containsKey(key)) {
        // 如果没有，创建一个update类型的bucketInfo
        BucketInfo bucketInfo = new BucketInfo(BucketType.UPDATE, fileIdHint, partitionPath);
        bucketInfoMap.put(key, bucketInfo);
    }
    // else do nothing because the bucket already exists.
    // 如果缓存的有（已分配bucket），获取对应的bucketInfo
    return bucketInfoMap.get(key);
}

 
 
为insert类型record分配bucket的addInsert方法，内容如下。因为要涉及到小文件分配等逻辑，相比addUpdate方法要复杂的多。
 
 
public BucketInfo addInsert(String partitionPath) {
    // for new inserts, compute buckets depending on how many records we have for each partition
    // 分配小文件
    SmallFileAssign smallFileAssign = getSmallFileAssign(partitionPath);

    // first try packing this into one of the smallFiles
    if (smallFileAssign != null && smallFileAssign.assign()) {
        // 如果分配给小文件成功，使用小文件的file ID构建bucketInfo并返回
        return new BucketInfo(BucketType.UPDATE, smallFileAssign.getFileId(), partitionPath);
    }

    // if we have anything more, create new insert buckets, like normal
    // 如果没有小文件，或者是小文件没有更多空间可以分配
    // 将record分配到新文件
    // newFileAssignStates代表指向新文件的候选bucket
    if (newFileAssignStates.containsKey(partitionPath)) {
        // 如果候选分配状态中有
        // 获取partitionPath对应的分配状态
        NewFileAssignState newFileAssignState = newFileAssignStates.get(partitionPath);
        if (newFileAssignState.canAssign()) {
            // 如果仍有空间，能够分配到这个新文件中
            // 执行分配
            newFileAssignState.assign();
            // 生成key
            final String key = StreamerUtil.generateBucketKey(partitionPath, newFileAssignState.fileId);
            // 查找是否有缓存的bucketInfo
            if (bucketInfoMap.containsKey(key)) {
                // the newFileAssignStates is cleaned asynchronously when received the checkpoint success notification,
                // the records processed within the time range:
                // (start checkpoint, checkpoint success(and instant committed))
                // should still be assigned to the small buckets of last checkpoint instead of new one.

                // the bucketInfoMap is cleaned when checkpoint starts.

                // A promotion: when the HoodieRecord can record whether it is an UPDATE or INSERT,
                // we can always return an UPDATE BucketInfo here, and there is no need to record the
                // UPDATE bucket through calling #addUpdate.
                return bucketInfoMap.get(key);
            }
            return new BucketInfo(BucketType.UPDATE, newFileAssignState.fileId, partitionPath);
        }
    }
    // 如果newFileAssignStates中没有
    // 或者是新文件的空间不足以分配
    // 创建新的bucketInfo。createFileIdOfThisTask创建新的file ID
    BucketInfo bucketInfo = new BucketInfo(BucketType.INSERT, createFileIdOfThisTask(), partitionPath);
    // 生成key
    final String key = StreamerUtil.generateBucketKey(partitionPath, bucketInfo.getFileIdPrefix());
    // 加入到bucket缓存中
    bucketInfoMap.put(key, bucketInfo);
    // 创建新文件分配状态
    NewFileAssignState newFileAssignState = new NewFileAssignState(bucketInfo.getFileIdPrefix(), writeProfile.getRecordsPerBucket());
    // 分配
    newFileAssignState.assign();
    // 加入到新文件分配缓存中
    newFileAssignStates.put(partitionPath, newFileAssignState);
    return bucketInfo;
}

 
 
createFileIdOfThisTask方法为insert record对应的bucket创建对应的fileID。
 
 
@VisibleForTesting
public String createFileIdOfThisTask() {
    // 使用UUID
    String newFileIdPfx = FSUtils.createNewFileIdPfx();
    // 使用fileIdOfThisTask计算hash，判断生成的newFileIdPfx是否属于当前task
    // 如果不属于，反复生成直到符合条件为止
    while (!fileIdOfThisTask(newFileIdPfx)) {
        newFileIdPfx = FSUtils.createNewFileIdPfx();
    }
    return newFileIdPfx;
}

 
 
fileIdOfThisTask类似于record按照fileId, maxParallelism, numTasks做KeyBy操作（Flink的keyBy算子调用的也是KeyGroupRangeAssignment.assignKeyToParallelOperator方法），判断计算出的Hash是否等于taskID。意思也就是说判断这个file是否归这个task来处理。
 
 
private boolean fileIdOfThisTask(String fileId) {
    // the file id can shuffle to this task
    return KeyGroupRangeAssignment.assignKeyToParallelOperator(fileId, maxParallelism, numTasks) == taskID;
}

 
 
getSmallFileAssign方法查找并分配相同partition path下的小文件。
 
 
private synchronized SmallFileAssign getSmallFileAssign(String partitionPath) {
    // 如果这个partition path下有可分配的小文件，获取这个小文件
    if (smallFileAssignMap.containsKey(partitionPath)) {
        return smallFileAssignMap.get(partitionPath);
    }
    // 获取分区下所有的small file，然后再其中查找归当前task负责的小文件
    // 这款车只返回当前task负责的小文件，而不是partition path下所有的小文件
    // 获取逻辑后面分析
    List smallFiles = smallFilesOfThisTask(writeProfile.getSmallFiles(partitionPath));
    if (smallFiles.size() > 0) {
        // 如果存在分配给当前任务的小文件
        LOG.info("For partitionPath : " + partitionPath + " Small Files => " + smallFiles);
        // 将这些小文件分配状态保存为SmallFileAssignState
        SmallFileAssignState[] states = smallFiles.stream()
            .map(smallFile -> new SmallFileAssignState(config.getParquetMaxFileSize(), smallFile, writeProfile.getAvgSize()))
            .toArray(SmallFileAssignState[]::new);
        // 保存到smallFileAssignMap中
        SmallFileAssign assign = new SmallFileAssign(states);
        smallFileAssignMap.put(partitionPath, assign);
        return assign;
    }
    // 没有小文件，返回null
    smallFileAssignMap.put(partitionPath, null);
    return null;
}

 
 
 
  
smallFileAssignMap缓存的是partition path和SmallFileAssign的对应关系。SmallFileAssign保存了某个partition下所有的小文件分配状态（有多少个小文件，每个小文件已分配多少record，还有多少剩余容量等）。
 
  
newFileAssignState缓存的是partitionPath_fileID和NewFileAssignState的对应关系。表示某个新文件的分配状态（每个文件已分配多少record，还有多少剩余容量等）。
 
 
 
 
WriteProfile的getSmallFiles获取partitionPath下的所有小文件。
 
 
public synchronized List getSmallFiles(String partitionPath) {
    // lookup the cache first
    // 如果缓存的有，返回缓存的内容
    if (smallFilesMap.containsKey(partitionPath)) {
        return smallFilesMap.get(partitionPath);
    }

    List smallFiles = new ArrayList<>();
    // 获取hoodie.parquet.small.file.limit配置，小于这个大小的都会被视为小文件
    if (config.getParquetSmallFileLimit() <= 0) {
        // 如果该配置小于等于0，没有任何文件被视为小文件
        this.smallFilesMap.put(partitionPath, smallFiles);
        return smallFiles;
    }

    // 查询文件系统，获取所有的小文件
    smallFiles = smallFilesProfile(partitionPath);
    // 加入缓存中
    this.smallFilesMap.put(partitionPath, smallFiles);
    return smallFiles;
}

 
 
smallFilesProfile查询文件系统获取partition path下的所有小文件。
 
 
protected List smallFilesProfile(String partitionPath) {
    // smallFiles only for partitionPath
    List smallFileLocations = new ArrayList<>();

    // 获取已完成的timeline
    HoodieTimeline commitTimeline = metaClient.getCommitsTimeline().filterCompletedInstants();

    if (!commitTimeline.empty()) { // if we have some commits
        // 如果有commit
        // 获取最近的一次commit
        HoodieInstant latestCommitTime = commitTimeline.lastInstant().get();
        // 从文件系统读取最新的，latestCommitTime之前的base file
        List allFiles = fsView
            .getLatestBaseFilesBeforeOrOn(partitionPath, latestCommitTime.getTimestamp()).collect(Collectors.toList());

        for (HoodieBaseFile file : allFiles) {
            // filter out the corrupted files.
            // 遍历这些文件，找出文件大小大于0并且小于hoodie.parquet.small.file.limit的文件
            // 这是被视为小文件的条件
            if (file.getFileSize() < config.getParquetSmallFileLimit() && file.getFileSize() > 0) {
                String filename = file.getFileName();
                // 创建SmallFile
                SmallFile sf = new SmallFile();
                sf.location = new HoodieRecordLocation(FSUtils.getCommitTime(filename), FSUtils.getFileId(filename));
                sf.sizeBytes = file.getFileSize();
                smallFileLocations.add(sf);
            }
        }
    }

    return smallFileLocations;
}

 
 
smallFilesOfThisTask方法从一系列小文件中找到当前task负责的小文件。逻辑如下：
 
 
@VisibleForTesting
public List smallFilesOfThisTask(List smallFiles) {
    // computes the small files to write inserts for this task.
    // 使用fileIdOfThisTask逐个判断small file的fileID，从而得知small file是否归当前task处理
    // 符合条件的加入集合中
    return smallFiles.stream()
        .filter(smallFile -> fileIdOfThisTask(smallFile.location.getFileId()))
        .collect(Collectors.toList());
}

 
 
SmallFileAssign
 
 
上面分析完了小文件的分配流程。小文件分配容量计算和状态维护的逻辑位于SmallFileAssign。本章节重点分析它。
 
 
SmallFileAssign用于分配小文件供数据写入。是小文件优化的一部分。SmallFileAssign在前面分析的getSmallFileAssign中创建。从创建可以得知一个SmallFileAssign维护的是同一个task负责的，位于同一个partition path下面的所有小文件分配record的状态。
 
 
SmallFileAssign有如下成员变量：
 
 
// 保存各个小文件的分配状态
final SmallFileAssignState[] states;
// 是states数组的下标。有多个小文件可以分配的时候，逐个分配这些小文件
// 当某个小文件容量已满无法继续分配的时候（成为大文件），assignIdx自增1，开始分配下一个文件
int assignIdx = 0;
// 标记这个SmallFileAssign是否还有小文件可分配
boolean noSpace = false;

 
 
assign方法尝试分配一个小文件。如果分配成功返回true。逻辑如下：
 
 
public boolean assign() {
    if (noSpace) {
        // 如果没有空间了，返回false
        return false;
    }
    // assignIdx是当前分配到第几个小文件
    SmallFileAssignState state = states[assignIdx];
    while (!state.canAssign()) {
        // 如果这个小文件不能分配
        // 指针向后移动
        assignIdx += 1;
        if (assignIdx >= states.length) {
            // 如果所有小文件都分配完了
            // 标记没有空间
            noSpace = true;
            return false;
        }
        // move to next slot if possible
        // 分配下一个小文件
        state = states[assignIdx];
    }
    // 分配到这个state中
    state.assign();
    return true;
}

 
 
成功完成assign过程之后，可以使用getFileId方法，获取分配到的小文件的fileId：
 
 
public String getFileId() {
    return states[assignIdx].fileId;
}

 
 
SmallFileAssign中每一个小文件的分配状态位于SmallFileAssignState类。它有如下成员变量：
 
 
// 已分配多少record
long assigned;
// 每个bucket平均多少个record，也就是最多能分配多少
// 受hoodie.parquet.max.file.size配置项影响
// 最大file大小 / 平均每条record的大小
long totalUnassigned;
// 对应的fileId
final String fileId;

 
 
接下来是判断可否分配的canAssign方法和assign方法：
 
 
public boolean canAssign() {
    // 已分配的数量不能超过总的未分配数量
    return this.totalUnassigned > 0 && this.totalUnassigned > this.assigned;
}

/**
 * Remembers to invoke {@link #canAssign()} first.
 */
public void assign() {
    // 已分配数量自增1
    this.assigned++;
}

 
 
到这里小文件的分配流程分析完毕。
 
 
MOR Upsert
 
 
HoodieFlinkMergeOnReadTable
 
 
HoodieFlinkMergeOnReadTable代表了Flink管理的MOR类型Hudi表。我们从这里开始分析。
 
 
对于MOR类型表，FlinkWriteHandleFactory.getFactory返回的是DeltaCommitWriteHandleFactory。它的create方法内容如下：
 
 
@Override
public HoodieWriteHandle create(
    Map bucketToHandles,
    HoodieRecord record,
    HoodieWriteConfig config,
    String instantTime,
    HoodieTable table,
    Iterator> recordItr) {
    final String fileID = record.getCurrentLocation().getFileId();
    final String partitionPath = record.getPartitionPath();
    final TaskContextSupplier contextSupplier = table.getTaskContextSupplier();
    return new FlinkAppendHandle<>(config, instantTime, table, partitionPath, fileID, recordItr, contextSupplier);
}

 
 
上面方法创建出的handle为FlinkAppendHandle。它主要负责将数据写入log文件。
 
 
HoodieFlinkMergeOnReadTable的insert方法：
 
 
@Override
public HoodieWriteMetadata> insert(
    HoodieEngineContext context,
    HoodieWriteHandle writeHandle,
    String instantTime,
    List> hoodieRecords) {
    if (writeHandle instanceof FlinkAppendHandle) {
        // 如果是FlinkAppendHandle类型handle
        FlinkAppendHandle appendHandle = (FlinkAppendHandle) writeHandle;
        return new FlinkUpsertDeltaCommitActionExecutor<>(context, appendHandle, config, this, instantTime, hoodieRecords).execute();
    } else {
        // 如果不是FlinkAppendHandle，调用父类HoodieFlinkCopyOnWriteTable的insert方法
        return super.insert(context, writeHandle, instantTime, hoodieRecords);
    }
}

 
 
和COW的BaseFlinkCommitActionExecutor不同的是。MOR的insert逻辑由FlinkUpsertDeltaCommitActionExecutor执行。MOR表写入log文件称之为delta commit，和COW表是不同的。
 
 
FlinkUpsertDeltaCommitActionExecutor
 
 
我们从execute方法开始。
 
 
@Override
public HoodieWriteMetadata execute() {
    return FlinkWriteHelper.newInstance().write(instantTime, inputRecords, context, table,
                                                config.shouldCombineBeforeUpsert(), config.getUpsertShuffleParallelism(), this, operationType);
}

 
 
后面的逻辑和BaseFlinkCommitActionExecutor基本相同。但是BaseFlinkDeltaCommitActionExecutor是BaseFlinkCommitActionExecutor的子类，覆盖了父类的handleUpdate和handleInsert方法。
 
 
我们重点分析父类BaseFlinkDeltaCommitActionExecutor的handleUpdate和handleInsert方法。
 
 
@Override
public Iterator> handleUpdate(String partitionPath, String fileId, Iterator> recordItr) {
    FlinkAppendHandle appendHandle = (FlinkAppendHandle) writeHandle;
    // 对于更新的数据，调用doAppend方法
    appendHandle.doAppend();
    // 关闭appendHandle并获取写入状态
    List writeStatuses = appendHandle.close();
    return Collections.singletonList(writeStatuses).iterator();
}

@Override
public Iterator> handleInsert(String idPfx, Iterator> recordItr) {
    // 创建FlinkLazyInsertIterable
    // 和BaseFlinkCommitActionExecutor的handleInsert方法基本相同
    return new FlinkLazyInsertIterable<>(recordItr, true, config, instantTime, table,
                                         idPfx, taskContextSupplier, new ExplicitWriteHandleFactory(writeHandle));
}

 
 
接下来两节分别对更新数据和插入数据分别分析。
 
 
更新数据逻辑
 
 
FlinkAppendHandle的doAppend方法位于父类HoodieAppendHandle中。
 
 
public void doAppend() {
    while (recordItr.hasNext()) {
        // 逐个遍历record
        HoodieRecord record = recordItr.next();
        init(record);
        flushToDiskIfRequired(record, false);
        writeToBuffer(record);
    }
    appendDataAndDeleteBlocks(header, true);
    estimatedNumberOfBytesWritten += averageRecordSize * numberOfRecords;
}

 
 
init方法查找record所属的file slice，获取log文件对应的writer，准备在下一步写入此文件。逻辑如下：
 
 
private void init(HoodieRecord record) {
    // init只执行一次
    if (doInit) {
        // extract some information from the first record
        // 获取这个hudi表的文件系统结构
        SliceView rtView = hoodieTable.getSliceView();
        // 获取最新的file slice（base file + log files）
        Option fileSlice = rtView.getLatestFileSlice(partitionPath, fileId);
        // Set the base commit time as the current instantTime for new inserts into log files
        String baseInstantTime;
        String baseFile = "";
        List logFiles = new ArrayList<>();
        // 如果找到了file slice
        if (fileSlice.isPresent()) {
            // 获取file slice的instant time（slice什么时候创建的）
            baseInstantTime = fileSlice.get().getBaseInstantTime();
            // 获取baseFile名称
            baseFile = fileSlice.get().getBaseFile().map(BaseFile::getFileName).orElse("");
            // 获取所有的log文件
            logFiles = fileSlice.get().getLogFiles().map(HoodieLogFile::getFileName).collect(Collectors.toList());
        } else {
            // 如果没有找到file slice
            baseInstantTime = instantTime;
            // Handle log file only case. This is necessary for the concurrent clustering and writer case (e.g., consistent hashing bucket index).
            // NOTE: flink engine use instantTime to mark operation type, check BaseFlinkCommitActionExecutor::execute
            // 如果record中存了instant time，且instant time是long类型的timestamp，使用record的instant time
            // instant time在更新和插入数据的时候是I或者U，不是long类型的timestamp，这种情况不会进入if分支
            if (record.getCurrentLocation() != null && HoodieInstantTimeGenerator.isValidInstantTime(record.getCurrentLocation().getInstantTime())) {
                baseInstantTime = record.getCurrentLocation().getInstantTime();
            }
            // This means there is no base data file, start appending to a new log file
            // 创建新的file slice
            fileSlice = Option.of(new FileSlice(partitionPath, baseInstantTime, this.fileId));
            LOG.info("New AppendHandle for partition :" + partitionPath);
        }

        // Prepare the first write status
        // 创建新的log写入状态
        writeStatus.setStat(new HoodieDeltaWriteStat());
        // 设置file id
        writeStatus.setFileId(fileId);
        // 设置partition path
        writeStatus.setPartitionPath(partitionPath);
        // 估算出每条数据的平均大小
        averageRecordSize = sizeEstimator.sizeEstimate(record);

        // 组装deltaWriteStat，对应的是log写入状态
        HoodieDeltaWriteStat deltaWriteStat = (HoodieDeltaWriteStat) writeStatus.getStat();
        deltaWriteStat.setPrevCommit(baseInstantTime);
        deltaWriteStat.setPartitionPath(partitionPath);
        deltaWriteStat.setFileId(fileId);
        deltaWriteStat.setBaseFile(baseFile);
        deltaWriteStat.setLogFiles(logFiles);

        try {
            // Save hoodie partition meta in the partition path
            // 组装partition元数据
            HoodiePartitionMetadata partitionMetadata = new HoodiePartitionMetadata(fs, baseInstantTime,
                                                                                    new Path(config.getBasePath()), FSUtils.getPartitionPath(config.getBasePath(), partitionPath),
                                                                                    hoodieTable.getPartitionMetafileFormat());
            // 写入partition元数据
            partitionMetadata.trySave(getPartitionId());

            // Since the actual log file written to can be different based on when rollover happens, we use the
            // base file to denote some log appends happened on a slice. writeToken will still fence concurrent
            // writers.
            // https://issues.apache.org/jira/browse/HUDI-1517
            // 创建一个标记文件
            // 标记要写入log file
            createMarkerFile(partitionPath, FSUtils.makeBaseFileName(baseInstantTime, writeToken, fileId, hoodieTable.getBaseFileExtension()));

            // 创建log writer，用于将数据写入log文件
            this.writer = createLogWriter(fileSlice, baseInstantTime);
        } catch (Exception e) {
            LOG.error("Error in update task at commit " + instantTime, e);
            writeStatus.setGlobalError(e);
            throw new HoodieUpsertException("Failed to initialize HoodieAppendHandle for FileId: " + fileId + " on commit "
                                            + instantTime + " on HDFS path " + hoodieTable.getMetaClient().getBasePath() + "/" + partitionPath, e);
        }
        // init执行后设置为false，不会反复执行
        doInit = false;
    }
}

 
 
flushToDiskIfRequired在预估record缓存了一定量的时候，flush这些records到log文件。方法逻辑如下：
 
 
/**
 * Checks if the number of records have reached the set threshold and then flushes the records to disk.
 */
private void flushToDiskIfRequired(HoodieRecord record, boolean appendDeleteBlocks) {
    // 估算已存入的record数量是否超过了预估record数量
    // 预估record数量为最大block size / 平均record size
    // 最大block由hoodie.logfile.data.block.max.size配置项决定
    // 或者记录的数据条数是100的倍数
    if (numberOfRecords >= (int) (maxBlockSize / averageRecordSize)
        || numberOfRecords % NUMBER_OF_RECORDS_TO_ESTIMATE_RECORD_SIZE == 0) {
        // 修正估算的平均record大小，原来的大小权重占80%，新record估算出的大小占20%
        averageRecordSize = (long) (averageRecordSize * 0.8 + sizeEstimator.sizeEstimate(record) * 0.2);
    }

    // Append if max number of records reached to achieve block size
    // 重新估算完如果还是超过预估record数量
    if (numberOfRecords >= (int) (maxBlockSize / averageRecordSize)) {
        // Recompute averageRecordSize before writing a new block and update existing value with
        // avg of new and old
        LOG.info("Flush log block to disk, the current avgRecordSize => " + averageRecordSize);
        // Delete blocks will be appended after appending all the data blocks.
        // flush数据block到磁盘，delete block被忽略（appendDeleteBlocks为false）
        // 这个方法后面分析
        appendDataAndDeleteBlocks(header, appendDeleteBlocks);
        // 更新已写入数据预估大小计数器
        estimatedNumberOfBytesWritten += averageRecordSize * numberOfRecords;
        // 已写入数据置0
        numberOfRecords = 0;
    }
}

 
 
writeToBuffer方法将record写入到recordList缓存中，要删除的数据位于recordsToDelete缓存。逻辑分析如下：
 
 
private void writeToBuffer(HoodieRecord record) {
    // 检查appendHandle中的partition path和record的partition path必须相同
    if (!partitionPath.equals(record.getPartitionPath())) {
        HoodieUpsertException failureEx = new HoodieUpsertException("mismatched partition path, record partition: "
                                                                    + record.getPartitionPath() + " but trying to insert into partition: " + partitionPath);
        writeStatus.markFailure(record, failureEx, record.getMetadata());
        return;
    }

    // update the new location of the record, so we know where to find it next
    if (needsUpdateLocation()) {
        // 恒为true
        record.unseal();
        // 设置新的record location
        record.setNewLocation(new HoodieRecordLocation(instantTime, fileId));
        record.seal();
    }
    // fetch the ordering val first in case the record was deflated.
    // 获取顺序值
    final Comparable orderingVal = record.getOrderingValue(writeSchema, recordProperties);
    // 做些准备工作，后面分析
    Option indexedRecord = prepareRecord(record);
    if (indexedRecord.isPresent()) {
        // Skip the ignored record.
        try {
            if (!indexedRecord.get().shouldIgnore(writeSchema, recordProperties)) {
                // 如果payload不为空，不用忽略
                // 加入buffer中，等待flush到磁盘
                recordList.add(indexedRecord.get());
            }
        } catch (IOException e) {
            writeStatus.markFailure(record, e, record.getMetadata());
            LOG.error("Error writing record  " + indexedRecord.get(), e);
        }
    } else {
        // 否则，添加到需要删除的元素缓存中
        recordsToDelete.add(DeleteRecord.create(record.getKey(), orderingVal));
    }
    // record计数器自增1
    numberOfRecords++;
}

 
 
prepareRecord方法判断数据是要新增还是要删除的。
 
 
private Option prepareRecord(HoodieRecord hoodieRecord) {
    // 获取record的metadata
    Option> recordMetadata = hoodieRecord.getMetadata();
    // 非compaction操作useWriterSchema为false，采用writeSchema
    Schema schema = useWriterSchema ? writeSchemaWithMetaFields : writeSchema;
    try {
        // Pass the isUpdateRecord to the props for HoodieRecordPayload to judge
        // Whether it is an update or insert record.
        // 如果record有currentLocation，说明数据已存在，为update类型
        boolean isUpdateRecord = isUpdateRecord(hoodieRecord);
        // If the format can not record the operation field, nullify the DELETE payload manually.
        // 如果不允许记录operation元数据字段，并且数据类型为删除
        // 需要清空数据的payload来表示这条数据是删除的
        boolean nullifyPayload = HoodieOperation.isDelete(hoodieRecord.getOperation()) && !config.allowOperationMetadataField();
        recordProperties.put(HoodiePayloadProps.PAYLOAD_IS_UPDATE_RECORD_FOR_MOR, String.valueOf(isUpdateRecord));

        Option finalRecordOpt = nullifyPayload ? Option.empty() : Option.of(hoodieRecord);
        // Check for delete
        if (finalRecordOpt.isPresent() && !finalRecordOpt.get().isDelete(schema, recordProperties)) {
            // 如果不是需要删除的数据
            HoodieRecord finalRecord = finalRecordOpt.get();
            // Check if the record should be ignored (special case for [[ExpressionPayload]])
            if (finalRecord.shouldIgnore(schema, recordProperties)) {
                return finalRecordOpt;
            }

            // Prepend meta-fields into the record
            // 生成metadata字段，将其加入到record中
            MetadataValues metadataValues = populateMetadataFields(finalRecord);
            HoodieRecord populatedRecord =
                finalRecord.prependMetaFields(schema, writeSchemaWithMetaFields, metadataValues, recordProperties);

            // NOTE: Record have to be cloned here to make sure if it holds low-level engine-specific
            //       payload pointing into a shared, mutable (underlying) buffer we get a clean copy of
            //       it since these records will be put into the recordList(List).
            // 准备返回数据
            finalRecordOpt = Option.of(populatedRecord.copy());
            if (isUpdateRecord || isLogCompaction) {
                updatedRecordsWritten++;
            } else {
                insertRecordsWritten++;
            }
            recordsWritten++;
        } else {
            // 如果是删除数据
            finalRecordOpt = Option.empty();
            recordsDeleted++;
        }

        writeStatus.markSuccess(hoodieRecord, recordMetadata);
        // deflate record payload after recording success. This will help users access payload as a
        // part of marking
        // record successful.
        hoodieRecord.deflate();
        return finalRecordOpt;
    } catch (Exception e) {
        LOG.error("Error writing record  " + hoodieRecord, e);
        writeStatus.markFailure(hoodieRecord, e, recordMetadata);
    }
    return Option.empty();
}

 
 
appendDataAndDeleteBlocks方法将新数据缓存recordList和delete缓存recordsToDelete中的数据写入到log block中。
 
 
/**
 * Appends data and delete blocks. When appendDeleteBlocks value is false, only data blocks are appended.
 * This is done so that all the data blocks are created first and then a single delete block is added.
 * Otherwise what can end up happening is creation of multiple small delete blocks get added after each data block.
 */
protected void appendDataAndDeleteBlocks(Map header, boolean appendDeleteBlocks) {
    try {
        // log block header信息添加instant time和schema
        header.put(HoodieLogBlock.HeaderMetadataType.INSTANT_TIME, instantTime);
        header.put(HoodieLogBlock.HeaderMetadataType.SCHEMA, writeSchemaWithMetaFields.toString());
        List blocks = new ArrayList<>(2);
        if (recordList.size() > 0) {
            // 默认需要添加metadata，否则无法增量查询
            String keyField = config.populateMetaFields()
                // 采用_hoodie_record_key作为key字段
                ? HoodieRecord.RECORD_KEY_METADATA_FIELD
                // 否则使用hoodie.table.recordkey.fields作为key字段
                : hoodieTable.getMetaClient().getTableConfig().getRecordKeyFieldProp();

            // pickLogDataBlockFormat根据base file格式决定log写入格式。对于parquet采用avro格式
            // 根据base file格式，将数据封装为对应格式的log block
            blocks.add(getBlock(config, pickLogDataBlockFormat(), recordList, header, keyField));
        }

        if (appendDeleteBlocks && recordsToDelete.size() > 0) {
            // 增加删除的数据block
            blocks.add(new HoodieDeleteBlock(recordsToDelete.toArray(new DeleteRecord[0]), header));
        }

        if (blocks.size() > 0) {
            // 写入数据block
            AppendResult appendResult = writer.appendBlocks(blocks);
            // 处理写入结果
            processAppendResult(appendResult, recordList);
            // 清空record缓存
            recordList.clear();
            if (appendDeleteBlocks) {
                // 清空delete record缓存
                recordsToDelete.clear();
            }
        }
    } catch (Exception e) {
        throw new HoodieAppendException("Failed while appending records to " + writer.getLogFile().getPath(), e);
    }
}

 
 
具体写入log block的过程可参考HoodieLogFormatWritter的appendBlocks方法。
 
 
@Override
public AppendResult appendBlocks(List blocks) throws IOException, InterruptedException {
    // Find current version
    // 获取log格式的版本，为1
    HoodieLogFormat.LogFormatVersion currentLogFormatVersion =
        new HoodieLogFormatVersion(HoodieLogFormat.CURRENT_VERSION);

    // 获取log文件的outputStream
    FSDataOutputStream originalOutputStream = getOutputStream();
    // 获取写入起始位置
    long startPos = originalOutputStream.getPos();
    // 已写入内容为0
    long sizeWritten = 0;
    // HUDI-2655. here we wrap originalOutputStream to ensure huge blocks can be correctly written
    // 确保巨大的block能够正确的写入
    FSDataOutputStream outputStream = new FSDataOutputStream(originalOutputStream, new FileSystem.Statistics(fs.getScheme()), startPos);
    // 遍历需要写入的block
    for (HoodieLogBlock block: blocks) {
        // 已写入数据大小
        long startSize = outputStream.size();

        // 1. Write the magic header for the start of the block
        // 写入magic数据，作为block开头
        // 数据为#HUDI#
        outputStream.write(HoodieLogFormat.MAGIC);

        // bytes for header
        // 获取log block的header数据
        byte[] headerBytes = HoodieLogBlock.getLogMetadataBytes(block.getLogBlockHeader());
        // content bytes
        // 获取block内容
        byte[] content = block.getContentBytes();
        // bytes for footer
        // 获取block footer
        byte[] footerBytes = HoodieLogBlock.getLogMetadataBytes(block.getLogBlockFooter());

        // 2. Write the total size of the block (excluding Magic)
        // 写入block长度
        outputStream.writeLong(getLogBlockLength(content.length, headerBytes.length, footerBytes.length));

        // 3. Write the version of this log block
        // 写入log format的版本
        outputStream.writeInt(currentLogFormatVersion.getVersion());
        // 4. Write the block type
        // 写入block类型
        outputStream.writeInt(block.getBlockType().ordinal());

        // 5. Write the headers for the log block
        // 写入header
        outputStream.write(headerBytes);
        // 6. Write the size of the content block
        // 写入content的长度
        outputStream.writeLong(content.length);
        // 7. Write the contents of the data block
        // 写入content
        outputStream.write(content);
        // 8. Write the footers for the log block
        // 写入footer
        outputStream.write(footerBytes);
        // 9. Write the total size of the log block (including magic) which is everything written
        // until now (for reverse pointer)
        // Update: this information is now used in determining if a block is corrupt by comparing to the
        //   block size in header. This change assumes that the block size will be the last data written
        //   to a block. Read will break if any data is written past this point for a block.
        // 记录log block总大小
        outputStream.writeLong(outputStream.size() - startSize);

        // Fetch the size again, so it accounts also (9).

        // HUDI-2655. Check the size written to avoid log blocks whose size overflow.
        // 检查避免overflow
        if (outputStream.size() == Integer.MAX_VALUE) {
            throw new HoodieIOException("Blocks appended may overflow. Please decrease log block size or log block amount");
        }
        sizeWritten +=  outputStream.size() - startSize;
    }
    // Flush all blocks to disk
    // flush到磁盘
    flush();

    // 构建写入结果
    AppendResult result = new AppendResult(logFile, startPos, sizeWritten);
    // roll over if size is past the threshold
    // 检查日志文件是否超出大小
    // 由hoodie.logfile.max.size配置项控制
    // 超出大小需要滚动到新的日志文件
    rolloverIfNeeded();
    return result;
}

 
 
到此为止MOR更新数据的逻辑分析完毕。
 
 
插入数据逻辑
 
 
和前面COW表的插入数据逻辑FlinkLazyInsertIterable类似。不同的是到执行doWrite方法这一步。
 
 
FlinkAppendHandle的doWrite方法位于父类HoodieAppendHandle中。doWrite方法内容为：
 
 
@Override
protected void doWrite(HoodieRecord record, Schema schema, TypedProperties props) {
    Option> recordMetadata = record.getMetadata();
    try {
        init(record);
        flushToDiskIfRequired(record, false);
        writeToBuffer(record);
    } catch (Throwable t) {
        // Not throwing exception from here, since we don't want to fail the entire job
        // for a single record
        writeStatus.markFailure(record, t, recordMetadata);
        LOG.error("Error writing record " + record, t);
    }
}

 
 
这三个方法和前面更新数据的逻辑相同，不再赘述。
 
 
MOR Insert
 
 
@Override
public HoodieWriteMetadata> upsert(
    HoodieEngineContext context,
    HoodieWriteHandle writeHandle,
    String instantTime,
    List> hoodieRecords) {
    // 检查必须是FlinkAppendHandle类型
    ValidationUtils.checkArgument(writeHandle instanceof FlinkAppendHandle,
                                  "MOR write handle should always be a FlinkAppendHandle");
    FlinkAppendHandle appendHandle = (FlinkAppendHandle) writeHandle;
    // 调用FlinkUpsertDeltaCommitActionExecutor，和upsert相同
    return new FlinkUpsertDeltaCommitActionExecutor<>(context, appendHandle, config, this, instantTime, hoodieRecords).execute();
}

 
 
这里逻辑和upsert相同，不再赘述。
 
 
本博客为作者原创，欢迎大家参与讨论和批评指正。如需转载请注明出处。
 

                            
                        
                    
                    
                    

                    
                    
                    

                
                

                    
                

            
        
    
    

        
你可能感兴趣的:(Hudi 源码之数据写入逻辑)

        

            

                
    
                    
  • 机器学习与深度学习间关系与区别
                        ℒℴѵℯ心·动ꦿ໊ོ꫞
人工智能学习深度学习python
                        
    一、机器学习概述定义机器学习（MachineLearning,ML）是一种通过数据驱动的方法，利用统计学和计算算法来训练模型，使计算机能够从数据中学习并自动进行预测或决策。机器学习通过分析大量数据样本，识别其中的模式和规律，从而对新的数据进行判断。其核心在于通过训练过程，让模型不断优化和提升其预测准确性。主要类型1.监督学习（SupervisedLearning）监督学习是指在训练数据集中包含输入
    
                    
    • 
                    
  • 【iOS】MVC设计模式
                        Magnetic_h
iosmvc设计模式objective-c学习ui
                        
    MVC前言如何设计一个程序的结构，这是一门专门的学问，叫做"架构模式"（architecturalpattern），属于编程的方法论。MVC模式就是架构模式的一种。它是Apple官方推荐的App开发架构，也是一般开发者最先遇到、最经典的架构。MVC各层controller层Controller/ViewController/VC（控制器）负责协调Model和View，处理大部分逻辑它将数据从Mod
    
                    
    • 
                    
  • 微服务下功能权限与数据权限的设计与实现
                        nbsaas-boot
微服务java架构
                        
    在微服务架构下，系统的功能权限和数据权限控制显得尤为重要。随着系统规模的扩大和微服务数量的增加，如何保证不同用户和服务之间的访问权限准确、细粒度地控制，成为设计安全策略的关键。本文将讨论如何在微服务体系中设计和实现功能权限与数据权限控制。1.功能权限与数据权限的定义功能权限：指用户或系统角色对特定功能的访问权限。通常是某个用户角色能否执行某个操作，比如查看订单、创建订单、修改用户资料等。数据权限：
    
                    
    • 
                    
  • c++ 的iostream 和 c++的stdio的区别和联系
                        黄卷青灯77
c++算法开发语言iostreamstdio
                        
    在C++中，iostream和C语言的stdio.h都是用于处理输入输出的库，但它们在设计、用法和功能上有许多不同。以下是两者的区别和联系：区别1.编程风格iostream（C++风格）：C++标准库中的输入输出流类库，支持面向对象的输入输出操作。典型用法是cin（输入）和cout（输出），使用>操作符来处理数据。更加类型安全，支持用户自定义类型的输入输出。#includeintmain(){in
    
                    
    • 
                    
  • 《投行人生》读书笔记
                        小蘑菇的树洞

                        
    《投行人生》----作者詹姆斯-A-朗德摩根斯坦利副主席40年的职业洞见-很短小精悍的篇幅，比较适合初入职场的新人。第一部分成功的职业生涯需要规划1.情商归为适应能力分享与协作同理心适应能力，更多的是自我意识，你有能力识别自己的情并分辨这些情绪如何影响你的思想和行为。2.对于初入职场的人的建议，细节，截止日期和数据很重要截止日期，一种有效的方法是请老板为你所有的任务进行优先级排序。和老板喝咖啡的好
    
                    
    • 
                    
  • Long类型前后端数据不一致
                        igotyback
前端
                        
    响应给前端的数据浏览器控制台中response中看到的Long类型的数据是正常的到前端数据不一致前后端数据类型不匹配是一个常见问题，尤其是当后端使用Java的Long类型（64位）与前端JavaScript的Number类型（最大安全整数为2^53-1，即16位）进行数据交互时，很容易出现精度丢失的问题。这是因为JavaScript中的Number类型无法安全地表示超过16位的整数。为了解决这个问
    
                    
    • 
                    
  • 扫地机类清洁产品之直流无刷电机控制
                        悟空胆好小
清洁服务机器人单片机人工智能
                        
    扫地机类清洁产品之直流无刷电机控制1.1前言扫地机产品有很多的电机控制，滚刷电机1个，边刷电机1-2个，清水泵电机，风机一个，部分中高端产品支持抹布功能，也就是存在抹布盘电机，还有追觅科沃斯石头等边刷抬升电机，滚刷抬升电机等的，这些电机有直流有刷电机，直接无刷电机，步进电机，电磁阀，挪动泵等不同类型。电机的原理，驱动控制方式也不行。接下来一段时间的几个文章会作个专题分析分享。直流有刷电机会自动持续
    
                    
    • 
                    
  • 店群合一模式下的社区团购新发展——结合链动 2+1 模式、AI 智能名片与 S2B2C 商城小程序源码
                        说私域
人工智能小程序
                        
    摘要：本文探讨了店群合一的社区团购平台在当今商业环境中的重要性和优势。通过分析店群合一模式如何将互联网社群与线下终端紧密结合，阐述了链动2+1模式、AI智能名片和S2B2C商城小程序源码在这一模式中的应用价值。这些创新元素的结合为社区团购带来了新的机遇，提升了用户信任感、拓展了营销渠道，并实现了线上线下的完美融合。一、引言随着互联网技术的不断发展，社区团购作为一种新兴的商业模式，在满足消费者日常需
    
                    
    • 
                    
  • 2018-07-23-催眠日作业-#不一样的31天#-66小鹿
                        小鹿_33

                        
    预言日：人总是在逃避命运的路上，与之不期而遇。心理学上有个著名的名词，叫做自证预言；经济学上也有一个很著名的定律叫做，墨菲定律；在灵修派上，还有一个很著名的法则，叫做吸引力法则。这3个领域的词，虽然看起来不太一样，但是他们都在告诉人们一个现象：你越担心什么，就越有可能会发生什么。同样的道理，你越想得到什么，就应该要积极地去创造什么。无论是自证预言，墨菲定律还是吸引力法则，对人都有正反2个维度的影响
    
                    
    • 
                    
  • 《大清方方案》| 第二话
                        谁佐清欢

                        
    和珅究竟说了些什么？竟能令堂堂九五之尊龙颜失色！此处暂且按下不表；单说这位乾隆皇帝，果真不愧是康熙从小带过的，一旦决定了要做的事，便杀伐决断毫不含糊。他当即亲自拟旨，着令和珅为钦差大臣，全权负责处理方方事件，并钦赐尚方宝剑，遇急则三品以下官员可先斩后奏。和珅身负皇上重托，岂敢有半点怠慢，当夜即率领相关人等，马不停蹄杀奔江汉。这一路上，和珅的几位幕僚一直在商讨方方事件的处置方案。有位年轻幕僚建议快刀
    
                    
    • 
                    
  • Python数据分析与可视化实战指南
                        William数据分析
pythonpython数据
                        
    在数据驱动的时代，Python因其简洁的语法、强大的库生态系统以及活跃的社区，成为了数据分析与可视化的首选语言。本文将通过一个详细的案例，带领大家学习如何使用Python进行数据分析，并通过可视化来直观呈现分析结果。一、环境准备1.1安装必要库在开始数据分析和可视化之前，我们需要安装一些常用的库。主要包括pandas、numpy、matplotlib和seaborn等。这些库分别用于数据处理、数学
    
                    
    • 
                    
  • WPF中的ComboBox控件几种数据绑定的方式
                        互联网打工人no1
wpfc#
                        
    一、用字典给ItemsSource赋值（此绑定用的地方很多，建议熟练掌握）在XMAL中：在CS文件中privatevoidBindData(){DictionarydicItem=newDictionary();dicItem.add(1,"北京");dicItem.add(2,"上海");dicItem.add(3,"广州");cmb_list.ItemsSource=dicItem;cmb_l
    
                    
    • 
                    
  • 《庄子.达生9》
                        钱江潮369

                        
    【原文】孔子观于吕梁，县水三十仞，流沫四十里，鼋鼍鱼鳖之所不能游也。见一丈夫游之，以为有苦而欲死也，使弟子并流而拯之。数百步而出，被发行歌而游于塘下。孔子从而问焉，曰：“吾以子为鬼，察子则人也。请问，‘蹈水有道乎’”曰：“亡，吾无道。吾始乎故，长乎性，成乎命。与齐俱入，与汩偕出，从水之道而不为私焉。此吾所以蹈之也。”孔子曰：“何谓始乎故，长乎性，成乎命？”曰：“吾生于陵而安于陵，故也；长于水而安于
    
                    
    • 
                    
  • Pyecharts数据可视化大屏：打造沉浸式数据分析体验
                        我的运维人生
信息可视化数据分析数据挖掘运维开发技术共享
                        
    Pyecharts数据可视化大屏：打造沉浸式数据分析体验在当今这个数据驱动的时代，如何将海量数据以直观、生动的方式展现出来，成为了数据分析师和企业决策者关注的焦点。Pyecharts，作为一款基于Python的开源数据可视化库，凭借其丰富的图表类型、灵活的配置选项以及高度的定制化能力，成为了构建数据可视化大屏的理想选择。本文将深入探讨如何利用Pyecharts打造数据可视化大屏，并通过实际代码案例
    
                    
    • 
                    
  • Python教程：一文了解使用Python处理XPath
                        旦莫
Python进阶python开发语言
                        
    目录1.环境准备1.1安装lxml1.2验证安装2.XPath基础2.1什么是XPath？2.2XPath语法2.3示例XML文档3.使用lxml解析XML3.1解析XML文档3.2查看解析结果4.XPath查询4.1基本路径查询4.2使用属性查询4.3查询多个节点5.XPath的高级用法5.1使用逻辑运算符5.2使用函数6.实战案例6.1从网页抓取数据6.1.1安装Requests库6.1.2代
    
                    
    • 
                    
  • Google earth studio 简介
                        陟彼高冈yu
旅游
                        
    GoogleEarthStudio是一个基于Web的动画工具，专为创作使用GoogleEarth数据的动画和视频而设计。它利用了GoogleEarth强大的三维地图和卫星影像数据库，使用户能够轻松地创建逼真的地球动画、航拍视频和动态地图可视化。网址为https://www.google.com/earth/studio/。GoogleEarthStudio是一个基于Web的动画工具，专为创作使用G
    
                    
    • 
                    
  • LLM 词汇表
                        落难Coder
LLMsNLP大语言模型大模型llama人工智能
                        
    Contextwindow“上下文窗口”是指语言模型在生成新文本时能够回溯和参考的文本量。这不同于语言模型训练时所使用的大量数据集，而是代表了模型的“工作记忆”。较大的上下文窗口可以让模型理解和响应更复杂和更长的提示，而较小的上下文窗口可能会限制模型处理较长提示或在长时间对话中保持连贯性的能力。Fine-tuning微调是使用额外的数据进一步训练预训练语言模型的过程。这使得模型开始表示和模仿微调数
    
                    
    • 
                    
  • 关于提高复杂业务逻辑代码可读性的思考
                        编程经验分享
开发经验java数据库开发语言
                        
    目录前言需求场景常规写法拆分方法领域对象总结前言实际工作中大部分时间都是在写业务逻辑，一般都是三层架构，表示层（Controller）接收客户端请求，并对入参做检验，业务逻辑层（Service）负责处理业务逻辑，一般开发都是在这一层中写具体的业务逻辑。数据访问层（Dao）是直接和数据库交互的，用于查数据给业务逻辑层，或者是将业务逻辑层处理后的数据写入数据库。简单的增删改查接口不用多说，基本上写好一
    
                    
    • 
                    
  • SQL Server_查询某一数据库中的所有表的内容
                        qq_42772833
SQLServer数据库sqlserver
                        
    1.查看所有表的表名要列出CrabFarmDB数据库中的所有表（名），可以使用以下SQL语句：USECrabFarmDB;--切换到目标数据库GOSELECTTABLE_NAMEFROMINFORMATION_SCHEMA.TABLESWHERETABLE_TYPE='BASETABLE';对这段SQL脚本的解释：SELECTTABLE_NAME：这个语句的作用是从查询结果中选择TABLE_NAM
    
                    
    • 
                    
  • 四章-32-点要素的聚合
                        彩云飘过

                        
    本文基于腾讯课堂老胡的课《跟我学Openlayers--基础实例详解》做的学习笔记，使用的openlayers5.3.xapi。源码见1032.html，对应的官网示例https://openlayers.org/en/latest/examples/cluster.htmlhttps://openlayers.org/en/latest/examples/earthquake-clusters.
    
                    
    • 
                    
  • DIV+CSS+JavaScript技术制作网页（旅游主题网页设计与制作）云南大理
                        STU学生网页设计
网页设计期末网页作业html静态网页html5期末大作业网页设计web大作业
                        
    ️精彩专栏推荐作者主页:【进入主页—获取更多源码】web前端期末大作业：【HTML5网页期末作业(1000套)】程序员有趣的告白方式：【HTML七夕情人节表白网页制作(110套)】文章目录二、网站介绍三、网站效果▶️1.视频演示2.图片演示四、网站代码HTML结构代码CSS样式代码五、更多源码二、网站介绍网站布局方面：计划采用目前主流的、能兼容各大主流浏览器、显示效果稳定的浮动网页布局结构。网站程
    
                    
    • 
                    
  • 高端密码学院笔记285
                        柚子_b4b4

                        
    高端幸福密码学院（高级班）幸福使者：李华第（598）期《幸福》之回归内在深层生命原动力基础篇——揭秘“激励”成长的喜悦心理案例分析主讲：刘莉一，知识扩充:成功=艰苦劳动+正确方法+少说空话。贪图省力的船夫，目标永远下游。智者的梦再美，也不如愚人实干的脚印。幸福早课堂2020.10.16星期五一笔记:1，重视和珍惜的前提是知道它的价值非常重要，当你珍惜了，你就真正定下来，真正的学到身上。2，大家需要
    
                    
    • 
                    
  • 2020-04-12每天三百字之连接与替代
                        冷眼看潮

                        
    不知道是不是好为人师，有时候还真想和别人分享一下我对某些现象的看法或者解释。人类社会不断发展进步的过程，就是不断连接与替代的过程。人类发现了火并应用火以后，告别了茹毛饮血的野兽般的原始生活（火烧、烹饪替代了生食）人类用石器代替了完全手工，工具的使用使人类进步一大步。类似这样的替代还有很多，随着科技的发展，有更多的原始的事物被替代，代之以更高效、更先进的技术。在近现代，汽车替代了马车，高速公路和铁路
    
                    
    • 
                    
  • 使用LLaVa和Ollama实现多模态RAG示例
                        llzwxh888
python人工智能开发语言
                        
    本文将详细介绍如何使用LLaVa和Ollama实现多模态RAG（检索增强生成），通过提取图像中的结构化数据、生成图像字幕等功能来展示这一技术的强大之处。安装环境首先，您需要安装以下依赖包：!pipinstallllama-index-multi-modal-llms-ollama!pipinstallllama-index-readers-file!pipinstallunstructured!p
    
                    
    • 
                    
  • 使用Apify加载Twitter消息以进行微调的完整指南
                        nseejrukjhad
twittereasyui前端python
                        
    #使用Apify加载Twitter消息以进行微调的完整指南##引言在自然语言处理领域，微调模型以适应特定任务是提升模型性能的常见方法。本文将介绍如何使用Apify从Twitter导出聊天信息，以便进一步进行微调。##主要内容###使用Apify导出推文首先，我们需要从Twitter导出推文。Apify可以帮助我们做到这一点。通过Apify的强大功能，我们可以批量抓取和导出数据，适用于各类应用场景。
    
                    
    • 
                    
  • 深入理解 MultiQueryRetriever：提升向量数据库检索效果的强大工具
                        nseejrukjhad
数据库python
                        
    深入理解MultiQueryRetriever：提升向量数据库检索效果的强大工具引言在人工智能和自然语言处理领域，高效准确的信息检索一直是一个关键挑战。传统的基于距离的向量数据库检索方法虽然广泛应用，但仍存在一些局限性。本文将介绍一种创新的解决方案：MultiQueryRetriever，它通过自动生成多个查询视角来增强检索效果，提高结果的相关性和多样性。MultiQueryRetriever的工
    
                    
    • 
                    
  • 数组去重
                        好奇的猫猫猫

                        
    整理自js中基础数据结构数组去重问题思考？如何去除数组中重复的项例如数组：[1,3,4,3,5]我们在做去重的时候，一开始想到的肯定是，逐个比较，外面一层循环，内层后一个与前一个一比较，如果是久不将当前这一项放进新的数组，挨个比较完之后返回一个新的去过重复的数组不好的实践方式上述方法效率极低，代码量还多，思考？有没有更好的方法这时候不禁一想当然有了！！！hashtable啊，通过对象的hash办法
    
                    
    • 
                    
  • 东南林氏之九牧林候选父系
                        祖缘树TheYtree

                        
    渊源介绍东晋初年晋安林始祖林禄公入闽，传十世隋右丞林茂，由晋安迁居莆田北螺村。又五世而至林万宠，唐开元间任高平太守，生三子：韬、披、昌。韬公之孙攒，唐德宗立双阙以旌表其孝，时号"阙下林家"。昌公字茂吉，乃万宠公第三子，官兵部司马，配宋氏，生一子名萍。萍于唐贞元间明经及第，官沣洲司马(后追赠中宪大夫)。唐太和年间归隐后，迁居仙游游洋，世称“游洋林”；其后裔居游洋后迁移漳州漳浦路下，由路下林第四房平和
    
                    
    • 
                    
  • 关于城市旅游的HTML网页设计——(旅游风景云南 5页)HTML+CSS+JavaScript
                        二挡起步
web前端期末大作业javascripthtmlcss旅游风景
                        
    ⛵源码获取文末联系✈Web前端开发技术描述网页设计题材，DIV+CSS布局制作,HTML+CSS网页设计期末课程大作业|游景点介绍|旅游风景区|家乡介绍|等网站的设计与制作|HTML期末大学生网页设计作业，Web大学生网页HTML：结构CSS：样式在操作方面上运用了html5和css3，采用了div+css结构、表单、超链接、浮动、绝对定位、相对定位、字体样式、引用视频等基础知识JavaScrip
    
                    
    • 
                    
  • Day1笔记-Python简介&标识符和关键字&输入输出
                        ~在杰难逃~
Pythonpython开发语言大数据数据分析数据挖掘
                        
    大家好，从今天开始呢，杰哥开展一个新的专栏，当然，数据分析部分也会不定时更新的，这个新的专栏主要是讲解一些Python的基础语法和知识，帮助0基础的小伙伴入门和学习Python，感兴趣的小伙伴可以开始认真学习啦！一、Python简介【了解】1.计算机工作原理编程语言就是用来定义计算机程序的形式语言。我们通过编程语言来编写程序代码，再通过语言处理程序执行向计算机发送指令，让计算机完成对应的工作，编程
    
                    
    • 
                                
  • 项目中 枚举与注解的结合使用
                                    飞翔的马甲
javaenumannotation
                                    
    前言：版本兼容，一直是迭代开发头疼的事，最近新版本加上了支持新题型，如果新创建一份问卷包含了新题型，那旧版本客户端就不支持，如果新创建的问卷不包含新题型，那么新旧客户端都支持。这里面我们通过给问卷类型枚举增加自定义注解的方式完成。顺便巩固下枚举与注解。 
 
一、枚举 
1.在创建枚举类的时候，该类已继承java.lang.Enum类，所以自定义枚举类无法继承别的类，但可以实现接口。 
 
   
    
                                
    • 
                                
  • 【Scala十七】Scala核心十一：下划线_的用法
                                    bit1129
scala
                                    
    下划线_在Scala中广泛应用，_的基本含义是作为占位符使用。_在使用时是出问题非常多的地方，本文将不断完善_的使用场景以及所表达的含义 
  1. 在高阶函数中使用 
scala> val list = List(-3,8,7,9)
list: List[Int] = List(-3, 8, 7, 9)

scala> list.filter(_ > 7)
r
    
                                
    • 
                                
  • web缓存基础：术语、http报头和缓存策略
                                    dalan_123
Web
                                    
    对于很多人来说，去访问某一个站点，若是该站点能够提供智能化的内容缓存来提高用户体验，那么最终该站点的访问者将络绎不绝。缓存或者对之前的请求临时存储，是http协议实现中最核心的内容分发策略之一。分发路径中的组件均可以缓存内容来加速后续的请求，这是受控于对该内容所声明的缓存策略。接下来将讨web内容缓存策略的基本概念，具体包括如如何选择缓存策略以保证互联网范围内的缓存能够正确处理的您的内容，并谈论下
    
                                
    • 
                                
  • crontab 问题
                                    周凡杨
linuxcrontabunix
                                    
      
一：  0481-079   Reached   a   symbol   that   is   not   expected.   
   
背景：  
*/5   *   *   *   *  /usr/IBMIHS/rsync.sh  
    
                                
    • 
                                
  • 让tomcat支持2级域名共享session
                                    g21121
session
                                    
    tomcat默认情况下是不支持2级域名共享session的，所有有些情况下登陆后从主域名跳转到子域名会发生链接session不相同的情况，但是只需修改几处配置就可以了。 
打开tomcat下conf下context.xml文件 
找到Context标签,修改为如下内容 
如果你的域名是www.test.com 
<Context sessionCookiePath="/path&q
    
                                
    • 
                                
  • web报表工具FineReport常用函数的用法总结（数学和三角函数）
                                    老A不折腾
Webfinereport总结
                                    
      
ABS 
ABS(number):返回指定数字的绝对值。绝对值是指没有正负符号的数值。 
Number:需要求出绝对值的任意实数。 
示例: 
ABS(-1.5)等于1.5。 
ABS(0)等于0。 
ABS(2.5)等于2.5。 
  
ACOS 
ACOS(number):返回指定数值的反余弦值。反余弦值为一个角度，返回角度以弧度形式表示。 
Number:需要返回角
    
                                
    • 
                                
  • linux 启动java进程 sh文件
                                    墙头上一根草
linuxshelljar
                                    
    #!/bin/bash
#初始化服务器的进程PId变量
user_pid=0;
robot_pid=0;
loadlort_pid=0;
gateway_pid=0;

#########
#检查相关服务器是否启动成功
#说明：
#使用JDK自带的JPS命令及grep命令组合，准确查找pid
#jps 加 l 参数，表示显示java的完整包路径
#使用awk，分割出pid 
    
                                
    • 
                                
  • 我的spring学习笔记5-如何使用ApplicationContext替换BeanFactory
                                    aijuans
Spring 3 系列
                                    
    如何使用ApplicationContext替换BeanFactory？ 
 
package onlyfun.caterpillar.device;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import
    
                                
    • 
                                
  • Linux 内存使用方法详细解析
                                    annan211
linux内存Linux内存解析
                                    
    来源 http://blog.jobbole.com/45748/ 
 
 

我是一名程序员，那么我在这里以一个程序员的角度来讲解Linux内存的使用。

一提到内存管理，我们头脑中闪出的两个概念，就是虚拟内存，与物理内存。这两个概念主要来自于linux内核的支持。

Linux在内存管理上份为两级，一级是线性区，类似于00c73000-00c88000，对应于虚拟内存，它实际上不占用
    
                                
    • 
                                
  • 数据库的单表查询常用命令及使用方法(-)
                                    百合不是茶
oracle函数单表查询
                                    
      
  
创建数据库; 
      
--建表
create table bloguser(username varchar2(20),userage number(10),usersex char(2));

 
      创建bloguser表,里面有三个字段 
  
  
&nbs
    
                                
    • 
                                
  • 多线程基础知识
                                    bijian1013
java多线程threadjava多线程
                                    
    一．进程和线程 
进程就是一个在内存中独立运行的程序，有自己的地址空间。如正在运行的写字板程序就是一个进程。 
“多任务”：指操作系统能同时运行多个进程（程序）。如WINDOWS系统可以同时运行写字板程序、画图程序、WORD、Eclipse等。 
线程：是进程内部单一的一个顺序控制流。 
线程和进程 
a.       每个进程都有独立的
    
                                
    • 
                                
  • fastjson简单使用实例
                                    bijian1013
fastjson
                                    
    一.简介 
        阿里巴巴fastjson是一个Java语言编写的高性能功能完善的JSON库。它采用一种“假定有序快速匹配”的算法，把JSON Parse的性能提升到极致，是目前Java语言中最快的JSON库；包括“序列化”和“反序列化”两部分，它具备如下特征：     
    
                                
    • 
                                
  • 【RPC框架Burlap】Spring集成Burlap
                                    bit1129
spring
                                    
    Burlap和Hessian同属于codehaus的RPC调用框架，但是Burlap已经几年不更新，所以Spring在4.0里已经将Burlap的支持置为Deprecated,所以在选择RPC框架时，不应该考虑Burlap了。 
这篇文章还是记录下Burlap的用法吧，主要是复制粘贴了Hessian与Spring集成一文，【RPC框架Hessian四】Hessian与Spring集成 
 
    
                                
    • 
                                
  • 【Mahout一】基于Mahout 命令参数含义
                                    bit1129
Mahout
                                    
    1. mahout seqdirectory 
  
    $ mahout seqdirectory 
        --input (-i) input               Path to job input directory(原始文本文件).
        --output (-o) output             The directory pathna
    
                                
    • 
                                
  • linux使用flock文件锁解决脚本重复执行问题
                                    ronin47
linux lock　重复执行
                                    
    linux的crontab命令，可以定时执行操作，最小周期是每分钟执行一次。关于crontab实现每秒执行可参考我之前的文章《linux crontab 实现每秒执行》现在有个问题，如果设定了任务每分钟执行一次，但有可能一分钟内任务并没有执行完成，这时系统会再执行任务。导致两个相同的任务在执行。 
例如：       
<?         
// 
test
.php      
    
                                
    • 
                                
  • java-74-数组中有一个数字出现的次数超过了数组长度的一半，找出这个数字
                                    bylijinnan
java
                                    
    

public class OcuppyMoreThanHalf {

	/**
	 * Q74 数组中有一个数字出现的次数超过了数组长度的一半，找出这个数字
	 * two solutions:
	 * 1.O(n)
	 * see <beauty of coding>--每次删除两个不同的数字，不改变数组的特性
	 * 2.O(nlogn)
	 * 排序。中间
    
                                
    • 
                                
  • linux 系统相关命令
                                    candiio
linux
                                    
    系统参数 
cat /proc/cpuinfo  cpu相关参数 
cat /proc/meminfo 内存相关参数 
cat /proc/loadavg 负载情况 
性能参数 
1）top 
M：按内存使用排序 
P：按CPU占用排序 
1：显示各CPU的使用情况 
k：kill进程 
o：更多排序规则 
回车：刷新数据 
2）ulimit 
ulimit -a：显示本用户的系统限制参
    
                                
    • 
                                
  • [经营与资产]保持独立性和稳定性对于软件开发的重要意义
                                    comsci
软件开发
                                    
     
 
     一个软件的架构从诞生到成熟，中间要经过很多次的修正和改造 
 
      如果在这个过程中，外界的其它行业的资本不断的介入这种软件架构的升级过程中 
    
      那么软件开发者原有的设计思想和开发路线
    
                                
    • 
                                
  • 在CentOS5.5上编译OpenJDK6
                                    Cwind
linuxOpenJDK
                                    
    几番周折终于在自己的CentOS5.5上编译成功了OpenJDK6，将编译过程和遇到的问题作一简要记录，备查。  
0. OpenJDK介绍 
OpenJDK是Sun（现Oracle）公司发布的基于GPL许可的Java平台的实现。其优点： 
1、它的核心代码与同时期Sun（-> Oracle）的产品版基本上是一样的，血统纯正，不用担心性能问题，也基本上没什么兼容性问题；（代码上最主要的差异是
    
                                
    • 
                                
  • java乱码问题
                                    dashuaifu
java乱码问题js中文乱码
                                    
    swfupload上传文件参数值为中文传递到后台接收中文乱码               在js中用setPostParams（{"tag" : encodeURI( document.getElementByIdx_x("filetag").value，"utf-8")}）; 
然后在servlet中String t
    
                                
    • 
                                
  • cygwin很多命令显示command not found的解决办法
                                    dcj3sjt126com
cygwin
                                    
    cygwin很多命令显示command not found的解决办法 
  
修改cygwin.BAT文件如下 
@echo off 
D: 
set CYGWIN=tty notitle glob 
set PATH=%PATH%;d:\cygwin\bin;d:\cygwin\sbin;d:\cygwin\usr\bin;d:\cygwin\usr\sbin;d:\cygwin\us
    
                                
    • 
                                
  • [介绍]从 Yii 1.1 升级
                                    dcj3sjt126com
PHPyii2
                                    
    2.0 版框架是完全重写的，在 1.1 和 2.0 两个版本之间存在相当多差异。因此从 1.1 版升级并不像小版本间的跨越那么简单，通过本指南你将会了解两个版本间主要的不同之处。 
如果你之前没有用过 Yii 1.1，可以跳过本章，直接从"入门篇"开始读起。 
请注意，Yii 2.0 引入了很多本章并没有涉及到的新功能。强烈建议你通读整部权威指南来了解所有新特性。这样有可能会发
    
                                
    • 
                                
  • Linux SSH免登录配置总结
                                    eksliang
ssh-keygenLinux SSH免登录认证Linux SSH互信
                                    
    转载请出自出处：http://eksliang.iteye.com/blog/2187265 一、原理 
     我们使用ssh-keygen在ServerA上生成私钥跟公钥，将生成的公钥拷贝到远程机器ServerB上后,就可以使用ssh命令无需密码登录到另外一台机器ServerB上。 
     生成公钥与私钥有两种加密方式，第一种是
    
                                
    • 
                                
  • 手势滑动销毁Activity
                                    gundumw100
android
                                    
    老是效仿ios，做android的真悲催！ 
有需求：需要手势滑动销毁一个Activity 
怎么办尼？自己写？ 
不用~，网上先问一下百度。 
结果： 
http://blog.csdn.net/xiaanming/article/details/20934541 
 
 
首先将你需要的Activity继承SwipeBackActivity，它会在你的布局根目录新增一层SwipeBackLay
    
                                
    • 
                                
  • JavaScript变换表格边框颜色
                                    ini
JavaScripthtmlWebhtml5css
                                    
    效果查看：http://hovertree.com/texiao/js/2.htm代码如下，保存到HTML文件也可以查看效果： 
<html>
<head>
<meta charset="utf-8">
<title>表格边框变换颜色代码-何问起</title>
</head>
<body&
    
                                
    • 
                                
  • Kafka Rest : Confluent
                                    kane_xie
kafkaRESTconfluent
                                    
    最近拿到一个kafka rest的需求，但kafka暂时还没有提供rest api（应该是有在开发中，毕竟rest这么火），上网搜了一下，找到一个Confluent Platform，本文简单介绍一下安装。 
这里插一句，给大家推荐一个九尾搜索，原名叫谷粉SOSO，不想fanqiang谷歌的可以用这个。以前在外企用谷歌用习惯了，出来之后用度娘搜技术问题，那匹配度简直感人。 
 
 环境声明：Ubu
    
                                
    • 
                                
  • Calender不是单例
                                    men4661273
单例Calender
                                    
             在我们使用Calender的时候，使用过Calendar.getInstance()来获取一个日期类的对象，这种方式跟单例的获取方式一样，那么它到底是不是单例呢，如果是单例的话，一个对象修改内容之后，另外一个线程中的数据不久乱套了吗？从试验以及源码中可以得出，Calendar不是单例。 
测试： 
  Calendar c1 = 
    
                                
    • 
                                
  • 线程内存和主内存之间联系
                                    qifeifei
java thread
                                    
    1， java多线程共享主内存中变量的时候，一共会经过几个阶段，    
  lock:将主内存中的变量锁定，为一个线程所独占。 
  unclock:将lock加的锁定解除，此时其它的线程可以有机会访问此变量。 
  read:将主内存中的变量值读到工作内存当中。 
  load:将read读取的值保存到工作内存中的变量副本中。 
  
    
                                
    • 
                                
  • schedule和scheduleAtFixedRate
                                    tangqi609567707
javatimerschedule
                                    
    原文地址：http://blog.csdn.net/weidan1121/article/details/527307 
import java.util.Timer;import java.util.TimerTask;import java.util.Date; 
/** * @author vincent */public class TimerTest { 
 
    
                                
    • 
                                
  • erlang 部署
                                    wudixiaotie
erlang
                                    
    1.如果在启动节点的时候报这个错 ： 
{"init terminating in do_boot",{'cannot load',elf_format,get_files}} 
则需要在reltool.config中加入 
{app, hipe, [{incl_cond, exclude}]}, 
  
  
2.当generate时，遇到： 
ERROR
    
                                
    •