Merge branch 'main' into add_gie_deploy

.github/workflows/release.yml

@@ -86,11 +86,10 @@ jobs:
         sudo chmod +x /usr/bin/ossutil64
 
         # download released charts
-        cd ${GITHUB_WORKSPACE}/charts
         ossutil64 -i "${oss_accesskey_id}" \
                   -k "${oss_accesskey_secret}" \
                   -e ${{ env.OSS_ENDPOINT }} \
-                  cp -r oss://graphscope/charts ./
+                  cp -r oss://graphscope/charts ./charts
 
     - name: Package Charts
       run: |

Makefile

@@ -42,13 +42,6 @@ all: learning client coordinator analytical interactive
 graphscope: all
 
 install: analytical-install interactive-install learning-install client coordinator
-    # client
-	pip3 install --user --editable $(CLIENT_DIR)
-	rm -rf $(CLIENT_DIR)/*.egg-info
-    # coordinator
-	pip3 install --user --editable $(COORDINATOR_DIR)
-	rm -rf $(COORDINATOR_DIR)/*.egg-info
-
 	echo "Run the following command to correctly set environment variable"
 	echo "export GRAPHSCOPE_HOME=$(INSTALL_PREFIX)"
 
@@ -61,6 +54,7 @@ clean:
 	rm -rf $(INTERACTIVE_DIR)/executor/ir/target
 
 	rm -rf $(LEARNING_BUILD_DIR) $(LEARNING_DIR)/proto/*.h $(LEARNING_DIR)/proto/*.cc
+	rm -rf $(LEARNING_DIR)/graphlearn/built
 
 	cd $(CLIENT_DIR) && python3 setup.py clean --all
 
@@ -74,11 +68,15 @@ client: learning
 	cd $(CLIENT_DIR) && \
 	pip3 install -r requirements.txt -r requirements-dev.txt --user && \
 	python3 setup.py build_ext --inplace --user
+	pip3 install --user --editable $(CLIENT_DIR)
+	rm -rf $(CLIENT_DIR)/*.egg-info
 
 coordinator: client
 	cd $(COORDINATOR_DIR) && \
 	pip3 install -r requirements.txt -r requirements-dev.txt --user && \
 	python3 setup.py build_builtin
+	pip3 install --user --editable $(COORDINATOR_DIR)
+	rm -rf $(COORDINATOR_DIR)/*.egg-info
 
 # We deliberately make $(ENGINE) depends on a file, and $(ENGINE)-install depends on $(ENGINE),
 # so that when we execute `make $(ENGINE)-install` after `make $(ENGINE)`, it will not

coordinator/setup.py

@@ -372,6 +372,8 @@ def parse_version(root, **kwargs):
         "Programming Language :: Python :: 3.7",
         "Programming Language :: Python :: 3.8",
         "Programming Language :: Python :: 3.9",
+        "Programming Language :: Python :: 3.10",
+        "Programming Language :: Python :: 3.11",
     ],
     keywords="GraphScope, Graph Computations",
     use_scm_version={

docs/_templates/base.html

@@ -27,6 +27,7 @@
   gtag('config', 'G-4TMYCGJ0X2');
 </script>
 
+<!-- Baidu analytics -->
 <script>
   var _hmt = _hmt || [];
   (function() {
@@ -37,4 +38,20 @@
   })();
 </script>
 
+<!-- MathJax rendering -->
+<script>
+MathJax = {
+  tex: {
+    inlineMath: [ ['$', '$'], ['\\(', '\\)'] ]
+  },
+  svg: {
+    fontCache: 'global'
+  }
+};
+</script>
+<script
+  type="text/javascript" id="MathJax-script" async
+  src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-chtml.js">
+</script>
+
 {% endblock %}

docs/analytical_engine/key_concepts.rst

@@ -1,6 +1,9 @@
 Key Concepts
 --------
 
+In this document, we introduce some important concepts in GraphScope analytical engine, which defines the
+graph loading strategies, inner/outer vertices, and message passing and synchronization strategies.
+
 LoadStrategy
 ^^^^^^^^^^^^
 
@@ -9,23 +12,23 @@ There are three ways to maintain the nodes crossing different fragments in Graph
 OnlyOut
 """""""
 
-Each fragment Fi maintains “local” nodes v and a set of “mirrors” for nodes v' in other fragments such that there exists an edge (v, v'). For instance, in addition to local nodes {4, 5, 6, 7}, F1 in graph G also stores a “mirror” node 3 and the edge (5, 3) when using OnlyOut strategy, as shown below.
+Each fragment $F_{i}$ maintains “local” nodes v and a set of “mirrors” for nodes v' in other fragments such that there exists an edge (v, v'). For instance, in addition to local nodes {4, 5, 6, 7}, $F_{1}$ in graph G also stores a “mirror” node 3 and the edge (5, 3) when using OnlyOut strategy, as shown below.
 
 .. image:: ../images/onlyout.png
   :alt: OnlyOut
 
 OnlyIn 
 """"""
 
-Under this case, each fragment Fi maintains “local” nodes v and a set of “mirrors” for nodes v' in other fragments such that there exists an edge (v', v). In graph G, F1 maintains “mirror” nodes {1, 9, 12} besides its local nodes.
+Under this case, each fragment $F_{i}$ maintains “local” nodes v and a set of “mirrors” for nodes v' in other fragments such that there exists an edge (v', v). In graph G, $F_{1}$ maintains “mirror” nodes {1, 9, 12} besides its local nodes.
 
 .. image:: ../images/onlyin.png
   :alt: OnlyIn
 
 BothInOut
 """""""""
 
-Each fragment Fi maintains “local” nodes v and a set of “mirrors” for nodes v' in other fragments such that there exists an edge (v, v') or (v', v). Hence, in graph G, “mirror” nodes {1, 3, 9, 12} are stored in F1 when BothInOut is applied.
+Each fragment $F_{i}$ maintains “local” nodes v and a set of “mirrors” for nodes v' in other fragments such that there exists an edge (v, v') or (v', v). Hence, in graph G, “mirror” nodes {1, 3, 9, 12} are stored in $F_{1}$ when BothInOut is applied.
 
 .. image:: ../images/inandout.png
   :alt: BothInOut
@@ -59,39 +62,40 @@ A node v is referred to as an
 OuterVertex
 """""""""""
 
-OuterVertex of fragment Fi if it resides at another fragment Fj and there exists a node v' in Fi such that (v, v') or (v', v) is an edge; e.g., nodes {1, 3, 9, 12} are OuterVertex of fragment F1 in graph G;
+OuterVertex of fragment $F_{i}$ if it resides at another fragment $F_{j}$ and there exists a node v' in $F_{i}$ such that (v, v') or (v', v) is an edge; e.g., nodes {1, 3, 9, 12} are OuterVertex of fragment $F_{1}$ in graph G;
 
 .. image:: ../images/outvertex.png
   :alt: OuterVertex
 
 InnerVertex
 """""""""""
 
-InnerVertex of fragment Fi if it is distributed to Fi; e.g. nodes {4, 5, 6, 7} are InnerVertex of fragment F1 in G;
+InnerVertex of fragment $F_{i}$ if it is distributed to $F_{i}$; e.g. nodes {4, 5, 6, 7} are InnerVertex of fragment $F_{1}$ in G;
 
 .. image:: ../images/invertex.png
   :alt: InnerVertex 
 
 InnerVertexWithOutgoingEdge
 """""""""""""""""""""""""""
 
-InnerVertexWithOutgoingEdge of fragment Fi if it is stored in Fi and has an adjacent edge (v, v') outcoming to a node v' in another fragment Fj; e.g., node 5 is an InnerVertexWithOutgoingEdge of F1 in G with the outgoing edge (5, 3);
+InnerVertexWithOutgoingEdge of fragment $F_{i}$ if it is stored in $F_{i}$ and has an adjacent edge (v, v') outcoming to a node v' in another fragment $F_{j}$; e.g., node 5 is an InnerVertexWithOutgoingEdge of $F_{1}$ in G with the outgoing edge (5, 3);
 
 .. image:: ../images/invertexout.png
   :alt: InnerVertexWithOutgoingEdge
 
 InnerVertexWithIncomingEdge
 """""""""""""""""""""""""""
 
-InnerVertexWithIncomingEdge of fragment Fi if it is maintained in Fi has an adjacent edge (v', v) incoming from a node v' in another fragment Fj; e.g., nodes {4, 5, 7} are InnerVertexWithIncomingEdge of F1 in G, and (1, 4), (9, 5), and (12, 7) are corresponding incoming edges.
+InnerVertexWithIncomingEdge of fragment $F_{i}$ if it is maintained in $F_{i}$ has an adjacent edge (v', v) incoming from a node v' in another fragment $F_{j}$; e.g., nodes {4, 5, 7} are InnerVertexWithIncomingEdge of $F_{1}$ in G, and (1, 4), (9, 5), and (12, 7) are corresponding incoming edges.
 
 .. image:: ../images/invertexin.png
   :alt: InnerVertexWithIncomingEdge
 
-MessageStrategy
+MessageManager and MessageStrategy
 ^^^^^^^^^^^^^^^
+In each graph application in GAE, a MessageManager is created to manage the messages passed between different fragments. Considering the diversity of graph applications, we provide many message passing strategies, which are defined in MessageStrategy.  
 
-Below are some message passing and synchronization strategies adopted by GraphScope analytical engine.  
+Below are message passing and synchronization strategies supported by GAE.  
 
 AlongOutgoingEdgeToOuterVertex
 """"""""""""""""""""""""""""""
@@ -120,23 +124,23 @@ Each message is passed along crossing edges from nodes that are both  InnerVerte
 SyncOnOuterVertexAsTarget
 """""""""""""""""""""""""
 
-It is applied in company with the OnlyOut loading strategy. Here each fragment Fi sends the states of its “mirror” node of OuterVertex v to Fj that v resides, if there exists edge (v', v) and v' is “local” node of Fi, for synchronizing different states of v. For instance, the state of “mirror” node 3 is sent from F1 to F0 for synchronization at F0. 
+It is applied in company with the OnlyOut loading strategy. Here each fragment $F_{i}$ sends the states of its “mirror” node of OuterVertex v to $F_{j}$ that v resides, if there exists edge (v', v) and v' is “local” node of $F_{i}$, for synchronizing different states of v. For instance, the state of “mirror” node 3 is sent from $F_{1}$ to $F_{0}$ for synchronization at $F_{0}$. 
 
 .. image:: ../images/sync1.png
   :alt: SyncOnOuterVertexAsTarget
 
 SyncOnOuterVertexAsSource
 """""""""""""""""""""""""
 
-It is applied together with the OnlyIn loading strategy. Similar to **SyncStateOnOuterVertexAsTarget**, each fragment Fi sends the states of its “mirror” nodes v to the corresponding fragments for synchronization. The difference is that for each such “mirror”, there exists outgoing edge (v, v') to certain “local” node v' of Fi. For example, the states of “mirror” nodes 1, 9, and 12 are sent from F1 to F0 and F2 for synchronization with other states.
+It is applied together with the OnlyIn loading strategy. Similar to **SyncStateOnOuterVertexAsTarget**, each fragment $F_{i}$ sends the states of its “mirror” nodes v to the corresponding fragments for synchronization. The difference is that for each such “mirror”, there exists outgoing edge (v, v') to certain “local” node v' of $F_{i}$. For example, the states of “mirror” nodes 1, 9, and 12 are sent from $F_{1}$ to $F_{0}$ and $F_{2}$ for synchronization with other states.
 
 .. image:: ../images/sync2.png
   :alt: SyncOnOuterVertexAsSource
 
 SyncOnOuterVertex
 """""""""""""""""
 
-This is applied together with the BothInOut loading strategy. Under this case, each fragment Fi sends the states of all its “mirror” nodes v to the corresponding fragments for synchronization, regardless of the directions of edges adjacent to v, e.g., the states of “mirror” nodes 1, 3, 9 and 12 are sent from F1 to F0 and F2 for further synchronization. 
+This is applied together with the BothInOut loading strategy. Under this case, each fragment $F_{i}$ sends the states of all its “mirror” nodes v to the corresponding fragments for synchronization, regardless of the directions of edges adjacent to v, e.g., the states of “mirror” nodes 1, 3, 9 and 12 are sent from $F_{1}$ to $F_{0}$ and $F_{2}$ for further synchronization. 
 
 .. image:: ../images/sync3.png
   :alt: SyncOnOuterVertex

docs/analytical_engine/networkx_compatibility.md

@@ -1,8 +1,8 @@
 # NetworkX Compatibility
 
-NetworkX is ....
+NetworkX is a Python package for manipulating and processing graph data on a single machine. It provides user-friendly interfaces for working with graph data and developing graph-based applications. Currently, it is widely used by graph application developers and researchers, particularly in the field of data science. However, it does not have the capability to handle large-scale graphs on a distributed environment.
 
-For ease of use, GraphScope provides NetworkX-compatible interface, which allows the users who are used NetworkX for their graph analysis over small graphs, to use GraphScope over large graphs with minimal changes.
+To solve this problem, GraphScope provides a NetworkX-compatible interface, which allows users who have used NetworkX for their graph analysis on small graphs to use GraphScope for large graphs with minimal changes.
 
 ## Convert a `Graph` to a `nx.Graph`