Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

SkyWalking BanyanDB Extend remote.FS with Object Storage Support for AWS, Google Cloud, and Azure

Overview:
The current implementation of the remote.FS interface only supports a local file system (via the implementation in local.go). This GSOC2025 project proposes to extend remote.FS with popular object storage services—namely AWS S3, Google Cloud Storage, and Azure Blob Storage. This enhancement will allow the project to support robust cloud-based backup and restore operations in addition to local storage.

Proposed Features:

  1. AWS S3 Implementation:
    • Implement methods for Upload, Download, List, and Delete operations using the AWS S3 API.
  2. Google Cloud Storage Implementation:
    • Provide a module that integrates with Google Cloud Storage to perform similar operations.
  3. Azure Blob Storage Implementation:
    • Develop functionality to access and manage Azure Blob Storage via the remote.FS interface.

Implementation Details:

  • Interface Compliance:
    Each object storage implementation must adhere to the remote.FS interface defined in remote.go.
  • Error Handling & Resilience:
    Implement robust error handling, logging, and retry mechanisms to ensure reliable operations across different cloud services.
  • Testing:
    Develop comprehensive unit and integration tests to cover edge cases and guarantee compatibility and stability.
  • Documentation:
    Update the project documentation to detail configuration, deployment, and usage of each cloud storage option.


Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Hongtao Gao, mail: hanahmily (at) apache.org
Project Devs, mail: dev (at) skywalking.apache.org

...

HugeGraph

[GSoC][HugeGraph] Implement Agentic GraphRAG Architecture

Apache HugeGraph(incubating) is a fast-speed and highly-scalable graph database/computing/AI ecosystem. Billions of vertices and edges can be easily stored into and queried from HugeGraph due to its excellent OLTP/OLAP ability.
 
Website: https://hugegraph.apache.org/
GitHub:

Currently, we have implemented a basic GraphRAG that relies on fixed processing workflows (e.g., knowledge retrieval & graph structure updates using the same execution pipeline), leading to insufficient flexibility and high overhead in complex scenarios. The proposed task introduces an Agentic architecture based on the principles of "dynamic awareness, lightweight scheduling, concurrent execution," focusing on solving the following issues:

  1. Rigid Intent Recognition: Existing systems cannot effectively distinguish between simple retrievals (e.g., entity queries) and complex operations (e.g., multi-hop reasoning), often defaulting to BFS-based template subgraph searches.
  2. Coupled Execution Resources: Memory/computational resources are not isolated based on task characteristics, causing long-tail tasks to block high-priority requests.
  3. Lack of Feedback Mechanisms: Absence of self-correction capabilities for erroneous operations (e.g., automatically switching to similar vertices/entities after path retrieval failures).

The task will include three core parts:

1. Dynamic Awareness Layer

  • Implement an LLM-based real-time (as of February 14, 2025) intent classifier that categorizes tasks (L1 simple retrieval/L2 path reasoning/L3 graph computation/L4+ etc.) based on semantic features (verb types/entity complexity/temporal modifiers).
  • Build a lightweight operation cache to generate feature hashes for high-frequency requests, enabling millisecond-level intent matching.

2. Task Orchestration Layer

  • Introduce a suitable workflow/taskflow framework emphasizing low coupling, high performance, and flexibility.
  • Adopt a preemptive scheduling mechanism allowing high-priority tasks to pause non-critical phases of low-priority tasks (e.g., suspending subgraph preloading without interrupting core computations).

3. Concurrent Execution

  • Decouple traditional RAG pipelines into composable operations (entity recall → path validation → context enhancement → result refinement), with dynamic enable/disable support for each component.
  • Implement automatic execution engine degradation, triggering fallback strategies upon sub-operation failures (e.g., switching to alternative methods if Gremlin queries timeout).

Recommended Skills

  1. Proficiency in Python and familiarity with at least one open/closed-source LLM.
  2. Experience with one LLM RAG/Agent framework like LangGraph/RAGflow/LLamaindex/Dify.
  3. Knowledge of LLM optimization techniques and RAG construction (KG extraction/construction experience is a plus).
  4. Strong algorithmic engineering skills (problem abstraction, algorithm research, big data processing, model tuning).
  5. Familiarity with VectorDB/Graph/KG/HugeGraph read-write workflows and principles.
  6. Understanding of graph algorithms (e.g., community detection, centrality, PageRank) and open-source community experience preferred.

Task List

  • Develop a hierarchical triggering mechanism for the intent classifier to categorize L1~LN tasks within milliseconds (accuracy >90%).
  • Semi-automatically generate Graph Schema/extraction prompts.
  • Support dynamic routing and query decomposition.
  • Design an execution trace tracker to log micro-operation resource consumption and generate optimization reports.
  • Enhance retrieval with graph algorithms: Apply node importance evaluation, path search, etc., to optimize knowledge recall.
  • Implement a dialogue memory management module for context-aware state tracking and information reuse.

Size

  • Difficulty: Hard
  • Project size: ~350 hours (full-time/large)

Potential Mentors

Difficulty: Major
Project size: ~350 hour (large)
Potential mentors:
Imba Jin, mail: jin (at) apache.org
Project Devs, mail: