​

在上一篇文章中，我们围绕“算子级血缘解析技术”，全面介绍了 Aloudata BIG 主动元数据平台的核心能力及优势，帮助企业加速实现数据管理的“自治理”，推动企业的数智化运营进程。

本篇文章，我们盘点和整理了十一个同客户交流过程中遇到的「Aloudata BIG 平台如何对接、应用」等方面的疑难杂题，以帮助您从落地视角，更深入地了解 Aloudata BIG 平台。 

从客户调研反馈来看，问题可分为如下四类：

【定位：血缘产品定位】聚焦 Aloudata BIG 平台如何与企业现有多类平台的集成及元数据采集适配，产品能力建设在企业内部与企业已有数据平台类产品的定位。

【要求：血缘全、准、鲜】如何确保血缘的全域接入和高准确率，如何针对改变过往的运动式梳理及血缘构建，确保血缘长期保鲜。 

【场景：业务场景应用】血缘能力构建之后的场景应用及价值。

【部署 &产品效果验证】是否支持信创环境部署，以及产品预期效果验证。

【定位：血缘产品定位】

Q1：在面对企业多平台数据仓库、大量表、复杂的 SQL 加工逻辑以及众多运行任务的情况下，如何完成与 BIG 平台的初始化对接？

【关键词】：采集内置、元仓对接、增全量

BIG 平台支持内置元数据实体和自定义采集，支持从元数据表、文件和 Kafka 消息通道中进行增量和全量采集。未来，BIG 平台还会开发从源系统的 MetaStore 中直接采集的功能。

以元数据表采集为例，BIG 的目标客户通常都已在 BIG 实施前对自身的元数据进行过采集、清洗和整理，将其存储在一个元数据表或系统中，假设 Hive 平台有 10 万张表，企业将这些表的 DDL（数据定义语言）、名称、所属数据库等信息插入至元数据表中，这时可以通过在 BIG 新建采集任务读取元数据表中的数据，实现元数据的接入，从而获得更细精度的解析和更多元数据的策略挖掘能力。BIG 兼容全量表和增量表的采集方式，这意味着企业可以根据自身的分析需求，选择提供全量表或者增量表进行采集。在采集增量表的时候，平台将自动识别和判断增量字段，以确保数据的准确性和时效性。

Q2：如企业已完成全量元数据接入 BIG 平台，后续新增的元数据部分，如何有效地实现对接？是否需要提供所有相关的 SQL 逻辑？或者是特定的文本格式或标准接口？

【关键词】：元数据表、T+1、后台对接

无需额外的步骤，仅需要提供相应的 SQL 即可完成与 BIG 平台对接。具体而言，企业需要将每一段 SQL 放置在特定的元数据表中，并在该表中明确标识每条 SQL 所对应的具体任务、执行该 SQL 的数据库环境等相关信息。BIG 平台按照 T+1 的方式运行，即次日处理前一日提交的 SQL，并自动执行解析任务。此外，BIG 平台还具备实时采集的能力，该能力已在多家头部券商客户的数据环境中得到成功实施。对于实时采集的需求，提供直接的后台对接服务，确保数据的即时性和准确性。

Q3：在企业已建设的数据治理平台或者资产管理平台上如何与 BIG 平台实现血缘能力外化及输出？

【关键词】：iframe 集成、微前端集成、图谱接口输出、企业用户集成与 SSO 

BIG 平台提供多种能力外发及输出模式：在用户集成端，支持快速地用企业的用户体系完成登录及鉴权集成，实现基于企业自有用户体系的无缝登录；在产品功能端，提供多种灵活的集成方式，包括 iframe 及微前端等，基于该方式可以快速地将 BIG 的核心能力与企业已有的类似数据治理平台、资产管理平台以及数据研发平台做融合集成，实现灵活的能力外发；在应用场景端，提供丰富的图谱接口，用户可以基于接口快速应用集成，场景定开。

【要求：血缘全、准、鲜】 

Q1：如何将上层应用类 BI 分析引擎数据接入到 BIG 平台，实现全流程血缘解析直至字段级？

【关键词】：定义数据接口、定制化、持续优化

所谓血缘全，是指在传统的血缘基础范围上，BIG 平台会将企业的应用场景，商业智能（BI）等自定义实体也会纳入到血缘链路。

对于自研 BI 分析引擎，我们将定义明确的数据接口或协议，按照这些接口或协议对接数据。若数据可通过 SQL 查询直接获取，我们将利用 SQL 任务进行高效的数据采集。对于第三方 BI 分析引擎，将需要与其开发者或提供商进行多方合作，明确所需的元数据类型，如数据存储方式、语义信息及实体关系等。随后，我们从第三方 BI 分析引擎中清洗和提取这些元数据，并进行定制化分析。最终，这些元数据将被整合到我们的数据血缘解析系统中，确保实现从数据源到 BI 报表的全流程字段级血缘解析。

在整个过程中，我们将严格控制数据质量，确保数据的准确性和完整性，并持续优化数据对接和血缘解析流程，以应对不断变化的业务需求和数据环境。

Q2：如何实现 95% 的血缘准确率交付以及 5% 的白盒分析，确保血缘的持续提升？

【关键词】：交叉对比验证、错误分类和归因分析、真实环境验证

首先我们会提供严格的产品出厂质量门禁，即在产品出厂前，会通过多解析器进行交叉比对验证，确保“血缘解析成功即形成正确的血缘、血缘解析不成功即报错”。然后，我们会深入分析错误日志，针对无法解析或解析失败的案例进行错误分类和归因分析，不断完善和优化血缘解析器能力。经过多年技术沉淀和在头部客户真实环境的验证，BIG 平台公开承诺：算子级血缘准确率可稳定在 95% 以上。在实际应用中，我们为招商银行、杭州银行生产环境均交付了超过 99%准确率的算子级血缘图谱。

Q3：在数据平台管理实践中，“过期血缘”管理是一个重要环节，贯穿数据开发、运维和分析全过程。BIG 平台如何对“过期血缘”进行管理，是否支持血缘保鲜？

【关键词】：实时血缘更新、元数据标签保鲜

为了有效管理“过期血缘”，BIG 平台提供了两层“血缘保鲜”机制：第一层，实时血缘更新，能够实时监控数据的变化，并根据这些变化自动更新现有的血缘图谱，通过这种机制，始终确保血缘图谱反映数据的最新状态，为开发、运维和分析人员提供准确的数据依赖关系信息。

第二层，元数据标签保鲜，当元数据和血缘发生变化时，我们需要判断原先为元数据挖掘的标签是否仍然适用于变化后的数据或资产，这涉及到标签的重新评估和可能的更新，以确保标签与数据的实际状态保持一致。

在现有的平台能力下，第一层保鲜通过自动化手段实现，确保血缘图谱的实时性和准确性；第二层保鲜则通过人工和自动化的结合，确保元数据标签的时效性和有效性。这种双层保鲜机制为数据平台的管理提供了强有力的支持，确保数据的质量、一致性和可追溯性。

【场景：业务场景应用】

Q1：在将数据表及其血缘关系接入 BIG 平台后，资产管理方面能够提供哪些支持？

【关键词】：资产打标及扩散、反向元数据输出、资产目录精准化和动态化

在将数据表及其血缘关系接入 BIG 平台后，资产管理方面我们还能够提供一系列功能支持，构成了资产管理的强大底座。BIG 平台可提供打标能力，企业根据业务需求为数据资产添加自定义标签，实现精细化分类和管理；内置血缘解析能力，清晰展示数据资产的来源、去向以及数据之间的依赖关系，为数据质量监控和风险控制提供有力支持；具有影响分析功能，通过分析数据资产的变动对业务流程、数据应用等方面的影响，为业务决策和风险评估提供科学依据；支持对海量数据资产进行统计分析，帮助企业深入了解数据资产的分布、使用情况等关键信息。

同时，BIG 平台可作为一个反向元数据输出工具，将自身的功能整合到客户现有的资产管理平台之上，实现功能的互补和增强。例如，杭州银行便成功将 BIG 平台的血缘页面集成到其资产平台的选择页面，实现了血缘关系的可视化、标签化管理、链路保障等功能与研发、运维等流程的紧密整合。

此外，企业可以将 BIG 平台与大模型、自动化分类算法等结合，实现资产目录的精准化和动态化更新。这种管理方式不仅解决了静态数据目录难以吸引和辅助业务的问题，还通过元数据的实时更新和场景打标的穿透能力，使数据分类更加高效、精准和动态化，为企业数据资产管理带来更大的想象空间。

Q2：如何借助于血缘产品能力帮助企业快速进行变更协同及影响面分析？

【关键词】：血缘版本、变更捕获、影响分析及报告产出

BIG 平台会提供算子级精准血缘图谱，在企业的全域数据资产被接入之后，BIG 平台会构建一张全域精准且可持续保鲜的链路图谱。一方面用户可基于 BIG 提供的影响分析报告功能进行变更模拟（如表删除、表结构变更、列删除、列更名、列类型变更等），基于设定的变更类型产出影响面分析报告，进行变更事前分析。另一方面，借助于 BIG 的血缘版本能力，在被标注的核心链路上，可构建链路监控预警操作，捕获事中企业数据的变更场景并基于精准的链路图谱进行变更影响面统计分析，产出影响面分析报告，在与企业的 OA 工作流集成之后，可以快速进行变更受影响 owner 的协同通知。借助于事前、事中的双重手段，让企业变更风险能管住、变更操作能落实、变更协同更高效。

Q3：是否支持精确查询数据库中特定表的存储情况？识别出不同表之间的数据重合度？提供针对大表的合并或删除建议，实现数据存储优化治理？

【关键词】：容量配置、口径判重

具体而言，我们可以在表的属性中新增一个名为“容量”的属性，并将其配置为一个采集任务。一旦配置完成，该任务将自动采集并导入表的容量数据到血缘图谱中，使得用户可以方便地查询每张表的容量大小。但是需要企业在初期设计元数据表时，将容量信息作为必要的属性进行定义和包含，这是因为 BIG 平台并不直接接入企业数据库的计算引擎，而是依赖于预先定义和配置的元数据表进行工作。

BIG 平台在元数据管理方面的真正价值体现在以下几个方面：首先，它能够帮助企业建立和维护数据表之间的血缘关系，确保数据的来源和流向清晰可见；其次，它能够解析出字段的口径信息，这对于理解和使用数据至关重要；最后，通过对字段口径的判重，它能够帮助企业快速识别出相同或相似的表，从而优化数据存储结构，减少冗余。

综上，BIG 平台不仅提升了元数据管理的效率和准确性，还使其能够根据运营策略开展数据治理工作，提高数据的可用性和价值。

【部署 &产品效果验证】

Q1：关于血缘产品的部署架构、数据存储是否支持信创？

【关键词】：兼容麒麟、支持信创类数据库、适配国产系统及浏览器

BIG 平台在在部署侧与诸如麒麟等信创系统做了兼容认证，支持 Arm 及 x86 架构部署，满足企业对信创的要求；在数据存储侧，我们采用 PostgreSQL+Nebula(图库) 的组合模式进行落地，主要是由于血缘关系通常表现为复杂的网络或图结构，其中包含了数据资产之间的依赖和关联关系。我们是将血缘数据存储在 Nebula 图数据库，因为这种类型的数据结构提供了高效的存储和查询机制，在数据存储侧如确实需要适配信创环境，企业可以考虑将  Nebula 图数据库迁移到兼容信创环境的其他图数据库系统中，或者探索在信创环境中部署和运行 Nebula 图数据库的可行性，这将确保血缘数据的完整性和查询效率得到最大程度的保留。

Q2：企业如何有效验证其现有数据资产或加工后的 SQL 在 BIG 平台上的运行效果？是否有对外的体验环境？

【关键词】：公网专有环境检验、企业数据环境 POC

一方面，我们支持公网专有环境的检验，企业提供样例脚本，将这些脚本导入到我们在公网上开放的专有环境中进行检验，快速评估脚本的兼容性、性能和效果。另一方面，我们也支持企业数据环境 POC，可以更准确地反映脚本在实际运行环境中的表现，包括数据质量、处理速度、资源消耗等。具体选择哪种方式，将根据企业的实际需求、时间安排和成本预算等因素来安排。

如想要了解更多关于 Aloudata BIG 产品及最佳实践的详情，进入 Aloudata 官网，快速了解期待您的关注、交流、分享和反馈。