大家要分几个层面看问题。

- 12306 这套东西大家都没考虑到它的历史包袱，最早的是时候为什么那么慢那么难用，是因为最早的 12306 是一个内部版本也就是以前在代售点那套系统，这套东西和铁路调度系统是强绑定的，当时 12306 是双系统制，外部下单相当于多了几个亿的火车票代售点，然后去提交，但是实际情况远远超过了当时铁总设计的预期，所以被骂的要死。
- 业务复杂度从最基本的票务类型开始算就很多类型：团体票、个人票、学生票，然后依次是座位类型和价格要进行动态计算价格，然后上架库存（觉得不以为然的自己可以尝试一下），然后就是噩梦的开始，用户一旦刷不出来票来就会拼命的刷新，本身就高负载遇到更大的压力，然后票务面临退改签这个过程要保证尽量不要出错，而且还要快速响应，确认作为后还要跟铁路系统对接，这个东西复杂度难以想象，当年只花了 3 个亿能做成已经相当不易。

@kaedea 贩毒依然有人干啊。。我觉得倒卖火车票的风险和利润比，比贩毒不会差。

@timedivision 这个不是问题，明确定义换什么就行

@Unclev21x 这个说到点上上了

@designer 以物换物啊
@imn1 并没有

@gebishushu 租赁有风险，如果被恶意掉包或者被弄坏，会搞得平台里里外外不是人

@watzds 你管她是做啥的，没事多围着妹子去打转去，连跟人处对象的勇气都没有，怎么证明你真的喜欢人家啊。你说工作上没有交集这个，完全是给自己找借口（不是“我”不行，是人家跟“我”没交集），谈恋爱这种事，有机会就上，没机会也要床罩机会上，你要这么怂就别谈了，有真心浪费，别耽误人家姑娘了好不

这个根本不是问题，你就跟她说想学一些前端的问题，要不周末出来一起见一下，同意就有戏

一尘科技，取自 "众里嫣然通一顾,人间颜色如尘土。 ——王国维 《人间词》"

调整一下 JVM 配置，给更多的内存，我 MBP 给了 4G 内存，稳定的很

@yellowmarlboro

公司项目千万别给自己团队增加学习，稳定快速构建压倒一切。架构可以迭代的，这个不是问题。

ETL 部分是最复杂的，也是最繁琐的，由于我不知道你这边实际情况怎么样，所以我只能从最坏的场景假设，我推荐使用两段式 ETL，具体做法如下：
第一阶段：日志收集和清洗，将日志一些无效、异常和缺失的数据要么过滤，要么基于算法补全。这个可以用 filebeat+ELK 架构（ ES 可以设置 TTL，TTL 值可以设置一周），这个数据丢失其实并不影响，大不了重跑（这里有个风险点，有数据泄露风险，所以传输过程一定要强加密，这个一定要重视，数据安全无小事）

第二阶段阶段，可以基于定时任务每天定时处理前一天任务，这个时候业务会特别复杂，所以可以使用 celery 或者 airflow 进行定制化开发 pipelines，主要工作有：数据富化、字段对齐、字段标准化、字段含义统一(sip 和 source_ip 可能是同一个意思，这个时候需要用 tdidf 等相似度算法来计算字段，还有一些“无头数据”，通过正文内容预测字段含义)、数据格式统一（例如：日期到底是时间戳还是 UTC 时间），数据格式输出格式标准化（是用 JSON 还是 YAML 或 XML 等），建立 index_id 这个是一条数据的唯一标识，用于跟踪数据流转过程

切记一定要有日志，所有的数据生命周期内必须要能完整跟踪到一条数据整个流转过程，如果在发现无法跟踪的数据进入了系统，一定要删除掉！

@levelworm 留个联系方式，可以一起聊一下😊

TDD 能治好你的病

@levelworm 并不是 BI，数据勤杂工。。

千万不要相信用 ES 去做数据仓库，Elasticsearch 不是数据库，而是一个搜索引擎，只是很多人把它当做数据库使用，ES 不适合数据仓库的原因有如下几点：

- 数据在一些统计聚合方面便利性和性能都不够（按时间维度进行复杂聚合用 ES 简直是灾难）
- 由于 ES 特性，如果你想保证数据不丢失就需要更多副本，那么就需要更多的资源开销，主要体现在几个方面
- 当数据崩溃后需要恢复的时间很长，我手里面用的 SAS RAID5 的盘，有 1T 数据恢复时间大概需要 5 分钟
- ES 想要稳定的运行那么就需要海量的内存，更多的硬盘空间，这块成本会增加很多

---

作为一个踩过数据仓库神坑的过来人，分享一点点经验可供参考。

1. 为什么要建立数据仓库？建立之后可以带来什么收益？（这点看上去是废话，实际上非常重要，很多企业建立数仓目标都不清楚，主要是看 BAT 都在弄，自己也得弄）
2. 数据调研
2.1 设计一个访谈表格（ eg：数据时间范围，业务来源等业务相关的东西）
2.2 对数据相关负责人进行了解业务模式和特点
2.3 设计数据交互标准（ eg：什么时候提交，什么格式，什么时间提交，什么方式等等，这个根据 2.1 和 2.3 来定）

3. ETL 方案确立
3.1 定义清洗方案（ eg：字段缺失，字段含义统一、无效标准等等）
3.2 数据转换，转换成标准格式或进行进一步富化
3.3 数据脱敏，对于关键数据传输要进行脱敏

4. 数据建模
4.1 确定维度表和事实
4.2 确定使用的数据仓库模型（ eg: 雪花型、星型还是星座型）
4.3 确定 index key

5. 确定整体技术架构
5.1 先确定自身项目数据容量和未来增长率
5.2 留好一个万能可扩展接口（哪怕未来实现扩展非常狼狈也要留出来，关键时候可以避免架构推倒重来）
TIPS: 没有万能的方案，需要考虑自身实际情况，比如你的项目人员都是 python 开发人员，那么千万别使用 Hadoop 生态，还有自身硬件和数据条件浙西都应该去考虑

6. 数据工厂

- 根据业务进行数据产品加工抽象方法（需要定义一套完整的 dataflow，eg：A 数据和 B 数据，根据 uid 进行 merge 然后产生 C 数据，形成新的事实表）
- 提供基础访问 API 接口，比如：支持一个 SQL 查询
TIPS:千万不要提供业务相关的 API，不仅不能很好的满足，而且会拖累整体质量

7. 数据审计
1. QOS
2. 权限管理
3. 数据流转过程

门槛低是好事，说明有充足的就业机会，如果你去上班最少得清华的博士，而且要求父母年收入不能低于 500 万，身高不低于 180 这个时候你又会抱怨这些门槛不合理

@berforest
@owencodeing
万一被抓了，公司项目组岂不是被团灭了 2333

兄弟还招人不，对你这个很感兴趣，做了好几次都没成功，希望能搭车再赌一次😄