自动部署自适应分析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存储库中。

初学者指南描述了在新报表文件中创建小部件的过程。如果使用“插入”选项卡或“组件”窗口，也可以将图表或表格插入到现有的报表中。