Bosch IoT 和应用程序驱动型分析的重要性

然而，要做到这一点，企业不能再仅仅依靠将数据从操作系统复制到单独的分析存储中。移动数据需要时间。相反，分析必须能够顺滑平移到应用程序本身的数据源。

“没有数据的支撑，就只是一次又一次的试错。”Kai Hackbarth如是说。他是 Bosch全球软件部门的高级技术宣传负责人，在物联网领域拥有超过 22 年的行业经验。“不论是汽车、工业、还是智能家居，我们都有相关经验。”Hackbarth 说。但轮胎是个例外，他最近正密切关注该领域及技术挑战。

“听起来可能挺简单的，”Hackbarth 表示，“但细想的话，[其实很复杂]。”

因为实践证明，轮胎可以收集大量不同类型的数据，让系统全面了解汽车在某一时间不同部件的运作状态。

“压力、温度、加速计，”Hackbarth 说道，“当然还有其他数据……对汽车安全和可持续性有重要影响。”

但是，想要发挥数据的真正价值，就需要在尽可能靠近来源的位置对其进行实时分析。为什么？

“事关安全大事儿，数据的全面性非常重要，”Hackbarth 说道，“但想要将全部原始数据上传到云中，会消耗大量成本。”

其中上传数据需要花费的时间是主要成本。

要想对问题做出反应，就不能依赖历史数据。因为与轮胎失压或湿路打滑相关的历史数据对车载应用程序并无意义，而这些应用程序恰好又需要在发生这种状况时作出及时响应。

所幸，Hackbarth 及他在 Bosch 的团队能够将实时分析技术部署到其应用程序中，处理海量数据。

一直以来，应用程序和分析都作为两个不同类别的工作负载而存在。因此，读写访问模式、并发及延迟等需求也不同。企业通常会部署专属的数据存储区，包括适用于应用程序的数据库以及适用于分析的数据仓库，然后再在这两种数据存储区之间输送或复制数据。

这种做法效果不错，但前提是，分析不需要影响应用程序实时响应的方式。然而，大多数客户期望应用程序能够在当下就采取智能措施，而不是事后补救。

Bosch 的轮胎项目同样以此为原则。要让一辆速度过快的车在逼近另一辆车时能够主动刹车，或是在轮胎感测到湿路打滑时减速，车载应用程序就需要能够实时分析从所有传感器传来的全部数据。

将实时分析内置到应用程序的这个过程称为“应用程序驱动型分析”。应用程序就是通过这种方式变得更加智能的。手机上的电商应用程序、车载安全应用程序以及能够监控火箭发射的应用程序都属于这类智能应用程序。

对于许多开发团队来说，他们需要关注应如何轻松地将这个功能内置到自己的应用程序中。在很长一段时间里，这都是一个亟待解答的难题。

“根据我从业22 年的经验，”Hackbarth 说道，“我们从未具备这能力。”

此前，各个公司的团队 (不单是 Bosch 的团队) 都不得不做大量的定制工程工作，才能在靠近来源的位置实现实时分析：

1）拼凑多个数据库来处理不同数据结构（文档、表格、时间序列测量数据、键值、图形等），且需要通过独有的查询 API 来访问每一种数据结构。

2）打造 ETL 数据管道，将数据转换为所需的分析格式，再将数据从实时数据库分层为成本更低的对象存储。

3）加速运转联盟查询引擎，跨各个数据层运作，且利用的还是自己独有的查询 API。

4）集成Serverless，响应实时数据变化。

5）设立自己的 API 层，将数据提供给使用中的应用程序。

以上操作会产生众多需要处理的运营和安全模型、大量数据集成工作以及大量数据复制。

然而，今时不同往日。市面上已有能够将运营和分析工作负载整合到一处的数据平台，进而将实时运营数据和实时分析结合起来。

我就在 MongoDB 任职，因此十分熟悉 MongoDB Atlas 平台。它能够为开发人员提供契合其工作流程的一系列集成式数据和应用程序服务。

开发人员能够载入任意结构的数据，以自己想要的任何方式索引、查询及分析数据，然后再对其进行归档。值得一提的是，无需打造自己的数据管道或复制数据，只需通过一个统一的 API 就能完成所有这些操作。

Bosch 团队就是以该平台为基础持续打造自己的解决方案。

Hackbarth 表示，“没有数据的支撑，就只是一次又一次的试错。”如今，有了数据和单一平台之后，他们能够将实时分析内置到应用程序中，收获兼顾响应能力和可行性的切实成果，变得更加智能。对于 Bosch 正在推进的轮胎项目及其他关键用例来说，他们尤其看重这个特质。

8月29日 北京站

8月31日 深圳站