数据资产发现原理：自动化发现的技术栈

上一章我们聊了“为什么要做数据发现”，这一章直接上干货——自动化发现到底靠什么技术实现？

我刚开始做数据资产治理的时候，以为数据发现就是写几个脚本连上数据库扫一遍。后来发现,事情远没那么简单。一个像样的数据发现SDK，背后是爬虫、API、日志解析这三块技术的组合拳。

说白了，自动化发现要解决的问题就是：在不依赖人工登记的前提下，自动感知你企业里到底有哪些数据、存在哪、长什么样。这就像给数据资产装了个雷达。

2.1 爬虫：数据资产的“侦察兵”

爬虫不只是用来抓网页的。在数据发现场景里，它的任务是遍历已知、发现未知。

我记得在给一家银行做项目时，他们的数据分散在几十个MySQL实例、上百个表空间中。人工梳理？不现实。我让爬虫引擎先连上数据库的元数据表，爬取所有库名、表名、字段名。

但这只是起点。真正的爬虫引擎需要支撑三件事：

1. 横向扩展——能同时扫上千个数据源，不把源系统压垮
2. 增量发现——第一次全量，之后只扫变化的部分
3. 深度遍历——从数据库到文件服务器，再到对象存储，穿透每一层

下面是一个精简版的爬虫核心逻辑，我用Python写了个示意框架：

class DataCrawler:
    def __init__(self, sources):
        self.sources = sources  # 数据源列表
        self.discovered = []

    def crawl(self):
        for source in self.sources:
            connector = self.get_connector(source['type'])
            # 元数据抽取
            tables = connector.list_tables(source)
            for table in tables:
                columns = connector.describe_table(table)
                self.discovered.append({
                    'source': source['name'],
                    'table': table.name,
                    'columns': [c.name for c in columns],
                    'row_count': connector.estimate_rows(table)
                })
        return self.discovered

2.2 API：数据资产的“连接器”

爬虫能扫内部存储，但遇到外部系统呢？比如公司的SaaS数据、云存储、或者那些只开放API的系统。这时候就需要API发现模块登场。

API发现的核心思路是：通过标准的元数据接口，拉取结构化信息。比如AWS的Glue API、阿里云的DataWorks接口、或者你自建系统的RESTful接口。

我建议把API发现模块设计成插件式的。一来方便扩展新数据源，二来可以针对不同API的限流策略做适配。

来看看我在项目里用的API适配器模式：

class APIConnector:
    def __init__(self, endpoint, ):
        self.session = requests.Session()
        self.session.headers.update({'Authorization': f'Bearer {}'})
        self.endpoint = endpoint

    def discover_datasets(self):
        # 第一步：获取数据集列表
        response = self.session.get(f'{self.endpoint}/datasets')
        resp.raise_for_status()

        datasets = []
        for item in response.json()['data']:
            # 第二步：对每个数据集，获取schema信息
            schema_resp = self.session.get(
                f'{self.endpoint}/datasets/{item["id"]}/schema'
            )
            item['schema'] = schema_resp.json()['fields']
            datasets.append(item)
        return datasets

你可能会问：API发现和爬虫有什么区别？

维度	爬虫模式	API模式
主动/被动	主动扫描	被动拉取
耦合度	高（需要读取存储）	低（走标准接口）
适用场景	数据库、文件系统	SaaS、云服务、微服务
性能影响	可能较大	可控

2.3 日志解析：数据资产的“监听器”

爬虫和API做的都是“静态发现”，也就是在某一时刻的快照。但数据是活的。每天都会有新表创建、字段变更、数据更新。

日志解析解决的就是这个“动态发现”问题。它通过监听数据库的binlog、应用的访问日志、或者Data Catalog的操作日志，实时捕获数据资产的变化。

我在做这个模块时，最头疼的是日志格式的多样性。MySQL的binlog、PostgreSQL的WAL、MongoDB的oplog，还有各种业务系统的自定义日志——每种格式都要写一个解析器。

核心思路是这样的：

1. 日志采集——用Filebeat或Fluentd收集日志文件或流
2. 格式解析——按数据源类型匹配对应的解析规则
3. 事件提取——从日志中提取出“什么资产发生了怎样的变化”
4. 状态更新——把变化同步回资产目录

class LogParser:
    def __init__(self, pattern_file='rules.yaml'):
        self.rules = self.load_patterns(pattern_file)

    def parse(self, raw_line: str) -> dict or None:
        for rule in self.rules:
            match = re.match(rule['pattern'], raw_line)
            if match:
                return {
                    'event_type': rule['event'],    # create/alter/drop
                    'asset_type': rule['asset'],     # table/column/index
                    'asset_name': match.group('name'),
                    'timestamp': match.group('time')
                }

    def load_patterns(self, path):
        with open(path, 'r') as f:
            return yaml.safe_load(f)['patterns']

2.4 知识体系总览

三种技术栈不是孤立工作的。它们互相配合，形成一个完整的自动化发现闭环。下面这张图展示了它们之间的协作关系：

从图上你可以看到：不同的数据源类型，会触发不同的发现策略。数据库和文件服务器主要靠爬虫做定期扫描，SaaS和云服务走API接口,而日志解析则是给所有数据源加上一个“实时心跳”，确保变化能被第一时间捕获。

2.5 怎么选？我的几点建议

你可能会纠结：做数据发现SDK时，到底主攻哪种技术？

其实没有标准答案。我个人的选型原则是这样的：

• 内部系统居多，且需要全量扫描——优先把爬虫引擎做扎实。它是兜底方案，能发现你意想不到的数据资产。
• 外部API为主，或者治理云上的数据——API发现模块是你的主战场。保证它能处理OAuth认证、限流、分页这三个经典问题。
• 对时效性有要求，需要分钟级感知变化——日志解析必须上。但要注意，日志解析不能作为唯一发现手段——它只能捕获变化，不能做初始发现。