记一次数据仓库选型讨论

近日，工程师们讨论数据平台和数据仓库选型问题。

备选考虑：

1. MySQL
2. PostgreSQL
3. GreenPlum
4. Teradata
5. HDFS + Hive
6. HBase
7. MongoDB
8. Oracle RAC

需求情况：

1. 业务量不高（DAU < 100），数据量不大（GB量级），未来半年到一年内数据量应该在TB量级以下。
2. 主要用于离线数据分析场景，暂时不需要支持实时分析，可能涉及复杂查询，未来会需要支持上层报表系统，不排除会开放给个别非技术人员使用。
3. 业务部门目前阶段没有明确的数据需求，半年内预计会有推广活动，届时会有活动数据监测分析和指标统计等需求。
4. 不会有采购商业级产品的预算，所以必须考虑开源产品。

以下是一些选型分析：

1. 成本角度

• 因为没有预算支持，那么Teradata和Oracle RAC都可以删掉了。

2. 应用场景角度

• 数据仓库的需求更多是OLAP需求而不是OLTP需求，所以面向OLTP场景优化的方案，像MySQL、HBase，可以排除了。
• 至于MongoDB，也有人用它跑Map-Reduce against non-structured data，但是更多是对业务系统的一种trade-off？

3. 规模角度

• 对于现有以及未来一段时期内的数据量，以上各种方案都可以支撑。
• Oracle RAC这样的解决方案更多应用实例是少量节点集群（几台到十几台）和scale up场景。
• 100个节点的量可以考虑Hadoop集群。
• Pg加上plproxy水平分片可以很容易scale out。

4. 易用性角度

• 如果考虑可能给非技术人员使用，SQL-like界面会更好。
• 如果将来可能对接成熟的报表系统，而不是从头开发，那么SQL界面会是必须。
• 业务运营的数据adhoc需求如果会占到一定量比例，那么用SQL和存储过程来解决会比写adhoc代码要更快速、更敏捷，运营人员能够更快拿到结果，工程师面临需求频繁变更的痛苦也会更小。

5. 运维难度和社区成熟度

• Greenplum社区还是较薄弱。没有运维经验。
• 商用系统如果不付费难以得到有效支持，遇到问题不易解决。

综上，建议方案是pg sharding + plproxy。

【延伸阅读】PostgreSQL 最佳实践 - 水平分库(基于plproxy) https://yq.aliyun.com/articles/59345

QY 20180209