1번: 철수
2번: 영희
3번: 영수

WITH RECURSIVE cte (n) AS
(
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM cte WHERE n < 5
)
SELECT * FROM cte;

명령문을 실행하면 간단한 선형 시퀀스를 포함하는 단일 열인 다음 결과가 생성됩니다.

+------+
| n    |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
+------+

•  WITH 절의 CTE가 자신을 참조하는 경우 WITH 절은 WITH RECURSIVE로 시작해야 합니다. (CTE가 자신을 참조하지 않으면 RECURSIVE가 허용되지만 필수는 아닙니다.) 재귀 CTE에 대한 RECURSIVE를 잊은 경우 다음 오류가 발생할 수 있습니다.

ERROR 1146 (42S02): Table 'cte_name' doesn't exist

• 재귀 CTE 하위 쿼리에는 UNION ALL 또는 UNION [DISTINCT]로 구분되는 두 부분이 있습니다.

SELECT ...      -- return initial row set
UNION ALL
SELECT ...      -- return additional row sets

• 첫 번째 SELECT는 CTE에 대한 초기 행을 생성하며 CTE 이름을 참조하지 않습니다. 두 번째 SELECT는 추가 행을 생성하고 FROM 절에서 CTE 이름을 참조하여 재귀합니다. 이 부분이 새 행을 생성하지 않으면 재귀가 종료됩니다. 따라서 재귀적 CTE는 비재귀적 SELECT 부분과 재귀적 SELECT 부분으로 구성됩니다.각 SELECT 부분은 그 자체로 여러 SELECT 문의 합집합이 될 수 있습니다.

CTE 결과 열의 유형은 비재귀적 SELECT 부분의 열 유형에서만 유추되며 열은 모두 null을 허용합니다. 유형 결정의 경우 재귀 SELECT 부분은 무시됩니다.

비재귀 부분과 재귀 부분이 UNION DISTINCT로 구분되면 중복 행이 제거됩니다. 이는 무한 루프를 피하기 위해 전이적 폐쇄(transitive closures)를 수행하는 쿼리에 유용합니다.

재귀 부분의 각 반복은 이전 반복에서 생성된 행에서만 작동합니다. 재귀 부분에 여러 쿼리 블록이 있는 경우 각 쿼리 블록의 반복은 지정되지 않은 순서로 예약되며 각 쿼리 블록은 이전 반복이 종료된 이후 또는 다른 쿼리 블록에서 생성된 행에서 작동합니다.

SELECT 1

SELECT n + 1 FROM cte WHERE n < 5

WITH RECURSIVE cte AS
(
  SELECT 1 AS n, 'abc' AS str
  UNION ALL
  SELECT n + 1, CONCAT(str, str) FROM cte WHERE n < 3
)
SELECT * FROM cte;

+------+------+
| n    | str  |
+------+------+
|    1 | abc  |
|    2 | abc  |
|    3 | abc  |
+------+------+

ERROR 1406 (22001): Data too long for column 'str' at row 1

WITH RECURSIVE cte AS
(
  SELECT 1 AS n, CAST('abc' AS CHAR(20)) AS str
  UNION ALL
  SELECT n + 1, CONCAT(str, str) FROM cte WHERE n < 3
)
SELECT * FROM cte;

+------+--------------+
| n    | str          |
+------+--------------+
|    1 | abc          |
|    2 | abcabc       |
|    3 | abcabcabcabc |
+------+--------------+

WITH RECURSIVE cte AS
(
  SELECT 1 AS n, 1 AS p, -1 AS q
  UNION ALL
  SELECT n + 1, q * 2, p * 2 FROM cte WHERE n < 5
)
SELECT * FROM cte;

+------+------+------+
| n    | p    | q    |
+------+------+------+
|    1 |    1 |   -1 |
|    2 |   -2 |    2 |
|    3 |    4 |   -4 |
|    4 |   -8 |    8 |
|    5 |   16 |  -16 |
+------+------+------+

• 재귀 SELECT 부분은 다음 구문을 포함해서는 안 됩니다. MySQL 8.0.19 이전에는 재귀 CTE의 재귀 SELECT 부분도 LIMIT 절을 사용할 수 없었습니다. 이 제한은 MySQL 8.0.19에서 해제되었으며 이제 LIMIT가 선택적 OFFSET 절과 함께 이러한 경우에 지원됩니다. 결과 집합에 미치는 영향은 가장 바깥쪽 SELECT에서 LIMIT를 사용할 때와 동일하지만 재귀 SELECT와 함께 사용하면 요청된 행 수가 생성되는 즉시 행 생성을 중지하므로 더 효율적입니다.
• 이러한 제약 조건은 재귀 CTE의 비재귀 SELECT 부분에는 적용되지 않습니다. DISTINCT에 대한 금지는 UNION 회원에게만 적용됩니다. UNION DISTINCT는 허용됩니다. 
  • Aggregate functions such as SUM()
  • Window functions
  • GROUP BY
  • ORDER BY
  • DISTINCT
• 재귀 SELECT 부분은 하위 쿼리가 아닌 FROM 절에서만 한 번만 CTE를 참조해야 합니다. CTE 이외의 테이블을 참조하고 CTE와 조인할 수 있습니다. 이와 같은 조인에서 사용되는 경우 CTE는 LEFT JOIN의 오른쪽에 있어서는 안 됩니다.

재귀 CTE의 경우 재귀 SELECT 부분에 재귀를 종료하는 조건이 포함되어 있다는 것이 중요합니다. 런어웨이 재귀 CTE를 방지하기 위한 개발 기법으로 실행 시간을 제한하여 강제 종료할 수 있습니다.

재귀 CTE가 재귀 실행 종료 조건 없이 실수로 작성되었다고 가정합니다.

WITH RECURSIVE cte (n) AS
(
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM cte
)
SELECT * FROM cte;

기본적으로 cte_max_recursion_depth 값은 1000이므로 CTE가 1000 수준을 초과하여 재귀하면 종료됩니다. 애플리케이션은 요구 사항에 맞게 세션 값을 변경할 수 있습니다.

SET SESSION cte_max_recursion_depth = 10;      -- permit only shallow recursion
SET SESSION cte_max_recursion_depth = 1000000; -- permit deeper recursion

이후에 시작되는 모든 세션에 영향을 미치도록 전역 cte_max_recursion_depth 값을 설정할 수도 있습니다.

쿼리가 느리게 실행되어 반복되는 경우 또는 cte_max_recursion_depth 값을 매우 높게 설정해야 하는 상황에서 깊은 반복을 방지하는 또 다른 방법은 세션당 시간 제한을 설정하는 것입니다. 이렇게 하려면 CTE 문을 실행하기 전에 다음과 같은 문을 실행하십시오.

SET max_execution_time = 1000; -- impose one second timeout

또는 CTE 문 자체에 옵티마이저 힌트를 포함합니다.

WITH RECURSIVE cte (n) AS
(
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM cte
)
SELECT /*+ SET_VAR(cte_max_recursion_depth = 1M) */ * FROM cte;

WITH RECURSIVE cte (n) AS
(
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM cte
)
SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM cte;

MySQL 8.0.19부터 재귀 쿼리 내에서 LIMIT를 사용하여 가장 바깥쪽 SELECT에 반환할 최대 행 수를 지정할 수도 있습니다. 예를 들면 다음과 같습니다.

WITH RECURSIVE cte (n) AS
(
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM cte LIMIT 10000
)
SELECT * FROM cte;

시간 제한을 설정하는 대신 또는 추가로 이 작업을 수행할 수 있습니다. 따라서 다음 CTE는 10,000개 행을 반환하거나 1초(1000밀리초) 동안 실행한 후(둘 중 먼저 발생하는 경우) 종료됩니다.

WITH RECURSIVE cte (n) AS
(
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM cte LIMIT 10000
)
SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM cte;

실행 시간 제한이 없는 재귀 쿼리가 무한 루프에 빠지면 KILL QUERY를 사용하여 다른 세션에서 종료할 수 있습니다. 세션 자체 내에서 쿼리를 실행하는 데 사용되는 클라이언트 프로그램은 쿼리를 종료하는 방법을 제공할 수 있습니다. 예를 들어, mysql에서 Ctrl+C를 입력하면 현재 명령문이 중단됩니다.

앞서 언급한 바와 같이 재귀 공통 테이블 표현식(CTE)은 계열 생성 및 계층적 또는 트리 구조 데이터 순회에 자주 사용됩니다. 이 섹션에서는 이러한 기술의 몇 가지 간단한 예를 보여줍니다.

피보나치 수열은 두 개의 숫자 0과 1(또는 1과 1)로 시작하며 그 이후의 각 숫자는 이전 두 숫자의 합입니다. 재귀 공통 테이블 표현식은 재귀 SELECT에 의해 생성된 각 행이 계열의 이전 두 숫자에 액세스할 수 있는 경우 피보나치 수열을 생성할 수 있습니다. 다음 CTE는 0과 1을 처음 두 숫자로 사용하여 10개의 숫자 계열을 생성합니다.

WITH RECURSIVE fibonacci (n, fib_n, next_fib_n) AS
(
  SELECT 1, 0, 1
  UNION ALL
  SELECT n + 1, next_fib_n, fib_n + next_fib_n
    FROM fibonacci WHERE n < 10
)
SELECT * FROM fibonacci;

CTE는 다음 결과를 생성합니다.

+------+-------+------------+
| n    | fib_n | next_fib_n |
+------+-------+------------+
|    1 |     0 |          1 |
|    2 |     1 |          1 |
|    3 |     1 |          2 |
|    4 |     2 |          3 |
|    5 |     3 |          5 |
|    6 |     5 |          8 |
|    7 |     8 |         13 |
|    8 |    13 |         21 |
|    9 |    21 |         34 |
|   10 |    34 |         55 |
+------+-------+------------+

CTE 작동 방식:

앞의 출력은 전체 CTE 결과를 보여줍니다. 일부만 선택하려면 최상위 SELECT에 적절한 WHERE 절을 추가합니다. 예를 들어 8번째 피보나치 수를 선택하려면 다음과 같이 하십시오.

mysql> WITH RECURSIVE fibonacci ...
       ...
       SELECT fib_n FROM fibonacci WHERE n = 8;
+-------+
| fib_n |
+-------+
|    13 |
+-------+

공통 테이블 식은 일련의 연속 날짜를 생성할 수 있으며, 이는 요약 데이터에 표시되지 않은 날짜를 포함하여 계열의 모든 날짜에 대한 행을 포함하는 요약을 생성하는 데 유용합니다.
판매량 테이블에 다음 행이 포함되어 있다고 가정합니다.

mysql> SELECT * FROM sales ORDER BY date, price;
+------------+--------+
| date       | price  |
+------------+--------+
| 2017-01-03 | 100.00 |
| 2017-01-03 | 200.00 |
| 2017-01-06 |  50.00 |
| 2017-01-08 |  10.00 |
| 2017-01-08 |  20.00 |
| 2017-01-08 | 150.00 |
| 2017-01-10 |   5.00 |
+------------+--------+

이 쿼리는 일일 판매를 요약합니다.

mysql> SELECT date, SUM(price) AS sum_price
       FROM sales
       GROUP BY date
       ORDER BY date;
+------------+-----------+
| date       | sum_price |
+------------+-----------+
| 2017-01-03 |    300.00 |
| 2017-01-06 |     50.00 |
| 2017-01-08 |    180.00 |
| 2017-01-10 |      5.00 |
+------------+-----------+

그러나 이 결과에는 테이블에 포함된 날짜 범위에 표시되지 않은 날짜에 대한 "구멍"이 포함되어 있습니다. 범위의 모든 날짜를 나타내는 결과는 판매 데이터에 대한 LEFT JOIN과 조인된 해당 날짜 집합을 생성하는 재귀 CTE를 사용하여 생성할 수 있습니다.

날짜 범위 시리즈를 생성하는 CTE는 다음과 같습니다.

WITH RECURSIVE dates (date) AS
(
  SELECT MIN(date) FROM sales
  UNION ALL
  SELECT date + INTERVAL 1 DAY FROM dates
  WHERE date + INTERVAL 1 DAY <= (SELECT MAX(date) FROM sales)
)
SELECT * FROM dates;

CTE는 다음 결과를 생성합니다.

+------------+
| date       |
+------------+
| 2017-01-03 |
| 2017-01-04 |
| 2017-01-05 |
| 2017-01-06 |
| 2017-01-07 |
| 2017-01-08 |
| 2017-01-09 |
| 2017-01-10 |
+------------+

판매 테이블에 대해 LEFT JOIN을 사용하여 CTE를 조인하면 범위의 각 날짜에 대한 행이 있는 판매 요약이 생성됩니다.

WITH RECURSIVE dates (date) AS
(
  SELECT MIN(date) FROM sales
  UNION ALL
  SELECT date + INTERVAL 1 DAY FROM dates
  WHERE date + INTERVAL 1 DAY <= (SELECT MAX(date) FROM sales)
)
SELECT dates.date, COALESCE(SUM(price), 0) AS sum_price
FROM dates LEFT JOIN sales ON dates.date = sales.date
GROUP BY dates.date
ORDER BY dates.date;

+------------+-----------+
| date       | sum_price |
+------------+-----------+
| 2017-01-03 |    300.00 |
| 2017-01-04 |      0.00 |
| 2017-01-05 |      0.00 |
| 2017-01-06 |     50.00 |
| 2017-01-07 |      0.00 |
| 2017-01-08 |    180.00 |
| 2017-01-09 |      0.00 |
| 2017-01-10 |      5.00 |
+------------+-----------+

재귀 공통 테이블 표현식은 계층 구조를 형성하는 데이터를 순회하는 데 유용합니다. 회사의 각 직원에 대해 직원 이름과 ID 번호, 직원 관리자의 ID를 표시하는 작은 데이터 세트를 생성하는 다음 명령문을 고려하십시오. 최상위 직원(CEO)의 관리자 ID는 NULL(관리자 없음)입니다.

CREATE TABLE employees (
  id         INT PRIMARY KEY NOT NULL,
  name       VARCHAR(100) NOT NULL,
  manager_id INT NULL,
  INDEX (manager_id),
FOREIGN KEY (manager_id) REFERENCES employees (id)
);
INSERT INTO employees VALUES
(333, "Yasmina", NULL),  # Yasmina is the CEO (manager_id is NULL)
(198, "John", 333),      # John has ID 198 and reports to 333 (Yasmina)
(692, "Tarek", 333),
(29, "Pedro", 198),
(4610, "Sarah", 29),
(72, "Pierre", 29),
(123, "Adil", 692);

mysql> SELECT * FROM employees ORDER BY id;
+------+---------+------------+
| id   | name    | manager_id |
+------+---------+------------+
|   29 | Pedro   |        198 |
|   72 | Pierre  |         29 |
|  123 | Adil    |        692 |
|  198 | John    |        333 |
|  333 | Yasmina |       NULL |
|  692 | Tarek   |        333 |
| 4610 | Sarah   |         29 |
+------+---------+------------+

각 직원의 관리 체인(즉, CEO에서 직원으로의 경로)이 포함된 조직도를 생성하려면 재귀 CTE를 사용합니다.

WITH RECURSIVE employee_paths (id, name, path) AS
(
  SELECT id, name, CAST(id AS CHAR(200))
    FROM employees
    WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.name, CONCAT(ep.path, ',', e.id)
    FROM employee_paths AS ep JOIN employees AS e
      ON ep.id = e.manager_id
)
SELECT * FROM employee_paths ORDER BY path;

+------+---------+-----------------+
| id   | name    | path            |
+------+---------+-----------------+
|  333 | Yasmina | 333             |
|  198 | John    | 333,198         |
|   29 | Pedro   | 333,198,29      |
| 4610 | Sarah   | 333,198,29,4610 |
|   72 | Pierre  | 333,198,29,72   |
|  692 | Tarek   | 333,692         |
|  123 | Adil    | 333,692,123     |
+------+---------+-----------------+

특정 직원의 경로를 찾으려면 최상위 SELECT에 WHERE 절을 추가합니다. 예를 들어 Tarek과 Sarah에 대한 결과를 표시하려면 해당 SELECT를 다음과 같이 수정합니다.

mysql> WITH RECURSIVE ...
       ...
       SELECT * FROM employees_extended
       WHERE id IN (692, 4610)
       ORDER BY path;
+------+-------+-----------------+
| id   | name  | path            |
+------+-------+-----------------+
| 4610 | Sarah | 333,198,29,4610 |
|  692 | Tarek | 333,692         |
+------+-------+-----------------+

공통 테이블 표현식(CTE)은 몇 가지 면에서 파생 테이블과 유사합니다.

이러한 유사성으로 인해 CTE와 파생 테이블은 종종 서로 바꿔서 사용할 수 있습니다. 간단한 예로, 다음 문장은 동일합니다.

WITH cte AS (SELECT 1) SELECT * FROM cte;
SELECT * FROM (SELECT 1) AS dt;

그러나 CTE는 파생 테이블에 비해 몇 가지 장점이 있습니다.

빅 데이터의 3대 요소(3V)

빅 데이터의 가치와 진실

지난 몇 년간 value와 veracity라는 두 가지 V가 더 등장했습니다. 데이터는 내재적 가치를 가집니다. 그러나 가치는 발견이 되기 전까지는 무용지물입니다. 중요성: 데이터가 얼마나 진실하고 신뢰할 수 있습니까?

오늘날에는 빅 데이터가 자본이 되었습니다. 세계에서 가장 큰 기술 회사를 생각해 보십시오. 이들이 제공하는 가치의 대부분은 데이터에서 나오고 있으며, 효율성을 높이고 신제품을 개발하기 위해 데이터를 지속적으로 분석하고 있습니다.

최근의 기술 혁신으로 데이터 스토리지 및 컴퓨팅 비용이 대폭 감소하면서 이전보다 더 많은 데이터를 보다 쉽고 저렴하게 저장할 수 있게 되었습니다. 더 많은 양의 빅 데이터를 보다 저렴하고 손쉽게 액세스할 수 있게 되면서 보다 정확하고 정밀하게 비즈니스 결정을 내릴 수 있게 되었습니다.

빅 데이터에서 가치를 찾는 것은 단순히 데이터를 분석하는 일이 아닙니다(분석은 완전히 다른 이점을 제공). 통찰력 있는 분석가, 비즈니스 사용자 및 경영진이 올바른 질문을 던지고, 패턴을 인식하고, 정보에 입각한 가정을 세우고, 행동을 예측해야 하는 전체적인 발견 프로세스입니다.

그렇다면 어떻게 여기까지 올 수 있었을까요?

빅 데이터의 역사

빅 데이터 자체의 개념은 비교적 새로운 것이지만, 대규모 데이터 세트의 기원은 최초의 데이터 센터가 등장하고 관계형 데이터베이스가 개발되는 등 데이터 세상이 막 시작되었던 1960년대와 70년대로 거슬러 올라갑니다.

2005년 무렵 사람들은 Facebook, YouTube 및 기타 온라인 서비스를 통해 사용자가 얼마나 많은 양의 데이터를 생성하고 있는지 깨닫기 시작했습니다. 같은 해에 Hadoop(빅 데이터 세트를 저장하고 분석하기 위해 특별히 개발된 오픈 소스 프레임워크)이 개발되었습니다. NoSQL도 이 기간 동안 인기를 얻기 시작했습니다.

Hadoop(그리고 최근에는 Spark) 같은 오픈 소스 프레임워크의 개발은 빅 데이터를 보다 손쉽게 사용하고 저렴하게 저장할 수 있게 해준다는 점에서 빅 데이터의 성장에 필수적이었습니다. 그 이후로 빅 데이터의 양이 급증했습니다. 사용자는 여전히 방대한 양의 데이터를 생성하고 있지만, 데이터를 생성하는 것은 인간만이 아닙니다.

Internet of Things(IoT)의 출현으로 더 많은 객체와 장치가 인터넷에 연결되어 고객 사용 패턴 및 제품 성능에 대한 데이터를 수집하고 있습니다. 머신러닝의 등장으로 더 많은 데이터가 생성되었습니다.

빅 데이터의 역사는 오래되었지만, 활용은 이제 시작 단계입니다. 클라우드 컴퓨팅으로 빅 데이터 가능성이 더욱 확장되었습니다. 클라우드는 개발자가 임시 클러스터를 손쉽게 가동하여 데이터 하위 집합을 테스트할 수 있도록 진정한 의미에서 탄력적인 확장성을 제공합니다. 또한 그래프 데이터베이스는 분석 속도를 높이고 포괄적인 방식으로 대량의 데이터를 표시할 수 있으므로 점점 더 중요해지고 있습니다.

빅데이터의 이점:

• 빅 데이터를 사용하면 더 많은 정보를 확보할 수 있기 때문에 보다 완벽한 답을 얻을 수 있습니다.
• 답이 완벽하다는 것은 데이터의 신뢰성이 높아진다는 의미입니다. 따라서 문제 해결에 대한 완전히 다른 접근 방식이 가능합니다.

빅 데이터 사용 사례

빅 데이터는 고객 경험에서 분석에 이르기까지 다양한 비즈니스 활동을 처리하는 데 도움이 될 수 있습니다. 다음은 몇 가지 예일 뿐이고,

빅 데이터는 많은 것을 약속하고 있지만, 해결해야 할 과제가 없지는 않습니다.

먼저 빅 데이터는 크기가 큽니다. 데이터 스토리지를 위한 신기술이 개발되기는 했지만, 약 2년마다 데이터 양의 2배 증가하고 있습니다. 따라서 조직들은 데이터 증가를 따라잡고 데이터를 효과적으로 저장하는 방법을 찾느라 고군분투하고 있습니다.

그러나 데이터를 저장하는 것만으로는 충분하지 않습니다. 데이터는 가치 있게 사용되어야 하고, 이는 큐레이션에 따라 결정됩니다. 클라이언트와 관련이 있고 의미 있는 분석이 가능한 방식으로 구성된 정제 데이터를 확보하려면 많은 작업이 필요합니다. 데이터 과학자는 작업 시간의 50~80%를 실제 사용하기 전에 데이터를 큐레이션하고 준비하는 데 할애하고 있습니다.

마지막으로 빅 데이터 기술은 빠른 속도로 변화하고 있습니다. 몇 년 전만 해도 Apache Hadoop는 빅 데이터 처리에 사용되는 인기 기술이었습니다. Apache Spark는 2014년에 도입되었습니다. 오늘날 두 가지 프레임워크를 조합하는 것이 가장 좋은 접근 방식인 것으로 보입니다. 빅 데이터 기술을 따라 잡는 것은 지속적인 도전입니다.

빅 데이터의 작동 원리

빅 데이터는 새로운 기회와 비즈니스 모델을 열어주는 새로운 통찰력을 제공합니다. 시작을 위해 세 가지 주요 작업이 수행됩니다.

1.  통합
빅 데이터는 서로 다른 종류의 소스와 어플리케이션으로부터 데이터를 수집해 종합합니다. 추출, 변환 및 로드(ETL)와 같은 기존의 데이터 통합 메커니즘은 일반적으로 이러한 작업에 적합하지 않습니다. 테라바이트 또는 페타바이트 규모로 빅 데이터 세트를 분석하려면 새로운 전략과 기술이 필요합니다.

통합하는 동안 데이터를 가져와서 처리하고, 비즈니스 분석가가 분석을 시작할 수 있는 형식으로 포맷팅되었는지 확인해야 합니다.

2.
빅 데이터를 관리하려면 스토리지가 필요합니다. 스토리지 솔루션은 클라우드, 온프레미스 또는 둘 다에서 사용할 수 있습니다. 데이터를 원하는 형식으로 저장하고, 원하는 처리 요구사항과 필요한 프로세스 엔진을 온디맨드 모델을 기반으로 해당 데이터 세트에 적용할 수 있습니다. 많은 사람들이 현재 데이터가 상주하는 위치에 따라 스토리지 솔루션을 선택하고 있습니다. 클라우드는 현재 컴퓨팅 요구사항을 지원하고 필요에 따라 리소스를 가동할 수 있다는 점에서 점차 인기를 얻고 있습니다.

3.  분석
빅데이터에 대한 투자는 데이터를 분석 및 처리할 때 그 가치를 발휘합니다. 다양한 데이터 세트의 시각적 분석을 통해 새로운 명확성을 확보할 수 있습니다. 새로운 발견을 위해 데이터를 추가로 탐색할 수 있습니다. 또한 발견한 내용을 다른 사람들과 공유할 수 있습니다. 머신러닝 및 인공 지능으로 데이터 모델을 구축할 수 있습니다. 데이터를 업무에 활용할 수 있습니다.

빅 데이터 모범 사례

빅 데이터 여정에 도움을 드리기 위해 반드시 기억해야 할 몇 가지 주요 모범 사례를 모아봤습니다. 다음은 성공적인 빅 데이터 토대를 구축하기 위한 지침입니다.

참조문서 : https://www.oracle.com/kr/big-data/what-is-big-data/#how