数据人应该掌握哪些大数据管理技术？
事实上，这个问题也让我陷入深思，因为我的脑海中还没有一个清晰的框架。本文仅仅是我对于这个问题的一些想法，并且很大部分是我对数据管理的当前状态与未来的推测。
阅读本文的前置知识
首先，和其他任何领域一样，有一些基础知识是任何软件工程师都应该了解的。
简而言之，我假设来到大数据领域的人已经知道某种编程语言，并且对例如算法、SQL、版本控制（VCS）、系统生命发展周期（SDLC）、网络、Linux 和 CI/CD 等基础知识有所了解。无论如何，这些软件工程的通用实践都是无处不在的。这是我认为在任何软件工程领域都需要了解的基础。如果你不了解它们，那么请你最好先学习它们。也许你另有高见，也可以与我讨论。
大数据基础
我认为这是另一个层面的基础知识。举例来说，这里我可以强调编程语言的重要性。因为在大数据的世界里，有一些语言是占据主导地位的。如果不了解这些语言，要完成某些事情非常难（甚至可以说是不可能的）。当然，这指的是例如 Java、Scala 这些 JVM 语言，也许 Kotlin 很快也会加入其中，当然还有 Python——无论做什么事情，Python 都是第二佳的语言，也是数据科学的编程语言事实标准。
除了编程语言以外，还有一些我认为应该学习的大数据的术语和基础概念，比如水平拓展、分布式系统、异步通信、CAP 定理、最终一致性、共识问题、可用性、持久性、可靠性、弹性、容错能力、灾难恢复等。你不需要对这些术语有非常深刻的理解，但如果你希望在这个领域有所成就的话，你至少还是先谷歌一下。
现在，让我们来谈谈这个领域是如何发展的，或者更准确的说，它所面临的挑战。
数据上的挑战
在某种形式上，这个层面的知识是指当处理数据时你需要解决的问题。你可以这样想：有大数据的地方，就有大的问题和挑战。
当你在进行某个层面上的数据处理工作时，你将需要一些特定的技能。下面我们就来深入了解它们。
大部分的大数据工作流程包含了如下几层：
数据层（Data Layer）
随着存储信息数量的增长，数据存储一直都是首要问题。这是任何与数据打交道的系统的基础——有许多技术可以存储海量的原始数据，这些原始数据可以来自传统的数据源，比如 OLTP 数据库，也可以来自更新的、更非结构化的数据源，比如日志文件、传感器、网站分析数据、文档档案数据和媒体档案数据。如你所见，这些领域差异巨大，有着各自的领域特点，而我们需要从所有这些领域收集数据。
第一件重要的事情就是用于存储数据的格式，如何将其存储结构最优化以及如何最优地存储这些数据。当然，在此时你会想到大数据领域的常见格式，例如 Parquet、CSV、Avro。另外，也可以考虑使用压缩工具，例如 Bzip2、Snappy、Lzo 等等。此外，优化工作基本上要么涉及适当的分区，要么是一些存储特定的东西。
支撑数据层的主要技术，当然是具有 HDFS 的 Hadoop——一个非常经典的大规模文件系统。因为它的持久性和在传统设备上无限的扩容能力，它已经非常流行了。然而，最近越来越多的数据被存储在云端，或者至少是混合云——企业正在从过时的本地存储系统迁移到类似 AWS S3、GCP GCS 或者是 Azure Blob 这样的托管服务。
对于 SQL 的解决方案，最流行的应用是 Hive 或者 Presto，或者是更有趣的数据仓库解决方案。我认为它们位于基础的 SQL 引擎之上。我们稍后会详细讨论。
对于 NoSQL 的解决方案，它要么是支持 ACID 的 Cassandra、文档数据模型且数据大小可管理的 MongoDB 或者是用于可伸缩解决方案的 AWS DynamoDB（如果你在 AWS Cloud 上）。
对于图数据库，我只能想起 Neo4j。它非常适用于存储图数据或者相关信息，比如一群人和他们之间的关系。对这类信息在传统的 SQL 数据库建模会是非常困难且低效的。
数据湖（Data Lake）
数据湖是一个公司的集中存储库，它可以存储所有关于业务的结构化和非结构化的数据。在数据湖中，我们按数据的原样来存储数据，而不进行结构化处理，然后在此之上进行不同类型的分析。
当今的数字化转型实际上是将数据驱动的方案应用于业务的各个层面，从而创造竞争优势。这也是为什么越来越多的公司希望构建自己的数据湖解决方案的原因。这种趋势仍在继续，这些技能还是被市场需要的。
在数据湖领域，最流行的的工具仍然是用于本地化方案的 HDFS，以及各类来自 AWS GCP 和 Azure 的云数据存储方案。除此之外，还有一些数据平台正在尝试填补一些细分市场并且创建集成解决方案，比如 Cloudera、Apache Hudi、Delta Lake。
数据仓库（Data Warehouse）
数据仓库可以被描述成用于存储已经处理好的业务数据的传统数据库，但它针对聚合请求作出了优化。无论如何，它还是和数据湖一样，都是构建分析和数据驱动决策的基础。它与数据湖之间并不排斥，而是相互补充。
数据集市是旨在满足某种特定的业务功能要求而设计的数据仓库解决方案的最后一层。数据集市具有从不同的数据源提取数据的能力，这使它成为数据仓库领域的一种增长趋势。
流行的数据仓库解决方案包括 Teradata、Snowflake、BigQuery 和 AWS Redshift。
数据总线（Data Hub)
现在我们有了数据仓库，来以数据的最终结论的形式对信息进行排序和呈现（其余的信息被丢弃了）；也有了数据湖——“存储了所有的内容，因为你永远不知道什么时候会用到它们”。而数据总线专注于既不属于第一类也不属于第二类的数据。
数据总线的架构允许你把数据留在原处，提供了集中的处理能力，但不提供存储能力。现在，数据在它所在的地方被搜索和访问。但是，因为需要对数据总线进行规划和管理，企业必须投入大量的时间和精力来决定数据的含义、数据从哪里来以及它在被放在数据总线之前必须完成哪些转换。
数据总线是存储架构的另一种理念。我敢打赌，它在未来一定会获得关注——所有它所需要的支持组件现在都已经可以获得了。
数据提取（Data Ingestion）
为了创建数据存储，你需要把数据从不同的数据源接入数据层，不管是数据湖、数据仓库还是只是 HDFS。数据源可以是像 Salesforce 这样的客户关系管理（CRM）公司，也可以是像 SAP 这样的企业资源计划系统，还可以是像 Postgres 这样的关系型数据库，或者是任何的日志文件、文档、社交网络图等等。并且数据可以通过批处理任务上传或者是通过实时流上传。
有很多用于数据提取的工具，其中一个非常常见的工具是 Sqoop。它提供了一个基于 Java 的可扩展框架，可以用于编写把数据导入 Hadoop 的驱动。Sqoop 运行在 Hadoop 的 MapReduce 框架上，也可以用于把数据从 Hadoop 导入到关系型数据库中。
另一个非常常见的工具是 Flume。它适用于数据流的输入比数据流的使用更快的场景。一般来说，Flume 用于把数据流导入 HDFS 或者是 Kafka，此时它承担是是 Kafka 的 Producer 的角色。多个 Flume agent 可以被用于从多个数据源收集数据到 Flume collector。
另一个受欢迎的工具是 Nifi。Nifi 处理器是面向文件的，没有模式（schema）。这意味着一些数据可以被表示成 FlowFile 的形式（它可以是位于磁盘上的实际文件或者是其他位置上获得的数据块）。每个处理器负责理解数据的内容，以对数据进行处理。所以，如果一个处理器理解格式 A，另一个处理器只能理解格式 B，你可能需要在两个处理器之间转换数据格式。
另外，还有一个消息总线领域中可以被称作标准之一的 Kafka。它是一个开源的流消息总线，可以从你的数据源创建提要，对数据建立分区并且以流的形式传送给消费者。Apache Kafka 是一个能在大规模生产环境中使用的，成熟且功能强大的解决方案。
数据处理（Data Precessing）
感谢上述数据提取的管道，现在数据已经传送到了数据层。现在，你需要能处理海量数据的技术，以便于分析和处理这些数据。数据分析师和数据工程师希望能够对大数据进行查询，这需要强大的计算能力。数据处理层必须将数据优化以促进更有效的分析，并提供计算引擎来执行查询。
这里最流行的模式是 ETL（Extract-Transform-Load），它是一种非常流行的数据处理范式。从本质上来说，我们把数据从数据源中提取、清理、然后转换成结构化的信息，并将其上传到目标的数据库、数据仓库或者是数据湖。
成功实现这一模式的工具之一便是 Apache Spark。我认为它是大数据工具包中最重要的工具之一，任何有海量数据处理经验的人应该都已经掌握它了。它在 Hadoop，Mesos，Kubernetes 或其他平台上对结构化或非结构化数据执行并行查询。Spark 还提供 SQL 接口，并具有良好的流处理和内置的机器学习功能。
ELT（Extract Load Transform）
现在有一种从 ETL 迁移到 ELT 的趋势，在 ELT 当中，转换（Transformation）的步骤发生在数据仓库里，而不是数据仓库之上。在我看来，这种趋势来自于对数据的了解不足。因为传统上，为了使数据更稳定和对用户而言更可访问，对于什么数据需要进入数据仓库有许多的计划和严格限制。然后这也带来了输入数据格式的更改和输出结构格式的更改等等。
像 Snowflake、AWS Redshift 这样的工具允许在载入的数据（甚至可以是非结构化的数据）之上创建一个抽象层，来为数据提供一个简单的 SQL API，而无需考虑那个字母 T——转换。
从批处理到实时处理
现在一个很清晰的趋势是，实时数据收集系统正在迅速地取代批处理的 ETL，这使得流数据成为了现实。越来越多的提取层和处理层正在转向实时，这又反过来促使我们学习新的概念、使用可以同时进行批处理和实时处理的多功能工具，例如 Spark 和 Flink。
内存内处理（In-Memory）
由于内存变得越来越便宜，并且企业依赖于实时处理的结果，因此内存计算使得他们能够拥有更丰富和更具有交互性的数据仪表板，这些仪表板能提供最新的数据并且随时都可以几乎实时地提供报告。通过在内存（而非硬盘）中分析数据，他们可以即时查看数据，并且对数据快速做出决策。
在大多数情况下，所有已知的解决方案都已经使用或者尝试使用这种方法。这里还是同样地，Spark 是最容易理解的例子，同时还有数据网格的实现，例如 Apache Ignite。
Apache Arrow 结合了列式数据格式和内存计算的优点。它提供了这些现代技术的性能优势的同时也提供了复杂数据和动态模式的灵活性。实际上，我不知道还有没有其他类似的格式。
管理上的挑战
这是另一个知识领域，它基本上位于一个稍微有所不同的平面，但与数据直接相关。管理上的挑战涉及隐私、安全、治理和数据/元数据管理。
搜索与信息获取
信息检索系统是一个算法网络，用于根据用户需要来搜索相关数据或者文档。
为了对海量数据进行有效的搜索，通常建议不要执行简单的扫描——然后就出现了各种工具和解决方案。我认为其中最常用的一个工具是 ElasticSearch。它被用于互联网搜索、日志分析和大数据分析。ElasticSearch 之所以受欢迎，是因为它易于安装、无需其他软件便可扩展至上百个节点、并由于其内置的 REST API 而易于使用。
另外，其他出名的工具包括 Solr、Sphinx 和 Lucene。
数据治理（Data Govenance）
这可能是大数据领域其中一个非常重要、但仍然被低估的领域，并且在我看来，还没有非常好的解决方案。数据治理的目的是建立方法、职责和流程以标准化、集成、保护和存储数据。如果没有有效的数据治理，企业中不同系统的数据的不一致性将无法消除。这会使数据集成变得更复杂，并导致数据集成问题，从而影响到业务智能、企业报告和数据分析应用的准确性。
我显然不是这个领域的专家，但我所见过的这个领域的相关工具包括 Informatica、Teradata、Semarchy。
安全
不断增加的数据量对防止入侵、泄漏和网络工具的保护措施造成了额外的挑战，因为数据保护的水平与数据、供应商和人员的增长不同步。全面的、端到端的数据保护措施不仅仅包括在整个生命周期（无论是在静止状态还是在传输状态）对数据进行加密，还需要从项目的一开始就对其进行保护。如你所见，这可能影响到我们在本文中提到的所有领域和方面。并且，和信息安全的所有内容一样，这类对策很难正确地实施。
诸如 GDPR、CCPA、LGPD 之类的隐私法规的出现对违规行为制定了严重的惩罚措施。企业必须考虑数据的机密性，并且在这些领域的专家也变得越来越重要。
在这个领域中，值得关注的工具包括：Apache Kerberos, Apache Ranger, Apache Accumulo.
数据目录（Data Catalog）
通常来说，在一个公司里，我们有大量不同形式、不同存储方式以及不同格式的数据，并且对数据有不同级别的访问权限。为了找到你需要的数据，你要么需要知道在哪里可以找到它，要么需要知道在哪里开始查找（如果有这样的一个地方）。这就是所谓的数据目录（data directory 或 data catalog）的作用。
企业数据源的管理是一个必不可少的过程，它是基于企业内各个局限的群体所知道的信息的。但是，要收集所有和存储在企业中的数据所相关的元数据并管理它并不容易，因为人员会离开企业、数据会被删除或添加。因此，建立数据目录是一项非常重要但复杂的任务。
在这个领域中，非常出名的工具有：Apache Atlas 和来自云服务商的其他解决方案。
分析上的挑战
数据分析与业务智能是一种用于制定数据驱动的决策的一种方法，它提供了有助于业务发展的信息。利用这个层面的技术，你可以启动查询来回答某个业务相关的问题，对数据进行切片与切块，构建数据仪表板并创建清晰的可视化结果。
有了更多的数据，你可以做出更准确的预测和更可靠的方案，并且以此建立新的预测，在机器学习的阶梯上不断高攀。
机器学习
机器学习是一种特殊的数据分析方法，它可以让你创建能够分析海量复杂数据的模型，并做出预测和决策，而不需要为此进行详尽的编程工作。越来越多的企业使用机器学习的方法来完成它们的日常运营分析和正常的业务运营。
在过去，机器学习在一定程度上受到以下方面的限制：在数据工程师团队将方案部署到生产环节之前，数据科学家无法对解决方案进行评估和测试。实际上，大多数组织都有一个传统的业务智能/分析团队，然后还有一个单独的数据科学团队和数据工程师团队。
现在，这些技能已经开始出现重叠，并且随着大数据慢慢转向分析和基于大数据建立知识，这些团队将更加深入地合作。因为如果没有机器学习，大数据就太“大”了。因此，我认为至少需要了解机器学习的基本概念。
当然，还应该特别注意机器学习所依赖的知识，例如统计学、机器学习的优化方法、偏差/方差、需要理解的不同指标，等等。在应用机器学习时，你基本上只需要了解基本的机制，而具体的公式是不重要的。但是，那些不理解语言背后的模型的人，通常来说会犯非常愚蠢的错误。
关于机器学习还有很多要说的，但我把这些话题留到下次。机器学习中还分了许多领域——自然语言处理、计算机视觉、推荐系统、知识表示等等。但是，通常当你开始理解了某一方面，你其实已经知道有哪些内容你是不理解的。因此，你可以深入地学习。
如果你希望成为一名机器学习工程师（算法工程师），先确保你了解 Python。它是一个机器学习领域的通用语。然后，各种不同的用于处理数据的框架也值得学习，例如 Numpy、Pandas、Dask 和已经提到的 Apache Spark。当然，还有最受欢迎的机器学习库：Scikit-Leaen 和 XGBoost。
我认为每个人应该都明白机器学习中真正重要的方向或多或少都与深度学习有关。当然，经典算法也不会消失在我们的视线中，因为在大多数情况下，它们已经足以构建一个好的模型。但当然，未来是建立在神经网络之上的。深度学习的魔力在于，随着数据的增加，它会变得更好。另外，其他值得了解的术语包括转移学习、1cycle 策略、CUDA 和 GPU 优化等。
深度学习最流行的库是带有 fast.ai 的 Pytorch、带有 Keras 的 TensorFlow（我认为它在不远的将来应该会被人们弃用，但还是在此提及一下。）
分布式机器学习
另一个值得一提的技术是分布式机器学习。正如我所说，大数据正在慢慢走向基于海量数据的更为复杂的数据分析。存储在中央存储库的大型数据集需要巨大的处理和运算能力，所以分布式机器学习是正确的方向。尽管它还存在很多问题（在以后的文章中会继续讨论）。
我个人对这种方法很有兴趣，但它除了大型企业以外，和其他任何人都没有关系。模型精度对大公司来说至关重要，而这只能从有着数百万个参数和海量数据的大型模型中获取。对于其他人，正如我所说，基于数据子集和预聚合数据的经典算法就已经对实际应用有非常好的效果了。
我可以列举几个在这个方向有用的工具：Spark Mllib、H2O、Horovod、Mxnet、DL4j，也还还有 Apache Ignite。
实时分析
尽管大公司通常看重实时的数据管理，但并不是所有公司都选择实时的大数据分析。理由可能各异：缺少实操经验或者资金不足、担心其可能导致的相关问题或者是一般意义上的管理惰性。然而，那些实施实时数据分析的公司将获得很大的竞争优势。
这方面的工具包括 Apache Spark Streaming、Apache Ignite Streaming、AWS Kinesis。
数据科学的自动化
为以某种方式自动化数据预处理、特征工程、模型选择和配置以及结果评估工作，人们发明了自动机器学习（AutoML）。AutoML 可以自动化这些任务，并能够对在哪个方面可以继续深入研究给出理解。
当然，这听起来很棒，但是它效果如何？这个问题的答案取决于你如何使用它。这个问题的重点在于了解人类所擅长的方面的和机器所擅长的方面。人们善于将现有数据和真实事件相结合——他们了解业务领域、了解特定数据的含义。机器擅长统计信息、存储和更新状态并执行重复过程。
通过自动化机器学习框架，类似探索性数据分析、数据预处理、超参数调整、模型选择和把模型放入生产环境这样的任务可以在某种程度上实现自动化。但是好的特征工程和提炼可实施的见解可以由了解业务需求的人类数据科学家来完成。通过分离这些活动，我们现在就可以很简单地从 AutoML 中受益。而且我认为，在未来 AutoML 将会取代大部分数据科学家的工作。
而且，我认为值得注意的是，这个行业正在经历机器学习平台解决方案的强劲发展（例如 Amazon Sagemaker、Microsoft Azure ML、Google Cloud ML 等等）。而随着机器学习的使用不断增长，许多企业正转向现成的机器学习平台来加快产品上市时间，减少运维成本和提高成功率（包括机器学习模型的部署量和调试量）。
可视化
我们的文化是视觉化的，并且可视化正在越来越成为了解每天生成的大数据的关键工具。数据可视化通过一种简单而易于理解的方式来指导数据、突出趋势和偏差，以此来讲述故事。好的可视化可以告诉我们事实、消除数据中的噪音、并突出显示有用的信息和业务前景。
在我看来，这个方向最受欢迎的工具是 Tableau、Looker 以及所有上述提及的技术栈，这些技术栈在某种程度上对于建立数据仓库和进行数据管理的必要的。
Tableau 是一个功能十分强大的表格化业务智能与数据可视化工具，它连接了数据，使你能够执行详细的、全面的数据分析，并且绘制图表和仪表板。
Looker 是一个基于云的业务智能平台，在你配置好用于描述你的数据的可视化设置后，它允许你使用 SQL 定义的指标来查询和分析大量数据。
运维上的挑战
为了解决上文所述的所有问题，你需要有正确架构基础设施，并且为该基础设施配套合理的管理、监控、和配置环境。而这还不是我在本节中要介绍的所有内容——还包括工作流的编排以及在数据管理中的各个方面开发运维（DevOps）实践。
Kubernetes
微服务的建设问题很久以前就得到解决了。所有严肃的解决方案都是构建在微服务架构上的。然后 Docker 容器、k8s、Helm、Terraform、Vault、Consul 和所有相关的东西都出现了。这一切都在不经意间成为了标准。
日志管理（Log Management）
日志管理是处理日志事件的过程，这些日志由不同的软件应用和运行这些应用的基础架构产生。它可以包括日志的搜集、分析、存储和搜索，其最终的目的是使用数据来进行故障排除，并获取业务、应用和基础架构的信息。
在这个方面，其中一个最重要的工具是 ELK。它包含以下几个部分：ElasticSearch（文本搜索工具）、Logstash 和 Beat（数据传送工具）、Kibana（数据可视化工具）。它们一起提供了用于实时数据分析的一个完整的工具。虽然它们可以被设计成一起使用，但它们每个都是一个单独的项目。ELK 提供了用于在线分析的功能，例如报告创建、警报、日志搜索等等。这使得它不仅仅成为了 DevOps 的通用工具，更是上述提及的所有领域的通用工具。
另一个工具是 Splunk，它是一个机器数据工具，为用户、管理员、开发人员提供了即时接收和分析所有由应用程序、基础架构中的网络设备和其他任何机器所创建的数据的能力。Splunk 可以通过图表、警报、报告等提供实时信息，从而接收机器数据，并把它转换成实时的分析。
工作流编排（Pipeline Orchetration）
工作流编排是容错的工作流程的自动化管理。大多数大型的数据解决方案由封装在工作流程中的重复的数据处理操作组成。工作流编排工具帮助自动化这些工作流程。它们可以以一种容错的方式计划作业，执行工作流以及协调任务之间的依赖关系。在这个方面，我过去经常听到的名字是 Oozie，而现在主要是 Airflow 或 AWS Step Functions。
云服务
很明显，在大数据领域，未来是建立在云上的。所以，每个对数据管理有兴趣的人都最好了解云的概念。
除了应用于云的层面的编程模式之外（例如 API 网关模式、发布/订阅模式、边车「Sidecar」模式），你还会遇到不同的概念，例如基础设施即代码、无服务。当然还有架构上的概念（N 层架构、微服务、松散耦合等等）。我个人认为，它使我在更高层面上对工程方法的原理有了的更深入的理解，在架构方法层面的理解也有了一些提升。
现在的云提供商有 GCP、AWS 和 Azure 等等，我相信没人会说选项只有它们（译者注：国内也有阿里云、腾讯云等选择）。你可能决定选择 AWS（举例来说），但所有云都是以相同的方式设计的。尽管它们有各自的特色，并且并非所有的云服务商都相互匹配。
我从哪开始学习 AWS？
当你打开AWS的文档，就会看见一个非常长的 AWS 服务的列表，但是这仅仅是全局目录的全局目录！没错——Amazon 现在实在是太大了。在写这篇文章的这一章节的时候，该目录大约有 250 个服务。学习 AWS 的是所有服务是不现实的。也没有理由去学习所有的服务。
John Markoff 说过：“互联网已经进入了它的乐高时代”。AWS 服务就像乐高——你找到正确的部件，并把它们组合起来。
为了强调最重要的部分，按照 AWS 历史上的先后出现顺序来排序是很合理的办法。它们包括：
S3——存储
EC2——虚拟机+EBS 硬盘
RDS——数据库
Route53——DNS
VPC——网络
ELB——负载均衡器
CloudFront——内容分发网络（CDN）
SQS/SNS——消息
IAM——对所有东西的访问权限控制
CloudWatch——日志/指标
然后，还有现代的微服务的部分，包括 Lambda、DynamoDB、API Gateway、CloudFront、IAM、SNS、SQS、Step Functions、EventBridge。
数据/解决方案的迁移
从本地解决方案到云服务的数据迁移的集成和准备过程是非常复杂且耗时的。除了迁移大量现有数据外，在迁移完成之前的几周或几个月内，公司还必须同步其数据源和平台。
除了迁移之外，企业还需要准备灾难恢复计划，从而在不牺牲业务的前提下，为任何可能发生的事情做好准备。显然。这里的解决方法也是迁移到云。
机器学习运维（MLOps)
我们的机器学习算法很好，但是要取得好的结果，确实需要大量的数据专家、数据工程师、领域专家以及更多的支持人员。专家的费用并不是非常高昂，可另一个障碍是我们对这种技术的理解仍然是比较原始的。最后，将模型投入生产环境并保持最新是最后的障碍。
因为在生产环节中，通常只有使用用与学习过程的相同昂贵且复杂的架构，模型才能实现在学习过程中创建的结果。我们应该理解，部署到生产环节是一个过程，而不是一个步骤，它需要在模型开发的很久之前就开始。它的第一步是定义业务目标、可以从数据中提取的价值假设和用于其业务的商业思路。
机器学习运维——是一个结合了机器学习过程和在商业过程中实现所开发的模型的方法的技术。这个概念作为一种与机器学习模型和机器学习方法相关的开发运维技术而出现。开发运维是一种软件开发的方法，它提升了单个变动的实施速度，并与此同时保持了灵活性和可靠性。
它通过多种方法来达成这一点，包括持续开发。将功能划分成多个独立的微服务、自动化测试以及自动化部署单个变动、全局性能监视、对所检测到的故障的快速响应，等等。
MLOps，或者是用于机器学习的开发运维，允许数据科学团队和 IT 团队协作，并通过监控、验证和管理模型，来加速模型的开发和实现。
当然，这个领域也没有什么特别新的技术——每个人都曾经或多或少的接触过这些技术。现在仅仅是新出现了一个炒作词汇，其背后往往是现成的解决方案，例如 Seldon、Kubeflow、或者 MLflow。
除此之外，有许多工具能将机器学习模型部署到生产环节，除了我们上述已经提到的工具之外，我认为最流行的工具有 TensorFlow Serving 和 Vowpal Wabbit。现有的机器学习平台所使用的管理机器学习应用生命周期（从数据到实验到生产环节的）的方法也值得研究：Google TFX、Facebook FBLearner、Uber Michelangelo、AWS Sagemaker、Standford DAWN、 TensorFlow Extended、Airbnb 的 Bighead 等等。
结论
最后，我写了很多东西，但看起来像什么都没说。我绝不认为自己是所有方面的专家，在本文，我仅仅是对技术进行了一些考证与猜测。但是，正如你从文章中所看到那样，许多技术在大数据的不同领域都有重叠，而且还不止于此。掌握了它们，你就不用担心找不到工作。但不要一味追求技术的潮流，而是要掌握与时俱进的技能。而且，最关键的技能很可能是软技能。
与数据工程相关的学习曲线本来就很陡峭了，现在还在变得更加陡峭。开发人员的编程项目的背后需要对企业各个领域的知识和对许多工具和现有解决方案的了解。
在数据管理方案，我们还处在“西部大开发”的阶段，特别是在机器学习领域。
英文：Luminousmen，翻译：infoQ
- EOF -
推荐阅读 点击标题可跳转看完本文有收获？请转发分享给更多人
关注「大数据与机器学习文摘」，成为Top 1%
点赞和在看就是最大的支持❤️