自动部署自适应分析Adaptive Analytics
当我们使用IRIS时，我们通常有能力快速的部署一个现成使用的BI基础模块（数据、分析立方体和IRIS BI仪表盘）。当我们开始使用Adaptive Analytics时，我们通常希望有同样的功能。Adaptive Analytics拥有我们需要的所有工具。文档中包含了对如何使用开放的网络API的描述。用户界面和引擎之间的所有交互也都是通过内部的Web API发生的，并且可以被发射出来。
有必要将这两个过程自动化：在容器中部署Adaptive Analytics和直接部署到服务器系统。为此，最简单的方法是使用bash脚本来处理API。我们唯一需要的第三方应用程序是一个名为jq的JSON文件解析器。你可以使用以下命令来安装它：
apt update
apt install -y jq
首先，我们需要登录以获得一个API访问令牌。这个令牌也适用于引擎本身的方法。我们必须将访问令牌保存在一个变量中，因为现在我们几乎在每个请求中都需要它。对于一个标准的登录和密码admin/admin，该命令将看起来像这样：
TOKEN=$(curl -u admin:admin --location --request GET 'http ://localhost:10500/default/auth')接下来，我们需要一个活跃的引擎来与API交互。如果没有许可证检查，引擎是不可用的，所以我们要为它提供许可证。Web API没有这个选项，所以我们必须使用引擎命令：
curl --location --request PUT 'http://127.0.0.1:10502/license' --header 'Content-Type: application/json' --data-binary "@$license"许可证变量包含许可证文件的路径。当我们在不同的平台和不同容量的PC上做一些测试时，我们注意到一个奇特的现象。在系统启动脚本完成后，Adaptive Analytics可能会出现这样的情况：服务还没有启动，但初始化脚本已经将控制权交给了我们的脚本。为了确保引擎启动和运行，我们在一个循环中组织发送许可证，直到我们收到许可证已被接受的消息。这样做的代码看起来像这样：
RESPONSE="1"
TIME=1
echo "Waiting for engine ......."
while [ "$RESPONSE" != "200 OK" ]
do
for license in /root/license/*
do
RESPONSE =$(curl --location --request PUT 'http://127.0.0.1:10502/license' --header 'Content-Type: application/json' --data-binary "@$license" | jq -r '.status.message')
sleep 1s
done
echo "$TIME seconds waiting"
TIME=$(($TIME + 1))
done
echo "Engine started"打印时间变量对于调试启动问题很有用。正如你所看到的，我们在一个特定的文件夹中循环浏览文件，以便不被文件名所束缚。我们将在未来再次使用这种方法。
现在我们可以与web API互动，我们可以将我们的项目上传到Adaptive Analytics。我们使用下面的代码将所有放在指定文件夹中的项目发送到引擎：
for cube in /root/cubes/*
do
sleep 1s
curl --location --request POST "http://localhost:10500/api/1.0/org/default/"Authorization: Bearer $TOKEN" --header "Content-Type: application/xml" --data-binary "@$cube"
sleep 5s
done如果我们希望我们的项目可以被BI系统使用，我们必须发布它们。幸运的是，在API中也有这样的方法。由于项目在导入时得到一个随机的唯一ID，首先，我们应该把这些ID解析成一个变量：
PROJECTS_ID=$(curl --location --request GET "http://localhost:10500/api/1.0/org/default/projects" -- header "Authorization: Bearer $TOKEN" | jq -r '.response[].id')然后我们需要遍历变量中的所有项目并发布它们。
for project in $PROJECTS_ID
do
curl --location --request POST "http://localhost:10500/api/1.0/org/default/project/$project/publish" --header "Authorization: Bearer $TOKEN"
sleep 1s
done现在我们需要告诉Adaptive Analytics如何连接到IRIS，以及应该如何命名连接，以便我们的项目能够接收它们。在API中有一个方法，但是它有不同的URL地址。事实证明，这是一个有文档记录的引擎方法。所以如果我们想使用它，我们需要访问一个不同的端口。该方法接受JSON文件形式的连接信息，但不可能从Adaptive Analytics以相同的格式导出它。API根据请求返回给我们的JSON文件有一些额外/缺失的字段。以下是用于IRIS连接的JSON文件模板：
{
"platformType": "iris",
"name": "name_you_want",
"connectionId": "name_you_want",
"overrideConnectionId":true,
"extraProperties":
{
"namespace": "Your_namespase ",
"udafMode": "customer_managed"
},
"aggregateSchema": "ATSCALE",
"readOnly":false,
"isImpersonationEnabled": false,
"isCanaryAlwaysEnabled": false,
"isPartialAggHitEnabled": false,
"subgroups":
[
{
" name": "iris",
"hosts": "iris",
"port": 1972,
"connectorType": "iris",
"username": "Your_username",
"password":"Your_password",
"isKerberosClientEnabled": false ,
"queryRoles":
[
"large_user_query_role",
"small_user_query_role",
"system_query_role"
],
"extraProperties": {},
"connectionGroupsExtraProps": {}
}
]
}值得一提的是“udafMode”参数:如果在IRIS中安装了UDAF，我们可以将其设置为“customer_managed”，如果没有安装UDAF，则设置为“none”。要了解更多关于UDAF是什么、为什么需要它以及在安装它时可能会遇到什么缺陷的信息，请查看这篇()文章。
当我们为所有连接准备好这样的文件时，我们应该从文件夹中加载它们：
for connection in /root/connections/*
do
sleep 1s
curl --location --request POST "http://localhost:10502/connection-groups/orgId/default" - -header "Authorization: Bearer $TOKEN" --header "Content-Type: application/json" --data-binary "@$connection"
sleep 5s
done接下来，我们希望有机会将Logi Report Designer连接到Adaptive Analytics实例。这就是为什么我们需要模拟Adaptive Analytics初始化的第一个步骤之一。因此，我们为hive连接设置端口：
sleep 1s
curl --location --request POST "http://localhost:10502/organizations/orgId/default" --header "Authorization : Bearer $TOKEN" --header "Content-Type: application/json" --data-raw '{"hiveServer2Port": 11111}'
为了不超过IRIS社区版本中的连接限制，我们必须限制Adaptive Analytics的同时连接数量。根据我们的经验，为了防止在测试场景中超过限制，在5个连接中保留3个是值得的。我们使用下面的代码模拟更改设置：
for settings_list in /root/settings/*
do
curl --location --request PATCH 'http://localhost:10502/settings' --header "Authorization: Bearer $TOKEN" --header "Content-Type: application/json" --data-binary "@$settings_list"
done在文件夹下的JSON文件中，写入如下内容：
{
"name": "bulkUpdate",
"elements": [
{
"name": "connection.pool.group.maxConnections",
"value": "3"
},
{
"name": "connection.pool.user.maxConnections",
"value": "3 "
}
]
}根据我使用Adaptive Analytics的经验，这种限制对性能影响不大。
修改设置后，需要重新启动引擎：
curl --location --request POST 'http://localhost:10500/api/1.0/referrerOrg/default/support/service-control/engine/restart'
现在我们有了自动准备Adaptive Analytics工作所需的一切。为方便您，我们已将上述脚本发表在：
https://github.com/intersystems-community/dc-analytics/blob/master/atscale-server/entrypoint.sh
在这个存储库中，您还可以找到使用聚合更新计划的脚本。聚合是在IRIS中配置UDAF时由Adaptive Analytics生成的特殊表。这些表存储聚合查询的缓存结果，从而加快了BI系统的工作速度。Adaptive Analytics有一个更新聚合的内部逻辑，但是自己控制这个过程要方便得多。
我们曾经遇到过这样的情况：这些表存储的数据已经过时好几天了。相应地，Adaptive Analytics返回的值与真实值明显不同。为了避免这种情况，我们在更新BI系统中的数据之前设置了每日的聚合更新。
您可以在Adaptive Analytics的web界面中按每个立方体配置更新。然后，您将能够使用脚本将时间表导出和导入到另一个实例，或者使用导出的时间表文件作为备份。如果不想单独配置每个数据集，还可以在应用程序中找到一个脚本，将所有数据集设置为相同的更新计划。
最后一件便于自动化的事情是在开发阶段从Adaptive Analytics备份项目本身。为了设置这种自动化，我们编写了另一个OEX应用程序，它每天一次将所选项目保存到Git存储库中。
最后一件便于自动化的事情是在开发阶段从Adaptive Analytics备份项目本身。为了设置这种自动化，我们编写了另一个OEX应用程序OEX application，它每天一次将所选项目保存到Git存储库中。
初学者指南描述了在新报表文件中创建小部件的过程。如果使用“插入”选项卡或“组件”窗口，也可以将图表或表格插入到现有的报表中。
