pb 数据窗口插入数据_100+PB数据分钟级延迟：Uber大数据平台介绍

 点击“蓝字”关注我们

文章来源 | Uber官方博客 

  作者 | Reza Shiftehfar   翻译 | 欧高炎    Uber 致力于在全球市场提供更安全和可靠的交通服务。为实现这一目标， Uber 在各个层面都依靠数据驱动的决策，从高流量事件期间的乘客需求预测到司机签约流程中的瓶颈识别和解决。Uber逐渐需要在基于 Hadoop 的大数据平台上以最低的延迟对超过 100PB 的数据进行清洗、存储和服务，以便获得更丰富的洞察。从 2014 年开始开发大数据解决方案，确保数据可靠性、可扩展性和易用性。如今，Uber专注于提高大数据平台的响应速度和执行效率。    在本文中，将对Uber的Hadoop平台进行全面解析，并讨论Uber下一步如何对这个丰富而复杂的生态系统进行扩展。 第1代：Uber的大数据开始 在2014年之前，Uber拥有的数据量还可以通过传统的联机事务处理过程数据库(例如MySQL和PostgreSQL)来处理。工程师必须单独访问每个数据库或表，通过编写代码来整合不同数据库中的数据。当时，Uber还没有存储的所有数据的全局视图。实际上，Uber的数据分散在不同的OLTP数据库中，总的数据级为若干TB，访问这些数据的延迟非常低(通常是亚分钟级)。下面的图1概述了2014年之前的数据架构。 图1：2014年之前，Uber存储的数据总量较小，可以使用传统OLTP数据库进行管理。没有数据的全局视图，直接查询对应数据库处理数据，数据访问速度很快。   随着Uber的业务呈指数级增长(运营城市/国家数量和乘客/司机数量)，传入数据量也随之增加。在同一个平台处理和分析数据的需求推动我们建立第一代分析数据仓库。为了使Uber尽可能地基于数据驱动来决策，需要确保分析师在同一个地方访问数据。为实现这一目标，首先将数据用户分为以下三大类： 1.    城市运营团队(数千名用户)：这些实地工作人员管理和扩展Uber在每个市场的运输网络。随着Uber的业务扩展到新城市，有成千上万的城市运营团队定期访问这些数据，以响应与司机和乘客相关的问题。 2.    数据科学家和数据分析师(数百名用户)：这些分析师和科学家分布在不同的功能组中，帮助Uber为用户提供最佳的交通工具和乘车体验。例如，预测乘车人需求以提供前瞻性的服务。 3.    工程团队(数百名用户)：整个公司的工程师专注于构建自动数据应用，例如欺诈检测和司机适职平台。 Uber的第一代分析数据仓库专注于将所有数据集中在同一个地方以及统一数据访问。对于前者，Uber决定使用Vertica作为我们的数据仓库软件，因为它快速，可扩展性高和面向列的存储设计。Uber还开发了多个专用的ETL作业从不同的来源(即AWS S3，OLTP数据库，服务日志等)将数据复制到Vertica中。为了实现后者，Uber将SQL确定为我们的标准化接口，并构建了一个在线查询服务来接受用户查询并将它们提交给底层查询引擎。图2描述了这个分析数据仓库： 图2：Uber第一代大数据平台将数据集中到一起并提供标准的SQL接口来访问数据。   第一代数据仓库服务的发布对整个公司的工程师来说都是一个巨大的成功。用户第一次拥有全局视图，可以在一个地方访问所有数据。大量新团队使用数据分析作为其技术和产品决策的基础。在几个月内，Uber的分析数据量增长到数十TB，用户数量增加到数百。 使用SQL作为简单的标准接口，让城市运营者能够轻松地与数据交互，而无需了解底层技术。此外，不同的工程团队开始针对用户需求构建基于数据的服务和产品(例如uberPool，前期定价等)提供信息。Uber也组建了新的团队以更好地使用和提供这些数据(例如我们的机器学习和实验团队)。 局限性 另一方面，Uber对数据仓库和接入数据的广泛使用也暴露出一些局限性。由于数据是通过专用ETL作业提取的，因而缺乏正式的模式通信机制，因此数据可靠性成为一个问题。Uber的大多数源数据都是 JSON格式 ，并且数据提取作业对生产者代码的更改没有弹性。 随着公司的发展，扩展数据仓库的代价越来越昂贵。为了降低成本，Uber开始删除旧的和过时的数据，以释放空间存储新数据。其次，Uber的大数据平台大部分无法进行水平扩展。这是因为平台的主要目标是为关键业务解决集中数据访问或查询的需求，根本没有足够的时间来确保平台的所有部分都是水平可扩展的。Uber的数据仓库实际上被用作数据湖，堆积所有原始数据以及执行所有数据建模和服务数据。 此外，由于生成数据的服务与下游数据消费者之间缺乏正式的约定，将输入导入数据仓库的ETL作业也非常脆弱(使用灵活的JSON格式导致源数据缺少模式保证)。相同的数据可能会被提取多次，如果用户在提取数据时对数据进行了不同的转换。这对我们的上游数据源(即在线数据存储)造成了额外的压力，并对服务质量产生负面影响。此外，这导致数据仓库需要存储几乎相同的数据的多个副本，进一步增加了存储代价。因为ETL作业是专用和源依赖的，且会对数据进行映射和转换，一旦数据质量存在问题，回填会非常耗时耗力。由于数据提取工作缺乏标准化，因此很难提取新的数据集和类型。 第2代：Hadoop的到来 为了突破这些局限性，Uber围绕Hadoop生态系统重构了大数据平台。更具体地说，我们引入了一个Hadoop数据湖，原始数据仅从在线数据存储中提取一次，并且在提取期间没有转换。这种设计转变显着降低了在线数据存储的压力，Uber能够从专用提取作业转变为可扩展的提取平台。为了让用户能够访问Hadoop中的数据，引入了Presto来实现交互式用户专用查询。Apache Spark提供原始数据(同时支持SQL和non-SQL格式)的编程访问，Apache Hive用来支持超大查询任务。用户可以根据其需要来选择最合适的查询引擎，平台变得更加灵活和易于访问。 为了保持平台的高可扩展性，确保所有数据建模和转换仅在Hadoop中进行，从而在出现问题时实现快速回填和恢复。只有最关键的建模表(即城市运营者实时利用这些表来运行纯粹快速的SQL查询)才被转移到我们的数据仓库。这大大降低了运行数据仓库的运营成本，同时还将用户引导到基于Hadoop的查询引擎，这些查询引擎的设计考虑了他们的特定需求。 Uber还利用了Apache Parquet的标准列式文件格式，通过提供列式访问和分析查询，提高了压缩率和计算资源收益，从而节省了存储空间。此外，Parquet与Apache Spark的无缝集成使该解决方案成为访问Hadoop数据的流行选择。图3总结了第二代大数据平台的架构： 图3：第二代大数据平台利用Hadoop实现水平扩展。结合Parquet，Spark和Hive等技术，提供数十PB数据的提取、存储和服务。   除了引入Hadoop数据湖之外，该生态系统中所有数据服务都可以水平扩展，从而提高了Uber的大数据平台的效率和稳定性。这种通用的水平可扩展性可以满足直接的业务需求，使Uber能够集中精力构建不仅仅支持特定问题的下一代数据平台。 Uber的第一代大数据平台容易受上游数据格式更改的影响，第二代大数据平台允许对所有数据进行模式化。从JSON过渡到Parquet，将数据模式和数据同时存储。为此，Uber构建了一个中央模式服务来支持模式收集、存储和服务。同时提供不同的客户端库将不同的服务集成到此中央模式服务中。脆弱的专用数据提取作业被替换为标准平台，将原始嵌套格式源数据传输到Hadoop数据湖中。对数据的所有操作和转换都在数据提取后，通过Hadoop平台上的水平可扩展的批作业来完成。 随着Uber的业务持续快速发展，Uber很快就拥有了数十PB的数据。每天都有数十TB的新数据被添加到数据湖中，大数据平台增长到超过10,000个vcores，每天运行的批处理作业超过100,000个。Hadoop数据湖成为所有分析Uber数据的核心事实来源。 局限性 随着公司不断扩展，Uber的生态系统中存储了数十PB的数据，Uber又面临着一系列新的挑战。 首先，存储在HDFS文件系统中的大量小文件(由于更多数据被提取以及更多用户编写的专用批处理作业生成更多的输出数据)给HDFS的名字节点(NameNode)带来增加额外的压力。此外，数据延迟仍然远远无法满足业务需求。用户只能每24小时访问一次新数据，这对于实时决策来说太慢了。将ETL和建模转移到Hadoop使得这个过程更具可扩展性，但依然存在瓶颈，因为ETL作业在每次运行中重新创建整个建模表。除此之外，新数据的提取和相关派生表的建模都基于创建整个数据集的新快照并交换旧表和新表以向用户提供对新数据的访问。提取作业必须返回源数据存储区，创建新快照，并在每次运行期间将整个数据集提取或转换为列式的Parquet文件。随着数据存储量的增长，在1000个节点的Spark集群上，这些作业可能需要超过20个小时才能运行完成。 每个作业的大部分工作在从最新快照中转换历史数据和新数据。虽然每个表每天只添加100GB左右的新数据，但提取作业都必须转换整个100 TB的数据表。对于在每次运行中重新创建新派生表的ETL和建模作业也是如此。这些作业必须依赖基于快照的源数据提取，因为历史数据的更新比例很高。从本质上讲，我们的数据包含许多更新操作(例如乘客和司机评分或支持订单完成的数小时或数天内的票价调整)。由于HDFS和Parquet不支持数据更新，提取作业需要从更新的源数据创建新快照、将新快照存到Hadoop、转换成Parquet格式、交换输出表以查看新数据。图4总结了这些基于快照的数据如何通过我们的大数据平台移动： 图4：虽然Hadoop支持PB级的数据存储，新数据的延迟仍然超过一天，这是由于基于快照的大型上游源表提取需要花费数小时来处理。 第3代：为长期计划重建Uber的大数据平台 到2017年初，Uber的大数据平台被整个公司的工程和运营团队使用，使他们能够在同一个地方访问新数据和历史数据。用户可以通过同一个UI门户轻松访问Hive， Presto， Spark， Vertica， Notebook等平台中的数据。Uber的计算集群中有超过100 PB的数据和100000个vcores。每天支持100,000个Presto查询， 10,000个Spark作业，以及 20,000个Hive查询。Uber的Hadoop分析架构遇到了可扩展性限制，许多服务受到高数据延迟的影响。 幸运的是，Uber的底层基础架构可以水平扩展以满足当前的业务需求。因此有足够的时间研究数据内容，数据访问模式和用户特定需求，以便在构建下一代之前确定最紧迫的问题。研究揭示了四个主要的痛点： 1.    HDFS可扩展性限制：许多依赖HDFS扩展其大数据基础架构的公司都面临着这个问题。根据设计，NameNode容量是HDFS的瓶颈，因此存储大量小文件会显著影响性能。当数据量超过10PB时这种影响会发生；当数据量超过50-100PB时，问题会十分严重。有一些相对简单的解决方案可以将HDFS从几十PB扩展到几百PB，例如利用ViewFS和使用HDFS NameNode 联盟。通过控制小文件的数量并将数据的不同部分移动到单独的集群(例如HBase和Yarn应用程序日志移动到单独的HDFS集群中)，能够减轻此HDFS限制。 2.    Hadoop中更快的数据：Uber的业务实时运营，因此，Uber的服务需要访问尽可能新鲜的数据。因此，对于许多用例而24小时的数据延迟太慢了，因此对更快的数据传输存在巨大需求。Uber的第二代大数据平台中的基于快照的提取方法效率低下，无法以较低的延迟提取数据。为了加快数据分发速度，不得不重新设计流水线，以便增量提取更新数据和新数据。 3.    Hadoop和Parquet中的更新和删除支持：Uber的数据包含很多更新，从数天(例如乘客或司机调整最近行程价格)到数周(乘客对上一次行程进行评分)甚至数月(由于业务需要的数据回填和历史数据更新)。在基于快照的数据提取中，每24小时提取一次源数据的新副本。换句话说，Uber一次提取所有更新，每天进行一次。但是，由于需要更新的数据和增量提取，解决方案必须能够支持现有数据的更新和删除操作。但是，由于大数据存储在HDFS和Parquet中，因此无法直接支持对现有数据的更新操作。另一方面，数据包含非常宽的表(大约1000列的表)，用户查询中往往包含5层或以上的嵌套查询，这些查询只涉及宽表中的少数列。这让Uber很难高效处理非列式格式数据。为了使大数据平台应对长期的数据增长，必须找到一种方法来解决HDFS文件系统中的这种限制，以便可以支持更新/删除操作。 4.    更快的ETL和建模：与原始数据提取类似，ETL和建模作业都是基于快照的，使得Uber的平台在每次运行中都要重建派生表。为减少建模表的数据延迟，ETL作业也需要支持增量操作。这要求ETL作业逐步从原始源表中提取已更改的数据，并更新先前派生的输出表，而不是每隔几小时重建整个输出表。 介绍Hudi 为了满足上述要求(突破HDFS水平扩展限制、加快Hadoop数据处理速度、在Hadoop和Parquet中支持数据更新和删除、实现更快的ETL和建模)，Uber构建Hudi(HadoopUpserts and Incremental)。Hudi是一个开源Spark库，在HDFS和Parquet之上提供一个抽象层来支持更新和删除操作。Hudi可以在任何Spark作业中使用，可以水平扩展，并且其运行只依赖于HDFS。因此，Hudi可以对任意大数据平台进行扩展，以支持对历史数据的更新和删除操作。 Hudi使Uber能够在Hadoop中更新、插入和删除现有的Parquet数据。此外，Hudi允许数据用户增量地提取更新的数据，显著提升了查询性能，同时支持对派生建模表的增量更新。 Uber的Hadoop生态系统中的原始数据是根据时间划分的，任何旧分区都可能在以后接收更新请求。因此，对于依赖于这些原始源数据表的数据用户或ETL作业，了解哪个日期分区包含更新数据的唯一方法是扫描整个源表并根据已有知识来过滤数据。更加麻烦的是，这些计算代价昂贵的查询操作的运行频率还非常高。 有了Hudi，用户可以简单地传递最近检查点时间戳，并检索该时间戳之后更新的数据，而无需运行扫描整个源表的昂贵查询。更新的数据包括添加到最近日期分区的新记录和对旧数据的更新(例如，今天发生的新行程和对6个月前某个行程数据的更改)。 使用Hudi库，Uber的数据提取模式从基于源数据快照的模式转换到增量的提取的模式，数据延迟从24小时减少到不到1小时。图5描述了集成了Hudi的大数据平台： 图5：第三代大数据平台采取了更快的增量数据提取模式(使用开源Marmaray框架)和更高效的存储和数据服务(使用开源Hudi库)。 通用数据提取 Hudi并不是Uber第三代大数据平台的唯一补充。Uber还通过ApacheKafka处理存储和大数据团队之间对上游数据库的更改。上游数据库事件(以及不同应用和服务的传统日志消息)使用统一的Avro编码(包括标准的全局源数据头信息，例如时间戳、行键、版本、数据中心信息和发起主机)流入Kafka。Streaming团队和大数据团队都使用这些存储更改日志事件作为其源输入数据以进行进一步处理。 Uber的数据提取平台Marmaray以小批量运行并从Kafka提取上游存储更改日志，使用Hudi库在Hadoop的现有数据上执行更改。前面已经提到，Hudi支持upsert操作，允许用户添加新记录并更新或删除历史数据。Spark上的提取作业每10-15分钟运行一次，Hadoop中原始数据延迟约为30分钟(考虑到1-2个提取作业失败或者重启)。为避免因多次将相同的源数据提取到Hadoop而导致效率低下，禁止在提取期间对数据进行任何转换。Uber的原始数据提取框架实际上成了EL平台，而不是传统的ETL平台。在此模型下，鼓励用户在上游数据以其原始嵌套格式到达后，在Hadoop中以批处理的模式进行转换操作。 自从 对Uber的大 数据平台实施这些更改以来，由于避免了不必要和低效的提取操作，我们节省了大量的计算资源。因为现在可以避免在提取过程中易于出错的转换，原始数据的可靠性也得到了显著提高。现在，用户可以在原始源数据的上层通过任何大数据引擎进行数据转换。此外，如果出现任何问题，用户可以重新运行其转换。同时可以通过使用更多计算资源和更高的程度并行性来更快地完成批转换作业，以满足用户服务协议。  增量数据建模 考虑到需要从上游数据存储中提取大量数据进Hadoop(截至2017年超过3,000个原始Hadoop表)， Uber还构 建了一个通用提取平台。在这个平台中，以统一和可配置的方式将原始数据提取到Hadoop中。大数据平台增量地更新Hadoop表，能够快速地访问源数据(数据延迟为10-15分钟)。但是，为了确保建模表也具有低延迟，必须避免建模的ETL作业中的低效操作(例如完全派生表复制或完整扫描原始数据数据表)。实际上，Hudi允许ETL作业仅从原始表中提取已更改的数据。建模作业仅仅需要在每一步迭代运行过程中给Hudi传入一个检查点时间戳，就可以从原始表中获取新的或更新的数据流(不用管日期分区数据实际存储在哪里)。 在ETL作业中使用Hudi写入器(Hudi Writer)，可以直接在派生建模表直接对旧分区和表进行更新，而无需重新创建整个分区或表。因此，建模ETL作业使用Hudi读取器增量地从源表中提取已更改的数据，并使用Hudi写入器增量地更新派生的输出表。现在，ETL作业可以在30分钟内完成，Hadoop中的所有派生表都仅有1小时以内的端到端延迟。 为了向Hadoop表的数据用户提供访问所有数据/新数据/更新数据的多种选项，使用Hudi存储格式的Hadoop原始表提供了两种不同的读取模式： 1.    最新模式视图。提供特定时间点Hadoop表的整体视图。此视图包括所有记录的最新合并值以及表中的所有现有记录。 2.    增量模式视图。从特定Hadoop表中提取给定时间戳以后的新记录和更新记录。此视图仅返回自最近检查点以来最近插入或已更新的行。此外，如果特定行自上一个检查点以来被多次更新，则此模式将返回所有这些中间更改的值(而不是仅返回最新的合并行) 图6描述了所有以Hudi文件格式存储的Hadoop表的这两个读取视图： 图6：通过Hudi写入器更新的原始表有两种不同的读取模式：最新模式视图返回所有记录的最新值；增量模式视图仅返回自上次读取后更新的记录。   用户通常根据需要在这两种表视图之间进行切换。使用专用查询基于最新状态分析数据时，他们会采用最新模式视图(例如提取美国每个城市的每周总旅行次数)。另一方面，当用户有一个迭代作业或查询仅仅需要获取自上次执行后的更新数据或新数据时，他们会使用增量模式视图。对于所有的Hadoop表，上面两种视图都是随时可用的，用户可以根据需要在两种模式之间进行切换。 标准化数据模型 除了提供同一个表的不同视图外，Uber还对数据模型进行了标准化。对所有原始Hadoop数据，提供以下两种类型的表： 1.    更改日志历史记录表。包含为特定上游表收到的所有更改日志的历史记录。此表使用户能够扫描给定表的更改历史记录，并且可以按键合并以提供每行的最新值。 2.    合并快照表。包含上游表的最新合并视图。此表包含每一个键接受的所有历史更改日志的压缩合并视图。 图7描述了如何使用给定更改日志流为特定上游源数据生成不同的Hive原始表： 图7：对Hive数据模型的标准化大大改善了整个大数据生态系统的数据质量。此模型包含一个合并的快照表，其中包含每个row_key的最新值和每个row_key的历史变更记录。  然而，更新日志流可能不包含给定键的整个行(所有列)。虽然合并的快照表始终提供特定键的所有列，更新日志历史表则可能是稀疏的，因此可以通过避免发送整行来提高效率。如果用户希望从更新日志历史记录表中提取更改的值并将其与合并的快照表连接以创建完整的数据行，还会在更新日志历史记录表中的合并快照表中包含相同键的日期分区。 图8显示了Uber的大数据平台的不同组件之间的关系： 图8：构建更具可扩展性的数据传输平台使我们能够在一种服务下以标准方式轻松聚合所有数据流水线，并支持数据源和数据接收器之间的多对多连接。  第4代：下一步是什么？ 自2017年推出第三代大数据平台以来，整个公司的用户可以快速可靠地访问Hadoop中的数据。但是依然还有进一步提升的空间。下面介绍一下在改进Uber的大数据平台方 面Uber正在 做的努力，包括提高数据质量、降低数据延迟、提高效率、增强可扩展性和提高可靠性。 数据质量 为了提高数据质量，Uber确定了两个关键的改进方向。首先，尽量避免非模式确认的数据。例如如果某些上游数据仓库在存储之前没有强制执行或检查数据模式时(例如存储值为JSON块的键值对)，导致不良数据进入Hadoop生态系统，从而影响所有依赖此数据的下游用户。为了防止不良数据的涌入，我们正在将对上游数据内容执行强制性模式检查，并在数据存在任何问题(例如未经过模式确认)时拒绝数据记录。 第二个方向是改善数据内容本身的质量。使用模式检查能确保数据包含正确的数据类型，但它们不检查实际数据值(例如整数而不是[0,150]之间的正数)。为了提高数据质量，Uber正在扩展其架构服务以支持语义检查。这些语义检查(Uber特定的数据类型)允许Uber在基本结构类型检查之外对数据内容添加额外约束。 数据延迟 Uber的目标是将Hadoop中的原始数据延迟减少到五分钟以内，将建模表的数据延迟减少到十分钟以内。这将允许更多用例从流处理转向使用Hudi的增量数据拉取进行更高效的小批量处理。 Uber还在扩展Hudi项目，以支持其他视图模式，包括现有的读取优化视图，以及新的实时视图(分钟级别的数据延迟)。这个实时视图依赖于我们的的开源解决方案(Hudi的一部分)，称之 为Merge-On-Read或 Hudi 2.0。 数据效率 为了提高数据效率， Uber 正在努力避免我们的服务依赖于专用硬件，且将服务尽量docker化。此外，Uber统一了Hadoop生态系统内部和外部的资源调度，以尽量桥接公司的Hadoop和非数据服务之间的鸿沟。这允许所有作业和服务以统一的方式进行调度，而不用管它们具体在什么媒介上运行。随着Uber的发展，数据本地化将成为Hadoop应用的一大问题，成功的统一资源管理器可以将所有现有的调度程序集中在一起(例如Yarn、Mesos和Myriad)。 可扩展性和可靠性 作为改善平台可扩展性和可靠性的努力的一部分，Uber确定了几个极端的情况下的问题。虽然数据提取平台是以通用可插拔的模式开发的，实际上游数据提取仍然包括许多依赖于源的流水线配置。这使得提取流水线变得脆弱且提高了运营成千上万这类流水线的维护成本。 为了确保对任意数据源的统一提取， Uber大数据团队和数据存储团队合作启动了一个项目，以统一所有上游数据源更新日志的内容、格式和元数据，而不管其具体技术架构。该项目将确保与这些特定上游技术相关的信息只是作为额外的元数据被添加到实际更新日志值中(而不用针对不同的数据源设计完全不同的更新日志内容)。无论上游源是什么，都可以统一进行数据提取。 Uber的Hudi的新版本将允许数分钟内为所有数据源生成更大的Parquet文件(从当前的128MB提高到1GB)。它还将消除当前版本对更新与插入比率的敏感性。Hudi 1.0依赖于一种名为copy-on-write的技术，只要有更新的记录，它就会重写整个源Parquet文件。这显著增加了写入放大，特别是当更新与插入的比率增加时。并且妨碍了在HDFS中创建大的Parquet文件。Hudi的新版本正在克服上述限制。具体方法是将更新的记录存储在单独的增量文件中，然后通过某种协议异步合并到Parquet文件中(当有足够数量的更新数据时再重写大的Parquet文件，以此来分摊写入开销)。将Hadoop数据存储在较大的Parquet文件中以及更可靠的源独立数据提取平台将使Uber的分析数据平台在未来几年随着业务的蓬勃发展而继续改进。 - FIN -

福利

人工智能应用挑战赛【能力提升培训第三场】直播回放来啦！   关注【智领云科技】公众号，后台回复关键字！   回复【 培训3 】，即可获取视频回放   回复【 PPT3 】，获取培训课件PPT

扫描添加小编微信，备注“姓名+公司职位”，加入【大数据学习交流群】，和志同道合的朋友们共同打卡学习！

更多精彩推荐

• 硅谷速递 | 脑机接口重现科幻电影场景?人机交互将成未来科技的关键技术？

• 北京数智医保创新竞赛 | 以“智慧”升级医保，智领云BDOS牢筑竞赛“地基”

• 探秘亚马逊AWS数据湖

• 梁刚：基于云原生技术建设“武汉健康云”云平台架构

• 只需3分钟，快速了解大数据平台架构

• 【必读！】Twitter数据平台的架构演化：分析数据的数据发现和消费

?更多智领云科技详细内容，点击“