@clickzetta/cz-cli-darwin-arm64 0.3.95 → 0.3.100

package/bin/skills/lakehouse-doc-en/references/access-control-general.md

@@ -0,0 +1,81 @@
+# Access Control Overview
+
+This document introduces the overall framework and key concepts of access control in Singdata Lakehouse. By understanding the core principles and related elements of access control, users and administrators can securely and flexibly allocate and manage permissions on the Singdata Lakehouse platform, ensuring compliant use of data and metadata objects.
+
+## 1. Access Control Model
+
+Singdata Lakehouse adopts a flexible access control mechanism, supporting two main models:
+
+* **Access Control List (ACL**): Permissions are directly assigned to users. This method is more intuitive in small or simple scenarios; however, in large orgnizations, the management difficulty increases with the number of users and permission requirements.
+
+:-: ![](.topwrite/assets/ACL.png =391)
+
+* **Role-Based Access Control (RBAC**): Permissions are first assigned to roles, and then roles are granted to users, achieving indirect management of permissions. RBAC helps simplify permission maintenance in complex environments. When business needs change, permissions can be adjusted at the role level without maintaining each user individually.
+
+:-: ![](<.topwrite/assets/Untitled Diagram.drawio.png> =591)
+
+Unlike traditional DAC (Discretionary Access Control), Singdata Lakehouse does not directly support the DAC model of secondary authorization based on object ownership. It is recommended to use RBAC for centralized, controllable unified management of permissions.
+
+In Singdata Lakehouse, RBAC and ACL authorization methods coexist. A user can be directly granted multiple permissions and multiple roles simultaneously. When the user performs any operation, their permission scope is the sum of the "directly granted permissions" and the "granted role" permissions. Users do not need to declare their current identity or role for operations; the authentication system will traverse all the permissions currently owned by the user and provide the authentication result.
+
+## 2. Objects and Their Ownership
+
+### Object
+
+Metadata objects are entities that can be granted permissions, including workspace, schema, table, view, virtual cluster, etc. These objects are created with full permissions by the creator by default but cannot be secondarily authorized. When accessing objects, if not explicitly authorized, access is denied by default.
+
+For all metadata objects in Singdata Lakehouse, see the authorization documentation.
+
+### Object Ownership
+
+The user who initially creates the object owns the object's ownership. The role owning the object can perform all operations on the object, including modification and deletion. Currently, transferring object ownership is not supported.
+
+To achieve a more flexible permission allocation mechanism and more secure access control, it is recommended to manage object access through a unified authorization method using the role permission system, with instance\_admin and workspace\_admin roles.
+
+## 3. Role Hierarchy and Types
+
+### Role
+
+Roles are carriers of permissions. After assigning permission points to a role, granting the role to a user can achieve indirect transmission of permissions. When a user has multiple roles, their permissions are the union of these role permissions.
+
+### Role Hierarchy
+
+Roles can be divided into two hierarchical scopes:
+
+* **Instance Role**: Used for global control of instance-level resources and operations.
+* **Workspace Role**: Applies to objects within a specific workspace (such as schema, table, virtual cluster, etc.). Workspace roles are bounded by the workspace and do not affect each other.
+
+:-: ![](.topwrite/assets/role-levels.drawio.png =531)
+
+This hierarchical structure helps achieve fine-grained access control at both global and local levels. When the business scale expands and permission requirements become complex, a clear role hierarchy between instance roles and workspace roles can simplify permission allocation.
+
+### Predefined Roles and Custom Roles
+
+Singdata Lakehouse provides several predefined roles (such as instance administrator, data source administrator, space administrator, etc.) to meet basic usage scenarios. Users can also create custom roles within the workspace (via SQL statements) to flexibly define and adjust permission sets that meet their business needs.
+
+For all predefined roles and their default permissions in Singdata Lakehouse, see the authorization documentation.
+
+## 4. Privilege and Authorization Management
+
+### Privilege
+
+Privileges define the smallest access units for operations on objects, including querying tables, inserting data, managing schemas, or using virtual clusters. Privilege points can finely define the read, write, modify, and delete operations that users can perform on objects.
+
+^
+
+For all metadata objects and their privilege points in Singdata Lakehouse, see the authorization documentation.
+
+### Grant & Revoke
+
+Use the `GRANT` and `REVOKE` commands to authorize or revoke permissions on metadata objects, with permission changes taking effect immediately. Corresponding visual operations can also be performed in the web interface.
+
+Example:
+
+`GRANT SELECT ON TABLE my_table TO ROLE analyst_role;`
+
+`REVOKE INSERT ON TABLE my_table FROM ROLE analyst_role;`
+Business objects (such as scripts, tasks, and data quality rules) do not currently support SQL fine-grained authorization. Their access permissions are granted through corresponding predefined roles.
+
+## No Super-User Concept
+
+There are no super-users or super-roles in Singdata Lakehouse that can bypass permission checks. All access operations must be explicitly authorized to ensure data access security and compliance.

package/bin/skills/lakehouse-doc-en/references/access-control.md

@@ -0,0 +1,235 @@
+# Authorization
+
+## 1. Access Control Model
+
+All metadata objects in Singdata Lakehouse are authorized for access based on an access control system. The access control models supported by Singdata Lakehouse include **Access Control List** (ACL) and **Role-Based Access Control** (RBAC).
+
+* **Access Control List** (**ACL, Access Control List**)
+
+Permissions are directly granted to users.
+
+* **Role-Based Access Control** (RBAC, Role-Based Access Control)
+
+Permissions are granted to roles, and users gain corresponding permissions by being granted roles.
+
+* **DAC (Discretionary Access Control) Mode Compatibility**
+
+Singdata Lakehouse does not directly support DAC mode. DAC mode means that the owner of a metadata object (table, view, virtual cluster, etc.) has all permissions for that object by default and can grant permissions to other entities. In Singdata Lakehouse, after a metadata object is created, its creator has all permissions for that object by default but cannot re-authorize.
+
+^
+
+The main concepts in the Singdata Lakehouse access control system include:
+
+* **Metadata Object (Object)**
+
+A metadata object is an entity that can be granted access permissions. A metadata object contains multiple permission points, and related operations will be denied unless explicitly granted permission.
+
+* **Role (Role)**
+
+A role is an entity that can be granted permissions. Roles can be assigned to users but cannot be assigned to other roles.
+
+* **Privilege (Privilege)**
+
+A privilege is the smallest level of definition for accessing a metadata object. Multiple different permission points can be used to control the scope of granted operations.
+
+* **User (User)**
+
+A user is an identity recognized by Singdata Lakehouse, which can be a user identity or a service identity.
+
+## 2. Roles
+
+### 2.1 Role Types
+
+There are two types of roles in Singdata Lakehouse: **predefined roles** and **custom roles**.
+
+To facilitate users in quickly completing basic authorization and using product features, Singdata Lakehouse has predefined multiple roles. Predefined roles are automatically created with the service instance, cannot be modified or deleted, but can be granted to users.
+
+Users can create custom roles as needed and authorize these roles. Custom roles can be modified or deleted at any time. Currently, custom roles can only be created within a workspace and do not support instance-level custom roles.
+
+### 2.2 Role Levels
+
+Metadata objects in Singdata Lakehouse are divided into two levels: "Instance" and "Workspace". Correspondingly, roles are also divided into "Instance Roles" and "Workspace Roles". There is no subordinate relationship between the two levels of objects. Instance-level roles do not have and cannot be granted any permissions for workspace-level metadata objects (workspace users, workspace roles, schema, table, compute cluster, etc.).
+
+Workspace roles are isolated by workspace boundaries. Roles with the same name are allowed in different workspaces. Permissions cannot be granted across workspaces to roles in another workspace.
+
+### 2.3 Predefined System Roles
+
+The predefined roles and permissions in the current system are shown in the table below:
+
+|          |          |                    |                                                                                          |                                                        |                                 |
+| -------- | -------- | ------------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------- |
+| **Role Level** | **Role Name** | **Role Code**           | **Permissions**                                                                                 | **Role Description**                                               | **Default Granted**                        |
+| Instance Role     | Instance Administrator    | instance\_admin    | Workspace - Create Workspace - View Instance Role - Grant/Revoke                                                              | Manage the creation and deletion of all workspaces within the instance, and manage the granting and revoking of instance-level roles within the instance. The instance administrator does not have any permissions within any workspace. | The user who creates the service instance. Multiple users can be granted this role, at least one user must be granted this role.     |
+|          | Instance User     | instance\_user     | Data Source - View Operations Center - View                                                                          | All users within the service instance are granted this role by default and it cannot be revoked.                                  | All users are granted this role by default and it cannot be revoked.                 |
+|          | Datasource Administrator   | datasource\_admin  | Data Source - Manage                                                                                  | Has management permissions for data sources, can add, delete, and modify all data source objects.                                |                                 |
+|          | Data Catalog Administrator  | datacatalog\_admin | Business Category - Manage Metadata Objects - View                                                                        | Has management permissions for functions and objects within the data catalog.                                     |                                 |
+|          | Data Catalog User   | datacatalog\_user  | Business Category - View Metadata Objects - View                                                                        | Has read-only permissions for the data catalog.                                           |                                 |
+|          | Instance SRE Administrator | instance\_sre      | Operations Center - View Tasks - Manage Task Instances - Manage Jobs - Manage                                                             | Has operational permissions for submitting, modifying, taking offline, and rerunning all task instances within the service instance.                      |                                 |
+| Workspace Role     | Workspace Administrator    | workspace\_admin   | Workspace Members - Manage Workspace Roles - Manage Environment - Manage Task Directory - Manage Task Scripts - Manage Operations Center - Manage Task Instances - Publish Metadata Permissions - ALL Data Permissions - ALL Compute Resource Permissions - ALL | Has all permissions for all objects within the workspace and can reauthorize. Can manage members and roles within the workspace.                    | By default, granted to the user who creates the workspace. Multiple users can be granted this role, at least one user must be granted this role. |
+|          | Workspace Member     | workspace\_user    | Workspace Members - View Workspace Roles - View Environment - View Task Directory - View Task Scripts - View Operations Center - View Task Instances - View Metadata - Read-Only                           | Has read-only permissions for tasks, environment, and all data objects within the workspace, and has read-only permissions for roles and members within the workspace.               | Not granted by default, needs to be actively granted.                   |
+|          | Development | workspace\_dev     | Space Member——View Space Role——View Task Directory——Manage Task Scripts——Develop Jobs——Manage Metadata——ALL Data——ALL Task Development Scripts——Publish Compute Cluster——Use         | Has management permissions for task directories within the space, editing permissions for task scripts, and read and write permissions for all data objects within the space.              |                                 |
+
+### 2.4 User-Defined Roles
+
+Currently, it is only supported to create custom roles within the workspace using SQL syntax. The syntax for creating custom roles is:
+```Plain
+CREATE ROLE <role_name>;
+```
+Only users who are granted the workspace administrator role (workspace\_admin) can create custom roles within the workspace and manage and delete permissions for custom roles at any time.
+
+## 3. Privileges
+
+### 3.1 Privilege Definition
+
+The granting of access control privileges determines the specific operations a user can perform on a particular object. For each metadata object in Singdata Lakehouse, there is a set of privileges that can be granted. For detailed information on all metadata objects and their privileges in Singdata Lakehouse, refer to the Privileges document.
+
+Metadata objects can be expressed in three ways:
+
+1) By object type and object name, representing an already created object. For example: table mytable (a table named mytable) or vcluster myvcluster (a compute cluster named myvcluster);
+
+2) By the keyword ALL plus the object category, representing all existing and future objects of that type. For example: ALL tables in schema my\_schema (all table-type objects in the schema named my\_schema);
+
+3) By the keyword ALL plus the keyword OBJECTS, representing all existing and future objects of all types. For example: ALL OBJECTS in workspace my\_workspace (all objects in the workspace named my\_workspace).
+
+Privileges can be expressed in two ways:
+
+1) By specific privilege points, for example: select, read metadata, update, etc.;
+
+2) By the keyword ALL plus the keyword PRIVILEGES, representing all privilege points. For example: ALL PRIVILEGES on table mytable (all privilege points on the table mytable).
+
+When managing privileges using SQL statements, use the GRANT <privilege> and REVOKE <privilege> commands. Adding with grant option at the end of the GRANT <privilege> statement indicates that the grantee is allowed to grant that privilege to other roles or users.
+
+### 3.2 Metadata Objects
+
+The metadata objects in Lakehouse and their parent objects are shown in the table below:
+
+|                   |           |
+| ----------------- | --------- |
+| **Metadata Object** | **Parent Object** |
+| workspace         | instance  |
+| share             | instance  |
+| network policy    | instance  |
+| schema            | workspace |
+| virtual cluster   | workspace |
+| connection        | workspace |
+| table             | schema    |
+| view              | schema    |
+| materialized view | schema    |
+| dynamic table     | schema    |
+| table stream      | schema    |
+| volume            | schema    |
+| index             | schema    |
+| function          | schema    |
+| job               | schema    |
+
+Metadata objects can be authorized through SQL.
+
+### 3.3 Business Objects
+
+In addition to metadata objects, business objects are generated during data development and data governance processes, as shown in the table below:
+
+|                    |                       |
+| ------------------ | --------------------- |
+| **Business Object** | **Business Category** |
+| Script             | Data Development      |
+| Task and Instance  | Monitoring Rules      |
+|                    | Notification Policy   |
+| Data Quality       | Quality Rules         |
+
+Business objects cannot be authorized through SQL. Users obtain related permissions by being granted preset roles that include business object permissions. Fine-grained authorization is not supported at this time.
+
+### 3.4 ALL Objects
+
+ALL objects are a special type of object that represents **current** and **future** individuals of a category. For example: all tables represent all current and future tables; all vclusters represent all current and future compute clusters.
+By using the `ALL` keyword, you can grant permissions to a collection of objects (such as all tables under a certain schema) at once, thereby reducing the tedious repetitive authorization operations. At the same time, the ALL keyword provides a "Future Grants" mechanism. For example: `all tables in schema s1` means all table-type objects currently and potentially added in the future within schema s1.
+
+When using ALL objects, it needs to be used together with the keyword "in" to clarify the scope described by the ALL object. The keyword "in" is followed by the parent object of the ALL object. For example: all tables in schema my\_schema; all vclusters in workspace my\_workspace.
+
+A special usage of ALL objects is to refer to all sub-objects under a certain parent object. For example: all objects in schema my\_schema, which means all types of objects under my\_schema, including tables, views, functions, etc.
+
+Note: Although ALL objects can improve the efficiency of authorization operations, please use the all objects method for authorization with caution. Only use all objects to refer to when you are sure that the scope referred to by all objects meets the authorization expectations, to avoid the authorization scope exceeding expectations.
+
+^
+^
+
+### 3.5 Permission Points
+
+All operation types of metadata objects are as follows:
+
+|                  |          |                                                  |
+| ---------------- | -------- | ------------------------------------------------ |
+| **Operation**    | **Type** | **Description**                                  |
+| Alter            | DDL      | Modify object attributes                         |
+| Create           | DDL      | Create object                                    |
+| Desc             | DDL      | Display all attributes of a single object        |
+| Drop             | DDL      | Delete an object                                 |
+| Set              | DDL      | Set parameters                                   |
+| Unset            | DDL      | Clear the setting of a parameter                 |
+| Show             | DDL      | Display the list of the object                   |
+| Truncate         | DDL      | Delete data in the table                         |
+| Undrop           | DDL      | Restore a deleted object                         |
+| Use              | DDL      | Use the object in a session context, such as use database, use vcluster |
+| Cancel           | DDL      | Cancel the object (applied to job objects)       |
+| Select           | DML      | Table data operation, query records              |
+| Delete           | DML      | Table data operation, delete records             |
+| Insert           | DML      | Table data operation, insert records             |
+| Insert Overwrite | DML      | Table data operation, insert and overwrite records                                    |
+| Merge            | DML      | Table data operation, merge records                                       |
+| Update           | DML      | Table data operation, update records                                       |
+| Replace          | DML      | Table data operation, replace records                                       |
+| Copy Into        | DML      | Load data from file into table                                     |
+| Get              | DML      | File operation, download file                                        |
+| List             | DML      | File operation, get file list                                      |
+| Put              | DML      | File operation, upload file                                        |
+| Remove           | DML      | File operation, delete file                                        |
+| Grant            | DCL      | Grant permissions                                             |
+| Revoke           | DCL      | Revoke permissions                                             |
+
+All operation types for business objects are as follows:
+
+| **Object**                | **Included Operations**                                                                                  |
+| --------------------- | ----------------------------------------------------------------------------------------- |
+| Script                | View&#xA;Modify code&#xA;Schedule configuration [“Development” feature page]&#xA;Format&#xA;Save&#xA;Publish&#xA;Run&#xA;Rollback (version)                  |
+| Task and Instance     | View&#xA;Schedule configuration [“Development” feature page]&#xA;Pause&#xA;Supplement data&#xA;Start&#xA;Offline&#xA;Rerun&#xA;Set success/Set failure&#xA;Recover             |
+| Monitor Rules         | Create monitor rule&#xA;View monitor rule&#xA;View alert events&#xA;Subscribe/Unsubscribe&#xA;Edit rule&#xA;Enable rule&#xA;Disable rule&#xA;Suppress alert events&#xA;Close alert events |
+| Announce Policy       | View notification history&#xA;View notification policy&#xA;Create notification policy&#xA;Edit notification policy&#xA;Delete notification policy&#xA;Copy notification policy&#xA;Create notification configuration&#xA;Modify notification configuration       |
+| DQC Rule              | Create rule&#xA;View rule&#xA;View validation object&#xA;View validation results&#xA;Edit rule&#xA;Delete rule&#xA;Test run rule&#xA;Set validation result success/Set failure&#xA;Revalidate   |
+
+Each operation corresponds to a unique permission point. When granted a certain permission point for an object, the corresponding operation can be performed on that object.
+
+### 3.6 ALL Permission Points
+
+ALL permission points are a permission point that exists on all types of metadata objects, representing all permission points for that object. The ALL permission point is an **independent** permission point and does not imply other permission points. Therefore, granting the ALL permission point does not cover other permission points, and revoking the ALL permission point does not revoke other permission points.
+For example: The user my\_user is granted the select and ALL privilege points on example\_table successively. At this time, since the my\_user user is granted the ALL privilege point, they can perform all operations on example\_table; when querying the my\_user user's privileges on example\_table, it shows that they have both select and all privilege points. When the ALL privilege point is revoked from the my\_user user, the my\_user user still retains the select privilege on example\_table.
+
+Using the ALL privilege point can quickly grant all privileges on an object, for example:
+```SQL
+Grant all privileges on table example_table to user my_user;
+```
+## 4. Grants
+
+### 4.1 Grant Definition
+
+The basic model of grants is to grant "**privilege points**" of an "**object**" to an "**identity**". The object can be a metadata object or a business object, the privilege point is one or more privilege points contained in this object, and the identity currently refers to two types: "user" and "role".
+
+### 4.2 Grant Relationship Management
+
+A user can obtain the privileges of an object in two ways: 1) directly granted the privileges of the object; 2) granted through a role that has the privileges of the object.
+
+When a user is granted multiple roles at the same time, the user's privilege scope is the union of the privilege scopes of multiple roles.
+
+Roles are not allowed to be granted to roles.
+
+### 4.3 View Grants
+
+Grants can be viewed from two perspectives: the granted identity and the granted object.
+
+From the perspective of the granted identity, for example: show grants to user my\_user; will display all roles granted to the user, as well as privileges **directly** granted.
+
+From the perspective of the granted object, for example: show grants on table my\_table; will display all privileges granted on the object, including those granted to users and roles.
+
+### 4.4 Grant Operations
+
+Grant operations for metadata objects can be performed using SQL operations, see the relevant introduction of the GRANT and REVOKE statements. They can also be performed on the web interface in the "Management" - "Security" - "Privileges" page.
+
+Currently, granting business objects is only supported by granting predefined roles, and individual business object grants are not supported.

package/bin/skills/lakehouse-doc-en/references/account-funds.md

@@ -0,0 +1,87 @@
+# Account Funds
+
+## Introduction
+
+Account funds are the account used by tenants on the Singdata platform to settle fees incurred after using product services. All Regions use this account for settlement. At the same time, you can also view the income and expense details of funds through this feature.
+
+## Feature Permissions
+
+For tenants with multiple users, the account funds feature is only accessible to users with the "Account Administrator" permission.
+
+## Categories
+
+Account funds are currently divided into two categories: cash account and voucher account.
+
+* Cash account: Funds can be pre-charged through corporate bank transfer, WeChat Pay, or Alipay online top-up.
+* Voucher account: Vouchers issued by Singdata to tenants.
+
+## Navigation Path
+
+Log in to Lakehouse Studio -> Cost Center -> Account Funds, as shown below:
+![](.topwrite/assets/image_1748336067204.png)
+* Cash balance: The tenant's current available balance. Amounts topped up through corporate bank transfer, WeChat Pay, Alipay, etc., will be deducted in real time based on consumption.
+* Unsettled amount: The tenant's current unsettled amount. When the cash balance is 0 and there are no available vouchers, continuing to use services will incur unsettled amounts. When unsettled amounts exist, prompt top-up is required to avoid affecting normal service operation.
+* Vouchers: The number of vouchers currently available to the tenant.
+
+### Cash
+
+#### Top-Up and Transfer
+
+Supports WeChat Pay, Alipay online top-up, and offline corporate bank transfer. The differences between top-up methods are as follows:
+
+| Top-Up Method | Description | Time to Account |
+| :--- | :--- | :--- |
+| Alipay Top-Up | Top up through an Alipay account, using Alipay balance, savings card bound to the account, credit card, family card, etc.                                                   | Real-time    |
+| WeChat Top-Up  | Top up through a WeChat account, using WeChat balance or bound savings card. Credit card top-up is not supported.                                                         | Real-time    |
+| Corporate Bank Transfer  | Requires using a bank account whose account name matches the real-name verification entity of the Singdata tenant for the transfer. Payment can be made through online banking, mobile banking app, or bank counter to Singdata's corporate account. After the transfer, contact your business representative to top up the amount to your Singdata cash account. | 3 business days |
+
+Top-Up and Transfer Operation Guide:
+
+On the cash account page, click the "Top-Up & Transfer" button to enter the top-up and transfer page, as shown below:
+![](.topwrite/assets/image_1748336104481.png)
+If choosing online top-up, the first top-up requires agreeing to the "Singdata Technology User Agreement". Click WeChat Pay or Alipay to select the top-up method, enter the top-up amount, and click "Top Up Now" to generate a payment QR code. Use the corresponding app on your mobile device to scan the QR code and complete payment, as shown below:
+![](.topwrite/assets/image_1747637006371.png)
+If choosing corporate bank transfer, enter the transfer page to view Singdata's receiving information. Transfer the required amount to Singdata's account according to the receiving information, and contact your business representative to complete the receipt. As shown below:
+![](.topwrite/assets/image_1747637124644.png)
+After completing the top-up, return to the cash account page to view the corresponding top-up transaction details. When there is an outstanding balance, the topped-up amount will be used in real time to offset the outstanding amount upon arrival.
+
+Exception handling: If online top-up is selected but the payment is not completed within the timeout period, a top-up failure message will be displayed, as shown below. In this case, you need to refresh the page and re-initiate the top-up.
+![](.topwrite/assets/topup_failed.jpeg)
+
+**About Invoices**: If you need to issue an invoice, please contact your business representative. Invoices will be issued based on your consumption records on the Singdata platform, not based on the actual top-up amount. Please be aware.
+
+**About Refunds**: Online refund requests are not currently supported. If you need to initiate a refund due to account cancellation or other circumstances, please contact your business representative to complete the refund offline. Refunds can only be returned to the original payment account.
+
+#### Transaction Details
+
+Transaction details show the income and expense records of the cash account, allowing you to view the account balance change history, as shown below:
+![](.topwrite/assets/image_1747637294249.png)
+* Transaction ID: Unique credential for platform transactions
+* Transaction Time: Time when the transaction occurred
+* Type: Includes three types: consumption, top-up, and refund
+* Account: Currently only the cash account
+* Transaction Amount: The amount generated at the time of the transaction
+* Available Balance: The remaining available cash amount after the transaction
+* Channel: The channel through which the transaction occurred. For top-up type transactions, records the top-up source channel, such as: corporate bank transfer, WeChat Pay, Alipay
+* Transaction Search: You can query transaction records for specific scenarios by setting conditions such as transaction time and transaction type.
+
+### Vouchers
+
+Click "Vouchers" at the top of the account funds page to enter the vouchers page. By default, it displays the tenant's currently available vouchers. You can switch to "All" or "Unavailable" to view vouchers in corresponding states, as shown below:
+![](.topwrite/assets/image_1747637516784.png)
+* Available Vouchers: Vouchers that are within their validity period and have an available balance
+* Unavailable Vouchers: Vouchers that have not yet reached their validity period, vouchers that have expired, or vouchers that are within their validity period but have exhausted their balance. Among these, vouchers that have not yet reached their validity period will automatically become available when the validity period begins; expired vouchers cannot be recovered.
+**Note**: All vouchers are issued by the Singdata platform and cannot be transferred or cashed out.
+
+#### Voucher Details
+
+Click the "View Details" button to view voucher consumption details, as shown below:
+![](.topwrite/assets/image_1747637759011.png)
+![](.topwrite/assets/image_1747637740486.png)
+* Voucher Status: Active, Not Yet Active, Expired
+* Voucher Face Value: The initial total amount of the issued voucher
+* Balance: The remaining amount of the voucher
+* Validity Period: The voucher is valid for offsetting bills within its validity period
+* Region Scope: The Region range of instances that the voucher supports for offsetting
+* Product Scope: The billing item range that the voucher supports for offsetting
+* Transaction Details: Covers voucher consumption records, displaying offset records by billing item dimension, supporting filtering by transaction time

package/bin/skills/lakehouse-doc-en/references/account.md

@@ -0,0 +1,2 @@
+## Account Management
+[Real-Name Authentication](authentication.md)

package/bin/skills/lakehouse-doc-en/references/account_user_management.md

@@ -0,0 +1,108 @@
+# Users Management Guide
+
+This document introduces how to add more users to your account and manage these users.
+
+Users with the account administrator role can manage users under the account through the "User Management" feature in the management center, which you can navigate to from the page navigation.
+
+## Configure Account Administrator
+
+Only users with the account administrator (Account\_admin) role can create and maintain global users. The first user who creates a Singdata account is granted the account administrator role by default.
+
+Users with the account administrator (Account\_admin) role can configure other users to become account administrators. The account administrator role can be granted to one or more users, but at least one user must be granted this role. To avoid business operation disruptions due to login issues of account administrator users, it is recommended to configure at least two users as account administrators.
+
+The steps to manage the account administrator role are:
+
+1\. After logging in, go to .accounts.singdata.com/workbench, click "User Management", click the "..." button on the right side of the user you want to set as an account administrator to expand the operation buttons, and click "Edit";
+
+:-: ![](.topwrite/assets/image_1740572948427.png =802)
+
+^
+
+2\. In the pop-up window, select "Yes" in the "Set as Account Administrator" section. Then click "Save".
+
+:-: ![](.topwrite/assets/image_1740573048895.png =449)
+
+3\. Account administrators can remove the "Account Administrator" role from other users. Similar to granting the account administrator role, in the user's "Edit" pop-up window, select "No" in the "Set as Account Administrator" section to remove the role.
+
+## User Management
+
+### Create Global Users
+
+Users with the account administrator role can click the "Create New" button on the "User Management" page, fill in the username, password, and phone number of the new user to create a global user.
+
+:-: ![](.topwrite/assets/image_1740573258188.png)
+
+:-: ![](.topwrite/assets/image_1740573290998.png =488)
+
+### Edit Global User Information
+
+On the "User Management" page, click the "..." on the right side of the user you want to edit, expand the operation bar, and click the "Edit" button to edit the user information. Only the user's email information and their designation as an "Account Administrator" can be modified. To ensure system security, even account administrators cannot modify other users' passwords and phone number information.
+
+:-: ![](.topwrite/assets/image_1740572948427.png =716)
+
+### Disable Global Users
+
+Disabling a global user will immediately change the current user's status and immediately prohibit all operations performed using that user identity. Disabling a global user is typically used to identify security risks and immediately halt all activities associated with the user identity to prevent further damage.
+
+Only users with the account administrator role can disable global users. On the "User Management" page, click the "..." on the right side of the user you want to disable, expand the operation bar, and click the "Disable" button. After a second confirmation, the user can be disabled.
+
+### Enable Global Users
+
+Only users in the "Disabled" status can be enabled. On the "User Management" page, click the "..." on the right side of the user you want to enable, expand the operation bar, and click the "Enable" button to enable the user.
+
+### Delete Global Users
+
+On the "User Management" page, click the "..." on the right side of the user you want to delete, expand the operation bar, and click the "Delete" button. In the pop-up window, enter the username of the user to confirm the deletion. Deleting a user identity will not automatically invalidate the user's login or disconnect the JDBC connection established with this user identity. However, any operation performed by this user on the web or any request executed using the JDBC connection will return an invalid identity.
+
+### Change User Password
+
+Account administrators cannot change other users' passwords; only the currently logged-in user can change their own password. While logged in, click the username in the lower left corner and click "Change Password". Complete the verification code verification in the pop-up window and enter the new password to complete the password change. The new password will take effect at the next login and will not affect the current login status.
+
+### Change User's Phone Number
+
+Account administrators cannot change other users' phone numbers; only the currently logged-in user can change their own phone number. While logged in, click the username in the lower left corner and click the "User Information" button to open the user information pop-up window. Click the "edit" button on the right side of the phone number, verify the current phone number in the pop-up window, and enter the new phone number to complete the phone number change.
+
+^
+
+## Service User Management
+
+### Create Custom Service Users
+
+Users with the account administrator role can click the "New Custom Service User" button on the "User Management" page, fill in the service user's username and password to create a custom service user.
+
+:-: ![](.topwrite/assets/image_1740573838659.png =448)
+
+^
+
+### Change Service User Password
+
+Users with the "Account Administrator" role can change the service user's password. Since changing the custom service user's password is a sensitive operation, it requires verification of the **currently logged-in user's** phone number. The password can only be changed after correctly entering the phone number verification code.
+
+:-: ![](.topwrite/assets/image_1740573966107.png =423)
+
+^
+
+### Disable Service Users
+
+Disabling a service user will immediately change the current service user's status and immediately prohibit all operations performed using that service user identity.
+Only users with the Account Administrator role can disable service users.
+
+On the **User Management** page, click the “...” button on the right side of the service user you want to disable to expand the action menu. Then, click the **Disable** button and confirm the action to complete the process.
+
+![](.topwrite/assets/image_1740574046973.png)
+
+^
+
+### Delete Service User
+
+On the **User Management** page, click the “...” button on the right side of the service user you want to delete to expand the action menu, then click the **Delete** button. In the pop-up window, enter the service user's name to confirm the deletion.
+
+Since service user identities are often associated with system scheduling tasks or other application tasks, deleting an active service user may disrupt production tasks and cause failures. Therefore, the deletion confirmation window includes a “**Force Delete**” checkbox for users to decide whether to proceed with a forced deletion.
+
+:-: ![](.topwrite/assets/image_1740574187675.png =549)
+
+If "**Force Delete**" is not selected, the service user identity will undergo **soft deletion**. This means all tasks utilizing this service identity will be interrupted. However, the service user will be retained for **24 hours**, during which it can be restored by clicking the "**Restore**" button, reverting the service user status to "**Enable**". Once restored, tasks using this service identity can resume normal execution (unless they require manual restart due to no retries or exceeding retry limits). After **24 hours**, the service user identity will be **permanently deleted** and cannot be recovered.
+
+If "**Force Delete**" is selected, the service user identity will be deleted immediately without a retention period.
+
+^

package/bin/skills/lakehouse-doc-en/references/agg_function.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc-en/references/aggregate_functions/approx_count_distinct.md

@@ -0,0 +1,50 @@
+### APPROX_COUNT_DISTINCT Function
+```sql
+approx_count_distinct(expr)
+```
+#### Function Description
+The `approx_count_distinct` function uses the hyperloglog algorithm to approximately calculate the number of distinct values in a column. When the cardinality is high, this function can quickly return an approximate result, but please note that the result will have some degree of error.
+
+#### Parameter Description
+* `expr`: The column for which the number of distinct values needs to be calculated. It can be of basic data types, including numeric types (integers, decimals), string types, time types, boolean types (true/false), decimal types, and binary types, etc.
+
+#### Return Result
+* The return value type is `bigint`, representing the approximately calculated number of distinct values.
+* `null` values will not be counted.
+
+#### Usage Example
+1. Calculate the number of distinct values in a numeric type column:
+```sql
+SELECT approx_count_distinct(num_col) FROM VALUES (1), (1), (2), (2), (3), (null) AS t(num_col);
+```
+Results:
+```
+3
+```
+2. Calculate the number of distinct values in a string type column:
+```sql
+SELECT approx_count_distinct(str_col) FROM VALUES ('apple'), ('banana'), ('apple'), ('orange'), (null) AS t(str_col);
+```
+Results:
+```
+3
+```
+3. Calculate the number of different values in a Boolean type column:
+```sql
+SELECT approx_count_distinct(bool_col) FROM VALUES (true), (false), (true), (null) AS t(bool_col);
+```
+Results:
+```
+2
+```
+4. Calculate the number of different values in the time type column:
+```sql
+SELECT approx_count_distinct(time_col) FROM VALUES ('2021-01-01 10:00:00'), ('2021-01-01 11:00:00'), (null), ('2021-01-01 10:00:00') AS t(time_col);
+```
+Results:
+```
+2
+```
+#### Notes
+* When the data volume is small, using the `approx_count_distinct` function may not be as efficient as directly calculating the accurate result. It is recommended to use this function when processing large amounts of data.
+* Since the `approx_count_distinct` function uses an approximate algorithm, the result may have some errors. Please use it with caution in scenarios where high accuracy is required.

package/bin/skills/lakehouse-doc-en/references/aggregate_functions/bit_and.md

@@ -0,0 +1,40 @@
+### BIT_AND Function
+```sql
+bit_and([distinct] expr)
+```
+#### Function Description
+The BIT_AND function is used to calculate the bitwise AND result of a set of integer values. This function performs a bitwise AND operation on the input expressions and returns the result.
+
+#### Parameter Description
+* `expr`: An integer type expression, which can be of type tinyint, smallint, int, or bigint.
+* `distinct`: An optional parameter used to specify whether to perform deduplication on the calculation result. If set to distinct, the function will calculate the bitwise AND result of the unique expression values.
+
+#### Return Value
+* The return value type is consistent with the input parameter type.
+* If it contains null values, null does not participate in the calculation.
+
+#### Usage Example
+1. Calculate the bitwise AND result of a set of values:
+```sql
+SELECT bit_and(col) FROM VALUES (3), (5), (7) AS tab(col);
+-- Result: 1
+```
+2. Calculate the bitwise AND result of the deduplicated value set:
+```sql
+SELECT bit_and(DISTINCT col) FROM VALUES (3), (3), (5), (7), (null) AS tab(col);
+-- Result: 1
+```
+3. Calculate the bitwise AND result of a column in the actual data table:
+```sql
+SELECT bit_and(user_id) FROM user_table WHERE status = 'active';
+-- Assuming the values of the user_id column are 1024, 2048, 3072, the result is 0 because there is no bit that appears in all values.
+```
+4. For datasets containing null values, calculate the bitwise AND result:
+```sql
+SELECT bit_and(score) FROM student_scores WHERE subject = 'Math';
+-- Assuming the values of the score column are 75, 85, null, 95, the result is 75 because null is not included in the calculation.
+```
+#### Notes
+* The BIT_AND function performs a bitwise AND operation on the input values, so the result may need further interpretation or conversion to a more understandable format.
+* When using the distinct parameter, the function will ignore duplicate values and only calculate non-duplicate values.
+* If all input values are null, the result will be null.