大规模数据存储技术架构:如何应对海量数据挑战?

612次阅读
没有评论

大规模数据存储技术架构:如何应对海量数据挑战?

作者:邓楠  MO产品总监

导读

随着传感器和网络技术的大规模应用,海量 IoT 设备产生了巨量数据,传统数据库方案难以满足这些数据的存储和处理需求。MatrixOne 是一款强大的云原生超融合数据库,具备优秀的流式数据写入和加工能力,同时拥有强大的可扩展性,能适应任意规模的负载和数据量。接下来,矩阵起源产品总监邓楠老师将为大家分享从 0 到 100 TB,MatrixOne如何助您轻松应对大规模数据挑战。

本次分享主要分为以下三个部分:

Part 1.

MatrixOne设计理念及技术架构介绍

Part 2.

MatrixOne内核1.0版本功能介绍

Part 3.

MatrixOne适用场景和最佳实践

本文字数:7000字+

阅读时间:8分钟+

Part 1

MatrixOne设计理念及技术架构介绍

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne 是一款全新的分布式云原生数据库,它完全依照云计算特点进行设计,紧密贴合当前云计算发展趋势。其主要特性包括线性扩展能力以及存算分离,这两点正是数据库行业当前的发展趋势。

MatrixOne 内核能力突出,它是一款 HTAP(混合事务分析处理)数据库,同时具备流处理能力。简单来说,MatrixOne 可视为将 MySQL、ClickHouse 和 Flink 三种技术融合于一体的产品。它不仅具备分布式系统的扩展性,还能覆盖大部分事务处理和分析处理场景。

MatrixOne 是一个开源项目,欢迎大家浏览上图中列出的开源地址,以及用户手册,以便深入了解技术细节和使用说明。MatrixOne 在设计时,以国内最大的开发者社群 MySQL 8.0 为主要兼容对象,因此用户在迁移过程中可以轻松上手,几乎无需重新学习使用方式。

大规模数据存储技术架构:如何应对海量数据挑战?

在当前大数据时代或 ABC 时代(人工智能、大数据、云计算),数据应用面临诸多挑战。其中一个关键问题是扩展性,数据的量和应用场景随着企业或应用的发展不断增长,需要保证在增长过程中数据应用能够具备相应的拓展能力。例如,一家公司从年收入零开始,逐渐发展到数十万、数百万、数千万甚至数亿级别。在这个过程中,数据量和应用需求也随之增长,这意味着数据架构必须随着时间推移和数据质量的变化不断调整。

以一家初创公司为例,初期可能只需一个简单的单体应用,使用 MySQL 主备即可。但随着公司成长,业务复杂度增加,数据量达到数十 GB 或百 GB 级别,单一数据库难以应对。此时,需要考虑分库、分表等方案,甚至引入更多组件如 Elasticsearch、ClickHouse、Hadoop、Spark 和 Flink 等。

这种情况下,MatrixOne 应运而生。之所以从零开始开发这款数据库,是因为现有的数据库产品虽然在单一能力上表现出色,但存在偏科现象。随着客户需求从简单到复杂、从小规模到大规模演变,需要多种组件来满足不同需求。

大规模数据存储技术架构:如何应对海量数据挑战?

当前数据应用领域面临的一大挑战是满足不断变化的业务需求。针对这一挑战,MatrixOne 的核心理念就是超融合,即整合各类数据库的核心功能,满足用户最关心的需求。

超融合包括以下几个方面:

  1. 分布式事务处理(OLTP):支持高效的增删改查操作,满足流程交易型应用的需求。

  2. 分析性应用(OLAP):提供强大的数据分析能力,帮助企业挖掘数据价值。

  3. 高速写入:支持大规模数据的快速写入,提升系统性能。

  4. 实时性:满足实时流处理需求,实现实时报表和分析预测。

MatrixOne 通过完全重构底层数据引擎,基于先进架构设计出一款超融合的全功能数据库。这意味着企业只需使用一款数据库就能解决各类应用场景的问题,包括流程交易、实时报表和分析预测等。

MatrixOne 数据库分为社区版,企业版和公有云三个版本:

  1. 社区版:开源免费,用户可以自由下载体验。

  2. 企业版:在社区版基础上增加了一系列运维工具和周边组件,便于企业级用户管理和运维。

  3. 公有云版本:完全托管的Serverless版本,即开即用,按使用量付费。

MatrixOne 的设计理念旨在帮助企业轻松应对不断变化的数据应用挑战,实现一站式解决方案。通过不同版本满足不同用户群体的需求,MatrixOne 成为了适应各类场景的优质数据库产品。

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne的另外一个理念就是云原生与Serverless,虽然在应用层开发者应用K8s等云原生技术已经相对普遍。但在数据层或数据库层,云原生化的程度仍有待提高。为实现真正的云原生数据应用,我们需将数据库完全容器化,使其具备自动化和弹性扩展的特点。为此,我们设计了 MatrixOne Cloud,将其 Serverless 化,使其与应用层一样具备完全自动扩展的能力。

MatrixOne Cloud 实现了以下几个设计理念:

  1. 自动化资源供给:用户无需关心负载的变化,数据库会根据需求自动调整资源分配。

  2. 弹性扩展:根据负载情况,自动进行扩容和缩容,实现资源的动态调整。

  3. 按实际用量付费:用户只需为实际使用的资源付费。

  4. 免运维:Serverless 架构使运维工作变得更加简单,消除了节点管理带来的复杂性。

  5. 面向云设计:MatrixOne Cloud 与云上各类成熟组件(如 K8s、S3 等)无缝集成。

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne 是一款全新设计的数据库,致力于满足现代云原生环境的需求。它采用了几个关键技术架构,其中之一是存算与事务分离。这一架构将存储,计算和事务三大功能拆分开来,以实现更高的灵活性和性能。

在 MatrixOne 中,存储层采用了业界公认的廉价且易用的 S3 对象存储。这种存储方式具有高度可扩展性和可用性,已成为云原生数据库的首选。

计算层则采用无服务器架构(serverless),将计算节点(Compute Node)实现为云上的容器化 Pod。这些 Pod 内部几乎没有状态,仅包含一些缓存。这种设计使得 Pod 可以根据需求快速扩展,例如,瞬间创建 100 个甚至 1000 个 Pod。基于 Kubernetes 平台的自动化管理,可以高效地处理这些扩展需求。

通过这些技术架构,MatrixOne 能够充分利用云计算的优势,提供高性能、高可用的云原生数据库解决方案。

MatrixOne 数据库是一个 HTAP(混合事务处理和分析处理)数据库,实现了事务处理(TP)和分析处理(AP)的统一。这一架构的核心是将事务相关的处理单独拆分为 TN 结构。TN 负责写入相关的仲裁和调度处理,并将新写入数据存在内存中,日志则先写入共享日志组件(Log Service)。共享日志组件具有一定的状态,因此需要用到一个三副本的Raft组来保证高可用。TN内存数据达到一定规模后会异步写入到S3存储中,并删除Log Service中的日志。这一设计使得 MatrixOne 能够实现 HTAP 的高效处理。

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne 还自主研发了存储引擎,存储引擎基于当前流行的 LSM Tree 技术。通过这一系列技术架构,MatrixOne 能为用户提供高性能、高可用的混合事务处理和分析处理能力,满足现代应用场景的需求。

大规模数据存储技术架构:如何应对海量数据挑战?

此外,MatrixOne 还实现了存储层面的多级冷热分离,以适应云上架构特点。

首先,在架构设计上,S3 作为云上主存储的选择方案,在使用时需要处理其对于读写 I/O,尤其是小文件处理不友好的问题。为了使 S3 能够满足 HTAP 需求(特别是TP的需求),引入了多级冷热分离的存储策略。

在 CN(计算节点)中,采用了两层缓存机制。一层是内存缓存,另一层是 CN 节点内的本地磁盘,例如 SSD 硬盘。这种两级存储策略使得最热的数据存放在内存缓存中,次热的数据存放在本地磁盘,而相对冷的数据则会被存储在 S3 中。

Log service共享日志模块,用于存储上面提到的事务日志,它需要用到相对读写更高效的块存储产品如EBS。这种存储的IO能力介于缓存和S3之间,读写性能良好,但成本较高。因此,它更适合于处理相对小量的存储需求,并具有高达 5 个 9 的可用性。

多层冷热分离架构,可以实现对事务处理(TP)和分析处理(AP)请求的良好兼容性。

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne的HTAP实现细节与行业中的主流做法也有差异。目前,行业中存在两种 HTAP 技术路线:一种是使用两个引擎,分别处理 TP 和 AP,将两个处理引擎合成为一个数据库;另一种是我们所采用的路线,即在一个引擎内通过区分不同链路来实现 HTAP。

两种方法核心差异在于写入和读取。写入方面,我们通过 TN(事务节点)处理所有相关仲裁。当写入请求到达 CN(代理层)后,相对比较大的数据块可直接写到 S3,而小数据则会写到TN的内存里。所有的写入commit信息都会记录到TN上。新写入的这些存在TN中的数据,我们叫LogTail会通过发布订阅形式推送到相关的计算节点CN的内存中。这意味着 CN 在服务读取请求时,能快速从 LogTail 找到最热的刚写入的数据即返回给用户。

通过这种方式,能够高效地服务于 TP 的小规模写入。对于 AP 相关的大规模查询,如果缓存或 LogTail 中没有所需数据,系统将直接从 S3 读取,由于AP的操作本身就会读较多数据,因此对S3的读取相对是比较友好的。总体而言,通过这种方式可以实现读写链路的区分,并在单一数据库内实现 HTAP 相关能力。

大规模数据存储技术架构:如何应对海量数据挑战?

接下来介绍多租户和多负载自定义资源隔离相关的能力。MatrixOne自带多租户能力,意味着可以在数据库中创建不同的租户,互相使用用不同的数据空间。不同的租户还绑定不同的计算资源组,也就是一个或者若干个CN,这完全基于 Kubernetes 中容器之间固有的隔离性。我们可以通过Proxy服务中的标签形式来定义不同的 CN 组。这些组可以绑定在租户上,也可以进一步根据业务需求进行划分。

举个例子:在集群中存在两个租户。例如,租户 account1拥有一个单独的资源CN组与之绑定。这个资源组可以自动管理扩展,可以指定最小CN个数和最多CN个数。同样,account2也可以实现类似的配置。在 account1内,可以进一步划分资源,将 CN资源组进一步划分为写入资源组和查询资源组。这种灵活的资源划分和隔离策略为业务运行提供了便捷。

大规模数据存储技术架构:如何应对海量数据挑战?

在云端,提供了自动扩缩容的能力,这是 Serverless 基础架构的基础。通过云原生相关的开源组件,如 KEDA,可以感知整个集群的负载。MatrixOne 具有一个独特之处,即会将集群的相关负载记录在 MatrixOne 内部。当集群或 CN(节点)的资源达到预设上限时,会触发扩容机制。这意味着,在达到特定阈值后,系统会自动调用 K8S 接口,增加 CN Set 的节点。由于这个过程实际上是调用 K8S 接口进行扩容,因此实现起来相当便捷。

大规模数据存储技术架构:如何应对海量数据挑战?

接下来要介绍的一个技术要点是流引擎,也称为 streaming 能力。虽然目前流引擎仍处于实验阶段,尚未完全成熟,但在整个架构中,它发挥着至关重要的作用,也是真正实现 一站式HTAP处理的核心。

流计算主要解决两个问题:

第一,MatrixOne的数据源可能多种多样,包括上游其他数据库或者IoT等设备产生的日志数据,都会需要实时入库。为了快速能接入不同数据源,流计算引擎负责处理前端写入数据的相关事宜。特别是,我们可以通过流引擎方便地接入诸如 Kafka 等消息队列,以及前端上游数据库相关组件。这些能力都被整合为一整套组件,从而将接入过程大大简化。

第二,数据从原始模型要经过一系列变换操作,最终转化为分析相关的表。在这个过程中,流引擎实现了数据转换相关功能,类似于数据仓库中的物化视图。通过对原始数据进行一定的变换,包括聚合和归一化操作,我们将数据转化为物化表。随后,通过查询这些物化表,实现了简化的数据处理链路。

这一创新之处在于,流引擎能够在数据库内部完成原始数据读取、处理和查询等操作,避免了将数据读取到外部进行处理后再写回数据库的繁琐过程。这也是我们一站式实现数据入库和使用的基础。

Part 2

MatrixOne内核1.0版本功能介绍

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne 今年发布了1.0 版本。整体实现了与 MySQL 8.0 高度一致的 SQL 语法,使得原有 MySQL 应用的迁移工作非常轻松便捷。其中包括 DDL(数据定义语言)和 DML(数据操作语言)等基本功能,涵盖了大部分常用数据类型。

在索引和约束方面,我们保持了与 MySQL 绝大部分能力的兼容,包括主键、唯一键、非空外键等。多租户相关能力是MatrixOne产品的一大亮点,通过数据库内部创建新租户,实现数据空间的隔离,便于 SaaS 应用处理多租户需求。同时,我们还支持租户间的数据发布订阅,允许在一定程度上实现数据互通,为用户提供更多便利。

大规模数据存储技术架构:如何应对海量数据挑战?

在查询方面,1.0 版本已经涵盖了主流的基础查询和高级查询功能,满足基本的业务应用和数仓中的应用需求。其中包括窗口函数、CTE(公共表表达式)以及递归 CTE 等高级查询能力。此外,常用的聚合函数和系统函数也一应俱全。

目前,查询功能与 MySQL 的兼容度达到了约 70%-80%。虽然 MySQL 还具备一些更高级的功能,如触发器、存储过程等,但在实际应用中,这些功能的利用率相对较低。在后续版本中,我们将根据用户需求和行业趋势,逐步完善这些功能,以满足不同场景下的需求。

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne支持事务处理,默认情况下使用悲观事务。悲观事务的处理方式与 MySQL 完全一致,主要包括使用 start 或 begin transaction 开始事务,commit 提交事务,以及 rollback 回滚事务等操作。

目前,默认使用悲观事务以及 RC(Read Committed)隔离级别。当然,用户可以根据需求切换到乐观事务以及 Snapshot isolation 等相关隔离级别。然而,在主流的行业应用中,悲观事务依然占据主导地位,主要是因为它便于应用程序的开发和维护。

大规模数据存储技术架构:如何应对海量数据挑战?

在部署架构方面,提供两种版本:包括单机部署和分布式部署。

单机部署相当简单,只需将二进制文件、源码或 Docker 镜像安装到服务器上即可。对于分布式部署,需要依赖 Kubernetes(K8S)和 Amazon S3。企业版中已包含这些依赖项。

针对云上部署,各大主流云服务提供商都提供了现成的 Kubernetes 平台、对象存储等资源。可以利用这些资源,通过提供的 Operator 快速部署整个系统。

目前推荐的最小配置为 3 个 8c32g,作为分布式生产环境部署。更多关于部署架构的详细信息,请参考官方网站上的文档。

大规模数据存储技术架构:如何应对海量数据挑战?

在开发和运维工具方面,MatrixOne与MySQL高度兼容。针对使用 MySQL 开发应用程序,我们已经验证了主流框架和多种语言的兼容性,其中包括 JavaPython 和 Golang。尽管我们尚未完全适配其他语言,如 C# 或 Ruby on Rails,但简单试用后,预计其匹配度也相对较高。因为 MatrixOne 本质上与 MySQL 兼容性良好,所以在使用这些语言时,大多能无缝切换。

此外,常用的 ORM 框架如 MyBatis、MyBatis Plus、SQLAlchemy 和 GORM 等,均已深度适配 MatrixOne。针对数据库管理工具,MatrixOne 与 MySQL 高度通用,便于开发者使用熟悉的Navicat,DBeaver等工具。

另外,我们自研了备份工具,包括逻辑备份和物理备份,以满足不同需求。这些备份工具与 MySQL 原生备份有所区别,但使用起来同样便捷。例如,mo-dump 类似于 MySQL dump,mo-backup 则相当于 MySQL 的 extra backup。

为了方便部署和管理,我们也开发了一套名为 MOCTL 的自研工具。此外,与 MySQL 不同的是,MatrixOne 天然记录数据库相关日志和查询,便于监控。通过对接 Grafana 等可视化组件,可轻松实现监控功能,无需额外采集器。

总之,在开发和运维方面,MatrixOne 与 MySQL 具有很高的一致性,有助于降低迁移成本,提升工作效率。

大规模数据存储技术架构:如何应对海量数据挑战?

在面向大数据领域开发时,会用到很多如 ETL 工具、计算引擎、BI 工具和数据调度等工具。为确保兼容性,我们已经对这些工具进行了适配,并在官方网站上提供了相关教程文档。

Part 3

MatrixOne适用场景和最佳实践

接下来,简要总结一下 MatrixOne 适用于哪些场景。

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOne 是一款超融合数据库,同时具备强大的云原生扩展性能力。其主要应用场景如下:

  1. 事务处理(TP):MatrixOne 可作为高性能的事务处理数据库,适用于需要高性能读写操作的场景。由于 MatrixOne 与 MySQL 语法接近,开发者无需额外学习即可上手。此外,MatrixOne 提供了更好的扩展性,支持分库分表,适用于需要分布式处理的场景。

  2. 分析处理(AP):MatrixOne 提供了高性能的 AP 能力,单机性能可与 ClickHouse 媲美,同时具备更好的扩展性。适用于需要高效报表查询、复杂分析以及 HTAP(混合事务处理和分析)的场景。

  3. 时序数据处理:适用于 IoT 设备监控、互联网业务监控等场景,这些场景下数据量大、写入并发高,且需要实时查询性能。MatrixOne 可提供窗口函数、降采样等高级功能,满足此类场景需求。

  4. SaaS/多租户应用场景:SaaS 应用需要具备扩展性、事务处理和应用处理能力,同时支持多租户。MatrixOne 支持多租户和自动扩容,适用于此类场景。

  5. 实时数据仓库:适用于实时数据仓库场景。MatrixOne 具有高实时性,适用于需要快速处理海量数据的应用。

  6. 数据中台:适用于轻量级主要面向结构化数据处理的数据中台场景。

  7. 数据智能AI:MatrixOne 支持实时 AI 处理,结合向量数据库技术,实现从数据处理、结构化到查询的一站式解决方案。通过融合 SQL 精准查询和大模型的模糊回答,MatrixOne 能提供更优秀的结果。

综上,MatrixOne 可广泛应用于事务处理、应用平台、时序数据处理、SaaS 应用、实时数据仓库、数据中台和数据智能AI 等场景。

大规模数据存储技术架构:如何应对海量数据挑战?

MatrixOn的核心价值就是一站式。在 HTAP(混合事务处理分析)场景中,传统的 HTAP 系统通常包括一套事务处理(TP)数据库、一套 BI 系统和一套分析处理(AP)数据库,并通过 ETL 工具实现数据互通。然而,在 MatrixOne 的支持下,这一整套架构可以变得更加紧凑和高效。

很多时候,BI 系统是从业务系统中分离出来独立运作的,因为它在处理大量数据时,业务系统的OLTP数据库难以胜任。但实际上,BI 系统应该是业务系统的一个有机组成部分。在 MatrixOne 的支持下,HTAP 系统可以实现底层能力的整合,避免分裂为两套系统。

我们可以将业务系统和 BI 系统整合在同一个 MatrixOne 集群中,通过资源组实现隔离和扩容策略。当业务负载达到一定程度时,系统可以自动进行扩容。数据仍然存储在 S3 中,实现了数据的融合。同时,通过MatrixOne 的分析能力,可以为不同业务分配专门的资源组,实现负载分离。这种解决方案既满足了数据融合的需求,又实现了业务之间的隔离。

大规模数据存储技术架构:如何应对海量数据挑战?

SaaS(软件即服务)场景是 MatrixOne 应用的另一大领域。在 SaaS 系统中,通常包括用户面和控制面两个部分。用户面主要针对各自独立的用户,涉及租户隔离问题。传统 SaaS 系统中,租户数据共享或完全隔离两种方案各有弊端。共享实例会导致资源竞争,而彻底隔离则管理成本过高。

MatrixOne 提供了一种折中方案,通过数据库内部的租户隔离功能,实现数据和资源组的独立管理。在 MatrixOne 中,可以创建数据库租户,实现数据隔离。每个租户的数据空间相互独立,同时可以分配不同的资源组,并具备自动扩缩容能力。这样,各个租户既可以保持隔离性,又能独立进行资源扩展,降低了管理成本。

控制面涉及监控、日志、计费和统计等功能,传统应用中通常通过单独的数据库或大数据组件来满足这些需求。MatrixOne 可以将这些功能集成到一个集群内,通过不同资源组的形式来实现各种负载的分割。同时通过订阅发布机制,可以控制面与用户面可以进行高效数据交互,实现数据共享。

总的来说,MatrixOne 可以为 SaaS 系统提供高效、便捷的数据处理方案。它整合了多个数据库功能,简化系统架构,降低管理成本。同时,MatrixOne 支持租户隔离和资源自动扩缩容,确保系统性能和稳定性。通过订阅发布机制,MatrixOne 还能实现数据交互,满足 SaaS 应用的需求。

大规模数据存储技术架构:如何应对海量数据挑战?

在 MatrixOne 中,我们同时关注时序和实时数据分析的场景。这两者虽然在侧重写入和查询方面有所不同,但整体架构相似。时序数据主要来源于 IOT 设备或监控系统,通过 Kafka 或其他消息队列写入数据库。另一方面,上游数据库(如 MySQL 或 TB 数据库)通过 ETL 过程将数据导入数据库。

MatrixOne 流处理框架针对 Kafka 提供了专用的 Connector,避免了额外引入 Flink 等组件。同时,我们可以为写入部分分配特定资源组,以应对大量并发写入或高频写入。由于资源组具有扩展性,写入任务能够得到有效承载。查询部分与之前提到的 AP 场景相似,根据业务需求划分资源组并赋予扩缩容能力。在中途涉及数据转换的场景中,MatrixOne 提供了实时流处理能力,可在数据流中间进行数据转换。这种方式涵盖了整个数据处理架构,实现从数据写入到查询的一体化解决方案。借助一套工具,MatrixOne 能够满足从数据写入、查询到后续 AI 相关处理的全部需求。

About

MatrixOne

MatrixOne 是一款基于云原生技术,可同时在公有云和私有云部署的多模数据库。该产品使用存算分离、读写分离、冷热分离的原创技术架构,能够在一套存储和计算系统下同时支持事务、分析、流、时序和向量等多种负载,并能够实时、按需的隔离或共享存储和计算资源。云原生数据库MatrixOne能够帮助用户大幅简化日益复杂的IT架构,提供极简、极灵活、高性价比和高性能的数据服务。

MatrixOne企业版和MatrixOne云服务自发布以来,已经在互联网、金融、能源、制造、教育、医疗等多个行业得到应用。得益于其独特的架构设计,用户可以降低多达70%的硬件和运维成本,增加3-5倍的开发效率,同时更加灵活的响应市场需求变化和更加高效的抓住创新机会。在相同硬件投入时,MatrixOne可获得数倍以上的性能提升

关键词:超融合数据库、多模数据库、云原生数据库、国产数据库。

大规模数据存储技术架构:如何应对海量数据挑战?

欢迎小伙伴们交流经验!

大规模数据存储技术架构:如何应对海量数据挑战?

官网

matrixorigin.cn 

源码

github.com/matrixorigin/matrixone

Slack

matrixoneworkspace.slack.com

大规模数据存储技术架构:如何应对海量数据挑战?

扫码加入MatrixOne技术交流群

(如二维码过期,请添加小助手微信: MatrixOrigin001)

往期技术文章推荐

往期推荐

开源数据库 MatrixOne 的 HTAP 分布式架构演进

微信AI团队:以标签为锚的LLM学习方法探索研究

Alluxio SDK 在 Presto/Trino 中的应用

如何成为好的数据产品经理?-快手数据平台负责人

数据治理与大模型一体化实践

关于A/B 实验中策略长期效果评估方案的研究

快手 Dragonfly 策略引擎的设计与应用

知乎舰桥平台的三板斧-内部营销篇

盘点AB实验长期影响评估的方法论

从 Elasticsearch 到 SelectDB,观测云实现日志存储与分析的 10 倍性价比提升

OLAP技术的选择,进化和思考

AB实验平台建设实践助力业务决策-货拉拉

知乎舰桥平台如何打造内容运营平台提升业务能力?

大模型时代 AI 技术在金融行业的创新应用

小米数据生产平台的产品设计方法与实践

网易数帆 指标中台构建核心技术解析

大规模数据存储技术架构:如何应对海量数据挑战?

DataFun

大规模数据存储技术架构:如何应对海量数据挑战?

点个在看你最好看

 

Read More 

正文完
可以使用微信扫码关注公众号(ID:xzluomor)
post-qrcode
 
评论(没有评论)
Generated by Feedzy