随着国内中台的火热，对中台定义百家争鸣的同时，达成共识的就是中台的“抽象、共享和复用”的方法论。那么要实现抽象、共享和复用，避免重复造轮子，首先需要知道自己有哪些轮子。如果数据中台是对数据能力的“抽象、共享和复用”，那么知道自己有哪些数据能力则非常重要。要清楚自己的数据能力，则需要对数据有一个360°的全局全生命周期的了解与掌握。
数据分析师、数据工程师、产品经理在数据驱动型产品的数据分析中，如何了解海量数据的上下文，包括：数据如何生成、何时被更新以及和其他数据集的血缘关系等，对挖掘数据潜力至关重要。然而，对数据360°全面了解和掌握，需要访问和理解数据的上下文，而数据上下文可能只存在于最近使用过该数据的工程师或分析师的脑海中。随着组织规模的扩大，在正确的环境中找到合适的数据人员全面了解数据则需要花费更多的时间。
根据 Redpoint 4 Data Trends to Watch in 2020 中对2020年大数据趋势的观察和预测：1）数据质量、 2）数据目录、3）KPI的可观察性、4）流式传输将成为或已经成为2020年大数据的几大关注对象。其中的数据目录，根据Alation的说法，就是“元数据的集合，结合了数据管理和搜索工具，帮助数据分析师和数据用户找到所需的数据，并提供可靠的评估信息。” 数据目录充当可用数据的清单，并提供信息以评估适用数据的预期用途，通过捕获相关数据的丰富信息，包括其应用程序上下文、行为数据、更改信息及数据访问信息等，支持自助数据访问，使分析师可以避免与IT部门合作来接收数据的缓慢过程，自行发现相关数据，从而提高了生产率。Redpoint此处提到的数据目录（Data Catalog）就是提供访问和理解数据上下文的途径，实现数据360°全局全生命周期了解与掌握的解决方案。
硅谷数据目录起源
虽然硅谷没有“数据中台”的说法，但是在很多硅谷公司的数据平台建设过程中，数据驱动的理念已深深嵌入其文化基因。大家并没有刻意去打造什么中台，但是“避免重复造轮子”、“快速迭代”、“数据驱动”、“业务驱动”是硅谷工程师文化的一些核心概念， 也是硅谷高效创新的一个核心。
随着数据成指数级增长流入，处理数据的系统复杂度也不断增加 ，各大硅谷公司在生产中碰到的问题也是惊人的类似。对数据流水线内部数据 360° 流转透视图的需求也随之而来且越来越旺盛。同时，随着机器学习的发展，对使用训练和测试数据集的生命周期管理自动化的工具和平台的需求变得越来越重要。有点自相矛盾的是，机器学习框架的发展速度比相应的数据管理工具集快了几个数量级。结合深度学习领域的最新研究发展了数十个高质量的开发框架，而用于管理支持机器学习模型的数据集生命周期的平台仍处于起步阶段。为了解决这一挑战，实现基于数据流水线的机器学习反哺数据处理能力，Uber 或 LinkedIn 等快速发展的技术公司开始构建自己的内部数据生命周期管理解决方案。由于元数据贯穿大数据平台数据流动的全过程，硅谷各大企业的注意力再次转到对元数据管理，不过此时，是对系统内元数据的全域多维管理。而此时的数据管理，需要回答以下5W1H的问题，包含但不限于：
数据目录正是硅谷各大公司在应对遇到的类似问题和困难时应运而生的，旨在对数据进行统一的搜索、发现、跟踪和管理批处理应用程序和数据集的分析等等，从而把数据在数据管道中的流转全局透明化，在透明化的过程中，随时可以回答上表5W1H的问题。对数据流转如此细颗粒度的全局掌握的实现，自然少不了方法论的支撑。
DataOps方法论
数据目录的实现建立在提取和显示所有元数据的基础上，自动提供数据上下文。因此，实现对系统内元数据的全域多维管理，就是实现数据的全生命周期管理，需要先实现数据的快速、通畅的流转。DataOps这种面向流程的自动化方法，旨在提高数据分析质量并缩短数据分析的周期时间，能大大降低数据分析的门槛，高效解决数据在流转的各个环节遇到的困难。因此，企业进入数据管理及应用阶段后，离不开DataOps这个关键方法论的帮助。
我们在深入DataOps：现代数据流水线的精髓和大浪淘沙后DataOps依旧中对DataOps进行过介绍。DataOps自2018年首次在Gartner的数据管理技术成熟度曲线报告中被提出后，得到硅谷各大公司的普遍应用和验证。而也正是对DataOps的广泛应用，硅谷的数据目录建设如雨后春笋般涌现。
图1：数据目录概览
硅谷的数据目录建设
下面我们将对硅谷几大主要数据目录解决方案进行介绍：
DAL/EagleEye - Twitter
随着数据源、数据量的不断增加，数据集的产生、消费及其在整个数据生命周期内的一致性 管理，成为 Twitter 进入数据管理及应用阶段面临的最大挑战，如何对所有数据操作进行 统一管理，推动 Twitter 数据平台团队开发了数据访问层（Data Access Layer (DAL)）， 并结合 EagleEye（搜索、发现、跟踪和管理批处理应用程序和分析数据集的内部 Web UI 工具），成为 Twitter 的数据目录工具。
Twitter EagleEye 旨在方便用户探索数据流水线内数据集的 schema、notes、健康状态、 物理分区及数据所有者等信息。作为 DAL 处理数据的前端可视化展现、探索工具。
DAL 的特征如下：
数据发现：跟踪哪些应用程序产生或使用了哪些数据集，数据集的语义和其它相关的元数 据是什么
数据审计：数据集被谁如何创建，被谁如何消费，数据集的依赖、服务等级协议（SLAs） 及报警规则，数据集间依赖是否一致，数据集的生命周期如何管理
数据抽象：数据的逻辑描述、物理描述，数据存储地址、格式及副本
数据消费：系统内其他大数据组件对数据平台数据集的交互
Data Hub - LinkedIn
LinkedIn 的 Data Hub（元数据搜索和发现工具）的核心重点是自动化收集、搜索及发现与 数据集及其他实体（如机器学习模型、微服务、人员、组等）相关的元数据。
图2：LinkedIn‘s Data Hub架构
具体来说，Data Hub 旨在实现四个特定目标 ：
建模：对所有类型的元数据及其关系进行建模。
获取：通过 API 的 pull 和流数据处理的 push 两种方式，大规模获取元数据变更信息 。
服务：规模化服务所收集的原始元数据和派生的元数据，及针对元数据的各种复杂查询。
索引：规模化索引元数据，并在元数据变更时自动更新索引。
Data Portal - AirBnb
除了数据规模增加的复杂度外，每个数据工具或团队都提供其数据范围内的局部视图，导致 数据通常通过与工具和团队而被隔离。那么，如何在数据质量参差不齐，数据复杂度、相关 性和可信度等标准不一的情况下对海量数据进行高效导航？AirBnb 的 Dataportal（数据资 源搜索、发现工具）希望将从对单个数据源的思考转变为集成数据空间的概念；数据空间提 供了数据的整体视图，提供了必要的数据背景信息。因此，任何员工，无论其角色如何，都 可以轻松地查找或发现数据，并对数据的可信度和相关性充满信心。从透明性的角度，通过 提供尽可能多的数据语境，并观察每个工具对基础数据的访问控制，将单个镜头放到数据空间中。
图3：AirBnb的Data Portal图示
在 Data Portal 模型中，知道谁生产或消费了数据与数据本身一样有价值。数据间的关系节点在孤立的数据组件与理解整个数据空间的能力之间提供了必要的联系。没有上下文的数 据通常毫无意义，可能导致错误的信息和昂贵的决策。因此，Dataportal 在内容页面显示 了跨数据获取资源所需的所有信息，如：谁消耗了资源，谁创造了资源，何时创建或更新了 资源，及与之相关的其他资源等。更多的元数据意味着更多的数据信息。对于数据表（任何 数据仓库的基础）尤其如此。而 Data Portal 的数据生态系统图示所提供的价值，还远不 止跨功能信息追踪数据血缘。
Amundsen - Lyft
随着 Lyft 的发展，寻找相关数据源变得越来越重要，但随着数据格局变得越来越零散、复 杂和孤立，这也成为 Lyft 的在大数据项目发展当前阶段中遇到的最大挑战之一。因此，如 何将数据发现大众化，从而快速从多源异构数据源中找到所需的数据源，将不同的数据资源 与人关联，将丰富的元数据与数据资源关联，使用图模型进行数据建模来处理实体（点）和 关系（边）之间的关系，成为 Amundsen 的追求目标和落地方案。
图 4：Amundsen 架构图
Amundsen 采用微服务架构，由五个主要组件组成：
元数据服务：提供有关数据源的元数据，处理来自前端服务以及其他微服务的元数据请求 。该服务可以配置 Apache Atlas（元数据引擎）。Amundsen 将元数据实体建模为一个图 ，在引入更多实体时可以方便地扩展模型。Lyft 目前使用 Neo4j 社区版本 3.3.5 来承 载元数据。我们每四个小时将 Neo4j 图备份到 Amazon S3 中。
搜索服务：Amundsen 的搜索服务提供 API，用于将资源编入搜索引擎中，并满足来自前 端服务的搜索请求。搜索服务集成 ElasticSearch 6.x，但也可以集成 Apache Atlas， 提供与 Solr 类似的搜索功能，处理来自前端服务的搜索请求。
前端服务：Amundsen 的前端应用程序是高度可配置的。通过功能标记和各种配置变量来 适配不同组织的独特需求。前端服务托管 Amundsen 的网络应用程序。
数据生成器: 一个通用的数据提取框架，可从各种来源提取元数据。ETL 有相应的组件 ，即提取，转换和加载，用于处理记录级操作。在 Lyft，使用 Apache Airflow 作为数 据生成器的编排引擎。
Common 是一个代码库分支，存储 Amundsen 的所有微服务的通用代码。
DataBook - Uber
随着业务的快速发展，复杂系统和海量数据（每天处理数万亿个 Kafka 消息，在多个数据 中心存储数百 TB 的 HDFS 数据，并支持每周数百万个分析查询），指数级增长的业务（和 数据）并不足以直接产生商业洞见。快速增长变化的数据，需要一种更简单、更快捷的方式 来更新这些信息。Uber Databook 的开发，帮助 Uber 员工更容易发现和探索数据集 。Databook 元数据让 Uber 的工程师、数据科学家和运营团队从原先的查看原始数据转变 为现在的掌握可操作信息。
Databook 有以下几大特征：
可扩展性：易于添加新的元数据、存储和实体
可访问性：服务可以以编程的方式访问所有元数据
可伸缩性：支持高吞吐量读取
其他：跨数据中心读写（WhereHows 缺乏对跨数据中心读写）
图 5：Databook 架构图
支持的元数据数据源：Hive、Vertica、MySQL、Postgres、Cassandra 和其他几种内部存储 系统的元数据。
Databook 提供元数据采集、存储、搜索。Databook 可以捕获关键的元数据变更，如数据集 lineage 和新鲜度。除了近乎实时地轮询和收集元数据之外，Databook UI 还收集来自数据 集消费者和生产者的语义信息，例如对表和列的描述。Databook 将多个源作为输入，存储 相关元数据，并通过 RESTful API 输出这些信息。
搜索是 Databook UI 的一项重要功能，用户能轻松访问和浏览表的元数据，进行跨维度搜 索，如名称、所有者、列和嵌套列。Databook 使用 Elasticsearch 作为全索引搜索引擎 ，Elasticsearch 从 Cassandra 同步数据。
Databook 利用机器学习模型生成数据洞见，以及创建高级的问题检测、预防和缓解机制。
MeatCat - Netflix
Netflix 的数据仓库由存储在 Amazon S3（通过 Hive），Druid， Elasticsearch，Redshift，Snowflake 和 MySql 的大量数据集组成。平台支持 Spark，Presto，Pig 和 Hive 来使用、处理和生成数据集。然而，在多数据源情况下，如 何确保数据平台可以作为一个“单一”数据仓库跨数据集进行互操作，为此，Netflix 构建了 Metacat。
Netflix 开始构建大数据平台时，采用 Pig 作为 ETL 语言，采用 Hive 作为临时查询语言。由于 Pig 本身没有元数据系统，因此，构建一个可以在两者之间互操作的系统似乎是理 想的选择。Metacat 也随之诞生，该系统提供支持所有数据存储的联合元数据访问层。各 种计算引擎可以用来访问不同数据集的集中式服务。
图 6：Metacat 架构图
Metacat 的三个主要实现目标：
元数据系统的统一视图
相关数据集的元数据的统一 API
数据集的任意业务和用户元数据存储
Metacat 的主要功能包括：数据抽象和互操作性，业务和用户定义的元数据存储，数据发现 ，数据变更审计及通知及 Hive Metastore 优化，从而提供提供有关数据血缘的上下文信息 和可插拔元数据验证。
Superglue - Intuit
数据管道血缘的复杂性直接影响数据分析师和数据科学家的生产率。监控、调试现有管道和 创建新管道的能力，是生产力的关键指标。理想的工具应该能够通过解析异构语言（如 Python，SQL，Hive 等）编写的数据管道 ETL 脚本来自动提取血缘。SuperGlue 的开发， 提供了一种可无缝跟踪复杂生产流水线血缘的工具，使其能够自动为分析师、数据科学家、 工程师进行数据流水线的解释、调试和迭代。
图7：Intuit’s Superglue图示
SuperGlue 提供的视图包括：
整体视图，将流水线血缘与运行时执行的统计信息结合，包括调度程序计时、数据质量、 脚本中的更改跟踪等。
血缘视图：显示指定表、作业、报表的上下游血缘关系及数据流水线 job 的血缘关系
执行视图：显示与作业和表关联的运行时详细信息，包括数据质量问题和更改追踪视图。 用户可以在血缘视图交互中高亮显示任何元素，并进行执行。
WeWork Marquez
在 WeWork，了解所有数据集的完整上下游关系及探索作业与其产生和使用的数据集之间的 依赖关系至关重要。为此，WeWork 开发了 Marquez，用于收集、聚合和可视化数据生态系 统元数据的核心服务。Marquez 维护着如何使用和生成数据集的出处，同时提供了作业运 行时的全局可见。
图8：WeWork‘s Marquez图示
Marquez 特征：
集中式元数据管理支持，包括：数据血缘、数据治理、数据健康检查、数据发现+探索
精确的高维度数据模型，包括：作业、数据集
通过指定的元数据 API 轻松收集元数据
以最小的依赖进行简单的操作和设计
RESTful API 支持与其他系统的复杂集成，如 Airflow、Amundsen 及 Dagster 等
Google Data Catalog
Data Catalog（可扩缩的全托管式元数据管理服务，为Google Cloud 所有元数据提供了一个中央目录系统）提供了一个集中的位置，组织可在此查找、挑选和描述其数据资源。可以通过两种主要方式与 Data Catalog 互动：搜索有访问权限的数据资源；使用元数据标记资源。
此外，Data Catalog 还可与 Cloud Data Loss Prevention (DLP) 互动，通过 Cloud Data Loss Prevention 强大的自动标记机制自动识别敏感数据。
Data Catalog 不会将数据资源中的数据编入索引。Data Catalog 会将用于描述资源的元数据编入索引。Data Catalog 可控制某些元数据（例如，用户生成的标记），但对于源自底层存储系统的所有元数据来说，Data Catalog 是一种只读服务，反映了底层存储系统提供的元数据和权限。对于资源的原生元数据，其添加、移除或更新等修改操作均可在底层存储系统中完成。
图9：Google’s Data Catalog
Data Catalog 特性：
无服务器：可扩缩的全托管式元数据管理服务
元数据即服务：使用自定义 API 和界面对数据资产进行编目，集中查看任何数据
集中式目录：自动捕获技术元数据并利用标记以结构化格式捕获业务元数据
搜索和发现：与 Gmail 和云端硬盘使用相同的 Google 搜索技术，快速查找数据资产
结构化元数据：支持架构化标记（例如 Enum、Bool、DateTime）而不仅仅是简单的文本标记
Cloud DLP集成：发现敏感数据并对其进行分类，简化数据治理
Cloud IAM集成：提供访问权限级别控制功能，在对数据资产进行读取、写入和搜索时遵循源 ACL
治理：集成了 Cloud DLP 和 Cloud IAM，提供安全性和合规性基础
Apache Atlas
在以往的元数据管理系统中，各类建模工具与数据集成工具并存，各自独立，且遵循的标准也不尽相同。给元数据收集、交互与管理带来诸多问题。因此，定义统一的元数据标准，建立集中的元数据库有着重要意义。而Atlas Atlas最初就是为这一目的而设计的。
Atlas实现了对于Hadoop生态系统的可视化，通过使用内置的连接器与Hadoop组件进行连接，提供专业且易于操作的跟踪功能，可跟踪丰富且多样的商业分类元数据。
图10：Apache Atlas架构
Apache Atlas 的特点之一是实时数据血缘采集
血缘采集，一般可以通过三种方式：
通过静态解析 SQL，获得输入表和输出表；（面临准确性的问题）
通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；（atlas采用的是这种方式）
通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。（可确保准确性，但实时性差）
对于需要元数据驱动的企业级Hadoop系统来说，Apache Atlas提供了可扩展的管理方式，且能够方便地支持对新的商业流程和数据资产进行建模。其内置的类型系统允许Atlas与Hadoop大数据生态系统之内或之外的各种大数据组件进行元数据交换。
Select Star
Select Star 公司的 Select Star 是基于数据目录的智能数据发现平台（SaaS产品），通过连接数据仓库商业智能公交，自动在数据仓库的上下文中构建元数据，自动检测并显示数据表、列级血缘，快速定位、查找字段。提供数据全文搜索，快速定位查找数据，查看最受程序欢迎（被查询、使用最多）的数据列。
数据目录的社交属性
除了上面提到到硅谷各大公司的数据目录解决方案的架构和特征介绍外，它们之间有个共同的特征是它的社交属性。
如 DAL/EagleEye 提供的数据资源管理中 “Discover Data Sources”模块能发现使用过的数据集，或者搜索感兴趣的数据集，并将查询结果以预览的方式进行展示。同时，用户可对特 殊字段添加的评论。
Dataportal 的员工中心数据和团队中心数据的设计，也在试图建立基于元数据的社交网络 。在员工中心数据中，员工是部落知识的最终拥有者，Dataportal 整合了员工创建、使用 或收藏的所有数据资源，公司中的任何员工都可以查看任何其他员工的页面，从生产和消费 的角度提高了透明度。在 Dataportal 的团队中心数据设计中， 团队拥有查询的表、创建 和查看的仪表板，跟踪的团队指标等。
Amundsen 在用户和数据资源之间建立关系，通过暴露这些关系来共享部落知识。用户与资 源之间的关系分为三种类型：已关注、已拥有和已使用。通过公开此信息，经验丰富的用户 将自己成为其团队中其他成员以及具有类似职务的其他员工的有用数据资源。例如，新员工 可以访问 Amundsen 并搜索其团队中经验丰富的用户，或进行类似分析的其他员工。然后， 新员工将能够查看他们可以考虑更深入地研究哪些资源，或者与该人联系以获取更多指导。 为了使这些部落知识更容易找到，我们还在内部员工目录的个人资料页面上添加了一个链接 ，它可以链接到每个用户的 Amundsen 个人资料。
Marquez 可以将作业的输入、输出数据集整理到搜索引擎，并基于用户点赞，添加的描述等 内容进行索引和排名，从而增加搜索数据集结果准确性。
在利用社交属性的同时，通过社交属性发展的功能所生成的数据本身，也成为了元数据数据源的一部分，反哺数据目录的 360° 全视角透视的完整数据生命周期管理。
数据目录应用的自助及协同工作
作为数据目录核心的元数据管理发展到集中阶段后，必然的会发展成为具体自助和协同工作 属性的服务。而数据目录的自助和协同工作属性最终实现的目的，总体可以概况为：元数据管理更自助，通过对元数据全生命周期的链路管理，元数据变更可看、可查、可追溯、可共享。
如 Dataportal 通过提供尽可能多的数据语境，并观察每个工具对基础数据的访问控制，将 单个镜头放到数据空间中。一个元数据的变更，在数据空间中，能牵出此变更元数据相关的 所有上下游数据集。
Databook 元数据让 Uber 的工程师、数据科学家和运营团队从原先的查看原始数据转变为 现在的掌握可操作信息。从手动更新转变为利用高级自动化元数据存储来收集各种经常刷新 的元数据。捕获关键的元数据变更，如数据集血缘关系和新鲜度。除了近乎实时地轮询和收 集元数据之外，Databook UI 还收集来自数据集消费者和生产者的语义信息，让元数据比以 往更具可操作性和实用性。
Metacat 作为数据存储的中央网关，可捕获任何元数据更改和数据更新，并围绕表和分区更 改构建了一个推送通知系统。从而将事件发布到数据管道（Keystone）中进行分析，以便更 好地了解数据使用情况和趋势。Metacat 也将数据平台架构发展为事件驱动架构，即将事件 发布到 SNS 允许数据平台中的其他系统对这些元数据或数据更改进行“响应”。例如，当一 个表被删除时，S3 仓库管理员服务可以订阅此事件并适当地清理 S3 上的数据。Metacat 还提供表 schema 和元数据的版本记录提供有关数据血缘的上下文信息，如在 Metacat 中 聚合诸如表访问频率之类的元数据，并将其发布到数据血缘服务，用于对表的重要性进行排 名。同时还可以在大数据目录网站 SQL 编辑器中自动建议和自动完成 SQL。并使用标签根 据组织和主题领域对数据进行分类，来标识用于数据生命周期管理的表。
数据目录方案汇总对比
从以上几大典型的数据目录解决方案中可以看成，各大公司在应对多源异构的大规模数据处理难题时，开发的产品功能、特征大同小异，处理数据所涉及的关系维度包括：用户、数据 、作业、资源等。如下表所示：
元数据管理、数据目录和数据资产管理
Apache Atlas 通过与 Hadoop、Hive 等系统的集成，自动捕捉动态的数据关联关系，提供了大数据元数据管理解决方案/工具。Select Star 则是基于数据仓库自动在数据仓库的上下文中构建元数据，对元数据进行管理。同时，上文已提到，数据目录是元数据的集合，结合了数据管理和搜索工具，通过统一入口，帮助数据分析师和数据用户找到所需的数据，并提供可靠的评估信息，也是实现元数据管理的解决方案/工具，但所管理的元数据范围覆盖数据从产生到消费的整个生命周期。
而数据能成为资产，最重要的就是要明确数据的所有权和使用权。数据在从产生到消费的整个生命周期中，可能被人消费，如：数据的查询、搜索、探索等，或者被程序消费，如：数据加工、处理、转换等，而在数据从产生到消费过程中所占用、消耗的系统资源，也是量化数据资产的重要指标之一。因此，要明确数据的所有权和使用权，量化数据资产的成本与消耗，需要引入业务数据、应用数据及用户数据三个维度的数据，进行数据应用的全生命周期管理。
总结
然而，对数据目录及全局的数据应用管理的需求，首先来自各大硅谷数据前沿公司数据处理人员和数据科学家的内部驱动，而走在前沿的他们，在市场上无法找到能全部满足公司内部多源异构数据的全局掌握的需求，而纷纷自己投产开发相应的数据目录和全局的数据应用管理的产品/应用，从而加速公司数据驱动的进程。
但是为什么硅谷几大公司都没有直接采用/接入开源的Apache Atlas作为解决方案？既然硅谷各大公司遇到的数据问题类似，解决方案也类似，那么，此类问题的解决方案能否被产品化，避免各个公司的重复建设？这些则是读者可以思考的问题。
- FIN -
更多精彩推荐
????欲了解智领云数据中台详情，请点击阅读原文。
878
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
