@asukanoir 我觉得 BI 定义还是很广。偏技术的往往就是 etl 和数据仓库，偏业务的就是 dashboard 和分析。

@cdlixucd 的确。。。现在 bi 烂大街了，奈何我还挤不进去。。。

bi 的确业务最重要。你这个需要做 dashboard 和数据建模么？不需要的话基本上就是 ba。

BA 强答：主要是 Excel 不能代替。。。

@outerws 啊这个是很早的东西了，八十年代的，最早一代文字冒险游戏的解析器。。。

据我所知这玩意最核心的就是 Parser，有兴趣的话可以看看 Zork Implementation Language，算是这块的老祖宗，但是现在看还是很牛逼的，相当于一个解析器。

Visual Studio

b 是个字符串，所以你每次打 b 无非就是出来字符串里头的内容。严格地说是 b 这个 name 指示的地址里头的内容。你可以再次给 b 赋值，就会变化了。但是这时候其实是指向另外一个地址。

```
>>>b
'a2019-12-04 23:20:53'
>>>hex(id(b))
'0x2126325b580'
>>>b = "a" + my_time()
>>>b
'a2019-12-04 23:21:15'
>>>hex(id(b))
'0x2126325b850'
```

@fff333 技术方面还是看 @SlipStupig 的帖子，我那个是流程的。。。

@cco +1 KIMBALL 的书都可以看看

@SlipStupig 微信号 Et-tu-Brute 多谢啦！还要多多请教

@SlipStupig 我这做 BA 挤破头想做 BI。。。

@SlipStupig 好羡慕你们这些有机会做 BI 的。。。

技术上我说不了太多，因为作为 BA 我只是消费者，不是生产者，虽然努力争取转 BI。

但是流程上，大体上我们公司是这样：（注意这是在数据仓库已经建好、ETL 已经稳定的情况下）

1. 业务出 Feature 设想，召集各部门的人开会 （ Server/Client 程序员、BI、BA 都有人参加）

2. 前几次会议主要是固定需求，以及和程序员确定技术上都可行，然后划定需要几个 Sprint

3. 接下来业务会和 BI 以及 BA 讨论这个 feature 需要几个 KPI，然后 BI 和 BA 把 KPI 划分成 Dashboard 和 Analysis，一般是 BI 负责 Dashboard，BA 负责 Analysis，不过也有重合的情况。Dashboard 偏重监控，analysis 偏重分析。

4. 接下来 BI、BA 和 Server/Client 讨论需要什么样的 telemetry （在我们这里，就是说 JSON 里头应该包括哪些 field, 什么格式，等等）

因为我自己是 BA，所以技术上我在这段之后就不进行追踪了，但是据我所知，BI 接下来应该就是准备 ETL 和建表或者仓库（小的 feature 建表甚至加列就够了，大的 feature 需要建新的仓库）。ETL 是有专人做好的 Python + Airflow + Kafka，然后进 Vertica 和 Databricks，BI 写好 scheme， 让 server 出数据测试成功之后就可以用了。

基本上小 Feature 3-4 个 JIRA （ 6-8 周），大 Feature 5-6 个 JIRA （ 10-12 周），估计比国内是要慢一些，但是我们同时会有几个 Feature 在进行，所以每个 BI 同时都要追踪 3 个左右的 feature。

等到 feature 出来前后，BI 还需要做 Tableau Dashboard，然后上传到 Tableau Server。但是报表这块可用的工具很多，Server 监控的话 Grafana 也不错。

背景：BA，不过和 BI 经常接触所以知道一些。

第一部分：数据仓库（纯听说加总结）
多数据来源融合的话，我估计你需要的是数据直接进数据仓库。要做的就是写 ETL 进某个数据仓库，100TB 的话我觉得目前市场上常见的都没问题，甚至本地的 PostgreSQL 应该都可以，毕竟你数据仓库里头主要需要的是聚合表。

数据仓库的建立可以看看 Data Modelling 的书，因为你数据来源比较繁杂，所以可能需要分别写 ETL，总之感觉比较麻烦的样子。我们公司数据来源比较单一，主要就是 APP 内部的 telemetry，走 Kafka 到 parser 然后到数据库，最后聚合到数据仓库。你们估计没有这么强的实时性需求。

另外看起来你们应该是需要很多数据仓库的样子，比如说监控和营收肯定是不同的数据仓库。

第二部分：可视化和分析
这块我比较熟悉，Power BI 和 Tableau 都做过，虽然经验都不超过一年。这块其实技术上都没啥难度（除非你准备做数据科学的活），大多数应该都是监控和简单的分析，所以最主要的是数据仓库的架构和需求的分析。这个要看具体了，但是你们必须先和 Business 商量好每件事情的 KPI。

最重要的，其实我觉得还是得从一开始就让业务介入，每次开会都必须要让业务清楚的知道，他想要你们做什么，然后你们是如何把他的需求转化成技术，最后是如何让业务那边的分析（或者你们自己做这块也可以）用你们的技术，出业务需要的报表。重复一下，业务必须深度介入，否则这件事情没法搞。我觉得比较理想的情况是，每一个业务分支都有自己的分析，并且熟悉 SQL, 或者愿意学习 SQL，这样你们就只需要做监控和自动化报表就可以了。能够自动化的全部自动化。数据挖掘什么的留给他们就行，当然除非你也想做，但是估计你精力跟不上。数据仓库这种东西需要经常维护的。

还有一点，这肯定是个很长期的过程，所以需要你们领导知道这点，不是几个礼拜的事情，而是几个月的事情。所以这个事情得有个比较牛逼的人做架构，定好里程碑，不然又是乱七八糟。架构弄不好，整个公司都吃亏。如果需求是在紧张，可以让大领导拍板挑一个最急需的业务线出来，做一个 Data Mart 作为示范。

抛异常我觉得也蛮好的，至少比返回 tuple 感觉舒服一些。