四种类型的数据分析模式
什么是数据科学家最重要的能力 － 最重要的能力将是能够把数据转化为对非专业人士而言清楚而有意义的见解。
描述型：发生了什么？
这是最常见的一种。在业务中，它向分析师们提供业务的重要衡量标准的概览。一个例子是每月的利润和损失账单。类似地，分析师可以获得大批客户的数据。了解客户（如，30%的客户是自雇型）的地理信息也可认为是“描述型分析”。充分利用可视化工具能增强描述型分析所带来的信息。
诊断型：为什么会发生？
这是描述型分析的下一步难题。通过评估描述型数据，诊断分析工具使得分析师们能够深入分析问题的核心原因。设计良好的商业信息dashboard整合了时间序列数据（譬如，在多个联系时间点上的数据）的读入、特征的过滤和钻入功能，能够用于这类分析。
预测型：可能发生什么？
预测型分析主要是进行预测。某事件在将来发生的可能性，预测一个可量化的值，或者是估计事情可能发生的某个时间点，这些都可以通过预测模型完成。预测模型通常运用各种可变数据来作出预测。数据成员的多样化与可能预测的目标是相关联的（如，人的年龄越大，越可能发生心脏病，我们可以说年龄与心脏病风险是线性相关的）。随后，这些数据被放在一起，产生分数或预测。在一个充满不确定性因素的世界里，能够预测允许人们作出更好的决定。预测模型在很多领域都被用到。
指导型：我需要做什么？
在价值和复杂度上，下一步就是指导性模型。指导性模型基于发生了什么、为什么会发生以及一系列“可能发生什么”的分析，帮助用户确定要采取的最好的措施。很显然，指导性分析不是一个单独的行为，实际上它是其他很多行为的主导。交通应用是一个很好的例子，它帮助人们选择最好的回家路线，考虑到了每条路线的距离、在每条路上的速度、以及很关键的目前的交通限制。另一个例子是生成考试时间表，不让任何学生的时间表发生冲突。
时序数据库
背景
时序数据库作为物联网方向一个非常重要的服务，业界的频频发声，正说明各家企业已经迫不及待的拥抱物联网时代的到来。2017 年时序数据库忽然火了起来。开年 2 月 Facebook 开源了 beringei 时序数据库；到了 4 月基于 PostgreSQL 打造的时序数据库 TimeScaleDB 也开源了，而早在 2016 年 7 月，百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品 TSDB，成为支持其发展制造，交通，能源，智慧城市等产业领域的核心产品，同时也成为百度战略发展产业物联网的标志性事件。
百度无人车在运行时需要监控各种状态，包括坐标，速度，方向，温度，湿度等等，并且需要把每时每刻监控的数据记录下来，用来做大数据分析。每辆车每天就会采集将近 8T 的数据。如果只是存储下来不查询也还好（虽然已经是不小的成本），但如果需要快速查询“今天下午两点在后厂村路，速度超过 60km/h 的无人车有哪些”这样的多纬度分组聚合查询，那么时序数据库会是一个很好的选择。
什么是时序数据库
时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析，机器学习，实现预测和预警。
时序数据库就是存放时序数据的数据库，并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。对比传统数据库仅仅记录了数据的当前值，时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。
基本概念
下面介绍下时序数据库的一些基本概念（不同的时序数据库称呼略有不同）。
- metric: 度量，相当于关系型数据库中的 table。
- data point: 数据点，相当于关系型数据库中的 row。
- timestamp：时间戳，代表数据点产生的时间。
- field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个 field。一般情况下存放的是会随着时间戳的变化而变化的数据。
- tag: 标签，或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp 加上所有的 tags 可以认为是 table 的 primary key。
时序数据库挑战
很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题，但少量数据是展现的纬度有限，细节少，可置信低，更加不能用来做大数据分析。很明显时序数据库是为了解决海量数据场景而设计的。
可以看到时序数据库需要解决以下几个问题
- 时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。
- 时序数据的读取：又如何支持在秒级对上亿数据的分组聚合运算。
- 成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
