近日，工程师们讨论数据平台和数据仓库选型问题。
备选考虑：
- MySQL
- PostgreSQL
- GreenPlum
- Teradata
- HDFS + Hive
- HBase
- MongoDB
- Oracle RAC
需求情况：
- 业务量不高（DAU < 100），数据量不大（GB量级），未来半年到一年内数据量应该在TB量级以下。
- 主要用于离线数据分析场景，暂时不需要支持实时分析，可能涉及复杂查询，未来会需要支持上层报表系统，不排除会开放给个别非技术人员使用。
- 业务部门目前阶段没有明确的数据需求，半年内预计会有推广活动，届时会有活动数据监测分析和指标统计等需求。
- 不会有采购商业级产品的预算，所以必须考虑开源产品。
以下是一些选型分析：
- 成本角度
- 因为没有预算支持，那么Teradata和Oracle RAC都可以删掉了。
- 应用场景角度
- 数据仓库的需求更多是OLAP需求而不是OLTP需求，所以面向OLTP场景优化的方案，像MySQL、HBase，可以排除了。
- 至于MongoDB，也有人用它跑Map-Reduce against non-structured data，但是更多是对业务系统的一种trade-off？
- 规模角度
- 对于现有以及未来一段时期内的数据量，以上各种方案都可以支撑。
- Oracle RAC这样的解决方案更多应用实例是少量节点集群（几台到十几台）和scale up场景。
- 100个节点的量可以考虑Hadoop集群。
- Pg加上plproxy水平分片可以很容易scale out。
- 易用性角度
- 如果考虑可能给非技术人员使用，SQL-like界面会更好。
- 如果将来可能对接成熟的报表系统，而不是从头开发，那么SQL界面会是必须。
- 业务运营的数据adhoc需求如果会占到一定量比例，那么用SQL和存储过程来解决会比写adhoc代码要更快速、更敏捷，运营人员能够更快拿到结果，工程师面临需求频繁变更的痛苦也会更小。
- 运维难度和社区成熟度
- Greenplum社区还是较薄弱。没有运维经验。
- 商用系统如果不付费难以得到有效支持，遇到问题不易解决。
综上，建议方案是pg sharding + plproxy。
【延伸阅读】PostgreSQL 最佳实践 - 水平分库(基于plproxy) https://yq.aliyun.com/articles/59345
QY 20180209
