阿里云爬坑日志（一）：使用 Dataworks 数据集成实现 REST API 数据集成
每次使用阿里云的产品都会血压升高，晚上喝了几口汾酒压压惊。
今天是使用Dataworks接入REST API 的数据到 Hologres ，没想到遇到了天坑：尽管配置 REST API 数据源的 Basic Auth 或者 Token Auth，但是在运行数据集成任务时，Dataworks 居然没有给 REST API 服务器发送认证信息（即 Authorization 消息头）。这不得不让人怀疑：这个功能有人在用吗，难道是个僵尸功能？
本文记录了此次“惊心动魄”的经历。
情景重现 🔗
以下的情景发生于 2024年3月27日。
确定架构 🔗
最近有一个接入应用系统数据到数据平台的需求。第一个反应就是写一段脚本，从 API 读取数据，写入到 Hologres 数据库中，然后定时调度即可。但是作为一个生产环境需要使用的数据集成任务，除了集成数据之外，还需要监控、报警、运行统计非功能的需求。因此还是得用专业的 ETL 工具。
封装数据API 🔗
应用系统的 API 调用起来比较复杂（比如认证需要使用 API Key和Secret换取 Access Token，有调用频率的限制；有些 API 还需要多次的递归调用）。此时，ETL 工具里的“拖拉拽”就显得捉襟见肘了，很可能得提供脚本（比如 Python脚本）完成复杂逻辑，然后在ETL工具调用。另一种方式，是对原 API 调用进行封装，将复杂的调用逻辑封装在 API 之中，然后对外提供直接使用的接口, 同时提供 Http Basic 或者 Bearer Token的认证方式；此时可以使用 Promethues 对接口进行监控和报警。这样将数据以新的 API 暴露出来后，还为其他消费场景复用。因此我们选择了这种方式，并且开发了 HTTP Basic Auth的认证方式。
【疯狂吐槽】后来，我才明白，这个决定是噩梦的开始。
在 Dataworks 创建数据源，使用 Basic Auth 认证方式 🔗
有了 API 后，就要考虑如何接入数据平台了。我们使用的数据平台工具是阿里云 Dataworks，其中提供了针对 REST API 的集成能力。其支持的认证方式包括 Basic Auth 和 Token Auth。选择验证方法为 Basic Auth。
【疯狂吐槽】不得不说。此处的中文“验证方法”。此处指的是 Authentication，英文应该为“认证方式”；而验证的中文，一般是 Validation 或者 Verification。更让人不解的是，页面上是“验证方式”，而文档中用的是“认证方式”，为什么不用“统一语言”？也许是因为中文博大精深吧。
在 Dataworks 的数据开发中创建集成任务 🔗
进入 Dataworks 的数据开发，创建离线同步节点。选择数据源为刚刚创建的 REST API 数据源。填写参数后，点击“数据预览”。此时可以看到 Dataworks 正常读取到了 REST API 里的数据。然后配置数据去向。
运行 REST API数据集成任务 🔗
配置好之后，点击“运行”按钮，然后稍等片刻，数据集成任务就开始运行了。
遗憾的是，任务执行失败。查看任务的日志，可以看到 REST API返回了 401 状态码。多次检查和重新配置数据源，依然是同样的错误。
还好 REST API是自己开发的。然后更新和部署API，打印出了 Dataworks 发给 API 的请求头：
{
"Accept-Encoding": ["gzip,deflate"],
"Connection": ["Keep-Alive"],
"User-Agent": ["Apache-HttpClient/4.4 (Java 1.5 minimum; Java/1.8.0_275)"]
}
看来有一些线索了：服务器没有接收到认证信息，即 Authorization 请求头。
作为对比，我使用 curl 访问了 API。此时打印的请求头为:
{
"Accept": ["*/*"],
"Authorization": ["Basic Zm9vOmJhcg=="],
"User-Agent": ["curl/7.61.1"]
}
所以 API 是可以打印 Authorization 的，但没有打印 Dataworks 集成任务请求的 Authorization，说明它没收到这个消息头。
由于我们是在本地机器访问本地网络的 REST API的。而 Dataworks 是通过 VPC 中的集成资源，经 VPN 访问的 REST API，所以可能有很大差异。于是找了一台阿里云 ESC 服务器，使用 curl 访问 REST API，可以发现服务器也打印了 Authorization。可以初步推测，缺少 Authorization 与 VPC、VPN 和网络配置的关系应该不大。
在遇到问题时，我联系了 Dataworks 的支持人员反馈问题，同时也协助调试。但没有找到解决办法。
通过 Token Auth 运行 REST API数据集成任务 🔗
既然 Basic Auth 不可用，那么试试 Token Auth 吧。其实看到页面上的 Token Auth，我是不明白什么是 Token Auth的。看了文档，才知道原来是 Bearer Token 认证。
于是，先给 REST API增加 Bearer Token认证的机制，然后在数据源页面修改认证方式为 Token Auth 。在填写 Bearer Token 的时候，是明文显示的，没有遮盖。虽然遮盖秘密信息是好的实践，但此处没有遮盖，也说得过去吧。
回到数据开发页面，再次运行数据集成任务。遗憾地是，任务又失败了，而且是同样的错误码 401。在 REST API 的服务器，依然没有收到 Authorization 消息头。看来，Token Auth 也有类似的问题。
但是，在查看集成任务日志的过程中，下巴都被惊掉了：日志里有明文的 Bearer Token。这相当于把用户密码打印到了日志里。在日志里打印登录凭证（Credentials），可以说是相当严重的信息安全事故了。 吓得我赶紧修改服务器端的 Bearer Token，然后立即阿里云 Dataworks 团队反馈。
【疯狂吐槽】曾经看到阿里云一些服务使用 HTTP 而不是 HTTPS 地址，我已经对阿里云有所顾虑；这次遇到打印 Bearer Token，让我对阿里云的安全意识和安全规范大跌眼镜，真不知道底线在哪里。
静待回应 🔗
看来 Basic Auth 和 Token Auth 都不可用，只能等待 Dataworks 的回应了。
其他要点 🔗
在配置 REST API 集成任务时，需要在页面“拖拉拽”地配置字段的映射。除了 REST API本身的字段外，我还想加入一些“元信息”，比如给每条记录新增一条 PROC_TIME 代表处理时间——这是一个很常见的实践。对于MaxCompute 数据源，可以配置函数类型的字段，比如字段为 now()，此时类型会自动变为 “函数”。但是对于 REST API并没有出现这种联动。也不知道 REST API 是否支持函数类型的字段。那就等认证的问题解决了再看吧。
结尾 🔗
鉴于项目的缘故，最近几个月接触了阿里云，并且尝试 Dataphin 和 Dataworks，最终选择 Dataworks 作为数据开发和数据治理的平台。从 Dataworks 的介绍和页面上的功能来看，它是一个大而全的平台，似乎可以满足数据工程师、分析师、架构师的所有使用需求。但是在实际使用中，我的个人体验是：Dataworks似乎在打造一个封闭的体系，但在细节上非常粗糙。在遇到几次问题后，我时常怀疑自己：“这个功能没有人用过，还是我的使用方法不对？”无论如何，作为一个付费的产品， Dataworks 的完成度并不高，在使用的过程中，它 给团队带来了相当多的惊喜，直接影响了交付效率和工作心情。看似花哨的东西，其实经不起实战的考验。就像很多幻灯片，看起来非常地体系化和完整，但实际上只是内容的堆砌，经不起实践的考验。
补记 🔗
不得不说，阿里云的产品不行，但服务还是很拼的。在反馈了这个问题的第二天（即2024年3月28日）晚上10点左右的时候，我收到了阿里云技术人员的回复：“确实存在问题，我们后续会优化一下，不过临时绕过的办法”，那就在配置 REST API 数据源时候，在“默认请求头”里“任意添加一项”，比如填写 {"a": "b"}。
【疯狂吐槽】其实我觉得阿里云的员工工作到很晚是正常的，毕竟人家的收入水平在那里摆着。为了尽快验证，我也只能跟着拼了。可我的收入，没法跟人比。
起初，我是没有明白这个解决方法的。我以为是要在默认请求头里设置 Authorization 消息头。但默认请求头会被打印到日志里，是不符合安全实践的，为此还给对方解释了大半天。后来才明白这个方法的意图，也就是字面意思：是在默认请求头”里任意添加一项“。于是赶紧验证，居然真的正常接入了 REST API 的数据！在开发截止日期的前夜绝处逢生，不知道是喜还是忧。
【疯狂吐槽】当我明白”任意添加一项”这句话的含义后，有一种被智商被按在地上摩擦的感觉。这个解决方法出其不意，打得我措手不及。甚至让人觉得触发了游戏里的隐藏机关。解决问题不能总是通过严谨的逻辑推理和因果分析，有时候真的是玄学！
【疯狂吐槽】既然阿里云已经承认是自己的问题，那我真的怀疑，这个功能真的有人在用吗？这次的经历，让我再次深信：阿里云并不是靠产品或者产品质量赢得客户的。那靠的是什么呢？也许随着我有了很多的阅历，深入到真实的成年人的世界里，会逐步地探究明白。