回顾一下两年前使用的无效日志，我们有超过 800 种的日志类型，容易出错，缺乏很多监测，导致数据事故和数据丢失，也对整个公司和数据平台造成不信任。

这是真实的邮件，每次产生数据事故之后都会发报告，告诉大家我们在代码重构中不小心丢失了日志中间的某个域，导致数据错误或不能被使用，甚至完全把某一种日志丢掉了。

针对这种情况我们就想到了需要对日志的格式进行约束，我们选择了 Apache Thrift，是与语言无关的格式定义语言，有丰富的客户端，支持 Java、Ruby、JS、Mobile 的开发端。这个语言本身比较简单、容易理解，有助于让数据科学家和产品工程师共同去定义这种日志格式，因为日志不光是要发送，还要被数据科学家所理解去处理，所以我们觉得 Apache Thrift 能够满足这样的协议。同时我们定义了标准的开发流程，让大家遵照这个开发流程。

为什么选择 Thrift 呢？第一是语法比较直观，非工程师也容易理解。第二点，它在 Ruby 环境中有良好的性能。同时日志格式信息和开发文档统一存取。第四，我们也有严格的版本管理信息，比如日志是前项还是后项的兼容性，在日志的进化当中，可以保证日志不会破坏后台的处理。同时我们也给出了相应的统一发布流程，可以发布 Jar、Gem 文件，使得后端服务和客户端可以使用这样的日志模式。

这是简单的例子，我们定义了这么一个日志格式，在 Java 和 Ruby 语言当中，有一些 field 必须在日志中间，还有一些 field 是可选的。

这是在 JS 当中有这样的格式之后，开发过程中如果忽略了一些必须的 field，开发时候发现错误及时更正，避免错误。

这是有了日志格式之后的开发流程。首先要定义格式，数据科学家和工程师共同定义这个格式，然后通过统一的发布流程，把数据日志发送到服务器或者客户端，客户端或服务器就会用这个日志格式产生日志，通过相应的流处理应用，将日志发送到数据仓库，最后在数据仓库中间对日志进行丢失检测、异常查询。

我们也开发一些前端的应用，使得用户能够非常方便地通过关键字查找日志，并且日志格式提供了一些元数据，如日志的作者、版本等等。同时我们也做一些简单代码的模板生成或者查询语言生成，比如给定日志之后可以对不同语言类型产生代码样板，在不同语言环境下简单地使用日志。

实时流处理

上面提到的三点就是模块级别的监测、端到端的审核和日志的格式。现在越来越多的应用需要实时的处理，因此在日志系统中间加入了实时流处理。

回顾一下之前整个日志的框架。有前端的移动端和服务，日志通过代理服务器或者直接进入 Kafka 总线。引入了流处理之后发生了大变化，通过 AirStream 这个流处理平台，数据实时地被 AirStream 处理，放入 Hbase，Hbase 是现在使用的存储方案，Druid 是多维度统计的存储时间序列的平台。我们有定时的作业可以把 Hbase 或实时的作业批量放到 Hbase 数据仓库中间，同时我们开发了 Presto 在 Hbase 上面的接口，使得用户可以用 Presto 对这些实时的数据进行查询。在反馈流程上面，除了原来的批处理反馈同时也引入了实时的反馈，可以将实时的信号反馈给产品服务器，使它能够做出更好的改进。

这是实时处理的一些重要的部件。第一基于 Spark Streaming 对实时数据进行了实时注入。第二我们使用了 HBase 对数据进行去重，并且按照数据类型进行分片，同时开发了 Hive/Presto 接口访问 Hbase，提供日志的实时查询，同时我们对数据进行实时多维度聚合的操作。